First, I am terribly sorry if what I am about to say is unhelpful. But, I am piping up in case the data I have collected is helpful:
I have been collecting longitudinal data on the top 500 most popular websites on the Internet (according to Tranco) for several months. What started as an attempt to track whether sites support Accurate ECN (TCP) and draft-seemann-quic-accurate-ack-ecn (QUIC) has morphed into a tool for general tracking of various aspects of connections to those websites (e.g., logging all QUIC transport parameters, flags on the TCP SYN/ACK, among others). All the data is available publicly (https://accurecny-data.pages.dev/) and the description of the data dictionary (along with other discussion) is at https://accurecny.cerfca.st/. We've uncovered some really "interesting" QUIC configurations and I hope you all might find it useful. I am really interested in doing anything that I can to help people like you who are doing the hard work of expanding the fundamentals of the Internet, so if there is anything I can explain about the data, anything that I can add to data the tool collects (or otherwise), please let me know. PS: There are plenty of things I have planned for the tool but I don't want to spam anyone. If you'd like to know more, I'd love to talk! Again, I hope that the data are helpful! Will On Mon, Sep 29, 2025 at 4:09 PM Yaroslav Rosomakho <[email protected]> wrote: > > These are really interesting data points. Thank you for sharing them! > > I do wonder if the difference in QUIC usage between apps and browsers is > mainly attributed to unreliable HTTP/3 discovery mechanisms or if parts of it > could also be explained by where the clients run. For example, apps being > less common on managed devices or on networks with filtering and being far > more common on personal mobile devices. > > > > Best Regards, > Yaroslav > > On Mon, Sep 29, 2025 at 8:20 PM Ian Swett > <[email protected]> wrote: >> >> 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/ 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. >>>> >>>> > > > 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.
