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

Re: BLOCKED frame specification

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Wed, 16 Apr 2014 18:37:26 -0700
Message-ID: <CAA4WUYg1e9NZPPdTE-KGwte1nVJPL1woPNw75hZBnPA1MF0usg@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>
On Wed, Apr 16, 2014 at 6:27 PM, David Krauss <potswa@gmail.com> wrote:

> On 2014-04-17, at 1:02 AM, Roberto Peon <grmocg@gmail.com> wrote:
> > Flow control is hop by hop, not end to end, and so all we care about is
> detecting the hop-by-hop flow control issues.
> > Specifically, we care about detecting when the remote side could not
> send because its flow control window was zero.
> But how do you know that the first hop is the one with blockage? The first
> rule of debugging is that a problem may be anywhere. If you're testing
> interoperability with an external site, you certainly don't know what's on
> their end...
> Apologies, I was thinking of blockage due to the dependency hierarchy, not
> flow control. Flow control stalls should frankly never happen. Flow control
> is supposed to improve reliability, and if it has bugs then the protocol is
> too complicated. When was the last time TCP flow control stalled an
> application? Anyway, any blockage-diagnosis facility would probably be more
> useful if it covered all possible root causes.

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:

> I'll try and propose a flow control simplification today, which would
> outlaw throttling after a stream is in progress but still allow 100
> CONTINUE emulation.
Received on Thursday, 17 April 2014 01:37:54 UTC

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