Subject: Experimental data on priorities

From: Ian Swett <[email-masked]>
Date: Mon, 15 Jul 2019 22:25:12 -0400

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

---

From: Patrick Meenan <[email-masked]>
Date: Tue, 16 Jul 2019 09:00:47 -0400

Lucas can speak to the current state of deployment at Cloudflare but the
scheme we deployed mirrors the current proposal well enough that the
results should apply. It's a little different because the prioritization
isn't originating from the client but it is being applied as if it was.

Cloudflare has ample evidence that "it works" at least in place of HTTP/2's
scheme over TCP and compares well to a well-implemented HTTP/2 client (when
serving web content to browsers anyway). Where the really big gains came
into play were in overriding the client-requested prioritization from
Safari and Edge and applying something that looks more like a mix of Chrome
and Firefox (sequential critical assets, interleaved images). In that case
it worked much better than HTTP/2 but it was because of the specific client
HTTP/2 priority schemes and the bulk of the gains came from applying better
sequencing server-side (though the ability to make server-side decisions
was a huge benefit of the scheme).  It also works well enough that the new
scheme is applied independent of the client so Chrome and Firefox also
don't regress.

Given that you can represent the proposed scheme in it's entirety with the
HTTP/2 schemes, I'm not sure you'll ever see an application performance
gain if you are using the same client and applying the exact same scheme to
both modes.  That said, the code complexity may prevent some features from
being implemented in the tree that could be added fairly easily to the new
scheme. The one that comes to mind for Chrome in particular is to enable
interleaving of image data instead of delivering them sequentially. With
the new scheme it's pretty much just carrying a bit through the stack to
indicate that the given fetch should be interleaved and it can be mixed in
to the serialized priorities trivially. Doing the same with the full HTTP/2
tree would be considerably more complex.

On Mon, Jul 15, 2019 at 10:29 PM Ian Swett <[email-masked]> wrote:

> 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

---

From: Ian Swett <[email-masked]>
Date: Wed, 17 Jul 2019 19:51:28 -0400

Mikkel, the 'why' is complicated and varied I suspect.

In Google's case, I know we like to isolate services like authentication
from static content from ads from large content(ie: YouTube) for a variety
of reasons.  I suspect we currently end up with as many as 2x more
connections than we really need, and we can likely fix a few of them, but I
anticipate we'll end up with >2 connections for the foreseeable future.

Why TaoBoa.com and TMall.com(both Alexa top 10) were using >20 H2
connections is quite confusing to me, or why Amazon is using 15 H2
connections, so I'd be curious if anyone knows.

On Tue, Jul 16, 2019 at 9:00 AM Patrick Meenan <[email-masked]> wrote:

> Cloudflare has ample evidence that "it works" at least in place of
> HTTP/2's scheme over TCP and compares well to a well-implemented HTTP/2
> client (when serving web content to browsers anyway). Where the really big
> gains came into play were in overriding the client-requested prioritization
> from Safari and Edge and applying something that looks more like a mix of
> Chrome and Firefox (sequential critical assets, interleaved images). In
> that case it worked much better than HTTP/2 but it was because of the
> specific client HTTP/2 priority schemes and the bulk of the gains came from
> applying better sequencing server-side (though the ability to make
> server-side decisions was a huge benefit of the scheme).  It also works
> well enough that the new scheme is applied independent of the client so
> Chrome and Firefox also don't regress.
>

Thanks, this makes complete sense to me.

> tree would be considerably more complex.

Agreed, we're starting to write the code to compare gQUIC's use of SPDY
priorities with Chrome's usage of the H2 tree with your proposal(in this
case, basically a variant of SPDY priorities), and we think that should be
relatively straightforward, but anything more complex would be a large
amount of work.

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