Re: BLOCKED frame specification

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:
https://www.belshe.com/2010/11/19/linux-client-tcp-stack-slower-than-windows/
.


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