Schahin Rajab sr2@kth.se 2016 04 20 TCP or QUIC Which protocol is most promising for the future of the internet?
Table of contents 1 Introduction 3 2 Background 4 2.1 TCP 4 2.2 UDP 4 2.3 QUIC 4 2.4 HTTP 2.0 5 3 Comparing TCP with QUIC 5 3.1 Request and Response Multiplexing 5 3.2 Latency 6 3.3 Vertical Handover 6 4 Analysis Which protocol takes home the prize? 6 5 Discussion 7 6 Conclusion 7 7 Future Work 8 References 9 1
Abstract This paper discusses which direction the internet is heading towards and whether the design of the most used transport protocol, TCP, will be able to meet these standards. Google has proposed a new experimental protocol called QUIC, in their goal of making the web faster. This paper compares different internetworking aspects of QUIC and TCP to examine which protocol suits best for the future of the internet. QUIC proved to hold the best promises with reduced latency, rapid iterations and better multiplexing. 2
1. Introduction A transport protocol is a way of exchanging data between two computers across the internet. The two most fundamental transport protocols of the transport layer are TCP ( Transmission Control Protocol ) and UDP ( User Datagram Protocol ). TCP was introduced over 40 years ago [1] and is a reliable protocol which can handle packet loss by retransmitting the packets and can also deliver the packets in order. UDP is its counterpart that does not provide these services and instead takes a connectionless approach by simply sending out the packets without establishing a connection first and these packets are then processed independently. This makes UDP faster than TCP, but is less reliable. Because of how much content there is that has to be transferred in byte order and without losses, TCP is the most widely used transport protocol today. However, the web has changed dramatically over the past two decades. From being a basic static web page being composed by only one server, web pages today are interactive and over one megabyte in size and has dozens of different resources and domain servers. Users demands a better web experience, they want high quality images and nice layout without having to wait longer than a second for the website to load (Jakob Nielsen published an article in 1993 https://www.nngroup.com/articles/ response times 3 important limits/ regarding response time where he explained that 0.1 second is how fast a website should load for it to feel instantaneous to the user ). People also access the internet through new devices such as mobile phones and tablets, and even machines are connected to networks so they can communicate with other machines! Even though we have seen a rapid development of the internet, we are still using protocols that were designed long before the first commercial internet access providers were established [2]. TCP have had many improvements since its first introduction in 1974 and is still seeing changes. However, iteration is slow and since it is built directly into the operating system s kernel, the deployment is slow as well considering the vast number of old operating systems still being used [3]. The speed of which TCP is improving at does not match the rate of change the web is undergoing. This paper will look at a new protocol that has been developed to catch up with the evolution of the internet by trying to reduce latency while at the same time does not compromise in security or reliability. This protocol is developed by Google and is called QUIC, Quick UDP Internet Connections. QUIC is built upon UDP but has similar features of TCP. Google developed QUIC with aim to reduce delay. Also, QUIC has a much faster iteration than what TCP has, a new version can be released within weeks instead of years. And it can be pushed out to clients more quickly since QUIC is built into Google s own browser, Chrome. 3
2. Background 2.1 TCP TCP guarantees that all bytes sent will arrive to its destination, and in order. TCP is connection oriented, meaning a connection has to be established before any data can be exchanged. All TCP connections are established through a three way handshake where the client begins by choosing a random sequence number and sends a SYN segment to the server. The server increments this sequence number by one and chooses its own sequence number and sends out a SYN ACK segment back to the client. Finally, the client increments both sequence numbers by one and establishes the connection by sending an ACK segment to the server. Once connection has been established, data can be exchanged through the route that was decided during the handshake. TCP splits data into segments and transfer them one by one in IP packets. When the client transfers one IP packet to the server it waits with sending out the next one until it receives an ACK segment from the server. TCP does this to make sure that the data has been received in full and in order. If an ACK segment has not been received within a certain amount of time, TCP handles this by retransmitting the lost packet. This makes TCP a reliable protocol to use. but not a very time efficient one. Since most applications depends on a reliable transport protocol, TCP is the most widely used. 2.2 UDP A datagram is a packet sent through an unreliable service with no guarantee of delivery or error correction. The user datagram protocol is a connectionless service, meaning there is a route lookup for each UDP packet. Lost packets are not retransmitted and packets are not necessarily received in order. UDP has a header that is lightweight compared to the 20 byte size header for TCP. It is only 8 byte in size and contains four 16 bit fields; Source port, destination port, length and checksum. This smaller overhead makes UDP useful when exchanging data between applications that allows loss of data in low latency. Such typical application is online gaming where low latency is needed and packet losses are acceptable. 2.3 QUIC QUIC is an experimental transport protocol developed by Google that runs over UDP. Main idea with this protocol is to reduce latency by minimizing the number of round trip times, RTT, it takes to establish a connection. If a client wants to re connect to a server, it can do so immediately without having to perform any handshake. The connection is also always encrypted [4]. 4
2.4 HTTP 2.0 The aim with HTTP 2.0 is to address the issues in HTTP 1.1 by introducing header field compression to reduce latency and by utilizing network resources more efficiently [5]. It introduces a new way of encapsulating HTTP messages called binary framing layer. Instead of text protocols, HTTP 2.0 divides its messages to smaller frames and encodes them in binary. These frames can be sent out simultaneously and makes it possible to deliver multiple requests/responses over a single TCP connection. A frame in HTTP 2.0 is the tiniest protocol unit and each frame has a frame header.. There exist different types of frames, each with its own purpose [6]. The two most common frame types are the header frame and the data frame, which carries header block fragment and HTTP request/response payloads respectively. 3. Comparing TCP with QUIC 3.1 Request and Response Multiplexing A typical issue with web pages that has many resources is how the page should be uploaded. If there is only one TCP connection opened then there can only be one request sent at a time before the client has to wait for a response from the server so it can send out the next request. This takes a long time for webpages with many resources. HTTP pipelining tackles this issue by sending multiple HTTP requests through a single open TCP connection at the same time. The problem with this is that the responses has to be sent back in the same order as the requests were received which can lead to Head of line blocking (HOL blocking). HOL blocking occurs when a request is taking so much time to be processed by the server that the subsequent requests gets blocked. Another problem is that HTTP pipelining is difficult to implement, the major web browsers have all disabled support of HTTP pipelining [7]. Instead, browsers open multiple TCP sessions to the server and sends one request through each connection and let the server handle these requests independently. This is a nice way of circumvent the TCP slow start limit as the TCP congestion windows are multiplied by the number of opened TCP sessions. But it is more expensive to operate since every established connection requires extra memory and CPU consumption for both the client and server. Also, implementing multiple parallel TCP connections is difficult to do [7]. A solution to this problem has been presented with the HTTP 2.0. Instead of opening multiple TCP sessions, HTTP 2.0 uses its binary framing layer to divide each HTTP message into frames and allows these frames to be interleaved and multiplexed onto a single TCP connection and reassembled at the other end [7]. This method reduces loading time for web 5
pages and also reduces the CPU usage and memory costs since we only require one TCP connection. However, since HTTP is based upon TCP, there is still a problem with HOL blocking at the transport level. But this is something QUIC could fix. Since QUIC runs over UDP, it can avoid this issue of TCP head of line blocking because UDP is not in order. 3.2 Latency Reducing the time it takes to load a web page is crucial to keep users engaged with the web site. When establishing an encrypted TCP connection, i.e. TCP+SSL ( Secure Socket Layer ), there is a handshake with up to 3 round trips. If one round trip would take, say, 100 milliseconds the client would then have to wait 300 ms before being able to send out the first request. QUIC on the other hand only require one round trip to establish a connection with a server it has not talked to before, and zero round trips to re connect to a server. QUIC manages to encrypt the connection even with zero round trips by assuming that the server s public key is still the same as before [8]. 3.3 Vertical handover When a device connected to the internet switches from one network interface to another, this is called a vertical handover. This could for example be, switching from 802.11 (Wi Fi) to LTE. The IP address of the device will change after a vertical handoff, and consequently, so will the port number. This is an issue for TCP since it is dependent on the ports at the endpoints which means that a new TCP connection needs to be established. A solution to this is Multipath TCP and is developed by the IETF, Internet Engineering Task Force, where a device can connect to multiple networks [9]. This would mean if one network drops the device can instead fall back to another one without losing the TCP connection or the congestion window. QUIC, on the other hand, does not rely on port pairs. Every QUIC packet has instead a 64 bit GUID, Globally Unique Identifier, which can be used to identify which port it came from to the server after the handover. This should help making the transition to a new network interface almost unnoticeable. And if the QUIC connection would be lost it could simply re connect to the server again with zero round trip time. 4. Analysis Which protocol takes home the prize? Internet is expanding at a rapid rate and QUIC is part of Google s goal to make the web faster. Not only do each person have multiple devices connected to internet nowadays, we are also starting to see devices being connected to other devices Internet of Things. It is estimated that by 2020, more than 50 billion devices will be connected [10]. Innovations are required to address this and TCP as it is today will not keep up. 6
QUIC reduces latency by clever zero round trips to talk to a server it already has talked to before. It solves the TCP bottleneck when it comes to head of line blocking problem by using UDP instead. And since TCP was originally designed during a time when machines were very large and stationary, it does not perform well during vertical handovers [11]. TCP is dependant on the source s and destination s IP port, and after a handover the device is assigned a new IP address so the TCP connection has to restart. This is too slow for the future. Already today most people are using mobile devices everywhere they go. Devices needs to be quicker at adapting to changes of network interfaces. QUIC solves this by having a 64 bit GUID on every packet that can explain to the server which port it came from before the handover, and which port it is using now. All this and more makes QUIC an attractive protocol to be used in the future instead of TCP. QUIC may not replace TCP, but perhaps some of its successful features can be implemented in TCP. 5. Discussion Trying to improve TCP instead of developing QUIC is not easy. Deploying a new version of QUIC is quick since the protocol is implemented directly into Google Chrome instead of some operating system kernel. When it could take more than a decade to release a new version of TCP to everyone because most people sits on old operating systems, it could take weeks for Google to just update QUIC on everyone s Chrome browser. This rapid iteration of QUIC is very beneficial to the future course of the internet since Google can collect statistics of how QUIC is performing and make changes accordingly. It accelerates the pace of which the web is changing at. Developing a whole new transport protocol is also a difficult task. All the routers and servers which helps transfer a packet between two endpoints have to understand the protocol being used or else it will drop it. Reprogramming every server, router, hub, switch etc. is close to impossible, so there is not much choice other than using TCP or UDP. Hence, why QUIC rests on top of UDP. 6. Conclusion TCP has design problems that does not match with the web today. QUIC has some promising features that could very well change our web experience dramatically in the long run. It is still in the experimental stage and mainly only Google s own servers supports QUIC. 7
7. Future work Google has released a QUIC toy server and client to be used by anyone [12]. This could be used to test how much better QUIC performs at packet recovery than TCP is and how QUIC behaves during packet losses. It would also be interesting to test out how much faster it is to download various web pages with QUIC than it is with TCP by enabling and disabling QUIC in the Chrome settings. 8
References [1] TCP/IP Background: TCP/IP. Accessed 7 April 2016. https://technet.microsoft.com/en us/library/cc775383(v=ws.10).aspx. [2] Roger Clarke s The Internet in Australia. Accessed 7 April 2016. http://www.rogerclarke.com/ii/ozi04.html#ciap. [3] QUIC FAQ for Geeks. Google Docs. Accessed 7 April 2016. https://docs.google.com/document/d/1lml9ef6qkrk7gbazy8bidvq3pno2xj_l_yshp40glqe/edit?pr ef=2&pli=1&usp=embed_facebook. [4] QUIC Crypto. Google Docs. Accessed 20 April 2016. https://docs.google.com/document/d/1g5nixaikn_y 7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?pref=2&pli=1&usp=embed_facebook. [5] RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2). Accessed 20 April 2016. https://tools.ietf.org/html/rfc7540. [6] Hypertext Transfer Protocol Version 2 (HTTP/2). Accessed 20 April 2016. http://http2.github.io/http2 spec/index.html#frametypes [7] Grigorik, Ilya. High Performance Browser Networking. O Reilly Media, 2013. p. 192, p.196, p.214. [8] QUIC Crypto. Google Docs. Accessed 20 April 2016. https://docs.google.com/document/d/1g5nixaikn_y 7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?pref=2&pli=1#heading=h.bzxklo2i5w6k. [9] Internet Draft MPTCP Working Group. Accessed 20 April 2016. https://www.ietf.org/id/draft ietf mptcp experience 04.txt. [10] CEO to Shareholders: 50 Billion Connections 2020 Ericsson. Accessed 20 April 2016. http://www.ericsson.com/news/1403231. [11] Ronquist, Mattias. TCP Reaction to Rapid Changes of the Link Characteristics due to Handover in a Mobile Environment. Royal Institute of Technology, 1999. http://people.kth.se/~maguire/degree PROJECT REPORTS/990805 Mattias_Ronquist final report.pdf [12] Playing with QUIC The Chromium Projects. Accessed 20 April 2016. https://www.chromium.org/quic/playing with quic. 9