- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 31 May 96 11:17:52 MDT
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I wrote the Age calculation rules with two assumptions in mind: (1) be conservative (2) don't assume any clock synchronization Koen observes that if you relax assumption #2, then you can still meet #1 with a slightly less restrictive set of rules. The benefit would be that one could remove half of the observed round-trip delay from the calculated age. The result would be that some cache entries might expire a few seconds later than they would under my rules. However, in order to do this you would need to have some external mechanism (i.e., outside the realm of HTTP/1.1) that tells you whether your clock is synchronized with the one at the host that generated the original response. Since (a) I don't think it is particularly easy for a client to know reliably that its clock is synchronized with the server's, and (b) even if this could be done, the net effect would be measured in a few more seconds of freshness. I think this is not a good idea. One more thing to consider: if my rules cause the Age to be overestimated by a lot (in a case where the clocks really are synchronized), it's almost certainly because there is a lot of variance in the packet-level RTT in the network. (We know that, in the absence of congestion, RTTs inside the orbit of the Moon are less than a few seconds.) But the high-variance situation is exactly the one where network-based clock synch protocols (such as NTP) do their worst job. It's of course possible to synchronize two hosts in this situation by synching each to, say, a GPS-based clock receiver, but this reduces even more the situations where Koen's approach would be of any help. -Jeff
Received on Friday, 31 May 1996 11:28:35 UTC