[e2e] TCP sequence number reset

[Kacheong Poon]

On 03/30/11 02:25 PM, Joe Touch wrote:

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


Right, that probably is better.  But I still think that the
mapping is OK.  See below.


> 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):


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.


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


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


This is fine.  TCP discards duplicated segment.  There is no
duplicated sequence number sent up to the app.


> So the receiver could think that D has the following seqnos:
> 0
> 4
> 0 *and* 4
>
> So which is it?


Your idea of mapping is not the same as my idea of simple
mapping.  Simple mapping should be simple :-)  You are
making it more complicated than necessary.  I am not saying
that letting an app know about TCP sequence number is
useful.  In fact, I don't believe an app needs to know about
SCTP TSN or SSN either.


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


This is not necessary.  The app does not need to care about
TCP segmentation.


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


The mapping to TCP is that an app can tell the TCP stack its
use of sequence number should be reset (changed).  Suppose
current tcp_snxt is S.  When TCP sends the next segment, the
sequence number in that segment's TCP header will be S.  But
if a reset has happend, that sequence number will be something
else.  In SCTP's case, the TSN has the same meaning as TCP
sequence number.  Just consider this simple case, every SCTP
message is 1 byte long.  Then SCTP TSN and TCP sequence
number means exactly the same thing.


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


As I mentioned, how to do the reset in TCP is orthogonal to
my question.  The question is do folks think that an app should
care about TCP sequence number at all.  And I think the
reasons map to SCTP as well.


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


Why do you think that reset is useful?  SCTP currently does not
have a way to reset TSN/SSN, just like TCP.  How to design
such a mechanism is the next question to ask when we are sure
that resetting is useful at the transport level.


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


This is how the proposed SCTP mechanism works.  It is not my
idea.


-- 

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