# Evaluation of Modern Internet Transport Protocols over GEO Satellite Links
## 3 Modern Internet Transport Protocols
### Quick UDP Internet Connection  
Quick UDP Internet Connection (QUIC) is a new UDP-based transport protocol that was designed to overcome several practical limitations of TCP. The current standardized protocol evolved from two versions: Google QUIC (GQUIC) and Internet Engineering Task Force QUIC (IETF-QUIC) [18]. The two versions have different implementations but they follow the same principles. Essentially, it is a byte-stream protocol that creates a reliable secure connection between the client and the server. Similar to TCP, it employs congestion control algorithms for detecting and recovering from packet loss to ensure error-free delivery. In the following, we summarize the main differences between TCP and QUIC to highlight the features of the new protocol. First, TCP requires the full three-way handshake for connection setup before any data transfer and another handshake to establish the TLS parameters for the connection whenever TLS-level security is desired. In contrast, QUIC allows faster connection setup with a mandatory TLS session to create a secure connection with minimum handshake overhead. It can establish a secure HTTP session within 1-RTT and even 0-RTT as illustrated in Figure 2. Although QUIC could use 0-RTT to establish a new connection, it will be vulnerable to security issues such as IP spoofing, amplification attacks and denial-of-serviceattacks. Therefore, it normally uses 1-RTT to reduce the handshake overhead compared to TCP without causing significant security risks [18]. Second, TCP suffers from the head of line blocking (HoLB) problem because it multiplexes multiple application-layer messages into a single layer-4 byte stream, in which a segment loss affecting one message will hold the other messages until the loss is recovered. QUIC avoids this problem by multiplexing the messages into one QUIC connection but each message is processed independently from the others. Thus, a segment loss in one message will not affect the others; only the affected message will be delayed until it recovers from the loss. For example, suppose application-layer messages \(A\), \(B\) and \(C\) have their sequence of multiplexed segments as \(A_{1}A_{2}B_{1}C_{1}C_{2}B_{2}A_{3}C_{3}\). If the client uses TCP, then a loss in segment \(B_{1}\) will delay the processing of all subsequent segments at the receiver until it recovers from the loss. However, QUIC will delay only the segments belonging to message \(B\) while the remaining segments in messages \(A\) and \(C\) will be processed as they arrive in order at the receiver [18]. Third, TCP uses the 4-tuple (client IP address, client port, server IP address and server port) to uniquely identify the connection between the client and the server. So, when the client moves from one network to another, the TCP connection will be terminated because the connection ID is associated with the client IP address. A new handshake would be needed to restart the connection with the server which will restart any ongoing application-layer data transfer. QUIC solves this issue by using a unique connection ID (CID) in both endpoints to eliminate the dependency on IP addresses and ports when establishing the connection. This allows client handoff to another network, e.g., from WiFi to 4G, with a new IP address without resetting the QUIC connection because it is detached from the client IP address [18]. QUIC adds a new abstraction layer between applications and transport in order to be easier to evolve and deploy in existing Internet platforms. However, this abstraction comes with the cost of increasing the overhead of the protocol stack and encryption. Because the  
Figure 2: Example HTTP requests/responses in HTTP/2 with TLS, HTTP/3 with 1-RTT and HTTP/3 with 0-RTT. implementation of QUIC is part of the applications, all TLS related encryption is done at the user space. This deprives QUIC of the faster kernel-space implementation and hardware acceleration that is available to TCP.