Subject: [quicwg/base-drafts] HTTP/3 priorities are too complex for a majority of implementers to implement (#2739)

From: ianswett <[email-masked]>
Date: Tue, 21 May 2019 16:11:42 -0700

A number of implementers have indicated a lack of interest(ie: I'll do something else for cases when I control both client and server) or complete unwillingness to implement existing HTTP/3 priorities.

I believe a core goal of HTTP/3 should be that the majority of implementations will support the specified priority scheme.  If that's not true, we should move priorities to an extension, but that may be a regression relative to HTTP/2, which is unappealing.

Measurement indicates that <<50% of servers implement H2 priorities(https://github.com/andydavies/http2-prioritization-issues) and clients use a fixed scheme they designed once and never changed. 

A key comment I hear repeatedly is that the tree structure is too complex, in particular requests depending upon requests.  The idea of proxy to origin using groups/placeholders for backend connections keeps coming up, but it's not actively used at the moment based on all input I've heard, so I heard a large amount of support for either making that an extension or optional in the same way push is optional in H3.

This is somewhat of a meta-issue, but it keeps coming up and I believe it's extremely important to achieve consensus on something that will be implemented.  As everyone keeps reminding me, that's where we failed with H2.  Let's not let a coin flip decide this time.

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 21 May 2019 23:16:03 -0700

How much is there to gain by complex priorities where the browser has to guess vs javascript controlled lazy loaders that now the sites requirements exactly?

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

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 22 May 2019 02:19:28 -0700

I agree with the points Ian has captured in the issue.

@mikkelfj I don't really understand your question. To use a simple case, are you asking about the difference between the browser's resource loading strategies for HTML vs Fetch/XHR? 

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 03:46:21 -0700

@LPardue actually I mixed two concepts in my question.

I'm asking generally, how much benefit does a priority tree provide over not having one, given that no-one bothers to support them in HTTP/2.

And second, perhaps it is not that important for performance sensitive websites because they use javascript to defer loading other javascript until first view images are loaded, and also to load more images when the user scrolls.

I'm not familiar  with Fetch/XHR. The lazy load techniques that I am referring to has to do with only making resources visible to the browser when needed by injecting script and image tags at opportune times and in an opportune order.

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

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 22 May 2019 04:17:22 -0700

Thanks for the clarification. I'm not an expert is the area you describe, so I'll let others step in if they want.

The approach sounds fragile because several factors may work against it. 

Assume a model where a HTTP/2 or HTTP/3 server is best placed to make use of its available bandwidth based on its view of the client wants and the availability of response data. If defering load means that a client holds back requests, then the server knowledge is limited. In this case, if the server experiences delays in accessing image data, it can't serve the lower priority items in the available time window.

Another problem with the approach is connection coalescing. A website may not be aware that the browser is reusing a connection for different domains.

I think prioritisation is important. However, I think the user agent is able to articulate its requirements without a depedency tree. A simpler model of prioritisation may improve the likelihood that the server bothers to use it in decision making. 

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 11:21:58 +0000 (UTC)

I have practical experience with this. I was working on a startup where page load times consistently ranked very high using this approach. It was combined with redirecting resources to a CDN network off the main server and using image scaling to match the target device.

The downside is that it does require javascript and modifications to web content. In this case it was limitd to a single config object, a very small javascript loader, and tag prefixing like <cdn:img ...> instead of <img >.

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

---

From: Robin Marx <[email-masked]>
Date: Wed, 22 May 2019 04:28:55 -0700

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

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 22 May 2019 04:33:09 -0700

It's good that there are ways to improve performance in such ways. However, I think that the HTTP/3 layer should allow prioritisation of resource loading. That way it applies to all user agents, not just those that have a DOM and or JavaScript engine.

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

Agreed.

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

---

From: Patrick Meenan <[email-masked]>
Date: Wed, 22 May 2019 06:32:11 -0700

The other big change discussed yesterday by moving away from a tree we can move from a relative priority structure where each request needs to know about the others on the same connection to an absolute priority scheme where priority can be tied to the request itself without extra knowledge. Within the HTTP/2 implementation itself it may not make a big difference but exposing it as an API on the client and server side becomes much easier (and it allows for merging of priority decisions made on the client and server sides). 

A simpler API could always be mapped to the tree but managing equivalent mappings on both ends can become unwieldy if you have multiple clients you don't control or talk to servers you don't control.

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