Re: proposed WINDOW_UPDATE text for session flow control windows

[William Chan (陈智昌) <[e-mail]>]

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 <[e-mail]>wrote:

>
>
>
> On Sun, Feb 10, 2013 at 2:14 PM, William Chan (陈智昌) <[e-mail]
> > 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?
>>
>>
>>
>