W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: WINDOW_UPDATE with streamid = 0 redundant?

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 11 Feb 2014 14:58:47 -0800
Message-ID: <CAP+FsNdtQkt36e1VnN6cNon8NWn9QJyfLB38RWRbwH_EVWxAeQ@mail.gmail.com>
To: Daniel Sommermann <dcsommer@fb.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 22:59:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC