Re: http/2 flow control

Nice writeup, will.

I guess if you wanted to note one more thing, the (max streams * default
per stream window) is potentially a type of flow control too, depending on
values chosen.

Mike



On Fri, Jan 25, 2013 at 7:22 AM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> Given the long previous debates in flow control discussions on the
> spdy-dev@ mailing list
> (https://groups.google.com/d/topic/spdy-dev/JB_aQPNI7rw/discussion), I
> thought it would be useful to write up a summary of lots (but not all)
> of the discussions before we engage in the f2f interim meeting
> discussions. Here's my summary:
>
> https://docs.google.com/document/d/15LMnvVWSY-kF-ME4RZIFHN0FukViapjiefQMmQCnr14/pub
> .
>
> It discusses the reasoning behind per-stream flow control windows, as
> included in SPDY3 and in the current http2 draft. It discusses some
> problems with it, and also tradeoffs between relying on transport
> level flow control windows (TCP) and session level flow control
> windows.
>
> This document left out some other proposals to hopefully keep it simpler:
> * Receiver sending a xon/xoff frame to instruct the sender to
> resume/stop sending.
> * Stream group flow control windows.
>
> The latter is fairly advanced, and I think it is only pertinent if we
> agree there is a need for session level flow control windows, since
> stream group flow control windows subsume session level flow control
> windows (session == a single stream group containing all streams).
>
> One last thing on flow control. It's definitely possible, as Patrick
> demonstrates in
> http://bitsup.blogspot.com/2012/12/managing-bandwidth-priorities-in.html,
> to use flow control facilities to control prioritization. It's my hope
> that HTTP/2's prioritization facilities will suffice for that end, and
> thus we won't try to use receive windows to control prioritization.
>
> Cheers.
>
>