Re: http/2 prioritization/fairness bug with proxies

[Roberto Peon <[e-mail]>]

On Thu, Feb 14, 2013 at 12:26 PM, Nico Williams <[e-mail]>wrote:

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

Priority and flow control are separate issues.
Priorities are an expression of the order in which the browser wants/needs
resources.
Flow control is for receivers which are memory constrained to be sure that
they won't overrun memory requirements.


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

If you want to synchronize things which are not part of a sequence, you
must do additional buffering, above and beyond what TCP may do, and you
must also include synchronization identifiers in both streams.


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

Browsers do this because HTTP effectively limits you to
one outstanding request per connection, which is effectively one request
per RTT per connection.
Allowing a larger concurrency per connection than 1 is what the
multiplexing does.

Browsers are most often not the ones likely to run out of ephemeral port
space-- that is a problem for proxies and servers.


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

If there are multiple connections, then the cost of coordination for this
kind of loadbalancing at large sites is orders of magnitude higher.
You're telling me that you wish to use multiple connections. Unless my
statement above is a lie, it must then follow that it will cost orders of
magnitude more for the same coordination.


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

This is not what browsers need. Browsers need to control the order in which
the server sends responses effectively enough that they can simply send
requests for resources as soon as they know about the resource.
Today they cannot, and attempt to control this by using heuristics to
decide when to send a requests (instead of simply sending it as soon as the
browser realizes it needs the resource). This causes an underutilization of
the available bandwidth.
Removal of this heuristic increases the amount of time it takes to load the
page.


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

Nico, I've been working closely with browser folks for quite a while
(years) and have a good grounding in what is suboptimal today, after all,
SPDY started as a project with a server/proxy developer (me) and a browser
developer (Mike Belshe).
Will Chan and others have been continuing the work on the Chrome side, and
he has already replied to you telling you what browsers need.
I've done several presentations and talks, several of them with browser
folks which do reference the primary browser issue of when to generate
requests.

You are a smart guy and likely have things to contribute, but, please
research before making assertions about what I do or do not know.
-=R