Re: [Editorial Errata Reported] RFC7540 (4871)

Kazuho Oku <kazuhooku@gmail.com> Thu, 01 December 2016 04:05 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 92FF3129693 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 20:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.396
X-Spam-Level:
X-Spam-Status: No, score=-9.396 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=-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 (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 wU0nAPtGJNa8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 20:05:17 -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 03C05128874 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 20:05:16 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cCIYv-00029n-Ko for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Dec 2016 04:01:33 +0000
Resent-Date: Thu, 01 Dec 2016 04:01:33 +0000
Resent-Message-Id: <E1cCIYv-00029n-Ko@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 <kazuhooku@gmail.com>) id 1cCIYn-00028w-1M for ietf-http-wg@listhub.w3.org; Thu, 01 Dec 2016 04:01:25 +0000
Received: from mail-wm0-f65.google.com ([74.125.82.65]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <kazuhooku@gmail.com>) id 1cCIYf-0006jk-V0 for ietf-http-wg@w3.org; Thu, 01 Dec 2016 04:01:19 +0000
Received: by mail-wm0-f65.google.com with SMTP id g23so32289793wme.1 for <ietf-http-wg@w3.org>; Wed, 30 Nov 2016 20:00:57 -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=/FWLa82zQT9dLl8YDaK+xbBY0SpCwAxseWBedfOKgoE=; b=ON3WcDBV/07smlv4yU14PZdPlbDdCEKMynQAZqVmZyo73cMOvCAuzc6mzzDlD4X51v 2vkoNL9M/BFcjeQS+h0WXYshhEZ6IEShMTbLeaxag2GxHbThCf+k+ges2qXPBcEGoRcy wj76UGqgeRRdqRLXer7oJi8DUCC67GIMBiUeZXSCm1kK7k+2odoR+c/+zlgtGjpHwMJO EXRyTAvG1ePSBqWPTMWBUkXOnHO454s37Gq02Hy7XZMCUmBWKYaDSwPCposIEsMDmx9D w1d6Eyro7L8LZiWdaw6uWRmo0IydcNo3Y5rpfzcB1B4eohjQA3mr8a4OAV00uZnZuty8 sbHw==
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=/FWLa82zQT9dLl8YDaK+xbBY0SpCwAxseWBedfOKgoE=; b=JQ1y2IjdwIuK7QBY5JYT3K2BB8zi5DwSN7RUlFdmI/KSL3jBRXGWSIYK8reK9+JaCn vdQLw/OXm5f05lGosiMpVXenYvHvhzZNTW2jkYs6OJ5HKeD3l41ESSX1Xoc9I2sJm+Z0 6BTN9ObUpeoWyYZYJUxFRi1Pb7xQuT8Z5Yz38Kg/QlQrc3BCaPMtaE/MziL6jmY964n5 ayG0C0E7nNQ/OoD9wC2QIVCRvG5G3xRo8yQXV/TcJa/TmSpilKqHudauSl1N491TXXNu Q+Xrrnmxal2H3YyYB4Zas/8uVT+4rrqmS/MOwcF1vT+I6ABbMgoNTLMSyxA4sSfT1BTB hi0g==
X-Gm-Message-State: AKaTC004+MFvkrz64jMvLUkMIiguiEa6Crqffa1F2piay23I7e1upsImdPSeODJUHOSrY8dOHjf3hKbHYHQKiA==
X-Received: by 10.28.71.137 with SMTP id m9mr29827953wmi.88.1480564850906; Wed, 30 Nov 2016 20:00:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.32.1 with HTTP; Wed, 30 Nov 2016 20:00:49 -0800 (PST)
In-Reply-To: <CABkgnnXXLUfC9q5YSQjRWZOqyPevkVrPT2VKvUAEK7caxQDDng@mail.gmail.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> <CABkgnnXXLUfC9q5YSQjRWZOqyPevkVrPT2VKvUAEK7caxQDDng@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 1 Dec 2016 13:00:49 +0900
Message-ID: <CANatvzwGSLLENx6kXdBe6RUTP7XghhM5=H6ezXzeMehkeYye5A@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Cory Benfield <cory@lukasa.co.uk>, 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=001a114c1ca2015dee054290de63
Received-SPF: pass client-ip=74.125.82.65; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f65.google.com
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-0.762, 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: titan.w3.org 1cCIYf-0006jk-V0 aa0f0a5de9cb7b34f7097cb1130b1026
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Editorial Errata Reported] RFC7540 (4871)
Archived-At: <http://www.w3.org/mid/CANatvzwGSLLENx6kXdBe6RUTP7XghhM5=H6ezXzeMehkeYye5A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33059
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>

Hi,

2016-12-01 8:03 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>om>:
> On 1 December 2016 at 00:05, Cory Benfield <cory@lukasa.co.uk> wrote:
>> My understanding of what Martin is suggesting is that that isn’t true:
>> blocked streams do not distribute their weight to their dependants.
However,
>> that’s also what the Python Priority implementation does.
>
> And this was my error in writing up the errata and my earlier emails.
> The spec is clear that there is no functional distinction between
> blocked and finished.  The original text is correct.
>
> It's pretty obvious however that it's not clear.  I'd answered on the
> basis of first principles, and that was an error on my part.
>
> Mike's algorithm is almost correct, but I would revise it.  Starting
> at the top level:
>
> Given a set of dependents of S,
>   find all S where not TreeBlocked(S) as S'
>   allocate resources to S' proportional to their weights
>     for a stream s in S', if StreamBlocked(s), repeat algorithm with
> its dependents
>
> Not treating closed as special keeps this simple.  If you were to
> treat closed as different to blocked, then you have the issues that
> Cory was digging into.
>
> Kazuho points out:
>> I also do not see why it would be beneficial to treat them [closed
streams] differently.
>
> It's beneficial if you have other streams that are not blocked that
> don't have dependencies.
>
> Imagine that you have two HTML files and then images for each as
> dependents.  If one HTML file is blocked, then there is potentially
> less value in loading the images that depend on it than there is in
> making progress on the other HTML file.  Now, that is arguably not
> valuable because HTML/image dependencies are sort of loose, but if you
> have an application that has absolute dependencies (I can't use this
> until you give me that) and other constraints (not enough memory to
> buffer), then you can see a way to treating closed and blocked
> differently.
>
> Of course, that isn't what the spec says and we don't get to change that
:)

Thank you for explaining what you had in mind.

That makes sense, and _if_ we are going to fix the issue, I'd prefer adding
a feature to group multiple streams into one so that other streams can
depend against a group of streams.

In H2O, we internally promote CSS and JavaScript files in such way, e.g.:

       +- CSS1 -+

 root -+- CSS2 -+- HTML - ...

       +- JS   -+

I believe that adding an ability to designate this kind of dependency would
be better than adding special casing for blocked streams.

> BTW, in answer to what people suggested about flow control, that is
> only one reason a resource might be blocked.  A resource might be
> blocked because the server hasn't finished building it, that might be
> IO or processing.



-- 
Kazuho Oku