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

From: Fred Akalin <[email-masked]>
Date: Fri, 21 Jun 2013 14:58:35 -0700

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.

First, it's not clear what disabling flow control means in that section.
Does it apply only one way (i.e., letting the other end know that they're
free to send data at any time) or both ways (i.e., being able to send data
at any time)? I'm assuming it's not the latter, as that would be dangerous
for the other end, but perhaps the language should be clarified.

My main concern is that I can't think of a situation where setting a really
high flow control window wouldn't suffice to effectively disable flow
control. Granted, it's not exactly the same thing, but I can't imagine that
keeping track of the received window size would be onerous enough that
adding this other special mode would be worth it. And if it is onerous for
some implementation, I would have low confidence that it would get the
tracking of the send window size right, either.

I searched, but I may have missed some earlier discussion on this -- feel
free to point me to it. Thoughts?

-- Fred

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Jun 2013 15:49:48 -0700

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

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 21 Jun 2013 16:13:43 -0700

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?

---

From: Fred Akalin <[email-masked]>
Date: Fri, 21 Jun 2013 16:23:58 -0700

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 <[email-masked]> 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.
>

---

From: Fred Akalin <[email-masked]>
Date: Fri, 21 Jun 2013 16:23:30 -0700

> fact, we want to encourage them to avoid implementing it.

I agree that flow control is hard, and simple implementations should avoid
it. However, why can't we just recommend to set the initial window size to
2^32-1? Is it a worry that simple clients may end up being used for
not-so-simple tasks like sending large files?

---

From: Roberto Peon <[email-masked]>
Date: Fri, 21 Jun 2013 16:54:49 -0700

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 <[email-masked]> wrote:

>> On Fri, Jun 21, 2013 at 3:49 PM, Martin Thomson <[email-masked]
>> > wrote:
>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 21 Jun 2013 17:05:29 -0700

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 <[email-masked]> wrote:

>>> On Fri, Jun 21, 2013 at 3:49 PM, Martin Thomson <
>>> [email-masked]> wrote:
>>>

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 21 Jun 2013 18:01:38 -0700

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 (陈智昌)
<[email-masked]>wrote:

>>> On Fri, Jun 21, 2013 at 4:13 PM, Jeff Pinner <[email-masked]>wrote:
>>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 21 Jun 2013 18:06:16 -0700

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 <[email-masked]> wrote:

> On Fri, Jun 21, 2013 at 5:05 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 21 Jun 2013 18:15:57 -0700

You could do that:

Send an INITIAL_WINDOW_SIZE setting to the max value, but that won't effect
the session window, so for that you'd have to send a WINDOW_UPDATE frame
that's set to max value - 64kB, and then you can send subsequent frames
after half-consumed.

I'm worried that naive clients won't do anything but use the default
values. What do the client guys think?

---

From: Fred Akalin <[email-masked]>
Date: Fri, 21 Jun 2013 18:26:59 -0700

I feel like since clients have to implement flow control anyway (to respect
the server window) that if we give clear instructions on how to
"effectively" disable flow control (send INITIAL_WINDOW_SIZE to max value,
send WINDOW_UPDATE frame for max value - 64KB), perhaps replacing the
existing section talking about the flag, that they'll do the right thing.

I feel like if a client is naive enough, it might even forget to set the
DISABLE_FLOW_CONTROL flag, anyway. There's only so much we can do!

-- Fred

On Fri, Jun 21, 2013 at 6:15 PM, Jeff Pinner <[email-masked]> wrote:

> You could do that:
>
> Send an INITIAL_WINDOW_SIZE setting to the max value, but that won't
> effect the session window, so for that you'd have to send a WINDOW_UPDATE
> frame that's set to max value - 64kB, and then you can send subsequent
> frames after half-consumed.
>

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 24 Jun 2013 06:44:24 +0000

I fail to see the issue with the current draft. Did you see section
http://http2.github.io/http2-spec/#fc-principles

that answer the questions about whether disabling (or doing anything at all) on flow control affects one direction or both directions. That section clearly states that flow control is unidirectional. Flow control is controlled by the receiver. When the receiver turns it off, or sends a window update, or whatever, this only affects the incoming direction to the receiver. The sender MUST heed whatever the receiver says.

Is there something that still needs clarification in that section?

So, for example, if a browser turns off flow control, it is telling the next hop (an intermediary or server) to send as much as he wants. But if the next hop tells the browser to regulate its sending via flow control, the browser MUST heed it.

I think having the big knobs to turn off flow control on a per-stream or per-connection basis is preferable to “turning off” flow control via the chatty and dynamic game of sending window updates to constantly open the window.

At any rate, I think the current mechanism is fine for this implementation draft, perhaps with minor clarification.

From: Fred Akalin [mailto:[email-masked]]
Sent: Friday, June 21, 2013 6:27 PM
To: Jeff Pinner
Cc: William Chan (陈智昌); Roberto Peon; Martin Thomson; HTTP Working Group
Subject: Re: Is the ability to disable flow control really needed?

I feel like since clients have to implement flow control anyway (to respect the server window) that if we give clear instructions on how to "effectively" disable flow control (send INITIAL_WINDOW_SIZE to max value, send WINDOW_UPDATE frame for max value - 64KB), perhaps replacing the existing section talking about the flag, that they'll do the right thing.

I feel like if a client is naive enough, it might even forget to set the DISABLE_FLOW_CONTROL flag, anyway. There's only so much we can do!

-- Fred
On Fri, Jun 21, 2013 at 6:15 PM, Jeff Pinner <[email-masked]<mailto:[email-masked]>> wrote:
You could do that:

Send an INITIAL_WINDOW_SIZE setting to the max value, but that won't effect the session window, so for that you'd have to send a WINDOW_UPDATE frame that's set to max value - 64kB, and then you can send subsequent frames after half-consumed.

I'm worried that naive clients won't do anything but use the default values. What do the client guys think?

---

From: Fred Akalin <[email-masked]>
Date: Mon, 24 Jun 2013 00:15:05 -0700

On Sun, Jun 23, 2013 at 11:44 PM, Gabriel Montenegro <
[email-masked]> wrote:

>  I fail to see the issue with the current draft. Did you see section ****
>
> http://http2.github.io/http2-spec/#fc-principles****
>
> ** **
>
> that answer the questions about whether disabling (or doing anything at
> all) on flow control affects one direction or both directions. That section
> clearly states that flow control is unidirectional. Flow control is
> controlled by the receiver. When the receiver turns it off, or sends a
> window update, or whatever, this only affects the incoming direction to the
> receiver. The sender MUST heed whatever the receiver says.****
>
> ** **
>

I think that section is perfectly clear. However, the section I was looking
at (and the only one that talks about ending flow control) was not. :)
Perhaps it would be better for the text describing the important semantics
of flow control to be in one section together, i.e. 3.6.1, and have 3.8.9
be only about the WINDOW_UPDATE frame itself.

I think having the big knobs to turn off flow control on a per-stream or
> per-connection basis is preferable to “turning off” flow control via the
> chatty and dynamic game of sending window updates to constantly open the
> window.
>

I hardly think that sending a WINDOW_UPDATE frame every 2^30 bytes can be
describes as chatty, especially since in the vast majority of cases the
number of WINDOW_UPDATE frames sent to turn off flow control, either
effectively or with the flag, remains the same (i.e., 1).

At any rate, I think the current mechanism is fine for this implementation
> draft, perhaps with minor clarification.
>

Sure, I think the other implementors and I are on the same page re. how
this works. Perhaps this is something we can resolve for after the
implementation draft.

-- Fred

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Jun 2013 11:46:54 -0700

On 24 June 2013 00:15, Fred Akalin <[email-masked]> wrote:
> of flow control to be in one section together, i.e. 3.6.1, and have 3.8.9 be
> only about the WINDOW_UPDATE frame itself.

I think that 3.6.1, point 6 is clear enough:

6. Flow control can be disabled by a receiver. A receiver can choose
to either disable flow control for a stream or connection by sending a
window update frame with a specific flag. See Ending Flow Control
(Section 3.8.9.4) for more details.

3.6.1 provides an overview and describes *what* can be done along with
some guidance in 3.6.2 on *why* (and why not).  3.8.9 describes the
*how*, as well as the repercussions of the same.  I believe that this
structure is most conducive to comprehension, but will consider pull
requests that propose revisions... After -04 is out :)

> effectively or with the flag, remains the same (i.e., 1).

It's more than that, it's the fact that a receiver has to maintain a
count and ensure that they don't over advertise (that's fatal).
Opting out is easier.