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: Jeff Pinner <jpinner@twitter.com>
Date: Fri, 21 Jun 2013 18:01:38 -0700
Message-ID: <CA+pLO_jgbKNYcr1bSbHfDb1y8MVohpzLpLm2=-yfZ74-mwYgkg@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Roberto Peon <grmocg@gmail.com>, Fred Akalin <akalin@google.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Saturday, 22 June 2013 01:02:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC