With no hats on (I echo Lucas' points on WG time): On the point of QUIC being blocked, at least from our perspective, this is not really an issue globally. UDP/443 has been widespread on the Internet for quite some time now thanks to the pre-IETF gQUIC deployments largely normalizing it, as have the subsequent IETF QUIC rollouts. For our services (Meta) we detect that QUIC is "blocked" a _very_ small portion of the time. How exactly you define this will change the number, but in terms of number of connection attempts where QUIC is definitely being blocked, it's low single digit percentages globally. Most of this is coming from known ASs where it's being blocked. This is certainly not responsible for the metrics reported by Cloudflare unless their customers are vastly overrepresented in such networks.
Our data strongly indicates that the "problem" is indeed that clients/sites are simply not choosing to utilize QUIC. For our services, where the majority (but not all) have QUIC enabled, we see HTTP/3's share of HTTP egress just shy of 90% globally, with many ASs where it is nearly 100%. We have the luxury of mostly controlling our own clients and servers, which lets us make assumptions others cannot. I would guess that the most likely reason why more sites and applications are not choosing to use QUIC is simply that it takes effort to make the switch, and it's not always an obvious slam dunk win. The wins can often be incremental and difficult to detect if sites are not deeply instrumented with performance and engagement metrics. Matt Joras On Mon, Sep 29, 2025 at 3:09 AM Lucas Pardue <[email protected]> wrote: > Hi, > > Responding in line > > On Mon, Sep 29, 2025, at 08:52, Yaroslav Rosomakho wrote: > > Hi. > > That’s a great topic. Absolutely worth bringing it up at the IETF124 > meeting if the agenda allows. > > > With chair hat on, I'd like any QUIC agenda time to be spent on something > that can be actionable. There have already been publications and > presentations on QUIC availability and uptake, MAPRG springs to mind but > there are various venues. > > The HAPPY WG is also dealing with related topics. > > I support discussion of this area but there may be more suitable places to > hold it at IETF 124. > > > > From my perspective, the plateau in HTTP/3 adoption comes down to four > main groups of issues: > > 1. UDP/443 blocked by misconfiguration or conservative policies. > > This is similar to the "disable IPv6 to fix problems" mindset. Some > operators block QUIC traffic out of caution, even when doing so causes more > harm than good. > > 2. Website owners are reluctant to enable HTTP/3. > > Brought to you by "if it isn’t broken, don’t fix it". Operators may fear > regressions or simply prioritise other work since TCP-based HTTP already > "works fine". > > 3. SNI-based filtering without QUIC support > > Many traffic filtering solutions that rely on SNI inspection do not > support QUIC, so their operators default to blocking UDP/443. This is > particularly visible on restricted networks such as guest Wi-Fis, which > often only allow TCP/80, TCP/443, and UDP/53. > I don't think IETF or QUIC WG should be doing anything to help passive SNI > filtering. > > 4. Enterprise traffic inspection (NGFWs and proxies) > > While some products support QUIC inspection, major browsers deliberately > downgrade to TCP/TLS when encountering certificates outside the Web PKI. > Chromium has enforced this since 2019 [1], and Firefox since 2024 [2]. In > Firefox it’s an advanced preference > (network.http.http3.disable_when_third_party_roots_found), in Chromium it > is hard-coded. This effectively excludes many enterprise deployments that > rely on local trust anchors. > Changing that unconfigurable behaviour to a setting easily adjustable in > managed environments would go a long way. > > > I think this is a good survey of factors. It can be simplified further > into a) Did the server operator enable and advertise QUIC support and b) > did the client select QUIC > > Ignoring out-of-band config, (a) is easy enough to survey - Advertisement > is done via public means with Alt-Svc and/or SVCB/HTTPS RR. Server > operators often know if they enabled something nor not. > > Surveying (b) is a lot harder. The client side decision making is opaque, > based on many factors. In Web land, there is something called Network Error > Logging (NEL) that can record and beacon issues establishing or maintaining > connections. However, the granularity is too coarse to help. I've had an > issue open for a couple of years with little movement [1]. There's an > opportunity for Happy Eyeballs v3 to pick up some of this, folks like Erik > Nygren have talked about reporting and it was on the agenda at IETF 123 [2]. > > I think it would be helpful to explore data on client-side choices more to > help inform any efforts in thus space. Even if it was a time bounded or > limited study. > > Cheers > Lucas > > > > [1] - https://github.com/w3c/network-error-logging/issues/134 > [2] - https://datatracker.ietf.org/doc/agenda-123-happy/06/ > > > > > Looking forward, I see two broad levers to move adoption beyond the > current plateau: > > Education and awareness. Helping operators understand that "HTTP/3 and > IPv6 are your friends" could avoid unnecessary blocking. A browser-side UX > nudge (such as showing a subtle “this site could be faster” indicator when > HTTP/3 isn’t used) might also help. > > Unique capabilities. Wider deployment of features that are only possible > with QUIC, such as WebTransport or Multipath QUIC, will make the benefits > tangible for developers and users. But this requires more implementation > work and easy-to-use APIs before it will drive adoption at scale. > > > > For IPv6, regulatory or procurement pressures have been an important > driver of adoption. In contrast, I don’t expect a similar external push to > accelerate migration to HTTP/3 / QUIC. > > > Best Regards, > Yaroslav > > > [1] https://issues.chromium.org/issues/40634582 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1929368 > > > On Mon, Sep 29, 2025 at 4:38 AM Lars Eggert <[email protected]> wrote: > > Hi, > > pitch for a discussion at 124. > > https://radar.cloudflare.com/ > <https://radar.cloudflare.com/adoption-and-usage?dateRange=52w> and > similar stats have had H3 around 30% for a few years now, with little > changes since the first quichbram up to that level. > > Topic: why is that and is there anything the WG or IETF can do to change > it (upwards, of course)? > > Thanks, > Lars > -- > Sent from a mobile device; please excuse typos. > > > > This communication (including any attachments) is intended for the sole > use of the intended recipient and may contain confidential, non-public, > and/or privileged material. Use, distribution, or reproduction of this > communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your system. > > >
