North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Question on Loosely Synchronized Router Clocks

  • From: Stephen Sprunk
  • Date: Wed Sep 19 00:58:48 2007


Thus spake "Xin Liu" <[email protected]>
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, actually.


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.

S

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