Updating timestamps (ts_recent) in Linux

["Duke, Martin" <[e-mail]>]

I've heard rumors that this has been discussed before on tcp-impl, but an extensive search found no messages on this topic.

How do people feel about the way Linux decides what timestamp to echo?

Specifically, although the behavior is compliant with RFC 1323, an old addendum to the RFC (http://www.kohala.com/start/tcplw-extensions.txt) pointed out some odd behavior.

Essentially, if the connection goes down, the subsequent retransmissions will have later ts values.  However, if an ACK was lost, the kernel currently does not update ts_recent with these values.  If the channel comes back up and a retrans succeeds, the client will send an ack with an ts echo equal to the old value of ts_recent.

As the difference between the echo and the current time is quite large, it 
will result in an extremely large RTT measurement, triggering a huge increase 
in the RTO.  In an unreliable, bursty link, such as satellites, another outage 
could occur shortly thereafter, and an inappropriately long timeout can occur.

The reason for the problem is that ts_recent is only updated if the receive window moves to the right.  Ideally, packets with sequence numbers to the left of the window edge should trigger an update as well.

There are certainly situations where the current Linux behavior is terrible, but I have yet to see an explanation for why this "bug" should not be fixed.  I've heard criticisms of the document cited above as a whole but have yet to understand why updating ts_recent more frequently will break something.  I know that BSD fixed this some time ago (Stevens talks about it in his book).

Any thoughts?

Martin Duke
[e-mail]