[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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
                                                           March 5, 2018

                   A Comparison between SCTP and QUIC


   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

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

   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

   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

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

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

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

   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

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

   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

   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

              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,
              draft-tsvwg-quic-protocol-00 (work in progress), June

              "QUIC: Design Document and Specification Rationale, Jim
              Roskind, Chromium Contributor", 2012.

              Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
              and Congestion Control", draft-ietf-quic-recovery-09 (work
              in progress), January 2018.

              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

              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
   Los Angeles

   Email: ajoseps@ucla.edu

   Tianxiang Li
   Los Angeles

   Email: tianxiang@cs.ucla.edu

   Zihao He
   Tsinghua University
   Beijing  100084

   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

   Phone: +86-10-6260-3059
   Email: cuiyong@tsinghua.edu.cn

   Lixia Zhang
   Los Angeles

   Email: lixia@cs.ucla.edu

Joseph, et al.          Expires September 6, 2018              [Page 24]