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

I agree with this. If implementation simplicity is the only reason for
disabling flow control, then we may as well just have a big switch to turn
it all off.


On Fri, Jun 21, 2013 at 4:13 PM, Jeff Pinner <jpinner@twitter.com> wrote:

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