Re: http/2 prioritization/fairness bug with proxies

On Tue, Feb 12, 2013 at 12:18 PM, Roberto Peon <grmocg@gmail.com> wrote:
> The problem that we have here is that the TCP API isn't sufficiently rich to
> allow us to do the right thing (e.g. read bytes without allowing the sender
> to send more). As a result, we have to have another level of flow control

That's not necessary here.

There are two issues here:

a) flow [and congestion] control;
b) prioritization of "interactive" or "control" traffic over bulk traffic.

These are exactly the same issues that have been faced in SSHv1 and SSHv2.

TCP can handle (a), but if you multiplex traffic of different QoS over
one TCP connection you run into the issues that SSHv1 and v2 have run
into.

There's two ways to address these issues: either don't it (it ==
multiplex diff QoS traffic over the same TCP conn.) or try hard never
to write more than one BDP's worth of bulk without considering higher
priority traffic.  Determining BDP is non-trivial and it can vary, but
it's reasonable to estimate it by looking at round-trip times (it'd be
nice if TCP could expose that to apps so they don't have to measure it
redundantly!) and growing send bandwidth until receive bandwidth stops
growing -- not exactly trivial, but reasonable.

Now, in practice browsers already use multiple TCP connections to the
same server anyways, so... what's wrong with per-priority TCP
connections?  (see below)

> which we'd otherwise be able to do without. Unfortunately, per priority TCP
> connections don't work well for large loadbalancers where each of these
> connections will likely be terminating at a different place. This would
> create a difficult synchronization problem server side, full of races and
> complexity, and likely quite a bit worse in complexity than getting flow
> control working well.

I think you're saying that because of proxies it's difficult to ensure
per-priority TCP connections, but this is HTTP/2.0 we're talking
about.  We have the power to dictate that HTTP/2.0 proxies replicate
the client's per-priority TCP connection scheme.

> Note that the recommendation will be that flow control be effectively
> disabled unless you know what you're doing, and have a good reason (memory
> pressure) to use it.

Huh?  Are you saying "we need and will specify flow control.  It won't
work.  Therefore we'll have it off by default."  How can that help?!
I don't see how it can.

Nico
--

Received on Wednesday, 13 February 2013 20:57:37 UTC