Re: Measurement of H2 ORIGIN Frames, revisiting CERTIFICATE Frames?

[Peter Lepeska <[e-mail]>]

Hi Sudheesh,

You may not care to go further back in time in your intro but old timers
like me will remember earlier pre HTTP/2 reasons that web performance gurus
used to advocate for domain sharding, which you mention here:

"... The gains were themselves bottlenecked by head-of-line blocking [35,
39]. This led to a practice of domain sharding, in which browsers are
‘tricked’ into initiating new and parallel connections to multiple
subdomains [30]. As a result, the burden of managing multiple connections,
scheduling requests, and optimizing rendering pipelines shifted to browsers.

Including overcoming TCP slow start and increasing concurrency. Totally
understand if you don't want to go down those memory lanes but it is
interesting to watch as the web performance community seems to oscillate
between advocating for more concurrent connections and advocating for
coalescing resource requests on to fewer connections. QUIC promises to put
this back-and-forth to bed but of course it comes with its own bandwidth
limitations for high latency / bandwidth product networks that might make a
future web acceleration guru to yet again advocate against coalescing.

It's almost like that Marc Andreessen quote but applied to web performance
optimization: “Only two ways to make money in business: One is to bundle;
the other is unbundle.” :)

Thanks,

Peter

On Mon, Sep 26, 2022 at 9:06 AM Sudheesh Singanamalla <
[e-mail]> wrote:

> Hello everyone,
>
> I would like to share some work from Cloudflare that may help inform
> ORIGIN Frame (and by extension, CERTIFICATE Frame) and, if there is
> interest, also present at the upcoming IETF 115.
>
> Cloudflare has been experimenting with H2 ORIGIN Frames
> <https://httpwg.org/specs/rfc8336.html> and recently published findings,
> experience, and insights in a paper to appear at the upcoming ACM
> Internet Measurement Conference
> <https://conferences.sigcomm.org/imc/2022/>. Here's a link to the preprint
> of the paper
> <https://files.research.cloudflare.com/publication/Singanamalla2022.pdf>
> in case you're all interested.
>
> Overall, the key observations from our work are:
> 1. Large-scale measurements indicate the current ecosystem has lots of
> opportunity to coalesce connections with ORIGIN, with only small (1 to 5)
> additions to certificate SANs.
> 2. The immediate motivation to support ORIGIN frames should be privacy,
> followed by opening opportunities for resource scheduling at the endpoints
> (e.g. prioritizations and early hints) that is not violated by competing
> connections for those resources.
> 3. Perhaps counter-intuitive, performance should not be assumed to improve
> but results suggest no worse is appropriate. Servers, of course, may
> benefit from fewer sockets and connection state.
> 4. Non-compliant network stacks do exist in the wild which might not drop
> unknown frames and result in tear-down of the connections.
>
> All told, we feel these results might bring attention to ORIGIN in H3
> <https://httpwg.org/http-extensions/draft-ietf-httpbis-origin-h3.html>,
> and maybe, too, revisit the CERTIFICATE frames
> <https://datatracker..ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs-06>
> draft.
>
> Thanks,
> Sudheesh
>