Re: proposed WINDOW_UPDATE text for session flow control windows

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/
> >>
> >>
> >>
> >
>
>