RE: [Editorial Errata Reported] RFC7540 (4871)

Mike Bishop <Michael.Bishop@microsoft.com> Wed, 30 November 2016 19:18 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8426129971 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 11:18:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.896
X-Spam-Level:
X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 e1N3e-SKev2w for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 11:18:10 -0800 (PST)
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 EDB231298CA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 11:18:09 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cCAKY-0000zF-65 for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Nov 2016 19:14:10 +0000
Resent-Date: Wed, 30 Nov 2016 19:14:10 +0000
Resent-Message-Id: <E1cCAKY-0000zF-65@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <Michael.Bishop@microsoft.com>) id 1cCAKL-0000xL-KL for ietf-http-wg@listhub.w3.org; Wed, 30 Nov 2016 19:13:57 +0000
Received: from mail-sn1nam01on0122.outbound.protection.outlook.com ([104.47.32.122] helo=NAM01-SN1-obe.outbound.protection.outlook.com) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from <Michael.Bishop@microsoft.com>) id 1cCAKC-0005Ia-Oy for ietf-http-wg@w3.org; Wed, 30 Nov 2016 19:13:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BtYkc7YKV15cZ5culCK3y1jnGjXxduY9+b9bb4mgj/E=; b=Onaazg9CW++GIC/f/ShoVYBCBgKByHaBBepvOVGyrpPkguvDT5nhZkMd87SGsrhumITUImJNonOOZxHnS7QSn5Ijxmi2YVR4YH4qgA8DPKRqk9l6jPztqUmJz33b5KA2smKL9k65/5WuXqslTCb61dqYyxPw0Io+ZH+p5RQw6sA=
Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Wed, 30 Nov 2016 18:58:32 +0000
Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.018; Wed, 30 Nov 2016 18:58:32 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: laike9m <laike9m@gmail.com>, Stefan Eissing <stefan.eissing@greenbytes.de>
CC: "tatsuhiro.t@gmail.com" <tatsuhiro.t@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>, Cory Benfield <cory@lukasa.co.uk>, Martin Thomson <martin.thomson@gmail.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Mike Belshe <mike@belshe.com>, Roberto Peon <fenix@google.com>, Ben Campbell <ben@nostrum.com>, Alissa Cooper <alissa@cooperw.in>, Alexey Melnikov <aamelnikov@fastmail.fm>, Patrick McManus <pmcmanus@mozilla.com>, "Mark Nottingham" <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: [Editorial Errata Reported] RFC7540 (4871)
Thread-Index: AQHSSsPC8dZvHZed4EK2PqC81icjTqDxNXSAgAAPOoCAADY/AIAABAmAgAAAVwCAAAbVgIAABY2AgAAR+oCAABF8AIAALhLA
Date: Wed, 30 Nov 2016 18:58:31 +0000
Message-ID: <BN6PR03MB2708DD14E2914CD194D711B4878C0@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <20161130043354.C786DB81319@rfc-editor.org> <1102C272-E8D6-40D3-9D39-7D4801ABD286@lukasa.co.uk> <CABkgnnXYTi0uv=Dm7zPrA=oPam+Zyka-jujFT2bU8GvqvT5JPg@mail.gmail.com> <03C57CE4-E61A-4BF6-A976-2191EB4B127C@lukasa.co.uk> <CANatvzzQZ_isxmd3Ne41QxE2s-sYsrksME+T0RtchM-K1b0DwA@mail.gmail.com> <24141783-A04A-42AD-9730-EB5C91A36516@lukasa.co.uk> <CANatvzygQViXZy0bxLzm3GK3KmVgT2qgSHio8V+3USDOYWxEGQ@mail.gmail.com> <CAPyZ6=KWvn8fMiOab5R_yMedovwo=c2QnGkewuAjKYBxO-5jrQ@mail.gmail.com> <F3F44070-A587-4B89-9DBB-ADDA6469CE4D@greenbytes.de> <CAJutW=d=48771N0WLvepV+qO0+Sk=3o3Goikng83t3iWv7vwoQ@mail.gmail.com>
In-Reply-To: <CAJutW=d=48771N0WLvepV+qO0+Sk=3o3Goikng83t3iWv7vwoQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2001:4898:80e8:c::14c]
x-ms-office365-filtering-correlation-id: b93c268d-755a-4eda-b565-08d41952e124
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2706;
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:BTUVrSgOokvIijStXbEaCnmMAZ59Hw9TmxkF11HhxaxZeNb69mY4Ny4CkS0LhqMC0f04tSxpnpODAs/dQDH4JQaYnBlwScW3qyKkphRA8wDTUyRQ+4UdxCnyxN1PikrFV9jqszBtmRdB4ZHSw4xUrt5ic/zFeyW/DE11kZhfcffJ5RsFAXiyQXdEACV4GWT3nxuPguIRP0Haqjpdcwtc8gqwd3mgjXZvzH1jAvcZ/Ct8hJIMt82Zv7Q5Hj6ErW+AJ5AWcvEhUE7pwj8Lg8c7vLZ8rtbJpbyxGez6ujrZuk469QhStGfHxBlegNpvnou4GLhFnOh9xbrz74llUmKLePpCVQ+b2PcXisReZNrg1VOHyU/RXHVQa+lXdmhXJT0Tq1aW+vTdhTKHudTnsudiVgXYe2VFvGAeCOu9O65/EZ8oxM72kGGXSXZg/cKY2Y1EwuuS35aSXXJH3qGeCFAz6HHuoZnz/CtM5BOiZn3SG5E=
x-microsoft-antispam-prvs: <BN6PR03MB27060F4938F2752D00B1F614878C0@BN6PR03MB2706.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217)(21748063052155)(21532816269658)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6047074)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706;
x-forefront-prvs: 0142F22657
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(7916002)(24454002)(199003)(189002)(377454003)(377424004)(2906002)(97736004)(101416001)(4326007)(2950100002)(86612001)(2900100001)(86362001)(4001150100001)(6116002)(5001770100001)(68736007)(102836003)(93886004)(790700001)(106116001)(105586002)(9686002)(99286002)(81166006)(7416002)(8936002)(81156014)(106356001)(33656002)(6506003)(606004)(38730400001)(5660300001)(3660700001)(76576001)(8990500004)(8676002)(19609705001)(8666005)(10290500002)(5005710100001)(122556002)(7696004)(189998001)(39060400001)(74316002)(39410400001)(7736002)(77096006)(92566002)(3280700002)(50986999)(229853002)(39450400002)(10090500001)(7846002)(345774005)(7906003)(54356999)(76176999)(7059030)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708DD14E2914CD194D711B4878C0BN6PR03MB2708namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2016 18:58:31.9022 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706
Received-SPF: pass client-ip=104.47.32.122; envelope-from=Michael.Bishop@microsoft.com; helo=NAM01-SN1-obe.outbound.protection.outlook.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-2.423, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: titan.w3.org 1cCAKC-0005Ia-Oy facbead9cc8ec19ad0f109aad127938a
X-Original-To: ietf-http-wg@w3.org
Subject: RE: [Editorial Errata Reported] RFC7540 (4871)
Archived-At: <http://www.w3.org/mid/BN6PR03MB2708DD14E2914CD194D711B4878C0@BN6PR03MB2708.namprd03.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33051
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>

And I think you’ve hit on half the controversy here:  wording.  From a non-graph-theory point of view, I read “neighbors” as “other nodes with a common parent.”  So the wording here may imply different things to different people.

I think of it as a recursive allocation – given a tree rooted at X and resources Y to allocate to it:

  *   Define Unblocked(N) true if N or any descendant of N can make progress
  *   If Unblocked(X) is false, allocate no capacity
  *   If X able to make progress, allocate Y to X; return
  *   Else
     *   Let C = count of children of X where Unblocked(child) is true
     *   Repeat algorithm allocating Y / C to the subtree rooted at each (unblocked) child of X

If I’m correct (always chancey), the other issue is that this text talks about redistributing if X is blocked, not if X and all descendants of X are blocked.  That’s addressed elsewhere, but not clearly stated in this particular instance.

From: laike9m [mailto:laike9m@gmail.com]
Sent: Wednesday, November 30, 2016 7:57 AM
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: tatsuhiro.t@gmail.com; Kazuho Oku <kazuhooku@gmail.com>om>; Cory Benfield <cory@lukasa.co.uk>uk>; Martin Thomson <martin.thomson@gmail.com>om>; RFC Errata System <rfc-editor@rfc-editor.org>rg>; Mike Belshe <mike@belshe.com>om>; Roberto Peon <fenix@google.com>om>; Ben Campbell <ben@nostrum.com>om>; Alissa Cooper <alissa@cooperw.in>in>; Alexey Melnikov <aamelnikov@fastmail.fm>fm>; Patrick McManus <pmcmanus@mozilla.com>om>; Mark Nottingham <mnot@mnot.net>et>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [Editorial Errata Reported] RFC7540 (4871)


Since it’s me that brought this question<https://github.com/http2/http2-spec/issues/758> to Martin, I also got some thoughts on it(from a reader's perspective):

Basically the question is not about the example being wrong, it’s about the above description being contradictory with the example.

…Resources are shared between streams with the same parent stream, which means that if a stream in that set closes or becomes blocked, any spare capacity allocated to a stream is distributed to the immediate neighbors of the stream. However, if the common dependency is removed from the tree, those streams share resources with streams at the next highest level.

So, let’s assume the example is correct, then there are three problems with this paragraph.
1.       “in that set”: “set” here apparently means “streams with the same parent stream”, so emphasizing “in that set” makes readers feel the resource reallocation process is between those streams. Better remove it.
2.       “neighbors”: it’s true that in graph theory “neighbors” means nodes that directly connect to a specific node(like C, D to A), but since we’re talking about a tree, if we could use more precise words like “dependent streams” or “child streams”, then there would be no controversy. I searched the whole RFC, “neighbor” is only used once, which does cause some confusion.
3.       “However, if the common dependency is removed from the tree, those streams share resources with streams at the next highest level.”: this whole sentence, in such case, is not even necessary.

So the modified version would be something like this:

Resources are shared between streams with the same parent stream, which means that if a stream closes or becomes blocked, any spare capacity allocated to the stream is distributed to the dependent streams of it.

But yeah, like Cory said, Martin definitely proposed the erratum for a reason, and it's still possible the erratum is what the RFC writers really meant.
​

On Wed, Nov 30, 2016 at 10:54 PM, Stefan Eissing <stefan.eissing@greenbytes.de<mailto:stefan.eissing@greenbytes.de>> wrote:
A stream is blocked only by flow-control, as I read it. The errata would suggest that the flow control of the parent would effectively rule those of its descendants? That does not make much sense to me.

This could easily become very messy. If flow control of dependant nodes become entangled with their ancestors, then we basically have nested flow control windows? Please. no.

-Stefan

> Am 30.11.2016 um 14:49 schrieb Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com<mailto:tatsuhiro.t@gmail.com>>:
>
>
>
> On Wed, Nov 30, 2016 at 10:29 PM, Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>> wrote:
> 2016-11-30 22:05 GMT+09:00 Cory Benfield <cory@lukasa.co.uk<mailto:cory@lukasa.co.uk>>:
> >
> >
> > On 30 Nov 2016, at 13:04, Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>> wrote:
> >
> > My understanding is that you do not need to distinguish between completed, idle and blocked states.
> >
> > For a stream under either of the three states, the weight associated to the stream is distributed to the dependents.
> >
> > That is what nghttp2 does and H2O does (except for the fact that it does not remember closed streams), and I this behavior is what is suggested by the spec.
> >
> >
> > My understanding of what Martin is suggesting is that that isn’t true: blocked streams do not distribute their weight to their dependants.
>
>
> Thank you for pointing that out.
>
> My understanding is that there is no special casing for blocked
> streams. Section 5.3.1 handles all the states we are discussing
> equally, quote:
>
>    Inside the dependency tree, a dependent stream SHOULD only be
>    allocated resources if either all of the streams that it depends on
>    (the chain of parent streams up to 0x0) are closed or it is not
>    possible to make progress on them.
>
> I also do not see why it would be beneficial to treat them differently.
>
>
> ​I agree with Kazuho.  I think RFC 7540 is written based on the idea that dependent stream ca​n receive resource if the streams between it and root are all either in closed, idle or blocked.
>
> Actually, from nghttp2 commit log, I made a commit which implemented the proposed  text.  But we later reverted it, since there is no text in the draft at that time to mandate that behaviour.
>
> Best regards,
> Tatsuhiro Tsujikawa
>
>
>
> >
> > However, that’s also what the Python Priority implementation does.
> >
> > Cory
> >
>
>
>
> --
> Kazuho Oku
>
>