- From: Nico Williams <nico@cryptonector.com>
- Date: Mon, 11 Feb 2013 17:59:44 -0600
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Mike Belshe <mike@belshe.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Feb 11, 2013 at 4:46 PM, William Chan (陈智昌) <willchan@chromium.org> wrote: > Theoretically possible is one thing. But the moment we get into the game of > trying to carve up portions of BDP via per-stream flow control windows for > prioritization purposes in normal operation (as opposed to just trying to > make reasonable progress under excessive load), I think we're in trouble, > and likely to get into performance issues due to poor implementations. As > I've stated before, I hope most implementations (and believe we should add > recommendations for this behavior) only use flow control (if they use it at > all, which hopefully they don't because it's hard) for maintaining > reasonable buffer sizes. Right. Don't duplicate the SSHv2 handbrake (Peter Gutmann's term) in HTTP/2.0. Use percentages of BDP on the sender side. Have the receiver send control frames indicating the rate at which it's receiving to help estimate BDP, or ask TCP. But do not flow control. Another possibility is to have the sender (or a proxy) use per-priority TCP connections. Nico --
Received on Tuesday, 12 February 2013 00:00:10 UTC