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.
