Ted Hardie's comments on draft-mogul-http-hit-metering-01.txt

I'm sorry it's taken me more than two weeks to reply to Ted's comments;
as I told him at the time, I have been dealing with too many deadlines
that couldn't be postponed.

    For readability, I would move the section in 1.2 which describes what
    cache-busting includes into the Introduction; I believe it would help
    clarify what problem is being addressed.

I'll consider that, but it's not clear that there is any ordering
that would lead all readers to a full understanding of the document
in a single pass.  The immediate audience for the I-D is this working
group, and anyone who doesn't already know something about the specifics
of cache-busting has more reading to do.
    
    It's not clear to me what "no additional network round-trips in any
    critical path" means--where is definition of "critical path" in this
    context?

Sorry, I guess this is CS jargon that might not be universally understood.
In systems (such as the Web) where latency is at issue, there is usually
a tree of steps which depend on one another, in such a way that the
final result cannot be accomplished until all of its predecessors have
been.  Since the tree structure admits some parallelism, it isn't necessary
to add up the timings for each step to discover the latency for the entire
process.  But any single path through this dependency tree cannot be
parallelized, and the longest such path is the one whose length (in
units of seconds) determines the overall latency.  This is the "critical
path", because no matter how much shorter you make any other path,
that doesn't change the overall latency for the final result.

If you view the final result, for a Web request, as rendering
a page at a browser, or otherwise acting on the result of a request,
clearly some network round trips (e.g., exchanging TCP SYN packets
if the connection doesn't already exist) are on the critical path.
The hit-metering design does add some round-trips for reporting
non-zero counts when a cache entry is removed, but these are off
any critical path, by design: they may be done in parallel with
any other operation, and are "best efforts" so one doesn't have to
serialize other operations with their success or failure.

If you want, I could change that to say:
   These new non-mandatory features require ...
   no additional network round-trips in any critical path that
   directly affects user-perceived latency.

Clearly, anything that changes network utilization (either increasing
or decreasing it) can *indirectly* affect user-perceived latency.
Our expectation is that hit-metering, on average, will reduce loading
and so its indirect effects do not add "network round-trips in any
critical path."  But there might be a few specific instances where
the added "non-critical-path" operations get in the way of an operation
on a critical path.  Such is life in datagram networks.
    
    In your design question in section 3.1, you note that having the
    origin server add the "Cache-control: proxy-mustcheck" to the response
    would get the proxies out of the business of adding headers to
    responses, and I think that this a very good thing.  I am concerned,
    though, about exactly how to define the Connection: proxy-mustcheck
    (or max-age=0) header in that case, since the proxies' behavior varies
    (depending solely on a Meter offer and Meter response? or those and
    others?)  In particular, how does this affect the behavior of the
    proxies when the server sends a Meter: header without having had the
    proxy volunteer (see Note in Section 3.3 near the bottom of page 11)?

We already have the statement (near bottom of page 12):
   A proxy that receives the Meter header in a request may ignore it
   only to the extent that this is consistent with its own duty to the
   next-hop server.

We could add something (somewhere before this) such as:
	A server MUST NOT send a Meter header that would require
	a proxy to do something that it has not yet offered to do.

Together, these two statements imply that a proxy receiving a Meter
header that asks it to do something that it didn't volunteer for
may safely (should?) ignore it.

I suspect that when you write "Connection: proxy-mustcheck"
you mean "Cache-control: proxy-mustcheck", which we'll presumably
end up expressing as "Cache-control: proxy-maxage=0".  At any
rate, I'm not sure what you think is ambiguous about this
statement in the draft (with "proxy-maxage=0" inserted):

   When a proxy forwards a hit-metered or usage-limited response to a
   client (proxy or end-client) not in the metering subtree, it MUST
   omit the Meter header, and it MUST add "Cache-control: proxy-maxage=0"
   to the response.

There is no dependency here on anything not explicity specified
in the proposal, is there?
    
    As I noted on previous drafts, I'm unsettled with the idea of the
    proxies' first use of this header being defined as applying to all
    subsequent requests made on the given transport connections; I
    appreciate the implementation advice, but I still believe that the
    problem should be solved generally.  If we do come to a general
    solution of "sticky" headers and it doesn't match this model, we have
    a serious piece of cruft.  How important is it not to repeat these
    particular bits on the wire?  I would much rather limit the bits by
    including only the abbreviated forms of the directive and responses
    than by making a de facto sticky header.

I could take the view that the "sticky" headers and abbreviation
mechanisms are simply minor performance optimizations, and therefore
are separable from the rest of the proposal.  But because some people
do have concerns about the wire overhead added by the hit-metering
proposal, it would be nice to know whether the people who are worried
about overheads are for or against these two optmizations.  (While
you are willing to accept the directive abbreviations, Koen apparently
is not, even though he does complain about "efficiency loss".)

I'd also like to point out that my co-author on the hit-metering
draft did indeed make a generic proposal for abbreviations and
stickiness (in early August 1996), and was treated rather badly
by the WG for his efforts.  I'd feel a bit more sympathetic about
complaints that this stuff should be generalized if the people
making those complaints had been more supportive of Paul's proposal.
Or if some of these people (you, Ted, are not at all the only one)
would go ahead and promote a specific proposal.
    
    As an editorial thing, I think that the "Note on the limit on 'uses'"
    text in 3.3 needs to be incorporated fully into the text and flagged
    in big, bold letters.  You may also want to think about what this
    means for the interpretation of a Meter: count=0/0 report in the
    presence of pre-fetching.
    
Well, we say
   A proxy SHOULD NOT transmit "Meter: count=0/0", since this conveys no
   useful information.
I guess you are saying that this might convey useful information
if the proxy does a prefetch that it never uses?   Would you like
to propose a solution that doesn't burden prefetching with a lot
of extra messages?

I've been doing quite a lot of my recent research on the topic of
prefetching, which I think will be important in the long run.  But
it's clear that there is a complex tradeoff between improved latency
and increased network loading, and it's not at all clear at this
point how to even define the criteria for this tradeoff, let alone
how to optimize them.

    I think section 8 needs to reference Koen's draft on multiple
    variants and it may need to define what to do in border cases.  If,
    for example, a meter-willing cache offers a list of variants to a
    an end-user and it declines all of them, should that be reported?
    
I would appreciate it if someone who (1) understands Koen's draft
and (2) is not opposed to the hit-metering proposal in general would
take a stab at suggesting some specifics here.

    I think section 8,the note on capturing referrals, doesn't seem to
    belong in this draft, unless the scope is larger than the goals
    statement implies.
    
I'll discuss this with Paul.  You're right that it is no longer
central to the proposal.

-Jeff

Received on Tuesday, 18 February 1997 15:10:31 UTC