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: 陈智昌 <willchan@chromium.org>
Date: Fri, 21 Jun 2013 18:06:16 -0700
Message-ID: <CAA4WUYjm8++r+E-UZuWeH=f6o2akHLzknAHgDMZMPKOy1C-M-g@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
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>
Hm, I'm not fully understanding this argument. Why wouldn't you just set
the flow control windows to the max and update the window after it gets
half-consumed?


On Fri, Jun 21, 2013 at 6:01 PM, Jeff Pinner <jpinner@twitter.com> wrote:

> 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:06:44 UTC

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