Re: BLOCKED frame specification

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!
>
>