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

Re: BLOCKED frame specification

From: 陈智昌 <willchan@chromium.org>
Date: Wed, 16 Apr 2014 18:50:28 -0700
Message-ID: <CAA4WUYg0X95r8zObKdLSpJsdzp0aOfiC9-kK66+Qp=yGauLq1w@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
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>
OK, just to be clear, I'm more worried about slowness/tuning than outright
hangs. If things hang, people are going to file bugs and maintainers of
major software projects are going to fix those issues. What's more
worrisome is non-obvious issues like performance tuning.


On Wed, Apr 16, 2014 at 6:48 PM, David Krauss <potswa@gmail.com> wrote:

>
> 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:50:56 UTC

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