Re: proposed WINDOW_UPDATE text for session flow control windows

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