#29: correcting corrected_initial_age

Hi Alex,

We put this on the HTTPbis issues list a while ago <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/29 
 >, and I've discussed it with a few folks F2F, but AFAICT it hasn't  
been discussed on-list.

In a nutshell, I think you're correct that there's a problem here, but  
your proposal:

>  creation_time = min(date_value, request_time - age_value);
>  current_age = now - creation_time;

has a few (small-ish) issues.

1) The corrected_received_age's subtraction of the date_value from now  
has the (intended, I assume) effect of accounting for upstream HTTP/ 
1.0 caches that don't append an Age header. Your proposal doesn't do  
this.

This is already being diccussed on-list (see recent thread "cache  
freshness / age calcs"), and may go away anyway. Your input there  
would be appreciated.

2) The behaviour when date_value isn't present isn't specified; we  
could address this in prose, but it would be awkward.

This could probably be worked around by either specifying a slightly  
more complex formula, or specifying that when the Date header isn't  
present, a completely separate (and presumably much simpler) formula  
is to be used.

Cheers,



On 31/08/2002, at 2:59 AM, Alex Rousskov wrote:

>
> Hi there,
>
> 	We are testing a couple of RFC 2616 MUSTs related to
> current_age calculation. Many proxies violate a subset of test cases
> that includes an artificial proxy-to-server delay. Looking at the
> results, I think that the proxies are doing the "right thing" and the
> RFC has a problem.
>
> 	I will start with a specific example when current_age formula
> from the RFC yields a way-too-conservative and unnatural result (100%
> error). I will then describe the problem and suggest a fix.
>
> 	I understand that a way-too-conservative age does not lead to
> stale documents being returned. However, if we want proxies to be
> compliant, we may want to fix/mention the problem in the errata or
> elsewhere. Otherwise, the more problems like that are left unaddressed
> (ignored), the more difficult it would be to convince implementors to
> pay attention to the RFC.
>
> 	Perhaps I got it all wrong, please check!
>
>
> A simple example
> ----------------
>
> Here is a real and simple example that detected the problem with the
> original current_age formula from "13.2.3 Age Calculations". The
> absolute values of timestamps below ("0" and "7") have no
> significance.
>
>   time event
>   ---- ------------------------------------------------------------
>    0.0 client request generated
>    0.0 client request reached the proxy, it is a MISS
>    0.0 proxy request to origin server is generated
>    0.0 proxy request reached the origin server
>    0.0 server response generated with Date correctly set to 0, no  
> Age header
>    -- a network delay of 7 seconds --
>    7.0 server response reached the proxy
>    7.0 proxy cached the response
>    7.0 proxy forwarded the response
>    7.0 the response reached the client
>    7.0 another client request for the same URL generated
>    7.0 client request reached the proxy, it is a HIT
>    7.0 proxy must compute Age header value, see math below
>
> Following RFC 2616:
>
>    age_value = 0             (the cached response has no Age header)
>    date_value = 0            (the cached response has Date set to 0)
>    request_time = 0          (the proxy generated request at time 0)
>    response_time = 7         (the proxy received response at time 7)
>    now = 7                   (the current time is 7)
>
>    apparent_age = max(0, response_time - date_value) = 7
>    corrected_received_age = max(apparent_age, age_value) = 7
>    response_delay = response_time - request_time = 7
>    corrected_initial_age = corrected_received_age + response_delay =  
> 14
>    resident_time = now - response_time = 0
>    current_age   = corrected_initial_age + resident_time = 14
>
> The true age is, of course, 7 and not 14. The above formulas just  
> double true
> current age in the case of a network delay between the proxy and the  
> origin
> server. The fixed formula (see below for the discussion) does not:
>
> current_age = now - min(date_value, request_time - age_value) =
>             = 7 - max(0, 0 - 0) = 7
>
> N.B. If the proxy computes Age header for misses and uses that as
> age_value when serving hits, the formulas yield the same result.
>
>
> The Problem
> -----------
>
> RFC 2616 says:
>
>   Because the request that resulted in the returned Age value must  
> have
>   been initiated prior to that Age value's generation, we can correct
>   for delays imposed by the network by recording the time at which the
>   request was initiated. Then, when an Age value is received, it MUST
>   be interpreted relative to the time the request was initiated...
>   So, we compute:
>
>      corrected_initial_age = corrected_received_age
>                            + (now - request_time)
>
> I suspect the formula does not match the true intent of the RFC
> authors. I believe that corrected_initial_age formula counts
> server-to-client delays twice. It does that because the
> corrected_received_age component already accounts for one
> server-to-client delay. Here is an annotated definition from the RFC:
>
>   corrected_received_age = max(
>     now - date_value, # trust the clock (includes server-to-client  
> delay!)
>     age_value)        # all-HTTP/1.1 paths (no server-to-client delay)
>
> I think it is possible to fix the corrected_initial_age formula to
> match the intent (note this is the *initial* not *received* age):
>
>   corrected_initial_age = max(
>     now - date_value,                # trust the clock (includes  
> delays)
>     age_value + now - request_time)  # trust Age, add network delays
>
> There is no need for corrected_received_age.
>
>
> Moreover, it looks ALL the formulas computing current_age go away with
> the above new corrected_initial_age definition as long as "now" is
> still defined as "the current time" (i.e., the time when current_age
> is calculated):
>
>   current_age = corrected_initial_age
>
> So, we end up with a single formula for all cases and all times:
>
> current_age = max(now - date_value, age_value + now - request_time) =
>             = now - min(date_value, request_time - age_value)
>
> It even has a clear physical meaning -- the min() part is the  
> conservative
> estimate of object creation time. We could rewrite for clarity:
>
>  creation_time = min(date_value, request_time - age_value);
>  current_age = now - creation_time;
>
>
> Am I missing something important here? If I am right, and the current
> formulas count server-to-client delays twice, is it worth mentioning
> in the errata or elsewhere as a bug? Or should we insist that
> implementations use current_age calculation from the RFC anyway?
>
> Thank you,
>
> Alex.
>
> -- 
>                            | HTTP performance - Web Polygraph  
> benchmark
> www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
>                            | all of the above - PolyBox appliance
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 14 October 2009 09:31:57 UTC