Subject: [quicwg/base-drafts] Lessen the divergence from the HTTP/2 prioritization scheme by requiring all PRIORITY frames to be sent on the control stream (#2754)

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 May 2019 22:58:04 -0700

One of the additional complexity of the HTTP/3 prioritization scheme, compared to HTTP/2, is that PRIORITY frames might arrive out-of-order, between the control stream and the request streams.

Our previous perception has been that it's worth the complexity, but I am becoming doubtful if it's necessary.

IIUC, the need for sending a PRIORITY frame on the request stream is to handle the rare-case (like 1%) where a packet carrying the control frame is being lost. But if we are to require a server to assign the most deferred priority (i.e. weight=0) to a request for which the PRIORITY frame is yet to be received, there would be a guarantee that the performance would not be worse compared to HTTP/2 over TCP even when packet loss is involved, as @pmeenan points out in https://github.com/quicwg/base-drafts/issues/2502#issuecomment-491108296.

To rephrase, sending PRIORITY frames on request streams is an "optimization" for a rare case instead of it being a requirement to achieve comparable or better performance to HTTP/2.

Therefore, I am suggesting to stop sending PRIORITY frames on the request stream. The benefit of stopping that is that then we can have the guarantee that all the PRIORITY frames would be received by the server in the order they were sent by the client.

Then, thanks to the in-order delivery guarantee, I think we can revive the "exclusive" bit , revert the introduction of the "placeholders" concept in place of idle streams.

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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 23 May 2019 00:28:58 -0700

I just lost a morr elegant reply so this might sound curt.

The proposal seems to make tree entry operations more deterministic. However, tree management like pruning and shuffling based on stream closure seems non-determinisitc. H2 has problems in this regard already.

Some H3 implementation experience is already bringing to light designs that have two world views of stream state: one for QUIC transport and one for H3. 

-- 
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/2754#issuecomment-495101059

---

From: ianswett <[email-masked]>
Date: Thu, 23 May 2019 07:31:59 +0000 (UTC)

I'll attempt to summarize the issue: HTTP/2 priorities are different, but not better, and this creates implementation work and technical debt?

Previous issue introducing placeholders: #441

-- 
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/2754#issuecomment-495101936

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 23 May 2019 00:35:42 -0700

@LPardue 
> The proposal seems to make tree entry operations more deterministic. However, tree management like pruning and shuffling based on stream closure seems non-determinisitc. H2 has problems in this reg…

Yeah. I think we share the view that the approach proposed will have the same pros and cons that the prioritization scheme of H2 has. I think that's a good thing, because it helps people use the same approach when using the 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/issues/2754#issuecomment-495103031

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 23 May 2019 00:36:53 -0700

@ianswett 
> I'll attempt to summarize the issue: HTTP/2 priorities are different, but not better, and this creates implementation work and technical debt?

I disagree with the view. Our task is to port HTTP/2 semantics to HTTP/3. This is how you can do it, with less divergence than we have in the draft now.

-- 
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/2754#issuecomment-495103376

---

From: Mike Bishop <[email-masked]>
Date: Thu, 23 May 2019 02:30:34 -0700

This is a possibility, presuming that we take #2690.  We needed PRIORITY on the request stream so that streams opening before the PRIORITY frame arrives don't erroneously starve other resources until the PRIORITY frame arrives.  #2690 plus reverting initial priority would allow bringing back exclusive dependencies; placeholders were separately discussed with HTTPbis as an enhancement to incorporate into HTTP/3, so I think a decision to revert that would be handled separately.

-- 
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/2754#issuecomment-495141840

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 23 May 2019 02:48:31 -0700

@MikeBishop Yes. The simplification is based on #2690. I also agree that we can discuss about placeholders separately.

-- 
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/2754#issuecomment-495148675

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 23 May 2019 03:36:02 -0700

> Yeah. I think we share the view that the approach proposed will have the same pros and cons that the prioritization scheme of H2 has. I think that's a good thing, because it helps people use the sa…

I have a nagging feeling, the QUIC streams can close in non-deterministic order from the remote peer perspective. This risks a H3 priority scheme that looks similar to H2 on paper but behaves quite differently. In the worst case this requires holding more state on the server in order to increase the chances that the client and server have similar global views.  

-- 
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/2754#issuecomment-495165020

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 26 May 2019 22:31:40 -0700

> I have a nagging feeling, the QUIC streams can close in non-deterministic order from the remote peer perspective. This risks a H3 priority scheme that looks similar to H2 on paper but behaves quite…

While I agree that the the streams are being closed in a different manner, it is my view that things would generally work better in HTTP/3, because closure of streams would be notified earlier to the client (due to having less HoLB). Earlier synchronization of states lead to less need for retaining information of closed streams.

-- 
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/2754#issuecomment-496082579