Subject: RE: [Simple] Sessions of MESSAGEs

From: "Robert Osborne" <[email-masked]>
Date: Mon, 20 Aug 2001 09:54:59 -0700

Hi,

I agree with Avshalom that MESSAGE should be allowed to be
carried over the normal SIP signalling transport, for several reasons

*	Creating a seperate TCP connection for a IM Session would
	be expensive, especially when going across firewalls
*	Allowing for the MESSAGE to travel along the normal
	signalling channel improves the authentication and
	security between domains

Rob O

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, August 20, 2001 9:32 AM
>To: [email-masked]
>Subject: Re: [Simple] Sessions of MESSAGEs
>
>
>
>Assuming that the SIMPLE protocol will develop over time to 
>give the same
>functionality as current IM systems, the
>restrictions imposed by inheritance from SIP bother me.
>
>What I am bothered about is that SIMPLE inherits the separation between
>signaling and media of SIP. It assumes a different transport for the
>signaling and the media. For example, in a conference the signaling
>(INVITEs/REFERs) should be done on a single TCP connection 
>while a new TCP
>connection should be created for sending the text messages of the
>conference.
>
>I am not sure if creating a new TCP connection for each IM 
>(when it is done
>by a session) or conference will scale. Maybe MESSAGE should 
>be allowed to
>be carried on the same transport as the INVITE message was sent on?
>
>-Avshalom
>Sametime/Lotus
>
>
>
>                                                               
>                                                                 
>                    "Peterson, Jon"                            
>                                                                 
>                    <[email-masked]>        To:     
>"[email-masked]'"                                
>                    Sent by:                          
><[email-masked]>                               
>           
>                    [email-masked]        cc:      
>                                                                 
>                    icsoft.com                        Subject: 
>    [Simple] Sessions of MESSAGEs                                
>                                                               
>                                                                 
>                                                               
>                                                                 
>                    20/08/2001 17:47                           
>                                                                 
>                                                               
>                                                                 
>                                                               
>                                                                 
>
>
>
>
>After the SIMPLE session last week in London, the SIMPLE 
>chairs received
>some feedback from the IESG with regards to the use of the 
>MESSAGE method
>end-to-end when an IM session has been established with an INVITE (as
>described in draft-ietf-simple-im-session-00).
>
>The IESG has some concerns that this mechanism constitutes the 
>use of SIP
>as
>a transport protocol. In other words, once the session has 
>been established
>between the two endpoints by the INVITE, if the MESSAGEs can only go
>directly end-to-end, then their headers and related protocol 
>apparatus are
>entirely superfluous and may do more harm than good. We saw during the
>meeting last week that there were definitely some pitfalls to allowing
>methods other than MESSAGE across the IM stream (as well as 
>questions about
>overlapping transactions, redirection, forking, and so forth), 
>and it isn't
>clear that the overhead is justified if MESSAGE is just an 
>envelope for its
>encapsulated MIME payload. The IESG was particularly 
>concerned, in addition
>to the protocol overhead, with congestion characteristics of 
>the messaging
>session and with the precedent that could be set by using SIP in this
>fashion.
>
>For these reasons, the IESG is not inclined to look favorably on that
>direction for our protocol work. They also weren't 
>enthusiastic about the
>potential use of RTP text for message transmission 
>(significant concerns
>were also raised on the floor in London about message framing, 
>especially
>at
>CPIM gateways). The recommendation we've been given is to focus on a
>standard transport protocol with understood congestion 
>properties such as
>TCP or SCTP. In London, Ben Campbell took an action item to begin
>investigating alternatives along these lines given the 
>significant concerns
>that arose on the floor with regards to the other approaches. 
>It seems that
>the primary question about this approach is what runs over the 
>transport
>protocol in question; i.e. MIME headers and bodies, pure message/cpim,
>BEEP,
>plain text, etc.
>
>If anyone feels strongly that we should continue to pursue the 
>use of the
>MESSAGE method for direct end-to-end IM signaling, or has 
>input about how
>the transport should operate, let's get this discussion 
>underway promptly
>so
>we can meet our projected September deliverables.
>
>Jon Peterson
>NeuStar, Inc
>SIMPLE co-chair
>
>_______________________________________________
>simple mailing list
>[email-masked]
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>
>
>
>_______________________________________________
>simple mailing list
>[email-masked]
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 20 Aug 2001 23:21:44 -0500

Ok, there's THREE topics:

1) MESSAGE sessions established directly between two nodes using SIP which
is routed by proxies.
2) MESSAGE transmissions outside of a session routed by proxies ("Pager
mode")
3) MESSAGE sessions between two nodes, where those messages are routed by
proxies using the routing semantics of any other SIP message. Oddly enough,
this begins to look a lot like BXXP.

We're debating #1 here.

#2 is still in the work plan.

As for #3, I like it -- I think it has a lot of advantages, and Robert has
definitely hit on some of them. But not all .For example, at some point,
we'll have the same kind of "privacy" concerns with message routing as we
now have with call routing. We'll want suppression of source location
information, network-authenticated remote-party-ID, the Privacy: header and
its accompanying semantics, etc. Guess what? We've already figured those out
for SIP "system" messaging, for the most part. Why not re-use the
infrastructure for "user" messaging? Sure it'll create server overhead. But
it will work the way we need it to work. You get what you pay for.

On the other hand, do we really need a "message session", or are serialized
"pager messages" with retransmission and in-order assembly by the
application good enough?

--
Dean

---

From: Vasilis Polychronidis <[email-masked]>
Date: Mon, 20 Aug 2001 22:10:55 -0700

Ok I am a little confused here.
Here is a quote from Jon Peterson's previous E-mail:
Dean please read my comments below:

After the SIMPLE session last week in London, the
SIMPLE chairs received
some feedback from the IESG with regards to the use of
the MESSAGE method
end-to-end when an IM session has been established with
an INVITE (as
described in draft-ietf-simple-im-session-00).

The IESG has some concerns that this mechanism
constitutes the use of SIP as
a transport protocol. In other words, once the session
has been established
between the two endpoints by the INVITE, if the
MESSAGEs can only go
directly end-to-end, then their headers and related
protocol apparatus are
entirely superfluous and may do more harm than good.

Dean which of the above statements up to this point did not understand?

We
saw during the
meeting last week that there were definitely some
pitfalls to allowing
methods other than MESSAGE across the IM stream (as
well as questions about
overlapping transactions, redirection, forking, and so
forth), and it isn't
clear that the overhead is justified if MESSAGE is just
an envelope for its
encapsulated MIME payload. The IESG was particularly
concerned, in addition
to the protocol overhead, with congestion
characteristics of the messaging
session and with the precedent that could be set by
using SIP in this
fashion.

For these reasons, the IESG is not inclined to look
favorably on that
direction for our protocol work. They also weren't
enthusiastic about the
potential use of RTP text for message transmission
(significant concerns
were also raised on the floor in London about message
framing, especially at
CPIM gateways). The recommendation we've been given is
to focus on a
standard transport protocol with understood congestion
properties such as
TCP or SCTP.

So we will have to work with standard transport protocol
such as TCP, SCTP, etc.
Dean is this clear to you?

In London, Ben Campbell took an action
item to begin
investigating alternatives along these lines given the
significant concerns
that arose on the floor with regards to the other
approaches. It seems that
the primary question about this approach is what runs
over the transport
protocol in question; i.e. MIME headers and bodies,
pure message/cpim, BEEP,
plain text, etc.

If anyone feels strongly that we should continue to
pursue the use of the
MESSAGE method for direct end-to-end IM signaling, or
has input about how
the transport should operate, let's get this discussion
underway promptly so
we can meet our projected September deliverables.

Dean are you proposing to use SIP as the transport in the IM Session case?

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

> 1) MESSAGE sessions established directly between two nodes using SIP which

MESSAGE method assumes SIP as the underlying transport method.
The consensus is not to do that. Please see above

> this begins to look a lot like BXXP.

MESSAGE method assumes SIP as the underlying transport manhood.
The consensus is not to do that. Please see above

> We're debating #1 here.

Correct. Robert initiated the debate. I am planning to answer all of his
concerns in a later E-mail.

> "pager messages" with retransmission and in-order assembly by the

Why the same topic arises again and again.
Here is a quote from a previous E-mail:

Jonathan,

Based on the other comments about sending MESSAGE over SIP signaling
paths,
it would then be necessary to segregate and prioritize SIP traffic to
prevent 1M IM messages from delaying SIP session setup traffic.

We don't need to repeat the problems that GSM systems had with SMS
traffic
interfering with call setup!

Mike

---

From: Ben Campbell <[email-masked]>
Date: Tue, 21 Aug 2001 10:03:33 -0500

> this begins to look a lot like BXXP.

Maybe it is to early in the morning for me, but I do not grasp the 
distinction between 1 and 3. Both appear to reduce to "message sessions 
over SIP routed by proxies". Perhaps the "routed by proxies" clause in 1 
was unintended?

[snip]

> "pager messages" with retransmission and in-order assembly by the

In all honesty, I hope we do not see a lot of 2 party messsage 
conversations invoking message sessions. The page model with a little 
intelligence on the client software's part is usually sufficient. You 
usually only invoke a session when you need something more than a two 
party conversation. You use it for N party conversation, or when you 
want to add and additional media type such as voice or video. For those 
cases, treating messaging like any other media stream has advantages.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 Aug 2001 13:42:31 -0500

In #1, only the session setup is over the proxy network, The actual
transport of messages in unspecified, but assumed to not be
sip-over-the-signaling-proxies. It might be TCP, or it might be end-to-end
SIP that does not traverse the signaling proxies.

in #3, the messages are carried by SIP over the same proxies that handle
other SIP messages, such as those used for setup. This gets us complete
reuse of privacy, firewall traversal, and all the other neat stuff in SIP
proxy networks.

--
Dean