Experimental data on priorities

When I presented slides on HTTP/3 priorities at the QUIC interim, one
consistent point was that the HTTP/3 working group wanted some experimental
evidence that an alternate scheme worked in practice.  gQUIC has always
used SPDY style priorities, FWIW, but we have no comparative data at
the moment.

I can imagine a few ways to evaluate a priority scheme, but I'd like to
know whether I have the correct ones(and relative importance).
- Application performance
- Code size/complexity
- Bytes on the wire
- Computational complexity/potential for attacks
- Reduction/change in edge cases(particularly for HTTP/3 without HoL
blocking)
- New capabilities (ie: easier for LBs/AFEs to contribute?)

*Experimentation Options*
The H2 stack at Google supports FIFO, LIFO and H2 priorities.  However,
it’s not currently using LOWAT and previous experiments have yielded no
measurable change in performance, so H2 does not seem like a good
experiment platform.

For gQUIC, we already have an implementation of H2 priorities that we’re
not using.  We can wire up an experiment to start using them and compare to
SPDY style priorities, but given Chrome's internal priority scheme with 5
levels and translation to a linked list in H2 priorities, I believe that
would only provide information on code size/complexity and bytes on the
wire.  Application performance would only change if one of the two schemes
had an implementation bug.

Expanding Chrome’s usage of priorities is possible, but it’s a longer term
project and I don't know whether they'll change.

*Other data*
Most thinking about priorities is based on the idea that a page is loaded
over a single connection, but in fact, that’s extraordinarily rare as I
presented at the interim(except Wikipedia).   Would it be useful to have
more data on this from the client and/or server perspective?

We'd be happy to work with someone else on gathering data as well, assuming
the WG would find the data we're gathering more valuable than what
Chrome/Google can provide alone.

Thanks, Ian