Confusion about Age: accuracy vs. safety

    > This change (only requiring Age on responses taken from a cache)
    > breaks the clock-deskewing properties of the original Age design.
    > The problem comes when a pre-1.1 cache is in the path and has
    > held onto the response for a while.  It's safest to add the Age
    > header as soon as possible, since it reduces the chances that
    > a skewed clock could result in incorrect comparisons.
    
    That is incorrect -- in fact, adding an Age header onto a response
    received from somewhere else can only make the algorithm less accurate.
    The reason is because the outbound requester is already going to add
    the amount of time it takes for the response to arrive, including any
    time spent by the cache in question.  Therefore, adding an Age header
    onto a response retrieved by a further network request will double
    the amount of Age that the outbound requester will observe,
    for no reason whatsoever, and guaranteeing that the Age calculation
    will be wrong.

I didn't say that adding the Age header early, rather than late,
makes the Age value more accurate.  It doesn't.

I said it makes it *safer*.  Which is to say, if there are any
potential errors in the system, either invisible caches or hosts with
offset clocks, it is safest to err on the side of overestimating
the Age, not underestimating it.  This means that a cache will be
less likely to declare a response "fresh" when it is actually "stale",
which I have consistently argued is far more harmful than the
alternative (having to contact the server for an entry that might
technically be "fresh").  The latter can happen anyway if the cache
has insufficient space, so it's an error we can live with.

The algorithm in the HTTP/1.1 specification tries to not to
underestimate the Age.  This is intentional, and it is neither
"incorrect" nor "for no reason whatsoever."

-Jeff

Received on Thursday, 11 July 1996 17:13:39 UTC