Re: WINDOW_UPDATE with streamid = 0 redundant?

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 22:50:12 UTC