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:14 -0800
Message-ID: <CAP+FsNfpt7EJC9gjM4quN_S9gxWdqmaMca3UHteP7DrAdQ1ADw@mail.gmail.com>
To: Daniel Sommermann <dcsommer@fb.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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:58:41 UTC

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