Re: proposed WINDOW_UPDATE text for session flow control windows

By flags, do you mean SETTINGS thingies, or do you mean values in the flags
byte (I'm assuming SETTINGS thingies?)
-=R


On Wed, Feb 20, 2013 at 1:43 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> I believe that many people will want to turn it off and keep it off.
> Besides, if you send multiple huge WINDOW_UPDATE frames, your peer
> (who is tracking the window size) will be forced to send you a
> RST_STREAM when their window goes off the scale.
>
> Another alternative:
> Send a WINDOW_UPDATE with a value of zero.  This could temporarily
> disable flow control on the referenced stream (or the session for
> stream ID 0).  Similarly, sending a SETTINGS_INITIAL_WINDOW_SIZE value
> of zero would disable flow control for all new streams.
>
> The current doc implicitly permits a value of zero on WINDOW_UPDATE,
> with zero net effect.  A zero on SETTINGS_INITIAL_WINDOW_SIZE would be
> bad, and thus might be considered "reserved" in a special kind of way.
>
> More flags is always an option, but that seems like it is a heavier,
> blunter instrument than this.
>
> On 20 February 2013 12:10, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
> > Do we need a protocol mechanism for this? What's wrong with advertising a
> > huge window and sending huge WINDOW_UPDATE frames as needed? Is the goal
> to
> > allow implementations to actually not implement receiver flow control at
> > all, and just disable it? Considering implementations always need to
> support
> > the peer's receive window advertisements, I view the extra implementation
> > difficulty of supporting receive windows correctly as pretty marginal.
> That
> > said, I do guess it's possible for implementations to set it to extremely
> > high, and in their testing never hit those window limits, and have
> > everything hang because they never sent out more WINDOW_UPDATEs. I do
> admit
> > that'd be bad.
> >
> > I guess I don't feel too strongly. Just wanted to make sure there was an
> > agreement that we needed an extra protocol mechanism rather than just
> > advertising huge windows and updating as needed.
> >
> >
> > On Wed, Feb 20, 2013 at 12:02 PM, Roberto Peon <grmocg@gmail.com> wrote:
> >>
> >> Two proposals:
> >>
> >> 1) Assuming we need/want this on a per-stream basis:
> >> Use a flag value (lets say 0x2) with the delta-window-size field set to
> >> all bits on (i.e. 0xFFFFFF).
> >> all-bits-on is currently illegal (the top bit is reserved so that we
> might
> >> use negative window updates in the future, should we decide to do
> that), so
> >> this should be quite difficult to screw up.
> >>
> >> Setting this on stream '0' would disable the session-level flow control.
> >>
> >> 2) Change SETTINGS so that it also includes the flag byte. This would be
> >> accomplished by adding a new settings ID (10). The LSB of that settings
> >> value would be interpreted as the flag-byte, as if received as in
> scheme 1.
> >> Thus, a settings with id:7, value 0xFFFFFFFF and with id:10
> value:0x00000002
> >> would disable flow control
> >>
> >>
> >>
> >>
> >> On Wed, Feb 20, 2013 at 9:16 AM, Martin Thomson <
> martin.thomson@gmail.com>
> >> wrote:
> >>>
> >>> I need to know how to advertise an infinite window so that receivers
> >>> are able to turn flow control off.  Does anyone want to propose
> >>> something?
> >>>
> >>> On 19 February 2013 14:54, William Chan (陈智昌) <willchan@chromium.org>
> >>> wrote:
> >>> > I've sent out the first pull request for
> >>> > SETTINGS_MAX_NUM_CONCURRENT_STREAMS. After that goes in, I'll rebase
> >>> > and
> >>> > re-run the HTML generator for the flow control change, and send a
> pull
> >>> > request for that.
> >>> >
> >>> > On Tue, Feb 19, 2013 at 2:48 PM, Mark Nottingham <mnot@mnot.net>
> wrote:
> >>> >>
> >>> >> William, can you send a pull request for your changes?
> >>> >>
> >>> >> Patrick, if you want to open an issue to remind us to revisit
> negative
> >>> >> window updates, please feel free.
> >>> >>
> >>> >> Cheers,
> >>> >>
> >>> >>
> >>> >> On 16/02/2013, at 11:10 AM, William Chan (陈智昌) <
> willchan@chromium.org>
> >>> >> wrote:
> >>> >>
> >>> >> > Thanks for the thoughts here. I will need to investigate on our
> end
> >>> >> > how
> >>> >> > much RAM we see get consumed here and if this would bring
> practical
> >>> >> > wins. If
> >>> >> > you feel strongly or anyone else supports this, let's add protocol
> >>> >> > support.
> >>> >> > Otherwise, out of inclination for fewer features and also a mild
> >>> >> > fondness
> >>> >> > for being able to be stricter in the protocol (enforcing
> >>> >> > WINDOW_UPDATE
> >>> >> > compliance). I don't feel strongly and I'm happy to revisit later
> >>> >> > on. This
> >>> >> > part is easy to change if desired.
> >>> >> >
> >>> >> >
> >>> >> > On Tue, Feb 12, 2013 at 6:54 AM, Patrick McManus
> >>> >> > <mcmanus@ducksong.com>
> >>> >> > wrote:
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > On Sun, Feb 10, 2013 at 2:14 PM, William Chan (陈智昌)
> >>> >> > <willchan@chromium.org> wrote:
> >>> >> > Do servers often have a need to immediately revoke buffer size
> >>> >> > promises?
> >>> >> > In absence of negative window updates, I would think servers would
> >>> >> > just stop
> >>> >> > sending WINDOW_UPDATEs. Is that mechanism insufficient?
> >>> >> >
> >>> >> >
> >>> >> > s/servers/receivers
> >>> >> >
> >>> >> > In this case I was thinking about firefox. In general we don't
> have
> >>> >> > a
> >>> >> > ram budget for transactions in the way a server does, so the
> >>> >> > reasonable
> >>> >> > thing to do in the general case is to set flow control to a very
> >>> >> > high value
> >>> >> > to ensure it isn't a choke point, right? However, RAM does have a
> >>> >> > way of
> >>> >> > suddenly appearing to be low and we get notifications of that.
> Lots
> >>> >> > of times
> >>> >> > this is due to other unrelated system activity - this is
> especially
> >>> >> > true on
> >>> >> > mobile. Currently we do a handful of things in reaction to that
> >>> >> > (dumping
> >>> >> > decoded image caches for example). Another reasonable reaction to
> >>> >> > that is to
> >>> >> > squelch some active streams and shrink their associated buffers..
> >>> >> > this is
> >>> >> > the context I was thinking about.
> >>> >> >
> >>> >> > waiting for a very large window to drain via lack-of-updates could
> >>> >> > take
> >>> >> > an extremely long time.
> >>> >> >
> >>> >> >
> >>> >> > All in all, I don't feel very strongly on this. I'd rather hear
> from
> >>> >> > more proxy/server vendors that they want this, rather than adding
> it
> >>> >> > in just
> >>> >> > because it might be useful. Or are you suggesting that Firefox
> would
> >>> >> > like to
> >>> >> > use this?
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> --
> >>> >> Mark Nottingham   http://www.mnot.net/
> >>> >>
> >>> >>
> >>> >>
> >>> >
> >>>
> >>
> >
>