Re: HEADERS and flow control

Tatsuhiro,

but flow control exists to limit the resources that a server must dedicate
to a connection.  If the window is 0, then the server is saying that it
does not have any more resources available.   So the client simple should
not send a new stream as there are no server resources.

By removing the protection of excess resource consumption from the protocol
will not magically give the server any more resources.

In the case that you give, if there are 200 bytes available, but the
headers of a new stream is 250, then there can be two possibilities - the
client sends the 250 without flow control and the server resets the stream
because it has not resources  OR the client does not send the 250, but
instead uses the 200 to allow another request to progress (and maybe
complete).

In either case no progress is made on the new request, which may be holding
up some other resource.   But in the current case, bandwidth is wasted and
no other stream progresses.

Removing flow control has not fixed the problem, it has just made it
somebody elses problem.

cheers








On 28 May 2014 14:31, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

>
>
>
> 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.
>>
>
>


-- 
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.