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