I agree with Matt and Lucas, but I wanted to add one persistent challenge that we've seen, which is the client knowing that QUIC is supported by a server (ie: Alt-Svc or the HTTPS record). In apps such as YouTube, we just tell it to try QUIC by default, and there we see QUIC usage blocked a very small portion of the time, as Matt said. In browsers, QUIC usage is persistently lower by a meaningful amount, though much higher than 50%. If there was an oracle in the client that could know whether the server supported HTTP/3, or something approximating that, that'd be enormously helpful.
QUIC usage does vary by time of year (think Christmas to New Year's) and day of week, but only the ~5% variation Willy posted above, and even 5% seems large based on my memory. Thanks, Ian On Mon, Sep 29, 2025 at 1:09 PM Matt Joras <[email protected]> wrote: > 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. >> >> >>
