RE: Is the ability to disable flow control really needed?

I fail to see the issue with the current draft. Did you see section
http://http2.github.io/http2-spec/#fc-principles


that answer the questions about whether disabling (or doing anything at all) on flow control affects one direction or both directions. That section clearly states that flow control is unidirectional. Flow control is controlled by the receiver. When the receiver turns it off, or sends a window update, or whatever, this only affects the incoming direction to the receiver. The sender MUST heed whatever the receiver says.

Is there something that still needs clarification in that section?

So, for example, if a browser turns off flow control, it is telling the next hop (an intermediary or server) to send as much as he wants. But if the next hop tells the browser to regulate its sending via flow control, the browser MUST heed it.

I think having the big knobs to turn off flow control on a per-stream or per-connection basis is preferable to “turning off” flow control via the chatty and dynamic game of sending window updates to constantly open the window.

At any rate, I think the current mechanism is fine for this implementation draft, perhaps with minor clarification.

From: Fred Akalin [mailto:akalin@google.com]
Sent: Friday, June 21, 2013 6:27 PM
To: Jeff Pinner
Cc: William Chan (陈智昌); Roberto Peon; Martin Thomson; HTTP Working Group
Subject: Re: Is the ability to disable flow control really needed?

I feel like since clients have to implement flow control anyway (to respect the server window) that if we give clear instructions on how to "effectively" disable flow control (send INITIAL_WINDOW_SIZE to max value, send WINDOW_UPDATE frame for max value - 64KB), perhaps replacing the existing section talking about the flag, that they'll do the right thing.

I feel like if a client is naive enough, it might even forget to set the DISABLE_FLOW_CONTROL flag, anyway. There's only so much we can do!

-- Fred
On Fri, Jun 21, 2013 at 6:15 PM, Jeff Pinner <jpinner@twitter.com<mailto:jpinner@twitter.com>> wrote:
You could do that:

Send an INITIAL_WINDOW_SIZE setting to the max value, but that won't effect the session window, so for that you'd have to send a WINDOW_UPDATE frame that's set to max value - 64kB, and then you can send subsequent frames after half-consumed.

I'm worried that naive clients won't do anything but use the default values. What do the client guys think?