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

From: "Lyndon Ong" <[email-masked]>
Date: Tue, 03 Apr 2001 13:17:14 -0700

Gonzalo,

Thanks for the link, this looks like a very nice paper.  In fact, some of the points might be good to incorporate/reference in the SCTP AS :o), esp. re: UDP vs. SCTP and the use of unordered service for some applications rather than multiple streams.  The AS authors are still working on the AS to make it more complete and clear (and unbiased).

Cheers,

Lyndon
--

On Tue, 03 Apr 2001 22:19:11   Gonzalo Camarillo wrote:
>Hello,
>
>You can check the following link out:
>http://www.cs.columbia.edu/~gonzalo/SIP_SCTP.pdf
>
>It compares advantages and disadvantages of using a single unordered
>stream over using multiple ordered streams to transport SIP.
>
>Best regards,
>
>Gonzalo
>
>La Monte Henry Piggy Yarroll wrote:
>> 
>> The purpose of streams in SCTP is to avoid head-of-line blocking.  A
>> single streams should ONLY be used for messages which have a strict
>> ordering requirement.  Standalone messages should travel via an
>> unordered stream.
>> 
>> The UA's DO allow multiple independant complex exchanges over separate
>> streams.  In many situations (e.g. telephony switching) it is
>> important to share congestion and flow-control information.  If you
>> DIDN'T use streams over a single SCTP association, you'd have to pay
>> the slow-start penalty for every new exchange.
>> 
>> "Fairlie-Cuninghame, Robert" <[email-masked]> writes:
>> > Hi Matt,
>> >
>> > I'm not convinced that SIP needs to use ordered delivery of messages across
>> > multiple streams. If we are not using stream specification within SIP (and I
>> > think I agree with you now Jonathan) then I believe SIP should be using a
>> > single unordered reliable stream rather than any/all the streams.
>> >
>> > -     This is simpler and as has been said before, a more complicated SIP
>> > adaptation layer may cause more complexity in transport-ignorant systems
>> > (whatever that might be <grin>). This is also closer to the model used by
>> > the existing SIGTRAN adaptation layers (ie, one link => one stream).
>> > -     The process of enforcing that an application must accept packets on
>> > all streams may force implementations on the API and design of the SCTP
>> > stack. The stack uses the concept of "used" and "unused" streams - what
>> > effect does using 64K streams on an association have on memory requirements.
>> > This may not be a relevant concern but I think SIP should try to be more
>> > conservative in its use of SCTP.
>> > -     The sending of  different call legs to different streams does not
>> > help much in my opinion. A single stream must still be able to accept
>> > packets for multiple call legs.
>> > -     Using arbitrary streams does not allow the use of other streams for
>> > any future purpose.
>> >
>> > I'm also not convinced that the bundling of SIP messages is that useful -
>> > SIP messages are usually quite large anyway. However, an interesting
>> > application for SCTP with SIP might be on low bandwidth point to point
>> > connections. The SIP application controls the association and so it is not
>> > too unreasonable that the SIP application may negotiate the use of other
>> > streams in the same association for media use. Now the fragmentation
>> > properties of SCTP could reduce any delay/jitter in the media carried on the
>> > same SCTP association. This is not possible if SIP and media are carried in
>> > separate streams. [This is probably not a main-stream application and maybe
>> > not even useful/desirable but I don't think it should be impossible.]
>> >
>> > Jonathan, I see you think that SCTP is not worth the trouble for SIP. I
>> > think that SCTP becomes more attractive to SIP when the media also uses SCTP
>> > such that SCTP becomes the only transport protocol needed (although not
>> > necessarily on the same association). SCTP has the interesting property that
>> > it makes the normally connectionless unreliable UDP media become
>> > connection-oriented unreliable U-SCTP media. I can even foresee that in the
>> > future, SCTP associations could be linked to hardware routing and resource
>> > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of any
>> > work in this field although the stream-based flow-limiting extension is
>> > useful - sounds like a good thesis/paper to me.] Anyway, the only piece
>> > missing is an SDP profile for SCTP (which I'm still in the process of
>> > proposing something - input welcome).
>> >
>> > Comments please.
>> >
>> > Cheers,
>> >
>> > Robert.
>> >
>> > -- My opinions should not be taken as necessarily representing those of
>> > Nuera Communications, Inc. --
>> >
>> > -----Original Message-----
>> > From: Matt Holdrege [mailto:[email-masked]]
>> > Sent: Wednesday, March 28, 2001 3:39 AM
>> > To:   [email-masked]
>> > Subject:      Re: [SIP] RE: SCTP as transport for SIP
>> >
>> > (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?
>> >
>> >
>> > _______________________________________________
>> > 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.
>> >
>> > ------_=_NextPart_001_01C0BB5B.B4B51C00
>> > Content-Type: text/html;
>> >       charset="iso-8859-1"
>> > Content-Transfer-Encoding: quoted-printable
>> >
>> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
>> > <HTML>
>> > <HEAD>
>> > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>> > charset=3Diso-8859-1">
>> > <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
>> > 5.5.2653.12">
>> > <TITLE>RE: [SIP] RE: SCTP as transport for SIP</TITLE>
>> > </HEAD>
>> > <BODY>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Hi Matt, </FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Hi Matt,</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">I'm not convinced that SIP needs to =
>> > use ordered delivery of messages across multiple streams. If we are not =
>> > using stream specification within SIP (and I think I agree with you now =
>> > Jonathan) then I believe SIP should be using a single unordered =
>> > reliable stream rather than any/all the streams.</FONT></P>
>> >
>> > <UL><LI><FONT SIZE=3D2 FACE=3D"Arial">This is simpler and as has been =
>> > said before, a more complicated SIP adaptation layer may cause more =
>> > complexity in transport-ignorant systems (whatever that might be =
>> > <grin>). This is also closer to the model used by the existing =
>> > SIGTRAN adaptation layers (ie, one link =3D> one =
>> > stream).</FONT></LI>
>> > <LI><FONT SIZE=3D2 FACE=3D"Arial">The process of enforcing that an =
>> > application must accept packets on all streams may force =
>> > implementations on the API and design of the SCTP stack. The stack uses =
>> > the concept of "used" and "unused" streams - what effect does using 64K =
>> > streams on an association have on memory requirements. This may not be =
>> > a relevant concern but I think SIP should try to be more conservative =
>> > in its use of SCTP.</FONT></LI>
>> > <LI><FONT SIZE=3D2 FACE=3D"Arial">The sending of  different call =
>> > legs to different streams does not help much in my opinion. A single =
>> > stream must still be able to accept packets for multiple call =
>> > legs.</FONT></LI>
>> > <LI><FONT SIZE=3D2 FACE=3D"Arial">Using arbitrary streams does not =
>> > allow the use of other streams for any future purpose. </FONT></LI>
>> > <BR>
>> > </UL>
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">I'm also not convinced that the =
>> > bundling of SIP messages is that useful - SIP messages are usually =
>> > quite large anyway. However, an interesting application for SCTP with =
>> > SIP might be on low bandwidth point to point connections. The SIP =
>> > application controls the association and so it is not too unreasonable =
>> > that the SIP application may negotiate the use of other streams in the =
>> > same association for media use. Now the fragmentation properties of =
>> > SCTP could reduce any delay/jitter in the media carried on the same =
>> > SCTP association. This is not possible if SIP and media are carried in =
>> > separate streams. [This is probably not a main-stream application and =
>> > maybe not even useful/desirable but I don't think it should be =
>> > impossible.]</FONT></P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Jonathan, I see you think that SCTP is =
>> > not worth the trouble for SIP. I think that SCTP becomes more =
>> > attractive to SIP when the media also uses SCTP such that SCTP becomes =
>> > the only transport protocol needed (although not necessarily on the =
>> > same association). SCTP has the interesting property that it makes the =
>> > normally connectionless unreliable UDP media become connection-oriented =
>> > unreliable U-SCTP media. I can even foresee that in the future, SCTP =
>> > associations could be linked to hardware routing and resource =
>> > reservation (eg using SCTP for MPLS instead of RSVP). [I don't know of =
>> > any work in this field although the stream-based flow-limiting =
>> > extension is useful - sounds like a good thesis/paper to me.] Anyway, =
>> > the only piece missing is an SDP profile for SCTP (which I'm still in =
>> > the process of proposing something - input welcome).</FONT></P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Comments please.</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">-- My opinions should not be taken as =
>> > necessarily representing those of Nuera Communications, Inc. --</FONT>
>> > </P>
>> >
>> > <P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
>> > Message-----</FONT></A>
>> > <BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:   Matt Holdrege =
>> > [<A =
>> > HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT></B>=
>> >
>> > <BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:  </FONT></B> <FONT =
>> > SIZE=3D2 FACE=3D"Arial">Wednesday, March 28, 2001 3:39 AM</FONT>
>> > <BR><B><FONT SIZE=3D2 =
>> > FACE=3D"Arial">To:    </FONT></B> <FONT SIZE=3D2 =
>> > FACE=3D"Arial">[email-masked]</FONT>
>> > <BR><B><FONT SIZE=3D2 =
>> > FACE=3D"Arial">Subject:       </FONT>=
>> > </B> <FONT SIZE=3D2 FACE=3D"Arial">Re: [SIP] RE: SCTP as transport for =
>> > SIP</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">(from the SCTP AS)</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">For SIP, considering the use of a =
>> > reliable transport protocol (i.e. not </FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">UDP) the features of SCTP would =
>> > be:</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">- acknowledged error-free =
>> > non-duplicated transfer of user data,</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">- data fragmentation to conform to =
>> > discovered path MTU size,</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">- sequenced delivery of user messages =
>> > within multiple streams,</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">   with an option for =
>> > order-of-arrival delivery of individual user</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">   messages,</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">- optional bundling of multiple user =
>> > messages into a single SCTP packet,</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">- network-level fault tolerance =
>> > through supporting of multi-homing at </FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">either or both ends of an =
>> > association.</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Applications that require framing of =
>> > reliable data streams can get that</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">feature from SCTP.</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Applications which transfer =
>> > independent message sequences that are </FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">unrelated (sometimes called =
>> > transactions) can benefit from the partial </FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">ordering provided by SCTP =
>> > streams.</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Applications that wish to transfer =
>> > messages that hold no particular</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">sequence or relationship to one =
>> > another can benefit from the unordered</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">service provided by SCTP.</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Finally for those applications seeking =
>> > network layer redundancy with</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">multiple Network Interface cards can =
>> > use SCTP's multi-homing feature.</FONT>
>> > </P>
>> >
>> > <P><FONT SIZE=3D2 FACE=3D"Arial">Is there any misunderstanding or =
>> > disagreement with the above?</FONT>
>> > </P>
>> > <BR>
>> >
>> > <P><FONT SIZE=3D2 =
>> > FACE=3D"Arial">_______________________________________________</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">This list is for continuing =
>> > development of the SIP protocol.</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">The sip-implementor's list is the =
>> > place to discuss implementation,</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">and to receive advice on =
>> > understanding existing sip.</FONT>
>> > <BR><FONT SIZE=3D2 FACE=3D"Arial">To subscribe to it, send mail to =
>> > </FONT>
>> > <BR><FONT SIZE=3D2 =
>> > FACE=3D"Arial">[email-masked] with =
>> > "subscribe" in the body.</FONT>
>> > </P>
>> >
>> > </BODY>
>> > </HTML>
>> > ------_=_NextPart_001_01C0BB5B.B4B51C00--
>> >
>> > _______________________________________________
>> > tsvwg mailing list
>> > [email-masked]
>> > http://www1.ietf.org/mailman/listinfo/tsvwg
>> 
>> _______________________________________________
>> 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.
>
>-- 
>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]
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/tsvwg
>

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.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: "Lyndon Ong" <[email-masked]>
Date: Tue, 03 Apr 2001 13:41:49 -0700

BTW, I'm suggesting we might incorporate some of the points made in Gonzalo's paper, e.g., use of unordered service for applications that do their own message correlation, ability to do transport level fragmentation, etc., not the overall conclusion of whether to use SCTP for SIP, which is out of scope.

Cheers,

Lyndon 
--

---

From: Coene Lode <[email-masked]>
Date: Wed, 4 Apr 2001 10:59:22 +0200

Well, I agree with the points made in the paper(certainly the conclusion
that SCTP is best used between SIP entities that handle large amounts of
traffics(example proxy-gateway)) The case is indeed wmuch weaker for low
amounts of traffic between user agen and proxy). They have made the point.
Enough said.

> From: Lyndon Ong [mailto:[email-masked]]
> Sent: dinsdag 3 april 2001 22:42
> To: sigtran
> Cc: Fairlie-Cuninghame, Robert; 'Matt Holdrege';
> [email-masked]; [email-masked]; 'Jonathan Rosenberg';
> [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP
> 
> 
> BTW, I'm suggesting we might incorporate some of the points 
> made in Gonzalo's paper, e.g., use of unordered service for 
> applications that do their own message correlation, ability 
> to do transport level fragmentation, etc., not the overall 
> conclusion of whether to use SCTP for SIP, which is out of scope.

This suggestion in gladly taken into account (as Scot mentioned something
about seeing something about UDP also in the draft). I'll try to hammer out
something along those lines later this day or tomorrow. 
In the mean time, Thank you to Gonzalo and his coauthors. 

> Lyndon 

BTW Lyndon, that Loede guy showed up once again in the mail header.  :-)

yours sincerly,
Lode

Siemens Atea ICN D CS D
Software Development 
Atealaan 34     
B-2200    Herentals    Belgium         
Tel +32-14-25-2081   /  Fax +32-14-25-3212
E-mail:   [email-masked]

---

From: "RANJITH MUKUNDAN" <[email-masked]>
Date: Wed, 4 Apr 2001 18:27:21 -0000

..but isn't  there an mechanism/option to toggle between 
transport(sctp/udp...) on a per service basis OR based on the traffic 
characteristics available at the servers (OAM parms) for new sessions?

thanks,
ranjith..

-----Original Message-----
From:	Coene Lode [SMTP:[email-masked]]
Sent:	Wednesday, April 04, 2001 2:29 PM
To:	[email-masked]'; sigtran
Cc:	Fairlie-Cuninghame, Robert; 'Matt Holdrege'; [email-masked]; 
[email-masked]; 'Jonathan Rosenberg'; 
[email-masked]; Coene Lode
Subject:	RE: [Tsvwg] RE: [SIP] RE: SCTP as transport for SIP

yours sincerly,
Lode

Siemens Atea ICN D CS D
Software Development
Atealaan 34
B-2200    Herentals    Belgium

---

From: Coene Lode <[email-masked]>
Date: Wed, 4 Apr 2001 18:30:49 +0200

Header is getting a bit overloaded :-)
See my comment below.

yours sincerly,
Lode

Siemens Atea ICN D CS D
Software Development 
Atealaan 34     
B-2200    Herentals    Belgium         

> From: RANJITH MUKUNDAN [mailto:[email-masked]]
> Sent: woensdag 4 april 2001 20:27
> To: 'Coene Lode'; [email-masked]'; sigtran
> Cc: Fairlie-Cuninghame Robert; 'Matt Holdrege'; 
> [email-masked];
> [email-masked]

That looks like a implementation issue to me. In any case, there is little
use in having it in one server if other servers do not support that
transport protcol. Thus toggling it off or on won't make a difference.

yours sincerly
Lode