Understanding QUIC Hunter Dellaverson, Tianxiang Li, Jana Iyengar, Lixia Zhang

+-+-+-+-+-+-+-+ ABSTRACT | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ Instead of describing QUIC mechanically by enumerating, | Destination Connection ID ... | Frame 1 | | Stream ID ... step-by-step, how it works, this paper aims to explain QUIC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | Packet Number ... | Frame 2 | | [Offset] ... from the €rst principles. We €rst use TCP, the most widely +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ used transport protocol so far, to explain the basic functions | Protected Payload (*) ... … | [Length] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ performed by a transport protocol and observed issues, and | Frame n | | Stream Data (*) ... discuss the insights learned from the design of a few other +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ transport protocols. We then move on to describe the QUIC Figure 1: QUIC Packet Format. ‡is is the Short design, the how’s and why’s of its speci€c approaches to Header2Packet Format used a er the version negoti- addressing the identi€ed problems. ation and 1-RTT key exchange process.

1 INTRODUCTION Œis includes congestion control, reliable delivery, QUIC is a relatively new transport protocol with a big up- etc. take and the potential to eventually replace TCP [7]. Many • A ’security’ layer that provides QUIC with secu- people want to learn QUIC quickly, but diving into the QUIC rity. Most importantly, this encompasses the 0-RTT speci€cations seems infeasible; not only the specs are long, handshake and authenticated connection setup. but they describe the protocol operations without necessar- ily explaining why. Œis writeup hopes to o‚er an insightful 2.1 ‡e Top Layer look at QUIC. 2.1.1 Multiplexing. line holder QUIC looks very di‚erent from TCP that people are fa- Connection: Each QUIC connection can accommodate miliar with, but exactly what are the di‚erences? And more multiple application data streams, following a similar idea importantly, why are these di‚erences? Where did the new to the structured stream abstraction of SST [4]. ideas come from? We note that the QUIC design and devel- Stream and frame: Each stream is identi€ed by a stream opment are still in rapid progress, therefore various speci€c ID. Each stream resembles a TCP connection, providing aspects are likely to change in near future. Nevertheless, we ordered byte-stream delivery either uni- or bidirectional. expect that the core elements focused on by the paper will Œe byte stream is cut to data frames, analogous to a TCP remain part of the protocol. segments. Stream frame o‚set is equivalent to TCP seq#, We begin by examining the taxonomy of the QUIC proto- used for data frame delivery ordering and loss detection col itself (§2), separated into logical components. We then and retransmission for reliable data delivery. Each data move into examining TCP as an illustrative example to show frame is uniquely identi€ed by [stream ID, frame o‚set]. the basic functions in a transport protocol, the issues that Multiple frames from di‚erent streams can be packaged into have been identi€ed, and lessons learned from years of trans- one QUIC packet (Figure 1) for transmission as long as it port protocol designs (§3). Finally, we investigate some of is within the MTU limit. When a QUIC packet is ACKed, the remaining challenges facing both QUIC and future trans- it indicates all the frames carried in that packet has been port protocols. (§4). received. Packet: Each packet in a QUIC connection is assigned 2 QUIC a unique packet number. Œis number increases monotoni- In this section we focus on the technical insights in the QUIC cally, indicating the transmission order of packets 1. A QUIC design, explaining how QUIC provides the required func- receiver inform the sender of each packet it receives via tions. QUIC can be thought of as having three components, QUIC ACK frames; however the sender does not retransmit which are helpful for providing structure to a discussion: lost QUIC packets; see §2.2.2 for data loss recovery. • A ’top’ layer that interfaces with applications, and 1 which applications directly use. Œis includes streams QUIC uses di‚erent packet number space for each encryption level (initial packets, handshake, application data). Packet numbers are unique within and other signalling. each packet number space, and packets are acknowledged in its own packet • A ’boŠom’ layer that interfaces with the network number space. Œis enables cryptographic data separation between di‚erent and provides an abstraction for the ’top’ layer to use. space. 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Gap] ... | Largest Acknowledged ... runs over a TCP connection, which supports reliable delivery +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [ACK Range] ... of a single byte steam only, the order of response contents | ACK Delay ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ can only be delivered according to the order in which the | [Gap] ... | ACK Range Count ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ server receives the requests. | [ACK Range] ... | First ACK Range ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Œe QUIC design provides the multiple stream support to +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | ACK Ranges (*) ... address the above limitation. More speci€cally, HTTP/3, the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Gap] ... | [ECN Counts] ... latest version of HTTP which is designed to run over QUIC, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [ACK Range] ... utilizes QUIC’s stream semantics to enable each HTTP re- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ sponse being delivered independently and with di‚erent Figure 2: QUIC ACK Frame Format. ‡e Largest Ac- priorities.” knowledged €eld indicates the largest packet num- • QUIC incorporates the stream multiplexing, per- ber the sender is acknowledging. An ACK Range stream ƒow control features originally provided by indicates the number of continuously acknowledged HTTP/2 into the transport layer. packets before the largest acknowledged packet num- • As the underlying transport for HTTP/3, QUIC pro- ber. Gap indicates the number of continuously unac- vides reliable in-order delivery at stream level and knowledged packets before each ACK Range congestion control at connection level. QUIC also provides security matching TLS + TCP, and lower connection set up latency. Packet Acknowledgment: QUIC receiver ACKs the • HTTP/3 uses frames as the basic unit of communi- largest packet number ever received, together with selective cation, application data is framed into QUIC Stream ACK (ACKing all received packets below it, coded in contin- Frames. Stream management is handled at the trans- uous packet number ranges) as shown in Figure 2. Œe use port layer, QUIC takes care of the reliable delivery of purposely de€ned ACK frame can support up to 256 ACK and ordering of the frames, then passes the received blocks in one ACK frame, as compared to TCP’s 3 SACK data to the application. ranges due to TCP option €eld size limit. Œis allows QUIC • Each HTTP request-response pair is mapped into an to ACK received packets repeatedly in multiple ACK frames, independent stream. Œis means di‚erent request- leading to higher resiliency against packet reordering and response pairs do not block each other in case of losses. loss. Since QUIC packet number increases monotonically and is decoupled from loss recovery, it can be used to tell easily Unreliable Datagram Delivery using QUIC: Some ap- and accurately about how many packets may be inside the plications, particularly those that need to transmit real-time network, as compared to TCP congestion control which data, prefer to transmit data without reliable delivery. Cur- shares the same ƒow control window used for reliability. rently one may support these applications by using UDP Head-of-Line Blocking: Since QUIC uses multiple inde- as the transport protocol, or the secure counterpart DTLS pendent streams, it avoids the Head-of-Line Blocking prob- [RFC6347]. Extending QUIC to support unreliable but se- lem, caused by waiting for recovering lost packet. When a cured data delivery would improve the above approach with packet is lost, only the streams with data frames contained a reliable and authenticated handshake, followed by secure in the packet will need to wait for the retransmission of the but unreliable delivery of application datagrams. Please refer lost frames. It will not block other streams from moving to [3] for more details forward. 2.1.2 Application over QUIC. HTTP mapping over QUIC: 2.2 ‡e Bottom Layer As an application protocol, HTTP encodes application con- 2.2.1 Congestion Control. line holder tents with rich semantics, and the most relevant feature to Decoupling of congestion control from reliability transport delivery is its request-response message exchange control: QUIC uses monotonically increasing packet num- model: a browser client can issue multiple requests in paral- bers for congestion control, and stream frame o‚set for lel, whose responses o‰en desire di‚erent delivery priorities reliability control. to maximize the viewer experience. However when HTTP Incorporating existing algorithms: QUIC does not aim to develop its own new congestion control algorithms, 2 QUIC has two types of packet headers. QUIC packets for connection nor use any speci€c one (e.g. cubic). Instead QUIC intends establishment need to contain a number of information, it uses the long header format. Once connection is established, only certain header €elds to follow the spirit of TCP congestion control. QUIC also are necessary, the subsequent packets use the short header format for provides an interface for incorporating di‚erent congestion eciency [7]. control mechanisms. 2 To avoid unnecessary congestion window reduction, QUIC security relation in between; these two IP addresses must does not collapse congestion window unless it detects per- stay stable throughout the handshake process. A‰er that, sistent congestion (loss of packets over a threshold period of one end of an established QUIC connection can securely ac- time). cept IP address changes from the other end if it can present the binding between the crypto and connection ID.3 Œis 2.2.2 Loss Detection and Recovery: ACK-based loss de- allows a QUIC connection to stay up in face of end point tection: As elaborated above, QUIC packets each contain address change (IP address and port number), for example a number of frames, each of which can be considered anal- in the case of connection migration or NAT rebinding. As ogous to an IP packet. QUIC performs loss detection on a double-check, an end point performs path validation if it the basis of these packets (which is to say, the equivalent detects the peer address change, by sending a special chal- of a collection of IP packets): for each ACK’d packet, all lenge frame with some random data to the peer’s address frames carried in that packet are considered received. Œe and receiving an echoed response with the same data from frames carried in a packet is considered lost if that packet is that address. unacknowledged when a later sent packet has been acknowl- edged, and when certain threshold is met. QUIC uses two 2.3.2 Connection Set Up and Security. Combines trans- types of threshold for determining whether an earlier sent port and security handshake together QUIC combines packet is lost, (i) packet number based: the in-ƒight packet’s transport and security handshakes together, acquiring the sequence number is smaller than the acknowledge packet information necessary for both in 1-RTT. More speci€cally, by a certain number, (ii) time-based: the in-ƒight packet this entails doing an authenticated key exchange along with was sent a certain amount of time before the acknowledged an authenticated transport parameters exchange at the same packet. Œese thresholds provide some grace period for time. Œis minimizes the latency necessary to set up a se- packet reordering, and avoids unnecessary retransmissions. cured connection. Whereas conventional TCP keeps secu- It also aims to avoid performance degradation caused by the rity and transport parameter exchanges separate – TLS lives congestion controller when detecting packet loss. on top of TCP – QUIC tightly integrates security. Part of Loss Recovery: A‰er loss has been detected. Œe lost this tight integration of security is that almost everything frames are then put into new outgoing packets (which will be in QUIC (outside of €elds necessary for the network, e.g., assigned new packet numbers, unrelated to the lost packets). source and destination addresses) is encrypted. Œis is an As QUIC packets are never retransmiŠed, this avoids the incredibly central design choice, that informs much of the ”retransmission ambiguity” problem in TCP caused by the rest of the protocol. Many of QUIC’s selling points, such retransmiŠed packet carrying the same sequence number as the increased privacy with respect to ISPs stem from as the lost packet. this. However, this encryption has also given rise to QUIC’s Accurate RTT Estimate: Accurate RTT estimate is well-known problems with €rewalls [2]. important for loss detection and congestion control. QUIC First time connection Instead, it uses TLS 1.3 running ACK encodes the delay between the receipt of a packet and over QUIC in order to provide security [6]. Œe relationship the transmission of its ACK. Œis allows the receiver of ACK between QUIC and TLS can be described as QUIC taking to calculate the actual time used in transmiŠing the packet information from TLS (handshake messages, keys, etc), and in the network. QUIC’s monotonically increasing packet in turn providing packet protection to TLS. Œe full €rst-time number avoids retransmission ambiguity, this combined connection proceeds as follows: with the ack delay feedback of each packet, provides accurate • Œe client sends Die-Helman keys in the €rst Hello RTT measurement. message, using the TLS the key share extension, which contains the endpoint’s cryptographic param- 2.3 ‡e Security Layer eters. Notably, this means the server is missing as- surance that the client is authenticated (which is 2.3.1 Connection Identifier. line holder optional), that the client is live, and that any re- QUIC uses the combination of two numbers, one from ceived 0-RTT data isn’t due to a replay aŠack. Œus, each end, to form a connection ID. When seŠing up a con- the only use for these keys prior to handshake com- nection, the client provides its own source connection id pletion is sending data. (SCID) and a random destination connection id (DCID) [5]. • Œe server completes the cryptographic handshake, Œe server will reply to this initial packet (either with a acks the initial frame, and includes a new connection handshake, in the 1-RTT case, or with data, in the 0-RTT id. case), and the client uses the SCID as the DCID in all future packets. To bind the connection ID to IP addresses, QUIC 3TCP does not have security state establishment between the two end, thus uses the initial IP addresses of client and server’s to establish it cannot accept dynamic IP address changes. 3 Figure 3: A Diagram illustrating the QUIC-TLS 1.3 1- Figure 4: A Diagram illustrating the QUIC-TLS 1.3 0- RTT exchange RTT exchange

• Œe two are thus using new session-speci€c keys that is idempotent.Additionally, in order to reduce security (ensuring forward secrecy), and can now proceed vulnerabilities, when a Client’s cached information expires, with a normal connection. the Server should reject the 0-RTT connection and send its 0-RTT connection resumption As mentioned in the authorization info as in the €rst time connection setup. Œis previous section, rather than using a novel protocol, QUIC is built into the QUIC protocol, and the Client should have uses TLS over QUIC [6] for 0-RTT connections. Œe full no trouble moving directly into a ’€rst time’ connection ’exchange’ is illustrated in Fig. 3, and proceeds as follows: setup. Version Negotiation Unlike traditional transport proto- • Œe Client sends a Hello packet with a few extra cols, QUIC supports the co-existence of di‚erent protocol extensions. Along with the actual data being sent in versions. In order to carry out this feature, the client and the message, the Hello packet also contains the fol- server can negotiate a mutually supported protocol version lowing: the key share extension, which contains the before establishing a connection. Œis is useful for the pro- endpoint’s cryptographic parameters; the pre shared key tocol to continuously evolve while allowing endpoints to extension (along with a psk key exchange modes), negotiate which version to use. For clients that support mul- which is used to denote the identity of the pre-shared tiple QUIC versions, QUIC should choose the largest of the key to be used in the handshake; and the early data minimum packets sizes across all the supported versions extension contains some information about the data as the size of its €rst packet. If the server does not accept being transmiŠed. the version selected by the client, it will send an additional • Œe Server then uses the TLS stack to check validity Version Negotiation packet to the client listing its accepted (e.g. if the correct cipher-suite was used). If the versions. Œis will introduce an additional 1-RTT latency to packet passes this check, the server uses both the the QUIC handshake process. QUIC stack, along with the application protocol to check the packet’s validity. 2.3.3 Authenticated and Encrypted Header and Payload. • Part of the QUIC stack check is ensuring that some Œe QUIC protocol has made an intentional choice to en- additional transport state is associated with the ses- crypt all practical portions of the packet. Œough this is a sion ticket, above and beyond the TLS 1.3 require- tradeo‚ – to give a speci€c example, hiding information ments. from the ISP has both bene€ts and costs – it enables new • When client’s cached information expires, server protections for end users. To be more speci€c, QUIC au- may reject 0-RTT connection and send its authen- thenticates all of its headers and payload (except version tication information as in the €rst time connection negotiation packets), as well as encrypting most of the data setup. exchanged. Figure 1 shows the QUIC packet format, packet Œere are, however, some additional best practices that should header €elds are unencrypted as they are used for rout- be followed. For instance, when using the 0-RTT mode, best ing or performing decryption of the payload. Œe packet practice dictates that the Client and Server should still create body containing frames are encrypted. Everything in the and use 1-RTT session keys to prevent replay aŠacks on the unencrypted header must remain in plaintext for proper op- protocol. 0-RTT keys should only be used to protect data eration. Œe header contains ƒags that are needed to specify 4 which €elds are included in the header and the length of certain €elds. Œe Connection ID is used for routing the Sender 6 5 4 3 2 1 Receiver packet to its destination server, and simultaneously serves as an identi€er for connection state. Œe packet number is needed for authentication and decryption, and thus can’t be Head Of Line Blocking encrypted. Figure 5: TCP Head of Line Blocking. Œis encryption also has the bene€t of ensuring QUIC can remain relatively easy to update. protocol ossi€cation is a well known problem – middleboxes cannot be easily up- • TCP performs reliable connection setup (tear down) graded to meet protocol changes, which limits the ƒexibility to let both ends agree on the initial (€nal) sequence of network protocol design. QUIC packets are mostly en- number used in a connection. Œis is done through crypted, which prevents modi€cation by middleboxes, and standard 3-way handshake. limits protocol ossi€cation. • reliable delivery needs 3 ingredients: data identi€er, ACK, retransmission timer. 3 TRANSPORT PROTOCOL 101 For connection setup, note that the initiating end can start In this section we start with TCP as an example to identify sending data with the third handshake message, thus there is the set of basic functions a (unicast) transport protocol must just one round trip delay. As we shown in §2.3.2, QUIC’s ini- support. People familiar with TCP may skip §3.1 and §3.2 tial connection setup follows a similar step, except that TCP to go directly to §3.3 which describes a few other transport uses this RTT just to reach agreement on initial sequence protocols that QUIC design draws lessons from. number, while QUIC to establish security association.

3.1 TCP 3.2 TCP’s Problems To provide reliable data delivery service between two end 1. head of line blocking (HLB): TCP uses window-based points, every data piece must be uniquely identi€ed, allow- ƒow control with sequential delivery, if a data piece D is lost, ing the two ends to €gure out whether all the data pieces waiting for D’s recovery by retramsmission leads to HLB. have been delivered. All transport protocols achieve this goal 2. Congestion control (CC): CC function was patched by €rst de€ning a unique connection identi€er, and within on TCP by borrowing the same control window used by ƒow- the connection assigning each data unit a unique identi€er, control mentioned above. CC aims to control the number of which is a monotonically increasing sequence number in packets inside the network, N . However whenever packets general. With monotonically increasing sequence numbers, are lost, the window adjustment is constrained by waiting the receiver can inform the sender of all the data it has re- for loss recovery, so its size is no longer a good estimate of ceived up to Seq# n by a simple cumulative acknowledgment N . ACK (n). 3. IP address changes can occur due to host multihom- TCP uses the combination of the two end points’ IP ad- ing, or mobility, and/or change of NAT. dresses and port numbers to create a globally unique con- 4. cost of 3-way handshake every time one communi- nection identi€er. However the use of IP addresses as part cates with another host, and lack of security support. of the connection ID makes a TCP connection fragile – it 5. Expressiveness of control: TCP packs all non-data breaks whenever any end changes its IP address. As we related communication between the two ends into the same show in §2.3.1, QUIC €xes this problem by replacing the two 20-byte TCP header: setup, tear down; ACK; and connection IP addresses by two unique numbers randomly drawn by reset. When new info needs to be communicated, e.g. SACK, each of the two ends. it has to be squeezed into TCP header option which is limited TCP performs three basic functions: to 20 bytes max. (1) demultiplexing, which is done by using port num- bers. 3.3 Other Transport Protocols (2) reliable byte stream delivery with window-based Although TCP has been the dominant transport protocol ƒow control, and in use by far, a number of other transport protocols were (3) congestion control, which was added to TCP a‰er also developed over the years, each €lls some needs missing its original design. from TCP. Œe second of these functions requires some further elab- 3.3.1 T/TCP. T/TCP: Transaction TCP (RFC1644), which oration: keeps the connection state a‰er the initial establishment, 5 thus avoiding the 3-way handshake for subsequent transac- 3.3.4 (D)TLS. Internet applications needs crypto protec- tions. tion, which got patched onto the existing transport protocol. Œe TLS design: it needs reliable delivery support of struc- 3.3.2 RTP. UDP can be viewed as a NO-OP transport tured data unit (ADUs). So it de€ned its own “Record Layer” protocol other than using port numbers to demultiplex in- and relies on TCP to provide reliable delivery. coming packets to intended processes, and an optional check- sum. However UDP does o‚er a likely unnoticed, but rather 3.4 Summary: Transport Protocol important advantage: it allows applications to make deci- Functions over IP sion on what data to be packaged into each IP packet, thus Globally uni€e connection ID that bind the two ends of enabling the realization of application data unit (ADU) [1]. the connection; wish to be IP address independent but must Realtime Transport Protocol (RTP) is the €rst widely used map to IP addresses reliably. transport protocol that runs over UDP, resulting in RTP Uni€e data identifier: must be reliably exchanged with implementation being outside kernel, allowing RTP to be the other end. tightly integrated with apps, and app implementations to window flow control for reliable delivery; wish to utilize ADU. avoid head-of-line blocking Transport protocols have traditionally been put in the Using port numbers for demux inside a host. kernel, one reason is for performance eciency. Every coin Congestion control:5 needs to control the number of has two sides, here the other side of the story is the diculty packets inside the network. in making protocol changes. By its name, QUIC adopted Control info exchange between the two ends; wish to RTP’s way of running over UDP, so that it is outside kernel have ƒexibility in de€ning new control messages. and support ADUs. securing the connection.6 3.3.3 SCTP. SCTP (RFC4960) preceded QUIC by 10+ years. Its design addresses three of the identi€ed TCP issues. 4 CONCLUSION AND FUTURE WORK For issue #1 HLB, SCTP de€nes multiple data substreams It is commonly agreed that QUIC represents the best trans- within a single SCTP connection. Œis removed the head- port protocol design the community has come out with so far. of-line blocking problem between the data of di‚erent sub- Œis is precisely because the basic ideas in the QUIC design streams, con€ning the problem to be with each substream did not simply drop out of sky one day, but rather, QUIC rep- which still needs in-order delivery. As we will see in §2.1.1, resents an accumulation of lessons learned from networking QUIC adopted this multi-substream approach to address experimentation and previous transport protocol designs. head-of-line blocking as well. QUIC adopted SCTP only partially addressed TCP issue #3 on IP ad- • T/TCP: keep state to achieve 0-RTT communication. dress changes: each end of a SCTP connection (called an • RTP: running over UDP to stay outside kernel, inte- association) can have multiple IP addresses, and the set may grate with app, and utilizing ALF/ADU idea docu- change. Nevertheless SCTP connection identi€ers are still mented in [1] bound to IP addresses. • SCTP: the multiple substreams to mitigate head-of- In addressing issue #5, SCTP de€ned multiple typed chunks, line blocking, and typed frames to support variety each chunk with its own header; multiple chunks can be of control exchanges packed into a single SCTP packet within the MTU limit. Each Adopting these ideas and synthesizing them into a single connection command is de€ned as a separate control chunk; protocol allows the QUIC protocol to minimize latency (o‰en application data are put into data chunks as ADUs, each touted as QUICs chief virtue) and minimize other problems 4 identi€ed by [stream ID, stream seq#]. Œis design gives (such as head-of-line blocking). SCTP ƒexibility of de€ning new connection management op- tions simply by adding a new chunk type; and SACK chunk REFERENCES is no longer limited by space. QUIC adopted this approach [1] David Clark and David Tennenhouse. Architectural considerations for of typed chunks to carry control and data, but changed the a new generation of protocols. In Proc. of SIGCOMM, 1990. terminology from chunk to frame. [2] Adam Langley et. al. Œe quic transport protocol: Design and internet- scale deployment. In Proc. of SIGCOMM, 2017.

5Ideally CC is network layer function, it landed on TCP because IP is 4Note that stream seq# identi€es a data chunk given by application, there- open-loop and thus has no control. fore SCTP has to handle data chunk fragmentation and reassembly, as in 6To be more speci€c, people currently view encrypted connections as contrast to TCP’s byte stream data model, thus TCP can chop o‚ a segment network security, although encryption provides only con€dentiality but no at any byte boundary. authenticity nor trust. 6 [3] Tommy Pault et. al. An unreliable datagram extension to quic. Rfc, August 2020. [4] Bryan Ford. Structured streams: a new transport abstraction. In Proceed- ings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications, pages 361–372, 2007. [5] J. Iyengar and M. Œomson. ‹ic: A udp-based multiplexed and secure transport. Rfc, June 2020. [6] J. Iyengar and S. Turner. Using tls to secure quic. Rfc, June 2020. [7] Jana Iyengar. Œe maturing of quic. hŠps://www.fastly.com/blog/maturing-of-quic, November 2019.

7