Subject: [quicwg/base-drafts] Remove PRIORITY (#2924)

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Jul 2019 14:38:57 -0700

For discussion, see #2922.

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

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 22 Jul 2019 22:45:55 -0700

An attempt to summarise some of my points stated on the PR:

Prioritisation of contending data egressing from a QUIC endpoint is an important property. In HTTP/3, the most applicable use case is concurrent response data. 

Considering how well this property is achieved, H2's prioritisation scheme - frame-based tree building requiring chatty exchanges of signals - in practice offers little demonstrable advantage over its anithesis - static absolute priorities. Worse still the challenges of realizing the flexibility of the dependency tree has led to static priority structures that are built the same way every time. One could argue that the success criteria for H2's prioritisation is abysmal because it has been shown that doing nothing is better than doing something*.

Research has shown that prioritisation is maximally effective when adapted to the needs of the application instance (aka specific web page). However, experience has shown that using frame-based tree building to do this is unachievable across a meaningful population of HTTP implementations within the lifetime of a protocol generation. Therefore, it is undesirable to port the same system to the next generation unless it is expected that the present issues can be fixed or corrected. No evidence of that has been presented.

Removing frame-based tree building does not remove all prioritisation signals. It reduces the amplitude of the signal but the waveform is still there is the form of request generation order and resource type. Enhancing this signal with deployment experience is the next step, which may or may not need to happen immediately and may or may not result in a single answer.

* admittadly in some, not all, cases.

-- 
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/2924#issuecomment-514062888

---

From: Robin Marx <[email-masked]>
Date: Tue, 23 Jul 2019 03:05:57 -0700

I really like your signal/waveform analogy Lucas, so I'll try to use it to make my point as well.

You view the removal of client-side signaling as just lowering the amplitude of the waveform. I view it more as taking too few samples to still satisfy the Nyquist theorem. In other words: we are indeed still able to reconstruct _something_ from the signals server-side, but the result doesn't (necessarily) look like the original anymore. This loss of information might be acceptable in some/most cases (important: acceptable, not optimal), but can be detrimental in an (important) subset of setups. 

I am mainly worried about the impact on more advanced recent and proposed features, such as preload/prefetch, async/defer and priority hints. These features were explicitly added to improve (load) performance and they are difficult to adhere to without client-side scheduling. I predict that removing prioritization from H3 without a fallback will lead to performance-minded people having to provide 2 different versions of their sites, 1 for H2 and 1 for H3. For example, the H2 version can have async/defer/preloads mentioned in the <head> of the HTML, the H3 version without priorities probably shouldn't. 

To also address your last "devil's advocate" from the other thread (https://github.com/quicwg/base-drafts/pull/2922#issuecomment-513989715): yes, FIFO willl work and won't be super-detrimental in most cases. However, it's been stated several times before that for H3 (and QUIC) to be successful and find adopters, it needs to have demonstrably better performance than H2/TCP. You will not get that from a simple FIFO and also not from more complex server-side-only heuristics based on user-agent + content-type (your "low amplitude" signal). If you want H3 to outperform (best-in-class) H2, I feel we need **more** signals, not less. And yes, much of H3's perf benefits will come from QUIC and 0-RTT etc. but even the Google paper quotes just 8% (at best) and those benefits are not limited to QUIC (e.g., TCP fast open, TLS 1.3 early data). The current discourse seems to be you agree that the performance would be worse than for H2, but that that's not an issue. I have a hard time understanding that point of view. 

In summary, I do not feel that server-side-**only** prioritization is a workable fallback solution (https://github.com/quicwg/base-drafts/pull/2922#issuecomment-513987999) (except maybe for implementations that were broken to start with... https://github.com/quicwg/base-drafts/pull/2922#issuecomment-513983658) and while sticking our heads in the sand on this might allow us to "ship" QUIC and H3 "on schedule", I doubt the value of that in the long run. I'm fine with removing H2's priority system, but shipping H3 without a decent replacement is [madness](https://resize.rbl.ms/simage/https%3A%2F%2Fassets.rbl.ms%2F17438671%2F980x.gif/980%2C880/ILf9gZME9keiTx7T/img.gif). 

-- 
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/2924#issuecomment-514144677

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 23 Jul 2019 11:49:30 -0700

> I am mainly worried about the impact on more advanced recent and proposed features, such as preload/prefetch, async/defer and priority hints. These features were explicitly added to improve (load) performance and they are difficult to adhere to without client-side scheduling. I predict that removing prioritization from H3 without a fallback will lead to performance-minded people having to provide 2 different versions of their sites, 1 for H2 and 1 for H3. For example, the H2 version can have async/defer/preloads mentioned in the head of the HTML, the H3 version without priorities probably shouldn't.

I agree with concern but not the predicted outcome. Given the number of problem H2 prioritization implementations, and the relative slugisshness in them getting fixed, we have not seen a proliferation of workaround versions of websites that solve these problems.

Order of request is a signal and in an ideal world this helps build a suitable response output queue from a server. But to backtrack a little, it is *hard* to instruct the UA , via HTML, to do this correctly.  Element decorations like preload/prefetch act as convenient runaround method, which helps to avoid requiring restructuring of HTML, by giving a supplementary signal to the server. I agree that such signals are desirable for actual applications and what I'd like to achiieve is a common form of this signal[1]. However, I don't have knowledge of the proportion of sites that are actively impacted by poor structuring.  We can't fix all problems for all people, the failure of H2's flexible toolkit demonstrates that. Therefore, as a group it might help to come to an agreement on what parity and equivalent performance actually looks like.

[1] footnote: on the server-side we base some prioritisation decision on our understanding of how the in-flight prioritisation tree is representing the UAs intent. This is a fragile approach for many reasons. Further, we don't yet know how H3 trees would look exactly, and so there is opportunity for error that affect the performance. Hoping that we'll fluke things and get stuff "just right" is an unfortunate position to be in. So I support simple or minimal signals - including some above the inherent request ordering I mentioned in my first comment.

-- 
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/2924#issuecomment-514336181

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 23 Jul 2019 20:36:28 -0700

Removing PRIORITY from the drafts while we reason about the priority scheme (if any) we want for HTTP/3 sounds good to me.

That being said, I think it's important to have some mechanism for the client to assist the server in providing resources in the best order. At the same time, it's clear that the HTTP/2 dependency tree is overly complex. As a result, something like pmeenan's scheme sounds great.

-- 
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/2924#issuecomment-514466198

---

From: MikkelFJ <[email-masked]>
Date: Wed, 24 Jul 2019 00:06:54 -0700

For reference, here is the pmeenan scheme: https://github.com/pmeenan/http3-prioritization-proposal

The scheme states the bandwidth splitting is implementation dependent. That makes me wonder if Weighted Round Robin scheduling would make sense - it is certainly something I would build into the core transport scheduler based on app provided priorities. It would be neat if H/3 tapped into such a framework.

This means the low priority content is not 100% excluded by higher priority content such that small content can get through eventually. But likely there could be some tunable parameter for how much residual bandwidth is reserved for the next lower priority. E.g. 0% or 10% etc. 

-- 
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/2924#issuecomment-514508478

---

From: Robin Marx <[email-masked]>
Date: Wed, 24 Jul 2019 07:09:12 -0700

There was a side meeting on prioritization in general at IETF 105 in Montreal. My personal notes (subject to errors and misinterpretations) are attached.

My main takeaways: 
- Will probably drop H2's scheme (tbd in the HTTPbis meeting later)
- Will probably move to extension-based setup to de-couple priorities from H3's core text and to stop it from being a blocker to launch QUIC/H3
- Will add a new SETTINGS parameter or similar setup so endpoints can indicate which prioritization setup they are using / want to use
- Hope to have enough people implement one or more of the extensions before H3 launches. Proof of implementation is expected to help determine which extension "wins"
- There is some disagreement on whether a frame-based or header-based design is best
- Should look at potential interop / backporting issues and opportunities for HTTP/2 as well

[IETF105Montreal_sidemeeting_notes_24july2019.txt](https://github.com/quicwg/base-drafts/files/3427181/IETF105Montreal_sidemeeting_notes_24july2019.txt)

-- 
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/2924#issuecomment-514647866

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Jul 2019 08:16:34 -0700

> Will add a new SETTINGS parameter or similar setup so endpoints can indicate which prioritization setup they are using / want to use

This seems a little controversial.  Patrick expressed a desire to limit the number of potential schemes.  One of the source of the failings in h2 was the way that it enabled proliferation of schemes.  On the converse side of this, Alan said that if implementation is consistent across servers, then allowing variation in clients is fine.  I would add that this is not consistently implemented.

Meta-point: I do want to have a scheme, I just have low expectations of our ability to succeed in the time frame we aspire to.

-- 
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/2924#issuecomment-514676082

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 24 Jul 2019 11:23:02 -0700

On Wed, Jul 24, 2019 at 8:16 AM Martin Thomson <[email-masked]>
wrote:

> Meta-point: I do want to have a scheme, I just have low expectations of
> our ability to succeed in the time frame we aspire to.
>
> I completely agree about the desire to have a scheme that is part of the
core of HTTP/3 (even if there are extensions which offer a more powerful
scheme). Given the time pressure that you mention, I would be
strongly inclined to support a very basic scheme.

-- 
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/2924#issuecomment-514744831

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 24 Jul 2019 12:28:50 -0700

The most minimal scheme that comes to my mind is one that does FIFO based on request order and allows urgent requests to jump the queue.

-- 
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/2924#issuecomment-514767751

---

From: MikkelFJ <[email-masked]>
Date: Wed, 24 Jul 2019 12:33:06 -0700

If it's to simple it is not very useful and might prevent something useful from happening.

I like the pmeenan scheme, it seems simple enough and can be negotiated for more advanced behaviour later on. This could easily be a header, and then it is fairly similar to @LPardue and @kazuho's proposal if I understand it right.

Basically: 7 priorities, and 1 concurrency bit in a header. Drop the lower bits if you have fewer levels. Future: use lower level bits for groups if you need it and can negotiate it.

-- 
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/2924#issuecomment-514769079

---

From: Robin Marx <[email-masked]>
Date: Thu, 25 Jul 2019 02:53:08 -0700

> This seems a little controversial. Patrick expressed a desire to limit the number of potential schemes. One of the source of the failings in h2 was the way that it enabled proliferation of schemes. 

I understand the argument, but I don't see how we could move prioritization to an extension (and mainly: allow more than one extension) and not add some kind of negotiation/setting to specify what is supported/will be used. I am a big proponent of adding this in if we decide not to fix priorities in H3 core **properly** (which is very much looking like it will be the case). Even if the SETTING ends up being moot down the line (e.g., all browsers decided to just support 1 approach), it will still be very useful for testing various extension proposals in the mean time (see it as a prioritization ALPN). I am interested in working on the design of such a setting. 

> Given the time pressure that you mention, I would be strongly inclined to support a very basic scheme.

This seems to be the most sensible way forward at this point. I would suggest to use the scheme proposed by Kazuho and Lucas (https://tools.ietf.org/html/draft-kazuho-httpbis-priority-01). It uses 8 different semantic prioritization levels ("urgency") and a progressive/non-progressive indicator. It could be seen as a simple variation on both Patrick Meenan's proposal and the original SPDY approach, while still allowing enough flexibility to represent some of the more subtle peculiarities of resource loading semantics. As I feel the best way to "finally fix" priorities down the line is to add a lot more semantic information with each request (see https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/28), I feel this simpler approach is a good foundation for that, that will also make "upgrading" easier down the line.

Concretely, I would suggest **adding the 8 urgencies and progressive boolean to the core H3 draft** (making a note that it's not perfect, but not awful either, and that they remain "hints") and to use (an) H3 frame(s) to transport them. Kazuho's and Lucas' proposal of using an HTTP-header to transmit the same information, can be done as an extension (hopefully to be implemented by most of us as well, especially the browsers). Patrick Meenan's setup can also be an extension, which people can use for experimentation. The "final fix" (whatever it may be) can start as a relatively simple extension, can be implemented by a subset of stacks to get some experience, and then grow organically. 

-- 
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/2924#issuecomment-514978982

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jul 2019 10:36:37 -0700

I think there's a compelling argument to be made for "HTTP Priorities" as a header that can traverse various versions and potentially be cached with a response.  HTTP/2 and HTTP/3 don't define any new headers, because headers are part of the semantic layer.  It seems to me like the paths we can choose are:

- Define "HTTP Priorities" in a separate draft, containing a header for initial values (and optionally frame(s) for mid-response reprioritization)
- Define a new HTTP/3 frame to carry priorities in the current draft
- Define a negotiation mechanism to select a priority scheme in the current draft; these scheme might involve frames or headers.

-- 
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/2924#issuecomment-516089336