Pasi Eronen: Section 5.4.2.2: The timestamp should also have some fuzz
factor taking the typical resolution of timestamps (e.g., 1 second)
into account. Otherwise we get a situation like this:

(Let's assume that both hosts have perfectly synchronized and accurate
clocks, timestamp resolution is 1 second, and transmission delay is
100 ms.)

   10.100 Sender sends a message, with Timestamp value 10
   10.200 Packet is received (RDnew=10, TSnew=10).  
          This is a new message, so we store RDlast=10, TSlast=10.
   11.950 Sender sends another message, with Timestamp value 11
   12.050 Packet is received (RDnew=12, TSnew=11). This is a known 
          peer, so we compare 11 > 10 + (12-10)*(1-0.01). 
          Unfortunately, this fails!

-----

Jari Arkko: I thought about this for a while, and at first it seemed
like requiring a higher clock resolution would solve it. But I don't
think we can mandate more than one second's resolution for all possible
types of nodes. So your suggestion of a fuzz factor sounds reasonable.

Here's the new text:

   Receivers SHOULD be configured with an allowed timestamp Delta value,
   a "fuzz factor" for comparisons, and an allowed clock drift
   parameter.  The recommended default value for the allowed Delta is
   3,600 seconds (1 hour), for fuzz factor 1 second, and for clock drift
   1% (0.01).

   ...

   o  When a message is received from a known peer, i.e., one that
      already has an entry in the cache, the time stamp is checked
      against the previously received SEND message:

        TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz