Re: WINDOW_UPDATE with streamid = 0 redundant?

On Tue, Feb 11, 2014 at 3:22 PM, Mike Bishop
<Michael.Bishop@microsoft.com> wrote:
> 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.

^^^ This nails it.

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

Received on Tuesday, 11 February 2014 23:33:19 UTC