Subject: issue 46 - fuzz factor

From: <[email-masked]>
Date: Mon, 22 Dec 2003 16:29:25 +0200

Pasi,

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

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

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------