Re: proposed WINDOW_UPDATE text for session flow control windows

[Martin Thomson <[e-mail]>]

I believe that many people will want to turn it off and keep it off.
Besides, if you send multiple huge WINDOW_UPDATE frames, your peer
(who is tracking the window size) will be forced to send you a
RST_STREAM when their window goes off the scale.

Another alternative:
Send a WINDOW_UPDATE with a value of zero.  This could temporarily
disable flow control on the referenced stream (or the session for
stream ID 0).  Similarly, sending a SETTINGS_INITIAL_WINDOW_SIZE value
of zero would disable flow control for all new streams.

The current doc implicitly permits a value of zero on WINDOW_UPDATE,
with zero net effect.  A zero on SETTINGS_INITIAL_WINDOW_SIZE would be
bad, and thus might be considered "reserved" in a special kind of way.

More flags is always an option, but that seems like it is a heavier,
blunter instrument than this.

On 20 February 2013 12:10, William Chan (陈智昌) <[e-mail]> wrote:
> Do we need a protocol mechanism for this? What's wrong with advertising a
> huge window and sending huge WINDOW_UPDATE frames as needed? Is the goal to
> allow implementations to actually not implement receiver flow control at
> all, and just disable it? Considering implementations always need to support
> the peer's receive window advertisements, I view the extra implementation
> difficulty of supporting receive windows correctly as pretty marginal. That
> said, I do guess it's possible for implementations to set it to extremely
> high, and in their testing never hit those window limits, and have
> everything hang because they never sent out more WINDOW_UPDATEs. I do admit
> that'd be bad.
>
> I guess I don't feel too strongly. Just wanted to make sure there was an
> agreement that we needed an extra protocol mechanism rather than just
> advertising huge windows and updating as needed.
>
>
> On Wed, Feb 20, 2013 at 12:02 PM, Roberto Peon <[e-mail]> wrote:
>>
>> 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 <[e-mail]>
>> 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 (陈智昌) <[e-mail]>
>>> 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 <[e-mail]> 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 (陈智昌) <[e-mail]>
>>> >> 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
>>> >> > <[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?
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> Mark Nottingham   http://www.mnot.net/
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>
>