Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>

Amos Jeffries <> Fri, 20 March 2015 19:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D0EB11A8ABD for <>; Fri, 20 Mar 2015 12:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6D8N6BCpHh86 for <>; Fri, 20 Mar 2015 12:09:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5996C1A8AA3 for <>; Fri, 20 Mar 2015 12:09:29 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YZ2Ee-0005ST-RQ for; Fri, 20 Mar 2015 19:05:32 +0000
Resent-Date: Fri, 20 Mar 2015 19:05:32 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YZ2EY-0005Ri-1F for; Fri, 20 Mar 2015 19:05:26 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1YZ2EW-0003CT-VX for; Fri, 20 Mar 2015 19:05:25 +0000
Received: from [] ( []) by (Postfix) with ESMTP id BFFDFE6FBD for <>; Sat, 21 Mar 2015 07:04:49 +1200 (NZST)
Message-ID: <>
Date: Sat, 21 Mar 2015 08:04:38 +1300
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.418, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1YZ2EW-0003CT-VX 728cc4ed5008b54de42d375f114f3229
Subject: Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>
Archived-At: <>
X-Mailing-List: <> archive/latest/28999
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 21/03/2015 5:50 a.m., Bob Briscoe wrote:
> Jason,
> At 16:00 19/03/2015, Jason Greene wrote:
>> I think thats a good argument for why it’s not suitable for
>> rate-limiting relative to a variable bandwidth product of a single
>> connection (which i took as your use-case a).
> I believe there is no need for an intermediate node to do flow control
> for individual streams. It does need to control the whole envelope
> within which all the streams are flowing through the proxy's app-layer
> buffer memory (e.g. due to a thick incoming pipe feeding a thin outgoing
> pipe). The best mechanism for controlling the app-layer buffer
> consumption of the aggregate connection is for the intermediate node to
> control the TCP receive window of the incoming stream.
> That doesn't preclude the intermediate node passing on any per-stream
> flow control messages emanating from the ultimate receiver so that the
> ultimate sender controls each stream's rate, which will alter the
> balance between streams within the overall envelope at the proxy.
> I explained all this in my review.

You seem to not be considering the common case where multiple incoming
pipes potentially match or exceed the size of the pipe they are being
multiplexed to.

Passing the WINDOW_UPDATE from clients to server pipes as-is has great
potential for HOL blocking at the server if any one of the clients
requests a large object with large window size.

Assiging a dedicated Nth of the server pipe to each client leads to
under-utilization if any of the clients pauses. And is very difficult to
guage in advance of N clients existing.

These also happen in reverse when one client fetches from N servers.

And can happen simultaneously in both directions in a multiplexed mesh
of connections. So that server X flooding its connection to client B can
fill client B's pipe and prevent server Y being able to deliver some
frames for client-B which HOL-block server Y from sending client A's

The HTTP/2 scheme allows the intermediary to dynamically offer or
withhold window space/credits to prevent any given stream causing those