[e2e] TCP sequence number reset

[Stjepan Gros]

On Thu, 2011-03-24 at 15:52 +0800, Kacheong Poon wrote: 
> 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, an app is allowed to reset the TCP sequence
> number when it wants to.  The sequence number is set to a number
> not acceptable (add 231) in the current connection.  Note that
> there is no clear usage proposed in that draft nor any reason
> that it is needed, just a mechanism to do it.  I want to see
> whether folks on this list think that it is a good or bad idea?
> And why?

I'll start with the question why should an application know/care about
sequence numbers of transport layer? No matter how hard I tried to think
of a reason for letting application know that I couldn't think of any.
If any application needs this functionality it can count those units for
itself (or prepend sequence numbers before sending data). Only
information currently unavailable to an application are sequence numbers
in flight, but again, of what use is that? In other words, sequence
numbers have certain meaning to the transport layer, and now this
mechanism would allow applications to add their own semantic on top of
it and make things even more complex. 

So let me try to summarize objections/comments valid for, at least, TCP:

A. There is no point in introducing any mechanism into any protocol
without a proper justification/motivation of what benefit it would
bring. Otherwise, it's only purpose is to increase protocol's complexity
(that of implemented protocol and/or in the number of protocol
specifications).

Of course, this is a valid reason only in the case when there is intent
to "standardize" mechanism (in RFC to be more precise).

B. Sequence numbers are internal mechanism to TCP. Allowing them to be
visible to applications would introduce tight coupling between TCP's
protocol machine and user applications. This would, IMHO, be analogous
(though not the same) to the situation we currently have with IP
addresses visible in the higher layers.

C. Impact of the application having the ability to mess with sequence
nmbers (and as the consequence with the window and congestion windows)
and acknowledge mechanism shouldn't be taken so lightly. I think more
analysis and studying potential consequences would be necessary.

These are high level objections and for me the reason A is number one
blocker. To get low level objections you should be more precise in the
description of the mechanism. This would allow protocol analysis that
could reveal potential illegal protocol states or possible protocol
malfunctioning.

My $0.02

Stjepan Gros