Subject: Re: [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: ianswett <[email-masked]>
Date: Tue, 04 Jun 2019 18:57:39 -0700

@kazuho sorry for the confusion, I was attempting to say that HTTP/3 priorities were different from HTTP/2 priorities, and that was a negative.  I just corrected my comment to say HTTP/3.

@LPardue your concerns are well-founded, but I think that's an existing problem and not a result of a recent change?  I previously mentioned(verbally) that tree maintenance should be a longer period of time(ie: 3 MSL https://en.wikipedia.org/wiki/Maximum_segment_lifetime ?), but I realize even that may not be sufficient for QUIC and instead we should use something like 3*PTO?

I also think attaching streams to streams is inherently dangerous and much more dangerous in QUIC than HTTP/2, which is why I want to change HTTP/3 priorities to never have streams depend upon 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-498908852

---

From: Robin Marx <[email-masked]>
Date: Wed, 05 Jun 2019 02:07:15 -0700

I also think we might be conflating some issues here... to me, streams-depending-on-streams + do we need placeholders is a separate discussion from the original statement of this issue. 

I am a bit hesitant to agree with this proposal, as I am worried about potential HOL blocking on the control stream, see also #2678 (a potential solution which was discarded in London). As mentioned above, this might be rare, but -any- loss on the control stream would impact priorities. Thinking of long fat networks and the CDN/proxy use case (of which it's still a bit unclear if we want to incorporate that into the HTTP/3 prioritization design), this might have a bigger impact than anticipated (though should only be occasional).

I myself was quite happy with just changing default behaviour (with #2690) in the case of potential re-ordering and don't really see the need for this change. The argument that it allows re-introducing exclusive priorities (uttered elsewhere) is true, but as also uttered elsewhere, I don't really see the need for that feature (was only used by Chrome for H2 afaict) and is better replaced with something like "implicit fifo" e.g., #2700 or #2723. 

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Jun 2019 16:12:52 -0700

@rmarx, the way I'm currently viewing it is that there are two tracks:
- The QUIC WG is gamely plugging along on its charter to replicate HTTP/2 functionality in HTTP/3 modulo changes required by the nature of the QUIC transport.
- In the meantime, the HTTP WG might come up with a way to replace/improve the one in HTTP/2.  When they tell us what they want to use, we'll do it.

With my editor's hat on, only the first is my business unless and until the second one concludes.  As an individual, I can and will go to HTTPbis and advocate for something better.  But on this side of the fence, I still have to make progress on the first in case the second one derails.  #2690, reverting initial PRIORITY and bringing back Exclusive dependencies gets us back closer to HTTP/2 equivalence and had general support at the interim.  So that's our just-in-case position while we see what HTTPbis decides.

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

---

From: ianswett <[email-masked]>
Date: Mon, 10 Jun 2019 11:45:39 -0700

@MikeBishop I think those two tracks make sense, though I do think along the way we're making some choices about the best way to change H2 priorities to be more suitable to QUIC and what compromises are and aren't acceptable, which is by its nature a series of compromises.

For example, it seems a defaulting request weight of 1 or 0 would be a more HTTP/2 like solution than adding a default placeholder?  But possibly it doesn't matter that much?

Are there outstanding PRs for the rest of the migration back to more H2-like priorities?

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 10 Jun 2019 20:43:55 -0700

@ianswett 
> For example, it seems a defaulting request weight of 1 or 0 would be a more HTTP/2 like solution than adding a default placeholder? But possibly it doesn't matter that much?

I do not think it matters much.

And I think that servers might want to play some game here, for example giving higher default precedence to responses that carry CSS files until a PRIORITY frame is being received.

That said, I think I prefer the design principle to be "provide something that is guaranteed to be at worst as good as HTTP/2." Giving least precedence to requests for which the client-specified priority is yet to be known is a natural way to achieve that.

> Are there outstanding PRs for the rest of the migration back to more H2-like priorities?

Just filed #2781. I think that #2761 and #2781 are the remaining changes that we need to make, in order to allow browsers use the same prioritization scheme as the ones they've used in HTTP/2 (with the exception being that idle prioritized streams are replaced by placeholders).

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

---

From: ianswett <[email-masked]>
Date: Wed, 12 Jun 2019 13:57:37 -0700

Thanks @kazuho, reviewing 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-501452556

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Jun 2019 14:23:36 -0700

Closed #2754 via #2781.

-- 
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#event-2408760506