Re: Hit-metering: to Proposed Standard?

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

It probably would help to think of our proposed design as counting
"uses" of "responses", not as counting "uses" of "resources".  When
one takes this perspectice, the fact that a resource may have several
names is largely irrelevant, as long as the mapping from the name
(URL) given in an HTTP request to a *cachable* response is stable.
(If it were not stable, then I would not expect the response to be
cachable in the first place!)
    
    >     > 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.

No, this is not required by our proposal.  The origin server may
want to do this if it wants to play complex games with the usage-limiting
mechanism, but for hit-metering, I see no reason for the origin
server to remember which proxies have a copy of a response.  (Some
people are working on cache-invalidation schemes that would require
some sort of server-side database, but this is a separate issue entirely.)

    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.

I'm not sure what you mean by "flow-information."  Can you give a
specific example?

-Jeff

Received on Monday, 25 November 1996 15:33:54 UTC