A Case Study in System Evolution. With the recent publication of a new specification of TCP (RFC 9293) we found ourselves reflecting on how TCP has evolved over the decades, and wondered what the future holds.
I've spent some time looking at QUIC, and am impressed with the technology - and especially in what the architecture portends and what it may become. One could develop other protocols with similar characteristics, but with QUIC already in all the browsers it seems that testing your hypothesis about superseding TCP is gong to happen earlier with this protocol than with trying to develop and deploy another.
Faster starts will give it an immediate benefit for short transmissions vs. TCP - especially with increasingly encrypted transmissions. So there is an end-user experience benefit, and also a bandwidth access advantage when it's co-mingled with TCP traffic. My guess is that it might also yield measurable battery improvements in wireless devices because of shortened transmissions.
QUIC is intending to provide FEC as an option. Using FEC for flows within a DE network provides an equivalency of an AF service. If you put a TCP flow within an IP-IP tunnel with FEC applied, then that TCP flow pushes aside other TCP flows on the same path. It no longer shares bandwidth equitably. This is easier to put in practice in networks with an abundance of bandwidth compared to the application need. Think Optical Broadband, 5G mmWave, and 6G WiFi. Once again QUIC with FEC will have an advantage over TCP when they are co-mingled.
I agree that the CICD approach and user-space code will allow faster deployments. As a user space application of UDP, it's not clear that any standardization need happen for a new variant - especially if that variant were negotiated at both ends for the same software supplier. It also solves the head-of-line blocking problem for multiplexed HTTP2 connections.
Finally, IMO, the biggest advantage to QUIC is having an application layer session identifier that exists across IP addresses. If the session identifier is linked to a single application, then architecturally this can become an application address, and that fixes an initial design problem with IP networking. An IP address indicates an interface on a host, and applications are "inferred" from well-known TCP or UDP ports. All sorts of problems come from this, like hosting multiples of the same app on the same server. (You could write another article entirely on what we've done to compensate from not having application addresses in IP networks, but that might be for a different time.) In fair disclosure, such a use would also require new "DNS" type function to discover these identifiers and make use of them in a larger context. Using the QUIC session identifier as an application identifier can provide many interesting benefits, and one of those that interests me the most is application-layer-mobility (think about hand-off from WiFi to a Cell network without losing the YouTube session). That is another win for end-user experience, and I think also a (long term) stake in the heart of many cellular providers. If the whole network-layer-mobility mechanism is made unnecessary - or even if it's just made an edge use case - then that speaks to a completely different future state for mobile networks. With this sort of session identifier, QUIC can easily assimilate MPTCP functionality and allow for interesting use of multiple access/network types simultaneously. That would move toward obsolete existing network-based-mobility. That, in turn, can provide benefits that are not possible with today's typical services and providers, and such benefits can lead to the sort of adoption that disrupts industries. (I actually think that mobile network providers will not go out of business, but that the sort of service they provide will change a lot in the future. But that would be a longer discussion, and I'm already typing too much. ;)
So I think you are absolutely correct that we can test your hypothesis, and also that there are a number of other interesting things going on with QUIC that are worth testing and examining. It seems that the industry is exploring how far you can push the end-to-end principle. In my case, I'm most interested in when the value-add of "mobility" is going to change hands.
Lots of good stuff going on with QUIC, but for me the high-order bit is that it offers the Request/Reply (aka RPC) transport protocol that the Internet has lacked from the beginning. We've obviously found ways to work around that limitation -- HTTP being an obvious example -- but that its taken so long is a testament to something intrinsic in how we (as a community/industry) manage change.
I've spent some time looking at QUIC, and am impressed with the technology - and especially in what the architecture portends and what it may become. One could develop other protocols with similar characteristics, but with QUIC already in all the browsers it seems that testing your hypothesis about superseding TCP is gong to happen earlier with this protocol than with trying to develop and deploy another.
Faster starts will give it an immediate benefit for short transmissions vs. TCP - especially with increasingly encrypted transmissions. So there is an end-user experience benefit, and also a bandwidth access advantage when it's co-mingled with TCP traffic. My guess is that it might also yield measurable battery improvements in wireless devices because of shortened transmissions.
QUIC is intending to provide FEC as an option. Using FEC for flows within a DE network provides an equivalency of an AF service. If you put a TCP flow within an IP-IP tunnel with FEC applied, then that TCP flow pushes aside other TCP flows on the same path. It no longer shares bandwidth equitably. This is easier to put in practice in networks with an abundance of bandwidth compared to the application need. Think Optical Broadband, 5G mmWave, and 6G WiFi. Once again QUIC with FEC will have an advantage over TCP when they are co-mingled.
I agree that the CICD approach and user-space code will allow faster deployments. As a user space application of UDP, it's not clear that any standardization need happen for a new variant - especially if that variant were negotiated at both ends for the same software supplier. It also solves the head-of-line blocking problem for multiplexed HTTP2 connections.
Finally, IMO, the biggest advantage to QUIC is having an application layer session identifier that exists across IP addresses. If the session identifier is linked to a single application, then architecturally this can become an application address, and that fixes an initial design problem with IP networking. An IP address indicates an interface on a host, and applications are "inferred" from well-known TCP or UDP ports. All sorts of problems come from this, like hosting multiples of the same app on the same server. (You could write another article entirely on what we've done to compensate from not having application addresses in IP networks, but that might be for a different time.) In fair disclosure, such a use would also require new "DNS" type function to discover these identifiers and make use of them in a larger context. Using the QUIC session identifier as an application identifier can provide many interesting benefits, and one of those that interests me the most is application-layer-mobility (think about hand-off from WiFi to a Cell network without losing the YouTube session). That is another win for end-user experience, and I think also a (long term) stake in the heart of many cellular providers. If the whole network-layer-mobility mechanism is made unnecessary - or even if it's just made an edge use case - then that speaks to a completely different future state for mobile networks. With this sort of session identifier, QUIC can easily assimilate MPTCP functionality and allow for interesting use of multiple access/network types simultaneously. That would move toward obsolete existing network-based-mobility. That, in turn, can provide benefits that are not possible with today's typical services and providers, and such benefits can lead to the sort of adoption that disrupts industries. (I actually think that mobile network providers will not go out of business, but that the sort of service they provide will change a lot in the future. But that would be a longer discussion, and I'm already typing too much. ;)
So I think you are absolutely correct that we can test your hypothesis, and also that there are a number of other interesting things going on with QUIC that are worth testing and examining. It seems that the industry is exploring how far you can push the end-to-end principle. In my case, I'm most interested in when the value-add of "mobility" is going to change hands.
Tom,
Lots of good stuff going on with QUIC, but for me the high-order bit is that it offers the Request/Reply (aka RPC) transport protocol that the Internet has lacked from the beginning. We've obviously found ways to work around that limitation -- HTTP being an obvious example -- but that its taken so long is a testament to something intrinsic in how we (as a community/industry) manage change.
RFC 9232 = Network Telemetry Framework , you mean RFC 9293 I guess?
Yup. Thanks for catching that mistake.