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

Re: v11-03 COMMENT: 16.2.4 Age Calculations

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 22 May 1996 23:32:03 +0200 (MET DST)
Message-Id: <199605222132.XAA29610@wsooti04.win.tue.nl>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, mogul@pa.dec.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/532
Jeffrey Mogul:
>    [Koen Holtman:]
>    I dare to predict that most 1.1 caches will in many cases use not use
>    the correction
>       corrected_received_age = max(now - date_value, age_value)
>    but will use
>       corrected_received_age = age_value
>    instead because the max( ) correction would often, because of clock
>    skew, needlessly decrease the freshness lifetime left without there
>    being any need for this from a general correctness standpoint.
>"Needless" is a slippery concept here. Decreasing the freshness
>lifetime can never turn a semantically transparent response into
>a non-transparent one, but failing to decrease the freshness lifetime
>can do so.  If one views the server's specified expiration time
>as an upper bound on the allowable freshness (rather than a lower
>bound, which makes little sense) then the protocol design has to
>be conservative here.

My argument is that one can do better than

       corrected_received_age = max(now - date_value, age_value)

so the spec should not _require_ this particular correction, as it
does now.

>    There are techniques that work much more reliably and efficiently.
>    For example, the proxy could do a single HEAD request directly to the
>I'm reluctant to encourage this in the specification, 

Me too.  You are correct that the spec should not discuss such things.

What I suggest is that some words are put in the spec that would allow
cache authors to implement something better than

       corrected_received_age = max(now - date_value, age_value)

without this making the cache non-conforming.  For example, below the
16.2.4 text

      apparent_age = max(0, response_time - date_value);
      corrected_received_age = max(apparent_age, age_value);
      response_delay = response_time - request_time;
      corrected_initial_age = corrected_received_age + response_delay;
      resident_time = now - response_time;
      current_age   = corrected_initial_age + resident_time;

 When a cache sends a response, it must add to the
 corrected_initial_age the amount of time that the response was
 resident locally. It must then transmit this total age, using the Age
 header, to the next recipient cache.

the following text could be added:

 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.


Received on Wednesday, 22 May 1996 14:38:57 UTC

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