Re: Dates vs. Deltas [was: An alternative to explicit revocation? ]

    >Actually, I spent part of the weekend mulling this over, and I
    >think the use of absolute expiration dates (as opposed to "seconds 
    >remaining") is a mistake.
    
    (1) I disagree, and (2) that's not what I was talking about. I
    was talking about the zillions of date formats: Tue, 02 Jan 1996 ...
    as opposed to nice sortable ISO format: 19960102163724Z.
    
I'm not thrilled about the current HTTP-date formats, especially
since my survey of Expires: headers shows that at least some
servers are incapable of generating them in correct syntax.  But
this is not something that our subgroup can or should address.

At any rate, it should be possible to write a conversion function
between HTTP-date format and ISO format, so I don't think this
is anything more than a representation issue.

    >Consider the problem of dealing with clock skew.
    I'd rather not. I'd rather

	(1) have as few mechanisms as possible depend on
	global synchronization (e.g. compare IMS dates
	for equality _only_, and never order)

I think you missed my point.  If we use absolute dates, then
clock skew *is* a problem.  I'm suggesting that we don't want
to add too many mechanisms to solve that problem.  (I think
we are in violent agreement here.)

	(2) in the few cases where we need global synchronization,
	just count on everybody having good clocks, and live
	with the resulting level of reliability.

The problem comes up if servers start assigning relatively short
expiration dates (or what I would prefer to call "fresh-until"
times, to keep the concepts separate).  For example, a sports-related
Web site might want to report new positions in a 1999 America's
Cup sailboat race every 10 seconds, but because everyone in the
world will be watching (won't you? :-)), the server would prefer
that these be cached as effectively as possible.  I'm sure there
are plenty of sites with 10-second clock errors (the Wall Street
Journal reported last year that Nynex's dial-the-time number was
off by almost a minute).

Such short fresh-until periods might be rare today, but 5 years
from now who knows what people will be doing with the Web?

    ew... I hate the term "cachable." I much prefer "fresh." 

My mistake.

    >One have the caches rewrite the expiration dates, or include
    >more mechanisms for clock-deskewing.  But it seems much simpler
    >and safer to express expiration as a number of seconds remaining,
    >which works as long as the inaccuracy in clock rates is reasonably
    >small.
    
    Exactly what do you mean by "works"? How exactly does it "work"?
    
    What exactly is the test for freshness using deltas, and what are the
    input parameters? Does the number of parameters increase with the
    number of parties involved in an HTTP transaction?  I'm playing
    devil's advocate (read: I'm too lazy to think it through myself.)

I've almost finished a lengthy writeup on this, but here's a summary
for now (although Dave Morris seems to have had a similar idea,
with a few different details):

    The server decides how long it wants a response to be fresh for,
    and transmits this value in a header (let's call it the
    Fresh-until:  header) as a number of seconds from the current
    time.

    For a moment, ignore the problem of network latency.  The cache
    receives this header, and stores it with the cached resource
    (probably converting it into an internal form of an absolute
    fresh-until date, since it's a pain to have to maintain relative
    times in the cache database).

    When a request is made to the cache that matches this entry, if the
    fresh-until time has not passed, the response can be returned.
    Otherwise, the cache has to check with the server.
    
    When a cache returns a cached response, it has to provide a
    Fresh-until: value to the recipient.  It computes this by
    subtracting its current clock value from the internal absolute
    Fresh-until stored in the cache entry, to get a currently-valid
    delta value.  Thus, "Fresh-until:" is handled a little differently
    than other kinds of cached headers; the cache does not forward the
    header as it was received from the server, but rather recomputes a
    current value.

    OK, so what about clock skew?  No problem, since the algorithm does
    not involve any agreement between server and clients/caches about
    the absolute value of the time of day.

    We do have to assume that all clocks are ticking at about the same
    rate, and that the cache's clock is not set backwards.  (This is
    probably true for any solution).

    What about network delay?  I.e., the server could say "Fresh-until:
    10" but the response could take 20 seconds to get to the cache.  We
    can solve this by having the cache interpret the delta relative to
    when it sends the REQUEST to the server, not when it receives the
    response.  Because this is guaranteed to be causally ordered before
    the time that the server generates the Fresh-until: value, it is
    always a conservative result.

    For example, suppose that the cache sends a request to the server
    at 3:00:20 (by its own clock), and the server receives and responds
    to the request at 3:00:30 with a Fresh-until value of 30
    (seconds).  The cache receives this request and computes a
    Fresh-until time of 3:00:50, not 3:01:00.
    
    What this means is that big latencies and small Fresh-until
    values will reduce caching effectiveness.  What it also means
    is that clock skew and transmission latency won't ever cause
    a cached response to be treated as fresh when it should be
    treated as stale.

    It also means that the cache has to be able to match the responses
    it gets from a server with the requests it made, but I think this
    will be necessary in any event if we are going to be able to do the
    Right Thing for content negotiation.

Can anyone see any problems with this?

-Jeff

Received on Wednesday, 3 January 1996 23:19:08 UTC