- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 15 Aug 95 11:00:57 MDT
- To: James Pitkow <pitkow@cc.gatech.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
It seems like an obvious solution(??) is for the cache to throw out
all timestamps greater than a given drift period from the current
time. If I told you I did something in the future, would you
believe me?
I would suggest that any timestamp more than 1 second in the future
is suspect, and should be tossed. Remember that when choosing
between "cache this" and "do not cache this", the latter is always
the safe choice.
I seems to recall a paper on that measured network clock drift,
though it is most likely not valid now with all the PCs out there.
Anybody else recall this paper? If so, we could get an empirical
basis for drift.
Dave Mills has written numerous papers, most recently in Proc.
SIGCOMM '94 (which cites a number of his earlier publications).
If the hosts involved are
o running NTP
o synchronized to proper time standards
o using reasonably decent clock crystals
then it is not at all hard to synchronize clocks to within a few
milliseconds, even over the Internet.
It's quite likely that manufacturers of cheap systems cut corners on
the clock-crystal quality, and/or the managers of a server or proxy
have failed to configure NTP properly. So in real life, the clocks
could be skewed in either direction. This, however, is not something
that the HTTP spec should be perverted to deal with.
-Jeff
Received on Tuesday, 15 August 1995 11:06:25 UTC