W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

RE: Sticky stuff.

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 9 Aug 1996 17:26:48 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960810002648Z-18604@mail.microsoft.com>
To: "'koen@win.tue.nl'" <koen@win.tue.nl>
Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'hallam@Etna.ai.mit.edu'" <hallam@etna.ai.mit.edu>


>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Subject: 	Re: Sticky stuff.
>
>
>>2. It was taken between proxy and server, 
>
>This is because the internet backbone links are the bottleneck, not
>the LAN between your proxy and your user agent.  Who cares if you get,
>say, 30% savings in web traffic on the LAN?  In this game, it is
>backbone savings that count.

Not everyone has a LAN link between user agent and proxy. Some small
number of people dial in to their proxy, which is owned by  their
service provider. Say order 10 million or so, with providers like AOL
and MSN.
>
>>where the effect of 304 (Not
>>Modified) is not seen. (The low % in headers in your because the average
>>response entity-body was ~10,000 bytes. In a 304 response, the
>>entity-body size is 0, so the savings in request header size is more
>>imprtant).
>
>I still have my original datasets, and just ran some new statistics on
>them.  In proxy<->outside server traffic, 200 responses made up 82% of
>all responses, and 304 responses 4%.

Again, I was talking about user-agent to proxy traffic, and the 304s
that would arise when the user-agent had something in its cache that it
needed to revalidate.
>
>[...]
>>3. It didn't consider asymmetric bandwidth situations. In the limit that
>>the downstream connection is infinite in speed and with low latency, the
>>savings of 80% in request header size that your study used would be
>>significant. (The most likely early deployment of cable modems will use
>>ordinary telephone lines as the request channel.
>
>And the modem hooked to the ordinary telephone line will probably do
>data compression, so you would gain little extra with sticky headers,
>I believe.

In your model, a 200 byte request would be reduced by useing sticky
headers to 40 bytes, and then the 40 bytes would be compressed to (say)
20 bytes (assuming a 2-1 compression ratio). Without sticky headers, and
the same compression ratio, requests would be 100 bytes. The savings
from sticky headers is still the same 80%. 
>
>[...]
>>I think a new study would be needed to take these effects into account
>>before we can conclude that sticky headers aren't worth the effrort.
>
>I agree.  To get something like a firm conclusion, at least one other
>study is needed.  My study was done a year ago, with a small sample
>(145 Mb of traffic), and by someone who is not a statistician.
>
>However, I think there is enough data to conclude that sticky headers
>are *unlikely* to be worth the effort.

Seems to me that there is enough data to show that it won't help much in
your environment.
In other environments, it's at least not so clear-cut.

Paul
Received on Friday, 9 August 1996 17:28:57 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:06 EDT