- From: Peter Lepeska <bizzbyster@gmail.com>
- Date: Thu, 29 Sep 2022 08:56:04 -0400
- To: Sudheesh Singanamalla <sudheesh@cs.washington.edu>
- Cc: ietf-http-wg@w3.org, Marwan Fayed <marwan@cloudflare.com>, Jonathan Hoyland <jhoyland@cloudflare.com>, Kurtis Heimerl <kheimerl@cs.washington.edu>, Chris Wood <chriswood@cloudflare.com>, suleman@cloudflare.com
- Message-ID: <CANmPAYGhJL5xLRO-nfigmry4Rs=pKtoidSSFNngPOgrbyJ2arw@mail.gmail.com>
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 < sudheesh@cs.washington.edu> 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 >
Received on Thursday, 29 September 2022 12:56:29 UTC