RE: Sticky stuff.

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.

2. It was taken between proxy and server, 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). Between the user and the proxy, there could be a significant
number of 304s. As user-agent caches get bigger, there would be even
more 304s (everything else being equal).

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. Phill points out that
if other latencies are significant, then header size savings won't
matter much -- but these kind of cable modems are pretty close to the
infinite speed, low latency model.)

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.

>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Sent: 	Thursday, August 08, 1996 4:12 PM
>To: 	Paul Leach
>Cc: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com; hallam@Etna.ai.mit.edu
>Subject: 	Re: Sticky stuff.
>
>Paul Leach:
>>>From:  hallam@Etna.ai.mit.edu[SMTP:hallam@Etna.ai.mit.edu] 
>  [...]
>>>2) I'm not sure of the amount that these proceedures buy us. It
>>>would be nice to have figures. 
>
>I guess this is a good time for me to repost the figures I calculated
>almost a year ago.  Look for a message `Statistics on reusing request
>headers in persistent connections'.  The conclusion:
>
> My conclusion is that the gains are too small to bother about request
> header reuse at this point:
>      - HTTP traffic savings would be about 1.3%
>      - speedup of browsing response time would be minimal:
>        page+inline loading times would be noticeably faster in
>        about 17% of all cases.
>
> Much higher gain/effort ratios can be had by focusing on other
> desirable features of future HTTP software, for example [...]
>
>The conclusion still seems to be valid.
>
>>>Jim G. has made good points about
>>>the importance of getting as much usefull information in
>>>the first packet send out (i.e. before we hit the slow start
>>>throttle). This mechanism appears to be aimed more at increasing
>>>the efficiency of later packets.
>>
>>There's not much that can be done about initial packets, unless somehow
>>the negotiation step can be skipped.
>
>If you mean `unless somehow the Accept headers can be left out': you
>can indeed leave them out under transparent content negotiation.  And
>in most requests, you will leave them out.  See Section 11.6
>(construction of short requests) in the conneg draft.  Does the
>request
>
>      GET /paper HTTP/1.1
>      Host: x.org
>      User-Agent: WuxtaWeb/2.4
>      Negotiate:
>
>fit into one packet?
>
>Koen.
>

Received on Thursday, 8 August 1996 18:21:50 UTC