On Tue, Jun 25, 2024, at 13:19, Chris Box wrote: > On Mon, 24 Jun 2024 at 22:08, Matt Joras <[email protected]> wrote: >> There's a lot to unpack here. Setting some context, as of today our (Meta) >> Internet egress to end users hovers at around 89% QUIC. The reason that is >> not closer to 100% mostly stems from certain products not completely >> utilizing QUIC yet, though every one of our platforms uses it to some degree. > > Impressive results! > >> Instances of UDP blocking are mostly isolated to smaller networks and are >> not widespread. > > That's good to know. So it's clear blocking is not the cause of it being a > minority. > >> For third party clients who use more cautious policies, the numbers are not >> as high. The percentage of HTTP/3 by browser as seen by our servers >> currently is roughly: >> Microsoft Edge: ~83% >> Chrome Desktop: ~75% >> Chrome Mobile: ~70% >> Firefox: ~60% >> Safari/Mobile Safari: ~40% >> Firefox Mobile: 30% >> >> We use the same alt-svc and HTTPS record strategy for all our major domains. >> This indicates that there are likely improvements to be made in both >> advertising QUIC's availability but more importantly browsers using it more >> proactively than they currently are. > > This appears significant. IIUC, those numbers could potentially reach ~89% as > that's what you achieve using first party apps. Safari routinely performs > HTTPS lookups and yet only reaches 40%. The use of old operating systems is > probably only part of the reason. > >> This is where many small impediments can start to accrue and stall out >> adoption. > > Yes of course for many reasons the long tail will be very slow to adopt > HTTP/3. I was mainly thinking about CDNs, whose business offering is to > deliver web content as quickly as possible. It's still surprising to me that > H3 is a small percentage on many CDNs. > > > On Tue, 25 Jun 2024 at 00:43, Martin Thomson <[email protected]> wrote: >> HTTP/3 25.09% 26.13% > > Thanks for the data, which is pretty similar to Cloudflare's. If that was > filtered to Meta destinations, perhaps you'd see the 60% figure that Matt > sees. > >> The question I'd ask is "so?" Should we care that QUIC isn't racing to the >> moon? > > I care about making the internet work better and be more responsive to users. > QUIC is a major improvement in that sense and it's sad to see it being > limited to a subset. I'd like to deliver these benefits to more people, more > of the time. As a community we can take actions that result in H3 overtaking > H2 on the internet.
Picking up on the performance angle only: QUIC protocol features offer advantages for sure. Some of those are targetted at particular network types, or stream usage patterns. For instance, HoL blocking avoidance helps when the network is lossy and HTTP requests are independent; that isn't always the case though. Each web page has its own special flavour of critical path. It can be difficult to monitor and prove with actual data that end-users see meaningful performance improvements due to leveraging the features of QUIC. The web platform only provides so much information. Advanced operators may have a bunch of client side analytics that can give deep introspection to every angle of their web app. Some folks might rely on RUM providers to capture industry-standard performance metrics such as Core Web Vitals. There are difficulties getting at information about the local network config (cell, wifi) or other access network details that would be interesting to understand if QUIC is addressing the needs of the network path. As a platform or service operator, its likely that you'll have no idea what the KPIs of the web applications that pass through you are. Focusing on low-level observables, such as connection or request times doesn't give the full, actual, picture. There is a disjoint, that can be hard to fill. In contrast, things like YouTube or Meta have purpose built clients that can do cool things. That's *in addition to* a culture of performance monitoring, tuning and ever incremental improvements. There can be layer 8 challenges to solve to enable or shift to any tech, especially if an organisations culture is already geared for it. This is not a new problem, web performance experts have been trying to deal with this for as long as I can remember. There are also many other opportunities for improving performance of web sites that are less deeply entwined with transport details, and work across all HTTP versions. QUIC deployment isn't just competing with TCP, it's competing with every other technology that can boost performance. For example, Speculation Rules [1]. There's only so much engineering hours to go around, and companies make a value judgement about where to invest that for peak ROI. As others have noted, some folks are risk averse and are happy enough with the status quo. If there are performance wins to be had, they'll likely be wanting to see case studies before the CTO signs off on turning something on that might even have the slightest hint of beung able to cause some regression in performance or stability. It also behoves me to mention we have QUIC powering the web in different ways than the OP question presents it. Apple Private Relay, for example, uses MASQUE for tunneling traffic - leverage QUIC's unique DATAGRAM feature. Similarly, Cloudflare is in the process of migrating its WARP traffic from Wireguard to MASQUE [2]. We also have WebTransport and MoQ, which are intended for use on the Web. These deliver possibilities that HTTP can't, such as other forms of interaction, or addressing the particular needs of low latency video distribution. I don't think we'll see deployments of these shift HTTP version share numbers dramatically. I don't think that matters. If more people watch more video due to MoQ providing an excellent QoE, that doesn't necessarily change their existing browsing habits. Cheers Lucas [1] - https://developer.chrome.com/docs/web-platform/prerender-pages [2] - https://blog.cloudflare.com/zero-trust-warp-with-a-masque > > Chris >
