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

[Robin Marx <[e-mail]>]

Thank you all for the comments.

While I agree with Lucas' point that not all streams in the priority tree have to exist yet (and that this is a nicer solution than buffering the priority frame), the fact that this can happen and that this should be treated as "unable to make progress" imo should be mentioned explicitly in the text then. 

The problem then indeed becomes that you get the situation described by Mike: there is no stream 3 yet, we don't know where it is in the tree, temporary 3 gets added as child of root node, stream 2 is now in effect a sibling of 1 instead of a child (since stream 3 is "unable to make progress"). This could be "briefly" but if the control stream is experiencing loss, it might last for 1RTT+, which might lead to some difficult to debug unwanted bandwidth allocations. 

The solution to that could indeed be to replicate stream 3's PRIORITY frame on the control stream as well, but that also feels a bit dirty... especially since a) this scheme is Chrome's default behavior for H2 and b) some of our tests indicate that this is a better default scheme than the current full round-robin one<sup>1</sup>. In this case, buffering the priority frame feels better to me. If we decide not to got for that route, I feel this use case (aka: "how to fake exclusive dependencies in H3") should be mentioned in the text. 

Summary of proposal: Either change to buffering behaviour or add additional text describing/clarifying A) non-opened streams can exist in the tree and B) how to fake exclusive dependencies. 

[1]: https://speeder.edm.uhasselt.be/www18/files/h2priorities_mwijnants_www2018.pdf


-- 
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-471989303