Re: HEADERS and flow control

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

>
> 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.
>
>
Are you saying that while server retains request headers in memory, it must
not respond WINDOW_UPDATE since it is the commitment of the resource?  If
so, the connection window gets drastically small and concurrency is vastly
reduced.
 ​


> 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).
>
>
​You cannot 250 bytes HEADERS frame WITHOUT flow control if flow control is
enabled for HEADERS.​
It is mandatory and violating flow control is subject to connection error.
For the latter, I feel like a non-trivial scheduling problem, but I'm not
sure.

Best regards,
Tatsuhiro Tsujikawa



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