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

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Jul 2019 11:40:07 -0700

In all the discussions we have had on this, what has become clear is
that the complexity of the scheme we built in HTTP/2 wasn't well
founded in theory or practice.

Rather than try to port that across, this recognizes that while
prioritization is important, signaling is a problem we haven't solved
yet.

Closes #many issues.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2922

-- Commit Summary --

  * Remove PRIORITY

-- File Changes --

    M draft-ietf-quic-http.md (278)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2922.patch
https://github.com/quicwg/base-drafts/pull/2922.diff

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 22 Jul 2019 11:47:30 -0700

Does this mean it goes away in v1, or restarting from scratch?

-- 
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/2922#issuecomment-513907015

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 22 Jul 2019 12:57:00 -0700

I think that this is the correct thing to do.

At the very least, I'd assume that server-driven prioritization using content-type would work well to some extent. Since the early days of H2, we've doing that for browsers that does not use dependency, and it is my understanding that it has been working OK. Though it would be preferable to have the capability of servers and clients providing "hints", especially to distinguish between a render-blocking JavaScript file and a asynchronously-loaded one.

> Does this mean it goes away in v1, or restarting from scratch?

I'd assume that once the QUIC and HTTP working group agree to drop priorities from H3, it would become the task of the HTTP WG to determine what to do.

-- 
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/2922#issuecomment-513930838

---

From: ianswett <[email-masked]>
Date: Mon, 22 Jul 2019 12:58:44 -0700

ianswett approved this pull request.

Thanks!

-- 
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/2922#pullrequestreview-265022570

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 22 Jul 2019 13:38:37 -0700

kazuho approved this pull request.

-- 
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/2922#pullrequestreview-265042977

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 22 Jul 2019 13:40:47 -0700

LPardue commented on this pull request.

I think this is in general a positive move. It closes some things out. However, I do wonder if it might make us revisit other things that were previously put to bed. For example, we might want to follow up the discussion about separate unidirectional streams [1], because the space is now smaller. 

[1] https://github.com/quicwg/base-drafts/issues/2678

> @@ -139,8 +139,8 @@ Alternative Services; this process is described in greater detail in
 Within each stream, the basic unit of HTTP/3 communication is a frame
 ({{frames}}).  Each frame type serves a different purpose.  For example, HEADERS
 and DATA frames form the basis of HTTP requests and responses
-({{request-response}}).  Other frame types like SETTINGS, PRIORITY, and GOAWAY
-are used to manage the overall connection and relationships between streams.
+({{request-response}}).  Other frame types like SETTINGS and GOAWAY are used to
+manage the overall connection and relationships between streams.

A minor contention: IMO SETTINGS or GOAWAY don't exemplify "relationships between streams". In fact, removing tree depencies helps makes request streams way more independent.

-- 
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/2922#pullrequestreview-265037706

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 22 Jul 2019 13:45:40 -0700

Please create an umbrella issue for discussion. I would like to go in this direction, but this requires discussion in the wg and in HTTP as well, and I would rather not have that on this PR.

-- 
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/2922#issuecomment-513947113

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 22 Jul 2019 13:53:36 -0700

I'm also a little nervy that the removal of text makes it appear that the first user of streams (HTTP/3) quietly ignores the transport's recommendation in section 2.3 

> A QUIC implementation SHOULD provide ways in which an application can
   indicate the relative priority of streams.  When deciding which
   streams to dedicate resources to, the implementation SHOULD use the
   information provided by the application.

-- 
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/2922#issuecomment-513950016

---

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

martinthomson commented on this pull request.

Do you think that I should just strike that sentence?

-- 
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/2922#discussion_r306035077

---

From: MikkelFJ <[email-masked]>
Date: Mon, 22 Jul 2019 14:22:12 -0700

> I'm also a little nervy that the removal of text makes it appear that the first user of streams (HTTP/3) quietly ignores the transport's recommendation in section 2.3

That is an endpoint to API thing - it just says an H/3 impl. should be able to prioritize streams server side, e.g. from some configuration. It doesn't say two endpoints should negotiate this.

-- 
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/2922#issuecomment-513959957

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 22 Jul 2019 14:33:38 -0700

Fair point. I think the transport text is actually pretty weak in articulating what it is asking for in terms of stream prioritization. For example, it mentions exchanging information  and then jumps to local-API concerns

> QUIC does not provide a mechanism for exchanging prioritization
   information.  Instead, it relies on receiving priority information
   from the application that uses QUIC.

-- 
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/2922#issuecomment-513963516

---

From: Robin Marx <[email-masked]>
Date: Mon, 22 Jul 2019 15:08:23 -0700

I understand the appeal of this proposal, but I don't agree that simply cutting priorities without replacing them with something else is the right way forward. 

I don't see how this PR actually solves anything... it will allow us to ship HTTP/3 sure, but it will be (even more) difficult to use correctly in practice. This puts the burden of figuring out prioritization fully on the servers, and [we've seen how well that will go in practice with H2](https://github.com/andydavies/http2-prioritization-issues). 

I would also like to see some more detailed explanation on the statement in the httpbis session just now (which was a bit more strongly worded than the original post in this thread):

> prioritization is important but we don't need signaling for prioritization

I'm not sure I follow this... Are we suddenly claiming that the server does not need client-side information anymore, which is the opposite of the reasoning behind H2's setup? Do you feel you can do good server-side prioritization without client-side signaling? What would that look like? Combining content-type with user-agent? 

---

In essence, I feel that if we remove tree-based priorities, we **must endorse another solution** (e.g., patrick meenan's setup, kazuho's http-header based solution) and standardize that alongside H3. I fear not doing this will lead to a mess that will be difficult to recover from (i.e., if we standardize the signaling part later on, it will be difficult to find enough uptake, which was one of the main goals on Ian's slides).  

-- 
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/2922#issuecomment-513973587

---

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

```suggestion
manage the overall connection.
```

yes, or do this.

-- 
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/2922#discussion_r306064042

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 22 Jul 2019 15:48:18 -0700

> Do you feel you can do good server-side prioritization without client-side signaling? What would that look like? Combining content-type with user-agent?

Our experience shows that this is effective. It event improves performance for certain User Agents that use a poor prioritization 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/pull/2922#issuecomment-513983658

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Jul 2019 15:56:16 -0700

@martinthomson pushed 1 commit.

5c18a9ea6bc09753ece048f021501edbac7fc572  Remove sentence about stream relationships

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2922/files/7c4a6f4e2a759c477c8a8aa26387167351c38fa4..5c18a9ea6bc09753ece048f021501edbac7fc572

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 22 Jul 2019 16:06:38 -0700

@rmarx 
> In essence, I feel that if we remove tree-based priorities, we **must endorse another solution** (e.g., patrick meenan's setup, kazuho's http-header based solution) and **standardize that alongside H3**.

I also think we should have a prioritization scheme before or when we deploy H3 in the wild, but process-wise, I think we should separate the discussion so as to minimize the chance of QUIC standardization process getting delayed, and because server-driven prioritization can work as a backup strategy.

-- 
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/2922#issuecomment-513987999

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 22 Jul 2019 16:15:11 -0700

devli's advocate H3's inherent prioritization scheme can use request generation order (stream ID), a server uses this to either FIFO or round-robin. This is NOT optimal but is it disastrous enough that we absolutely should not be shipped that way?

-- 
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/2922#issuecomment-513989715

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 22 Jul 2019 21:03:02 -0700

Can we please have this discussion on the issue #2924, and not on this PR?

-- 
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/2922#issuecomment-514045281