Re: H2 HEADERS and flow control

On Jul 3, 2014 1:22 AM, "Greg Wilkins" <gregw@intalio.com> wrote:
>
>
> No I'm not intending to start the whole debate on this again..... I just
have a question on one aspect.
>
> I totally accept that we cannot flow control headers whilst we have a
mutable shared state table, and I pretty much accept the benefits of said
shared mutable state table in this incarnation of the protocol.
>
> But why can't we at least deduct the header frame sizes from the
available window size, so that a stream that is sending a lot of data in
headers does not necessarily get more share of the connection.

We considered this, but if headers are being used as a control channel for
a stream, it's problematic to flow control it. Just like how we don't flew
control control frames.

>
> Simple example is that if a response is sent starting with a 16KB HEADERS
and a 10KB CONTINUATION, then instead of the data frames having a 64KB
window, they will be left with a 48KB window.
>
> The caveats will of course have to be that a header/continuation frame
will not be able to reduce the window below 0, nor shall it be prevented
from being sent if the window is zero.   Thus of a 256KB header is sent,
the stream window will be zero, but the 7 continuation frames will all get
sent, but the stream will stall on the first data frame waiting for a
window update.
>
> If we accept that most implementations will have a limit on header size
<=16KB for 99.99% of users, then including the header frame sizes in the
window accounting will at least remove the incentive for applications to
move data to the headers to avoid flow control.  Ie sending headers will
still have a cost - only that it is paid by your data frames rather than
your headers/continuations.
>
> Has this been considered before?
>
> regards
>
>
>
>
>
>
>
>
> --
> Greg Wilkins <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
scales
> http://www.webtide.com  advice and support for jetty and cometd.