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

Re: Hit Metering - report of 0/0

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 21 Nov 96 14:01:26 PST
Message-Id: <9611212201.AA04469@acetes.pa.dec.com>
To: mcmanus@appliedtheory.com
Cc: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
    >   A proxy SHOULD NOT transmit "Meter: count=0/0", since this conveys
    >   no useful information.
    
    I believe that this draft should be silent on this issue, largely
    because whether a count=0/0 response is useful information or not is a
    context sensitive question.
    
    The origin server is explicitly given the right the right to decide
    whether or not to enter into a caching 'contract' with a proxy based
    upon any criteria it chooses. I can envision a situation where
    reporting of 0 hit counts would be a valuable criteria to base this
    decision on.

You may be right that a case could be made that this information
is sometimes useful.  But if so, then I think you need to suggest
a modification to the proposal that would allow the server to
request the 0/0 counts *only* when they are needed.  And this would
have to include some careful language around how and when a proxy
receiving such a report needs to forward it to the next inbound
server.

In the absence of a specific server request for a 0/0 count,
the proxy would not know if the 0/0 report is worth sending.
Since a significant fraction of the entries in typical proxy
caches are removed without ever being reused, if a proxy
simply defaulted to sending 0/0 reports in all cases, it
could end up sending more messages than if hit-metering were
not used at all.

I think there are better metrics for measuring network reliability.
For example, with just a little help from the TCP stack, either
end could count the number of retransmissions and/or timeouts.
This shouldn't require us to add extra message traffic to the
network, via otherwise unnecesary HTTP messages.

Anyway, you might take some comfort in our use of the term
"SHOULD NOT" rather than "MUST NOT" in this context :-)

-Jeff
Received on Thursday, 21 November 1996 17:02:21 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:16 EDT