Re: 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.

It doesn't make it safer -- the algorithm already takes that into account.
What you are saying is that every step along the way should add the amount
of time it took to satisfy the request EVEN IF THE REQUEST CAME DIRECTLY
FROM THE ORIGIN.  That means that if the request passes through three
caches (A, B, C) with each segment taking (a, b, c, d) amount of time to
satisfy the request

     UA  ------->  A  ------->  B  --------->  C  ------->  OS
            a           b              c             d

then the Age will be calculated as follows:

     At  C:  age=d
         B:  age=d+(c+d)
         A:  age=d+(c+d)+(b+c+d)
        UA:  age=d+(c+d)+(b+c+d)+(a+b+c+d)

when we all know that the REAL age at UA must be less than (a+b+c+d).
Note that (a+b+c+d) will always be added by UA.

The wording that I submitted would have corrected that error in the
specification.  Fortunately, the existing wording of the spec is only
ambiguous -- we'll just have to interpret "cache" to mean that it only
takes effect on retrieval from the caching mechanism.

> 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."

The algorithm is correct -- the explanation and requirement in the section
on Age was and is incorrect, because it implies that all hops must add
to the Age.  It was not intentional -- I was present during all of
the discussions on Age and it was not designed to be incorrect.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Friday, 12 July 1996 07:22:47 UTC