Re: proposed WINDOW_UPDATE text for session flow control windows

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

Received on Wednesday, 20 February 2013 17:17:48 UTC