* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Quic Status Pages

QUIC (Active WG)
Tsv Area: Mirja K├╝hlewind, Spencer Dawkins | 2016-Oct-04 —  
Chairs
 
 


2016-10-04 charter

QUIC (quic)
-----------

 Charter

 Current Status: Active

 Chairs:
     Lars Eggert <lars@netapp.com>
     Mark Nottingham <mnot@mnot.net>

 Transport Area Directors:
     Spencer Dawkins <spencerdawkins.ietf@gmail.com>
     Mirja K├╝hlewind <ietf@kuehlewind.net>

 Transport Area Advisor:
     Spencer Dawkins <spencerdawkins.ietf@gmail.com>

 Mailing Lists:
     General Discussion: quic@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/quic
     Archive:            https://mailarchive.ietf.org/arch/browse/quic/

Description of Working Group:

  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.

Goals and Milestones:
  Feb 2017 - Working group adoption of Core Protocol document
  Feb 2017 - Working group adoption of Loss detection and Congestion Control document
  Feb 2017 - Working group adoption of TLS 1.3 mapping document
  Feb 2017 - Working group adoption of HTTP/2 mapping document
  Feb 2017 - Working group adoption of QUIC Applicability and Manageability Statement
  Nov 2017 - Working group adoption of Multipath extension document
  Mar 2018 - Core Protocol document to IESG
  Mar 2018 - Loss detection and Congestion Control document to IESG
  Mar 2018 - TLS 1.3 Mapping document to IESG
  Nov 2018 - HTTP/2 mapping document to IESG
  Nov 2018 - QUIC Applicability and Manageability Statement to IESG
  May 2019 - Multipath extension document to IESG


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/quic/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -