IETF Proceedings

IETF-96 Proceedings

Introduction | Area, Working Goup & BoF Reports | Plenaries | Training | Internet Research Task Force

QUIC (quic) (WG)

Minutes | Jabber Logs | Mailing List Archives

Additional information is available at tools.ietf.org/wg/quic

Chair(s):

Transport Area Area Director(s):

Assigned Area Director

Spencer Dawkins

Recordings:

Meeting Slides:

Blue Sheets:

bluesheets-96-quic-01.pdf

No Current Internet-Drafts

No Request for Comments

Charter (as of 2016-09-14):

The QUIC working group will provide a standards-track specification for a UDP-
based, stream-multiplexing, encrypted transport protocol, based on pre-
standardization implementation and deployment experience, and generalizing the
design described in draft-hamilton-quic-transport-protocol, draft-iyengar-quic-
loss-recovery, draft-shade-quic-http2-mapping, and draft-thomson-quic-tls.

Key goals for QUIC are:

- Minimizing connection establishment and overall transport latency
for applications, starting with HTTP/2;
- Providing multiplexing without head-of-line blocking;
- Requiring only changes to path endpoints to enable deployment;
- Enabling multipath and forward error correction extensions; and
- Providing always-secure transport, using TLS 1.3 by default.

The work of the group will have five main focus areas, corresponding to five
core deliverables.

The first of these is the core transport work, which will describe the wire
format, along with the mechanisms for connection establishment, stream
multiplexing, data reliability, loss detection and recovery, congestion control,
version negotiation, and options negotiation. Work on congestion control will
describe use of a standardized congestion controller as a default scheme for
QUIC. Defining new congestion control schemes is explicitly out of scope for
this group. QUIC is expected to support rapid, distributed development and
testing of features.

The second of these focus areas is security. This work will describe how the
protocol uses TLS 1.3 for key negotiation and will also describe how those keys
are used to provide confidentiality and integrity protection of both application
data and QUIC headers. This work will ensure that QUIC has security and privacy
properties that are at least as good as a stack composed of TLS 1.3 using TCP
(or MPTCP when using multipath).

The third focus area will describe mappings between specific application
protocols and the transport facilities of QUIC. The first mapping will be a
description of HTTP/2 semantics using QUIC, specifically with the goal of
minimizing web latency using QUIC. This mapping will accommodate the extension
mechanisms defined in the HTTP/2 specification. Upon completion of that mapping,
additional protocols may be added by updating this charter to include them.

The fourth focus area will extend core protocol facilities to enable multipath
capabilities for connection migration between paths and load sharing
across multiple paths.

The fifth focus area will provide an Applicability and Manageability Statement,
describing how, and under what circumstances, QUIC may be safely used, and
describing deployment and manageability implications of the protocol. The
working group will consider the impact of the protocol on network management
practices, in line with RFC 7258. Current network management of transport
protocols includes the ability to apply access control lists (ACLs), hashing of
flows for equal-cost multipath routing (ECMP), directional signaling of flows,
signaling of flow setup and teardown, and the ability to export information
about flows for accounting purposes. The QUIC protocol need not be defined to
enable each of these abilities in the same way they are presently enabled for
TCP, but the working group must consider the tradeoffs between manageability and
other goals.

Extensions that will support partial reliability, and negotiation and use of
Forward Error Correction schemes, are out of scope in this version of the
working group charter.

Note that consensus is required both for changes to the current protocol
mechanisms and retention of current mechanisms. In particular, because something
is in the initial document set does not imply that there is consensus around the
feature or around how it is specified.

QUIC will work closely with the HTTPbis working group, especially on the third
focus area.

In order to achieve the milestones set out below, the group expects to make
extensive use of interim meetings, especially in its first year.