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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Mar 2001 02:37:31 -0500

-----Original Message-----
>From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
>Sent: Saturday, March 24, 2001 7:12 AM
>To: 'Tom-PT Taylor'
>Cc: [email-masked]'
>Subject: RE: [SIP] RE: SCTP as transport for SIP
>
>
>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 ?

I have many reservations.

I spoke to several people at IETF about SCTP, and the answer I consistently
got (and this includes Allison), is that SCTP usage should not require new
signaling of stream IDs. 

I have a more fundamental problem. Why bother? No one has yet to demonstrate
to me that SCTP will bring any benefits to SIP. I know already that the
failover performance is WORSE with SCTP than with the currently specified
SIP mechanisms. I am unconvinced that the head of line blocking problem is
"solved", in fact. I believe I can demonstrate that the average latency for
transmitting  a packet across an SCTP connections with N streams is worse
than an SCTP connection with one stream, or a TCP connection. How?
Fundamental queueing theory. Remember, even though SCTP has multiple
streams, its still congestion controlled. Let me assume that we have a total
rate of lambda that the congestion control algorithm allows for the
association, and that this is split across N streams. Now, you can model
this as a system of N queues, each being served at rate LAMBDA/N. Data is
fed into the queue and transmitted when serviced. In the case of one stream,
its a single queue, being served at rate N. It is a well known result of
queuing theory that a queueing system with N queues at rate LAMBDA/N has a
worse average latency than a single queue with rate LAMBDA. So, the average
latency for the use of SCTP will be HIGHER. Now, maybe it turns out that you
get lower variance in the latency (and I suspect it is true); I don't know
the result. The point is - what is the problem being solved? If you think
you are reducing the average latency, well, you're not!

I really worry that SCTP is being pushed as a panacea for problems we don't
even know we have. So, I still wait for someone to tell me the problem, and
then show me why SCTP is the solution. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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 02:35:37 -0600

Jonathan,

Your math is off.  SCTP does not rate limit its streams.  All
streams share the same receive and congestion window.  One is
allowed to hog the entire LAMBDA if it wants.  There is no
difference between the latency of the same traffic on one stream
versus the determinate or indeterminate splitting of the same
traffic over multiple streams.  They all meet at the same
overall congestion window.

Actually, you could choose the stream to send on at random and
the only difference on the line would be the contents of 2 bytes
per data chunk.  You see, SCTP really only tags data with the
stream identifier and sequence number.  The sender has no other
use for the information.  All retransmission and windowing is
performed at the Association (connection) level and not at the
stream level.

There is a draft for per-stream receive windowing which might
cause the effect you describe, but this is not part of RFC 2960.

On the other hand, you may be correct in saying that SCTP does
not solve the head-of-line blocking problem.  Particularly when
data chunk fragmentation is occuring, a missing packet may block
all other streams until it is retransmitted and successfully
received.  This may actually be worse that multiple TCP
connections which, although they do suffer from HOL blocking, do
not block other TCP connections when they do.

Other characteristics of SCTP include preservation of message
boundaries (which is meaningless to SIP), and multi-homing
(which only really works well over a "controlled" network and
causes port problems for SIP when used).

--Brian

Jonathan Rosenberg wrote:                       (Tue, 27 Mar 2001 02:37:31)
[snip]
> you are reducing the average latency, well, you're not!
[snip]

-- 
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: Matt Holdrege <[email-masked]>
Date: Tue, 27 Mar 2001 17:38:44 -0800

(from the SCTP AS)

For SIP, considering the use of a reliable transport protocol (i.e. not 
UDP) the features of SCTP would be:

- acknowledged error-free non-duplicated transfer of user data,

- data fragmentation to conform to discovered path MTU size,

- sequenced delivery of user messages within multiple streams,
   with an option for order-of-arrival delivery of individual user
   messages,

- optional bundling of multiple user messages into a single SCTP packet,

- network-level fault tolerance through supporting of multi-homing at 
either or both ends of an association.

Applications that require framing of reliable data streams can get that
feature from SCTP.

Applications which transfer independent message sequences that are 
unrelated (sometimes called transactions) can benefit from the partial 
ordering provided by SCTP streams.

Applications that wish to transfer messages that hold no particular
sequence or relationship to one another can benefit from the unordered
service provided by SCTP.

Finally for those applications seeking network layer redundancy with
multiple Network Interface cards can use SCTP's multi-homing feature.

Is there any misunderstanding or disagreement with the above?