There is emerging implementation and deployment experience with QUIC, a UDP-based protocol that provides a stream-multiplexing encrypted transport. Based on that implementation and deployment experience, the QUIC working group will provide a standards track specification 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. The working group will consider deployment and manageability considerations for the protocol. Manageability includes inner transport header format, parsability in flow export, ACL application, hashing of "flows" and directional signaling of flow installation and tear down. 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 testing and development 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 Statement, describing how, and under what circumstances, QUIC may be safely used, and describing deployment and manageability implications of the protocol. 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.