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

Re: Sticky stuff.

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 10 Aug 1996 00:12:10 +0200 (MET DST)
Message-Id: <199608092212.AAA19354@wsooti04.win.tue.nl>
To: Paul Leach <paulle@microsoft.com>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, hallam@etna.ai.mit.edu
Paul Leach:
>
>There were several problems with your analysis, some of them pointed out
>at the time it was first posted.
>
>1. It didn't include the effects of Accept-Language, Accept-Encoding,
>Accept-Charset, or From (or Host, but it didn't exist at the time).
>These can add to the average request size. So could future headers added
>to HTTP.

I calculated the `500 byte scenario' to take such things into account.
Even this scenario showed no impressive improvements.  It would be
good to measure the average request size for today's clients, but I do
not expect large increases compared to a year ago.

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

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

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

[...]
>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.  I therefore see no reason for
sticky headers to become a WG activity at this point.

Koen.
Received on Friday, 9 August 1996 15:14:17 EDT

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