QUIC Congestion Control And Loss Recovery
draft-iyengar-quic-loss-recovery-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2016-07-08
Replaced by draft-ietf-quic-recovery
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         J. Iyengar
Internet-Draft                                                  I. Swett
Intended status: Informational                                    Google
Expires: January 9, 2017                                    July 8, 2016

               QUIC Congestion Control And Loss Recovery
                  draft-iyengar-quic-loss-recovery-00

Abstract

   QUIC is a new multiplexed and secure transport atop UDP.  QUIC builds
   on decades of transport and security experience, and implements
   mechanisms that make it attractive as a modern general-purpose
   transport.  QUIC implements the spirit of known TCP loss recovery
   mechanisms, described in RFCs, various Internet-drafts, and also
   those prevalent in the Linux TCP implementation.  This document
   describes QUIC congestion control and loss recovery, and where
   applicable, attributes the TCP equivalent in RFCs, Internet-drafts,
   academic papers, and/or TCP implementations.

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 January 9, 2017.

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
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Iyengar & Swett          Expires January 9, 2017                [Page 1]
Internet-Draft                    QUIC                         July 2016

   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.

1.  Introduction

   QUIC is a new multiplexed and secure transport atop UDP.  QUIC builds
   on decades of transport and security experience, and implements
   mechanisms that make it attractive as a modern general-purpose
   transport.  The QUIC protocol is described in [draft-hamilton-quic-
   transport-protocol].

   QUIC implements the spirit of known TCP loss recovery mechanisms,
   described in RFCs, various Internet-drafts, and also those prevalent
   in the Linux TCP implementation.  This document describes QUIC
   congestion control and loss recovery, and where applicable,
   attributes the TCP equivalent in RFCs, Internet-drafts, academic
   papers, and/or TCP implementations.

   This document first describes parts of the QUIC transmission
   machinery that are necessary to describe the congestion control and
   loss recovery mechanisms.  The document then describes QUIC's default
   congestion control and default loss recovery, followed by a list of
   the various TCP mechanisms that QUIC implements (in spirit) in its
   loss recovery mechanisms.

2.  Design of the QUIC Transmission Machinery

   All transmissions in QUIC are sent with a packet-level header, which
   includes a packet sequence number (referred to below as a packet
   number).  These packet numbers never repeat in the lifetime of a
   connection, and are monotonically increasing, which makes duplicate
   detection trivial.  This fundamental design decision obviates the
   need for disambiguating between transmissions and retransmissions and
   eliminates significant complexity from QUIC's interpretation of TCP
   loss detection mechanisms.

   Every packet can contain several frames; we outline the frames that
   are important to the loss detection and congestion control machinery
   below.

   o  STREAM frames contain application data.  Crypto handshake data is
      also sent as STREAM data, and uses the reliability machinery of
      QUIC underneath.

   o  ACK frames contain acknowledgment information.  QUIC uses a SACK-
      based scheme, where the largest_acked packet number is explicitly

Iyengar & Swett          Expires January 9, 2017                [Page 2]
Internet-Draft                    QUIC                         July 2016

      reported in the ACK frame, and packets with sequence numbers
      lesser than the largest_acked are reported as ACK ranges.  The ACK
      frame also includes a receive timestamp for each packet newly
Show full document text