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