Re: [Editorial Errata Reported] RFC7540 (4871)

Kazuho Oku <> Thu, 01 December 2016 04:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92FF3129693 for <>; Wed, 30 Nov 2016 20:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.396
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wU0nAPtGJNa8 for <>; Wed, 30 Nov 2016 20:05:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03C05128874 for <>; Wed, 30 Nov 2016 20:05:16 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCIYv-00029n-Ko for; Thu, 01 Dec 2016 04:01:33 +0000
Resent-Date: Thu, 01 Dec 2016 04:01:33 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCIYn-00028w-1M for; Thu, 01 Dec 2016 04:01:25 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cCIYf-0006jk-V0 for; Thu, 01 Dec 2016 04:01:19 +0000
Received: by with SMTP id g23so32289793wme.1 for <>; Wed, 30 Nov 2016 20:00:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id m9mr29827953wmi.88.1480564850906; Wed, 30 Nov 2016 20:00:50 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 30 Nov 2016 20:00:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Kazuho Oku <>
Date: Thu, 01 Dec 2016 13:00:49 +0900
Message-ID: <>
To: Martin Thomson <>
Cc: Cory Benfield <>, RFC Errata System <>, Mike Belshe <>, Roberto Peon <>, Ben Campbell <>, Alissa Cooper <>, Alexey Melnikov <>, Patrick McManus <>, Mark Nottingham <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a114c1ca2015dee054290de63"
Received-SPF: pass client-ip=;;
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: 1cCIYf-0006jk-V0 aa0f0a5de9cb7b34f7097cb1130b1026
Subject: Re: [Editorial Errata Reported] RFC7540 (4871)
Archived-At: <>
X-Mailing-List: <> archive/latest/33059
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


2016-12-01 8:03 GMT+09:00 Martin Thomson <>:
> On 1 December 2016 at 00:05, Cory Benfield <> wrote:
>> My understanding of what Martin is suggesting is that that isn’t true:
>> blocked streams do not distribute their weight to their dependants.
>> 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