[e2e] TCP sequence number reset

[Joe Touch]

Kacheong,

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

----