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

When we talk about reducing implementation complexity, it's important to
keep in mind that all implementations that want to interoperate need to at
least respect the receiver's flow control windows. I think the marginal
complexity to also assert static flow control windows is pretty minor. I do
agree that we don't want to encourage people to try to do "smart"
allocation of buffers and flow control windows, as that would add
significant extra complexity.

So, yeah, I don't think disabling flow control windows buys us much in
saved complexity, but whatever. I don't feel too strongly.


On Fri, Jun 21, 2013 at 4:54 PM, Roberto Peon <grmocg@gmail.com> wrote:

> one big red flow-control button: Works for me.
>
> Setting 2^32-1 isn't necessarily "simple"-- 4+Gb files are common enough
> these days and would mess up a simple wget like tool.
> -=R
>
>
> On Fri, Jun 21, 2013 at 4:23 PM, Fred Akalin <akalin@google.com> wrote:
>
>> 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.
>>>>
>>>>
>>>
>>
>