Subject: Interaction of WINDOW_UPDATE and SETTINGS for Flow Control

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

Just going through the WINDOW_UPDATE stuff and I found this text
regarding the reduction of window size:

   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.

...amongst a lot of text on the subject.

This implies a special case, but I believe that the code (and text)
should be more general than this.  A server can always send SETTINGS
to reduce the initial window size to lower than it previously was.
This is ALWAYS a problem, not just at new session time.

Otherwise, a similar race condition could result in errors (the most
annoying being that the window goes over 2^31, causing the stream to
terminate.  For example, I know that the current is 2^30 available.
The initial value was 2^29 and the receiver has sent an update for
whatever I sent plus 2^29.  Then, the receiver sends a SETTINGS change
to reduce the initial size back to 2^16, followed by an update for
2^30.  If I didn't adjust the window size down, this would blow my
local window out to 2^31, which is too big (and triggers a RST_STREAM
error).

I'd like to propose that we make the aforementioned section apply more
generally to all cases where SETTINGS includes a value for the initial
window size.  Senders will be required to reduce (or expand) the
windows on all streams that they are currently tracking, as
appropriate.