Re: New document on "Simple hit-metering for HTTP"

Koen writes:
    But when removing the cache entry, _the proxy does not necessarily
    have an open persistent connection to the origin server in question_.
    I would be more happy if the draft explicitly allowed a proxy to
    report the hit count of a removed cache entry within, say, one day of
    removing it.  This would allow the proxy to batch the HEAD requests
    for each server and send them at night, when the there is enough
    bandwidth left to make opening extra connections not hurt.
    
Paul writes:
    Sure -- it already says it need not wait for the HEAD request to finish
    before removing the item; it wouldn't hurt to mention that it can defer
    (and batch) the requests as long as there is a high probability that it
    will get made.

I see no problem with saying that the proxy can defer and batch
the final-report HEAD requests but I do not believe that it makes
sense to have this delayed until "at night" (which is a problematic
concept, since it assumes that the proxy actually knows when more
bandwidth will be available).

I'm worried that long delays in updating this information will
discourage origin servers from using the mechanism, and I'm also
worried that any mechanism that causes all of the proxies within
a particular time zone to spontaneously generate a large stream
of requests at a particular point in time will cause the nasty
synchronized congestion that Floyd and Jacobson warned about in
Proc. SIGCOMM '93.  (One could avoid this by some randomization,
but they point out that this is much harder than one might suppose.)

So my suggestion is that the spec says something like:

	A proxy MAY defer the final-report HEAD request to an origin
	server, and send a batch of these later, either piggybacked on
	its next request to the server or when sufficient resources are
	available.  A proxy SHOULD NOT delay these reports longer than
	absolutely necessary, to avoid discouraging the use of
	hit-metering.  A proxy SHOULD NOT delay these reports if there
	is a significant probability that it will be unable to deliver
	them after the delay.  A proxy MUST NOT delay these reports for
	delivery at a non-randomly-chosen specific time of day; this is
	necessary to prevent unnecessary congestion.

-Jeff

Received on Friday, 16 August 1996 13:59:51 UTC