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

Jeffrey Mogul:
>
>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".)

What I complained about was:

 The stickiness and header compression (header abbreviation) should
 largely be cut -- this stuff just generates a lot of code, and the
 efficiency savings in no way compensate for the efficiency loss due to
 the extra requests and the cache busting outside of the metering
 subtree. 

Let me clarify my position. My main efficiency worry is:

 If many people, who do not use cache busting now, start using hit metering,
 then caches _outside_ of the metering subtree will have to do much more
 revalidation requests, which means more RTT overheads and a slower web.

In one particular doom scenario, someone would write an experimental hit
counting apache module, and thousands of clueless server operators would
remove comments in a makefile and end up enabling it for each and every
resource, without even realising that they have done so.  Something like
this has happened before with an experimental user tracking module.  

I would like to have very extensive and careful applicability statements in
the draft to reduce the risks of such scenarios.  I would rather not have
any standards track demographics spec, than a hit metering spec with bad
applicability statements. (And the statements in the current draft are even
beyond mere badness.)

I'm not worried at all about a few more bytes in headers.  Headers are no
big factor.  I have age-old statistics to back this up:
http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0261.html

Like Ted, I _am_ concerned that introducing a single sticky header will
reduce the usable lifetime of HTTP/1.x as a protocol suite.  You can only
add so much features before you drown in feature interactions.  Some of this
is already visible in your section 5.5.

I think that the header abbreviation you have is ugly, but I could live with
it.

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

My main complaint about Paul's stickyness proposal has always been timing:
there are plenty of optimisations which have higher gains (entity
compression is one of them), and which deserve to be implemented first.
Eventually, it will pay to get more specific about stickyness.

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

Jeff, reading my draft won't kill you.  Many people did so and lived.

As a first approxymation, I think TCN and hit metering won't explode when
mixed together.  If you specify (in an appendix or something) what kind of
hits a hit-metering-and-TCN proxy should report when performing the first
two of the three optimisations in section 13 of the TCN draft, you should be
home free.  The Vary stuff in the hit metering draft will ensure accurate
reports in all other cases.  Much simpler Vary stuff would too, by the way,
but that is another issue.

>-Jeff

Koen.

Received on Sunday, 23 February 1997 09:52:25 UTC