Re: Explicit revocation

[Sorry abt the prev bogus reply]

> Having explicit revocation is a good thing, but I agree with others
> that it is too complex/unexplored to get it into HTTP 1.1

Agreed; I only want it so as Larry said, that we don't make it NOT
possible as a further extension.  Like, define Cache-control: and such
so that they're extensible and don't barf if you have a not previously
enumerated value.

> 60% savings in connections and 75% savings in bandwidth????  I am a
> bit disturbed by that figure, it is highly atypical.

Those were "up to".  But there _are_ sites with those figures -- there
is log analysis data to support that.  Those sites run with 2-3 GB
cache, and several thousand users.  With that setup, however, it's not
unlikely to reach those figures, I know of several sites.

> The paper `Caching Proxies: Limitations and Potentials' at
> http://www.w3.org/pub/Conferences/WWW4/Papers/155/ concludes:
> 
> |1.  We confirmed previous data in the literature that a caching proxy
> |    has an upper bound of 30-50% in its hit rate, given an infinite
> |    size cache and an eight day cache purge interval.
> 
> I have measured a fairly constant 30-40% hit rate and 30-40% bandwidth
> saving at our proxy cache.

The "upper bound" is a foggy term, as there really isn't any hard
upper bound.  It also depends on the server software; with CERN proxy
it really seems to be limited to 30-40%, but with Netscape's it's
common to reach better than 40%, and not uncommon to be even above
60%.  Yes, you do need 2-3GB disk for that.

> Are you sure that your figures are for a cache that caches _outgoing_
> http requests, i.e. request made by your local users to WWW servers
> not on your local network?

They're a mixture; typically most are outgoing, though, only some in
local network.

> I'm sorry to be so negative, but I have serious doubts about caching
> schemes in proxies being able to reduce internet traffic with more
> than 50%.

They can do even better than the numbers I quoted once servers start
doing Cache-control: and let the proxies get rid of some of those
unnecessary conditional GETs.

  Some people have argued that the exponential growth of web
> traffic makes is _necessary_ for caching proxies to reach hit rates of
> at least 95%, but I see no way in which caching technology to provide
> such an exponential improvement.

I have a strong belief that 95% is not hard at all to achieve.  The
active set of documents doesn't grow exponentially, even if the total
amount of content out there does.  As new content gets added, the
older stuff will also be phased out and forgotten.

> On a related note, I recently discovered that the Netscape client
> cache, if configured to `verify document: every time', will indeed do
> a conditional GET for every new request on a resource that lacks an
> Expires header.

As Jeffrey pointed out, Expires: is hardly ever there.  Netscape has
to be realistic about what it does.  If the feature didn't work the
way it currently does, it would be tagged "broken" by most users.

> I hope you are talking about not always performing conditional GETs on
> resources that are not expired here.  It would be _very bad_ for a
> cache not to relay conditional GETs on documents that are expired.

Conditional GET's are a Good Thing.  Yes, I just meant that
unnecessary ones are, well, unnecessary, and should be reduced when
possible.

> I conclude that we should first focus on reducing the number of
> _unnecessary_ conditional GETs by giving some guidelines in the 1.1
> protocol.

Agreed!

Cheers,
--
Ari Luotonen				ari@netscape.com
Netscape Communications Corp.		http://home.netscape.com/people/ari/
501 East Middlefield Road
Mountain View, CA 94043, USA		Netscape Server Development Team

Received on Saturday, 30 December 1995 01:32:24 UTC