W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Re: Age calculations in HTTP 1.1 11/21/97 document

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Fri, 27 Feb 98 12:01:24 PST
Message-Id: <9802272001.AA18498@acetes.pa.dec.com>
To: Burt Silverman <burts@us.ibm.com>
Cc: http-wg@cuckoo.hpl.hp.com, mogul@pa.dec.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5412
    Looking at section 13.2.3, I found that I could only make sense of
    the formulas if I switched the definition of apparent_age from
    apparent_age = max(0,response_time - date_value);
    apparent_age = max(0,request_time - date_value);
    For example, if in year
    1981, the user sent a request
    1989, date_value
    1990, request from the cache to the server
    2000, resonse_time
    2001, now
    apparent_age = 1 year
    response_delay = 10 years
    corrected_initial_age = 11 years
    resident_time = 1 year
    current_age = 12 years. This seems to make sense.
    But with the official definitions,
    apparent_age = 11 years
    response_delay = 10 years
    corrected_initial_age = 21 years
    resident_time = 1 year
    current_age = 22 years. This brings us back to 1979, and doesn't make
    much sense.

It's misleading to try to discuss this in terms of years, since
it's highly unlikely that the difference between request_time
and response_time would be larger than a few minutes at most.

Anyway, the problem we're trying to solve here is that in this

	request_time        date_value          response_time
	      |                |                       |

it really makes no sense to compute

    apparent_age = max(0, request_time - date_value);

because if the clocks are synchronized, then (with non-zero
speed-of-light delay) the value (request_time - date_value)
is always negative, and so the max(0, request_time - date_value)
would always be zero.

The fact that the response_delay is counted twice in the
final result is an attempt to correct for clock skew,
since if you can't guarantee that the client and server
clocks are synchronized (and we can't!), then the apparent_age
could be wrong by a significant amount.  (Trace studies show
that a lot of the clocks in HTTP servers are set wrong, and
we suspect that the situation for clients could be even
worse.)  Adding in the response_delay helps to avoid underestimating
the Age of a response in the presence of clock skew.

The actual magnitude of the error is normally quite small,
since response_delay ought to be on the order of several
seconds, or several minutes at most.

Received on Friday, 27 February 1998 12:03:19 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC