Re: Comments on draft-mogul-http-hit-metering-01.txt

Jeffrey Mogul writes:
> Anyway, I'll drop the sticky-header stuff from the hit-metering
> proposal IF nobody objects to the extra overhead in the requests.
> And if it leads to at least one of the current critics turning
> into a supporter.

Dropping the sticky header stuff eliminates one of the last of
my objections to the current draft.  Provided you are following
Larry Masinter's suggestions about audience, I think you can
count me as "one of the current critics" turning into a supporter.

Through the course of this discussion I have become convinced that
something must be done to encourage sites to drop cache-busting
techniques based on a desire for accurate (or, to be frank, large)
hit counts.  When we started, Sally Hambridge's numbers from Intel
and our own experience at NASA indicated to me that so many
requests were against rapidly changing resources that caching in
general was not ultimately going to be the saving grace many felt
it would be and that the incremental gains that this scheme
represents were not going to be worth the additional complexity
they implied.  Jeff and others have convinced me that position was
wrong and that the reduction in traffic is worth the complexity of
the base hit-metering scheme.  My objections to the sticky header
elements of the current draft have primarily been that they might
prove to be incompatible with a later, general solution and thus
discourage adoption of something which would be a bigger win.  I
realize that eliminating something on the basis of a possible
future better thing is a gamble, but I think it's the right
side to bet on in this case.  Thanks for removing it.

At Jeff's prompting, I went back to Paul Leach's general proposal
on sticky headers and re-read it and the threads debating it.  On
reflection, I believe that we could make the proposal the basis of
a general scheme, but that it too would need to be boiled down to
its basics to demonstrate where the cut off was for a reasonable
return in bandwidth reduction for the investment in complexity.  I
think we might also want to sit down as a group in Memphis and try
think about all of these proposals in the larger context of
layering state on this stateless protocol.  With cookies, we are
enabling servers and clients to create a session state in one way;
with a sticky header proposal, we would be creating a different
method for creating state, possibly between different players
(Even the reporting and usage-limiting mechanisms of the
hit-metering proposal could be considered a kind of "state").
Based on both the discussion of the sticky header proposal and the
discussions of the state management drafts, I think it would be
valuable to sit down and hash exactly when we saw each being used
and go from that discussion to a set of solutions.

		regards,
			Ted Hardie
			NASA NIC




-- 
Ted Hardie			
hardie@nic.nasa.gov

Received on Wednesday, 5 March 1997 15:14:11 UTC