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

From: "La Monte H.P. Yarroll" <[email-masked]>
Date: Wed, 20 Jun 2001 15:35:40 -0500

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:

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?

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 20 Jun 2001 16:58:43 -0500

La Monte,

See my comments below...

> 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

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

---

From: Chip Sharp <[email-masked]>
Date: Fri, 22 Jun 2001 12:36:51 -0400

A MUST requirement on the transmitter doesn't automatically imply a MUST 
requirement on the receiver.

There is no requirement in the spec for the receiver to report an ordering 
violation.

For ECN, what would be the implication of reporting a higher TSN in the ECNE?

Chip

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Jun 2001 12:42:54 -0500

The only penalty I can think of is that the receiver
may think that two seperate packets marked may
be seperate congestion events (rather doubtful but
it could happen). If so, the sender (who did not
order the chunks) is penalized... i.e. it ends
up having to reduce its cwnd twice...

R

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

---

From: Jon Grimm <[email-masked]>
Date: Fri, 22 Jun 2001 13:50:17 -0500

This seems true for the case where the mis-reporting of the ECNE
LowestTSN by caused by out-of-order TSNs in a packet.  I believe La

> the packet (better yet would be the LAST TSN).  How immutable is this?

If the LAST TSN where chosen for a sender that actually ordered its TSNs
per spec., it would seem that the sender could then be artificially
penalized.   

Regards,
Jon Grimm

---

From: "La Monte H.P. Yarroll" <[email-masked]>
Date: Fri, 22 Jun 2001 17:27:08 -0500 (CDT)

I could imagine a really poor implementation being unable to identify
the transport associated with the higher TSN and thus failing to apply 
the congestion control changes to the right transport.

If I'd noticed this 4 months ago, I would have suggested that we drop
the TSN ordering requirement AND allow the ECNE to report ANY TSN from
the affected packet.

Neither of these is severe changes, but we are pretty late in the game 
for this sort of thing.  For our implementation these two changes
would eliminate 20 lines of code and about 8 bytes of storage per
chunk...  Not a big deal--just a little crufty inelegance.

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 09:03:37 -0500

Jon:

This is my whole point.. I don't think you understood who
I meant by recevier :-)

The guy that does NOT order his TSN's will suffer the
penalty... so whats the problem with this... You DON'T
follow the spec and you get penalized... You DO follow
the spec and thinks work properly..

I think this is a GOOD thing :>

R

---

From: Randall Stewart <[email-masked]>
Date: Mon, 25 Jun 2001 09:51:24 -0500

> the congestion control changes to the right transport.

Huh? I think you are talking about a BUGGY implementation NOT a
really poor one. After all part of implementing SCTP is dealing
with the multi-homing. From what I read you are saying above you could
just as easily claim the same terms for packet loss as well.. what is to
stop a "really poor implementation" from claiming the congestion
signal (a loss event) is unable to identify the transport associated
with the lost TSN?

Same issue...

Sorry La Monte.. I can't buy this argument.. 

R

---

From: Jon Grimm <[email-masked]>
Date: Mon, 25 Jun 2001 10:57:47 -0500

Randy, 
	Hmmmm....   I was not actually discussing the scenario where someone
misorders their TSNs.  I agree with your conclusion for that scenario.  
Instead I was trying to work through what would happen if the sender was
ordering their TSNs, but the receiver was instead sending the Highest
(last) TSN in the packet with the ECNE.   
	
	Maybe this second scenario is a non-issue.   The sender (receiving the
ECNE chunk) will (likely) still be able to find the correct congested
path.  Additionally, in your Ref. implementation, you seem to save away
the last assigned TSN (lastCWR_TSN) at the time process the ECNE
request.  Upon receipt of the next ECNE chunk, you compare this
saved-away value with the Lowest_TSN field in the new ECNE as a general
indicator of a "new" congestion event.   This would seem to remain safe
from a receiver not sending the "lowest" TSN in the ECNE.  

	I was trying to extend your arguments to this second scenario that the
sender may end up getting penalized for the receiver's non-compliance to
"lowest" TSN in the ECNE.   

	Must the ECNE contain the Lowest TSN?  The worst that I could see
happening is that some implementations (though not likely) may see this
as a new congestion event.          
  
	Does "lowest" TSN matter in the ECNE or could it be any TSN?
 
Regards,
Jon Grimm