[e2e] TCP sequence number reset

[Marcel Waldvogel]

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