[e2e] TCP sequence number reset
touch at isi.edu
Fri Mar 25 08:16:33 PDT 2011
On 3/24/2011 11:14 PM, Kacheong Poon wrote:
> On 03/25/11 01:15 PM, Joe Touch wrote:
>> The SCTP TSN is similar to TCP's sequence number, but due to the
>> relationship to the SSNs they're not directly related. Resetting the TSN
>> appears to be useful only in relation to resetting all the SSNs at once,
>> since they are based on the TSN. The document lacks any direct rationale
>> for TSN reset other than this, which is implied (this should be
>> explicitly addressed, IMO).
>> There's no notion of separate streams in TCP, so there's no purpose in
>> resetting TCP's sequence number, thus the analogy doesn't hold.
> What is your reason that a TCP connection cannot be seen as the same
> as an SCTP association with 1 single stream?
TCP never ever communicates anything to the user based on the seqno.
SCTP derives SSNs from the TSN (from the draft):
Stream Reset Request Sequence Number: 4 bytes (unsigned integer)
This field is used to identify the request. It is a monotonically
increasing number that is initialized to the same value as the
Initial TSN number. It is increased by 1 whenever sending a new
Stream Reset Request parameter.
(note that this is a significant change from RFC 2960:
1.3.4 Acknowledgement and Congestion Avoidance
SCTP assigns a Transmission Sequence Number (TSN) to each user data
fragment or unfragmented message. The TSN is independent of any
stream sequence number assigned at the stream level.
and the SSN has specific user-level semantics (RFC 2960):
The stream sequence number in all the streams shall start from 0 when
the association is established.
Thus resetting the SSN is required to reuse a stream.
> And what is your
> reason that "reusing a stream" requires "resetting a stream"?
See above, from RFC 2960.
In TCP, by comparison, the seqno is never meaningful to the user;
resetting it has no purpose.
More information about the end2end-interest