Re: proposed WINDOW_UPDATE text for session flow control windows

Seems reasonable to me at least.
-=R


On Wed, Feb 27, 2013 at 5:28 PM, Martin Thomson <martin.thomson@gmail.com>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 <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/
> >
> >
> >
>