Re: Sticky stuff.

Paul Leach:
>>From:  koen@win.tue.nl[SMTP:koen@win.tue.nl]
>>>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.

I'm not a specialist in modem technology, but AFAIK modems offer you a
constant amount of bandwidth both ways.  So savings on the request
stream will not get you more bandwidth on the response stream, which
means that the savings matter even _less_ than on a LAN.  My wait
chain calculations will _over_estimate the speedup in the modem case,
assuming that the modem is the bottleneck.

As for the high RTT on some of Digital's internal links: RTTs are
irrelevant for this discussion.  If anything, they will make the
savings less noticable.  If Digital's internal links were highly
_saturated_, that would be another thing.

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

The compression ratio varies depending on what you try to compress.
Have you ever gzipped a httpd logfile?  If the same effect happens
with modem compression, Jim will learn something about how HTTP works
very soon.

>Paul

Koen.

Received on Monday, 12 August 1996 14:12:22 UTC