Re: proposed WINDOW_UPDATE text for session flow control windows

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 <grmocg@gmail.com> 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 <martin.thomson@gmail.com>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 (陈智昌) <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/
>> >>
>> >>
>> >>
>> >
>>
>>
>