Subject: proposed WINDOW_UPDATE text for session flow control windows

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 10 Feb 2013 00:03:10 -0800

Here's my commit in my github fork of the HTTP/2.0 spec:
https://github.com/willchan/http2-spec/commit/8ba562d34e33e784aad3549a8bab8a6bba87d508

Here's the HTML generated for that (it looks very broken, sorry, I am n00b
at this tooling):
http://htmlpreview.github.com/?https://github.com/willchan/http2-spec/blob/master/draft-ietf-httpbis-http2.html#WINDOW_UPDATE

Roberto and I have had some minimal discussion about this at my pull
request to his SPDY spec repo:
https://github.com/grmocg/SPDY-Specification/pull/4.

Note, I did not update the flow control principles section. I also did not
update the SETTINGS section, although arguably the SETTINGS id
SETTINGS_INITIAL_WINDOW_SIZE should be renamed to
SETTINGS_INITIAL_STREAM_WINDOW_SIZE to be explicit.

My diff is rather simple. It changes the text to indicate stream 0 is used
for the session window. It also does some minor wordsmithing because the
original text was pretty ambiguous. I'm included the full updated
WINDOW_UPDATE text here:

========================================

3.6.8.  WINDOW_UPDATE

   The WINDOW_UPDATE control frame is used to implement per stream and
   per session flow control in HTTP/2.0.  Flow control in HTTP/2.0 is
   per hop, that is, only between the two endpoints of a HTTP/2.0
   connection.  If there are one or more intermediaries between the
   client and the origin server, flow control signals are not explicitly
   forwarded by the intermediaries.  (However, throttling of data
   transfer by any recipient may have the effect of indirectly
   propagating flow control information upstream back to the original
   sender.)  Flow control only applies to the data portion of data
   frames.

   Flow control in SPDY is implemented by a data transfer window for

Belshe, et al.           Expires August 14, 2013               [Page 26]

Internet-Draft                  HTTP/2.0                   February 2013

   each stream and one for the entire session.  The data transfer window
   is a simple uint32 that indicates how many bytes of data the sender
   can transmit.  When the session starts, the sender initializes the
   session window to the initial session window size.  After a stream is
   created, but before any data frames have been transmitted, the sender
   initializes the stream window to the initial stream window size.  The
   window size is a measure of the buffering capability of the
   recipient.  The sender MUST NOT send a data frame with a data length
   greater than the session window size or the stream window size.
   After sending each data frame, the sender decrements both the per
   stream window size and the session window size by the amount of data
   transmitted.  When a stream window size becomes less than or equal to
   0, the sender MUST NOT send data frames for that stream, except for a
   zero length data frame with the FIN flag set.  Likewise, when the
   session window size becomes less than or equal to 0, the sender the
   sender MUST NOT send data frames for that stream, except for a zero
   length data frame with the FIN flag set.  The recipient can send a
   WINDOW_UPDATE frame back to notify the sender that it has consumed
   some data and freed up buffer space to receive more data for the
   stream or session.

   +----------------------------------+
   |1|   unused     |         9       |
   +----------------------------------+
   | 0 (flags) |     8 (length)       |
   +----------------------------------+
   |X|     Stream-ID (31-bits)        |
   +----------------------------------+
   |X|  Delta-Window-Size (31-bits)   |
   +----------------------------------+

   Control bit: The control bit is always 1 for this message.

   Unused

   Type: The message type for a WINDOW_UPDATE message is 9.

   Length: The length field is always 8 for this frame (there are 8
   bytes after the length field).

   Stream-ID: The stream ID that this WINDOW_UPDATE control frame is
   for.  If the stream ID value is 0, the WINDOW_UPDATE frame applies to
   the session window.

   Delta-Window-Size: The additional number of bytes that the sender can
   transmit in addition to existing remaining window size.  The legal
   range for this field is 1 to 2^31 - 1 (0x7fffffff) bytes.

Belshe, et al.           Expires August 14, 2013               [Page 27]

Internet-Draft                  HTTP/2.0                   February 2013

   The window size as kept by the sender must never exceed 2^31
   (although it can become negative in one special case).  If a sender
   receives a WINDOW_UPDATE that causes the window size to exceed this
   limit, then if the Stream-ID was 0, it MUST send a GOAWAY frame with
   status code FLOW_CONTROL_ERROR to terminate the session.  And if the
   Stream-ID references an active stream, it must send a RST_STREAM
   frame with status code FLOW_CONTROL_ERROR to terminate the stream.

   When a HTTP/2.0 connection is first established, the default initial
   window size for all streams is 64KB and the initial window size for
   the session is 64KB.  An endpoint can use the SETTINGS control frame
   to adjust the initial window size for the streams in the session.
   That is, its peer can start out using the 64KB default initial stream
   window size when sending data frames before receiving a SETTINGS
   frame.  Because SETTINGS is asynchronous, there may be a race
   condition if the recipient wants to decrease the initial window size,
   but its peer immediately sends 64KB on the creation of a new
   connection, before waiting for the SETTINGS to arrive.  This is one
   case where the window size kept by the sender will become negative.
   Once the sender detects this condition, it must stop sending data
   frames and wait for the recipient to catch up.  The recipient has two
   choices:

      immediately send RST_STREAM with FLOW_CONTROL_ERROR status code.

      allow the head of line blocking (as there is only one stream for
      the session and the amount of data in flight is bounded by the
      default initial window size), and send WINDOW_UPDATE as it
      consumes data.

   In the case of option 2, both sides must compute the stream window
   size based on the initial stream window size in the SETTINGS.  For
   example, if the recipient sets the initial stream window size to be
   16KB, and the sender sends 64KB for a stream immediately on session
   establishment, the sender will discover its window size is -48KB on
   receipt of the SETTINGS.  As the recipient consumes the first 16KB,
   it can send a WINDOW_UPDATE of 16KB back to the sender.  This
   interaction continues until the sender's window size becomes positive
   again, and it can resume transmitting data frames.

   After the recipient reads in a data frame with FLAG_FIN that marks
   the end of the data stream, it should not send WINDOW_UPDATE frames
   for the stream as it consumes the last data frame.  A sender should
   ignore all the WINDOW_UPDATE frames associated with the stream after
   it send the last frame for the stream.

   The data frames from the sender and the WINDOW_UPDATE frames from the
   recipient are completely asynchronous with respect to each other.

Belshe, et al.           Expires August 14, 2013               [Page 28]

Internet-Draft                  HTTP/2.0                   February 2013

   This property allows a recipient to aggressively update the window
   size kept by the sender to prevent the stream from stalling.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 10 Feb 2013 08:53:29 -0500

>From time to time I bang the drum for allowing negative window updates
(i.e. allowing the receiver to revoke, given a rtt, a portion of previously
granted and unused window due to local resource changes on the receiver).
This proposal doesn't contain that provision - but it has an obvious unused
bit where it could go.

If nobody else sees the value in that I'll stop banging the drum - but this
is sort of a last call to sanity check that.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 10 Feb 2013 11:14:43 -0800

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?

One thing I like about the lack of negative window updates is the ability
to assert (for streams that don't race with a SETTINGS frame that sets the
initial window size) that the sender is respecting flow control. I guess
you can still assert this as long as you aren't actively using negative
window updates.

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?

On Sun, Feb 10, 2013 at 5:53 AM, Patrick McManus <[email-masked]>wrote:

> If nobody else sees the value in that I'll stop banging the drum - but
> this is sort of a last call to sanity check that.
>
>
> On Sun, Feb 10, 2013 at 3:03 AM, William Chan (陈智昌) <[email-masked]
> > wrote:
>
>> Here's the HTML generated for that (it looks very broken, sorry, I am
>> n00b at this tooling):
>>
>> Note, I did not update the flow control principles section. I also did
>> not update the SETTINGS section, although arguably the SETTINGS id
>> My diff is rather simple. It changes the text to indicate stream 0 is
>> used for the session window. It also does some minor wordsmithing because
>> the original text was pretty ambiguous. I'm included the full updated
>> WINDOW_UPDATE text here:
>>

---

From: RUELLAN Herve <[email-masked]>
Date: Mon, 11 Feb 2013 15:02:46 +0000

From my understanding, when the recipient has consumed some data from a stream, it needs to send two WINDOW_UPDATE frames to notify the sender:
- One for updating the stream window size.
- One for updating the session window size.

These two frames could be merged into one by stating that a WINDOW_UPDATE for a stream window also applies to the session window.
This impacts the WINDOW_UPDATE frames received for a closed stream: they should still be applied to the session window.

I find that sending only one WINDOW_UPDATE frame is slightly better from the design point of view. I'm not sure of the impact at the implementation level. I would think it is better to process one "complex" frame than two "simple" ones.

Opinions?

Hervé.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> William Chan (???)
> Sent: dimanche 10 février 2013 09:03
> To: HTTP Working Group
> Subject: proposed WINDOW_UPDATE text for session flow control windows
> 
> https://github.com/willchan/http2-
> spec/commit/8ba562d34e33e784aad3549a8bab8a6bba87d508
> 
> Here's the HTML generated for that (it looks very broken, sorry, I am n00b at
> this tooling):
> http://htmlpreview.github.com/?https://github.com/willchan/http2-
> spec/blob/master/draft-ietf-httpbis-http2.html#WINDOW_UPDATE
> 
> request to his SPDY spec repo: https://github.com/grmocg/SPDY-
> Specification/pull/4.
> 
> My diff is rather simple. It changes the text to indicate stream 0 is used for
> the session window. It also does some minor wordsmithing because the

---

From: Roberto Peon <[email-masked]>
Date: Mon, 11 Feb 2013 10:09:30 -0800

Sometimes you don't want to increase it when a stream has consumed it
though.

I agree that it is probably the common case though, and that a flag could
be used to indicate whether or not this behavior is desired.

The question then is whether or not having two codepaths for this right now
is a big deal.
On Feb 11, 2013 7:04 AM, "RUELLAN Herve" <[email-masked]> wrote:

> From my understanding, when the recipient has consumed some data from a
> stream, it needs to send two WINDOW_UPDATE frames to notify the sender:
> These two frames could be merged into one by stating that a WINDOW_UPDATE
> for a stream window also applies to the session window.
> This impacts the WINDOW_UPDATE frames received for a closed stream: they
> should still be applied to the session window.
>
> I find that sending only one WINDOW_UPDATE frame is slightly better from
> the design point of view. I'm not sure of the impact at the implementation
> level. I would think it is better to process one "complex" frame than two
> "simple" ones.
>
> Opinions?
>
> Hervé.
>
> n00b at
> not
> used for

---

From: Patrick McManus <[email-masked]>
Date: Tue, 12 Feb 2013 09:54:21 -0500

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 15 Feb 2013 15:52:00 -0800

I don't think it's a big deal. Note that it's unlikely that we'll want to
issue a WINDOW_UPDATE for every DATA frame. Implementations hopefully would
do smarter batch window updating, and the session window batch update
probably would reopen the window consumed by multiple streams.

On Mon, Feb 11, 2013 at 10:09 AM, Roberto Peon <[email-masked]> wrote:

> The question then is whether or not having two codepaths for this right
> now is a big deal.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 15 Feb 2013 16:10:31 -0800

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 <[email-masked]>wrote:

>
>
>
> On Sun, Feb 10, 2013 at 2:14 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Feb 2013 09:48:00 +1100

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 19 Feb 2013 14:54:51 -0800

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 <[email-masked]> wrote:

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Feb 2013 09:16:10 -0800

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 (陈智昌) <[email-masked]> wrote:
>> > 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.
>> >
>> >
>> > <[email-masked]> wrote:
>> > In absence of negative window updates, I would think servers would just stop
>> > 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.
>> >
>> > 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?
>> >
>> >
>> >
>> >
>>
>> --

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Feb 2013 12:02:56 -0800

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 <[email-masked]>wrote:

> >> > On Tue, Feb 12, 2013 at 6:54 AM, Patrick McManus <
> [email-masked]>
> >> > wrote:
> >> >
> >> >
> >> >
> >> > waiting for a very large window to drain via lack-of-updates could
> take
> >> > an extremely long time.
> >> >
> >> >

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 20 Feb 2013 12:10:59 -0800

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 <[email-masked]> wrote:

> Use a flag value (lets say 0x2) with the delta-window-size field set to
> all bits on (i.e. 0xFFFFFF).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Feb 2013 13:43:00 -0800

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 (陈智昌) <[email-masked]> wrote:
> 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.
>
>> Thus, a settings with id:7, value 0xFFFFFFFF and with id:10 value:0x00000002
>> would disable flow control
>>
>>
>>
>>
>>> >> > On Tue, Feb 12, 2013 at 6:54 AM, Patrick McManus
>>> >> > <[email-masked]>
>>> >> > wrote:
>>> >> >
>>> >> >
>>> >> >

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Feb 2013 13:49:03 -0800

By flags, do you mean SETTINGS thingies, or do you mean values in the flags
byte (I'm assuming SETTINGS thingies?)
-=R

On Wed, Feb 20, 2013 at 1:43 PM, Martin Thomson <[email-masked]>wrote:

> support
> >> On Wed, Feb 20, 2013 at 9:16 AM, Martin Thomson <
> [email-masked]>
> >> wrote:
> >>>
> >>> >> 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 (陈智昌) <
> [email-masked]>
> >>> >> 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
> >>> >> > In this case I was thinking about firefox. In general we don't
> have
> >>> >> > a
> >>> >> > 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
> >>> >> > 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?
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> --

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Feb 2013 14:40:29 -0800

> byte (I'm assuming SETTINGS thingies?)

Either.  New settings are probably lower cost than flags, but they
certainly aren't free.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 20 Feb 2013 14:52:37 -0800

I'm afraid of simply sending a large window size, because I suspect that
simple implementations will mess it up for objects > 31 bits in size.
If we don't have a SETTINGS thing, then we're requiring flow control for
the first RT for any stream.

I like the flag solely because it is difficult to do by accident, unlike
using zero (which is technically fine otherwise)

The other thing to consider is when, if ever, one can transition from
flow-control disabled to requiring its use again.
Even if we don't allow this, it will require text explaining it.
-=R

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Feb 2013 15:00:48 -0800

> simple implementations will mess it up for objects > 31 bits in size.

Yes. Absolutely.

> If we don't have a SETTINGS thing, then we're requiring flow control for the
> first RT for any stream.

Yes, that's the implication.  Though a client is always able to
disable flow control without consequence, because it speaks first,
before the server sends anything.  It's only servers that need to
worry about having it on briefly.  The consequences are minimal - they
just don't receive as many packets as they possibly could - but then
that is always true for two reasons: TCP INIT CWD and the time it
takes to send the WINDOW_UPDATE.

> using zero (which is technically fine otherwise)

I don't believe in accidents, but I see your point.

> Even if we don't allow this, it will require text explaining it.

I thought about this.  The obvious choice is to start again from zero
when a WINDOW_UPDATE comes in.  The problem is knowing (at the
receiver end) when counting started.  Once you stop counting, that's
the real difficulty.  I believe that once it's off, flow control will
need to stay off.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Feb 2013 12:00:41 +1100

Opening as:
  https://github.com/http2/http2-spec/issues/44
... and marking as ready for the editors to have a kick at it.

Regards,

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 17:28:24 -0800

Just started out on this, taking Roberto's suggestion of having a
setting and a WINDOW_UPDATE flag.  A few minor points came up.

Disabling flow control for the session potentially has two different
mechanisms: settings and window update.  Is this OK, or would people
prefer to only have the WINDOW_UPDATE?  I think that for simple
implementations, the settings will be a more attractive prospect.

I've said that using SETTINGS to disable flow control has an effect on
both new *and existing* streams.  Again, this makes an attractive
option for implementations that don't want flow control.

Re-enabling flow control is an error.  Basically, we have no mechanism
to unambiguously identify when flow control starts.  I don't believe
that it is worthwhile to provide such a mechanism.

See https://github.com/http2/http2-spec/commit/d8013a3e1659696debc8773e9467b8ad829c49ee

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 20:41:52 -0800

Seems reasonable to me at least.
-=R

On Wed, Feb 27, 2013 at 5:28 PM, Martin Thomson <[email-masked]>wrote:

> See
> https://github.com/http2/http2-spec/commit/d8013a3e1659696debc8773e9467b8ad829c49ee
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 27 Feb 2013 21:01:07 -0800

* Is there a reason to disable stream flow control, but not session flow
control? Feels weird to me.
* I see more reason to allow stream flow control without session flow
control, but I feel like if people truly wanted simplicity, why don't they
just disable flow control entirely? Do we really need the granularity here
of stream vs session?

I know there are people who want to disable flow control entirely. Are
there people who only want to disable stream or session flow control? If
someone truly wants this, then sure. Otherwise, I'd err on the side of
fewer changes and keeping the spec simpler for now.

Nit: I don't want to bikeshed too much, but my preference is to call the
shed DISABLE_FLOW_CONTROL instead of END_FLOW_CONTROL. But whatever.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 21:14:55 -0800

> control? Feels weird to me.

Yeah, I didn't worry about that because I did see a case for disabling
flow control in the other direction (session only) and providing a
graduated mechanism [ off, streams only, streams and session ] seemed
less intuitive than [ streams: on/off, session: on/off ].  Now, if few
enough people care about that, it's easy to disable all at once and be
done with it.

> shed DISABLE_FLOW_CONTROL instead of END_FLOW_CONTROL. But whatever.

Noted, I'll do that.  I had DISABLE originally, but I thought END
sounded properly final.  After all, there is no going back.