Re: http/2 prioritization/fairness bug with proxies

Nico Williams <> Wed, 13 February 2013 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFF6921E808A for <>; Wed, 13 Feb 2013 12:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.705
X-Spam-Status: No, score=-7.705 tagged_above=-999 required=5 tests=[AWL=2.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id On2pCZ3+grMY for <>; Wed, 13 Feb 2013 12:59:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B8FD321E8089 for <>; Wed, 13 Feb 2013 12:59:58 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1U5jOm-0006rR-BA for; Wed, 13 Feb 2013 20:57:48 +0000
Resent-Date: Wed, 13 Feb 2013 20:57:48 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U5jOb-0006qi-SA for; Wed, 13 Feb 2013 20:57:37 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1U5jOa-0002PO-V6 for; Wed, 13 Feb 2013 20:57:37 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 7186A27BC061 for <>; Wed, 13 Feb 2013 12:57:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=U4Zv0S8p8Zg2ehG0Njzh UBmms6Y=; b=Nu2MQpBkufhhF0D9blLc1ardGDu+RxV/f67Ow7HoukJ3JESaO2TH SYb1kdHUWxdwSQRmRWHOiF31Iqw/337zwr50QLwV/qcmrWGx9XMB12kVwcEoSYbV TTJnqzWcsq17qLepxeTpvX25CzgD8JOlEoUUKggnwtx8o+DbZB5IPzw=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 1A92E27BC05E for <>; Wed, 13 Feb 2013 12:57:14 -0800 (PST)
Received: by with SMTP id hm11so6493732wib.5 for <>; Wed, 13 Feb 2013 12:57:13 -0800 (PST)
MIME-Version: 1.0
X-Received: by with SMTP id r2mr12720989wia.28.1360789033664; Wed, 13 Feb 2013 12:57:13 -0800 (PST)
Received: by with HTTP; Wed, 13 Feb 2013 12:57:13 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 13 Feb 2013 14:57:13 -0600
Message-ID: <>
From: Nico Williams <>
To: Roberto Peon <>
Cc: Yoav Nir <>, HTTP Working Group <>
Content-Type: text/plain; charset=UTF-8
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.449, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: 1U5jOa-0002PO-V6 703dcaa36fe13d362ac582486a901b75
Subject: Re: http/2 prioritization/fairness bug with proxies
Archived-At: <>
X-Mailing-List: <> archive/latest/16596
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, Feb 12, 2013 at 12:18 PM, Roberto Peon <> 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

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.