W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

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

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 21 Jun 2013 16:54:49 -0700
Message-ID: <CAP+FsNeRN1ar-yzorDNSYDkUsgKQnHL+wGTaaXGFV=fRLwrKGg@mail.gmail.com>
To: Fred Akalin <akalin@google.com>
Cc: Jeff Pinner <jpinner@twitter.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
>>>
>>>
>>
>
Received on Friday, 21 June 2013 23:55:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC