Subject: [quicwg/base-drafts] HTTP/3 is lacking priorities (#3198)

From: Ryan Hamilton <[email-masked]>
Date: Wed, 06 Nov 2019 12:55:46 -0800

Since HTTP/3 is a multiplexed protocol (just as HTTP/2 was) a sender which is servicing multiple requests needs some way to decide which request to send data on. HTTP/2 used a ... baroque ... prioritization scheme that this working groups has decided (rightly, IMO) is a poor fit for HTTP/3. Before shipping HTTP/3 we should settle on some prioritization mechanism for HTTP/3. (Possible a very simple scheme with the opportunity for extensions to provide more sophisticated schemes.)

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Nov 2019 13:14:52 -0800

Correction: HTTP/3 lacks a means of *signaling* priority. That distinction gets lost too often 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/3198#issuecomment-550503232

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 06 Nov 2019 13:52:11 -0800

Well, HTTP/3 the specification lack priorities in any form whatsoever :)

But yes, you're totally right that an HTTP/3 endpoint implementation can do prioritization based on locally available information. What is lacking is a way for and endpoint to provide information to the peer to facilitate the prioritization.

I'll be interested to see what sort of normative language we end up with for how an endpoint is required (or not) to act on this information. 

-- 
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/3198#issuecomment-550516922

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 06 Nov 2019 14:11:18 -0800

Request order is an implicit signal. In the absence of anything else I would borrow the text from RFC 7540

```
... input to a prioritization process.  It does not guarantee any particular processing or transmission order for the stream relative to any other stream.  An endpoint cannot force a peer to process concurrent streams in a particular order...
```
As discussed elsewhere, a sane default recommendation for servers based on request order might be useful.

But I hope we as a group can come up with a slightly better more complete answer. 

-- 
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/3198#issuecomment-550524058