[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 draft-hamilton-early-deployment-quic

Network Working Group                                        R. Hamilton
Internet-Draft                                                J. Iyengar
Intended status: Informational                                  I. Swett
Expires: July 16, 2016                                           A. Wilk
                                                                  Google
                                                        January 13, 2016


       QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2
                      draft-tsvwg-quic-protocol-02

Abstract

   QUIC (Quick UDP Internet Connection) is a new multiplexed and secure
   transport atop UDP, designed from the ground up and optimized for
   HTTP/2 semantics.  While built with HTTP/2 as the primary application
   protocol, QUIC builds on decades of transport and security
   experience, and implements mechanisms that make it attractive as a
   modern general-purpose transport.  QUIC provides multiplexing and
   flow control equivalent to HTTP/2, security equivalent to TLS, and
   connection semantics, reliability, and congestion control equivalent
   to TCP.

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 http://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 July 16, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Hamilton, et al.          Expires July 16, 2016                 [Page 1]


Internet-Draft                    QUIC                      January 2016


   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.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   5.  A QUIC Overview . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Connection Establishment Latency  . . . . . . . . . . . .   5
     5.2.  Flexible Congestion Control . . . . . . . . . . . . . . .   6
     5.3.  Stream and Connection Flow Control  . . . . . . . . . . .   6
     5.4.  Multiplexing  . . . . . . . . . . . . . . . . . . . . . .   7
     5.5.  Authenticated and Encrypted Header and Payload  . . . . .   7
     5.6.  Forward Error Correction  . . . . . . . . . . . . . . . .   7
     5.7.  Connection Migration  . . . . . . . . . . . . . . . . . .   8
   6.  Packet Types and Formats  . . . . . . . . . . . . . . . . . .   8
     6.1.  QUIC Public Packet Header . . . . . . . . . . . . . . . .   8
     6.2.  Special Packets . . . . . . . . . . . . . . . . . . . . .  12
       6.2.1.  Version Negotiation Packet  . . . . . . . . . . . . .  12
       6.2.2.  Public Reset Packet . . . . . . . . . . . . . . . . .  13
     6.3.  Regular Packets . . . . . . . . . . . . . . . . . . . . .  13
       6.3.1.  Frame Packet  . . . . . . . . . . . . . . . . . . . .  14
       6.3.2.  FEC Packet  . . . . . . . . . . . . . . . . . . . . .  15
   7.  Life of a QUIC Connection . . . . . . . . . . . . . . . . . .  15
     7.1.  Connection Establishment  . . . . . . . . . . . . . . . .  15
     7.2.  Data Transfer . . . . . . . . . . . . . . . . . . . . . .  16
       7.2.1.  Life of a QUIC Stream . . . . . . . . . . . . . . . .  16
     7.3.  Connection Termination  . . . . . . . . . . . . . . . . .  18
   8.  Frame Types and Formats . . . . . . . . . . . . . . . . . . .  19
     8.1.  Frame Types . . . . . . . . . . . . . . . . . . . . . . .  19
     8.2.  STREAM Frame  . . . . . . . . . . . . . . . . . . . . . .  19
     8.3.  ACK Frame . . . . . . . . . . . . . . . . . . . . . . . .  21
       8.3.1.  Entropy Accumulation  . . . . . . . . . . . . . . . .  25
     8.4.  STOP_WAITING Frame  . . . . . . . . . . . . . . . . . . .  25
     8.5.  WINDOW_UPDATE Frame . . . . . . . . . . . . . . . . . . .  26
     8.6.  BLOCKED Frame . . . . . . . . . . . . . . . . . . . . . .  27
     8.7.  CONGESTION_FEEDBACK Frame . . . . . . . . . . . . . . . .  27
     8.8.  PADDING Frame . . . . . . . . . . . . . . . . . . . . . .  27
     8.9.  RST_STREAM Frame  . . . . . . . . . . . . . . . . . . . .  27
     8.10. PING frame  . . . . . . . . . . . . . . . . . . . . . . .  28
     8.11. CONNECTION_CLOSE frame  . . . . . . . . . . . . . . . . .  28
     8.12. GOAWAY Frame  . . . . . . . . . . . . . . . . . . . . . .  29



Hamilton, et al.          Expires July 16, 2016                 [Page 2]


Internet-Draft                    QUIC                      January 2016


   9.  QUIC Transport Parameters . . . . . . . . . . . . . . . . . .  30
     9.1.  Required Parameters . . . . . . . . . . . . . . . . . . .  30
     9.2.  Optional Parameters . . . . . . . . . . . . . . . . . . .  30
   10. QuicErrorCodes  . . . . . . . . . . . . . . . . . . . . . . .  30
   11. Priority  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
   12. HTTP/2 Layering over QUIC . . . . . . . . . . . . . . . . . .  32
     12.1.  Stream Management  . . . . . . . . . . . . . . . . . . .  32
     12.2.  HTTP/2 Header Compression  . . . . . . . . . . . . . . .  33
     12.3.  Parsing HTTP/2 Headers . . . . . . . . . . . . . . . . .  33
     12.4.  Persistent Connections . . . . . . . . . . . . . . . . .  33
     12.5.  QUIC Negotiation in HTTP . . . . . . . . . . . . . . . .  33
   13. Handshake Protocol Requirements . . . . . . . . . . . . . . .  34
     13.1.  Connection Establishment in 0-RTT  . . . . . . . . . . .  34
     13.2.  Source Address Spoofing Defense  . . . . . . . . . . . .  34
     13.3.  Opaque Source Address Tokens . . . . . . . . . . . . . .  34
     13.4.  Transport Parameter Negotiation  . . . . . . . . . . . .  35
     13.5.  Certificate Compression  . . . . . . . . . . . . . . . .  35
     13.6.  Server Config Update . . . . . . . . . . . . . . . . . .  35
   14. Recent Changes By Version . . . . . . . . . . . . . . . . . .  35
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  36
     15.2.  Informative References . . . . . . . . . . . . . . . . .  36
     15.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Contributors

   This protocol is the outcome of work by many engineers, not just the
   authors of this document.  The design and rationale behind QUIC draw
   significantly from work by Jim Roskind [1].  In alphabetical order,
   the contributors to the project are: Britt Cyr, Ryan Hamilton, Jana
   Iyengar, Fedor Kouranov, Charles Krasic, Jo Kulik, Adam Langley, Jim
   Roskind, Robbie Shade, Satyam Shekhar, Cherie Shi, Ian Swett, Raman
   Tenneti, Antonio Vicente, Patrik Westin, Alyssa Wilk, Dale Worley,
   Dan Zhang, Daniel Ziegler.

2.  Acknowledgments

   Special thanks are due to the following for helping shape QUIC and
   its deployment: Chris Bentzel, Misha Efimov, Roberto Peon, Alistair
   Riddoch, Siddharth Vijayakrishnan, and Assar Westerlund.  QUIC has
   also benefited immensely from discussions with folks in private
   conversations and public ones on the proto-quic@chromium.org mailing
   list.







Hamilton, et al.          Expires July 16, 2016                 [Page 3]


Internet-Draft                    QUIC                      January 2016


3.  Introduction

   QUIC (Quick UDP Internet Connection) is a new multiplexed and secure
   transport atop UDP, designed from the ground up and optimized for
   HTTP/2 semantics.  While built with HTTP/2 as the primary application
   protocol, QUIC builds on decades of transport and security
   experience, and implements mechanisms that make it attractive as a
   modern general-purpose transport.  QUIC provides multiplexing and
   flow control equivalent to HTTP/2, security equivalent to TLS, and
   connection semantics, reliability, and congestion control equivalent
   to TCP.

   QUIC operates entirely in userspace, and is currently shipped to
   users as a part of the Chromium browser, enabling rapid deployment
   and experimentation.  As a userspace transport atop UDP, QUIC allows
   innovations which have proven difficult to deploy with existing
   protocols as they are hampered by legacy clients and middleboxes, or
   by prolonged Operating System development and deployment cycles.

   An important goal for QUIC is to inform better transport design
   through rapid experimentation.  As a result, we hope to inform and
   where possible migrate distilled changes into TCP and TLS, which tend
   to have much longer iteration cycles.

   This document describes the conceptual design and the wire
   specification of the QUIC protocol.  Accompanying documents describe
   the combined crypto and transport handshake [QUIC-CRYPTO], and loss
   recovery and congestion control [draft-quic-loss-recovery].
   Additional resources, including a more detailed rationale document,
   are available on the Chromium QUIC webpage [2].

4.  Conventions and Definitions

   All integer values used in QUIC, including length, version, and type,
   are in little-endian byte order, and not in network byte order.  QUIC
   does not enforce alignment of types in dynamically sized frames.

   A few terms that are used throughout this document are defined below.

   o  "Client": The endpoint initiating a QUIC connection.

   o  "Server": The endpoint accepting incoming QUIC connections.

   o  "Endpoint": The client or server end of a connection.

   o  "Stream": A bi-directional flow of bytes across a logical channel
      within a QUIC connection.




Hamilton, et al.          Expires July 16, 2016                 [Page 4]


Internet-Draft                    QUIC                      January 2016


   o  "Connection": A conversation between two QUIC endpoints with a
      single encryption context that multiplexes streams within it.

   o  "Connection ID": The identifier for a QUIC connection.

   o  "QUIC Packet": A well-formed UDP payload that can be parsed by a
      QUIC receiver.  QUIC packet size in this document refers to the
      UDP payload size.

5.  A QUIC Overview

   We now briefly describe QUIC's key mechanisms and benefits.  QUIC is
   functionally equivalent to TCP+TLS+HTTP/2, but implemented on top of
   UDP.  Key advantages of QUIC over TCP+TLS+HTTP/2 include:

   o  Connection establishment latency

   o  Flexible congestion control

   o  Multiplexing without head-of-line blocking

   o  Authenticated and encrypted header and payload

   o  Stream and connection flow control

   o  Forward error correction

   o  Connection migration

5.1.  Connection Establishment Latency

   QUIC combines the crypto and transport handshakes, reducing the
   number of roundtrips required for setting up a secure connection.
   QUIC connections are commonly 0-RTT, meaning that on most QUIC
   connections, data can be sent immediately without waiting for a reply
   from the server, as compared to the 1-3 roundtrips required for
   TCP+TLS before application data can be sent.

   QUIC provides a dedicated stream (Stream ID 1) to be used for
   performing the handshake, but the details of this handshake protocol
   are out of this document's scope.  For a complete description of the
   current handshake protocol, please see the QUIC Crypto Handshake
   [3]document.  QUIC current handshake will be replaced by TLS 1.3 in
   the future.







Hamilton, et al.          Expires July 16, 2016                 [Page 5]


Internet-Draft                    QUIC                      January 2016


5.2.  Flexible Congestion Control

   QUIC has pluggable congestion control and richer signaling than TCP,
   which enables QUIC to provide richer information to congestion
   control algorithms than TCP.  Currently, the default congestion
   control is a reimplementation of TCP Cubic; we are currently
   experimenting with alternative approaches.

   One example of richer information is that each packet, both original
   and retransmitted, carries a new packet sequence number.  This allows
   a QUIC sender to distinguish ACKs for retransmissions from ACKs for
   original transmissions, thus avoiding TCP's retransmission ambiguity
   problem.  QUIC ACKs also explicitly carry the delay between the
   receipt of a packet and its acknowledgment being sent, and together
   with the monotonically-increasing packet numbers, this allows for
   precise roundtrip-time (RTT) calculation.

   Finally, QUIC's ACK frames support up to 256 NACK ranges, so QUIC is
   more resilient to reordering than TCP (with SACK), as well as able to
   keep more bytes on the wire when there is reordering or loss.  Both
   client and server have a more accurate picture of which packets the
   peer has received.

5.3.  Stream and Connection Flow Control

   QUIC implements stream- and connection-level flow control, closely
   following HTTP/2's flow control.  QUIC's stream-level flow control
   works as follows.  A QUIC receiver advertises the absolute byte
   offset within each stream upto which the receiver is willing to
   receive data.  As data is sent, received, and delivered on a
   particular stream, the receiver sends WINDOW_UPDATE frames that
   increase the advertised offset limit for that stream, allowing the
   peer to send more data on that stream.

   In addition to per-stream flow control, QUIC implements connection-
   level flow control to limit the aggregate buffer that a QUIC receiver
   is willing to allocate to a connection.  Connection flow control
   works in the same way as stream flow control, but the bytes delivered
   and highest received offset are all aggregates across all streams.

   Similar to TCP's receive-window autotuning, QUIC implements
   autotuning of flow control credits for both stream and connection
   flow controllers.  QUIC's autotuning increases the size of the
   credits sent per WINDOW_UPDATE frame if it appears to be limiting the
   sender's rate, and throttles the sender when the receiving
   application is slow.





Hamilton, et al.          Expires July 16, 2016                 [Page 6]


Internet-Draft                    QUIC                      January 2016


5.4.  Multiplexing

   HTTP/2 on TCP suffers from head-of-line blocking in TCP.  Since
   HTTP/2 multiplexes many streams atop TCP's single-bytestream
   abstraction, a loss of a TCP segment results in blocking of all
   subsequent segments until a retransmission arrives, irrespective of
   the HTTP/2 stream that is encapsulated in subsequent segments.

   Because QUIC is designed from the ground up for multiplexed
   operation, lost packets carrying data for an individual stream
   generally only impact that specific stream.  Each stream frame can be
   immediately dispatched to that stream on arrival, so streams without
   loss can continue to be reassembled and make forward progress in the
   application.

   Caveat: QUIC currently compresses HTTP headers via HTTP/2 HPACK
   header compression, which imposes head-of-line blocking for header
   frames only.

5.5.  Authenticated and Encrypted Header and Payload

   TCP headers appear in plaintext on the wire and not authenticated,
   causing a plethora of injection and header manipulation issues for
   TCP, such as receive-window manipulation and sequence-number
   overwriting.  While some of these are active attacks, others are
   mechanisms used by middleboxes in the network sometimes in an attempt
   to transparently improve TCP performance.  However, even
   "performance-enhancing" middleboxes still effectively limit the
   evolvability of the transport protocol, as has been observed in the
   design of MPTCP and in its subsequent deployability issues.

   QUIC packets are always authenticated and typically the payload is
   fully encrypted.  The parts of the packet header which are not
   encrypted are still authenticated by the receiver, so as to thwart
   any packet injection or manipulation by third parties.  QUIC protects
   connections from witting or unwitting middlebox manipulation of end-
   to-end communication.

   Caveat: PUBLIC_RESET packets that reset a connection are currently
   not authenticated.

5.6.  Forward Error Correction

   In order to recover lost packets without waiting for a
   retransmission, QUIC currently employs a simple XOR-based FEC scheme.
   An FEC packet contains parity of the packets in the FEC group.  If
   one of the packets in the group is lost, the contents of that packet
   can be recovered from the FEC packet and the remaining packets in the



Hamilton, et al.          Expires July 16, 2016                 [Page 7]


Internet-Draft                    QUIC                      January 2016


   group.  The sender may decide whether to send FEC packets to optimize
   specific scenarios (e.g., beginning and end of a request).

5.7.  Connection Migration

   TCP connections are identified by a 4-tuple of source address, source
   port, destination address and destination port.  A well-known problem
   with TCP is that connections do not survive IP address changes (for
   example, by switching from WiFi to cellular) or port number changes
   (when a client's NAT binding expires causing a change in the port
   number seen at the server).  While MPTCP addresses the connection
   migration problem for TCP, it is still plagued by lack of middlebox
   support and lack of OS deployment.

   QUIC connections are identified by a 64-bit Connection ID, randomly
   generated by the client.  QUIC can survive IP address changes and NAT
   re-bindings since the Connection ID remains the same across these
   migrations.  QUIC also provides automatic cryptographic verification
   of a migrating client, since a migrating client continues to use the
   same session key for encrypting and decrypting packets.

6.  Packet Types and Formats

   QUIC has Special Packets and Regular Packets.  There are two types of
   Special Packets: Version Negotiation Packets and Public Reset
   Packets, and two types of Regular Packets: Frame Packets, and FEC
   Packets.  All QUIC packets should be sized to fit within the path's
   MTU to avoid IP fragmentation.  Path MTU discovery is a work in
   progress, and the current QUIC implementation uses a 1350-byte
   maximum QUIC packet size for IPv6, 1370 for IPv4.

6.1.  QUIC Public Packet Header

   All QUIC packets on the wire begin with a public header sized between
   2 and 19 bytes.  The wire format for the public header is as follows:
















Hamilton, et al.          Expires July 16, 2016                 [Page 8]


Internet-Draft                    QUIC                      January 2016


        0        1        2        3        4            8
   +--------+--------+--------+--------+--------+---    ---+
   | Public |    Connection ID (0, 8, 32, or 64)    ...    | ->
   |Flags(8)|      (variable length)                       |
   +--------+--------+--------+--------+--------+---    ---+

        9       10       11        12
   +--------+--------+--------+--------+
   |      QUIC Version (32)            | ->
   |         (optional)                |
   +--------+--------+--------+--------+

       13      14       15        16        17       18
   +--------+--------+--------+--------+--------+--------+
   |         Packet Number (8, 16, 32, or 48)            |
   |                         (variable length)           |
   +--------+--------+--------+--------+--------+--------+


   The payload may include various type-dependent header bytes as
   described below.

   The fields in the public header are the following:

   o  Public Flags:

      *  0x01 = PUBLIC_FLAG_VERSION.  Interpretation of this flag
         depends on whether the packet is sent by the server or the
         client.  When sent by the client, setting it indicates that the
         header contains a QUIC Version (see below).  This bit must be
         set by a client in all packets until confirmation from the
         server arrives agreeing to the proposed version is received by
         the client.  A server indicates agreement on a version by
         sending packets without setting this bit.  When this bit is set
         by the server, the packet is a Version Negotiation Packet.
         Version Negotiation is described in more detail later.

      *  0x02 = PUBLIC_FLAG_RESET.  Set to indicate that the packet is a
         Public Reset packet.

      *  Two bits at 0x0C indicate the size of the Connection ID that is
         present in the packet.  These bits must be set to 0x0C in all
         packets until negotiated to a different value for a given
         direction (e.g., client may request fewer bytes of the
         Connection ID be presented).

         +  0x0C indicates an 8-byte Connection ID is present




Hamilton, et al.          Expires July 16, 2016                 [Page 9]


Internet-Draft                    QUIC                      January 2016


         +  0x08 indicates that a 4-byte Connection ID is present

         +  0x04 indicates that a 1-byte Connection ID is used

         +  0x00 indicates that the Connection ID is omitted

      *  Two bits at 0x30 indicate the number of low-order-bytes of the
         packet number that are present in each packet.  The bits are
         only used for Frame Packets.  For Public Reset and Version
         Negotiation Packets (sent by the server) which don't have a
         packet number, these bits are not used and must be set to 0.
         Within this 2 bit mask:

         +  0x30 indicates that 6 bytes of the packet number is present

         +  0x20 indicates that 4 bytes of the packet number is present

         +  0x10 indicates that 2 bytes of the packet number is present

         +  0x00 indicates that 1 byte of the packet number is present

      *  0x40 is reserved for multipath use.

      *  0x80 is currently unused, and must be set to 0.

   o  Connection ID: This is an unsigned 64 bit statistically random
      number selected by the client that is the identifier of the
      connection.  Because QUIC connections are designed to remain
      established even if the client roams, the IP 4-tuple (source IP,
      source port, destination IP, destination port) may be insufficient
      to identify the connection.  For each transmission direction, when
      less uniqueness is sufficient to identify the connection, a
      truncated transmitted Connection ID length is negotiable.

   o  QUIC Version: A 32 bit opaque tag that represents the version of
      the QUIC protocol.  Only present if the public flags contain
      FLAG_VERSION (i.e public_flags & FLAG_VERSION !=0).  A client may
      set this flag, and include EXACTLY one proposed version, as well
      as including arbitrary data (conforming to that version).  A
      server may set this flag when the client-proposed version was
      unsupported, and may then provide a list (0 or more) of acceptable
      versions, but MUST not include any data after the version(s).
      Examples of version values in recent experimental versions include
      "Q025" which corresponds to byte 9 containing 'Q", byte 10
      containing '0", etc.  [See list of changes in various versions
      listed at the end of this document.]





Hamilton, et al.          Expires July 16, 2016                [Page 10]


Internet-Draft                    QUIC                      January 2016


   o  Packet Number: The lower 8, 16, 32, or 48 bits of the packet
      number, based on which FLAG_?BYTE_SEQUENCE_NUMBER flag is set in
      the public flags.  Each Regular Packet (as opposed to the Special
      public reset and version negotiation packets) is assigned a packet
      number by the sender.  The first packet sent by an endpoint shall
      have a packet number of 1, and each subsequent packet shall have a
      packet number one larger than that of the previous packet.  The
      lower 64 bits of the packet number is used as part of a
      cryptographic nonce; therefore, a QUIC endpoint must not send a
      packet with a packet number that cannot be represented in 64 bits.
      If a QUIC endpoint transmits a packet with a packet number of
      (2^64-1), that packet must include a CONNECTION_CLOSE frame with
      an error code of QUIC_SEQUENCE_NUMBER_LIMIT_REACHED, and the
      endpoint must not transmit any additional packets.  At most the
      lower 48 bits of a packet number are transmitted.  To enable
      unambiguous reconstruction of the packet number by the receiver, a
      QUIC endpoint must not transmit a packet whose packet number is
      larger by (2^(bitlength-2)) than the largest packet number for
      which an acknowledgement is known to have been transmitted by the
      receiver.  Therefore, there must never be more than (2^46) packets
      in flight.  Any truncated packet number shall be inferred to have
      the value closest to the one more than the largest known packet
      number of the endpoint which transmitted the packet that
      originally contained the truncated packet number.  The transmitted
      portion of the packet number matches the lowest bits of the
      inferred value.

   A Public Flags processing flowchart follows:























Hamilton, et al.          Expires July 16, 2016                [Page 11]


Internet-Draft                    QUIC                      January 2016


Check the public flags in public header
                 |
                 |
                 V
           +--------------+
           | Public Reset |    YES
           | flag set?    |---------------> Public Reset Packet
           +--------------+
                 |
                 | NO
                 V
           +------------+          +-------------+
           | Version    |   YES    | Packet sent |  YES
           | flag set?  |--------->| by server?  |--------> Version Negotiation
           +------------+          +-------------+               Packet
                 |                        |
                 | NO                     | NO
                 V                        V
           Regular Packet         Regular Packet with
                              QUIC Version present in header

6.2.  Special Packets

6.2.1.  Version Negotiation Packet

   A version negotiation packet is only sent by the server.  Version
   Negotiation packets begin with an 8-bit public flags and 64-bit
   Connection ID.  The public flags must set PUBLIC_FLAG_VERSION and
   indicate the 64-bit Connection ID.  The rest of the Version
   Negotiation packet is a list of 4-byte versions which the server
   supports:

     0        1        2        3        4        5        6        7       8
+--------+--------+--------+--------+--------+--------+--------+--------+--------+
| Public |    Connection ID (64)                                                 | ->
|Flags(8)|                                                                       |
+--------+--------+--------+--------+--------+--------+--------+--------+--------+

     9       10       11        12       13      14       15       16       17
+--------+--------+--------+--------+--------+--------+--------+--------+---...--+
|      1st QUIC version supported   |     2nd QUIC version supported    |   ...
|      by server (32)               |     by server (32)                |
+--------+--------+--------+--------+--------+--------+--------+--------+---...--+








Hamilton, et al.          Expires July 16, 2016                [Page 12]


Internet-Draft                    QUIC                      January 2016


6.2.2.  Public Reset Packet

   A Public Reset packet begins with an 8-bit public flags and 64-bit
   Connection ID.  The public flags must set PUBLIC_FLAG_RESET and
   indicate the 64-bit Connection ID.  The rest of the Public Reset
   packet is encoded as if it were a crypto handshake message of the tag
   PRST (see [QUIC-CRYPTO]):

        0        1        2        3        4         8
   +--------+--------+--------+--------+--------+--   --+
   | Public |    Connection ID (64)                ...  | ->
   |Flags(8)|                                           |
   +--------+--------+--------+--------+--------+--   --+

        9       10       11        12       13      14
   +--------+--------+--------+--------+--------+--------+---
   |      Quic Tag (32)                |  Tag value map      ... ->
   |         (PRST)                    |  (variable length)
   +--------+--------+--------+--------+--------+--------+---

   Tag value map: The tag value map contains the following tag-values:

   o  RNON (public reset nonce proof) - a 64-bit unsigned integer.
      Mandatory.

   o  RSEQ (rejected packet number) - a 64-bit packet number.
      Mandatory.

   o  CADR (client address) - the observed client IP address and port
      number.  This is currently for debugging purposes only and hence
      is optional.

   (TODO: Public Reset packet should include authenticated (destination)
   server IP/port.)

6.3.  Regular Packets

   Regular Packets are authenticated and encrypted.  The Public Header
   is authenticated but not encrypted, and the rest of the packet
   starting with the Private Flags field is encrypted.  Immediately
   following the Public Header, Regular Packets contain AEAD
   (authenticated encryption and associated data) data.  This data must
   be decrypted in order for the contents to be interpreted.  After
   decryption, the plaintext starts with a Private Header.







Hamilton, et al.          Expires July 16, 2016                [Page 13]


Internet-Draft                    QUIC                      January 2016


        0        1
   +--------+--------+
   |Private | FEC (8)|
   |Flags(8)|  (opt) |
   +--------+--------+


   The fields in the private header are the following:

   o  Private Flags:

      *  0x01 = FLAG_ENTROPY - for data packets, signifies that this
         packet contains the 1 bit of entropy, for fec packets, contains
         the xor of the entropy of protected packets.

      *  0x02 = FLAG_FEC_GROUP - indicates whether the fec byte is
         present.

      *  0x04 = FLAG_FEC - signifies that this packet represents an FEC
         packet.

   o  FEC (FEC Group Number Offset): An FEC Group Number is the Packet
      Number of the first packet in the FEC group.  The FEC Group Number
      Offset is an 8 bit unsigned value which should be subtracted from
      the current packet's Packet Number to yield the FEC Group Number
      for this packet.  This is only present if the private flags
      contain FLAG_FEC_GROUP.  All packets within a single FEC group
      must have Packet Numbers encoded into an identical number of bytes
      (i.e., the Packet Number coding must not change during a group)

   (TODO: Document the inputs to encryption and decryption and describe
   trial decryption.)

6.3.1.  Frame Packet

   Beyond the Private Header, Frame Packets have a payload that is a
   series of type-prefixed frames.  The format of frame types is defined
   later in this document, but the general format of a Frame Packet is
   as follows:

   +--------+---...---+--------+---...---+
   | Type   | Payload | Type   | Payload |
   +--------+---...---+--------+---...---+








Hamilton, et al.          Expires July 16, 2016                [Page 14]


Internet-Draft                    QUIC                      January 2016


6.3.2.  FEC Packet

   FEC packets (those packets with FLAG_FEC set) have a payload that
   simply contains an XOR of the null-padded payload of each Data Packet
   in the FEC group.  FEC packets must also have FLAG_FEC_GROUP set.

   +-----...----+
   | Redundancy |
   +-----...----+

7.  Life of a QUIC Connection

7.1.  Connection Establishment

   A QUIC client is the endpoint that initiates a connection.  QUIC's
   connection establishment intertwines version negotiation with the
   crypto and transport handshakes to reduce connection establishment
   latency.  We first describe version negotiation below.

   Each of the initial packets sent from the client to the server must
   set the version flag, and must specify the version of the protocol
   being used.  Every packet sent by the client must have the version
   flag on, until it receives a packet from the server with the version
   flag off.  After the server receives the first packet from the client
   with the version flag off, it must ignore any (possibly delayed)
   packets with the version flag on.

   When the server receives a packet with a Connection ID for a new
   connection, it will compare the client's version to the versions it
   supports.  If the client's version is acceptable to the server, the
   server will use this protocol version for the lifetime of the
   connection.  In this case, all packets sent by the server will have
   the version flag off.

   If the client's version is not acceptable to the server, a 1-RTT
   delay will be incurred.  The server will send a Version Negotiation
   Packet to the client.  This packet will have the version flag set and
   will include the server's set of supported versions.

   When the client receives a Version Negotiation Packet from the
   server, it will select an acceptable protocol version and resend all
   packets using this version.  These packet must continue to have the
   version flag set and must include the new negotiated protocol
   version.  Eventually, the client receives the first Regular Packet
   (i.e. not a Version Negotiation Packet) from the server indicating
   the end of version negotiation, and the client now sends all
   subsequent packets with the version flag off.




Hamilton, et al.          Expires July 16, 2016                [Page 15]


Internet-Draft                    QUIC                      January 2016


   In order to avoid downgrade attacks, the version of the protocol that
   the client specified in the first packet and the set of versions
   supported by the server must be included in the crypto handshake
   data.  The client needs to verify that the server's version list from
   the handshake matches the list of versions in the Version Negotiation
   Packet.  The server needs to verify that the client's version from
   the handshake represents a version of the protocol that it does not
   actually support.

   The rest of the connection establishment is described in the
   handshake document [QUIC-CRYPTO].  The crypto handshake is performed
   over the dedicated crypto stream (Stream ID 1).

   During connection establishment, the handshake must negotiate various
   transport parameters.  The currently defined transport parameters are
   described later in the document.

7.2.  Data Transfer

   QUIC implements connection reliability, congestion control, and flow
   control.  QUIC flow control closely follows HTTP/2's flow control.
   QUIC reliability and congestion control are described in an
   accompanying document.  A QUIC connection uses a single packet
   sequence number space for shared congestion control and loss recovery
   across the connection.

   All data transferred in a QUIC connection, including the crypto
   handshake, is sent as data inside streams, but the ACKs acknowledge
   QUIC Packets.

   This section conceptually describes the use of streams for data
   transfer within a QUIC connection.  The various frames that are
   mentioned in this section are described in the section on Frame Types
   and Formats.

7.2.1.  Life of a QUIC Stream

   Streams are independent sequences of bi-directional data cut into
   stream frames.  Streams can be created either by the client or the
   server, can concurrently send data interleaved with other streams,
   and can be cancelled.  QUIC's stream lifetime is modeled closely
   after HTTP/2's [RFC7540].  (HTTP/2's usage of QUIC streams is
   described in more detail later in the document.)

   Stream creation is done implicitly, by sending a STREAM frame for a
   given stream.  To avoid stream ID collision, the Stream-ID must be
   even if the server initiates the stream, and odd if the client
   initiates the stream. 0 is not a valid Stream-ID.  Stream 1 is



Hamilton, et al.          Expires July 16, 2016                [Page 16]


Internet-Draft                    QUIC                      January 2016


   reserved for the crypto handshake, which should be the first client-
   initiated stream.  When using HTTP/2 over QUIC, Stream 3 is reserved
   for transmitting compressed headers for all other streams, ensuring
   reliable in-order delivery and processing of headers.

   Stream-IDs from each side of the connection must increase
   monotonically as new streams are created.  E.g.  Stream 2 may be
   created after stream 3, but stream 7 must not be created after stream
   9.  The peer may receive streams out of order.  For example, if a
   server receives packet 10 including frames for stream 9 before it
   receives packet 9 including frames for stream 7, it should handle
   this gracefully.

   If the endpoint receiving a STREAM frame does not want to accept the
   stream, it can immediately respond with a RST_STREAM frame (described
   below).  Note, however, that the initiating endpoint may have already
   sent data on the stream as well; this data must be ignored.

   Once a stream is created, it can be used to send and receive data.
   This means that a series of stream frames can be sent by a QUIC
   endpoint on a stream until the stream is terminated in that
   direction.

   Either QUIC endpoint can terminate a stream normally.  There are
   three ways that streams can be terminated:

   1.  Normal termination: Since streams are bidirectional, streams can
       be "half-closed" or "closed".  When one side of the stream sends
       a frame with the FIN bit set to true, the stream is considered to
       be "half-closed" in that direction.  A FIN indicates that no
       further data will be sent from the sender of the FIN on this
       stream.  When a QUIC endpoint has both sent and received a FIN,
       the endpoint considers the stream to be "closed".  While the FIN
       should be sent with the last user data for a stream, the FIN bit
       can be sent on an empty stream frame following the last data on
       the stream.

   2.  Abrupt termination: Either the client or server can send a
       RST_STREAM frame for a stream at any time.  A RST_STREAM frame
       contains an error code to indicate the reason for failure (error
       codes are listed later in the document.)  When a RST_STREAM frame
       is sent from the stream originator, it indicates a failure to
       complete the stream and that no further data will be sent on the
       stream.  When a RST_STREAM frame is sent from the stream
       receiver, the sender, upon receipt, should stop sending any data
       on the stream.  The stream receiver should be aware that there is
       a race between data already in transit from the sender and the
       time the RST_STREAM frame is received.  In order to ensure that



Hamilton, et al.          Expires July 16, 2016                [Page 17]


Internet-Draft                    QUIC                      January 2016


       the connection-level flow control is correctly accounted, even if
       a RST_STREAM frame is received, a sender needs to ensure that
       either: the FIN and all bytes in the stream are received by the
       peer or a RST_STREAM frame is received by the peer.  This also
       means that the sender of a RST_STREAM frame needs to continue
       responding to incoming STREAM_FRAMEs on this stream with the
       appropriate WINDOW_UPDATEs to ensure that the sender does not get
       flow control blocked attempting to delivery the FIN.

   3.  Streams are also terminated when the connection is terminated, as
       described in the next section.

7.3.  Connection Termination

   Connections should remain open until they become idle for a pre-
   negotiated period of time.  When a server decides to terminate an
   idle connection, it should not notify the client to avoid waking up
   the radio on mobile devices.  A QUIC connection, once established,
   can be terminated in one of two ways:

   1.  Explicit Shutdown: An endpoint sends a CONNECTION_CLOSE frame to
       the peer initiating a connection termination.  An endpoint may
       send a GOAWAY frame to the peer prior to a CONNECTION_CLOSE to
       indicate that the connection will soon be terminated.  A GOAWAY
       frame when sent signals to the peer that any active streams will
       continue to be processed, but the sender of the GOAWAY will not
       initiate any additional streams and will not accept any new
       incoming streams.  On termination of the active streams, a
       CONNECTION_CLOSE may be sent.  If an endpoint sends a
       CONNECTION_CLOSE frame while unterminated streams are active (no
       FIN bit or RST_STREAM frames have been sent or received for one
       or more streams), then the peer must assume that the streams were
       incomplete and were abnormally terminated.

   2.  Implicit Shutdown: The default idle timeout for a QUIC connection
       is 30 seconds, and is a required parameter("ICSL") in connection
       negotiation.  The maximum is 10 minutes.  If there is no network
       activity for the duration of the idle timeout, the connection is
       closed.  By default a CONNECTION_CLOSE frame will be sent.  A
       silent close option can be enabled when it is expensive to send
       an explicit close, such as mobile networks that must wake up the
       radio.

   An endpoint may also send a PUBLIC_RESET packet at any time during
   the connection to abruptly terminate an active connection.  A
   PUBLIC_RESET is the QUIC equivalent of a TCP RST.





Hamilton, et al.          Expires July 16, 2016                [Page 18]


Internet-Draft                    QUIC                      January 2016


8.  Frame Types and Formats

   QUIC Frame Packets are populated by frames. which have a Frame Type
   byte, which itself has a type-dependent interpretation, followed by
   type-dependent frame header fields.  All frames are contained within
   single QUIC Packets and no frame can span across a QUIC Packet
   boundary.

8.1.  Frame Types

   There are two interpretations for the Frame Type byte, resulting in
   two frame types: Special Frame Types, and Regular Frame Types.
   Special Frame Types encode both a Frame Type and corresponding flags
   all in the Frame Type byte, while Regular Frame Types use the Frame
   Type byte simply.

   Currently defined Special Frame Types are:

      +------------------+-----------------------------+
      | Type-field value |     Control Frame-type      |
      +------------------+-----------------------------+
      |     1fdooossB    |  STREAM                     |
      |     01ntllmmB    |  ACK                        |
      |     001xxxxxB    |  CONGESTION_FEEDBACK        |
      +------------------+-----------------------------+

   Currently defined Regular Frame Types are:

      +------------------+-----------------------------+
      | Type-field value |     Control Frame-type      |
      +------------------+-----------------------------+
      | 00000000B (0x00) |  PADDING                    |
      | 00000001B (0x01) |  RST_STREAM                 |
      | 00000010B (0x02) |  CONNECTION_CLOSE           |
      | 00000011B (0x03) |  GOAWAY                     |
      | 00000100B (0x04) |  WINDOW_UPDATE              |
      | 00000101B (0x05) |  BLOCKED                    |
      | 00000110B (0x06) |  STOP_WAITING               |
      | 00000111B (0x07) |  PING                       |
      +------------------+-----------------------------+

8.2.  STREAM Frame

   The STREAM frame is used to both implicitly create a stream and to
   send data on it, and is as follows:






Hamilton, et al.          Expires July 16, 2016                [Page 19]


Internet-Draft                    QUIC                      January 2016


     0        1       ...               SLEN
+--------+--------+--------+--------+--------+
|Type (8)| Stream ID (8, 16, 24, or 32 bits) |
|        |    (Variable length SLEN bytes)   |
+--------+--------+--------+--------+--------+

  SLEN+1  SLEN+2     ...                                         SLEN+OLEN
+--------+--------+--------+--------+--------+--------+--------+--------+
|   Offset (0, 16, 24, 32, 40, 48, 56, or 64 bits) (variable length)    |
|                    (Variable length: OLEN  bytes)                     |
+--------+--------+--------+--------+--------+--------+--------+--------+

  SLEN+OLEN+1   SLEN+OLEN+2
+-------------+-------------+
| Data length (0 or 16 bits)|
|  Optional(maybe 0 bytes)  |
+------------+--------------+

   The fields in the STREAM frame header are as follows:

   o  Frame Type: The Frame Type byte is an 8-bit value containing
      various flags (1fdooossB):

      *  The leftmost bit must be set to 1 indicating that this is a
         STREAM frame.

      *  The 'f' bit is the FIN bit.  When set to 1, this bit indicates
         the sender is done sending on this stream and wishes to "half-
         close" (described in more detail later.)

      *  which is described in more detail later in this document.

      *  The 'd' bit indicates whether a Data Length is present in the
         STREAM header.  When set to 0, this field indicates that the
         STREAM frame extends to the end of the Packet.

      *  The next three 'ooo' bits encode the length of the Offset
         header field as 0, 16, 24, 32, 40, 48, 56, or 64 bits long.

      *  The next two 'ss' bits encode the length of the Stream ID
         header field as 8, 16, 24, or 32 bits long.

   o  Stream ID: A variable-sized unsigned ID unique to this stream.

   o  Offset: A variable-sized unsigned number specifying the byte
      offset in the stream for this block of data.





Hamilton, et al.          Expires July 16, 2016                [Page 20]


Internet-Draft                    QUIC                      January 2016


   o  Data length: An optional 16-bit unsigned number specifying the
      length of the data in this stream frame.  The option to omit the
      length should only be used when the packet is a "full-sized"
      Packet, to avoid the risk of corruption via padding.

   A stream frame must always have either non-zero data length or the
   FIN bit set.

8.3.  ACK Frame

   The ACK frame is sent to inform the peer which packets have been
   received, as well as which packets are still considered missing by
   the receiver (the contents of missing packets may need to be resent).
   The design of QUIC's ACK frame is different from TCP's and SCTP's
   SACK representations in that QUIC ACKs indicate the largest packet
   number observed thus far followed by a list of missing packet, or
   NACK, ranges indicating gaps in packets received below this packet
   number.  To limit the NACK ranges to the ones that haven't yet been
   communicated to the peer, the peer periodically sends STOP_WAITING
   frames that signal the receiver to stop waiting for packets below a
   specified sequence number, raising the "least unacked" packet number
   at the receiver.  A sender of an ACK frame thus reports only those
   NACK ranges between the received least unacked and the reported
   largest observed packet numbers.  The frame is as follows:



























Hamilton, et al.          Expires July 16, 2016                [Page 21]


Internet-Draft                    QUIC                      January 2016


      0        1                           N
 +--------+--------+---------------------------------------------------+
 |  Type  |Received|                Largest Observed                   |
 |  (8)   |Entropy |              (8, 16, 32, or 48 bits)              |
 +--------+--------+---------------------------------------------------+

    N+1       N+2      N+3      N+4                   N+8
 +--------+--------+---------+--------+--------------------------------+
 |    Ack Delay    |   Num   | Delta  |        First Timestamp         |
 |     Time (16)   |Timestamp|Largest |           (32 bits)            |
 |                 |   (8)   |Observed|                                |
 +--------+--------+---------+--------+--------------------------------+

    N+9         N+11 - X
 +--------+-------------------+
 | Delta  |   Time Since      |
 |Largest | Previous Timestamp|  <-- Repeat (NumTimestamp - 1) times
 |Observed|     (16 bits)     |
 +--------+-------------------+

     X                        X+1 - Y                           Y+1
 +--------+-------------------------------------------------+--------+
 | Number |     Missing Packet Sequence Number Delta        | Range  |
 | Ranges |           (8, 16, 32, or 48 bits)               | Length |
 | (opt)  |        (repeats Number Ranges times)            |(Repeat)|
 +--------+-------------------------------------------------+--------+

     Y+2                       Y+3 - Z
 +--------+-----------------------------------------------------+
 | Number |            Revived Packet Number                    |
 | Revived|  (8, 16, 32, or 48 bits, same as Largest Observed)  |
 | (opt)  |        (repeats Number Revived times)               |
 +--------+-----------------------------------------------------+

   The fields in the ACK frame are as follows:

   o  Frame Type: The Frame Type byte is an 8-bit value containing
      various flags (01ntllmmB).

      *  The first two bits must be set to 01 indicating that this is an
         ACK frame.

      *  The 'n' bit indicates whether the frame has any NACK ranges.

      *  The 't' bit indicates whether the ACK frame has been truncated.
         Truncation can happen when the complete ACK frame does not fit
         within a single QUIC Packet, or when the number of NACK ranges
         exceeds the maximum number of reportable NACK ranges (255).



Hamilton, et al.          Expires July 16, 2016                [Page 22]


Internet-Draft                    QUIC                      January 2016


         When truncated, the ACK frame limits the largest observed
         packet number to the largest that can be reported, even though
         the receiver may have received packets with packet numbers
         larger than the largest observed.

      *  The two 'll' bits encode the length of the Largest Observed
         field as 1, 2, 4, or 6 bytes long.

      *  The two 'mm' bits encode the length of the Missing Packet
         Sequence Number Delta field as 1, 2, 4, or 6 bytes long.

   o  Received Entropy: An 8 bit unsigned value specifying the
      cumulative hash of entropy in all received packets up to the
      largest observed packet.  Entropy accumulation is described later
      in this section.

   o  Largest Observed: A variable-sized unsigned value representing the
      largest packet number the peer has observed.  When an ACK frame is
      truncated, it indicates a packet number greater than the specified
      largest observed has been received, but information about those
      additional receptions can't fit into this frame (typically due to
      packet size restrictions).

   o  Ack Delay Time: A 16-bit unsigned float with 11 explicit bits of
      mantissa and 5 bits of explicit exponent, specifying the time
      elapsed in microseconds from when largest observed was received
      until this Ack frame was sent.  The bit format is loosely modeled
      after IEEE 754.  For example, 1 microsecond is represented as 0x1,
      which has an exponent of zero, presented in the 5 high order bits,
      and mantissa of 1, presented in the 11 low order bits.  When the
      explicit exponent is greater than zero, an implicit high-order
      12th bit of 1 is assumed in the mantissa.  For example, a floating
      value of 0x800 has an explicit exponent of 1, as well as an
      explicit mantissa of 0, but then has an effective mantissa of 4096
      (12th bit is assumed to be 1).  Additionally, the actual exponent
      is one-less than the explicit exponent, and the value represents
      4096 microseconds.  Any values larger than the representable range
      are clamped to 0xFFFF.

   o  Timestamp Section:

      *  Num Timestamp: An 8-bit unsigned value specifying the number of
         timestamps that are included in this ack frame.  There will be
         this many pairs of <packet number, timestamp> following in the
         timestamps.

      *  Delta Largest Observed: An 8-bit unsigned value specifying the
         packet number delta from the first timestamp to the largest



Hamilton, et al.          Expires July 16, 2016                [Page 23]


Internet-Draft                    QUIC                      January 2016


         observed.  Therefore, the packet number is the largest observed
         minus the delta largest observed.

      *  First Timestamp: A 32-bit unsigned value specifying the time
         delta in microseconds, from the beginning of the connection of
         the arrival of the packet specified by Largest Observed minus
         Delta Largest Observed.

      *  Delta Largest Observed (Repeated): (Same as above.)

      *  Time Since Previous Timestamp (Repeated): A 16-bit unsigned
         value specifying delta from the previous timestamp.  It is
         encoded in the same format as the Ack Delay Time.

   o  Missing Packet Section:

      *  Num Ranges: An optional 8-bit unsigned value specifying the
         number of missing packet ranges between largest observed and
         least unacked.  Only present if the 'n' flag bit is 1.

      *  Missing Packet Sequence Number Delta: A variable-sized packet
         number delta.  For the first missing packet range, it is a
         delta from the largest observed.  For subsequent nack ranges,
         it is the number of packets received between ranges.  In the
         case of the first nack range, a value of 0 specifies that the
         packet reported as the largest observed is missing.  In the
         case of the later nack ranges, a value of 0 indicates the
         missing packet ranges are contiguous (used only when more than
         256 packets in a row were lost).

      *  Range Length: An 8-bit unsigned value specifying one less than
         the number of sequential nacks in the range.

   o  Revived Packet Section:

      *  Num Revived: An 8-bit unsigned value specifying the number of
         revived packets, recovered via FEC.  Just like the Num Ranges
         field, this field is only present if the 'n' flag bit is 1.

      *  Revived Packet Sequence Number: A variable-sized unsigned value
         representing a packet the peer has revived via FEC.  Its length
         is the same as the length of the Largest Observed field.  All
         packet numbers in this list are sorted in ascending order
         (smallest first) and must also be present in the list of NACK
         ranges.






Hamilton, et al.          Expires July 16, 2016                [Page 24]


Internet-Draft                    QUIC                      January 2016


8.3.1.  Entropy Accumulation

   The entropy bits for a subset of packets (known to a receiver or
   sender) are accumulated into an 8 bit unsigned value, and similarly
   presented in both a STOP_WAITING frame and an ACK frame.  If we
   defined E(k) to be the FLAG_ENTROPY bit present in packet number k,
   then the k'th packet's contribution C(k) is defined to be E(k) left
   shifted by k mod 8 bits.  The accumulated entropy is then the
   bitwise-XOR sum of the contributions C(k), for all packets in the
   desired subset.

8.4.  STOP_WAITING Frame

   The STOP_WAITING frame is sent to inform the peer that it should not
   continue to wait for packets with packet numbers lower than a
   specified value.  The packet number is encoded in 1, 2, 4 or 6 bytes,
   using the same coding length as is specified for the packet number
   for the enclosing packet's header (specified in the QUIC Frame
   Packet's Public Flags field.)  The frame is as follows:

      0        1        2        3         4        5        6      7
 +--------+--------+--------+--------+--------+--------+-------+-------+
 |Type (8)|Sent    |   Least unacked delta (8, 16, 32, or 48 bits)     |
 |        |Entropy |                       (variable length)           |
 +--------+--------+--------+--------+--------+--------+-------+-------+

   The fields in the STOP_WAITING frame are as follows:

   o  Frame Type: The Frame Type byte is an 8-bit value that must be set
      to 0x06 indicating that this is a STOP_WAITING frame.

   o  Sent Entropy: An 8-bit unsigned value specifying the cumulative
      hash of entropy in all sent packets up to the packet with packet
      number one less than the least unacked packet.  [See "Entropy
      Accumulation" section in the ACK frame section for details of this
      calculation.]

   o  Least Unacked Delta: A variable length packet number delta with
      the same length as the packet header's packet number.  In the case
      of an FEC revived packet, the same length as the other packets in
      the FEC group.  Subtract it from the header's packet number to
      determine the least unacked.  The resulting least unacked is the
      smallest packet number of any packet for which the sender is still
      awaiting an ack.  If the receiver is missing any packets smaller
      than this value, the receiver should consider those packets to be
      irrecoverably lost.





Hamilton, et al.          Expires July 16, 2016                [Page 25]


Internet-Draft                    QUIC                      January 2016


8.5.  WINDOW_UPDATE Frame

   The WINDOW_UPDATE frame is used to inform the peer of an increase in
   an endpoint's flow control receive window.  The stream ID can be 0,
   indicating this WINDOW_UPDATE applies to the connection level flow
   control window, or > 0 indicating that the specified stream should
   increase its flow control window.  The frame is as follows:

   An absolute byte offset is specified, and the receiver of a
   WINDOW_UPDATE frame may only send up to that number of bytes on the
   specified stream.  Violating flow control by sending further bytes
   will result in the receiving endpoint closing the connection.

   On receipt of multiple WINDOW_UPDATE frames for a specific stream ID,
   it is only necessary to keep track of the maximum byte offset.

   Both stream and session windows start with a default value of 16 KB,
   but this is typically increased during the handshake.  To do this, an
   endpoint should negotiate the SFCW (Stream Flow Control Window) and
   CFCW (Connection/Session Flow Control Window) parameters in the
   handshake.  The value associated with each tag should be the number
   of bytes for initial stream window and initial connection window
   respectively.

   The frame is as follows:

       0         1                 4        5                 12
   +--------+--------+-- ... --+-------+--------+-- ... --+-------+
   |Type(8) |    Stream ID (32 bits)   |  Byte offset (64 bits)   |
   +--------+--------+-- ... --+-------+--------+-- ... --+-------+

   The fields in the WINDOW_UPDATE frame are as follows:

   o  Frame Type: The Frame Type byte is an 8-bit value that must be set
      to 0x04 indicating that this is a WINDOW_UPDATE frame.

   o  Stream ID: ID of the stream whose flow control windows is being
      updated, or 0 to specify the connection-level flow control window.

   o  Byte offset: A 64-bit unsigned integer indicating the absolute
      byte offset of data which can be sent on the given stream.  In the
      case of connection level flow control, the cumulative number of
      bytes which can be sent on all currently open streams.








Hamilton, et al.          Expires July 16, 2016                [Page 26]


Internet-Draft                    QUIC                      January 2016


8.6.  BLOCKED Frame

   The BLOCKED frame is used to indicate to the remote endpoint that
   this endpoint is ready to send data (and has data to send), but is
   currently flow control blocked.  This is a purely informational
   frame, which is extremely useful for debugging purposes.  A receiver
   of a BLOCKED frame should simply discard it (after possibly printing
   a helpful log message).  The frame is as follows:

        0        1        2        3         4
   +--------+--------+--------+--------+--------+
   |Type(8) |          Stream ID (32 bits)      |
   +--------+--------+--------+--------+--------+

   The fields in the BLOCKED frame are as follows:

   o  Frame Type: The Frame Type byte is an 8-bit value that must be set
      to 0x05 indicating that this is a BLOCKED frame.

   o  Stream ID: A 32-bit unsigned number indicating the stream which is
      flow control blocked.  A non-zero Stream ID field specifies the
      stream that is flow control blocked.  When zero, the Stream ID
      field indicates that the connection is flow control blocked at the
      connection level.

8.7.  CONGESTION_FEEDBACK Frame

   The CONGESTION_FEEDBACK frame is an experimental frame currently not
   used.  It is intended to provide extra congestion feedback
   information outside the scope of the standard ack frame.  A
   CONGESTION_FEEDBACK frame must have the first three bits of the Frame
   Type set to 001.  The last 5 bits of the Frame Type field are
   reserved for future use.

8.8.  PADDING Frame

   The PADDING frame pads a packet with 0x00 bytes.  When this frame is
   encountered, the rest of the packet is expected to be padding bytes.
   The frame contains 0x00 bytes and extends to the end of the QUIC
   packet.  A PADDING frame only has a Frame Type field, and must have
   the 8-bit Frame Type field set to 0x00.

8.9.  RST_STREAM Frame

   The RST_STREAM frame allows for abnormal termination of a stream.
   When sent by the creator of a stream, it indicates the creator wishes
   to cancel the stream.  When sent by the receiver of a stream, it




Hamilton, et al.          Expires July 16, 2016                [Page 27]


Internet-Draft                    QUIC                      January 2016


   indicates an error or that the receiver did not want to accept the
   stream, so the stream should be closed.  The frame is as follows:

     0        1            4      5              12     8             16
+-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+
|Type(8)| StreamID (32 bits) | Byte offset (64 bits)| Error code (32 bits)|
+-------+--------+-- ... ----+--------+-- ... ------+-------+-- ... ------+

   The fields in a RST_STREAM frame are as follows:

   o  Frame type: The Frame Type is an 8-bit value that must be set to
      0x01 specifying that this is a RST_STREAM frame.

   o  Stream ID: The 32-bit Stream ID of the stream being terminated.

   o  Byte offset: A 64-bit unsigned integer indicating the absolute
      byte offset of the end of data for this stream.

   o  Error code: A 32-bit QuicErrorCode which indicates why the stream
      is being closed.  QuicErrorCodes are listed later in this
      document.

8.10.  PING frame

   The PING frame can be used by an endpoint to verify that a peer is
   still alive.  The PING frame contains no payload.  The receiver of a
   PING frame simply needs to ACK the packet containing this frame.  The
   PING frame should be used to keep a connection alive when a stream is
   open.  The default is to do this after 15 seconds of quiescence,
   which is much shorter than most NATs time out.  A PING frame only has
   a Frame Type field, and must have the 8-bit Frame Type field set to
   0x07.

8.11.  CONNECTION_CLOSE frame

   The CONNECTION_CLOSE frame allows for notification that the
   connection is being closed.  If there are streams in flight, those
   streams are all implicitly closed when the connection is closed.
   (Ideally, a GOAWAY frame would be sent with enough time that all
   streams are torn down.)  The frame is as follows:

        0        1             4        5        6       7
   +--------+--------+-- ... -----+--------+--------+--------+----- ...
   |Type(8) | Error code (32 bits)| Reason phrase   |  Reason phrase
   |        |                     | length (16 bits)|(variable length)
   +--------+--------+-- ... -----+--------+--------+--------+----- ...

   The fields of a CONNECTION_CLOSE frame are as follows:



Hamilton, et al.          Expires July 16, 2016                [Page 28]


Internet-Draft                    QUIC                      January 2016


   o  Frame Type: An 8-bit value that must be set to 0x02 specifying
      that this is a CONNECTION_CLOSE frame.

   o  Error Code: A 32-bit field containing the QuicErrorCode which
      indicates the reason for closing this connection.

   o  Reason Phrase Length: A 16-bit unsigned number specifying the
      length of the reason phrase.  This may be zero if the sender
      chooses to not give details beyond the QuicErrorCode.

   o  Reason Phrase: An optional human-readable explanation for why the
      connection was closed.

8.12.  GOAWAY Frame

   The GOAWAY frame allows for notification that the connection should
   stop being used, and will likely be aborted in the future.  Any
   active streams will continue to be processed, but the sender of the
   GOAWAY will not initiate any additional streams, and will not accept
   any new streams.  The frame is as follows:

        0        1             4      5       6       7      8
   +--------+--------+-- ... -----+-------+-------+-------+------+
   |Type(8) | Error code (32 bits)| Last Good Stream ID (32 bits)| ->
   +--------+--------+-- ... -----+-------+-------+-------+------+

         9        10       11
   +--------+--------+--------+----- ...
   | Reason phrase   |  Reason phrase
   | length (16 bits)|(variable length)
   +--------+--------+--------+----- ...

   The fields of a GOAWAY frame are as follows:

   o  Frame type: An 8-bit value that must be set to 0x06 specifying
      that this is a GOAWAY frame.

   o  Error Code: A 32-bit field containing the QuicErrorCode which
      indicates the reason for closing this connection.

   o  Last Good Stream ID: The last Stream ID which was accepted by the
      sender of the GOAWAY message.  If no streams were replied to, this
      value must be set to 0.

   o  Reason Phrase Length: A 16-bit unsigned number specifying the
      length of the reason phrase.  This may be zero if the sender
      chooses to not give details beyond the error code.




Hamilton, et al.          Expires July 16, 2016                [Page 29]


Internet-Draft                    QUIC                      January 2016


   o  Reason Phrase: An optional human-readable explanation for why the
      connection was closed.

9.  QUIC Transport Parameters

   The handshake is responsible for negotiating a variety of transport
   parameters for a QUIC connection.

9.1.  Required Parameters

   o  SFCW - Stream Flow Control Window.  The size in bytes of the
      stream level flow control window.

   o  CFCW - Connection Flow Control Window.  The size in bytes of the
      connection level flow control window.

9.2.  Optional Parameters

   o  SRBF - Socket receive buffer size in bytes.  The peer may want to
      limit their max CWND to something similar to the socket receive
      buffer if they fear the peer may sometimes be delayed in reading
      packets from kernel's socket buffer.  Defaults to 256kbytes and
      has a minimum value of 16kbytes.

   o  TCID - Connection ID truncation.  Indicates support for truncated
      Connection IDs.  If sent by a peer, indicates the connection IDs
      sent to the peer should be truncated to 0 bytes.  Useful for cases
      when a client ephemeral port is only used for a single connection.

   o  COPT - Connection Options are a repeated tag field.  The field
      contains any connection options being requested by the client or
      server.  These are typically used for experimentation and will
      evolve over time.  Example use cases include changing congestion
      control algorithms and parameters such as initial window.

10.  QuicErrorCodes

   The number to code mappings for QuicErrorCodes are currently defined
   in the Chromium source code in src/net/quic/quic_protocol.h.  (TODO:
   hardcode numbers and add them here)

   o  QUIC_NO_ERROR: There was no error.  This is not valid for
      RST_STREAM frames or CONNECTION_CLOSE frames

   o  QUIC_STREAM_DATA_AFTER_TERMINATION: There were data frames after
      the a fin or reset.





Hamilton, et al.          Expires July 16, 2016                [Page 30]


Internet-Draft                    QUIC                      January 2016


   o  QUIC_SERVER_ERROR_PROCESSING_STREAM: There was some server error
      which halted stream processing.

   o  QUIC_MULTIPLE_TERMINATION_OFFSETS: The sender received two
      mismatching fin or reset offsets for a single stream.

   o  QUIC_BAD_APPLICATION_PAYLOAD: The sender received bad application
      data.

   o  QUIC_INVALID_PACKET_HEADER: The sender received a malformed packet
      header.

   o  QUIC_INVALID_FRAME_DATA: The sender received an frame data.  The
      more detailed error codes below are prefered where possible.

   o  QUIC_INVALID_FEC_DATA: FEC data is malformed.

   o  QUIC_INVALID_RST_STREAM_DATA: Stream rst data is malformed

   o  QUIC_INVALID_CONNECTION_CLOSE_DATA: Connection close data is
      malformed.

   o  QUIC_INVALID_ACK_DATA: Ack data is malformed.

   o  QUIC_DECRYPTION_FAILURE: There was an error decrypting.

   o  QUIC_ENCRYPTION_FAILURE: There was an error encrypting.

   o  QUIC_PACKET_TOO_LARGE: The packet exceeded MaxPacketSize.

   o  QUIC_PACKET_FOR_NONEXISTENT_STREAM: Data was sent for a stream
      which did not exist.

   o  QUIC_CLIENT_GOING_AWAY: The client is going away (browser close,
      etc.)

   o  QUIC_SERVER_GOING_AWAY: The server is going away (restart etc.)

   o  QUIC_INVALID_STREAM_ID: A stream ID was invalid.

   o  QUIC_TOO_MANY_OPEN_STREAMS: Too many streams already open.

   o  QUIC_CONNECTION_TIMED_OUT: We hit our pre-negotiated (or default)
      timeout

   o  QUIC_CRYPTO_TAGS_OUT_OF_ORDER: Handshake message contained out of
      order tags.




Hamilton, et al.          Expires July 16, 2016                [Page 31]


Internet-Draft                    QUIC                      January 2016


   o  QUIC_CRYPTO_TOO_MANY_ENTRIES: Handshake message contained too many
      entries.

   o  QUIC_CRYPTO_INVALID_VALUE_LENGTH: Handshake message contained an
      invalid value length.

   o  QUIC_CRYPTO_MESSAGE_AFTER_HANDSHAKE_COMPLETE: A crypto message was
      received after the handshake was complete.

   o  QUIC_INVALID_CRYPTO_MESSAGE_TYPE: A crypto message was received
      with an illegal message tag.

   o  QUIC_SEQUENCE_NUMBER_LIMIT_REACHED: Transmitting an additional
      packet would cause a packet number to be reused.

11.  Priority

   (TODO: implement)

   QUIC will use the HTTP/2 prioritization mechanism.  Roughly, a stream
   may be dependent on another stream.  In this situation, the "parent"
   stream should effectively starve the "child" stream.  In addition,
   parent streams have an explicit priority.  Parent streams should not
   starve other parent streams, but should make progress proportional to
   their relative priority.

12.  HTTP/2 Layering over QUIC

   Since QUIC integrates various HTTP/2 mechanisms with transport
   mechanisms, QUIC implements a number of features that are also
   specified in HTTP/2.  As a result, QUIC allows HTTP/2 mechanisms to
   be replaced by QUIC's implementation, reducing complexity in the
   HTTP/2 protocol.  This section briefly describes how HTTP/2 semantics
   can be offered over a QUIC implementation.

12.1.  Stream Management

   When HTTP/2 headers and data are sent over QUIC, the QUIC layer
   handles most of the stream management.  HTTP/2 Stream IDs are
   replaced by QUIC Stream IDs.  HTTP/2 does not need to do any explicit
   stream framing when using QUIC---data sent over a QUIC stream simply
   consists of HTTP/2 headers or body.  Requests and responses are
   considered complete when the QUIC stream is closed in the
   corresponding direction.

   Stream flow control is handled by QUIC, and does not need to be re-
   implemented in HTTP/2.  QUIC's flow controller replaces the two
   levels of poorly matched flow controllers in current HTTP/2



Hamilton, et al.          Expires July 16, 2016                [Page 32]


Internet-Draft                    QUIC                      January 2016


   deployments---one at the HTTP/2 level, and the other at the TCP
   level.

12.2.  HTTP/2 Header Compression

   QUIC implements HPACK header compression [4] for HTTP/2, which
   unfortunately introduces some Head-of-Line blocking since HTTP/2
   header blocks must be decompressed in the order they were compressed.

   Since streams may be processed in arbitrary order at a receiver,
   strict ordering across headers is enforced by sending all headers on
   a dedicated headers stream, with Stream ID 3.  An HTTP/2 receiver
   using QUIC would thus process data from a stream only after receiving
   the corresponding header on the headers stream.

   Future work will tweak the compressor and decompressor in QUIC so
   that the compressed output does not depend on unacked previous
   compressed state.  This could be done, perhaps, by creating
   "checkpoints" of HPACK state which are updated when headers have been
   acked.  When compressing headers QUIC would only compress relative to
   the previous "checkpoint".

12.3.  Parsing HTTP/2 Headers

   Bytes sent on the dedicated headers stream are simply HTTP/2 HEADERS
   frames.  The exact layout of these frames is described in RFC 7540
   [5].

12.4.  Persistent Connections

   Unlike when using TCP, the underlying connection for QUIC is
   guaranteed to be persistent.  The HTTP "Connection" header is
   therefore does not apply.  For best performance, it is expected that
   clients will not close a QUIC connection until the user navigates
   away from all web pages using that connection, or until the server
   closes the connection.

12.5.  QUIC Negotiation in HTTP

   The Alternate-Protocol header is used to negotiate use of QUIC on
   future HTTP requests.  To specify QUIC as an alternate protocol
   available on port 123, a server uses:

   "Alternate-Protocol: 123:quic"

   When a client receives a Alternate-Protocol header advertising QUIC,
   it can then attempt to use QUIC for future secure connections on that
   domain.  Since middleboxes and/or firewalls can block QUIC and/or UDP



Hamilton, et al.          Expires July 16, 2016                [Page 33]


Internet-Draft                    QUIC                      January 2016


   communication, a client should implement a graceful fallback to TCP
   when QUIC reachability is broken.

   Note that the server may reply with multiple field values or a comma-
   separated field value for Alternate-Protocol to indicate the various
   transports it supports.

   A server can also send a header to notify that QUIC should not be
   used on this domain.  If it sends the alternate-protocol-required
   header, the client should remember to not use QUIC on that domain in
   future, and not do any UDP probing to see if QUIC is available.

13.  Handshake Protocol Requirements

   QUIC provides a dedicated stream (Stream ID 1) to be used for
   performing a combined connection and security handshake, but the
   details of this handshake protocol are out of this document's scope.
   However, QUIC does impose a number of requirements on any such
   handshake protocol.  The following list of requirements documents
   properties of the current prototype handshake which should be
   provided by any future handshake protocol.

13.1.  Connection Establishment in 0-RTT

   The QUIC handshake protocol manages to successfully achieve 0-RTT for
   most connections, and is critical to QUIC's latency improvements.

13.2.  Source Address Spoofing Defense

   TCP verifies the client's address by burning a round trip on the SYN,
   SYN_ACK exchange.  QUIC uses a source address token delivered by the
   server in a previous connection.

13.3.  Opaque Source Address Tokens

   QUIC servers store a number of pieces of data in the source address
   token, for use on a subsequent connection from the same client.  This
   includes recently used source addresses, measured bandwidth to the
   client, and server-designated connection IDs (for Stateless REJs).
   An alternative handshake protocol's analog of a source address token
   needs to be (i) opaque at the client, and (ii) large enough to permit
   these bits of information to be stored.  Alternatively, the handshake
   protocol should have a different method to store this information at
   the client.







Hamilton, et al.          Expires July 16, 2016                [Page 34]


Internet-Draft                    QUIC                      January 2016


13.4.  Transport Parameter Negotiation

   In addition to negotiating crypto parameters, the QUIC handshake also
   negotiates QUIC and HTTP/2 level parameters, including max open QUIC
   streams and other QUIC connection options.

13.5.  Certificate Compression

   The QUIC handshake compresses certificates so that an REJ, including
   the common Google certificate chain, is able to fit into two 1350
   byte packets.  This helps to reduce the amplification attack
   footprint of QUIC without reducing 0-RTT rate.

13.6.  Server Config Update

   QUIC uses a Server Config Update (SCUP) message to refresh the
   source-address token (STK) and server config mid-connection,
   extending the period over which 0-RTT connections can be established
   by the client.

14.  Recent Changes By Version

   o  Q009: added priority as the first 4 bytes on spdy streams.

   o  Q010: renumber the various frame types

   o  Q011: shrunk the fnv128 hash on NULL encrypted packets from 16
      bytes to 12 bytes.

   o  Q012: optimize the ack frame format to reduce the size and better
      handle ranges of nacks, which should make truncated acks virtually
      impossible.  Also adding an explicit flag for truncated acks and
      moving the ack outside of the connection close frame.

   o  Q013: Compressed headers for *all* data streams are serialized
      into a reserved stream.  This ensures serialized handling of
      headers, independent of stream cancellation notification.

   o  Q014: Added WINDOW_UPDATE and BLOCKED frames, no behavioral
      change.

   o  Q015: Removes the accumulated_number_of_lost_packets field from
      the TCP and inter arrival congestion feedback frames and adds an
      explicit list of recovered packets to the ack frame.

   o  Q016: Breaks out the sent_info field from the ACK frame into a new
      STOP_WAITING frame.




Hamilton, et al.          Expires July 16, 2016                [Page 35]


Internet-Draft                    QUIC                      January 2016


   o  Changed GUID to Connection ID

   o  Q017: Adds stream level flow control

   o  Q018: Added a PING frame

   o  Q019: Adds session/connection level flow control

   o  Q020: Allow endpoints to set different stream/session flow control
      windows

   o  Q021: Crypto and headers streams are flow controlled (at stream
      level)

   o  Q023: Ack frames include packet timestamps

   o  Q024: HTTP/2-style header compression

   o  Q025: HTTP/2-style header keys.  Removal of error_details from the
      RST_STREAM frame.

   o  Q026: Token binding, adds expected leaf cert (XLCT) tag to client
      hello

   o  Q027: Adds a nonce to the server hello

   o  Q029: Server and client honor QUIC_STREAM_NO_ERROR on early
      response

   .

15.  References

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key Words for use in RFCs to Indicate
              Requirement Levels", March 1997.

15.2.  Informative References

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
              Protocol Version 2 (HTTP/2)", May 2015.

   [QUIC-CRYPTO]
              Langley, A. and W. Chang, "QUIC Crypto", June 2015.

   [QUIC-CC]  Iyengar, J. and I. Swett, "QUIC Loss Recovery and
              Congestion Control", December 2015.



Hamilton, et al.          Expires July 16, 2016                [Page 36]


Internet-Draft                    QUIC                      January 2016


15.3.  URIs

   [1] https://goo.gl/dMVtFi

   [2] https://www.chromium.org/quic

   [3] http://goo.gl/jOvOQ5

   [4] http://http2.github.io/http2-spec/compression.html

   [5] https://httpwg.github.io/specs/rfc7540.html#HEADERS

Authors' Addresses

   Ryan Hamilton
   Google

   Email: rch@google.com


   Janardhan Iyengar
   Google

   Email: jri@google.com


   Ian Swett
   Google

   Email: ianswett@google.com


   Alyssa Wilk
   Google

   Email: alyssar@google.com















Hamilton, et al.          Expires July 16, 2016                [Page 37]


Html markup produced by rfcmarkup 1.120, available from https://tools.ietf.org/tools/rfcmarkup/