[e2e] TCP sequence number reset

[Joe Touch]

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.

Joe