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

Jeffrey Mogul:
>
>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.

Jeff, I think you misunderstood the context of my proposal.  It is not
about measuring RTTs, it is about measuring clock skew.  The proposed
text does not mean to allow caches to shave half of the observed round
trip time off the age, in fact, the proposed text in

 http://www-uk.hpl.hp.com/people/ange/archives/http-wg-archive/1197.html

which is

 If detailed information about clock skew is available, a cache MAY
 calculate apparent_age using a different formulae than the one above.
 However, use of a different formulae MUST NOT increase the
 probability that clock skew and intermediate HTTP/1.0 caches cause
 the freshness requirements of the origin server to be violated.

disallows this, because such shaving would increase the probability
that the computed age is too low.

I suggest you re-read the messages leading up to the message
referenced above to see what context I was talking about.  To provide
an example along with these messages: I am worried about the following
case:

- badly skewed origin server clock: 9:00
- cache clock:                      10:00

- origin server sends a response with a cache-control header that
  indicates a 30 minute lifetime

Now, the age calculation algorithm in the draft leads to the cache
which receives the response to compute that the response is 60 minutes
old.  This would lead to the cache being forced to revalidate the
response every time it serves it.  This is bad, and it can be improved
on with some work. 

My proposes text does noting more than _allow_ such improvements.  In
one of the messages leading up to the message referenced above, I
already indicated an improvement that would cut the over-estimation of
the age in the above case from 60 minutes to the RTT of an un-cachable
response.  Such improvements are simply too attractive to block, and my
proposed text intends to un-block them.

[....]
>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.

Overestimations _and_ underestimations of the age will happen with the
rules in the draft, the latter if there are 1.0 caches in the chain,
as a result of _clock skew_.  This is a much bigger problem than RTT
variance.  Given that many web servers run on cheap PC hardware, and
given that the clocks in cheap PCs are notoriously inaccurate, I
expect that clock skew problems will not be uncommon.

>-Jeff

Koen.

Received on Friday, 31 May 1996 16:38:21 UTC