Re: WINDOW_UPDATE with streamid = 0 redundant?

My understanding is there may also be scenarios where a client wishes to
defer stream window updates, but not session updates. Eg if a client
accepts a pushed stream but isn't ready to consume it yet, it might want to
leave the stream stalled while updating the session window.


On Tue, Feb 11, 2014 at 6:06 PM, Daniel Sommermann <dcsommer@fb.com> wrote:

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