[e2e] TCP sequence number reset
touch at isi.edu
Mon Mar 28 04:36:56 PDT 2011
> 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.
There is *no* correlation between TCP segments and the user interface
so yes, we could modify the user interface to indicate
a sequence number, but which one? when TCP receives data,
it's buffered until ACKd; it's sent to the user after
being ACKd. There is no "sequence number" associated with
a received byte other than its offset from the start of
the stream. Consider that a given byte could be received
in multiple segments (esp. if a large segment is thought lost
due to ACK loss and ends up being retransmitted as smaller
segments, e.g., after a path MTU change).
> 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.
If you assume the initial number is 0, then you already get the
relevant info by counting bytes.
> 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?
The notion of such an ID isn't associated with a given byte in TCP; it
is associated with a message in SCTP.
>> (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?"
I would presume that's one use case. My problem with modifying TCP to
support this is that it's going to require as much, if not more,
mechanism than shutting the connection and starting a new one.
In specific, there is *no* mechanism for stateful exchange of TCP options.
if you want to reset the sequence number, at *best*
you'll need to create a way to halt current data
transmission (e.g., send an option), a way to wait
for pending operations to complete (e.g., receive
an option confirmation) and then a way to confirm
the change (send an option confirmation).
i.e., you'll recreate the SYN TWHS
>> > 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.
You have one Internet draft currently active that refers to SCTP, not
TCP. The title of your post talks about resetting TCP numbers, not SCTP
numbers. So that document isn't particularly relevant to this email
thread, except as inspiring the goal of a similar mechanism in TCP.
Your original post states as follows, so let's go through it in detail:
> Just want to get some opinion from the list members about an
> idea proposed in an IETF draft. The equivalent idea when
> applied to TCP is sequence number reset. The idea is that
> assuming an application can access TCP sequence number with
> each byte of data,
Which above I have shown is undefined.
> an app is allowed to reset the TCP sequence
> number when it wants to.
Which above I have explained is the same cost as starting a new connection.
> The sequence number is set to a number
> not acceptable (add 231) in the current connection.
There is no sequence number which is unacceptable for a connection; all
numbers are valid, it's just that some may refer to old segments and
others may refer to segments not yet acknowledged.
> Note that
> there is no clear usage proposed in that draft nor any reason
> that it is needed, just a mechanism to do it.
It would be useful to explain a goal use, otherwise it's impossible to
determine whether the mechanism is sufficient.
More information about the end2end-interest