[e2e] TCP sequence number reset

[Kacheong Poon]

On 03/30/11 03:47 PM, Joe Touch wrote:

>> It is still 4. Regardless of the TCP level segmentation, each
>> bytes has its own TCP sequence number.
>
> The receiver already knows that; it can just count as it reads bytes.
> That's the point I made very early on...


Right, the receiver just needs to know about the TCP IRS,
it then knows about the other sequence number.  It is the
same as in SCTP.  A receiver knows the TSN of all messages
if it knows the initial TSN.  An app does not really need
to care about TSN.  The same thing can be applied to SSN
since SSN serves the same purpose as TSN, just at the stream
level.


> So your simple map is already possible.


That's what I've been saying.


> What you *really* want is:
>
> a boundary in the TCP stream
>
> and everything before that boundary is part of one thing (the first
> stream) and everything after that boundary is part of the second.


The mapping from SCTP to TCP is that there is only 1 stream.
So there is no such stream boundary needed.


> This has *nothing* to do with resetting the seqno. The seqno is
> irrelevant to establishing this boundary.


No, it is not relevant.  But I think this is also not relevant
to TSN/SSN reset.


> Many have tried to find a way to put such a boundary in TCP, and it
> basically requires adding another state to the state diagram, and
> dealing with entering and leaving that state. The work required is the
> same as a 3WHS, which is why this has been abandoned.


No, I am not trying to propose such a mechanism.  My question
is before we even try to design such a mechanism, is the
problem worthwhile to be solved.  This is the question to the
TSN/SSN reset mechanism.


-- 

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