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

David Krauss <potswa@gmail.com> Fri, 20 March 2015 02:29 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1351D1A90EB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Mar 2015 19:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.607
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXEDAV2q_DJL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Mar 2015 19:29:01 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3AA1A1BB1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 19 Mar 2015 19:29:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1YYmcr-0001BO-6S for ietf-http-wg-dist@listhub.w3.org; Fri, 20 Mar 2015 02:25:29 +0000
Resent-Date: Fri, 20 Mar 2015 02:25:29 +0000
Resent-Message-Id: <E1YYmcr-0001BO-6S@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <potswa@gmail.com>) id 1YYmcj-0001Ad-TC for ietf-http-wg@listhub.w3.org; Fri, 20 Mar 2015 02:25:21 +0000
Received: from mail-pa0-f44.google.com ([209.85.220.44]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <potswa@gmail.com>) id 1YYmci-0005Mz-5u for ietf-http-wg@w3.org; Fri, 20 Mar 2015 02:25:21 +0000
Received: by pagj4 with SMTP id j4so2431169pag.2 for <ietf-http-wg@w3.org>; Thu, 19 Mar 2015 19:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.70.26.100 with SMTP id k4mr181186164pdg.125.1426818293555; Thu, 19 Mar 2015 19:24:53 -0700 (PDT)
Received: from [172.20.10.2] ([121.54.44.88]) by mx.google.com with ESMTPSA id ey10sm5184966pab.47.2015.03.19.19.24.47 (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 <potswa@gmail.com>
In-Reply-To: <CAAoo=c7Wov+WG9sMNHWumCaAF5v6mdudZWma3jxy6x3L-4DNtw@mail.gmail.com>
Date: Fri, 20 Mar 2015 10:24:34 +0800
Cc: Bob Briscoe <bob.briscoe@bt.com>
Message-Id: <EB84A7BE-78CF-4DAD-B007-C1EF8AB70CCC@gmail.com>
References: <201503061443.t26EhiV9013453@bagheera.jungle.bt.co.uk> <CAAoo=c7Wov+WG9sMNHWumCaAF5v6mdudZWma3jxy6x3L-4DNtw@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.2070.6)
Received-SPF: pass client-ip=209.85.220.44; envelope-from=potswa@gmail.com; helo=mail-pa0-f44.google.com
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Hub-Spam-Report: AWL=-4.378, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.246, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.558, RCVD_IN_SORBS_WEB=0.614, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1YYmci-0005Mz-5u 9b350f9fcbd27e4c99200be718ffcab7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 flow control <draft-ietf-httpbis-http2-17>
Archived-At: <http://www.w3.org/mid/EB84A7BE-78CF-4DAD-B007-C1EF8AB70CCC@gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28995
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

> On 2015–03–20, at 8:18 AM, Stuart Douglas <stuart.w.douglas@gmail.com <mailto:stuart.w.douglas@gmail.com>> 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 <bob.briscoe@bt.com> wrote:
> 
> 5.2. Flow Control <https://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-5.2> 
> "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.