QUIC Is Not a TCP Replacement(systemsapproach.substack.com)
systemsapproach.substack.com
QUIC Is Not a TCP Replacement
https://systemsapproach.substack.com/p/quic-is-not-a-tcp-replacement
14 comments
I think some of the argument you aren't seeing is in all the "narrow waist" implications and some of the links out from this article nearby that.
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.
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.
Author of the post here. Good comments. I was being deliberately provocative in the title to make a point. As I note in the article, it may or may not turn out that QUIC replaces TCP; the main point is that we didn't need a "TCP replacement" as much as we needed something new to meet the requirements of RPC (and HTTP in particular) and QUIC is doing that nicely. It may turn out that is all we need and TCP disappears, but as you say, there are reasons to doubt that including the extent to which TCP is baked in to existing systems.
If we did not have to deal with the two problems you identify (direct communication peer to peer - effectively the NAT problem with IPv4 - and current firewall practice), then SCTP would be worth a look. I'm not a low-level network expert, and I haven't looked at QUIC in detail, but from the article it seems that SCTP addresses the issues raised in the article. It is a transport protocol on the same level as TCP and UDP, and originally devised for telecoms to transport SS7 signalling information. It's a very good fit to SIP, which is where I came across it.
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.
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.
My understanding here is that some of why QUIC is built the way it is (on top of UDP) is in somewhat direct response to lessons learned from SCTP, including and especially how hard it is route SCTP in practice on today's internet.
> 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.
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.
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.
It is fair to suggest that some of that TCP-specific infrastructure impedes progress.
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.
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.
Even on top of UDP, it still bypasses TCP-specific infrastructure. It will still be subject to any UDP-specific infrastructure, but that has a significantly smaller scope, at least if you exclude measures that (for better or worse) middleboxes could just as easily apply to traffic using a new top-level protocol.
This is a wonderful and thoughtful essay. And TBH, despite having used RPC since before the TCP transition and still being frustrated (just a couple of months ago!) by doing RPC over TCP I never really twigged to the gain mismatch.
QUIC is a TCP replacement for many uses, just not all. It (or something like it) will probably the dominant protocol in the future.
People in general don't understand what TCP is. Drives my insane. In practice, is it even possible to replace anything else than web traffic with QUIC today?
yes Quic is not just HTTP. its a connection protocol
In theory it is a transport layer protocol like TCP but QUIC seems to mostly be used for specific application layer protocols.
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.
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.
again quic is not just Http.
you can proxy an sftp connexion through quic.
By having a (tcp to quic) gateway at the source and a (quic to tcp) relay at the destination.
I have seen this implemented in production!
I have seen this implemented in production!
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.