Question on Loosely Synchronized Router Clocks
Stephen Sprunk
stephen at sprunk.org
Tue Sep 18 19:52:17 UTC 2007
Thus spake "Xin Liu" <smilerliu at gmail.com>
> 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
More information about the NANOG
mailing list