Re: http/2 prioritization/fairness bug with proxies

[Nico Williams <[e-mail]>]

On Wed, Feb 13, 2013 at 4:43 PM, Roberto Peon <[e-mail]> wrote:
> SCTP: Unfortunately not deployable due to consumer NAT interactions.

I know :(

> Bulk-traffic: There are a number of different levels of traffic we're
> prioritizing. It isn't just 'bulk' or 'highpri'

I believe there's really only two or three categories of traffic:
bulk, non-bulk w/ Nagle algorithm, non-bulk w/o Nagle.  That's really
it.  If there are multiple bulk flows where it is not desirable for
one slow/stuck sink to cause all the other bulk flows to stop, then
you need a TCP connection per-bulk flow (or at least that one
possibly-slow flow).

But it's possible that we're talking about different thing.  One thing
is priority for server processing of requests.  Another is for proxies
-- here we have to start worrying about the multiplexing issues that
SSHv1 and SSHv2 have had, and since I think we ware talking about
proxies I keep coming back to these issues.

> Certain features require synchronization between control data and payload
> (e.g. server push).
> It is not possible to demux these without additional complexity from a
> protoco standpoint.

I don't see why.  Can you explain in more detail?

> From an implementation standpoint: I'm already running out of ephemeral port
> space. I *do Not* want to use more connections.

It's certainly what browsers do already, and have for many years.
What's the problem?

> From an implementation standpoint: It is often impossible to figure out that
> k connections belong to a single client at all loadbalancers without
> sacrificing orders of magnitude of performance. Orders of magnitude, not
> just a factor of X.

But I'm not saying you need to do that.  Nor am I implying it.

> There isn't even a guarantee that multiple connections will go to the same
> load balancer.

All that matters is that bulk traffic be on separate TCP connections
from non-bulk.  That's one bit in the request/response headers.

> Browsers have used multiple connections because of limitations in HTTP,
> which we're already solving with multiplexing.

I strongly suspect that you're not solving them.  It's not just "oh,
let's multiplex".  You need to watch out for the issues other
protocols that multiplex different flows on single TCP flows have had.
 You haven't demonstrated a grasp of those issues.

> The flow control is window-update based, however a receiver can indicate to
> a sender a value which effectively means: never limit yourself on flow
> control.

That's roughly what SSHv2 does.  It's a disaster.  If you don't
believe me, do at least go ask others who have experience in this.

Nico
--