Re: http/2 prioritization/fairness bug with proxies

Hi

I think the third option (separate streams for each client) is the most fair. Whatever mechanism is used by the server for fairness among clients will be at work here. What is the downside here, wasting TCP sockets?

What if we added a header (or a field to a header) called proxy-disambiguation, where the proxy assigns a short (16-bit? 32-bit?) identifier for each real client. That way the issue of prioritization/fairness gets pushed to the server where it belongs.

Where is the SPDY/4 prioritization proposal described?

Yoav

On Feb 4, 2013, at 7:33 AM, 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.

Received on Monday, 4 February 2013 06:29:00 UTC