Subject: RE: [Tsvwg] Re: Must SCTP data chunks be in TSN order?

From: Jon Berger <[email-masked]>
Date: Thu, 21 Jun 2001 09:53:44 +0100

RFC2960 section  6.10:
"The transmitter MUST transmit DATA chunks within a SCTP packet in
increasing order of TSN."

Jon

-----Original Message-----
From: Qiaobing Xie [mailto:[email-masked]]
Sent: 20 June 2001 22:59
To: La Monte H.P. Yarroll
Cc: [email-masked]; [email-masked]
Subject: [Tsvwg] Re: Must SCTP data chunks be in TSN order?

La Monte,

See my comments below...

"La Monte H.P. Yarroll" wrote:
> 
> Are SCTP DATA chunks bundled in a single packet required to be in TSN
> order?  I can't find a mention of the topic in RFC 2960.  I vaguely
> recall a discussion suggesting that they ought to be in ascending TSN
> order, but that it is not required.
> 
> If they are NOT required to be in ascending TSN order, then we have
> some bothersome extra code to write for ECN:

So, you won't mind adding code to check whether TSNs are in ascending
order in *every* received packet and adding yet more code to reporting
any ordering violation?

I think the code you would need to add to enforce the new rule would be
many many times more than tracking the LOWEST TSN in your ECN
subroutine.

-Qiaobing

> 
> Appendix A:
> 
>    ECN-Echo:
> 
>    RFC 2481 details a specific bit for a receiver to send back in its
>    TCP acknowledgements to notify the sender of the Congestion
>    Experienced (CE) bit having arrived from the network.  For SCTP this
>    same indication is made by including the ECNE chunk.  This chunk
>    contains one data element, i.e. the lowest TSN associated with the IP
>    datagram marked with the CE bit, and looks as follows:
> 
> In other words, we have to find the LOWEST TSN in the whole packet.
> 
> For our implementation, we don't really care WHICH TSN we get in an
> incoming ECNE--we can identify the sending transport based on ANY TSN
> in the chunk.  What we'd LIKE to do is just report the FIRST TSN in
> the packet (better yet would be the LAST TSN).  How immutable is this?
> |
|
> |
|
> ---------------------- Mailing List commands
--------------------------------
> Send the following in the body of a message to
[email-masked]
> SUBSCRIBE TO LIST    : subscribe list-name   | LIST OF LISTS   : lists
> UNSUBSCRIBE TO LIST  : unsubscribe list-name | RETRIEVE HELP   : help
> WHO ON ON THE LIST   : who list-name         | GET DESCRIPTION : info
list-name
> |
|
> Or you can use http://majordomo.cig.mot.com
>
----------------------------------------------------------------------------
--

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

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 21 Jun 2001 18:00:35 -0500

Hmmm, a surprise to me. This must have been an addition from the final
stage during the RFC editing.

Now, is there any implementation enforcing this "MUST" on the receiver
side? Or is every receiver just processing the arrived packets with
total trust that its peer data sender always puts TSNs in order?

I'd think a "SHOULD" here is better. 

If we want to keep the "MUST", then we need to clarify what the receiver
should do if a packet showed up with a bad TSN order.

-Qiaobing 

Jon Berger wrote:
> |                                                                             |
> |                                                                             |
> ---------------------- Mailing List commands --------------------------------
> Send the following in the body of a message to [email-masked]
> WHO ON ON THE LIST   : who list-name         | GET DESCRIPTION : info list-name
> |                                                                             |
> ------------------------------------------------------------------------------

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Jun 2001 18:16:22 -0500

Qiaobing,

> should do if a packet showed up with a bad TSN order.

IMHO it doesn't make too much sense, and might even take more
work, to send them out of order).  As to what to do if they come
out of order: for interoperability sake, the implementation
"SHOULD NOT" rely on the fact that TSNs arrive in order.

I think that we are just talking about order within the SCTP
message here.  SCTP processing is such that it must handle TSNs
in different orders *between* SCTP messages.  It is not difficult
to make an implementation which can also handle them *within*
SCTP messages without additional processing effort.  If you cache
the last TSN received and expect to walk the out_of_order/gap
queue starting at the last cached point but fall back to scanning
from the beginning of the queue, out of order TSNs within an SCTP
message would just cause more fallbacks.

This does not address the original problem of middle boxes which
want to expect TSNs in increasing order within a message.  In that
case, perhaps leaving the "MUST" would be better.  Let the endpoint
take the more relaxed behavior.

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "La Monte H.P. Yarroll" <[email-masked]>
Date: Thu, 21 Jun 2001 18:15:14 -0500 (CDT)

Our implementation is fully Postelian--we can process TSN's in any
order but we (now) put them in outbound packets in TSN order.

We WILL blithely assume that the first data chunk in a packet has the
lowest TSN and report that in an ECNE.  If a (nonconformant) peer
implementation violates the assumption on TSN ordering, it is
responsible for figuring out what the TSN in the ECNE means.

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 21 Jun 2001 18:33:24 -0500

> order but we (now) put them in outbound packets in TSN order.

I would guess that most of the implementions will do it this way because
it makes a lot of sense. But this implies a "SHOULD" interpretation to
the spec.

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Jun 2001 11:15:25 -0500

Qiaobing:

The enforcment of this is VERY VERY easy, if you want to
enforce it.

Every time you look at the next TSN in a sctp packet, verify
that it is larger than the last one I just processed. If it
is not.. stop processing the rest of the sctp packet.

This will NOT kill the association, but instead it will
degrade performance of the sender.

A simple enforcment, that requires NO messages state
or otherwise..

I think this item should be left as is..

R

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

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 22 Jun 2001 12:08:30 -0500

Jon Berger wrote:
> 
> Well the receiver can do what they like (ABORT, ignore, do what they think
> the peer wanted) because the sender is not obeying the protocol.  If there
> is no reason to allow a sender to send in a bizarre order, why place
> additional cost on the receiver?
> 

I highly suspect any serious implementation will take the route of
aborting the association, unless it has no interest in achieving good
inter-operability. The reason is that, there is nothing preventing the
receiver from continuing the conversation. It is not an unrecoverable
situation. Not even close to one.

Randall Stewart wrote:
...
> degrade performance of the sender.

This is a much more constructive way of handling the ordering violation
by the sender and an elegant one as well. I wonder whether we should
capture this in the Implementor's Guide, or in a later BCP.

-Qiaobing