http/2 prioritization/fairness bug with proxies

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.

Received on Monday, 4 February 2013 05:33:50 UTC