[e2e] TCP sequence number reset

Kacheong Poon ka-cheong.poon at oracle.com
Tue Mar 29 22:36:29 PDT 2011

As I mentioned in my reply to Joe Touch, I am not trying
to propose such a TCP mechanism.  I just mapped the proposed
SCTP mechanism to TCP since TCP is more widely known and
probably will generate more comments.  And I think your
comments below can be mapped to SCTP and still be applicable.
It is this sort of comments which I'd like to gather since
I am probably the only person in the TSVWG mailing list who
has reservation on the proposed SCTP mechanism.

On 03/28/11 09:53 PM, Marcel Waldvogel wrote:
> Several questions need to be answered before we can decide on "Do we want to go through the hassle of resetting the sequence number?"
> 1. What sequence number (relative or absolute, see below) do you want to export to applications?
> 2. Why do you want to do it? (Or why may someone want to do so?)
> 3. What would be the semantics of this?
> 4. Why do you want to reset it?
> 5. If SCTP already has the functionality, why not use SCTP for applications requiring it?
> None of these questions have been answered so far. I am trying to structure the discussion a little bit by answering the first one and opening the second.
> The "relative" sequence number of a particular byte (relative to the ISN) can best be computed by the application itself, recording the number of bytes read so far. This way of counting also makes sure that the "right" thing is counted, i.e., what the application probably wants to know, which is likely not related to the internal TCP state of the connection endpoint. The application is then also free to define a mechanism to reset that variable, no transport protocol or interface changes needed.
> The "absolute" sequence number (the one transmit in SEQ and ACK fields) is probably of no use to a "normal" application and resetting it will cause major problems as outlined in previous mails.
> For the first ("relative") one, I do not see a need to change the API. Even if there were good uses for it, the application is free to count the bytes itself and reset counters at will and has the added advantage of remaining fully portable.
> The second ("absolute") case is dangerous and will likely cause all kinds of interoperability problems. Unless someone comes up with a use case, we should stop wasting our time discussion it further.
> As a result, even after the clarification from the first question, I see no way of positively answering the second question.
> -Marcel


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

More information about the end2end-interest mailing list