Subject: Re: [Tsvwg] A question of Un-Ordered SCTP

From: Kacheong Poon <[email-masked]>
Date: Mon, 17 Feb 2003 03:27:30 -0600 (CST)

Included message from Caitlin Bestler <[email-masked]>:

>----
>So, trying to work with SCTP on SCTP's terms, you have three
>possible strategies:
>
>-- Include a SSN-equivalent in the Data Chunk.
>
>-- Allow out-of-order placement of ordered Data chunks.
>
>-- Make SCTP's SSN meaningful for unordered delivery.
>
>The pure ULP solution obviously has the least impact on
>the SCTP layer. But it smacks of having the ULP duplicate
>functionality that rightfully belongs at the transport
>layer. I believe the quick consenseus is that sequenced
>unordered delivery is a natural concept that has value
>beyond any single ULP.

I don't think that the above functionality "rightfully
belongs to the transport layer (SCTP in this case)."  To
me, the unordered delivery mechanism as specified in RFC
2960 simply means that such data chunks can be delivered
in whatever order the receiver wants.  This also
automatically means that the sender can send such chunks
in whatever order it wants if it deems necessary.  For
example, an implementation can choose to place a smaller
unordered data chunk ahead in the send queue before a bigger
unordered data chunk.  Assuming that the SSN is assigned
when data chunk is sent, to make the suggested change
to RFC 2960 to an implementation may mean more than what
has been discussed.  And it is really a protocol change,
not just implementation's choice of how to generate
"arbitrary numbers" to be put in the SSN field of unordered
chunk as it actually places extra restrictions on how an
implementation handled such chunks as described above.

The SSN in SCTP is designed to be used for order of
delivery by SCTP, that's why it is ignored for unordered
delivery.  If an ULP wants to have ordered delivery, don't use
this feature of SCTP.  If an ULP wants unordered delivery, but
it still wants to know the sender's sending order, just place
its own sequence number.  Overloading the SSN in SCTP, even
if it is assigned by SCTP, not by ULP, is really a bad design
choice.  

Anyway, just my $0.02.  BTW, I also cc the SCTP
implementors' list.  I believe people there should
be aware of such things.  I don't know why that list
was removed from the cc list...

>----

							K. Poon.
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Mon, 17 Feb 2003 10:19:07 -0600

> implementation handled such chunks as described above.
You make an excellent point.. for this very set of
reasons one must not depend on being able to do
priority of unordered data chunks as well. A implementation
(as Brian mentioned his does) MAY prioritize un-ordered
but it also MAY NOT...

> if it is assigned by SCTP, not by ULP, is really a bad design

This brings up another point that I had not contemplated... if
an implementation is assigning SSN's (as well as TSN's) at the
last minute, the SSN assigned does NOT necessarily align
with presentation order to SCTP. So by this reasoning it
is really better if the ULP puts a SSN in its data as to
how it presented the data to the SCTP stack... thus assuring
the symantics it wants. I think you have convinced me
it is better to let the ULP deal with it..

Oh, I do still think the CAPABILITIES indication may be
a good thing though...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 17 Feb 2003 11:28:57 -0600

On 2/17/03, Randall Stewart wrote:

>
>This brings up another point that I had not
>contemplated... if an implementation is assigning SSN's
>(as well as TSN's) at the last minute, the SSN assigned
>does NOT necessarily align with presentation order to
>SCTP. So by this reasoning it is really better if the ULP
>puts a SSN in its data as to how it presented the data to
>the SCTP stack... thus assuring the symantics it wants. I
>think you have convinced me it is better to let the ULP
>deal with it..
>

The essential characteristic of ULPs that would have used
the sequenced unordered capability is that the order of
presentation from the ULP has signifigance, but that data
delivery should not be delayed at the receiving end to
restore that original order, rather the information should
be provided to the ULP to allow it to do so.

Generally these applications would want their presentation
order within a stream to match the actual transmit order.
For streaming media applications this is crucial, it would
be next to impossible for a sender transport re-ordering to
be beneficial to the application. RDDP can be quite tolerant
of order inversions between *some* Data Chunks (tagged ones
between the same set of untagged messages), but complex
"half-ordering" is pretty clearly ULP specific and not
something that SCTP should be expected to support.

So that leaves the same three options for comparison:

1) keep the sequence unordered capability, but clarify
that in-stream order, as presented by the sending ULP,
must be preserved by the sending SCTP layer. Any restoration
of that order, however, is left to the receiving ULP.

This contrasts with ordered delivery, where the receiving
SCTP layer restores the order.

The biggest hit here is that it is now clear that this
method will not work for RDDP over unmodified SCTP stacks.
If neither the TSN or SSN can be relied upon to reflect
the sending RDDPs ordering critical RDDP ordering rules
cannot be properly enforced.

2) ULP labeling of DDP stream ordering combined with
unordered delivery. The receiving DDP layer is solely
responsible for restoration of order.

This actually isn't that bad for RDDP. For streaming media
applications, particularly over partially reliable SCTP,
it has the negative effect of failing to constrain the
sending SCTP layer to send the data chunks in the order
presented.

3) Unordered delivery of ordered data streams. A purely
local interface option allows the receiving ULP to specify
whether it wants SCTP to hold data chunks until they can be
delivered in order, or to deliver them early and merely
indicate the order they should have been in.

This approach has some very nice features, but has very
serious performance impilcations if RDDP is implemented
on top of an unmodified SCTP receiver.

If several implementers believe that the third option is a
relatively minor fix, then I believe that it would be an
adequate solution for both RDDP and streaming media ULPs.
Otherwise the second option looks like the best approach.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 24 Feb 2003 20:14:27 -0600

I fully agree with Kacheong's assessment that adding the 2nd sequence
number to SCTP would constitute a *protocol* change. It would basically
alter the semantics of an existing SCTP parameter. If we do that, I
don't think anyone knows for sure which existing implementations would
be broken and which wouldn't. It would also create a dangerous
precedence; if we alter the protocol for the sake of this ULP, there
might be many more down the road with a similar "minor" request to
change SCTP. 

Moreover, from a coder's viewpoint, the change may be very easy to make
(a couple of lines), but to some one who has already had the old
implementation widely deployed (or worse, embedded in some widely sold
applications), the cost of upgrading/replacing the stack could be huge. 

We want to people to think SCTP is stable. Changes of this nature, if
easily allowed, would shake people's believe that SCTP is stable and
make them wonder if their investment in implementing and deploying SCTP
is going to be wasted. 

Let the ULP have the 2nd sequence number is a better idea, IMO.

-Qiaobing