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

[Kazuho Oku <[e-mail]>]

@rmarx Thank you for your comments and for the fantastic research (maybe I should have said this earlier)! 

I think we are really discussing two issues here: a) how the server should behave when the client does not provide priority information at all, and b) when priority information is not available due to a packet loss. To resolve both the issues (I do share the concerns), maybe we should better have two different issues opened for each.

For _b_ (which IIUC is the original topic of this issue), I would argue the following.

As a general statement, mis-prioritization happens until the lossed packet is retransmitted and received. Therefore, the impact is small.

That said, if the client uses Firefox-like prioritization scheme (i.e. grouped by placeholders), it is fair to assume that unresolvable nodes appear only during the very early stages of the connection. During that time, there is higher probability of receiving a request that should be given higher priority than than the precedence requests (i.e. request for CSS arriving after request for HTML). That's very different from what you see in later moments (i.e. requests for things like images and async javascript files arrive, that require lower priority).

If the client uses Chrome-like prioritization scheme (i.e. daisy chaining), I now think that we should recommend the client to send a PRIORITY frame on the request stream to specify the parent node, _and also transmit the same information by sending a PRIORITY frame on a control stream_, then sending another PRIORITY frame to indicate that a sibling is converted to a child of the newly created node. By transmitting the same information on both streams, the server would never see an unresolvable node in the prioritization tree. So why not recommend clients do that, instead of trying to figure out how the server should compensate for the lack of the information?

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