Re: HEADERS and flow control

On Wed, May 28, 2014 at 7:09 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 9 May 2014 20:42, Roberto Peon <grmocg@gmail.com> wrote:
>
>> Currently HEADERS are not subject to flow control. There are a couple of
>> reasons for this, but the biggest one is that this helps to prevent a
>> deadlock which can occur when a server is waiting for a particular
>> request before it can make progress on other responses, but flow control is
>> asserted.
>>
>
>
> Circling back on this one!
>
> Excluding HEADERS from flow control doesn't prevent deadlock.   If the
> request that the server is waiting on is a post with a body and the
> connection window is consumed, then we are deadlocked just the same.
>
>
​If we just flow control HEADERS as is in the current draft, we get
unavoidable deadlock.
This is because HEADERS cannot be arbitrary split into several frames since
the draft says that only first or last HEADERS have HTTP semantics.
We can do this in DATA frame.  For example, if there is 200 bytes available
in connection window and 250 bytes available in stream window, we send 200
bytes DATA and wait for WINDOW_UPDATE.  Meanwhile we can also send urgent
frames like PING, WINDOW_UPDATE and RST_STREAM etc..
For HEADERS we have to send entire frame and you may hit window size = 0 in
the middle of the HEADERS payload. If this happens, we just stuck until
WINDOW_UPDATE comes.
Suppose that both ends send HEADERS and hit connection window = 0 in the
middle of HEADERS.  This is nasty deadlock situation.

​Best regards,
Tatsuhiro Tsujikawa​




> Flow control is intended to limit the resources that a server needs to
> commit to a stream/connection. So exempting headers just gives an incentive
> to put more data in them, to thus consume more server resources and thus
> increase the chances of once stream interacting with another.
>
> Big data is not a problem for a server, as you only have to read a little
> bit of it at a time and stream it to the application (which may decide to
> aggregate, but that is somebody else design decision).  Big headers are a
> big resource commitment for servers as we must hold them for the entire
> duration of the request handling.
>
> So if a server accepts >64KB of headers on a stream, it has to hold those
> for the entire duration of the request handling as the application can ask
> for a header at any time.  Even if the request handling suspends and waits
> a long time for some downstream service, the headers have to be held.
>
> To me, this is just like the browsers unilaterally deciding to break the
> two connection rule, regardless of the impact on server resources, except
> in this case at least servers have the ability to say no.  However, if
> browser vendors decide to allow larger headers to be sent and large
> corporations with big budgets are accepting of those headers, this will
> have a big resource impact on the rest of use.   Sorry for my "flair for
> the dramatic", but this goes somewhat towards network neutrality as we
> should not be designing a protocol that will only scale for those with big
> budgets!
>
> 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.
>