W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

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

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 16 Aug 1996 14:08:11 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960816210811Z-41863@tide19.microsoft.com>
To: 'Jeffrey Mogul' <mogul@pa.dec.com>
Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1382
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.
Received on Friday, 16 August 1996 14:17:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC