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

[Patrick Meenan <[e-mail]>]

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