The Internet is evolving from both a usage and connectivity point of view as are the underlying architecture and protocols. The quest for more responsive applications, the emergence of new security and privacy concerns and the web style of design and implementation is impacting everything from ways of working to the delivery and deployment protocols and standards. The QUIC transport protocol is a concrete example of such impact. While the IETF is working on QUIC to create a usable and deployable transport protocol ensuring the protocol evolution, 3GPP is considering using QUIC for the 5G packet core. Hence, QUIC is becoming a vehicle for transport protocol evolution and we are actively contributing to that evolution.
QUIC is a UDP (User Datagram Protocol) based stream-multiplexed and secure transport protocol with integrity protected header and encrypted payload. Unlike the traditional transport protocol stack TCP (Transmission Control Protocol), which resides in the operating system kernel, QUIC can easily be implemented in the application. This brings lots of flexibility in terms of evolution, congestion control selection and implementation of new features.
Why is QUIC designed like this? Let’s start from the beginning: Originally, QUIC was designed and developed at Google. According to their design principles outlined in 2012, the main motivations were to
- reduce latency throughout the internet, especially for mobile users
- improve responsiveness in user interaction
Other benefits included better support for HTTP2 (then SPDY), and improved privacy. QUIC achieves those targets by providing Zero-Round Trip Time (0-RTT) connection setup, stream multiplexing, introduction of binary protocol framing, improved congestion control and connection migration. It is also always encrypted.
The quest for improvements in transport protocol is not new, but wider experimentation and deployment of new protocols have been unsuccessful to some extent. (The Internet Engineering Task Force (IETF) has produced a number of protocols aiming at faster and better transport for the internet.) However, newer protocols such as DCCP (Datagram Congestion Control Protocol) and SCTP (Stream Control Transmission Protocol) have had deployment issues. The middleboxes like NATs and firewalls, usually block all the traffic they don’t recognize and even impose rules to already known protocols, leading to network ossification. The selection of UDP as the base protocol for QUIC was mainly to achieve lower latency both at the connection setup and in the recovery phases. The question remained if UDP could penetrate the internet, since there were issues with restricted UDP usage in networks and UDP NAT binding. In July 2015 Google presented measurements showing that QUIC worked for over 92 percent of the connections from internet users to Google services.
Even though that figure did not differentiate between mobile users and fixed-line users, this addressed the potential deployment issues to design a transport protocol over UDP.
Another aspect that has slowed down the evolution of transport is the dependency on operating systems to adopt newer and better transport features. Here, the fact that QUIC can be implemented in the user space of operating systems helps. QUIC can be realized in an application on any host system that supports UDP.
With all those design choices and experimental results, the IETF transport community was convinced enough to start a new working group (WG) to standardize a new general-purpose transport protocol based on the original version of the QUIC protocol. This standardization work is done in the QUIC WG, in which participants from across the ICT industry, like service providers, content providers, CDN owners, and network vendors, come together to create a usable and deployable transport protocol ensuring transport protocol evolution.
The industry-wide engagement in the WG brings new requirements and additional analyses to the table, which leads to new design choices. One example: QUIC now uses TLS 1.3 for encryption. Another example: new QUIC frames have been created, like the NEW_CONNECTION_ID frame to convey QUIC connection ID alternatives to avoid likability when path migration happens. Some new features have been added, like ECN (Explicit Congestion Notification) which was not part of the initial QUIC protocol. Currently the working group is discussing some interesting topics like the possibility of packet number encryption, the inclusion of a single bit in the clear text header to help the passive measurement of RTT at the network operator’s domain. There are some decisions to make in the QUIC WG.
For 3GPP radio access technologies, there is a need for efficient transport protocol to meet the requirement on both low latency and high bandwidth, especially with the advent of 5G networks. Here, it is important to use appropriate technologies to avoid network ossification. For 5G networks, there is also a need to redesign the 5G packet core to allow more flexible network functions and innovation. The 3GPP standardization groups have decided to create a service base packet core architecture (SBA) and the choice of protocol is HTTP2 over TCP. However, being interested in the features of QUIC – which include no Head of Line (HoL) blocking, multiplexing, flow control, security, better congestion control – in short, a potentially better and faster protocol than TCP for SBA, they are now studying the potential of replacing TCP with QUIC. The decision has yet to be made but this illustrates a potential path for QUIC to become the transport of choice not only for the users’ traffic but for the control plane traffic as well.
Media traffic is and will continue to make up a dominant percentage of internet traffic. Different types of media are transported over different protocols or combination of protocols. For example, RTP is the preferred choice for conversational media, streaming media is typically transported over HTTP over TCP and when it comes to live video, there are multiple alternatives. Efforts have been made in different standardization organizations and forums to streamline the protocols and formats used to transport media traffic over the Internet. Will QUIC become the convergence layer for protocol used for media traffic? This question is yet to be answered.
Ericsson has always been a facilitator for better and faster networks and an active contributor to the evolution and definition of IETF protocols. We consider QUIC a vehicle for transport protocol evolution, and, as described through this post, there are important questions that remain to be answered. We will actively contribute to the transport protocol evolution and QUIC standardization. In that spirit, we are glad to host the June 2018 interim meeting of the QUIC working group at the Ericsson headquarters in Stockholm, Sweden.
Read more about Ericsson’s engagement with the IETF
Acknowledgments: The author would like to thank Magnus Westerlund, Jari Arkko, and Harald Kallin for contributions to the discussion.