Re: Hit-metering: to Proposed Standard?

> Jeffrey Mogul:
>     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.

usage-limiting on its own is no problem, from my point of view. My worry is 
the combination and how it is going to be used in the combination with 
hit-metering.

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

How about resources that are avilable from several sources (URNs)?

Your proposal does not force a particular path through a mesh, but the 
implementations of your proposal are likely to do that unless the issues 
concerning these aspects are raised, discussed and not recommended in your 
proposal.

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

The proxy may have to store where I did get a document, and the origin server 
may have to (or want to) store who it gave a document. As a cachemanager I 
will (probably) have to handle flow-information that I do not have to care 
about today. I would like to count and send count to the server, without 
caring about flow. Combinations of hit-metering and usage-limiting may force 
me to store flow-information.


Ingrid
-- 
  Ingrid.Melve@uninett.no            MIME, PGP and PEM email encouraged
        UNINETT, Postboks 6883 Elgeseter, N-7002 Trondheim, Norway 
  Oj, der telte han meg. Ċjojoj, er telte han meg en gang til!

Received on Friday, 22 November 1996 05:06:45 UTC