Re: Hit-metering: to Proposed Standard?

> Jeffrey Mogul:
> 
> Since we have not seen any criticism of our latest proposal, we would
> like to interpret this as lack of criticism rather than lack of
> interest, because we already have evidence that several large customers
> are eager to deploy implementations of our proposal.

I have some questions to the draft as it stands.

The concept of hit-metering is reasonably clear (as cachemaster I get phone 
calls asking for hitcounts and refuse to give them out), but the reason for 
usage-limiting is less clear to me. Either I implement hitmetering, in which 
case the webserver gets its counts; or I do not, in which case I ignore the 
usage-limiting. 

My question is: why bother with usage-limiting ?
(and implementing it in a caching mesh with multiple co-operating caches on 
each level in a "hierarchy" will be a pain). The purpose of bounding 
inaccuracy in a count is not achieved by adding usage-limiting, as the primary 
inaccuracy will be added by ill-behaving caches, users' inimitable inaccurate 
ways (check once per session, always check, never check), servers/network 
failure and so on (including all those that do hitmetering but do not honour 
the usage-limiting).  The only useful thing is that it does limit the number 
of times a "well-behaved" cache server hands out the same ad. Is the 
complexity of usage-limiting worth it?

To illustrate the mesh problem: If I am a cache that gets handed 2 usages 
through my first parent and 4 through my second parent, do I have to report 
back through the parent who gave me the usage-limit or can I freely chose to 
report back through my third parent (who has not connected to the origin 
server before and is likely to report 4 out of zero and 2 out of zero or 
generally confuse the origin server)? If I have to report through the 
appropriate parent, this requires me to store where I got the document from; 
and it heavily influences traffic patterns, robustness and the redundancy of 
my mesh.

<<
3.3 Negotiation of hit-metering and usage-limiting
   An origin server that wants to collect hit counts for a resource, by
   simply forcing all requests to bypass any proxy caches, would respond
   to requests on the resource with "Cache-control: proxy-revalidate".
   (An origin server wishing to prevent HTTP/1.0 proxies from improperly
   caching the response could also send both "Expires: <now>", to
   prevent such caching, and "Cache-control: max-age=NNNN", to allow
   newer proxies to cache the response).
>>

In reading the HTTP/1.1 spec, I had the understanding that must-revalidate and 
proxy-revalidate as defined in 14.9 only requires a cache to revalidate if the 
response is stale, not every time a request is made (unless there is an 
Authorization field). Please correct me if I am wrong.

> draft-ietf-http-v11-spec-07.txt:
> When the must-revalidate directive is present in a response received 
> by a cache, that cache MUST NOT use the entry after it becomes stale 
> to respond to a subsequent request without first revalidating it with 
> the origin server. (I.e., the cache must do an end- to-end 
> revalidation every time, if, based solely on the origin server's 
> Expires or max-age value, the cached response is stale.)
> [..]
> The proxy-revalidate directive has the same meaning as the must- 
> revalidate directive, except that it does not apply to non-shared 
> user agent caches.

If the proxy handing out a "Cache-control: proxy-revalidate" also is expected 
to modify staleness parameters like "Cache-control: max-age=0" this should be 
stated.  Are caches allowed to change max-age ??

More questions to come.


Ingrid
-- 
  Ingrid.Melve@uninett.no            MIME, PGP and PEM email encouraged
        UNINETT, Postboks 6883 Elgeseter, N-7002 Trondheim, Norway 
  Oj, der telte han meg. Der telte han meg en gang til! For en tøffing!

Received on Wednesday, 20 November 1996 10:29:39 UTC