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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2015-06-17
Replaced by draft-hamilton-early-deployment-quic
Stream (None)
Intended RFC status (None)
Formats plain text pdf html 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: December 19, 2015                                 June 17, 2015

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

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 December 19, 2015.

Copyright Notice

   Copyright (c) 2015 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 December 19, 2015               [Page 1]
Internet-Draft                    QUIC                         June 2015

   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.  Contributors

   This document and protocol is the outcome of work by several
   engineers at Google.

2.  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 [1].

3.  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.

Iyengar & Swett         Expires December 19, 2015               [Page 2]
Internet-Draft                    QUIC                         June 2015

   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
Show full document text