Subject: Re: [Editorial Errata Reported] RFC7540 (4871)

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Dec 2016 20:33:40 +1100

On 1 December 2016 at 15:00, Kazuho Oku <[email-masked]> wrote:
> 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.

Yeah, Patrick decided that he would use weights to fix that.  In your
example, all the HTML would be dependent on an empty node that has
weight 1, which would be adjacent to the JS/CSS.  In theory the HTML
does get some share.

I think that much more complexity and we might as well just upload
javascript for the server to run.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 1 Dec 2016 10:21:00 -0500

> weight 1, which would be adjacent to the JS/CSS.  In theory the HTML

and I have to say that in general I have a preference for "some small
share" systems rather than strict ordering. It tends to turn priority
inversion problems from deadlocks into performance corner cases. Much safer.

> javascript for the server to run.

:) - that's the kind of thinking that gave us PAC.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Dec 2016 14:12:42 +1100

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

Cheers,

> On 1 Dec. 2016, at 10:03 am, Martin Thomson <[email-masked]> wrote:
> 
> On 1 December 2016 at 00:05, Cory Benfield <[email-masked]> 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/

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Dec 2016 17:34:22 -1000

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

Please

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Dec 2016 14:35:24 +1100

RFC Editor, this errata is REJECTED.

Cheers,

> On 30 Nov. 2016, at 3:33 pm, RFC Errata System <[email-masked]> wrote:
> 
> The following errata report has been submitted for RFC7540,
> "Hypertext Transfer Protocol Version 2 (HTTP/2)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7540&eid=4871
> 
> --------------------------------------
> Type: Editorial
> Reported by: Martin Thomson <[email-masked]>
> 
> Section: 5.3.4
> 
> Original Text
> -------------
> For example, assume streams A and B share a parent, and streams C
> and D both depend on stream A. Prior to the removal of stream A,
> if streams A and D are unable to proceed, then stream C receives
> all the resources dedicated to stream A. If stream A is removed
> from the tree, the weight of stream A is divided between streams
> C and D. If stream D is still unable to proceed, this results in
> stream C receiving a reduced proportion of resources. For equal
> starting weights, C receives one third, rather than one half, of
> available resources.
> 
> Corrected Text
> --------------
> For example, assume streams A and B share a parent, and streams C
> and D both depend on stream A. When A is complete, streams C and
> D receive all the resources that would be allocated to stream
> A. If stream D is unable to proceed, stream C shares resources
> with stream B. Assuming equal starting weights on all streams,
> this means that streams B and C receive an equal share.  However,
> if stream A is removed from the tree, the weight of stream A is
> divided between streams C and D. With stream A removed and stream
> D unable to proceed, stream C receives a reduced proportion of
> resources. For equal starting weights, C receives one third,
> rather than one half, of available resources.
> 
> Notes
> -----
> The example was incorrect.  Dependent streams do not receive resources if their parent is blocked; they only receive resources once the parent is complete.
> 
> Note that I didn't correct the common misunderstanding regarding the third here.  That might be further improved by doing the math.  That is:
> 
> Before removal: A=N (C=N, D=N), B=N;
> After removal: B=N, C=N/2, D=N/2;
> Therefore viable streams are B=N and C=N/2 meaning a total pool of 3N/2.  The resource proportion allocated to C is therefore (N/2)/(3N/2)=1/3.
> 
> But that would probably need an entire section for the example, rather than a single paragraph.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7540 (draft-ietf-httpbis-http2-17)
> --------------------------------------
> Title               : Hypertext Transfer Protocol Version 2 (HTTP/2)
> Publication Date    : May 2015
> Author(s)           : M. Belshe, R. Peon, M. Thomson, Ed.
> Category            : PROPOSED STANDARD
> Source              : Hypertext Transfer Protocol Bis APP
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
>