[austin-cheney]

Another example is QUIC. What is the benefit of QUIC? On one hand Google boasts it greatly increases page load speed, which is contextually arguable. On the other hand, Google’s design priorities were to introduce UDP to the browser because UDP supports multicast, which lowers CPU utilization in data centers.

[wahern]

They claimed and showed QUIC slightly-to-moderately reduced latency, particularly for mobile. This benefits Google by loading pages with third-party content, i.e. ads, faster.

But QUIC significantly increases CPU utilization on servers, at least the widely used userland stacks do. Unless/until Google deploys QUIC in the kernel (or puts the whole network stack in userland, a la DPDK), this won't change.

The multicast claim is kinda bizarre. I can see how QUIC could help eliminate UDP client barriers, but those barriers pale in comparison to multicast. Multicast routing just doesn't exist on the Internet; it's only supported within some independent, typically small networks. Most ISPs don't support it. Wherever you could manage to distribute content with multicast, you'd necessarily also be resolving the collateral routing problems which QUIC support resolves, whereas even ubiquitous QUIC doesn't materially improve the multicast situation.

[austin-cheney]

You can invent your own conclusions all you want. Google’s evidence and motivations are what I stated. Their words, not mine.

[wahern]

I couldn't find any evidence Google pushed QUIC with the aspiration of utilizing IP multicast.

In 2022 an RFC for adding multicast support to QUIC was published, but backed by Akamai, not Google. And of course the RFC has the caveat that it would only be useful over multicast networks, e.g. edge servers colocated at an ISP. It seems this effort has picked up some steam over 2025 and 2026.

But I didn't look too hard. Can you share sources?

[austin-cheney]

Here is a Google Chrome discussion about it from 2018: https://groups.google.com/a/chromium.org/g/proto-quic/c/pAQz...

Here is a quick overview (undated) from Google about it: https://peering.google.com/#/learn-more/quic

The phrase in that last one is: "multiplexing without head of line blocking". If you search for that phrase you will get a bunch of results. The browser is an extremely limited interface with regards to transmission, so the solution in the browser is always open more sockets. However, on the server, the advantages are huge.

You have to understand that multicast is OSI layers 2, 3, and 4. Its layer 2 because it uses a NIC as a local identifier for management apart from other multicast sockets available, UDP and TCP are layer 4 protocols, and it also takes on some layer 3 capabilities for congestion management. This is where the CPU advantage comes in, because you are offloading some of the traffic processing elsewhere in the stack and to network devices, like switches/routers.

Yes, Google has said that part of the motivation was reducing CPU load but I cannot remember where I saw that.

[wahern]

I don't understand the conflation of multiplexing and multicasting. Are we talking about the same multicasting? (https://en.wikipedia.org/wiki/IP_multicast)

Regarding QUIC CPU load, at least as of a year or two ago it's demonstrably greater then TCP+TLS. Even Google's own numbers showed higher server-side load of up to 10%, IIRC. QUIC has to do all the same work (QUIC libraries embed the same congestion control and stream management logic as TCP, even using slightly modified versions of BBR, CUBIC, etc), and then some. More over, both TCP stream management and TLS are often offloaded to the NIC, and QUIC support isn't nearly as mature there. Even with vanilla NICs, high-performance application servers use kTLS. Unless your QUIC userland stack is DMA'ing raw packets directly to and from the NIC, QUIC is doing more work.

[chrisweekly]

IIRC, QUIC was also the precursor to HTTP/3. I don't like Google's motivations for wanting a faster web, but many of the things they've encouraged and/or provided have made things faster and more efficient. I'm not a google apologist, there's so much wrong and so much harm done... just saying it's maybe worth separating the tech from the motives.

[doodlesdev]

HTTP/3 uses QUIC as the transport layer, which in turn relies on UDP. QUIC replaces TCP while allowing a reduction of handshake exchanges in HTTP/3 first requests. Finally, even though UDP supports multicast, I believe QUIC doesn't. GP saying Google has developed it to use multicast thus is nonsense. Furthermore, QUIC takes much more CPU than TCP right now, due to running in userland.

In my opinion, QUIC and HTTP/3 are technical marvels, but are perhaps way too complicated and don't really serve the interest of most internet users.

There will be a point in the development of web browsers and associated technologies where we should just stop a bit to get things stable instead of churning protocol version after protocol version after new API. Will it ever stop?

Eventually, it all becomes so complicated no company can manage it all. Honestly, we might already be past this point, with Chromium at almost 40mi LOC, more than the Linux kernel itself, including all its drivers. When will the madness stop? Do we really need such complicated software to see Instagram posts, comment on a few Hacker News threads and mess around with Google Sheets?

The biggest reason I worry so much about this is that in the web, adding new features, APIs and protocols is easy. Removing and deprecating is basically impossible.

[pie_flavor]

It's not very complicated to import the QUIC library, or to import the HTTP library with HTTP/3 supported. For the library authors, QUIC isn't more complicated to implement than TCP. Doomsaying about the complexity of Google Sheets is completely unrelated to whether QUIC is good tech and superior to TCP, which it is; the only remaining complaint is that it's too new to have been part of the kernel yet, and if that makes technology somehow illegitimate then I guess we're just stuck with the mistakes of the 90s forever, why ever invent anything new at all.

[austin-cheney]

That is also entirely incorrect. There are many challenges to implementing an original QUIC library. The Node.js project is developing and evaluating for this right now and the effort is extensive.

[pie_flavor]

There are also many challenges to implementing an original TCP library.

[austin-cheney]

> Finally, even though UDP supports multicast, I believe QUIC doesn't.

Don’t confuse the browser for the server. QUIC is UDP but UDP is not QUIC. Unlocking UDP for the browser allows capabilities on the remote end that aren’t available to the browser.