W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: [Editorial Errata Reported] RFC7540 (4871)

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>

2016-12-01 8:03 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> 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.
>> 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
Received on Thursday, 1 December 2016 04:01:25 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 December 2016 04:01:28 UTC