Re: [Editorial Errata Reported] RFC7540 (4871)

Kazuho Oku <kazuhooku@gmail.com> Wed, 30 November 2016 13:11 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 3F881129468 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 05:11:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.997
X-Spam-Level:
X-Spam-Status: No, score=-7.997 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, RCVD_IN_SORBS_SPAM=0.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=gmail.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 2YaFmi_Jjm1L for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 05:11:41 -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 B1CBB1294EC for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 05:08:35 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cC4ZD-0005WD-HM for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Nov 2016 13:04:55 +0000
Resent-Date: Wed, 30 Nov 2016 13:04:55 +0000
Resent-Message-Id: <E1cC4ZD-0005WD-HM@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 <kazuhooku@gmail.com>) id 1cC4Z6-0005Uy-TK for ietf-http-wg@listhub.w3.org; Wed, 30 Nov 2016 13:04:48 +0000
Received: from mail-wj0-f194.google.com ([209.85.210.194]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <kazuhooku@gmail.com>) id 1cC4Yz-0004e6-PV for ietf-http-wg@w3.org; Wed, 30 Nov 2016 13:04:43 +0000
Received: by mail-wj0-f194.google.com with SMTP id xy5so22133548wjc.1 for <ietf-http-wg@w3.org>; Wed, 30 Nov 2016 05:04:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kk1Dkquj1H4zyy+krz0gucuTNCPxNRQm53wVDLYc/eM=; b=aU9js7MhQskZWMYAzviZy0wj8doxbT5eqVeXLaHpzm+16bOUNuDJWGV98XCWxkXHXn Jt+wiBNZ4rciaoV0RC36GgnsUIsGfhzEpqMRpQN7O7EGWH5MLe/EFrQvFUmTe4B9TMNx 7sWk6tplPQZbjfncMiWF8/SMqwJ3HXRNpZ8S9wvpDhJhih7S8wp7xlZH5nkf+ZZr4o+V gw5oGOzwPwTiJ/EuJNoyMalaF4RpyrBzKuICSDW95lGKo9LLhUrui7/S4xdQOheGIvlA DwT+5XMqgrqFI9ZrLxSfqcbmI150gPnGqGQ3NGNbulcb4UWnL97WpdFMIufJu94IHKjl zzLw==
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=Kk1Dkquj1H4zyy+krz0gucuTNCPxNRQm53wVDLYc/eM=; b=Wzl+YGmNpnvESSyF+Kp7iW8NqHxEDPeW15WGtTZRdKBoU+if+v6DtzbB6RmjMzSX3G TsdDdc1zxpdMMALTPQTLDuc06I7IY499v/HLGINH00mc9wJCcE/bFTCQc5gdZdqLRrwy 6wc4YKDsX/cS4VP9+A2dODP742wG/+Z0C8ICOLcrr7uj1v99hstuW9FptWjgo4WgJjgq fnBOH9aXk5AS9cDd8v1rhxNy0Vt8EIA6kP6h992pRPkkaW4UQxVhA5NqukcAH/rbDf9o cbF7rQkeSmZZIltYB0VTJZWk7xcT9P6V68anBdcDJ0RhHXtChqWeDiG/es9E/M+TPOag PWIA==
X-Gm-Message-State: AKaTC00YA/PsbjHHGo19PUxFEYWYLHDjrB8J5BXULqC/1sXeAWZ9ZgyAUimUPY7hwpbIS7YQ0AUgXsT1bwBKig==
X-Received: by 10.194.172.100 with SMTP id bb4mr27077260wjc.53.1480511054689; Wed, 30 Nov 2016 05:04:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.32.1 with HTTP; Wed, 30 Nov 2016 05:04:13 -0800 (PST)
In-Reply-To: <03C57CE4-E61A-4BF6-A976-2191EB4B127C@lukasa.co.uk>
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>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 30 Nov 2016 22:04:13 +0900
Message-ID: <CANatvzzQZ_isxmd3Ne41QxE2s-sYsrksME+T0RtchM-K1b0DwA@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: 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="089e013c6b2a803dcb05428457a8"
Received-SPF: pass client-ip=209.85.210.194; envelope-from=kazuhooku@gmail.com; helo=mail-wj0-f194.google.com
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: AWL=-1.408, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cC4Yz-0004e6-PV e21fc95172ec7d093591fd48e0423f4d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Editorial Errata Reported] RFC7540 (4871)
Archived-At: <http://www.w3.org/mid/CANatvzzQZ_isxmd3Ne41QxE2s-sYsrksME+T0RtchM-K1b0DwA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33042
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>

2016-11-30 21:49 GMT+09:00 Cory Benfield <cory@lukasa.co.uk>:

>
> > On 30 Nov 2016, at 09:35, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >
> > On 30 November 2016 at 19:41, Cory Benfield <cory@lukasa.co.uk> wrote:
> >> What happens if both stream A and B are blocked? Should my server
> endeavour to serve dependent streams in that case?
> >
> > I guess so.  You don't want to completely stall out.  Obviously, if A
> > and B have a parent with siblings that aren't blocked, then you
> > continue there, but if everything is stalled, then I guess it's OK to
> > make progress on any stream.
> >
> > You could probably devise some sort of scheme where you pick the
> > stream using some algorithm or other - maybe based on some best-fit
> > criteria.  But I'd say that it doesn't matter at that point: if we
> > assume that all streams that aren't blocked depend on blocked streams,
> > then none of them will be useful to the other side until those blocked
> > streams finish.  All you are doing is avoiding having a completely
> > wasted connection.
>
> So presumably the sensible heuristic for this is to do the following logic:
>
> 1) Select the streams that depend on stream 0 that are not blocked,
> completed, or idle, and add them to set A.
> 2) For each stream dependent on stream 0 that is completed or idle,
>     a) Select their children that are not blocked, completed or idle,
> adjusting their effective weights as detailed in RFC 7540, and add them to
> set A.
>     b) If no streams were selected in part a), but there are streams that
> are completed or idle streams, repeat step 2) for the children of those
> streams.
> 3) If set A is empty, repeat the above but treat streams that are blocked
> as though they are completed or idle (that is, allow their children to be
> selected to be served).
>
> I am not sure how many server/intermediary implementations actually
> implement priority in this manner. It’d be interesting to hear what the
> others do.
>
>
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.


> Cory
>
>
>


-- 
Kazuho Oku