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

Re: http/2 prioritization/fairness bug with proxies

From: Nico Williams <nico@cryptonector.com>
Date: Mon, 11 Feb 2013 17:59:44 -0600
Message-ID: <CAK3OfOi7So1KWXdfv+UEqKAr-o1TaXiZmSmJx61WFR3J0zW_JA@mail.gmail.com>
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.

Received on Tuesday, 12 February 2013 00:00:10 UTC

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