Re: BLOCKED frame specification

On Apr 17, 2014, at 4:48 AM, 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.

It’s not necessarily a hang. It’s also possible that the client is sending WINDOW_UPDATE frames, just not sending them soon enough. Suppose the RTT is 0.5 seconds and bandwidth is 10 Mbps. If the client lets the window get down to 500 KB before sending the WINDOW_UPDATE, there could be 2.5 Mb (313 KB) en route, and within the 0.25 second it takes the WINDOW_UPDATE to reach the server, the window will empty. 

That’s the kind of thing a BLOCKED frame might help detect.

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