W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: http/2 flow control

From: Mike Belshe <mike@belshe.com>
Date: Mon, 28 Jan 2013 14:41:52 +0900
Message-ID: <CABaLYCv-K4A8AbtyjCc35H77pSjvTOVACcR6g9fpt0W3c3MAUA@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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.


On Fri, Jan 25, 2013 at 7:22 AM, William Chan (陈智昌)

> 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.
Received on Monday, 28 January 2013 05:42:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC