W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

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

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Fri, 31 May 96 11:17:52 MDT
Message-Id: <9605311817.AA23401@acetes.pa.dec.com>
To: Koen Holtman <koen@win.tue.nl>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/622
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC