[e2e] TCP sequence number reset

[Kacheong Poon]

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.  That
draft was at LC in TSVWG and I'd like to gather more opinion
as there did not seem to have much discussion on the TSVWG
mailing list from a transport protocol design perspective.
And a more fundamental issue is that there is no supporting
argument for having such a mechanism in SCTP except to re-use
a stream to send multiple files.  I cannot consider that a
supporting reason.  The problem is that it seems that I am the
only person raising this question about that proposed SCTP
mechanism in the mailing list.

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.  And I deliberately
did not mention that I had strong reservation about that
draft hoping that folks want jump to conclusion and will give
opinion on whether they think it is a good or bad idea.  But
it seems that this does exactly the opposite....


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.


>  > And to create a
>  > concept of SSN as in SCTP, it just maps IRS (initial receive
>  > sequence number) to 0 and you get the equivalence of SSN.
>
> If you assume the initial number is 0, then you already get the
> relevant info by counting bytes.


Right.  That's why I said it's an easy mapping to TCP.  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.


> In specific, there is *no* mechanism for stateful exchange of TCP options.
> if you want to reset the sequence number, at *best*
> you'll need to create a way to halt current data
> transmission (e.g., send an option), a way to wait
> for pending operations to complete (e.g., receive
> an option confirmation) and then a way to confirm
> the change (send an option confirmation).
>
> i.e., you'll recreate the SYN TWHS


In fact, this is similar to the proposed SCTP mechanism.  I
don't see why we need to introduce a mechanism at the transport
layer just to support something which can easily be done at the
app layer.


> You have one Internet draft currently active that refers to SCTP, not
> TCP. The title of your post talks about resetting TCP numbers, not SCTP
> numbers. So that document isn't particularly relevant to this email
> thread, except as inspiring the goal of a similar mechanism in TCP.


I guess I should have stated my reason in raising the question...


> Your original post states as follows, so let's go through it in detail:
>
>> Just want to get some opinion from the list members about an
>> idea proposed in an IETF draft. The equivalent idea when
>> applied to TCP is sequence number reset. The idea is that
>> assuming an application can access TCP sequence number with
>> each byte of data,
>
> Which above I have shown is undefined.


As I mentioned, it can be defined.


>  > an app is allowed to reset the TCP sequence
>> number when it wants to.
>
> Which above I have explained is the same cost as starting a new connection.


I agree.  It is this kind of opinion that I want to gather
from this list.


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


>  > Note that
>> there is no clear usage proposed in that draft nor any reason
>> that it is needed, just a mechanism to do it.
>
> It would be useful to explain a goal use, otherwise it's impossible to
> determine whether the mechanism is sufficient.


This was exactly my question raised in the TSVWG mailing list...


-- 

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