[e2e] TCP sequence number reset
detlef.bosau at web.de
Mon Mar 28 09:01:11 PDT 2011
On 03/28/2011 03:53 PM, Marcel Waldvogel wrote:
> 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.
In addition, changing the API may not even be sufficient, but the
internal function of a socket would be subject to change as well.
E.g., when an application could refer to some "extremely old" relative
sequence number, it is well possible that some requested data is no
longer available in the socket(s, both, sender side and receiver side as
well) and the sending application. We should bear in mind that the
sending application is free to discard any data which has been
successfully written to the sending socket and the sending socket is
free to discard any data, which has been acknowledged by the receiving
socket. So, some reference to "old" data may point to data, which no
longer exists neither in the socket nor in the sending application. The
same holds true for any attempt to "roll back" a TCP stream to some
state, any information for which was discarded long ago.
As Eric pointed out, TCP is a distributed state machine with "loosely"
coupled sockets. "Loosely coupled" in the sense that we have a soft
state which is robust against packet loss or packet order distortion.
Although packet loss or packet order distortion may lead to some
throughput degradation, both is overcome without any severe harm to the
flow itself. In contrast to that, a strict coupling of states between
communication end points may lead to quite some two army problems, which
may be quite cumbersome to deal with.
More information about the end2end-interest