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

On 24 June 2013 00:15, Fred Akalin <akalin@google.com> wrote:
> 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 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 :)

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

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.

Received on Monday, 24 June 2013 18:47:22 UTC