Re: #541: CONTINUATION - option #4

Hey Willy,

On 7 Jul 2014, at 6:54 pm, Willy Tarreau <w@1wt.eu> wrote:

> Hi Mark,
> 
> making a quick comment about this below :
> 
> On Mon, Jul 07, 2014 at 06:10:25PM +1000, Mark Nottingham wrote:
>> Thinking through deployment scenarios --
>> 
>> a) Imagine a forward proxy that has a single connection to the user agent.
>> Each time the UA requested an origin that necessitated a new connection, the
>> proxy would have to advertise a new, lower request MHS if the origin
>> advertises one less than the current client connection's. It could only raise
>> the UA->proxy request MHS again when that connection is no longer in use by
>> the client (and it'd likely need to use some heuristic to figure this out).
>> This isn't great, because you're effectively getting the smallest MHS you're
>> currently connected to (for some value of "currently"), and it's dynamic.
> 
> I think you're mixing two sides. Here the proxy does not have to impact one
> client's MHS depending on the other ones. At best it would impact the MHS on
> the connections to the origin server. The MHS is a property of the connection
> and does not have to be transferred between the two sides (better, must not).

I'm not sure I buy that. If I connect to a proxy and its request MHS is bigger than the next-hop's request MHS, I'll send requests assuming the first. 

It's true it doesn't have to be in lockstep, but there are consequences they're if not (as I talked through).


> From this point on, the proxy can decide whether or not some client connections
> may be coalesced to the origin server. If one is watching a video while another
> one is loading some CSS, it's likely that we'll make better use of at least two
> connections. Just like we'd prefer to have two if one is watching a video at
> 16kB data frames while someone else is doing some very interactive stuff like
> using a WYSIWYG editor or simply benefiting from auto-completion on a search
> engine.
> 
> Thus I'm pretty sure that forward proxies (and probably reverse proxies as
> well) will try to assign streams to connections based on some form of QoS.
> If it has to be done for data, for sure it will be needed on headers. Imagine
> the large number of small companies still running on ADSL with 4M/1M or so,
> you definitely don't want there to have one user sending large cookies over
> the connection and block the stream for all other users for the time it takes
> to send a huge 16kB of headers.
> 
> So MHS can help the proxy take the proper decision as well.

I suspect some intermediaries will end up grouping requests from different connections together by MHS.

I wonder if any sort of MHS setting is better-off being something coarse-grained (e.g., aligned on 1k or 4k) so that you don't have peers doing weird things like advertising 423 byte MHS, thereby screwing things up...

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 7 July 2014 09:00:23 UTC