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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 14:37:02 -0500

-----Original Message-----
>From: Tom-PT Taylor [mailto:[email-masked]]
>Sent: Thursday, March 15, 2001 10:33 AM
>To: 'Jonathan Rosenberg'; 'Fairlie-Cuninghame, Robert';
[email-masked]'
>Cc: [email-masked]'
>Subject: RE: [SIP] RE: SCTP as transport for SIP
>
>
>I have read the later notes in this thread, but this will do for a reply.
The first point 
>I would like to make is that Robert's points are very much related to
implementation.  If, 
>for instance, your SCTP association has been set up solely for transport of
SIP, there is 
>no issue about which streams to listen and send on -- they are all used.
If you are 
>setting up an SCTP association with the intent of devoting certain streams
to one protocol, 
>certain streams to another, and you want to do it on a dynamic rather than
configured 
>basis, then either the receiving end has to classify the streams according
to initial 
>received content or the two ends need a way to negotiate stream usage.
This falls outside 
>of the current SIGTRAN model, which tends to have an adaptation layer which
sets up 
>associations for its own use.  What is needed for Robert's case is a
generic adaptation 
>layer which has no user-protocol-specific services but does handle the
required 
>housekeeping.

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.

-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: Gonzalo Camarillo <[email-masked]>
Date: Sun, 25 Mar 2001 08:33:50 +0300

As I said in my previous mail, SIP should use the unordered SCTP
service. Therefore, sending SIP messages with different stream ids or
with the same does not make a difference.

When M3UA is used ISUP messages are sent to different streams typically
based on the CIC. However, SIP, as opposed to ISUP, does not assume a
transport that delivers messages in order. Therefore, sending SIP
messages using different stream ids does not improve the performance.

The only issue is the stream id to use for SIP messages. It does not
really matter to use ANY or to use always the stream id zero. In this
thread has been claimed that using all the time stream id zero would
allow future extensions such as out of band communication between
proxies... could somebody elaborate on that? Which kind of extensions do
folks have in mind?

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]

---

From: Michael Thomas <[email-masked]>
Date: Sun, 25 Mar 2001 06:51:32 -0800 (PST)

While I suspect that head of line blocking might
be a worthwhile thing to avoid with SIP -- which
is what I'm guessing that you're getting at here
-- do we actually need to define a MUST profile
for SIP/SCTP? The thing I'm curious of is whether
we want to allow for bump-in-the-stack like
library shims for UDP based implementations which
might not have a clue as to what the application
is and would thus need to be somewhat
conservative.

		Mike

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 27 Mar 2001 16:55:03 +0300

Brian,

I have bundled together your three mails. Comments inline.

"Brian F. G. Bidulock" wrote:
> 
> Gonzalo,
> 
> ISUP does *not* assume a transport that delivers messages in order.
> 

Yes, you are right. Actually MTP one out of a lot of times delivers
messages out of order. Anyway, this is not important for the SIP
discussion.

>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?

Actially we can still make use of urgent data. When you have an SCTP
ordered stream and you mark a chunk as unordered it does not mean that
it will have a high priority than ordered chunks. It just means that it
will be delivered to the application as soon as it arrives to the
receiver. When all the chunks of a stream are marked as unordered, they
are also deliver immediately to the application.

Therefore, when you have an urgent chunk to send, you will send it as
"unrodered", but it will make no difference that the rest of the packets
are ordered or unordered.

>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.

Well, this is out of the question. Even if you have IP fragmentation you
will have the IP fragments delivered in order to the transport layer.
What we are talking about is unordered chunks. Not unordered fragments
of chunks (this would not make any sense in a message-oriented protocol
such as SCTP). 

Regards,

Gonzalo

> Gonzalo Camarillo wrote:                    (Sun, 25 Mar 2001 08:33:50)
> >
> 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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 27 Mar 2001 17:34:55 +0300

> Yes, it will make a difference: your urgent chunk will be blocked by
> non-urgent chunks in the receiver's queue because they are all
> unordered.  In the other case, the urgent chunk will be delivered ahead
> of ordered chunks without being blocked in the receiver's queue.

No. Everything depends on how you build your application queue. 

What you are saying is can be only implemented if from the SIP
application I can check the SCTP "unordered" flag when a SCTP chunk is
received. This way, when I receive a new SCTP chunk, I check if the
"unordered" flag is set and I mark it as urgent in my application queue.

However, SIP applications will most likely use an SCTP interface that
does not allow to read this flag. And even it they could read the flag,
the pain of implementing such a priority queue in the application is not
worthwhile.

> No, I am talking about RFC 2960 Section 6.9 fragmentation.  When DATA
> chunks fragment in SCTP (to avoid IP fragmentation), the fragments
> must be delivered in order (because they have no fragment number) and
> the reassembled chunks must be delivered in order (because they have
> no stream sequence numbers).  Therefore, the receiver must not permit
> TSN gaps and must completely receive and reassemble chunks before
> delivery, resulting in strict ordered delivery regardless of the
> unordered attribute.

What you are saying is obvious. If my SCTP stack receives a chunk with
flags indicating that it is a fragment of a message, the stack will not
deliver the chunk until it has received all the fragments of the message
(it will know it because flags indicate which is the first and the last
fragment of the message). Otherwise, SCTP fragmentation would not work.

This has nothing to do with what we are talking about. We are talking
about unordered messages.

Regards,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 27 Mar 2001 20:45:55 +0300

Brian,

> Socket interface permits normal MSG_OOB flags.  Not too tough to have
> one thread recvmsg with MSG_OOB set, the other not.
> 

I still think that it is not worthwhile implementing it. When there is a
big gain, sometimes it is alright adding complexity. However, this is
not the case. Let's keep it simple.

Take into consideration that, regarding transport, your proposal does
not improve anything. The packets are delivered equaly fast to the
receiver in both sitiation (unordered message within an ordered stream
vs. unordered stream). What you are asking for is simply a flag in the
message that says "This message is URGENT". Then, you want to implement
your local queues according to this flag.

I really doubt that we want to add such a flag in the protocol.

> If fragmented, your unordered messages will be delivered ordered.

No. If fragmentation occurs, the chunks (several) that made up my
message (one) will be reassembled at the destination. For reassembly,
the chunks have to be ordered. However, this is different than ordered
delivery of messages.

Regards,

Gonzalo

---

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

Gonzalo,

---

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

Gonzalo,

Please see comments below:

Gonzalo Camarillo wrote:                     (Tue, 27 Mar 2001 16:55:03)
> messages out of order. Anyway, this is not important for the SIP

Then why mention it?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Mar 2001 12:41:43 -0600

Gonzalo,

I suggest you reread the RFC.

Gonzalo Camarillo wrote:                   (Tue, 27 Mar 2001 20:45:55)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Mar 2001 08:49:23 -0600

Gonzalo,

Gonzalo Camarillo wrote:                      (Tue, 27 Mar 2001 17:34:55)