HTTP/3 Prioritization: kickstarting the discussion (again)

[Robin MARX <[e-mail]>]

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
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05