James Kehr here with the Windows Networking Escalation Engineering team. Today’s topic is the newly published QUIC protocol. This is a quick discussion, all puns intended, about why QUIC is important to the modern internet.
Back in my day…
Back in the old days, about the mid-1990’s, when the Internet was new and the Wild Wild Web was a better fit for WWW than the World Wide Web, Internet connections were really slow. Youngsters can’t appreciate just how amazingly slow the Internet was back then.
A simple web page could take upwards of 1-2 minutes to load. Good video streaming, forget about it! High resolution video was originally 640x480, what we now call 480p or SD video, but most early video was 320x240. Even at the lower resolution you’d start the video, then immediately pause it so the video could buffer. Go refill your beverage, talk with friends, read a book, and about 5-10 minutes later you could start the video. And, if you were lucky, it wouldn’t pause to buffer before the video was done.
This is normally the part when us old timers do the traditional joke of “And we liked it! We loved it!” but that would be a lie. We hated it. It was horrible. We were Internet addicts and we wanted to surf the net and not have to wait.
Students of computer history will note that around this time a huge surge in computer advancements began. Processor and network speeds improved dramatically. Displays got larger with higher resolutions. New Internet connection technologies sprung up everywhere. Then the smartphone happened, and a second wave of innovation hit. To put this in perspective, the current flagship smartphones are about ten times (10x) more powerful than the fastest super computer of 1995.
The driving force behind most of this innovation was, you guessed it, a fast and stable Internet experience. People today want to open a site and have the page loaded by the time their thumb clears the smartphone screen or the cursor clears the browser window. Our video needs to stream immediately in 4K with no buffering and no pixelation.
Despite the massive leaps in technologies that have enabled the modern Internet experience, we have been using the same major Internet protocol since the beginning, our tried-and-true friend, TCP.
The Old Guard and the New Guard
Let me start by saying that TCP, or Transmission Control Protocol, isn’t go anywhere any time soon. It is, and will be, the dominant network protocol in the world for years to come. Which begs the question, why replace it?
TCP was first developed in 1974 for the precursor to the Internet, ARPAnet. A little math will reveal that TCP will have its 50th birthday soon. ARPAnet was mainly used by military and educational institutions across closed circuits until ARPAnet became the commercial Internet in the early 1990’s. The TCP/IP suite of protocols used by ARPAnet were carried over to the Internet. TCP, as the resilient transport protocol, became the de facto standard for most Internet activities. Without TCP the Internet would not have worked quite right.
This is normally where I say something like TCP is bad and needs to be replaced, but there isn’t anything necessarily bad about TCP because it’s a great protocol. The problem is that we can’t change TCP to make it better and meet the needs of modern Internet services that need to be crazy fast. The TCP protocol is simply too embedded to make any significant changes to it without the risk of breaking millions of devices.
A lot of ideas have been thrown around to improve the Internet experience over the years but none of them stuck until QUIC, the Quick UDP Internet Connection protocol, was developed at Google using a unique concept. Rather than developing a completely new protocol that would require a massive upgrade to the Internet backbone the QUIC protocol extends an existing protocol, UDP. I say extend because QUIC is a transport layer protocol, not an application protocol, even though QUIC is transmitted inside the UDP segment. Think of it like this:
UDP + QUIC = the transport layer
QUIC uses UDP for ports and connectionless transport, then adds the resiliency of TCP, the security of TLS 1.3, sprinkles in a dash of commands and version control from protocols like SMB, and then mixes in a set of new protocol concepts and efficiencies to create something entirely unique in the protocol world.
Why Should I Care?
Big tech companies are excited about QUIC because it adds several changes that will help make Internet services better, especially edge services where every millisecond matters. By extension, this makes the Internet experience better for everyone. Here are some of the improvements in QUIC:
Encryption
QUIC 1.0 requires TLS 1.3 based encryption for all data. This makes data over QUIC inherently secure regardless of service.
Lower Connection Latency
QUIC doesn’t change the laws of physics, but it doesn’t have to wait for two handshakes (TCP then TLS) to complete a secure network connection. Connection setup takes fewer packets to complete than TCP + TLS and can be resilient after close. This means you start getting data faster the first time you connect to a service, and potentially faster the second time.
Connection Reuse
QUIC can reuse a session in two ways: streams and session tickets. A single QUIC session can have multiple simultaneous data streams. A server can also grant clients a session ticket that can be used to reconnect to a server without going through a full handshake. This reduces the number of client-server connects and allows fast, secure reconnections.
Connection Migration
This is one of the coolest features, in my opinion, as it allows a QUIC connection to survive an IP change. Let’s say you have a laptop with WiFi and LAN, and switch from a wired LAN connection to WiFi. With TCP the connections must be closed, and new connections opened using the WiFi IP address. With QUIC, the client can provide evidence to the server to prove who they are and continue with the existing connection on the new IP as if nothing changed. Making the mobile user experience more seamless.
Security
In addition to encryption, QUIC is built to prevent or lessen the impact of things like Denial of Service (DoS), replay, reflection, spoofing, and other types of attacks. QUIC can’t eliminate all attacks, but it does try to make it harder to successfully attack.
Version Control
QUIC can change and be adapted to meet new Internet needs because it has version control. QUIC 1.0 was published in May 2021 via RFC 9000, plus RFCs 8999, 9001, and 9002. Future versions of QUIC are free to change the protocol as needed. Computers can support multiple simultaneous versions of QUIC. This allows new version to fix and improve the QUIC protocol while supporting older implementations during a transition period. Over time the old versions can be dropped to keep QUIC secure and up to date for decades to come.
Extension Frames
People and companies can extend QUIC to meet their own needs. This is handled via QUIC extension frames, which can be public and potentially be added to a future version of QUIC, or private and used only for internal services. There are few rules that must be followed, but otherwise people are free to extend QUIC via custom frames as they see fit.
The All-Important Caveats…
Not everything is sunshine and flowers in QUIC land. QUIC 1.0 is brand spanking new, less than 4 months old at the time of writing. It’s going to take time for most devices to support QUIC. Modern browsers already support QUIC. The newest versions of Windows, Window 10 21Hx, Windows 11, and Windows Server 2022, have native QUIC support. Some older versions of Windows should see MsQuic support in early 2022. Apple has native QUIC support starting with Big Sur. Linux and FreeBSD currently need a QUIC driver installed or implemented in the user application, but future versions may have native support.
Older OS builds are the problem here and may not have any QUIC capabilities outside the browser. And if there’s one thing that IT has taught me, many people are generally slow to upgrade.
Then there’s the learning curve when developing for QUIC. The QUIC protocol does things a bit differently than TCP and plain UDP. Learning the best way to leverage QUIC streams to your advantage will take some time and effort.
Finally, there’s the traffic shaping problem. Some networks and ISPs will prefer TCP traffic over UDP, and rightly so. TCP is currently the de facto transport protocol on the Internet. This can, however, cause problems with QUIC performance in the short term when certain network congestion conditions are reached. A heavily congested network may drop UDP traffic to pass TCP traffic. This will change as backbone networks become more aware of QUIC. In the short term, there might be performance issues during peak hours.
Does this give you license to ignore QUIC? It shouldn’t. Microsoft, Apple, Google, Amazon, Facebook, Cloudflare, and other big tech companies are already using QUIC because of its advantages over TCP. The tech world is ready for a QUIC switch, so you should be thinking about it, too.
MsQuic
No article would be complete without a small plug for your own product. Microsoft’s implementation of QUIC is called MsQuic. It is an open source, cross platform project available to the world. Windows and Linux are fully supported as of version 1.5.0, with MacOS currently in the alpha stage. There is support in MsQuic for the UDP offloading features announced for Windows Server 2022, which will be available in Windows 11, as well. The UDP features do require a compatible network adapter. MsQuic performance is pretty impressive, too.
I hope that helps you understand some of the pros and cons of QUIC, and why people are so excited about it. Keep an eye on the Networking and Storage at Microsoft Tech Communities for more content about QUIC and SMB over QUIC in the future.
Microsoft
