draft-ietf-http-hit-metering-03.txt

Regarding draft-ietf-http-hit-metering-03.txt ...

>1.1 Goals, non-goals, and limitations
>...
>   This design has certain potential limitations:
>
>      - If it is not deployed widely in both proxies and servers,
>        it will provide little benefit.
>
>      - It may, by partially solving the hit-counting problem,
>        reduce the pressure to adopt more complete solutions, if
>        any become available.
>
>      - Even if widely deployed, it might not be widely used, and
>        so might not significantly improve performance.
>
>   These potential limitations might not be problems in actual practice.

It may also be that, by placing this proposal on the standards track,
proxy implementers will be forced, for the sake of efficiency or lack
of network resources, to add the Meter field to every request regardless
of their intention to pass along metering information.  The result would
be that every proxied HTTP request would include an extra 19 bytes serving
no useful purpose.

>   The Meter header carries zero or more directives, similar to the way

It is NOT the "Meter header".  The header of a message is the sum of all
of the header fields.  It should be referred to as the "Meter field" or
"Meter header field" or "Meter request-header" (the latter is a BNF rule).

The proposal places restrictions on proxies in order to restrict the
actions of shared caches.  The presence of a non-caching proxy in the
chain will break the metering tree, even though a non-caching proxy
has no impact on metering itself.  Section 5.5 (which should be referred
to by earlier sections) suggests that such proxies always add the Meter
field, thus increasing network overhead merely to sustain the possibility
of the metering tree.

>3 Design concepts
>...
>   No proxy is required to implement hit-metering or usage-limiting.
>   However, any proxy that transmits the Meter header in a request MUST
>   implement every unconditional requirement of this specification,
>   without exception or amendment.
>
>   This is a conservative design, which may sometimes fail to take
>   advantage of hit-metering support in proxies outside the metering
>   subtree.  However, it is likely that without the reliability offered
>   by a conservative design, managers of origin servers with
>   requirements for accurate approximations will not take advantage of
>   any hit-metering proposal.

In other words, it is a design that forces the proxy (with or without
cache) to advertize metering support, rather than using the existing
extensibility of the Cache-Control field to allow the origin server
to state its requirements for metering explicitly.  The alternative
design that is not mentioned is to introduce a metering cache-directive
that modifies the semantics of the "private" or "s-maxage" directives, e.g.

    Cache-control: s-maxage=0, meter="..."

in a response, wherein a cache that recognized the meter directive could
ignore the s-maxage directive.  The advantage of the alternative is that
it does not add "Connection: Meter" to every proxied request, it does not
require the proxy to modify the response, it does not break when a non-caching
proxy is in the chain, and it has zero impact when "cache-busting for the
sake of metering" is not an issue.  The disadvantage is that it reveals
the origin server's intentions for busting the shared cache.

The proposal assumes that the impact of a MUST requirement in a proposed
standard will be sufficient to establish trust, since it allows the
origin server to hide behind a veil of otherwise important cache-control
directives.  I believe that network applications exist to perform a
service, and that the requirements of that service will not be altered
by a MUST requirement in a specification that has nothing to do with
interoperability.  The applications will find a way around those
requirements, or simply ignore them, if doing so results in better service.

>5.2 Abbreviations for Meter directives
>   To allow for the most efficient possible encoding of Meter headers,
>   we define abbreviated forms of all Meter directives.  These are
>   exactly semantically equivalent to their non-abbreviated
>   counterparts.  All systems implementing the Meter header MUST
>   implement both the abbreviated and non-abbreviated forms.
>   Implementations SHOULD use the abbreviated forms in normal use.

Then don't define any non-abbreviated form!  This is a network protocol,
not a user-readable treatise.  Long header field names are often necessary
to avoid conflicts with other names (and protocols); long field values
are never useful unless they contain data intended to be read by a
human being, which is clearly not the case here.

There is also a great deal of unnecessary duplication in the specification.
Some of the meter directives are actually defined in three different
locations, four if you include the abbreviated forms.

When the proposal is ready for publication as an RFC, it should be
assigned Experimental status until such time as the overhead placed on
proxies is *demonstrated* to be offset by the benefit gained by caching
responses that would otherwise have been busted for the sole purpose of
gathering hit counts.  In particular, no Internet proxy should activate an
implementation of this proposal until there exist some deployed origin
server implementations.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-1715
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 16 July 1997 22:59:53 UTC