QUIC Is Not a TCP Replacement
systemsapproach.substack.com
systemsapproach.substack.com
First, that TCP wasn't suitable for RPC based systems. Which can be true, but doesn't imply anything about the position that QUIC isn't ideal for reliable byte streams. Even though QUIC does great for RPC, there's plenty of possibility that QUIC does great for reliable byte streams.
The second argument is that QUIC is complex, and the main argument seems to be:
> QUIC is doing a lot of work: its definition spans three RFCs covering the basic protocol (RFC 9000), its use of TLS (9001) and its congestion control mechanisms (9002)
In general, I think the decomposition of specs into different pieces is a huge win for clarity & understandability and implies little about how much "work" it is to implement.
That QUIC integrates these three pieces reasonably elegantly, with clear boundaries between the aspects, shows how simple & conceptually well separated the pieces can be made.
And then, TCP just doesn't cover encryption, which makes using TCP securely a whole new set of complexities & difficulties. TLS itself has a host of extensions & related RFCs that you may need to evaluate and implement, and you and some other shop may choose quite significantly different ways of setting up TLS between systems. QUIC isn't entirely free of all these choices, but it is of some of them, and having the extra work built in is, in my view, less work in the long run.
I'm left unconvinced that the requirements of TCP have anything special or notable over the requirements of QUIC, or that sticking to TCP in some cases has any real advantage or cause. It still feels to me like everything could switch to QUIC and we'd likely do better, & end up creating better systems.
The "narrow waist" concept was originally that the only protocol that the internet required every network to speak natively or directly was IP. TCP and UDP were intended to be two protocols among many at the next layer up, but through various factors and accidents things got ossified to just those two protocols at that layer and even that so much so that increasingly in the last few decades TCP/IP is seen as the "real internet" (the "waist" expanded).
From that perspective QUIC looks like a hack: it's built at the next layer up (on top of UDP rather than a true peer among UDP and TCP) because building at the right layer level is "no longer allowed" (thanks to decades of firewalls, middleboxes, routers with bad assumptions baked in, etc).
Those things that ossified TCP, though, are also many of the reasons that QUIC can't compete with TCP and that TCP is inherently special on the modern internet as one of only two "approved" protocols and something of a "last man standing" even among them. As an example, pointed to in that RFC list, QUIC has to define its own congestion control, and it's something of an application-level service. TCP has decades of congestion control tech in the wild, some of it baked incredibly low level into routers, so much so that a lot of it is just "automatic" and "magic". Applications don't need to do any work to opt-in to it. It's sad that that work is hard-coded specifically to TCP and only TCP and cannot be easily applied to new network protocols, but that's just the reality of the modern internet.
A long-term connection is established between peers, as for TCP, but this can use multiple redundant paths rather than a single path. Within that connection, multiple independent streams with reliable transmission can exist - which relates to the RPC problem raised in the article, and to situations such as requesting parts of a web page in parallel.
NAT might not be a huge problem, as the protocol does have source and destination ports. One could also envision a proxy on a client device to translate HTTP/TCP to HTTP/SCTP for browsers not yet using SCTP directly. However home routers would probably be an insurmountable obstacle to widespread adoption, and neither Windows nor MacOS currently support SCTP.
If anything, the fact that a billion crappy unadjustable unmoving assumptions arent built into QUIC seems like an obvious win. TCP itself has a bunch of modern re-spins on what traffic control might possibly be better (bbr2 being a recent notable), yet there's so many legacy systems which already impeded progress & growth & basic modernization...
Conversely with QUIC, Broken shitty networking gear is about to get found out & replaced, when the modern QUIC internet takes over the vast majority of traffic & is just better. The "smart" middleboxes have long been more problems than aids, & their ancient cruft auto-magic is more hinderances in most places than than help.
Dropping & throttling UDP better will be a fine middleground, one where middleboxes have less control, but the end to end rather than hop to hop to hop protocol will adapt better.
However, I don't think it is fair to suggest that QUIC will do anything to fix that infrastructure. QUIC, for better and worse, intentionally kicks the can further down the road by hopping around on top of UDP infrastructure. Maybe some QUIC successor will have the guts to move things to a proper top-level protocol, but QUIC itself isn't yet that step.
And I have discussions probably every month with people arguing that "it is just TCP" and you have to explain to them that no, there is no way to do SFTP through a WAF or to run a database on that cloud service and so on.
I have seen this implemented in production!