QUIC working group A. Joseph Internet-Draft T. Li Intended status: Informational UCLA Expires: September 6, 2018 Z. He Y. Cui Tsinghua University L. Zhang UCLA March 5, 2018 A Comparison between SCTP and QUIC draft-joseph-quic-comparison-quic-sctp-00 Abstract To cumulate design lessons from our protocol development efforts, this document provides a preliminary comparison between two transport protocol designs, Stream Control Transport Protocol (SCTP) and Quick UDP Internet Connections (QUIC). We identify their commonalities and differences, summarize the characteristics of QUIC which we believe represent progresses in transport protocol designs. We hope this draft useful in helping others to gain further understanding of both SCTP and QUIC, and in future protocol design efforts. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Joseph, et al. Expires September 6, 2018 [Page 1] Internet-Draft QUIC and SCTP comparison March 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. A High Level Overview of the Two Protocols . . . . . . . . . 4 3.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. A Comparative Examination of Specific Protocol Mechanisms . . 5 4.1. Packet Structure . . . . . . . . . . . . . . . . . . . . 5 4.1.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Connection Setup . . . . . . . . . . . . . . . . . . . . 8 4.2.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Substreams . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Reliability and Congestion Control . . . . . . . . . . . 14 4.5.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. Flow Control . . . . . . . . . . . . . . . . . . . . . . 17 4.6.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . 18 4.7. Connection Teardown . . . . . . . . . . . . . . . . . . . 19 4.7.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . 19 4.7.2. QUIC . . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. Other Differences between QUIC and SCTP . . . . . . . . . 19 5. Current Situations of SCTP and QUIC . . . . . . . . . . . . . 20 6. Conclusions from the comparison . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Informative References . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Joseph, et al. Expires September 6, 2018 [Page 2] Internet-Draft QUIC and SCTP comparison March 2018 1. Introduction Quick UDP Internet Connections (QUIC) builds upon the design lessons learned from many existing protocols. The purpose of this draft is to draw parallels and display differences between the two transport protocols, Stream Control Transport Protocol (SCTP) and Quick UDP Internet Connections (QUIC), with a hope to gain deeper insight from the comparison, extract general lessons, and trends. As such, this draft is not intended to be a deep dive into the inner working details of the protocols, but rather a high level view of similar core functionality and mechanisms of the protocols. These two protocols were developed years apart and for very different purposes, however as transport protocols they share a number of similarities. However it should be noted that at the time of this writing, the QUIC specification is still under active development. This means that parts of the specifications are still incomplete or missing at this time. This draft focuses on what has been documented so far; the reader should keep in mind that the QUIC protocol might have changed after the time of this draft's publication. 2. Background The SCTP protocol was originally developed in year 2000 to transport Public Switched Telephone Network (PTSN) signaling messages over IP; it was later adapted to be a general purpose transport protocol [RFC4960]. The motivation of developing a new transport protocol came from perceived drawbacks of using TCP for transmitting PTSN messages: HOL-Blocking, lack of host multi-homing support, mismatch between TCP's byte-stream data model and PTSN applications's message- oriented communication, and TCP's vulnerability to SYN attacks. SCTP uses multiple substreams to mitigate HOL blocking, enables each transport connection to utilize multiple interfaces, and reliably delivers application messages instead of byte streams. The development of the QUIC protocol was started by Jim Roskind's team at Google in 2012, aiming to remove identified performance bottlenecks in transport protocols. As Internet bandwidths continue to increase due to technology advances and infrastructure buildout, the Round Trip Time (RTT) became a physical upper bound of the speed of light. The existing transport protocols take multiple RTTs to deliver a web page's contents [QUIC-DESIGN]. Using multiple TCP connections to improve performance has its own limitations: it forces client applications to bind to many different sockets to send out multiple separate requests, resulting in redundant connection setup and bandwidth wastage as well as inefficient allocation of computer resources. QUIC developed an innovative design for connection setup that integrates transport protocol and TLS functions to minimize RTT. Joseph, et al. Expires September 6, 2018 [Page 3] Internet-Draft QUIC and SCTP comparison March 2018 Similar to STCP, QUIC developed support for multiple substreams instead of using multiple transport connections[QUIC-DESIGN]. QUIC's predecessor was another transport protocol from Google called SPDY, which ran over a single TCP connection and routinely with SSL [QUIC-DESIGN]. The lessons learned from SPDY drove many of the design decisions for QUIC, including the decision to run over UDP instead of TCP to avoid TCP's HOL-Blocking, an innovative congestion control scheme, and considerations for mobile devices in connection teardown [QUIC-DESIGN]. 3. A High Level Overview of the Two Protocols 3.1. SCTP A SCTP connection is comprised of an association between two endpoints, each is defined by a set of IP addresses and a port number. A SCTP connection is referred to as an association so the rest of this draft will use this term. While a primary IP address is used for each endpoint, each end may inform the other end a set of addresses it may use to transmit packets. Moving away from TCP's approach of one-header-fitting-all, STCP designed multiple separate data structures called "chunks" to carry association control information and applications data messages. SCTP communicates with an Upper Layer Protocol (ULP) through the use of message primitives ASSOCIATE and SHUTDOWN. These primitives are how applications are able to communicate with SCTP to setup and teardown association. SCTP supports multiple message substreams by letting each of the two endpoints negotiate with the other on the number of substreams they can support at the association setup time, and ensures in-order delivery of messages in substream to the ULP through the use of a substream sequence number. To provide reliable message delivery for all substreams, SCTP assigns each data chunk a unique Transmission Sequence Number (TSN). Note that the TSN is on per association basis, not per substream. It works in an identical way to TCP sequence number in ensuring reliable delivery, except that the former names a data chunk while the latter a data byte. A data may contain either a data message, or a segment of a data message. SCTP uses the same congestion avoidance and control mechanisms as TCP, and similar selectively acknowledgement scheme, except that it designed a dedicated SACK chunk, as opposed to TCP's use of its option field for SACK. 3.2. QUIC A QUIC connection is comprised of an association between two endpoints defined by a pair of IP address and port number (at the time of this writing, QUIC's multihoming/multipath support is still Joseph, et al. Expires September 6, 2018 [Page 4] Internet-Draft QUIC and SCTP comparison March 2018 under development). The IP addresses and ports can change in the middle of a connection. A fundamental difference between QUIC and TCP or SCTP is that QUIC is a user space transport protocol, which allows rapid protocol revision without having to wait for system upgrades. To support rapid protocol revision, QUIC's connection setup goes through a negotiation process that involves determining the lowest common version supported between the two endpoints and a cryptographic handshake which incorporates TLS to provide a secure connection. Within a QUIC connection, substreams can be started at any time, excluding tear down phase. Either endpoint can start a substream, which can be either bidirectional or unidirectional. QUIC inherits TCP's byte stream data model. Dedicated control structures called "frames" are used to communicate with and carry byte data to endpoints. Similar to SCTP, QUIC has a dedicated SACK frame to carry selective acknowledgement, although the semantics of QUIC SACK differs from that of SCTP in important ways. SACK informs which packets are delivered to the other end; un-ACKed packets are considered lost. No QUIC packet is ever retransmitted, packet numbers always increases monotonically. From each received SACK frame, a QUIC endpoint can infer which byte frames have been received by the other end. To ensure reliable in-order data delivery of each byte stream to the application, the sender will retransmit the byte frames that are not acknowledged. The new frames may repackage the missing byte offsets. As another difference from SCTP, QUIC practices flow control both on a connection basis and on per substream basis, by advertising the max amount of data allowed on a connection, as well as per stream. If an endpoint transmits more than advertised, the entire connection is torn down. 4. A Comparative Examination of Specific Protocol Mechanisms 4.1. Packet Structure The packet structures of both SCTP and QUIC break away from TCP's one-header-fits-all design. Instead, they used dedicated control chunks for connections setup, teardown and SACK. 4.1.1. SCTP The SCTP [RFC4960] packet structure contains a common header (Figure 1) with attached DATA chunks (Figure 2) which is analogous to QUIC's Short Header (Figure 3) and STREAM frames (Figure 4). The common header contains fields for the set of source and destination Joseph, et al. Expires September 6, 2018 [Page 5] Internet-Draft QUIC and SCTP comparison March 2018 IP addresses and ports, verification tag, and a checksum of the packet. The DATA chunk has a type and reserved fields of 0. The U bit set to 1 indicates that the data is unordered and the value in the Stream Sequence Number (SSN) can be ignored. The SSN indicates what number message the chunk contains for the related Stream, and also determines the order the messages will be delivered to the ULP (unless it is meant to be unordered). SSN always starts from 0 and increments up to 65535 with wrap around. The Transmission Sequence Number (TSN) enumerates the Chunks attached to the common header and increment sequentially with wrap around over the lifetime of an association. TSNs range from 0 to 4294967295, and can start at a random value in the range. TSNs are repeated during retransmission of packets to ensure reliable delivery. The Length field indicates the length of the DATA Chunk including the 16 bytes of the fields starting from the Type field. The Stream identifier is the number identifying the stream the chunk belongs to. The Payload Protocol Identifier is not relevant for the purposes of this paper and is not used by the SCTP protocol itself, but is intended for use by middleboxes. The User Data field contains user data which is padded at the end to a 4 byte boundary of all-zero bytes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SCTP Packet Structure Joseph, et al. Expires September 6, 2018 [Page 6] Internet-Draft QUIC and SCTP comparison March 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User Data (seq n of Stream S) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SCTP DATA Chunk 4.1.2. QUIC The QUIC packet structure consists of a common header called a short header (Figure 3) and attached Frames in the protected payload (Figure 4). A user data payload bearing packet sent after connection is set up is called a STREAM frames (Figure 4), analogous to SCTP's DATA Chunks (Figure 2), and is the primary frame used for data transfer [QUIC-TRANSPORT]. The Type field indicates the type of Frame it is: the range 0x10-0x17 indicates a STREAM Frame. The lower three bites of the Type field also encode whether certain fields are in the frame. 0x04 is the OFF bit, if set to 1, there is an offset field, if set to 0, the frame starts from byte offset of 0 or there is no data. 0x02 is the Length bit, if set to 1, there is a length field, if set to 0, the length of the data extends to the end of the packet. Finally the 0x01 is the FIN bit, if set to 1, it is the final frame in a stream [QUIC-TRANSPORT]. The Stream ID identifies the stream the frame belongs to, as well as if the stream is bidirectional or unidirectional and if the server or the client created the stream. If the second least significant bit is 1, the stream is unidirectional, if it is 0, the stream is bidirectional. If the least significant bit is 1, the server initiated the stream, if it is 0, the client initiated the stream. The offset field indicates the byte offset that the STREAM Frame is carrying, and the length field indicates the length of the stream data. There can be multiple STREAM Frames per QUIC packet/header. [QUIC-TRANSPORT] Joseph, et al. Expires September 6, 2018 [Page 7] Internet-Draft QUIC and SCTP comparison March 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |0|C|K| Type (5)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + [Connection ID (64)] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (8/16/32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Short Header 0 1 2 3 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Offset (i)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Length (i)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Data (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: STREAM Frame 4.2. Connection Setup For connection setup, SCTP adopts the 4-way handshake with digitally signed state cookie for preventing denial-of-service attacks (SYN- flooding). The state cookie is sent by the server in response to the client's INIT message, and contains all of the state that the server needs to ensure that the association is valid, including Message Authentication Code (MAC) [RF2104], a timestamp, and the cookie lifespan. The cookie contains all the information needed for SCTP association setup, so the server's SCTP stack does not need to keep information about the associating client. For connection setup, QUIC directly incorporates TLS key negotiation process with the transport handshake, establishing secure connection using 1-RTT with successful version negotiation, and 0-RTT for connection resumptions. During initial connection setup, the server Joseph, et al. Expires September 6, 2018 [Page 8] Internet-Draft QUIC and SCTP comparison March 2018 gives the client a cryptographic cookie known as Source Address Token (client IP and timestamp) for source address validation. It also sends the Server Config containing the server's long-term Diffie- Hellman public value and server preference. These information can be used for subsequent connections. This provides a secure and efficient way for establishing connections, yet unlike traditional syn-cookies for preventing syn-flood attack which are designed for single use, QUIC's longterm cookies might bring potentials for new types of attacks (e.g. replay attack). QUIC server also adopts stateless address validation, the cookie stores all state necessary to continue the connection. 4.2.1. SCTP While SCTP is similar to TCP where a connection is defined by a pair IP addresses and port numbers, SCTP is slightly different by defining a set of possible IP addresses and port numbers in its common header. This is to facilitate SCTP's multihoming features, since messages can be sent or received at any of these addresses, even though there is a primary address specified. A normal SCTP association begins when an endpoint "A" sends an INIT chunk to the other endpoint. The INIT chunk (Figure 5) will contain a Verification Tag value which is a random number between the range of 1 and 4294967295. The Verification Tag can be used as the initial TSN as well. The other endpoint "Z" will respond with an INIT ACK chunk containing its own Verification Tag as well as as generating and sending a State Cookie back. Endpoint "A" will then respond with a COOKIE ECHO chunk which might contain DATA chunks as well. Endpoint "Z" will acknowledged the COOKIE ECHO with a COOKIE ACK chunk, which can also be bundled with other DATA chunks. The ULP of each of the endpoints will then be notified that a successful association has been established. Within the INIT and INIT ACK chunks that were sent by each endpoint, the number of outbound and inbound streams accepted by each endpoint were communicated. The endpoints will take the minimum of each of their preferred outbound streams and the minimum inbound stream of the other endpoint, minus 1: min(local outbound stream, remote minimum inbound streamC) - 1. All SCTP substreams are unidirectional. The State Cookie that is sent out during connection setup contains a Message Authentication Code (MAC) [RF2104], a timestamp and the lifespan for the cookie. The entire SCTP association setup results in a 4-way handshake in order to avoid a SYN-flood situation. Once a connection is set up, it is possible that SCTP will fragment its chunks in order to avoid IP fragmentation. Fragmentation is done by a source host only and the peer endpoint will reassemble once it is received. Joseph, et al. Expires September 6, 2018 [Page 9] Internet-Draft QUIC and SCTP comparison March 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ Optional/Variable-Length Parameters / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: SCTP INIT Chunk 4.2.2. QUIC A normal QUIC connection begins with version negotiation between two endpoints. An Initial packet with a long header is sent out by a client to determine if both endpoints support the same version of QUIC. The Version Negotiation packet (Figure 6) is sent by the server if the client that sent out the initial packet is attempting to create a new connection and the client's version is not accepted by the server. If the Initial packet's version is supported by the server or the client responds to the server's Version Negotiation packet with a supported version, the handshake process continues. After a version is settled on by both endpoints, the transport and cryptographic handshake begins. Stream 0, is a reserved substream that is used for the cryptographic handshake process. The current version of QUIC uses TLS 1.3 to encrypt the connection and authenticate the server and optionally authenticate the client. QUIC is able to reduce handshake delay caused by RTT by combining the transport and cryptographic handshake together to provide a secure connection from the start of a connection. QUIC embeds the TLS functionality within the protocol itself, without having to run a separate TLS handshake and session after the transport handshake. During the cryptographic handshake, each endpoint advertises transport parameters that define the initial parameters for the connection. These transport parameters includes values that determine the maximum amount of data that can be transmitted per stream, as well as per connection data maximums. These values are updated during the lifetime of a connection to facilitate flow control. Once a connection is established, substreams can be created during any point of the connection lifetime. QUIC also supports both Joseph, et al. Expires September 6, 2018 [Page 10] Internet-Draft QUIC and SCTP comparison March 2018 unidirectional and bidirectional substreams which is determined during sub stream setup. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |1| Unused (7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported Version 1 (32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Supported Version 2 (32)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Supported Version N (32)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: QUIC Version Negotiation Packet 4.3. Substreams One of the major features of both of these protocols are multiplexed streams. An issue with TCP is that a dropped packet can block message delivery for all application-level streams since TCP uses a single-byte stream abstraction. This blockage is called Head-of-Line Blocking. SCTP and QUIC solve for this by supporting multiplex streams within the protocol itself. If a dropped packet occurs for either protocol, in-order messages/byte streams can still be delivered for other streams if they are available. SCTP intended to get rid of HOL-Blocking by substreams, but its Transmission Sequence Number (TSN) couples together the transmission of all data chunks. For SCTP, each packet contains different data chunks from different streams identified by Stream ID (SID), if the data chunk of one streams is lost, the data of other streams should still be received by the application. However, a TSN is assigned to every data chunk in the association. For SCTP Cumulative ACK, the value of the Cumulative TSN ACK parameter is the last TSN received before a break in the sequence of received TSNs. The next TSN value following this one has not yet been received at the endpoint sending the SACK. This parameter therefore acknowledges receipt of all TSNs less than or equal to its value. As a result, in SCTP if a packet is Joseph, et al. Expires September 6, 2018 [Page 11] Internet-Draft QUIC and SCTP comparison March 2018 lost, all the packets with TSN after this lost packet cannot be received until it is retransmitted. QUIC adopts two levels of numbering. User data is uniquely identified by stream ID and offset, it also has a monotonically increasing packet sequence number.The packet sequence number is used for congestion control and loss detection and it numbers all the packets (SCTP don't number control packets). QUIC selective ack, acknowledges packet sequence number of the last received packet, and QUIC retransmits the lost packet using a new sequence number. As a result, the congestion window could open up for more packets, and the lost packet does not affect the packets following it from being received, thus avoiding the HOL-Blocking problem. However, as QUIC SACK tells which packets get lost but does not retransmit the lost packet, QUIC has to keep internal mapping of which stream frame in which packet, to know which one needs to be retransmitted, which introduces additional processing. 4.3.1. SCTP SCTP substream setup requires the number of substreams as well as their Stream IDs be declared at association setup. SCTP does not have the functionality to start streams during a association since it does not differentiate between client-initiated and server-initiated streams. Additionally, streams persist through the lifetime of an active association. SCTP's INIT Chunk declares two fields, Number of Outbound Streams (OS) and Number of Inbound Streams (NIS), to help negotiate the number of streams to be created during an association. The number of streams is not negotiated in the traditional sense, but instead the minimum of the requested streams and offered streams is taken. For example, if a receiver advertises 6 streams in its MIS field, and a sender advertises 12 streams in its OS field, the number of streams to the receiver will be 6. If either of these fields is set to 0, the association will be aborted. If a sender is limited to less streams than was requested, it can communicate to its application layer it failed to secure the number of streams that was required, and the application can decide to continue the association or abort it. SCTP substreams are only unidirectional and each stream's sequence number must start from 0. Since streams are created during association setup, if the number of streams needs to be changed, the association needs to be torn down and re-setup. 4.3.2. QUIC QUIC has the functionality to start or teardown a substream during any point of the connection (aside from connection teardown). The parity of the Stream ID allows QUIC to spawn new substreams on either the client or server side without the need to undergo negotiations Joseph, et al. Expires September 6, 2018 [Page 12] Internet-Draft QUIC and SCTP comparison March 2018 between each side to decide on an ID. Since parity is decided by the least significant bit, a client only picks even Stream IDs, and the server only picks odd Stream IDs. QUIC substreams support unidirectional and bidirectional streams which is determined by setting the second to least significant bit in the Stream ID. The bit reservations allow for streams to be started at anytime during the lifetime of a connection without the need for negotiation. Each endpoint is restricted to their own non-overlapping range of IDs, thus canceling out the need to negotiate for an ID in order to avoid conflicts.The protocol defines several transport parameters and frames to define and control the behavior of the streams. The MAX_STREAM_DATA frame is advertised by the receiver to flow control individual streams. If a peer attempts to send more data than is advertised, the connection is terminated. MAX_STREAM_ID is a similar frame advertised by the receiver to indicate the maximum number of streams allowed on the connection. If a peer attempts to start a stream with a Stream ID higher than the advertised maximum, the connection is terminated. The sender can communicate with the receiver that it is unable to send more data, or start a new stream through STREAM_BLOCKED and STREAM_ID_BLOCKED frames respectively. The receiver can advertise new data and stream limits any time during a connection and is bound to honor these limits, e.g. a receiver cannot advertise a higher limit and refuse it once a sender starts sending. An important implementation note is that if a QUIC packet is dropped, every stream that was in that packet is blocked. It is up to the QUIC implementation to determine the number of streams to be sent per packet to limit the occurrences of HOL-Blocking. QUIC needs to balance sending data for all its dream with the chance of stream blockage when a dropped packet occurs. Once an endpoint of a stream has finished transmitting its data, it will set the FIN bit on its last STREAM frame or the frame after the last STREAM frame to indicate the stream is closed in the direction of the endpoint, resulting in a half closed stream. Once both endpoints have sent STREAM frames with the FIN bit set, the stream is fully closed. 4.4. Fragmentation For data model, SCTP uses application-defined messages. However, QUIC adopts the bidirectional byte stream model of TCP, the reasoning of which is probably the desire of close coupling with HTTP/2 that was originally designed to run over TCP. Consequently, not only does it facilitate the movement of applications from TCP to QUIC, but also liberates QUIC from message fragmentation that SCTP has to take care of. Joseph, et al. Expires September 6, 2018 [Page 13] Internet-Draft QUIC and SCTP comparison March 2018 4.4.1. SCTP In order to avoid IP fragmentation, SCTP fragments its own chunks, so that its packets can fit under the Path MTU [QUIC]. Since SCTP relies on messages as its unit of data, it needs to determine how to fragment and reassemble its payload to keep the rest of the protocol functioning, meaning it needs to keep its headers unfragmented and handle reassembly of the data once it is received. SCTP achieves this by utilizing bit flags in the DATA Chunk header and numeric values in its TSN and SSN fields. The B bit set to 1 indicates that the chunk is the first fragment of a user message. The E bit set to 1 indicates that the chunk is the last fragment of a user message. If both B and E are set to 1, then the message is not fragmented. If both B and E are set to 0, then the chunk is a middle fragment of the user message. The TSN field indicates the Transmission Sequence Number of the DATA Chunk which is used to identify and acknowledge successfully received Chunks. Each DATA Chunk in a packet shares a different sequential TSN and SSN, whereas each fragmented DATA Chunk must also shares a different sequential TSN, but the same SSN among the fragmented DATA Chunks containing the same message. A receiver will then be able to acknowledge all the Chunks it received with its corresponding TSN, and rebuild the underlying messages by matching DATA Chunks with payloads sharing the same SSN. 4.4.2. QUIC A QUIC packet must contain whole frames, and not have frames split up between packets. A QUIC packet must fit under the Path MTU [QUIC-TRANSPORT]. QUIC can resize packets without the need of complex mechanisms to track fragments of messages like in SCTP since every QUIC data payload is just a byte stream and is easily adjustable through changing byte offset field in the STREAM Frame. There is no message to fragment since the data is already at its most granular form. The actual size of a QUIC packet is determined by implementation of the protocol and how the application using it behaves. The current draft does not go into much detail on how to pack QUIC packets with frames aside from recommending to pack as many frames as possible to minimize per-packet bandwidth and computational cost [QUIC-TRANSPORT]. However a balance needs to occur. If there are too many frames in a packet, and the packet is lost, all those streams are blocked, if there are too little frames, there is increased per-packet bandwidth and computational cost. 4.5. Reliability and Congestion Control Reliable delivery in transport protocols is defined as providing the abstraction of guaranteeing delivery of every message on an active connection . Congestion control is defined to be how an endpoint Joseph, et al. Expires September 6, 2018 [Page 14] Internet-Draft QUIC and SCTP comparison March 2018 limits the number of messages it sends out on a network in order to prevent the network from becoming clogged and dropping packets. QUIC and SCTP both provide reliable delivery as well as forms of congestion control. SCTP borrows most of its congestion control concepts from TCP and QUIC utilizes TCP's and its own mechanisms. The ACK blocks indicate ranges of packet numbers that were received below the Largest Acknowledged, with GAP blocks indicating gaps in the packet number series. This is unlike SCTP's Cumulative TSN ACK which tracks the lowest contiguous acknowledged TSN. 4.5.1. SCTP SCTP ensures reliable in-order delivery of data through the use of the TSN. Unlike QUIC's Packet Number, TSN is not a monotonically increasing value. TSNs are used to identify and acknowledge chunks by a receiver, and if a sender does not receive an acknowledgement in a certain amount of time, it knows what chunks to retransmit because of their associated TSN. TSNs are used to track missing chunks, and chunks are retransmitted with the same TSN that they had when they were originally dropped so the receiver knows it is no longer missing a chunk. This allows SCTP to guarantee reliable delivery of DATA Chunks. Since TSN is separate from SSN, the in-order delivery mechanism for streams is kept separate from the reliable delivery mechanism. SSN controls in-order delivery to the ULP, while TSN controls reliable delivery between endpoints. TSN is also agnostic to what stream it belongs to. SCTP keeps track of the Cumulative TSN ACK, the last TSN an endpoint has received before a break in the series of TSN values. Every TSN below the Cumulative TSN ACK value is contiguously acknowledged by the receiver. If a receiver has gaps in TSNs that were not received, it will communicate only what it has received, leaving the sender to determine what is missing. A receiver sends out a SACK Chunk (Figure 7) to acknowledge the receipt of TSNs. GAP blocks are attached to the SACK Chunk to acknowledge sequences of TSN values above the Cumulative TSN ACK. A GAP block indicates ranges of TSNs that are acknowledged by the receiver. Gap Ack Block Start indicates the inclusive start offset of TSNs from the Cumulative TSN ACK. Gap Ack Block End indicates the inclusive end offset of TSNs from the Cumulative TSN ACK. A sender determines what TSNs are missing through repeated GAP blocks containing the same gaps in TSN ranges, which indicate the same chunks are missing repeatedly. The sender will then retransmit the missing chunks. Congestion control in SCTP is governed by the same mechanisms that TCP utilizes such as slow start, fast retransmit and retransmission timer. Joseph, et al. Expires September 6, 2018 [Page 15] Internet-Draft QUIC and SCTP comparison March 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: SCTP SACK Chunk 4.5.2. QUIC QUIC ensures reliable in-order delivery of data through the use of the byte offset field in STREAM frames. If a packet is dropped, the individual frames within the packet will be retransmitted, not the packet itself. This means that a new packet with a new packet number will be constructed, and the dropped frames will be attached and sent with it. The packet number in a QUIC packet is always monotonically increasing, or in other words, a duplicate packet number will never be sent making it easy to distinguish acknowledgements of retransmission from the original packets [QUIC-RECOVERY]. This plays into the stream abstraction concept that is present within QUIC: there is always a constant stream of data being sent on a connection. It is up to the implementation to decide how many packets to use to resend dropped frames. Additionally, since endpoints know which sent packets of theirs is missing, they know what byte offsets are missing, allowing them the ability to resize frames for transmission as they see fit. At time of writing, the QUIC draft does not specify how the frames are resized [QUIC-TRANSPORT]. The ACK Delay field indicates the time in microseconds that the largest acknowledged packet was received by which facilitates creating an accurate RTT timer [QUIC-RECOVERY]. The Largest Acknowledged field in the ACK Joseph, et al. Expires September 6, 2018 [Page 16] Internet-Draft QUIC and SCTP comparison March 2018 Frame (Figure 8) indicates the largest packet number that was received. The reason QUIC tracks the latest packet number is due to the packet number always being monotonically increasing allowing transmission order to be easily tracked. SCTP tracks the lowest contiguous TSN in its Cumulative TSN ACK field since SCTP might retransmit TSNs which is not an issue with QUIC. Just as SCTP utilizes the same mechanisms as TCP for congestion control, so does QUIC, however with some important modifications. QUIC simplifies its congestion control and loss detection by splitting out its source of information for reliable delivery: stream id and byte offsets, from its source of information for transmission order: monotonically increasing packet numbers. SCTP and TCP both conflate reliable delivery and transmission order into one source of information, the TSNs. Another simplification that QUIC brings is that QUIC ACK's are always honored, and never reneged upon, unlike SCTP which uses a SACK similar to TCP and can be reneged [QUIC-RECOVERY]. TCP's congestion control algorithms such as slow start, fast retransmit, and RTT timers are still used in QUIC, just adapted to use its packet number as well as some other minute differences [QUIC-RECOVERY]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Largest Acknowledged (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Delay (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Block Count (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Blocks (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: QUIC ACK Frame 4.6. Flow Control Flow control is defined as the pressure or limit a receiving endpoint advertises to a sender in order to prevent the receiver from being overwhelmed and drop packets. Flow control is similar to congestion control, but whereas congestion control focuses on preventing congestion on the network or system, flow control focuses on preventing an endpoint from being overwhelmed. A common flow control concept is a sliding window, in which an endpoint advertises an amount of bytes its sending counterpart can transmit. Both of these protocols practice a form of sliding window. Unlike UIC, there is no flow control data that is sent between sender and receiver on a per stream basis, but rather flow control is done on a per association basis. Joseph, et al. Expires September 6, 2018 [Page 17] Internet-Draft QUIC and SCTP comparison March 2018 4.6.1. SCTP Flow Control in SCTP is done only on a per association basis using mechanisms similar to TCP as defined in TCP Congestion Control [RFC2581]. When a receiver sends out a SACK Chunk (Figure 7), it includes a field called Advertiser Receiver Window Credit (a_rwnd). This value represents the remaining available buffer space at the receiver. Since SACKs can be received out of order, a sender will not necessarily assume they have a_rwnd amount of buffer space to send. At the start of a SCTP association, each endpoint will receive the a_rwnd of its peer in the INIT (Figure 5) or INIT ACK Chunk, and will take that to be the actual receiving window (rwnd) of the corresponding endpoint. As the association lifetime continues, each endpoint will subtract the size of DATA chunks that are sent or retransmitted to a peer from the peer's rwnd. This is because the sender assumes the peer's buffer space will be taken up by the transmitted chunk. Each endpoint will also add the size of DATA chunks that are marked for retransmission. With each SACK an endpoint receives, it will update its rwnd according to a_rwnd in the SACK, minus any outstanding bytes from missing chunks that have not be acknowledged yet. 4.6.2. QUIC Flow Control in QUIC is done on both a connection and substream basis. The most important parameters for flow control in QUIC are the transport parameters MAX_DATA and MAX_STREAM_DATA parameters. These two parameters are communicated during connection setup, and also have corresponding Frames which can be communicated during a connection. Once a value is advertised for these parameters by an endpoint, the endpoint must honor it. MAX_DATA indicates the maximum amount of data that can be communicated on a connection. MAX_STREAM_DATA indicates the maximum amount of data that can be communicated on a stream basis. It is up to each endpoint to divide up the data between all of its streams. As the connection and stream lifetime continues, endpoints will advertise higher MAX_DATA and MAX_STREAM_DATA to flow control its sending peer. If either of these variables are disobeyed by a sender on any of the streams, the entire connection is torn down. An exception is made for Stream 0, which is reserved for the cryptographic handshake on setup. None of the byte usage of Stream 0 is counted towards the limits of the transport parameters [QUIC-TLS]. Since QUIC utilizes a byte stream paradigm and byte offsets are communicated in STREAM frames, data usage is easily calculated on both endpoints by recording largest received byte offsets. This leads to virtually no chance of an endpoint breaking this agreement unless there is a bug in its implementation or it is a malicious actor. Joseph, et al. Expires September 6, 2018 [Page 18] Internet-Draft QUIC and SCTP comparison March 2018 4.7. Connection Teardown 4.7.1. SCTP Once it is time for a SCTP association to end, the endpoints engage in a 3-way handshake to shutdown the association. The ULP will send out a SHUTDOWN primitive to the lower layer where it will wait for all its sent chunks to be acknowledged or retransmit missing ones. The endpoint will then send out a SHUTDOWN chunk to initiate a clean close of the association after it has confirmed its peer has received all sent data. On receipt of the SHUTDOWN chunk, the peer endpoint will stop accepting data from its ULP and confirm it has received all data and then respond with a SHUTDOWN-ACK. Finally, the initiating endpoint will send out a SHUTDOWN-Complete chunk to close the association. 4.7.2. QUIC Once it is time for a QUIC connection to shut down, an endpoint sends out a closing frame, CONNECTION_CLOSE or APPLICATION_CLOSE to its peer and enters a closing state in which it discards all internal state except what is required to build closing frames. If there are open substreams when the frame is received, the streams are implicitly closed. If the initiator of the shutdown receives packets while it is in a closing state, it replies to each of them with either a closing frame. The receiver of the closing frame enters a draining state in which it does not send anymore packets and discards internal state. Before the receiver enters the draining state, it can also send a closing frame. At most, a QUIC connection teardown is a two-way handshake unless there are dropped packets from the initiator. Another way the connection might close down is implicitly through no network activity, resulting in the endpoints timing out. 4.8. Other Differences between QUIC and SCTP SCTP supports multi-homing. Specifically, an endpoint can include multiple IP addresses in the INIT or INIT ACK chunk, so the other endpoint can establish a multi-path connection with the endpoint. When one of the connections times out, a chunk can be retransmitted through another active connection, increasing the resilience of SCTP connection. Nonetheless, QUIC itself does not support multi-homing. Instead, there exists an Multipath Extension for QUIC Draft working in progress to add multipath capability into QUIC protocol [MULTIPATH-QUIC] . QUIC greatly resembles the combination of TCP, TLS and HTTP/2. QUIC packets are always encrypted (except for the public header) and authenticated (including the public header). The encryption prevents Joseph, et al. Expires September 6, 2018 [Page 19] Internet-Draft QUIC and SCTP comparison March 2018 middle box parsing the congestion information and breaking with any forward changes, which is currently a problem for TCP. The public header is required either for routing or for decrypting the packet so it is unencrypted. However, this packet is also fully authenticated, preventing in-network tampering. Any modification of the QUIC packet will cause the teardown of the connection. Nevertheless, SCTP protocol itself does not include encryption or authentication, just like TCP. 5. Current Situations of SCTP and QUIC Temporarily, SCTP is used mostly in the telecom industry. However, as for the IP network, the deployment of SCTP is not much widespread. In-network devices, for example, NAT gateways, does not support SCTP well. NAT gateways need to be upgraded to be SCTP-aware. Nevertheless, the cruel truth is that modification of middle boxes is very expensive, and internet service providers are supposed to seek their own interests to update the devices. As a matter of fact, some firewalls only allow TCP or UDP packets to pass through, which constrains SCTP to very small living space. Considering that MPTCP can meet such needs, there is less motivation to deploy SCTP. The worse thing is that, unlike MPTCP, the SCTP socket APIs differ greatly from TCP, and developers need to update their source code to deploy SCTP, thus significantly impeding the wide deployment of SCTP. Designed by Google, QUIC is now widely used in Chrome clients accessing Google services. QUIC is deployed as a substitution of SPDY, representing about 7% of the Internet traffic. QUIC works atop of UDP, so mostly in-network devices that support UDP will support QUIC. At least, it is more friendly to middleboxes than SCTP. Since QUIC works in the application layer, it is supposed to be upgraded much more frequently than TCP stack in kernel. Fortunately, QUIC provides a new set of APIs, which are not transparent to the upper applications. Similar to SCTP, developers also need to rewrite the source code to allow the former applications to use QUIC. Tech giants, like Tencent, are trying to deploy QUIC to provide better service for users. With the support of giants and communities, the deployment of QUIC is promising in the future. 6. Conclusions from the comparison QUIC has adopted a number of features from long years of protocol design efforts. QUIC and SCTP share some commonalities and differences. We conclude some design considerations of QUIC as following. Joseph, et al. Expires September 6, 2018 [Page 20] Internet-Draft QUIC and SCTP comparison March 2018 o Latency: QUIC combines transport and crypto handshakes, utilizing cryptographic cookie for connection resumption, minimizing connection latency. o Security: QUIC packets are always encrypted (except for the public header) and authenticated (including the public header). QUIC also address the security issues inherent in allowing data exchange during the 0-rtt handshake, through the use of a security token for address validation. However, QUIC's use longterm cryptographic cookie and connection ID brings window for new types of attacks. Balancing tradeoff of gains and losses is always a part of protocol design. o Compatibility: QUIC runs in userspace, allowing fast deployment and experimentation. As it runs over UDP, it is compatible with most middlebox implementations. QUIC also adopts a fall back mechanism for normal TCP handshake incase one of the parties do not support the protocol. QUIC also adopts congestion control protocol to achieve fairness with existing TCP connections. The compatibility issue is one of the reasons why SCTP was not widely deployed. o Parallelism: Through stream multiplexing, the missing frames of one stream will not block the delivery of other streams payload data, avoiding HOL-Blocking problem, but also introduces additional processing, as QUIC has to keep internal mapping of which stream frame in which packet, to know which one needs to be retransmitted. o Flexibility: QUIC has a pluggable congestion control mechanism and has more signaling than TCP, which makes QUIC more informative for congestion control algorithms. It also provides opportunities for further experimentation of congestion control features. o Fine granularity: QUIC supports the traffic control both in stream and connection level, following HTTP/2. o Adjustability: The QUIC connection can survive IP address changes and NAT rebinding due to the stable connection ID during connection migration. o Lightness: QUIC adopts the bidirectional byte stream model of TCP, which facilitates the movement of applications from TCP to QUIC and liberates QUIC from message fragmentation that SCTP has to take care of. Joseph, et al. Expires September 6, 2018 [Page 21] Internet-Draft QUIC and SCTP comparison March 2018 Hopefully these advantages of QUIC can serve as the general principles for future development of QUIC and the design of other incipient protocols. 7. Contributors Hang Shi Tsinghua University P.R. China Email: shihang7422166@gmail.com Yuming Hu Tsinghua University P.R. China Email: Kumius@foxmail.com 8. Informative References [MULTIPATH-QUIC] Coninck, Q. and O. Bonaventure, "Multipath Extension for QUIC, https://tools.ietf.org/html/ draft-deconinck-multipath-quic-00", draft-tsvwg-quic- protocol-00 (work in progress), October 2017. [QUIC] Iyengar, J. and I. Swett, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2, https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00", draft-tsvwg-quic-protocol-00 (work in progress), June 2015. [QUIC-DESIGN] "QUIC: Design Document and Specification Rationale, Jim Roskind, Chromium Contributor", 2012. [QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", draft-ietf-quic-recovery-09 (work in progress), January 2018. [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport Layer Security (TLS) to Secure QUIC", draft-ietf-quic- tls-09 (work in progress), January 2018. Joseph, et al. Expires September 6, 2018 [Page 22] Internet-Draft QUIC and SCTP comparison March 2018 [QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic- transport-09 (work in progress), January 2018. [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, DOI 10.17487/RFC2581, April 1999, . [RFC4896] Surtees, A., West, M., and A. Roach, "Signaling Compression (SigComp) Corrections and Clarifications", RFC 4896, DOI 10.17487/RFC4896, June 2007, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . Authors' Addresses Arun Joseph UCLA Los Angeles USA Email: ajoseps@ucla.edu Tianxiang Li UCLA Los Angeles USA Email: tianxiang@cs.ucla.edu Zihao He Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: hezihao9512@gmail.com Joseph, et al. Expires September 6, 2018 [Page 23] Internet-Draft QUIC and SCTP comparison March 2018 Yong Cui Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: cuiyong@tsinghua.edu.cn Lixia Zhang UCLA Los Angeles USA Email: lixia@cs.ucla.edu Joseph, et al. Expires September 6, 2018 [Page 24]