Re: [quicwg/base-drafts] HTTP/3 with strict priorities (#2700)

[Lucas Pardue <[e-mail]>]

> This is an important aspect of this discussion. Extant HTTP/2 stacks can use the current (ID-20) version of HTTP/3 prioritization with few changes. Radical departures from it will inevitably result in more work for them -- not just in programming effort, but also to research how to use the new prioritization scheme effectively.

Which stacks do you have in mind? 

A survey of user agents indicates that the priority trees were designed once and not iterated on. Developers or users have little control to modify behaviour here. 

On the server side, the priority tree is an input into the logic. If the servers' processing is tightly coupled to the input scheme, that would suggest difficulty in trying out alternatives, which is maybe an indicator to the feasible success of prioritisation extensions.

As Cloudflare recently blogged about, our extant HTTP/2 stack has many problems in trying to deliver on the intended design expections. However, a broad set of those problems had nothing to do with the priority tree itself.

Yes, we don't want to throw the baby out with the bathwater. However, we should also be aware that there's going to be a ton of work to determine how HTTP/3 performs in real-world usage scenarios. Predicting the effects of HTTP/3's design on that work is hard.



-- 
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/pull/2700#issuecomment-493503003