draft-ietf-quic-transport-22.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: January 10, 2020 Mozilla Expires: January 17, 2020 Mozilla
July 9, 2019 July 16, 2019
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-22 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion Accompanying documents describe QUIC's loss detection and congestion
control and the use of TLS for key negotiation. control and the use of TLS for key negotiation.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2020. This Internet-Draft will expire on January 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 48 skipping to change at page 8, line 48
x (i) ...: Indicates that x uses the variable-length encoding in x (i) ...: Indicates that x uses the variable-length encoding in
Section 16 Section 16
x (*) ...: Indicates that x is variable-length x (*) ...: Indicates that x is variable-length
2. Streams 2. Streams
Streams in QUIC provide a lightweight, ordered byte-stream Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application. Streams can be unidirectional or abstraction to an application. Streams can be unidirectional or
bidirecational. An alternative view of QUIC unidirectional streams bidirectional. An alternative view of QUIC unidirectional streams is
is a "message" abstraction of practically unlimited length. a "message" abstraction of practically unlimited length.
Streams can be created by sending data. Other processes associated Streams can be created by sending data. Other processes associated
with stream management - ending, cancelling, and managing flow with stream management - ending, cancelling, and managing flow
control - are all designed to impose minimal overheads. For control - are all designed to impose minimal overheads. For
instance, a single STREAM frame (Section 19.8) can open, carry data instance, a single STREAM frame (Section 19.8) can open, carry data
for, and close a stream. Streams can also be long-lived and can last for, and close a stream. Streams can also be long-lived and can last
the entire duration of a connection. the entire duration of a connection.
Streams can be created by either endpoint, can concurrently send data Streams can be created by either endpoint, can concurrently send data
interleaved with other streams, and can be cancelled. QUIC does not interleaved with other streams, and can be cancelled. QUIC does not
skipping to change at page 82, line 51 skipping to change at page 82, line 51
of byte 0 contain a packet type. Packet types are listed in of byte 0 contain a packet type. Packet types are listed in
Table 5. Table 5.
Type-Specific Bits (X): The lower four bits (those with a mask of Type-Specific Bits (X): The lower four bits (those with a mask of
0x0f) of byte 0 are type-specific. 0x0f) of byte 0 are type-specific.
Version: The QUIC Version is a 32-bit field that follows the first Version: The QUIC Version is a 32-bit field that follows the first
byte. This field indicates which version of QUIC is in use and byte. This field indicates which version of QUIC is in use and
determines how the rest of the protocol fields are interpreted. determines how the rest of the protocol fields are interpreted.
DCID Len: The byte following the version contains the lengths of the DCID Len: The byte following the version contains the length in
two connection ID fields that follow it. These lengths are bytes of the Destination Connection ID field that follows it.
encoded as two 4-bit unsigned integers. The Destination
Connection ID Length (DCIL) field occupies the 4 high bits of the This length is encoded as an 8-bit unsigned integer. In QUIC
byte and the Source Connection ID Length (SCIL) field occupies the version 1, this value MUST NOT exceed 20. Endpoints that receive
4 low bits of the byte. An encoded length of 0 indicates that the a version 1 long header with a value larger than 20 MUST drop the
connection ID is also 0 bytes in length. Non-zero encoded lengths packet. Servers SHOULD be able to read longer connection IDs from
are increased by 3 to get the full length of the connection ID, other QUIC versions in order to properly form a version
producing a length between 4 and 18 bytes inclusive. For example, negotiation packet.
a byte with the value 0x50 describes an 8-byte Destination
Connection ID and a zero-length Source Connection ID.
Destination Connection ID: The Destination Connection ID field Destination Connection ID: The Destination Connection ID field
follows the DCID Len and is between 0 and 20 bytes in length. follows the DCID Len and is between 0 and 20 bytes in length.
Section 7.2 describes the use of this field in more detail. Section 7.2 describes the use of this field in more detail.
SCID Len: The byte following the Destination Connection ID contains SCID Len: The byte following the Destination Connection ID contains
the length in bytes of the Source Connection ID field that follows the length in bytes of the Source Connection ID field that follows
it. This length is encoded as a 8-bit unsigned integer. In QUIC it. This length is encoded as a 8-bit unsigned integer. In QUIC
version 1, this value MUST NOT exceed 20 bytes. Endpoints that version 1, this value MUST NOT exceed 20 bytes. Endpoints that
receive a version 1 long header with a value larger than 20 MUST receive a version 1 long header with a value larger than 20 MUST
skipping to change at page 130, line 14 skipping to change at page 130, line 14
23.1. Normative References 23.1. Normative References
[DPLPMTUD] [DPLPMTUD]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08 Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-08
(work in progress), June 2019. (work in progress), June 2019.
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", draft-ietf-quic-recovery-22 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[QUIC-TLS] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using Transport Thomson, M., Ed. and S. Turner, Ed., "Using Transport
Layer Security (TLS) to Secure QUIC", draft-ietf-quic- Layer Security (TLS) to Secure QUIC", draft-ietf-quic-tls-
tls-22 (work in progress). latest (work in progress).
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 131, line 50 skipping to change at page 131, line 50
Roskind, J., "QUIC: Multiplexed Transport Over UDP", Roskind, J., "QUIC: Multiplexed Transport Over UDP",
December 2013, <https://goo.gl/dMVtFi>. December 2013, <https://goo.gl/dMVtFi>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-05 (work in progress). draft-ietf-quic-invariants-latest (work in progress).
[QUIC-MANAGEABILITY] [QUIC-MANAGEABILITY]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-05 Transport Protocol", draft-ietf-quic-manageability-05
(work in progress), July 2019. (work in progress), July 2019.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
 End of changes. 8 change blocks. 
22 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/