Re: [Editorial Errata Reported] RFC7540 (4871)

Ryan Hamilton <rch@google.com> Wed, 30 November 2016 15:27 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 035E2129454 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 07:27:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.497
X-Spam-Level:
X-Spam-Status: No, score=-8.497 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=-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 (2048-bit key) header.d=google.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 9cmVKsup2B1O for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 07:24:42 -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 5BDFC1294F1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 07:24:42 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cC6h2-0005Jq-2B for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Nov 2016 15:21:08 +0000
Resent-Date: Wed, 30 Nov 2016 15:21:08 +0000
Resent-Message-Id: <E1cC6h2-0005Jq-2B@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 <rch@google.com>) id 1cC6gu-0005FG-TD for ietf-http-wg@listhub.w3.org; Wed, 30 Nov 2016 15:21:00 +0000
Received: from mail-yw0-f178.google.com ([209.85.161.178]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <rch@google.com>) id 1cC6gn-0000LU-Pq for ietf-http-wg@w3.org; Wed, 30 Nov 2016 15:20:55 +0000
Received: by mail-yw0-f178.google.com with SMTP id t125so158739160ywc.1 for <ietf-http-wg@w3.org>; Wed, 30 Nov 2016 07:20:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2CQwMuSBeGCg0+rh1mSctERaRO3x1bCYNODDB5PoW4Y=; b=GknDNmUzOjLOiBPpdM/u46wIauTeiiJ5l9jbb89XoXmp1A/5Knwat55pHj9Lz7ucX8 UTFqy01lj5Ls8xgYzCKZlnE1KsFIwnJ2DOX9eLsCIODkMxCzPBUnrgvNouJUsOkX4fR+ JSnK6jLrTWIgyGwSKg+TWez6QButcXgHPgeG8oPdilLxYSuIDzLaRZd37r8s6kNE5Z+8 XsxOBO4TbNMp8tqdeRvlIUm5YIfkrduvrB+4lAekys2tpR2J9QAph8SxwgIuVvXglPGy sm3QpF+BNddyIHpNKz/fjMb7HU9b+zGrAegcD+ejBm89FFLoGge/Drv+raulnTTw0V+N KmgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2CQwMuSBeGCg0+rh1mSctERaRO3x1bCYNODDB5PoW4Y=; b=lV1E7/e/Z2o6u2j56ZX4W0Qtu8TRQwDIQcAks3tQNxxqpw69jVTwCczXh3HI5/+tMi BTbtzZwwClaz1RsndeanUXeUhnL3GwX//FbiyLYqvzaQZXa61JNbd9/UUReBlJpvjYGN +YVYVrHAoAO6JCCu8/dtxp7S8ivR6uTLPChVYy2FYQaJyUtUTukniKJrXTZE5QfJHRj6 S4W4XA6rTppvyd9covOPYKKh7vLfLkJRFWvByhfrdlLdgmG/69jckVBY1uLEBm4ELzfI EKQ0Iw8UqZsBzx+do9LphFDLB1jOGRpNch40cEtSvfuaptqTDVDnc5pr0VfTYcZadHhO 2zOA==
X-Gm-Message-State: AKaTC020rjBaEGos2y5oEyyhhIyHe+a/zk3BZ/sJV9TY8OmQtf03hi8OLuzD4cPwF3Eb8PXlgmktZnxowcD1BRWB
X-Received: by 10.129.79.207 with SMTP id d198mr36238506ywb.64.1480519227211; Wed, 30 Nov 2016 07:20:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.216.215 with HTTP; Wed, 30 Nov 2016 07:20:26 -0800 (PST)
In-Reply-To: <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> <F3F44070-A587-4B89-9DBB-ADDA6469CE4D@greenbytes.de>
From: Ryan Hamilton <rch@google.com>
Date: Wed, 30 Nov 2016 07:20:26 -0800
Message-ID: <CAJ_4DfQEYQr1OBepx1asM3BwJXHzmnLR089m2KwTtW-F5HPyEg@mail.gmail.com>
To: 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>
Content-Type: multipart/alternative; boundary="001a114da1509f86750542863e99"
Received-SPF: pass client-ip=209.85.161.178; envelope-from=rch@google.com; helo=mail-yw0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-6.5
X-W3C-Hub-Spam-Report: AWL=0.422, 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, RP_MATCHES_RCVD=-2.899, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cC6gn-0000LU-Pq 08f84e9b0a4d33a213d5de52a858ef01
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Editorial Errata Reported] RFC7540 (4871)
Archived-At: <http://www.w3.org/mid/CAJ_4DfQEYQr1OBepx1asM3BwJXHzmnLR089m2KwTtW-F5HPyEg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33049
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>

I completely agree. Priority is all about sending the most important data
first. Flow control is a distinct issue and mixing them together seems
complex and confusing in ways that would limit the effectiveness of
priority.

On Wed, Nov 30, 2016 at 6:54 AM, Stefan Eissing <
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>:
> >
> >
> >
> > 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>:
> > >
> > >
> > > 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
> >
> >
>
>
>