QUIC
charter-ietf-quic-01

Document Charter QUIC WG (quic)
Title QUIC
Last updated 2016-10-04
State Approved
WG State Active
IESG Responsible AD Spencer Dawkins
Charter Edit AD Spencer Dawkins
Send notices to (None)

Charter
charter-ietf-quic-01

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. 

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.

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.

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

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