Re: HTTP/3 Prioritization: kickstarting the discussion (again)

[Nick Harper <[e-mail]>]

I'm in favor of a simpler approach for H3 priorities, and something like
Patrick Meenan's proposal sounds good. I like the simplicity and
statelessness of that proposal. I don't foresee any issues with
implementing it in Chrome, nor do I see any issues with needing to maintain
separate priority implementations for H2 vs H3.

I would prefer that a simpler proposal be the default (MTI) priority scheme
used in H3. If there are applications that need the full expressivity and
complexity of the H2 or draft-20 tree based approach to priorities, I think
that would be better suited to an extension.

On Wed, Jul 3, 2019 at 9:30 AM Patrick Meenan <[e-mail]> wrote:

> I don't know if we want it as an explicit goal but one of the main reasons
> for my initial alternative proposal was that it is stateless which makes it
> easier for application logic outside of the connection-owning code to
> reason about and influence prioritization. That can always be handled by a
> translation from something proprietary into a tree at the actual connection
> but having both sides speak the same stateless model makes it a lot
> cleaner.
>
> On Wed, Jul 3, 2019 at 12:11 PM Robin MARX <[e-mail]> wrote:
>
>> Hello everyone,
>>
>> As I expect most of you know, there has been quite a bit of talk over at
>> the QUIC / HTTP/3 working group recently on what to do with the dependency
>> tree / prioritization system from HTTP/2 in H3.
>>
>> There are two major issues:
>> - There a a few subtle HOL-blocking issues in porting the system to H3
>> due to the way streams work in QUIC
>> - Quite a few people feel H2's approach is overly complex and can/should
>> be simplified
>>
>> For now, the QUIC wg has taken the stance to try and stay as close to H2
>> as possible (e.g., exclusive priorities had been removed before, but are
>> now back in the editor's draft of HTTP/3).
>> The QUIC wg wishes to see more real implementation experience and
>> experimental results for new proposals before considering them. It also
>> feels this issue is best discussed in the httpbis wg. And thus we come to
>> this email.
>>
>> We have been recently running some prioritization experiments for a
>> variety of schemes and proposals using our own HTTP/3 implementation in the
>> Quicker project.
>> We have discussed our findings in a paper, which you can find in
>> attachment and also on https://h3.edm.uhasselt.be.
>>
>> The paper attempts to provide a rather extensive discussion of the issues
>> with H2's setup, H3's approaches so far and the alternative proposals that
>> have been made.
>> As I appreciate not everyone has the time to read all of that, our main
>> findings are:
>>
>> 0) The current proposal (which should be "draft-21" soon) for HTTP/3
>> works well in practice, though the semantics of the "orphan placeholder"
>> might still need to be tweaked a bit.
>>
>> 1) Simpler setups are also perfectly viable.. The main contender, from
>> Patrick Meenan (
>> https://github.com/pmeenan/http3-prioritization-proposal/blob/master/README.md)
>> would be a good candidate for this.
>>
>> 2) However, there is no single scheme that produces ideal results for all
>> web pages (e.g., the scheme that is best for page A can perform really
>> badly for page B). So dropping everything for a single, simpler approach is
>> potentially sub-optimal. Similarly, the current approach of browsers of
>> just using a single scheme for all pages might need revision.
>>
>> 3) Ideally, we should thus allow the scheme to be tweaked per-page,
>> either via a mechanism where the server indicates the optimal scheme to the
>> client (which we propose in the paper), or where the client communicates
>> additional metadata to the server (e.g., resource is blocking/non-blocking,
>> can be processed progressively, ...) to make server-side prioritization
>> easier (Kazuho Oku is working on a proposal for this, but doesn't feel it's
>> ready to share here yet).
>>
>>  4) In order to make progress on H3, it's probably best to stick with the
>> draft-21 approach (potentially with a few more small tweaks) and define a
>> new approach as an extension or implement it at the higher HTTP layer
>> (i.e., as HTTP headers, rather than H3 frames). However, would that then
>> find enough adoption fast enough...
>>
>> While I'll be the first to admit our study isn't terribly extensive or
>> fully realistic (we tested 40 pages in lab settings without a real
>> browser), I still feel our results are enough to have a basis to continue
>> the discussion on. We of course encourage others to share their results as
>> well.
>> Some more background information can be found here as well:
>> https://github.com/quicwg/wg-materials/blob/master/interim-19-05/priorities.pdf
>>
>> I'm a bit unsure what the best questions are to ask at this point, but
>> some attempts:
>> - Are implementers willing to implement 2 completely different approaches
>> (1 for H3, 1 for H2)?
>> - Are (browser) implementers willing to consider supporting multiple
>> schemes (specific trees)?
>> - Are (server) implementers willing to create/support more complex
>> (user-driven) server-side prioritization config/APIs?
>> - How important is it to move to a simpler (and thus less flexible)
>> setup?
>> - Should this be a blocker for HTTP/3 or not?
>>
>> Looking forward to your feedback.
>> With best regards,
>> Robin
>>
>> --
>>
>> Robin Marx
>> PhD researcher - web performance
>> Expertise centre for Digital Media
>>
>> T [phone] - GSM [phone]
>>
>> www.uhasselt.be <http://www.uhasselt..be>
>> Universiteit Hasselt - Campus Diepenbeek
>> Agoralaan Gebouw D - B-3590 Diepenbeek
>> Kantoor EDM-2.05
>>
>>
>>