The information below is for a proposed recharter. The current approved charter is version 01
Document Charter QUIC WG (quic)
Title QUIC
Last updated 2020-01-27
State Approved
WG State Active
IESG Responsible AD Magnus Westerlund
Charter Edit AD Magnus Westerlund
Send notices to (None)


The QUIC working group will provide standards-track specifications for a
UDP-based, stream-multiplexing, encrypted transport protocol, based on
pre-standardization implementation and deployment experience.

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, 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, or working elsewhere.

The fourth focus area will be on extensions to core protocol facilities, to
enable datagram delivery, version negotiation, and multipath capabilities.
Other extensions are out of the scope of this charter.

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.
Additionally, the Working Group will delivery a mechanism to assist load
balancers in their handling of QUIC.

Current practices for network management of transport protocols include 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, or enable them in the same way as they are enabled by TCP when
used with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, reflecting the tensions described in
RFC 7258.

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.

The QUIC working group will work closely with the HTTPbis working group,
especially on the QUIC mapping for HTTP/2.