Re: proposed WINDOW_UPDATE text for session flow control windows

[William Chan (陈智昌) <[e-mail]>]

* Is there a reason to disable stream flow control, but not session flow
control? Feels weird to me.
* I see more reason to allow stream flow control without session flow
control, but I feel like if people truly wanted simplicity, why don't they
just disable flow control entirely? Do we really need the granularity here
of stream vs session?

I know there are people who want to disable flow control entirely. Are
there people who only want to disable stream or session flow control? If
someone truly wants this, then sure. Otherwise, I'd err on the side of
fewer changes and keeping the spec simpler for now.

Nit: I don't want to bikeshed too much, but my preference is to call the
shed DISABLE_FLOW_CONTROL instead of END_FLOW_CONTROL. But whatever.


On Wed, Feb 27, 2013 at 8:41 PM, Roberto Peon <[e-mail]> wrote:

> Seems reasonable to me at least.
> -=R
>
>
> On Wed, Feb 27, 2013 at 5:28 PM, Martin Thomson <[e-mail]>wrote:
>
>> 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/
>> >
>> >
>> >
>>
>
>