Re: [Editorial Errata Reported] RFC7540 (4871)

[Mark Nottingham <[e-mail]>]

Conversation seems to have concluded - this one is REJECT, correct?

Cheers,


> On 1 Dec. 2016, at 10:03 am, Martin Thomson <[e-mail]> wrote:
> 
> 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 :)
> 
> 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.
> 

--
Mark Nottingham   https://www.mnot.net/