[e2e] TCP sequence number reset

[Detlef Bosau]

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.

Detlef