Re: [quicwg/base-drafts] PRIORITY frame on control stream referencing unopened request stream (#2502)

[Robin Marx <[e-mail]>]

Again, thanks everyone for the interesting discussion and Pat for weighing in :) 

I've been thinking about it a bit more and have found that my earlier suggestion "add as direct child of the last added node (could be root) with weight 1" simply does not work... 

To make discussion easier, I've made a small diagram:
![exclusivity_problems](https://user-images.githubusercontent.com/2240689/57520389-d36ea380-731d-11e9-825a-106553366ef3.png)

In S5 you can see that such a scheme would create a circular dependency for a (short) time. 

I've been considering it further and these are possible options that do seem to work and might be better:
- Add as child to the root with weight 1 instead of 16
- Add as child to the "least important placeholder" with weight 1 (e.g., the placeholder receiving the least bandwidth) if there are placeholders, if not: fallback to root. (this assumes placeholders always remain and always have some path back up to the root)
- Add as child to the currently "most important resource" (resource receiving most bandwidth): non-optimal and can lead to weird situations, BUT at least prevents the most important resource from being interrupted (e.g., in the example, this would add the red node as child of the HTML, since that is the one getting the bandwidth). 

We could also do all three (first try placeholder, then try resource, then fall back to root). 
This could use a fair amount more of working out the edge cases though

---------------------------------------------------------------------------------------

Then, I took a step back and thought about: do we really need exclusive priorities? 
The main goal is to keep the option to daisy-chain resources. This is still possible today: just add as a child to another resource. 
What we miss with non-exclusivity is the option to then re-prioritize when a new, more important resource needs to be inserted in the daisy-chain (it cannot be injected somewhere in the middle as an only child, only as a sibling, see also the HIGHEST-subtree in P3 and P4 in the image below for a similar situation). 

As I understand it though, this re-prioritization is **not needed within similarly important resources** (e.g., CSS does not have to necessarily overtake Fonts, just images). 
Using that, I've tried to cobble together a new scheme that simulates Chrome's approach using what we have available today (see P2 in the image below): 
![exclusivity_light](https://user-images.githubusercontent.com/2240689/57521628-18480980-7321-11e9-8aa9-842d62744fc3.png)


This setup allows re-prioritization between the placeholders, but **not** within the same "importance bucket": less fine-grained than exclusive priorities, but quite workable. (e.g., in P4+5, CSS is discovered later, after the image. However, due to the placeholders, it can be added and is sent before the images, but NOT before the font, as was the case in HTTP/2's P3). 

Put differently: we cannot have P3, but at least P5 is not P4. 

---------------------------------------------------------------------------------------

In conclusion:
- Fairly small updates to the default behavior could give us most of the improvements we are looking for
- Daisy-chaining and re-prioritization (within a certain degree of granularity) is still possible in the current scheme







-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2502#issuecomment-491246513