Re: Non-persistent Cookie proposal

Brian Behlendorf:
>
>On Sat, 12 Aug 1995, Koen Holtman wrote:
>> James Gosling:
>> >One of the most important axis for evaluation of *any* protocol is how
>> >it scales.  All of the stateful dialog proposals that I've seen on this
>> >list score very low on this.
>> 
>> Both my proposal and (I believe) the one by Dave Kristol intend to
>> provide *some* minimal support for stateful dialogs as soon as
>> possible, not to be the ultimate stateful dialog solution.
>
>How the designers intend a protocol to be used, and how the users end up
>using it, can be drastically different.  The protocol designers should be
>aware of what people would want to use their protocol for.

I violently agree.  Note that my Cookie proposal *does* address such
`protocol abuse' issues.

[....]
>So the question is - should we build in mechanisms to discourage
>statefulness, while still allowing it,

I don't want mechanisms to discourage statefulness, I want mechanisms
to discourage the disabling of caching for frivolous reasons.

> or should we wait until cache managers
>start denying access to particular hosts?

I don't expect the average cache manager to start denying access based
on the output of some advanced cache statistics tools.  If there is a
need to reduce web traffic costs, I expect a much less subtle course
of action, i.e. `tuning' the Expires header, which also impacts on the
well-behaving (stateful dialog) sites.

What we really need are at least two cache disabling methods, say

  Pragma: frivolous_no_cache
  Pragma: useful_no_cache

and some mechanism to discourage frivolous use of the second one.
This way, cache operators that need to reduce IP traffic can start by
breaking frivolous caching only.

>  I would like to work towards a
>model where as little state as possible travels over the connection, and is
>only sent when needed, hopefully less than 10% or even 3% for the most
>stateful application.

This is a desirable *second* goal, and both current proposals address
this goal to some extent.

By offering alternatives to session-id-in-the-url hacks (30% cache
efficiency: only inline pictures can be cached) and authentication (0%
cache efficiency: caches are required to be transparent) as
implementation techniques for stateful dialogs, both Dave's and my
proposal can improve caching of stateful dialogs to, say, 80%,
depending on how many responses in the dialog depend on the state.

Improving the efficiency from 80% to 90% or even 97% by using Java or
somesuch is not that important as long as
 - the amount of stateful dialog traffic is small, say 20% of the
   total web traffic
 - average cache efficiency is less than 80%.

(Note: I have no idea how efficient the average cache is nowadays, and
I would love to see some statistics about this.)

With these made-up percentages, we get:

State-Info or non-persistent cookie: overall caching efficiency
improves by ( 80% - (0%+30%)/2 ) * 20% =  13%

Java-like stuff:overall caching efficiency improves by
            ( 97% - (0%+30%)/2 ) * 20% =  16.4%

Thus, waiting for Java gets us 3.4%.  What we really should be talking
about is the percentage to be gotten by eliminating frivolous caching.

>  Java is crucial for this, but a better model for
>building client-side information bases is what's really on order (a la Paul
>Burchard's ideas).  Koen's and Dave's proposals have those critters flying
>across the wire an *awful* lot. 

As long as stateful services generate only a small part of web traffic
this *awful* lot has not that much overall impact.  Also, note that my
proposal does not require proxy caches to always forward the
State-Info/Cookie header.

I think the biggest (web) bandwidth eaters today, and in the future,
will be picture, sound, and mpeg sites.  What you should really worry
about is such sites going commercial and starting to send their stuff
in an encrypted form to paying customers, not about stateful services
getting more common.  Do you want to stop the development of shttp?

I think it is too early to attempt making `better models for building
client-side information bases': lets wait until stateful dialogs on
the web become more common, only then will we be able to get a good
idea of what client side provisions are actually needed.

[...]
>Furthermore applications like Internet 
>Phone and CUSeeMe will put pressure on the backbone providers to start 
>metering their IP traffic - when that happens it will *definitely* hit 
>home that having local caches of information is a Very Good Thing.

If Internet Phone and CUSeeMe become really popular, this would in
fact decrease the need to push Web caching to the limit.

[...]
>> I don't think that Java
>> browsers will be generally available, and, more importantly, generally
>> used by more than, say, 90% of web users for some years to come.
>
>Um, a lot of people doing a lot of relevant work are a lot more optimistic
>about that.  There is a press release on home.netscape.com you should look
>at.

Well, I said 90%, not 70%.  We may get 70% within a year (though I
won't hold my breath), 90% will take considerably longer.  Some
illuminating statistics about people upgrading their (Netscape)
browsers were posted here some time ago.

And anyway, I do not expect Java (or anything that gets press releases
on home.netscape.com, for that matter), to lessen the overall
bandwidth use by the web.  If anything, Java will create a whole new
class of bandwidth-consuming interactive multimedia applications
(grapical MUDs via your web browser, anyone?).  The Internet will
continue to survive nevertheless.

>        Brian

Koen.

Received on Sunday, 13 August 1995 06:09:57 UTC