[e2e] TCP sequence number reset

[Joe Touch]

Let's start with the punchline, before we revisit details:

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

This really then comes back to one of two points. Either:

1) you have a real problem you want solved
	which, AFAICT, you are claiming has not been shown
	for SCTP, and you are not proposing

2) you have a solution which has some useful properties which we could 
then consider as possibly useful for something
	AFAICT, the solution in TCP is either not feasible,
	or costs as much as a new connection (and with less
	complexity), at which point this is not a good
	motivator

So we're stuck with either hacking on the solution until we think it 
works in a way that provides a benefit worth the cost, OR finding a 
reason to develop a solution.

Since neither seems to be the case, the rest of this discussion seems to 
be moot.

Some points below *if* we want to continue to discuss the TCP version, 
but if we're not focusing on a TCP version, just skip them.

Joe

On 3/30/2011 1:15 AM, Kacheong Poon wrote:
> 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.

No; you've been saying you need to augment the API. I've claimed (and 
now shown) that the required info is already available.

However, you don't really need this at all - you really need to know 
'before' and 'after' some boundary, as per below. But let's please not 
focus on the mechanism if it's not important (as per above)

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

OK, now you lost me.

The ONLY reason to reset the TCP sequence number is to have two 
sequences - one before the reset, one after. I.e., two streams. We agree 
that's not what TCP does, but that's what you want.

My point is that this is not possible in TCP. But let's please not focus 
on the mechanism if it's not important (as per above).