Re: [quicwg/base-drafts] HTTP/3 priorities are too complex for a majority of implementations (#2739)

[Robin Marx <[e-mail]>]

I feel we need a bit more nuance for this statement though:

> Measurement indicates that <<50% of servers implement H2 priorities (https://github.com/andydavies/http2-prioritization-issues)

To my understanding, the servers probably -do- implement HTTP/2 priorities, they just don't function correctly. If I interpret @pmeenan's blogposts and our conversations, this is not due to bugs in the HTTP/2 prioritization, but due to implementations not using things like TCP_NOTSENT_LOWAT, or having caches in front of their servers, or general other bufferbloat-alike problems that prevent good re-prioritization. This issue will not be solved by just moving to a simpler scheme. Because we're using UDP and iiuc kernel interfacing for UDP does not allow large kernel buffers/people are only passing what's ready to send as the congestion controller is also in their control etc. this hopefully will be less of an issue independent of the used scheme. 

With regards to browsers having bad setups, I feel that by now we do have a much better grasp of what things *should* look like for the browser side (see Patrick's proposal). It's mainly a matter of getting people to change the browser code. For the life of me, I still don't understand why Chrome hasn't touched that code for years (see also: https://bugs.chromium.org/p/chromium/issues/detail?id=651538).


To re-iterate my point from yesterday: I like (semi-)#2700 because it allows new stacks to implement only the priority-based scheme without placeholders and inter-stream dependencies (send SETTINGS_NUM_PLACEHOLDER = 0). Existing stacks can be extended relatively easily to incorporate it (or fake it with internal placeholders, which is what we've been doing for tests and works well).  

So, my point: simply moving to a much simpler scheme will not automagically give better (re-)prioritization behaviour, nor is it needed to completely drop the tree-based stuff to allow easier up-front implementations. 

---------

To jump into the other conversation going on above: this sounds like the Polaris paper (and related work), see http://web.mit.edu/polaris/. This has been shown to work well, but it tricky to get right, and doesn't preclude the current setup from being useful in other situations.

Also, I feel this is a separate topic that might require a different issue to not take away from the core issue being discussed here. 

-- 
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/2739#issuecomment-494763363