W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: H2 HEADERS and flow control

From: David Krauss <potswa@gmail.com>
Date: Fri, 4 Jul 2014 15:18:22 +0800
Cc: Nicholas Hurley <hurley@todesschaf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <526B695B-3964-4590-BCE9-0E27293C5417@gmail.com>
To: Greg Wilkins <gregw@intalio.com>

On 2014Ė07Ė04, at 1:54 PM, Greg Wilkins <gregw@intalio.com> wrote:

> Whilst what I'm advocating could be somewhat implemented by self control/priorty I don't think it can entirely be done so, and certainly not just by the server.
> Currently a browser that has just sent a 64KB header is free to immediately send another 64KB of data without any say so from the server.  This will effectively give that client twice the share of any shared connections from load balancer to app server vs a browser that sends small headers.

Too many requests is exactly what ENHANCE_YOUR_CALM is for. Itís not supposed to happen under normal conditions, i.e. itís an indication of trouble.

> If the header size was included in the flow control calculations, then the browser would have to wait for a WINDOW_UPDATE after sending a 64KB header before it could send any data.   It would thus be only able to take the same share of any amalgamated connection as a small header sender.

TCP window updates do the job youíre asking for. The load balancer should simply delay reading the delinquent socket at the time it sends or forwards ENHANCE_YOUR_CALM.

To be sure, this sucks for other users sharing the same client-side proxy (assuming it aggregates connections). But that raises doubt of whether equal sharing of server resources is a useful goal in the first place.
Received on Friday, 4 July 2014 07:19:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC