Subject: RE: [SIP] RE: SCTP as transport for SIP

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sat, 24 Mar 2001 04:11:52 -0800

Damn I hate it when I find problems in my own suggestions. Using an
unordered reliable channel may increase the likelihood of an INVITE being
delivered after a CANCEL (and other quirky situations). Good SIP
implementations should be able to handle this (as out-of-order delivery is
quite possible in normal UDP) but it may produce more confusion in some
implementations. So is it worth using multiple reliable ordered streams for
each transaction or call-leg to overcome any head-of-line blocking in a
single ordered reliable stream? Maybe. As I've said in a previous email, it
rules out using any other streams in the association for other purposes (in
a clean manner) and makes it difficult for the reciever to make use of the
separation. Is this a worthwhile tradeoff ?
 
The alternative is to allow the specification of which stream to use in the
contact & via. This allows the separation of streams but additionally allows
the receiving side to also make use of this separation. In the long run, I
think this is a better solution for more efficient use of SCTP associations.
Jonathan, you still have reservations ?
 
Cheers,
 
Robert.
 
-- My opinions should not be taken as necessarily representing those of
Nuera Communications, Inc. --

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Friday, March 23, 2001 4:17 PM
To: 'Tom-PT Taylor'
Cc: [email-masked]'
Subject: RE: [SIP] RE: SCTP as transport for SIP

Ok, let's sneak this reply in between the IETF and the bakeoff. 
 
I disagree with your conclusions. First of all I would like to rule out
demultiplexing of protocols via the payload id. In my mind, this is akin to
demultiplexing multiple RTP sessions by using the SSRC - ugly. It all boils
done to the fact that an SCTP stream provides a number of properties - it is
NOT just an arbitrary demultiplexing value like UDP ports. Likewise, in my
mind sending unrelated reliable and unrelible data flows using differing
per-packet behaviours is again ugly and misses the point of SCTP. There are
reason why we have SCTP streams - so that logical flows can be separated
(each with its own delivery parameters) without this sort of ugliness (see
Footnote 1). 
 
I can not see how this whole idea of saying that SIP can arbitrarily send on
streams without even specifying which it will be using is:
a) not a very good design - if you are going to use multiple streams then it
should be specified.
b) specifying API implementation
c) not allowing future extensions of SIP to properly use or negotiate the
use of within the association (because you have arbitrarily used _all_
streams).
 
If you are saying that an SCTP enabled SIP UA/proxy may use a separate
stream per transaction or per call to overcome head of line blocking then I
would say that you should be instead be using an the unordered reliable
delivery option on a single stream. If the stream cannot be specified, then
what way is the receiving SIP device able to use that separation of the
streams for any benefit ? It can't. So if the recieving UA/proxy can't
separate the streams then the SIP device may as well use stream 0 for all
unspecified streams in an unordered reliable delivery manner. 
 
Summary: To arbitrarily send on any stream in SIP (ie, without stream
specification) is effectively wasting any usefulness provided by SCTP
streams and rules out any future improvements. Why do you feel that using
arbitrary streams (without specification) is a) a good idea and b) better
than using a single unordered (or ordered) reliable stream ?
 
Regards,
 
Robert.
 
Footnote 1: The U-SCTP draft requires that a stream is explicitly configured
as either relaible or unreliable. Arbitrarily/unnecessarily over-riding this
transport property with per-packet behaviours should not be encouraged in my
mind. 

-- My opinions should not be taken as necessarily representing those of
Nuera Communications, Inc. -- 

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Monday, March 19, 2001 3:08 PM
To: Fairlie-Cuninghame, Robert
Cc: [email-masked]'
Subject: RE: [SIP] RE: SCTP as transport for SIP

There are two issues here: SIP-level assignment to streams and SDP-level
assignment to streams (which applies only to media flows).
 
At the SIP level: let me point out that SCTP actually allows protocol
multiplexing at the stream level.  Each DATA chunk has its own protocol
identifier as well as stream identifier.  An application must therefore be
prepared to monitor all streams in an association and receive relevant data
from any stream UNLESS we standardize more restrictive behaviour.  Quite
frankly, I don't see why we should do so.  Certainly, requiring that all SIP
signalling use stream 0 by default is far too restrictive.
 
At the media level, I could see a case for specifying the stream number for
a given media flow within the SDP.  Again, this isn't totally necessary, but
it makes more sense than in the SIP case.  It's obvious that you can't
multiplex data to be delivered reliably and data to be delivered unreliably
within the same SCTP packet.  That can be taken care of by specifying
per-packet behaviour in the SCTP layer, and probably has to be.  (I haven't
read Randy's draft yet.)  However, dedicating specific streams to media
transport seems like logical application behaviour. 
 
 -----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Saturday, March 17, 2001 11:29 AM
To: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B881:EXCH]
Cc: [email-masked]'
Subject: RE: [SIP] RE: SCTP as transport for SIP

> 
> I think that such a generic adaptation layer is a bad idea. 
> 
> The reason is that one already exists - port numbers. Doing 
> what Robert is 
> describing will require not just SIP, but *every* application 
> and system 
> that uses port numbers to now incorporate another demux 
> identifier, the SCTP 
> stream ID. We'd need to update DNS specifications, NATs, IANA 
> registrations, 
> and the whole nine yards. I'd rather not. I just don't see a 
> need for yet 
> another layer of demux. 
> 
> So, given that just SIP runs over an SCTP association, since 
> the association 
> is setup by SIP, any stream can be used by SIP, and we are 
> back to where we 
> started, which is that nothing extra is required for SCTP. 
> 

Hi Jonathan, 

As I said in my last email, I agree that there are problems and I do not
propose to have all the answers. 

However, if we are going to use SCTP for SIP then we should do it properly.
Each association has both internal and network overhead associated with it
(unlike TCP which only has internal overhead). SIP Proxies and gateways
often use the port field to perform state machine demux - this would result
in a huge number of associations if each had to have its own association
(because it uses a different port). This is doubled if both sides use this
technique. [Obviously this would not be a good way of implementing things
for a proxy using SCTP.]

I think that most of the cases that you mentioned need changing (DNS, NATS,
IANA) are independent of this argument. In order to make anything use SCTP
transport then it must be able to specify or understand SCTP parameters to
some extent (so you've already gone 7 of those 9 yards). For instance, if
SIP UA/proxy understands the transport=SCTP option thenn it is should also
be able to understand other options. 

Ok let's take a look at your suggestion that SIP may send/recv to any stream
in an association. In my mind it would at least be better to say that if a
service is not dynamically negotiated or statically configured [ie, known to
be otherwise] then it should be assumed to be sending/recving on the first
(zeroth) stream in the association. This assumes that one application is
controlling an SCTP endpoint (which I don't think is a bad assumption) and
that service can be located by doing a plain old DNS lookup without any need
for specifying a stream in the response. Then at least sub-services (also
controlled by the application) can make use of the other streams in the same
association by using SCTP-aware negotiation or specification.

Many media-based application layer protcols are made to be transport-layer
independent (ie, carry no transport layer information in the packets), eg,
RTP. So for instance SDP can be easily expanded to encompass SCTP which
covers a lot of the ground for negotiation in media-based application. 

Making the default stream in both directions be zero at least allows you to
introduce changes/extensions incrementally rather than locking them out
entirely.

Robert. 

-- My opinions should not be taken as necessarily representing those of
Nuera Communications, Inc. --

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 25 Mar 2001 06:56:41 +0300

Hello Robert,

A SIP application has different behaviors depending on whether the
transport protocol is is reliable or not (typically TCP or UDP).
However, there is no distinction between an ordered or an unordered
transport.

A SIP UA will typically send a request per RTT. So, typically there are
no unordered requests. In the cases that this actually happens
(receiving a BYE before the INVITE, for instance) the SIP application is
ready to handle it. A SIP server using TCP cannot expect that requests
arrive in order just because it is using TCP. The TCP connection is
established just to the previous hop. The previous hop might be using
UDP towards its previous hop.

Therefore, a SIP application cannot be confused by the arrival of
unordered requests. Besides, SIP carries Cseq.

Since current application make no assumption about the network providing
an ordered service, the SCTP unordered service is the way to go.

So, let's focus on how to manage stream ids within an unordered service.

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Mar 2001 00:22:38 -0600

Gonzalo,

A side-effect of using SCTP's unordered service is that implementation
of the unordered service under SCTP can include the concept of urgent
data: unordered chunks can be delivered ahead of ordered chunks.

Now it may be that SIP does not wish to later use this urgent data
concept, however, why preclude it?

--Brian

Gonzalo Camarillo wrote:                  (Sun, 25 Mar 2001 06:56:41)

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Mar 2001 01:19:10 -0600

Gonzalo,

I should also point out, that if SIP messages become fragmented between
data chunks (quite possible when doing SOCK_STREAM style writes), they
will be reassembled and delivered in order by the receiver, anyway.

Brian F. G. Bidulock wrote:                  (Tue, 27 Mar 2001 00:22:38)