[e2e] TCP sequence number reset

[Joe Touch]

Hi, Kacheong,

On 3/30/2011 12:33 AM, Kacheong Poon wrote:
...
> Each bytes sent in a TCP connection has a TCP sequence number
> attached to it. In the example case below,
>
>
>> X thinks the PMTU is 6
>> X sends
>> ABCDEF seqno 0
>> X receives an ICMP 'too big', saying 3 bytes are OK
>> X times out, and so sends:
>> ABC seqno 0
>> DEF seqno 4
>>
>> Now let's look at the receive side:
>>
>> Y reads ABCDEF
>>
>> What is the seqno of D?
>
>
> 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...

>> Well, if the first ABCDEF went through, then it's 0
>> If it was lost, and then the other two packets arrive out of order,
>> then the entire ABCDEF is presented to the user when DEF shows up, at
>> which point ABC all have seqno 0 and DEF all have seqno 4
>
>
> The simple mapping I suggested was to send up the same TCP level
> sequence number to the app. So regardless of the order a segment
> arrives, the sequence number won't change.

AOK - you clearly don't need to even send that. It's trivial to 
determine now without augmenting the API:

	tot_offset = 0

	while (count = read(buf)) {
		offset of buf[i] is "tot_offset + i"

	just before looping:
	tot_offset += count;
	}


So your simple map is already possible.

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.

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

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.

Joe