[e2e] TCP sequence number reset

[Joe Touch]

Hi, Kacheong,

On 3/29/2011 10:07 PM, Kacheong Poon wrote:
> I guess I should have first stated why I raised the question
> in e2e. I think the proposed draft about SCTP TSN/SSN mechanism
> is unjustified and should not be moved forward as a PS.
...
> Hence I posted the question to e2e as I think there are more
> folks with transport protocol design experience whom can
> comment more. And since TCP is more widely known, I mapped
> the proposed mechanism to a TCP mechanism.

My concern is that moving this mechanism over to TCP is meaningless. If 
you really want to focus on the SCTP mechanism, perhaps it would be more 
useful to start a thread on that directly; there are many on this list 
familiar with SCTP.

Later you say:
 > IMHO,
 > the mapping is not key to my question. I want to see if folks
 > on this list see a reason why resetting TCP sequence number
 > can be useful. There is one comment on the TSVWG mailing list
 > that TSN/SSN reset is useful to "unknot network situation." I
 > don't know what network situation that is and what "unknot" really
 > means. But maybe folks in e2e know better than I.

I don't know specifically what the SCTP reset could be useful for, but 
it doesn't make sense to talk about it in the context of TCP at all, so 
TCP is not a good example for the discussion you seek.

---

Since this thread focuses on the TCP version, the remainder of my 
comments focus on that (as have most of my prior ones):

> On 03/28/11 07:36 PM, Joe Touch wrote:
>
>> > 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).
>
> Using the BSD socket interface to do the mapping, it is simple
> to send up an ancillary data with each recvmsg() call which
> contains the TCP sequence number of the first received byte.
> One can argue if that is useful, but is easily done.

A given received byte has an offset from the beginning of the stream, 
which is trivially counted (without augmenting the current API).

A given received byte has no other related sequence number. I think you 
*want* a byte to be tagged with the sequence number of the segment in 
which it was received. However, that is ambiguous. Consider the 
following (I made the numbers smaller to make the example easier to type):

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?

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

To make matters worse, ABCDEF could have arrived *and* ABC DEF too.

So the receiver could think that D has the following seqnos:
	0
	4
	0 *and* 4

So which is it?

Presenting a seqno to the user implies that TCP segments are meaningful 
to the user. They're simply not. TCP is allowed to segment as desired - 
regardless of how data is presented, and can re-segment as needed during 
retransmission.

To say that the seqno reset means anything is to say the seqno means 
something, and it simply doesn't. It's an offset for data reassembly, 
that's all.

You really want a flag in the middle of the stream. The closest thing to 
this is the URG pointer, whose use has been deprecated, and had similar 
problems with correlating an out-of-band E2E signal with in-band data.

TCP simply doesn't have a way to do that. SCTP does, which is why the 
reset mechanism is meaningful there (albeit perhaps not useful for any 
particular purpose), but isn't here.

...
>> > 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.
>
> A sequence number outside the TCP receive window is not
> acceptable. It is defined in RFC 793.

Sequence numbers of any value can always arrive; numbers outside the 
window are packets that are too old to arrive correctly, so that's why 
they're dropped. All sequence numbers could appear on the wire at any 
time - if you start using "unexpected" numbers for other purposes, you 
defeat an explicit protection mechanism in TCP.

Joe