W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: proposed WINDOW_UPDATE text for session flow control windows

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 27 Feb 2013 17:28:24 -0800
Message-ID: <CABkgnnVm30edw=ZQbyq9zUbLqQfWMi_YS9Y4n5MjNQTeM5GESg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Roberto Peon <grmocg@gmail.com>, William Chan (ι™ˆζ™Ίζ˜Œ) <willchan@chromium.org>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 <mnot@mnot.net> 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 <martin.thomson@gmail.com> wrote:
>
>> On 20 February 2013 14:52, Roberto Peon <grmocg@gmail.com> 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/
>
>
>
Received on Thursday, 28 February 2013 01:28:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 28 February 2013 01:28:55 GMT