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

> On 2015–03–20, at 8:18 AM, Stuart Douglas <stuart.w.douglas@gmail.com <mailto: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.

When I made similar arguments last year, the only reply was that flow control throttling and negative credit work and nobody wants to fix what isn’t broken. Also, nobody wants to add complexity to PRIORITY that would overlap functionality already provided by WINDOW_UPDATE. Theoretical arguments about deadlocks aren’t enough, you have to actually implement and demonstrate the condition.

This standardization process is based on rough consensus and working code, not theorizing. However, the definition of “working” is left up to the prototypers who are forming the consensus, which can lead to circular logic. At any rate, the ship has sailed. What we can do now is do our best to implement robustness over performance, and publicly demonstrate any apparent weaknesses and exploits.


> On 2015–03–06, at 10:43 PM, Bob Briscoe <bob.briscoe@bt.com> wrote:
> 
> 5.2. Flow Control <https://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-5.2> 
> "Flow control is used for both individual
>    streams and for the connection as a whole."
> Does this means that every WINDOW_UPDATE on a stream has to be accompanied by another WINDOW_UPDATE frame on stream zero? If so, this seems like 100% message redundancy. Surely I must  have misunderstood.

The decision in this case was that efficiency is not a concern.

I’ve not reviewed this thread fully, sorry, but you might find insight in the mailing list archives. These controversies came up during the evolutionary process.