Re: http/2 prioritization/fairness bug with proxies

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).

Cheers,


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