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

David Krauss <> Fri, 20 March 2015 02:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1351D1A90EB for <>; Thu, 19 Mar 2015 19:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.607
X-Spam-Status: No, score=0.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SBL_CSS=3.335, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cXEDAV2q_DJL for <>; Thu, 19 Mar 2015 19:29:01 -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 7E3AA1A1BB1 for <>; Thu, 19 Mar 2015 19:29:01 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YYmcr-0001BO-6S for; Fri, 20 Mar 2015 02:25:29 +0000
Resent-Date: Fri, 20 Mar 2015 02:25:29 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YYmcj-0001Ad-TC for; Fri, 20 Mar 2015 02:25:21 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1YYmci-0005Mz-5u for; Fri, 20 Mar 2015 02:25:21 +0000
Received: by pagj4 with SMTP id j4so2431169pag.2 for <>; Thu, 19 Mar 2015 19:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PaV/7oJSHkpq4bVHvXtw5TCs5QAFa9iuObjlKYJ/9bo=; b=x+LnhJhJrcvhogTI5RNdg9cG04H4xYhjMV5AorFWrQ1o+AL2rGvH4FqhKVD5/qHQvw t7wILwTTK6kuDyF3mdIfH7VexMq3pquzwk0tft/ueHq3TIWPK57dIlFDjNuyWhwJrwwl Y8DKT72i9s1H36+50rE1BEVbcShsHmik0qedHNsmXnrMGsMV/pnaDZp4UMVUax5d/60v zVWddxqUVruHp2ml1HBx6tP7Ldd4m/D54DpzJYO4jPw+vaBoL0IhpH4+fmKzIO/paGBV k64pexehV4kIUmYkZ1xwM/aYS6l2e3X8Tb/V9mtVYCJOcsdLUsB0rrAMWllrjWQdt6Q3 7iRA==
X-Received: by with SMTP id k4mr181186164pdg.125.1426818293555; Thu, 19 Mar 2015 19:24:53 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id ey10sm5184966pab.47.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Mar 2015 19:24:52 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2A7C395C-17AF-4024-90AA-371AE287894B"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: David Krauss <>
In-Reply-To: <>
Date: Fri, 20 Mar 2015 10:24:34 +0800
Cc: Bob Briscoe <>
Message-Id: <>
References: <> <>
To: HTTP Working Group <>
X-Mailer: Apple Mail (2.2070.6)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Scan-Sig: 1YYmci-0005Mz-5u 9b350f9fcbd27e4c99200be718ffcab7
Subject: Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>
Archived-At: <>
X-Mailing-List: <> archive/latest/28995
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On 2015–03–20, at 8:18 AM, Stuart Douglas < <>> wrote:
> Basically IMHO flow control should not be used to control priority, that is what PRIORITY frames are for, and in general servers can only ever do priority on a best effort approach anyway. If you try and use flow control to enforce a strict priority mechanism you run a very real risk of deadlocks.

When I made similar arguments last year, the only reply was that flow control throttling and negative credit work and nobody wants to fix what isn’t broken. Also, nobody wants to add complexity to PRIORITY that would overlap functionality already provided by WINDOW_UPDATE. Theoretical arguments about deadlocks aren’t enough, you have to actually implement and demonstrate the condition.

This standardization process is based on rough consensus and working code, not theorizing. However, the definition of “working” is left up to the prototypers who are forming the consensus, which can lead to circular logic. At any rate, the ship has sailed. What we can do now is do our best to implement robustness over performance, and publicly demonstrate any apparent weaknesses and exploits.

> On 2015–03–06, at 10:43 PM, Bob Briscoe <> wrote:
> 5.2. Flow Control <> 
> "Flow control is used for both individual
>    streams and for the connection as a whole."
> Does this means that every WINDOW_UPDATE on a stream has to be accompanied by another WINDOW_UPDATE frame on stream zero? If so, this seems like 100% message redundancy. Surely I must  have misunderstood.

The decision in this case was that efficiency is not a concern.

I’ve not reviewed this thread fully, sorry, but you might find insight in the mailing list archives. These controversies came up during the evolutionary process.