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

I agree that many simple clients may want to not keep track of flow control
windows, and there are good reasons for them not to try. That being said,
Section 3.6.2:

Deployments that do not require this capability SHOULD disable flow control
for data that is being received.

is very different than providing per-stream disabling via SETTINGS or
WINDOW_UPDATE frames. Maybe the thing to do here is to not provide so many
knobs (per-stream / all streams / connection / all of the above) and only
allow the client to turn off flow-control completely?


On Fri, Jun 21, 2013 at 3:49 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 21 June 2013 14:58, Fred Akalin <akalin@google.com> wrote:
> > Reading the "Ending Flow Control" section of the spec (3.8.9.4:
> > http://http2.github.io/http2-spec/#EndFlowControl ), I'm wondering if we
> > even need the ability to disable flow control at all.
>
> This is something that we discussed at some length in the Tokyo
> interim.  Getting flow control right is hard.  An implementation will
> screw itself if it doesn't take a great deal of care.  Flow control
> always costs in performance, at best it just costs the bytes for a few
> WINDOW_UPDATE frames; at worst, you end up with lots of periods where
> you receive nothing but silence.  Of course, the upside is that you
> can get good concurrency without spending infinite amounts of RAM.
>
> This is why we included Section 3.6.2:
>
> http://http2.github.io/http2-spec/#rfc.section.3.6.2
>
> Many simple implementations will choose to avoid flow control.  In
> fact, we want to encourage them to avoid implementing it.
>
>