Re: HTTP/3 Prioritization Proposal

I'm not sure this is exactly what I'd specify, but I prefer this over the
existing priority scheme and I believe it's simple enough most clients
would actually implement it.

I agree with Lucas that H3 makes experimenting with priority easier, and
I'd like to see a lot more of it given the lack of adoption of H2
priorities on the client side.

I agree with Subodh that deadlines are very useful in QUIC, but I'm not
convinced that clients are always in a better position to specify the
deadline than servers.  If servers can specify the deadline, then we don't
need to add them to priorities.

On Tue, Jan 29, 2019 at 3:12 AM Subodh Iyengar <subodh@fb.com> wrote:

> I personally find the concurrency levels quite a nice simplification, and
> you should definitely write a draft.
> For non browser, cases we've been thinking of supplying deadlines to the
> peer to guide things like transmission/re-transmission policies. It might
> be interesting (while still keeping it simple) to consider deadlines within
> a concurrency group.
> In any case, even just being able to negotiate a priority scheme will mean
> that we can start of with something simple and then add on.
>
> Subodh
> ------------------------------
> *From:* Amos Jeffries <squid3@treenet.co.nz>
> *Sent:* Monday, January 28, 2019 6:16 PM
> *To:* ietf-http-wg@w3.org
> *Subject:* Re: HTTP/3 Prioritization Proposal
>
> On 29/01/19 1:33 pm, Mike Bishop wrote:
> > I think you’re both right, actually.  We’ve had discussions in H3 about
> > whether the built-in PRIORITY scheme should be pulled out to an
> > extension, and one of the reasons not to was that we didn’t have a
> > competing priority scheme specified.  If the proposal is an extension,
> > whether to H2 /or /H3, the HTTPbis WG owns those per our recharter, no?
> > So it belongs here, but it’s relevant to the H3 discussion and H3 is a
> > reasonable target.
>
>
> IMO, if there are multiple priority schemes competing then there has to
> be some SETTINGS (or equivalent) negotiation between the endpoints about
> which one they are going to use.
>
> This new proposal uses the same number of bits as the existing HTTP/2
> scheme, so could easily re-use the same bits - the endpoints just need
> to negotiate which interpretation those bits are given.
>
>
> That said, looking through the proposal the very first thing that stands
> out to me is that all the problems cited are somewhat artificial, or at
> least indirect. They are a natural result of the particular Browsers
> choice of implementation rather than problems with the priority design
> itself:
>
>  * Chrome - does not implement concurrency in its tree -> problems with
> items that benefit from concurrency .
>
>  * Firefox - aggregate only by type, forced concurrency -> problems with
> items that should be high priority but have type with low-priority
> classification, and with items that need sequential delivery.
>
>  * Safari - does not implement -> latency problems with objects that
> could benefit from priority markings.
>
> The rational conclusion then is that better Browser implementations
> would solve these particular annoyances. So what problems exactly are
> preventing that better implementation happening?
>
> Any replacement prioritization would likely have to face and resolve the
> same issues. Along with the issues which caused the HTTP/2 priority
> complexity -  that was a very simple design to begin with too.
>
>
>
>
> As a side note this statement worries me:
>
> "
> The dependency tree management requires the tree state to be
> synchronized on both ends of the connection.
> "
>
> IIRC one of the main benefits of the priority scheme we have is
> precisely the opposite to that. Priority itself being a guideline more
> than a hard requirement and sync between the endpoints after the initial
> request weight assignment by HEADERS is an optional bonus for better UI
> performance.
>
> The Browse endpoint and the Origin endpoint(s) *will* have different
> trees. If only because the response content comes from multiple
> locations (middleware cache vs origin cache vs origin as-needed
> generator) with vastly different frame delivery speeds.
>
>
> Amos
>
>