Re: [Editorial Errata Reported] RFC7540 (4871)

Stefan Eissing <stefan.eissing@greenbytes.de> Wed, 30 November 2016 14:58 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 98FE712958C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 06:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.498
X-Spam-Level:
X-Spam-Status: No, score=-8.498 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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=greenbytes.de header.b=N/2kcyPR; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=PNGo9Ceq
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 eCbivTUXKpAy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 06:58:50 -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 132891294E6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 06:58:49 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cC6HZ-0001ls-AV for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Nov 2016 14:54:49 +0000
Resent-Date: Wed, 30 Nov 2016 14:54:49 +0000
Resent-Message-Id: <E1cC6HZ-0001ls-AV@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <stefan.eissing@greenbytes.de>) id 1cC6HT-0001iu-RI for ietf-http-wg@listhub.w3.org; Wed, 30 Nov 2016 14:54:43 +0000
Received: from mail.greenbytes.de ([5.10.171.186]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <stefan.eissing@greenbytes.de>) id 1cC6HM-0001Qj-Uk for ietf-http-wg@w3.org; Wed, 30 Nov 2016 14:54:38 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id BD01515A31C3; Wed, 30 Nov 2016 15:54:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1480517648; bh=BxFsrAcCxblPLpmwhopNF3umg2nFGKFzr2pMy4mIHL8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=N/2kcyPRCrNO+gDuLF5+LeVpNMdQg0cgiCdzWB+A8SfSxR6FTmglxQf2EREGay5x1 697m/RC+smHxA97LEJOWjpKAt1x/CBNagH2lljA4/PyLbL2KRznDX+jYFOl0ZB3r7O T8SN3J5f1V7pkF5O0mfOn9DJfapSuE/xDQQy5vXU=
Received: from [192.168.1.175] (unknown [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id BF38715A0251; Wed, 30 Nov 2016 15:54:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1480517646; bh=BxFsrAcCxblPLpmwhopNF3umg2nFGKFzr2pMy4mIHL8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=PNGo9CeqPm/zpvkO4owBMcFXdW3H+5BIlA0NaVvvJA4JHBugmbzCNArR2RlGranH1 1tnMv+mbC2ji1vUw6/HWPB6zQ+3LybZlwrWjV4sruvoiJ66po1ycHtaiRVXDmcliQr VeXrzEwn56zjpxcdCTRirwb5TfRHVBuSVGAYDiRs=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <CAPyZ6=KWvn8fMiOab5R_yMedovwo=c2QnGkewuAjKYBxO-5jrQ@mail.gmail.com>
Date: Wed, 30 Nov 2016 15:54:05 +0100
Cc: 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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F3F44070-A587-4B89-9DBB-ADDA6469CE4D@greenbytes.de>
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>
To: "tatsuhiro.t@gmail.com" <tatsuhiro.t@gmail.com>
X-Mailer: Apple Mail (2.3251)
Received-SPF: pass client-ip=5.10.171.186; envelope-from=stefan.eissing@greenbytes.de; helo=mail.greenbytes.de
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: AWL=0.302, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.899, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cC6HM-0001Qj-Uk cfb444fc25ae48b8e30c9140e8378c8b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Editorial Errata Reported] RFC7540 (4871)
Archived-At: <http://www.w3.org/mid/F3F44070-A587-4B89-9DBB-ADDA6469CE4D@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33048
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>

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>om>:
> 
> 
> 
> On Wed, Nov 30, 2016 at 10:29 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
> 2016-11-30 22:05 GMT+09:00 Cory Benfield <cory@lukasa.co.uk>uk>:
> >
> >
> > On 30 Nov 2016, at 13:04, Kazuho Oku <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
> 
>