RE: WINDOW_UPDATE with streamid = 0 redundant?

But implementations not only do, but should send updates beyond the initial size.  For example, the HTTP/2 equivalent to an Expect: 100-continue is to advertise a small window to the client.  Most requests will never hit the window, because they'll be GETs without bodies.  The client opens and half-closes the stream without ever sending a flow-controlled frame on it.  If small is non-zero and appropriately-sized, many POSTS can be completed in the same way.

For the case where the client wants to POST something large, the server has specified how much it can send without the server having "approved" it.  After the server sees the headers and initial portion of the body, it will send back either a WINDOW_UPDATE (i.e. continue), a HEADERS (e.g. 403, need auth before I'll take this), or a RST_STREAM (bad request).  It avoids having so much data in flight when the server expects it can make a decision without seeing all of the body and have a response racing with wasted payload.  It gives the server the ability to trade off wasted data versus a wasted RTT - but if the server decides to continue, the WINDOW_UPDATE will presumably be many times the initial stream window.

Basically, they serve different purposes - the session-level flow control prevents overwhelming your peer with more data than they can take.  The per-stream flow control prevents one stream crowding out the others within that allowed space.

From: Daniel Sommermann [mailto:dcsommer@fb.com]
Sent: Tuesday, February 11, 2014 3:06 PM
To: Roberto Peon
Cc: Martin Thomson; HTTP Working Group
Subject: Re: WINDOW_UPDATE with streamid = 0 redundant?

Ah I see, the problem is that individual streams may send WINDOW_UPDATE such that their size exceeds their SETTINGS_INITIAL_WINDOW_SIZE, and that would increase the size of the connection window above it's desired size unexpectedly.

If clients never sent WINDOW_UPDATEs such that the window exceeded its initial size I think the proposal could work, but that is common practice now. Thanks for the clarification.
On 02/11/2014 02:58 PM, Roberto Peon wrote:
Sorry that could be confusing as stated, here is the same thing without (hopefully) the confusing bit!

The connection level window is almost always < sum(stream windows), and this is necessary to ensure that large stream concurrencies can be advertised.

On Tue, Feb 11, 2014 at 2:58 PM, Roberto Peon <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:
No, it is very very very important that they're separate.
The sum of the connection level window is almost always < sum(stream windows), and this is necessary to ensure that large stream concurrencies can be advertised.

-=R

On Tue, Feb 11, 2014 at 2:47 PM, Daniel Sommermann <dcsommer@fb.com<mailto:dcsommer@fb.com>> wrote:
Right, but as I understand it, the connection-level limit is meant to model the total buffering capability of the receiver. This amount of buffer space is only reduced when data on a particular stream is buffered. When that data is processed, we eventually send a WINDOW_UPDATE for that stream, but in reality, the receiver has also freed space in its total buffer budget by the same amount, so at some point, a WINDOW_UPDATE for the connection will follow for the same amount.

What I'm suggesting is that we make the connection-level WINDOW_UPDATE implicit with the stream-level WINDOW_UPDATE, since it fits with modeling the buffering capability of the remote side.


On 02/11/2014 02:40 PM, Martin Thomson wrote:
On 11 February 2014 14:33, Daniel Sommermann <dcsommer@fb.com<mailto:dcsommer@fb.com>> wrote:
"Separate WINDOW_UPDATE frames are sent for the stream and connection level
flow control windows. "

It seems that we don't usually need a separate WINDOW_UPDATE for the
connection (with streamid = 0). When a particular stream gets processed, we
send a WINDOW_UPDATE for that stream, but doesn't this also imply that the
connection-level window should also be updated? When would a WINDOW_UPDATE
for a stream NOT imply an update on the connection window?

I can see keeping around WINDOW_UPDATE with streamid = 0 for the case where
you want to increase only the connection window size at the beginning of the
connection, but after that setup, it seems like a waste of bandwidth to send
these extra WINDOW_UPDATE frames for the connection window.

Thoughts?
There are two layers of flow control windows, one per stream, and a
single connection-level window.

WINDOW_UPDATE on stream 0 increases the space advertised on the
connection-level window.  It's critical to protocol operation that
this be separately updated to the stream-level windows.