[e2e] TCP sequence number reset

[Kacheong Poon]

On 03/25/11 11:16 PM, Joe Touch wrote:

> TCP never ever communicates anything to the user based on the seqno.


As I mentioned in my original email, "assuming an app can
get the sequence number."  If a stack wants to export TCP
sequence number, it is very simple to do.  And to create a
concept of SSN as in SCTP, it just maps IRS (initial receive
sequence number) to 0 and you get the equivalence of SSN.
So with this simple mapping, why do you still think that a
TCP connection is not the same as an SCTP association with
one single stream?


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


This number, Stream Reset Request Sequence Number, has nothing
to do with SCTP SSN and TSN.  It is just a number to identify
a request.  It is just part of the protocol mechanism introduced
for TSN/SSN resetting.  And it does not need to be initialized
to initial TSN number.  My question is not about the mechanism.
My question is about how people think about the idea of TCP
sequence number reset (which is just a simple mapping of what
the draft proposed).


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


??  When asked about the "stream reuse usage", the authors
mentioned one example in the WG mailing list, which is sending
multiple files in one stream.  So stream reset signifies an
EOF of one file.  Is this your idea of "stream reuse?"


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


Please read the draft and my original question carefully before
jumping to conclusion.


-- 

					K. Poon.
					ka-cheong.poon at oracle.com