Re: WINDOW_UPDATE with streamid = 0 redundant?

And vice versa, in cases where the server behind a proxy is happy to accept
more data, but the proxy itself is under memory pressure.

-=R


On Tue, Feb 11, 2014 at 3:11 PM, Johnny Graettinger <
jgraettinger@chromium.org> wrote:

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