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