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: Thu, 8 Aug 1996 14:23:35 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960808212335Z-12970@INET-01-IMC.itg.microsoft.com>
To: "'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: 	hallam@Etna.ai.mit.edu[SMTP:hallam@Etna.ai.mit.edu]
>Sent: 	Thursday, August 08, 1996 1:07 PM
>To: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	Sticky stuff. 
>
>
>
>Some comments on the sticky headers draft:-
>
>1) The asymmetry between the client/server responses may be due
>more to the current limited way in which HTTP is used than a
>feature of the problem itself. If we get servers which can implement
>the PUT and POST mechanisms then I think that the situation might
>well change.

I don't understand this. Accept-* headers (for example) are always
request headers, and only clients ever send them, even on PUT and POST.
So I don't know how increased PUT and POST popularity would change the
asymmetry.
>
>2) I'm not sure of the amount that these proceedures buy us. It
>would be nice to have figures. 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. On low speed dial-in lines,
compressing later packets still helps.
>
>I suspect that the control data is not a substantial fraction of 
>the total message size.

It is for GET requests -- there is no data.

> It may be more effective to push on
>people to implement compression/decompression of message data
>rather than to worry overmuch on the size of the control data.
>Or at the very least point out this issue in the draft.

Sure.
> 
>3) Section 2.2 asserts that proxies typically multiplex server
>connections across multiple clients. Is this in fact the case?

>My wording was ambiguous. The "typically" referred mostly to the fact that
>they acted on behalf of many clients. In practice today, probably not many
proxies implement persistent connections, so they obviously can't
>multiplex them. In the subWG meeting on persistent connections, I recall
>comments to the effect that persistent connections would be good for proxies,
>who could keep them open to servers longer because they would be merging
>requests from many clients.

>What is the actual benefit of doing this? 

The connection does not have to be reopened.

>How often do two
>people from the same site wish to connect to the same remote site
>simultaneously?

 It doesn't have to be simultaneuously -- just near enough in time to
>make it worth keeping the connection open,
>
>I am very skeptical about people having implemented such a 
>feature in a multi-process server where the interprocess communication
>overhead would be very large for the payoff. Certainly
>the phrase "typical" does not seem appropriate. I could see it
>being possible in a single process, multi-thread server. I
>would like to see figures showing how often this case came up
>before compromising other optimisations to adapt to this
>complication.

What other optimization was compromised?
>
>I point out this problem because much of the complication of 
>the spec appears to be working arround this convergence of
>independent sessions into a single stream.

How so? A second context is created just like the first one, with the
addition of specifying the context number.
>
>
>On the other hand there may well be a number of proxies performing
>usefull work undoing the effects of simultaneous connections
>for image downloads. In this situation combining 4 streams from
>one anti-social browser into one is quite plausible, but note that
>in this case the headers will probably be compresssable!
>
>
>4) The sticky header and possibly the connection header should be 
>explicitly excluded from the set of sticky headers (!)

Good point.
>
>5) Section 6.
>
>This section should note that "replay attack" problem will always
>be present whenever the compression technique is possible. If
>an authentication technique authenticates the message itself then
>it will have to be a function of the message body and hence not
>"sticky-able".

I don't think so -- the authentication should be applied before the
sticky compression. Maybe I just don't understand this point.
>
>6) Some mechanism for flushing the header cache would be usefull.
>This would help in the multiplexing proxy server case. After 
>it is finished receiving input from one source the proxy can send
>a "flush" message and reset the stream.

OK.
>
>Overall I would like to see an awfull lot of numbers based on 
>empirical measurement before deciding whether this is a 
>worthwhile scheme or not. Although it looks OK to me I know
>from experience that without hard numbers it is very easy to
>overoptimise corner cases that almost never occur.

Anybody have traces? The usual log doesn't have enough data to see what
the improvement is, I suspect. Also, the presence of the mechanism may
alter behavior -- instead of sending tailoring the Accept header value
based on the URL's extension (.html, .gif, etc) to save space, the
client could just create on big Accept that they send once and then omit
therever after.

I have logs from our proxies that can measure the interval between
consecutive references to a single site to see it pays for a proxy to
keep a connection open to a server after a client is done with it.

Paul
>
>
>
>
>
>
>
>
>
Received on Thursday, 8 August 1996 14:25:21 EDT

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