Interaction of WINDOW_UPDATE and SETTINGS for Flow Control

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.

Received on Wednesday, 20 February 2013 21:38:20 UTC