QUIC has a lot going for it, but it is a large library (six figure LoC)

This isn't really about QUIC so much as it is about developer experience. Authentication, confidentiality, integrity, congestion control, reliable+ordered streams etc. are all fundamental features of the protocol, so of course it's a bit beefy. Those LoC have to be written somewhere - whether in the kernel or in userspace makes little difference, semantically. The reason that QUIC is a library is because it's still relatively new. That said, support for creation of QUIC sockets in the Linux kernel is underway (https://lwn.net/Articles/1029851/).

I am baffled you can even get to six figure LoC implementing QUIC. Having done the majority of a QUIC implementation before deciding I needed to design a new protocol that fixes QUIC's performance limitations, a minimal, but fully functional and performant implementation with zero dependencys (except for cryptography) should only take maybe 5,000 lines.

If you use the default parameters with such a implementation you will likely cap out at a pretty slow ~10 Gbps/core, but if you reduce the ACK frequency you can probably get to ~30-50 Gbps/core without too much trouble.

Redacting "I noticed that a kernel level impl is only 9000 loc (shallow dive https://lwn.net/Articles/1029851/). As it doesn't fully implement the feature set.

Also I noticed that Plan 9's IL protocol (avoids head of line because the type of messaging it's used for) another point pointed out in the x comments.

I wonder if he's focusing on consumer distributed AI inference (due to quic being browser supported) or maybe just a comment on the protocol in general.

I mean, isn't TCP six figure LoC? It just lives in the kernel, not in a library.

Can't say I disagree much with his take. We've been doing the whole internet thing going on six decades now, and we shouldn't need to think about this stuff nearly as much as we still do. Maybe once it reaches 100 years old we'll know how to do stuff in a sane fashion by default.