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

Re: http/2 prioritization/fairness bug with proxies

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 4 Feb 2013 17:51:13 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E5854D4A-3647-4E5C-B323-D3DD698207D4@mnot.net>
To: William Chan (陈智昌) <willchan@chromium.org>
Thanks, William. I think most of this came out in discussion.

Personally, as someone who works with proxies, I like grouping (as I said in the meeting).


On 04/02/2013, at 4:33 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> Mike told me I didn't explain this properly at the interim meeting,
> which was totally true, since I was just trying to do a brief survey
> of browser considerations. In retrospect, I'll prepare fuller
> presentations next time to explain things more clearly.
> Anyway, the existing prioritization bug is as follows:
> * Multiple users speaking HTTP/2 to a proxy, where they indicate
> stream priorities within their respective HTTP/2 sessions
> * The proxy speaks HTTP/2 to a server, demuxing the client sessions
> and re-muxing some of the streams into a shared HTTP/2 session to a
> server.
> The natural thing to do in HTTP/2 as currently drafted is to have the
> proxy simply respect the clients' priorities when forwarding to the
> server. That obviously means that specific clients can request
> long-lived high priority streams, or repeatedly request high priority
> streams. This may or may not starve other streams, depending on how
> the backend server handles the priorities.
> There are a number of different ways to handle this in HTTP/2 as
> currently drafted:
> * Long-lived high priority streams can be slowly deprioritized by the
> backend server.
> * The proxy can modify the priorities as it sees them. It could
> neutralize them all (set them all to equivalent values) or if a client
> requests too many high priority streams, it could start lowering the
> priority levels of new streams from that client. The backend server
> obviously can't do this because it doesn't (at least, shouldn't!) know
> the clients behind the proxy.
> * The proxy can use separate HTTP/2 sessions for each client.
> I consider all those options as suboptimal, and thus consider this
> issue to be a protocol bug. Our SPDY/4 prioritization proposal
> addresses this by using stream groups with advisory (all this is
> advisory after all) per group weights (for weighted scheduling). I'd
> like to hear what people think of this issue and how we should address
> it in HTTP/2.
> Cheers.

Mark Nottingham   http://www.mnot.net/
Received on Monday, 4 February 2013 06:51:25 UTC

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