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

Re: BLOCKED frame specification

From: David Krauss <potswa@gmail.com>
Date: Thu, 17 Apr 2014 09:48:12 +0800
Cc: Roberto Peon <grmocg@gmail.com>, Johnny Graettinger <jgraettinger@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>
Message-Id: <920013E6-C7CC-4547-A94E-0EF2736B3988@gmail.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>

On 2014–04–17, at 9:37 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> TCP flow control often stalls applications. Especially when networks strip out window scaling (this definitely happens, but I unfortunately have no public data to share here). And then there's the historical issue with Linux receive windows being too small by default: https://www.belshe.com/2010/11/19/linux-client-tcp-stack-slower-than-windows/.

That’s gonna make it slow, not stalled. I gather that the condition of present concern is when a client accidentally allows the window of a particular stream to go to zero, due to intentionally failing to send receipts as a throttle control. The client screwed up the accounting and gets confused.

However it can also occur upstream by an intermediary that fails to anticipate all the corner cases of such client-initiated throttling to prevent its intermediate windows from glitching to zero. (At least, I anticipate this, I haven’t yet worked through a blow-by-blow example.)

The solution is not to use flow control for relative throttling but priority instead. Don’t play with fire!

Received on Thursday, 17 April 2014 01:48:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC