Question on Loosely Synchronized Router Clocks

Stephen Sprunk stephen at
Tue Sep 18 19:52:17 UTC 2007

Thus spake "Xin Liu" <smilerliu at>
> Ideally, yes, a protocol should not rely on clock synchronization
> at all. However, to ensure freshness of messages, we don't have
> many choices, and clock synchronization seems to be the least
> painful one.  So we asked about router clocks on the current
> Internet. If normally router clocks are synchronized and we have
> a mechanism to detect and fix out-of-sync clocks, ...

Your protocol should not attempt to "fix" clocks that aren't in sync unless 
it's specifically labeled as a time-distribution protocol.  If people wanted 
that, they'd be using NTP.  Do not surprise them with unexpected behavior.

> ... is it reasonable to assume clock synchronization in the rest
> of our design?

In general, it is not.  I can't think of any existing protocol that does, 

There's basically two common methods for determining "freshness": 
liveness-based and duration-based.  BGP, for instance, uses the model where 
the most recent message regarding a particular route is assumed to be fresh 
until the peer is detected to be dead, in which case all messages from that 
peer become stale.  RIP, on the other hand, uses the model where a message 
is fresh (unless updated) for a certain duration and it becomes stale when 
that duration expires.

Notice that neither requires the sender or receiver to agree on the time. 
Even in protocols like SIP, which include an explicit validity duration for 
some messages, that duration is specified as the number of seconds after 
transmission, not a fixed point in time.  You don't need to agree on what 
time it is to agree when "180 seconds from now" is.  The receiver takes the 
current local time, adds the duration specified, and that's the local 
expiration time.

HTTP muddles this a bit by allowing absolute time/date expiration; however, 
it requires the server to send what it thinks the current time/date is.  The 
client should then calculate the difference and uses it as if it were a 
duration above.  (i.e. if the server says it's now 1 Jan 1980 00:00:00 and 
an object expires on 31 Jan 1980 00:00:00, and my local time is now 18 Sep 
2007 19:49:00, my client should actually use an expiration of 17 Oct 2007 
19:49:00.)  That's ugly.


Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 

More information about the NANOG mailing list