Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>

On 21 March 2015 at 05:22, Bob Briscoe <bob.briscoe@bt.com> wrote:

> Certainly, if flow control is not used to close down a stream, then not
> being able to close down a stream won't be a problem. That does leave the
> problem of what per-stream flow control /can/ be used for, if it can't be
> used to slow down streams!
>
>
Bob,

I'm not following you here?     I've re-read your review and this thread I
don't see where it is indicated that the flow control mechanism cannot shut
down a stream??

In fact the problem highlighted are actually the opposite in that flow
control, if given an under generous window it will stop the stream too
often because it does not allow for enough in flight data.

If the window_update is overgenerous in an attempt to maximim network
performance, then this still does not prevent the flow control mechanism
from stopping stream. Receivers must commit memory to match the windows and
thus must be prepared to read/buffer data within the window size.   A
stream who's consumer is blocked/slow will still eventually be stopped
without HOL blocking any other streams because the receiver has committed
the buffers to match the window.

Overgenerous windows will have an impact on priority, because as you say,
you can't claw back data already sent if the receivers priorities change.
  But then I'm pretty much of the opinion that priorities are a nigh
impossible dream. If streams are created in reverse priority order, then
most senders are going to be able to significantly reorder them since once
low priority ones have been dispatched to the application it is too late to
claw back resources for a subsequently arriving (or reprioritized exiting)
high priority stream.    I'm +1 with Stuart when he says:

On 20 March 2015 at 11:18, Stuart Douglas <stuart.w.douglas@gmail.com>
wrote:

> Basically IMHO flow control should not be used to control priority, that
> is what PRIORITY frames are for, and in general servers can only ever do
> priority on a best effort approach anyway. If you try and use flow control
> to enforce a strict priority mechanism you run a very real risk of
> deadlocks.



So I'm with you when you say the mechanism has been poorly named and
described and is in many ways still experimental with unknown impact on
priority and network performance.

I also acknowledge that without acks it's will be near impossible to
dynamically tune window sizes to match network performance as TCP does.
However, I expect that more often than not it will be memory limits that
statically set the window sizes rather than any dynamic measure of network
performance.  This will almost certainly cost network efficiency in some
cases (A single h2 stream is probably never going to saturate a high
bandwidth network), but we are yet to learn if this is a significant number
of use-cases.

But not following you when you say flow control can't be used to stop a
stream.

cheers






-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.