Re: Hit Metering - report of 0/0

In a previous episode...Jeffrey Mogul said:
-> 
->     >   A proxy SHOULD NOT transmit "Meter: count=0/0", since this conveys
->     >   no useful information.

->     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.

That's absolutely true, and I think you can take that conclusion one
step further. 

In the absence of a specific server request for any minimum return
count, the proxy cannot know if the report is worth sending. Some servers
may not believe that a return connection is worth the overhead of
receiving a 1/0 report, just as some servers may insist on seeing a
0/0 report to know that the proxy's 'best-effort' is succeeding.

perhaps the initial negotiation could contain a count-range meter
header from the proxy indicating the bounds (both hi and low) it is
willing to report for, and the server response could return min and
max values in that range that represents the reporting interval.
(i.e. don't report anything less than 2 hits, but never go more than
15 without sending a report)

 This nicely separates the functionality of max-uses from the
reporting functions in any case. I don't see any reason to believe
that their values are going to be derived from the same criteria, just
because you want more frequent reports from a cache that has held your
page for 2 weeks than every 2 weeks, doesn't mean the resource is now
invalid. 

What do people think of this?

-> 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.

agreed, but my point is that the server's decision to enter into the
reporting 'contract' and allow caching is a decision that is opaque to
your proposal. There shouldn't be language that excludes some
techniques because it isn't relevant or important, in a black-boxed
decision we can't know what will be relevant.

-Patrick

--
Patrick R. McManus - Applied Theory Communications -	Software Engineering
http://pat.appliedtheory.com/~mcmanus			Programmer Analyst
mcmanus@AppliedTheory.com	'Prince of Pollywood'	Standards, today!
*** - You Kill Nostalgia, Xenophobic Fears. It's Now or Neverland. - ***

Received on Friday, 22 November 1996 06:20:48 UTC