[e2e] TCP sequence number reset

[Joe Touch]

On 3/24/2011 9:48 AM, Kacheong Poon wrote:
> On 03/24/11 09:38 PM, Eric Brown wrote:
>> Whether the idea proposed in the draft you are referencing truly
>> has an analogue in TCP may or may not be true. You haven't included
>> a reference. That being said, I'd consider this to be a bad thing with
>> respect to TCP. First and foremost TCP is a distributed state machine,
>> that is how it is able to achieve reliable and ordered delivery of
>> data in even the most hostile of conditions. A necessary component of
>> a distributed state machine is a virtual clock. Sequence numbers are
>> TCP's virtual clock ensuring that the FSM progresses in order. In the
>> very least it would be difficult to understand all the consequences of
>> overloading more semantics on the progression of the sequence space.
>
>
> The draft is draft-ietf-tsvwg-sctp-strrst-09.txt and I think
> the analogy to TCP is accurate.

SCTP includes the idea of individual streams, and the value of the 
sequence number has a meaning within a stream. In the above draft, it's 
used to allow a stream to be reused within an E2E association.

In TCP, the sequence number only has meaning to the reliability of the 
stream; there's only one E2E association. Resetting the number has no 
semantic value within the stream. There is no way to establish that TCP 
has no outstanding data, and so *can* reset the stream, other than via a 
FIN (which would close the connection).

Applications in TCP never see or know the sequence number. All they know 
is the byte stream they are presented with.

Finally, this has nothing to do with virtual clock; the FSM of TCP has 
independent components - one having to do with the sequence number, and 
another having to do with the state machine. They interact only in a 
very few cases. The virtual clock is how TCP ends up pacing the outputs, 
in a very loose sense (e.g., ACK compression interferes with it, as do 
cumulative ACKs and reordering, etc.)

Overall, I don't see *why* anyone would want to reset TCP's seqnum. TCP 
options are sent unreliably and out of order, and generally aren't 
bidirectionally stateful EXCEPT during the SYN handshake. Just doing the 
reset would be hard enough, and it would probably require just as much 
effort (if not more) and delay as setting up a new connection - i.e., 
lots of pain with little benefit.

Joe