Re: [Editorial Errata Reported] RFC7540 (4871)

[Kazuho Oku <[e-mail]>]

Hi,

2016-12-01 8:03 GMT+09:00 Martin Thomson <[e-mail]>:
> On 1 December 2016 at 00:05, Cory Benfield <[e-mail]> 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