Meter: max-uses=10

   The proxies use that response to satisfy the current requesting end-
   client.  The max-uses directive in this example allows the
   combination of P1, P2, and P3 together to satisfy 10 additional end-
   client uses (unconditional GETs) for the resource.

   This specification does not constrain how P3 divides up that
   allocation among itself and the other proxies.  For example, P3 could
   retain all of max-use allocation for itself.  In that case, it would
   forward the response to P1 and/or P2 with

       Meter: max-uses=0

   P3 might also divide the allocation equally among P1 and P2,
   retaining none for itself (which may be the right choice if P3 has
   few or no other clients).  In this case, it could send

       Meter: max-uses=5

   to the proxy (P1 or P2) that made the initial request, and then
   record in some internal data structure that it "owes" the other proxy
   the rest of the allocation.

   Note that this freedom to choose the max-uses value applies to the
   origin server, as well.  There is no requirement that an origin
   server send the same max-uses value to all caches.  For example, it
   might make sense to send "max-uses=2" the first time one hears from a
   cache, and then double the value (up to some maximum limit) each time
   one gets a "use-count" from that cache.  The idea is that the faster
   a cache is using up its max-use quota, the more likely it will be to
   report a use-count value before removing the cache entry.  Also, high
   and frequent use-counts imply a corresponding high efficiency benefit
   from allowing caching.

   Again, the details of such heuristics would be outside the scope of
   this specification.

4 Analysis

   This section includes informal analyses of several aspects of hit-
   metering:

      1. the accuracy of results when applied to counting users
         (section 4.1).

      2. the problem of counting users whose browsers do not
         include caches, such as Network Computers (section 4.2).




 
RFC 2227            Hit-Metering and Usage-Limiting         October 1997


      3. delays imposed on "critical paths" for HTTP operations
         (section 4.3).

4.1 Approximation accuracy for counting users

   For many (but not all) service operators, the single most important
   aspect of the request stream is the number of distinct users who have
   retrieved a particular entity within a given period (e.g., during a
   given day).  The hit-metering mechanism is designed to provide an
   origin server with an approximation of the number of users that
   reference a given resource.  The intent of the design is that the
   precision of this approximation is consistent with the goals of
   simplicity and optional implementation.

   Almost all Web users use client software that maintains local caches,
   and the state of the art of local-caching technology is quite
   effective.  (Section 4.2 discusses the case where end-client caches
   are small or non-existent.)  Therefore, assuming an effective and
   persistent end-client cache, each individual user who retrieves an
   entity does exactly one GET request that results in a 200 or 203
   response, or a 206 response that includes the first byte of the
   entity. If a proxy cache maintains and reports an accurate use-count
   of such retrievals, then its reported use-count will closely
   approximate the number of distinct users who have retrieved the
   entity.

   There are some circumstances under which this approximation can break
   down.  For example, if an entity stays in a proxy cache for much
   longer than it persists in the typical client cache, and users often
   re-reference the entity, then this scheme will tend to over-count the
   number of users. Or, if the cache-management policy implemented in
   typical client caches is biased against retaining certain kinds of
   frequently re-referenced entities (such as very large images), the
   use-counts reported will tend to overestimate the user-counts for
   such entities.

   Browser log analysis has shown that when a user revisits a resource,
   this is almost always done very soon after the previous visit, almost
   always with fewer than eight intervening references [11].  Although
   this result might not apply universally, it implies that almost all
   reuses will hit in the end-client cache, and will not be seen as
   unconditional GETs by a proxy cache.