Re: Hit-metering: to Proposed Standard?

    The default use includes both usage-limiting and hit-metering,
    servers are likely to try to take advantage of the combination.

Yes, maybe.  After all, a server that wants to do some form of
usage-limiting has exactly one option today: cache-busting.  In
our proposal, it has the option to do usage-limiting without entirely
breaking caching (by setting the limit above zero) and without
eliminating the possibility of prefetching.  So I believe our
proposal at least gives the option of compromise.

    If usage-limiting and hit-metering are independent, why have an
    example that shows how to use usage-limiting in combination with
    hit-metering?

Precisely because they are independent, they can be combined.
We gave examples of various combinations of hit-metering and
usage-limiting to show that they are, in fact, independent.

    If a origin server hands out usages only to caches that do
    hit-metering; and cache-busting documents to the rest (I read your
    draft as suggesting this is a neat way to do it), then the
    combination does influence which parent I fetch documents from. The
    security aspects of this are interesting, because it may force
    unaware caches to channel their traffic through one branch of the
    mesh (and possibly take down the top cache server as it gets
    overloaded). If the origin server keeps track of what
    usage-limiting happens at different cache servers (as your example
    suggest), this is a bigger problem.

We certainly cannot solve all of the problems arising from trying
to simultaneously optimize security, bandwidth, latency, and ease
of management.  Our proposal does not, however, force a cache to
use any particular path through the mesh (i.e., if it has multiple
paths, we don't force GETs to follow any specific path, although
we would at least expect HEADs to return reports to the appropriate
server.)  Since we open up another possible dimension for optimization
(i.e., one path allows metering, one does not) this makes the
optimization problem harder, but the default solution is not any worse.
    
    > As I said in my response to Ted Hardie, our specification probably
    > ought to say explicitly that the proxy needs to record the identity
    > of the immediate source of a response, and this is another example
    > where that is important.
    
    How will this influence load-sharing?

It should not.  It only influences who needs to see the hit-meter
reports, and it would be entirely acceptable for the proxy to store
multiple source-identities if it is willing to do the bookkeeping
according to the rules we defined.  The implementation becomes somewhat
more complex, but this is the tradeoff for trying to optimize things.

-Jeff

Received on Thursday, 21 November 1996 17:02:20 UTC