Re: http/2 prioritization/fairness bug with proxies

On Feb 3, 2013 10:26 PM, "Yoav Nir" <ynir@checkpoint.com> wrote:
>
> 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?

Using separate connections is generally suboptimal for all the reasons we
are adding multiplexing.

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

That's an option if we agree we should change the protocol to support
stream grouping. I'm focusing now on that decision, not on the choice of
the actual mechanism.

>
> Where is the SPDY/4 prioritization proposal described?

I didn't link to it earlier because I wanted to focus on the stream
grouping concept and not the other aspects of the proposal.

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