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

I'll make the changes Jeff suggests to the next revision.

>----------
>From: 	Jeffrey Mogul[SMTP:mogul@pa.dec.com]
>Sent: 	Friday, August 16, 1996 12:50 PM
>To: 	Paul Leach
>Cc: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	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 14:17:47 UTC