W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: proposed WINDOW_UPDATE text for session flow control windows

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 20 Feb 2013 09:48:00 +1100
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <2595AFA8-9928-4511-B569-3DFC36B73C5C@mnot.net>
To: William Chan (陈智昌) <willchan@chromium.org>
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/
Received on Tuesday, 19 February 2013 22:48:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 February 2013 22:48:38 GMT