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

It may not by much in terms of saved complexity but what about transfer
rate? What is the implication for the maximum transfer rate for
long-latency connections?

Assuming something to the effect of 100 ms one-way time and a client
implementing a default strategy of updating the window after its
half-consumed, with the default 64kB transfer window doesn't that limit the
transfer rate to something like 320kB/s?

It's back of the envelop math but I think it indicates that there is
something to be gained by having the client disable flow control, besides a
reduction in complexity.

But I do think it should be a single switch, something that disables all
receive windows for both streams and the connection, and that we shouldn't
provide a mechanism to re-enable.



On Fri, Jun 21, 2013 at 5:05 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

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