Re: proposed WINDOW_UPDATE text for session flow control windows

[Martin Thomson <[e-mail]>]

Just started out on this, taking Roberto's suggestion of having a
setting and a WINDOW_UPDATE flag.  A few minor points came up.

Disabling flow control for the session potentially has two different
mechanisms: settings and window update.  Is this OK, or would people
prefer to only have the WINDOW_UPDATE?  I think that for simple
implementations, the settings will be a more attractive prospect.

I've said that using SETTINGS to disable flow control has an effect on
both new *and existing* streams.  Again, this makes an attractive
option for implementations that don't want flow control.

Re-enabling flow control is an error.  Basically, we have no mechanism
to unambiguously identify when flow control starts.  I don't believe
that it is worthwhile to provide such a mechanism.

See https://github.com/http2/http2-spec/commit/d8013a3e1659696debc8773e9467b8ad829c49ee

On 25 February 2013 17:00, Mark Nottingham <[e-mail]> wrote:
> Opening as:
>   https://github.com/http2/http2-spec/issues/44
> ... and marking as ready for the editors to have a kick at it.
>
> Regards,
>
>
> On 21/02/2013, at 10:00 AM, Martin Thomson <[e-mail]> wrote:
>
>> On 20 February 2013 14:52, Roberto Peon <[e-mail]> wrote:
>>> I'm afraid of simply sending a large window size, because I suspect that
>>> simple implementations will mess it up for objects > 31 bits in size.
>>
>> Yes. Absolutely.
>>
>>> If we don't have a SETTINGS thing, then we're requiring flow control for the
>>> first RT for any stream.
>>
>> Yes, that's the implication.  Though a client is always able to
>> disable flow control without consequence, because it speaks first,
>> before the server sends anything.  It's only servers that need to
>> worry about having it on briefly.  The consequences are minimal - they
>> just don't receive as many packets as they possibly could - but then
>> that is always true for two reasons: TCP INIT CWD and the time it
>> takes to send the WINDOW_UPDATE.
>>
>>> I like the flag solely because it is difficult to do by accident, unlike
>>> using zero (which is technically fine otherwise)
>>
>> I don't believe in accidents, but I see your point.
>>
>>> The other thing to consider is when, if ever, one can transition from
>>> flow-control disabled to requiring its use again.
>>> Even if we don't allow this, it will require text explaining it.
>>
>> I thought about this.  The obvious choice is to start again from zero
>> when a WINDOW_UPDATE comes in.  The problem is knowing (at the
>> receiver end) when counting started.  Once you stop counting, that's
>> the real difficulty.  I believe that once it's off, flow control will
>> need to stay off.
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>