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: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Fri, 21 Jun 2013 17:05:29 -0700
Message-ID: <CAA4WUYiZCuK7CZWd-FoOXYjfpG0EfX6VoyV_xVSMzbRJqUC3eQ@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Fred Akalin <akalin@google.com>, Jeff Pinner <jpinner@twitter.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 (
>>>> > 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 Saturday, 22 June 2013 00:06:02 UTC

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