Re: Repeat of proposed addition to Age calculations (pre-04 13.2.3)

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.

	(a) I don't think it is particularly easy for a client
	to know reliably that its clock is synchronized with
	the server's,
	(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.


Received on Friday, 31 May 1996 11:28:35 UTC