Subject: Re: [Tsvwg] Updating timestamps (ts_recent) in Linux

From: David Borman <[email-masked]>
Date: Tue, 12 Aug 2003 10:53:49 -0500 (CDT)

Hi,

Sorry that I haven't responded sooner.  I've submitted the update to
RFC 1323 to internet drafts again, maybe this time we can get it
actually published...

> Date: Thu, 7 Aug 2003 14:59:05 -0700
> From: "Duke, Martin" <[email-masked]>
> Subject: [Tsvwg] Updating timestamps (ts_recent) in Linux
>
> I've heard rumors that this has been discussed before on tcp-impl, but an
> extensive search found no messages on this topic, so apologies for possibly
> re-treading old ground.
>
> 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.

These changes are in 1323.bis.

> 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.

For copying TSval from the packet to TS.Recent, rule (2) in RFC 1323 is:
              SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN

This attempted to only update TS.Recent when you received new data.
But that causes the problem with lost ACKs.  In addition, when you
receive an ACK (SEG.LEN == 0), the timestamp that you receive will
not be artificially inflated (since it was just generated by the remote
side when it sent the ACK), so it is OK to update TS.Recent from ACK only
packets (but only if TS.Recent has advanced)

In 1323.bis, rule (2) is:
              SEG.TSval >= TSrecent and SEG.SEQ <= Last.ACK.sent

This change addresses these two issues with RFC 1323:
        (1)  It failed to update TSrecent for a retransmitted segment
             that resulted from a lost ACK.
   
        (2)  It failed if SEG.LEN = 0.

So this modified rule allows TSrecent to be updated whenever a newer
TSrecent is received, except when the packet is out of order.  In that
case, we continue to echo the TS from the latest received packet at or
to the left edge of the window.

> 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?

As a final thought, updating TSrecent more often does not mean that you
can get RTT measurements more often.  It continues to be the case that the
only time you can get a reliable RTT measurement from timestamps is when
when new data is acknowledged.  That is because dup ACK packets can be
spontainiously generated by the remote side to do a window update.  In
that case, taking an RTT measurement can be vastly over inflated.  And
since there is no way to reliably identify whether a received dup ACK
is due to out-of-order data arriving or due to the remote side deciding
to update the window, the best course of action is to only take RTT
measurements when new data is acknowledged.
 
> Martin Duke
> [email-masked]

			-David Borman

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 13 Aug 2003 10:26:33 +0200

>measurements when new data is acknowledged.

This brings up another issue that is currently not defined in any RFC: what 
is a DUPACK?

The BSD code (tcp_input.c) is quite clear about it: an ACK is a DUPACK if
   1. the TCP sender has outstanding data, AND
   2. the ACK number is the largest seen so far, i.e., it acks snd_una, AND
   3. the ACK is a pure ACK, i.e., SEG.LEN == 0, AND
   4. the advertized window info didn't change,
      i.e., this is *not a window update*.

So, we with this definition of a DUPACK it should be save for the TCP 
receiver to echo the most recently received ts_val in DUPACKs, and for the 
TCP sender to use such DUPACKs to get a reliable RTT measurement.

Did I miss something?

///Reiner