draft-ietf-quic-transport-04.txt   draft-ietf-quic-transport-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Thomson, Ed. Intended status: Standards Track M. Thomson, Ed.
Expires: December 15, 2017 Mozilla Expires: December 29, 2017 Mozilla
June 13, 2017 June 27, 2017
QUIC: A UDP-Based Multiplexed and Secure Transport QUIC: A UDP-Based Multiplexed and Secure Transport
draft-ietf-quic-transport-04 draft-ietf-quic-transport-latest
Abstract Abstract
This document defines the core of the QUIC transport protocol. This This document defines the core of the QUIC transport protocol. This
document describes connection establishment, packet format, document describes connection establishment, packet format,
multiplexing and reliability. Accompanying documents describe the multiplexing and reliability. Accompanying documents describe the
cryptographic handshake and loss detection. cryptographic handshake and loss detection.
Note to Readers Note to Readers
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 15, 2017. This Internet-Draft will expire on December 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 3, line 40 skipping to change at page 3, line 40
8.7. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 44 8.7. STREAM_BLOCKED Frame . . . . . . . . . . . . . . . . . . 44
8.8. STREAM_ID_NEEDED Frame . . . . . . . . . . . . . . . . . 45 8.8. STREAM_ID_NEEDED Frame . . . . . . . . . . . . . . . . . 45
8.9. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 45 8.9. RST_STREAM Frame . . . . . . . . . . . . . . . . . . . . 45
8.10. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 46 8.10. PADDING Frame . . . . . . . . . . . . . . . . . . . . . . 46
8.11. PING frame . . . . . . . . . . . . . . . . . . . . . . . 46 8.11. PING frame . . . . . . . . . . . . . . . . . . . . . . . 46
8.12. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 46 8.12. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 46
8.13. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 47 8.13. CONNECTION_CLOSE frame . . . . . . . . . . . . . . . . . 47
8.14. GOAWAY Frame . . . . . . . . . . . . . . . . . . . . . . 48 8.14. GOAWAY Frame . . . . . . . . . . . . . . . . . . . . . . 48
9. Packetization and Reliability . . . . . . . . . . . . . . . . 49 9. Packetization and Reliability . . . . . . . . . . . . . . . . 49
9.1. Special Considerations for PMTU Discovery . . . . . . . . 51 9.1. Special Considerations for PMTU Discovery . . . . . . . . 51
10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 51 10. Streams: QUIC's Data Structuring Abstraction . . . . . . . . 52
10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 52 10.1. Stream Identifiers . . . . . . . . . . . . . . . . . . . 52
10.2. Life of a Stream . . . . . . . . . . . . . . . . . . . . 52 10.2. Life of a Stream . . . . . . . . . . . . . . . . . . . . 53
10.2.1. idle . . . . . . . . . . . . . . . . . . . . . . . . 54 10.2.1. idle . . . . . . . . . . . . . . . . . . . . . . . . 54
10.2.2. open . . . . . . . . . . . . . . . . . . . . . . . . 54 10.2.2. open . . . . . . . . . . . . . . . . . . . . . . . . 54
10.2.3. half-closed (local) . . . . . . . . . . . . . . . . 55 10.2.3. half-closed (local) . . . . . . . . . . . . . . . . 55
10.2.4. half-closed (remote) . . . . . . . . . . . . . . . . 55 10.2.4. half-closed (remote) . . . . . . . . . . . . . . . . 56
10.2.5. closed . . . . . . . . . . . . . . . . . . . . . . . 56 10.2.5. closed . . . . . . . . . . . . . . . . . . . . . . . 56
10.3. Stream Concurrency . . . . . . . . . . . . . . . . . . . 56 10.3. Stream Concurrency . . . . . . . . . . . . . . . . . . . 57
10.4. Sending and Receiving Data . . . . . . . . . . . . . . . 57 10.4. Sending and Receiving Data . . . . . . . . . . . . . . . 57
10.5. Stream Prioritization . . . . . . . . . . . . . . . . . 57 10.5. Stream Prioritization . . . . . . . . . . . . . . . . . 58
11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 58 11. Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 59
11.1. Edge Cases and Other Considerations . . . . . . . . . . 59 11.1. Edge Cases and Other Considerations . . . . . . . . . . 60
11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 60 11.1.1. Response to a RST_STREAM . . . . . . . . . . . . . . 60
11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 60 11.1.2. Data Limit Increments . . . . . . . . . . . . . . . 61
11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 61 11.2. Stream Limit Increment . . . . . . . . . . . . . . . . . 61
11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 61 11.2.1. Blocking on Flow Control . . . . . . . . . . . . . . 61
11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 61 11.3. Stream Final Offset . . . . . . . . . . . . . . . . . . 62
12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 62 12. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 62
12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 62 12.1. Connection Errors . . . . . . . . . . . . . . . . . . . 63
12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 63 12.2. Stream Errors . . . . . . . . . . . . . . . . . . . . . 63
12.3. Error Codes . . . . . . . . . . . . . . . . . . . . . . 63 12.3. Error Codes . . . . . . . . . . . . . . . . . . . . . . 63
13. Security and Privacy Considerations . . . . . . . . . . . . . 67 13. Security and Privacy Considerations . . . . . . . . . . . . . 67
13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 67 13.1. Spoofed ACK Attack . . . . . . . . . . . . . . . . . . . 67
13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 68 13.2. Slowloris Attacks . . . . . . . . . . . . . . . . . . . 68
13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 68 13.3. Stream Fragmentation and Reassembly Attacks . . . . . . 68
13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 68 13.4. Stream Commitment Attack . . . . . . . . . . . . . . . . 69
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 69 14.1. QUIC Transport Parameter Registry . . . . . . . . . . . 69
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
15.1. Normative References . . . . . . . . . . . . . . . . . . 70 15.1. Normative References . . . . . . . . . . . . . . . . . . 70
15.2. Informative References . . . . . . . . . . . . . . . . . 71 15.2. Informative References . . . . . . . . . . . . . . . . . 71
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 72 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 72 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 72
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 72 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 72
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 72 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 72
C.1. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 73 C.1. Since draft-ietf-quic-transport-03 . . . . . . . . . . . 73
C.2. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 74 C.2. Since draft-ietf-quic-transport-02 . . . . . . . . . . . 73
C.3. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 76 C.3. Since draft-ietf-quic-transport-01 . . . . . . . . . . . 74
C.4. Since draft-hamilton-quic-transport-protocol-01 . . . . . 76 C.4. Since draft-ietf-quic-transport-00 . . . . . . . . . . . 76
C.5. Since draft-hamilton-quic-transport-protocol-01 . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
QUIC is a multiplexed and secure transport protocol that runs on top QUIC is a multiplexed and secure transport protocol that runs on top
of UDP. QUIC aims to provide a flexible set of features that allow of UDP. QUIC aims to provide a flexible set of features that allow
it to be a general-purpose transport for multiple applications. it to be a general-purpose transport for multiple applications.
QUIC implements techniques learned from experience with TCP, SCTP and QUIC implements techniques learned from experience with TCP, SCTP and
other transport protocols. Using UDP as the substrate, QUIC seeks to other transport protocols. Using UDP as the substrate, QUIC seeks to
skipping to change at page 8, line 14 skipping to change at page 8, line 14
early handshake packets, such as the Version Negotiation packet, are early handshake packets, such as the Version Negotiation packet, are
not encrypted, but information sent in these unencrypted handshake not encrypted, but information sent in these unencrypted handshake
packets is later verified as part of cryptographic processing. packets is later verified as part of cryptographic processing.
PUBLIC_RESET packets that reset a connection are currently not PUBLIC_RESET packets that reset a connection are currently not
authenticated. authenticated.
3.6. Connection Migration and Resilience to NAT Rebinding 3.6. Connection Migration and Resilience to NAT Rebinding
QUIC connections are identified by a 64-bit Connection ID, randomly QUIC connections are identified by a 64-bit Connection ID, randomly
generated by the client. QUIC's consistent connection ID allows generated by the server. QUIC's consistent connection ID allows
connections to survive changes to the client's IP and port, such as connections to survive changes to the client's IP and port, such as
those caused by NAT rebindings or by the client changing network those caused by NAT rebindings or by the client changing network
connectivity to a new address. QUIC provides automatic cryptographic connectivity to a new address. QUIC provides automatic cryptographic
verification of a rebound client, since the client continues to use verification of a rebound client, since the client continues to use
the same session key for encrypting and decrypting packets. The the same session key for encrypting and decrypting packets. The
consistent connection ID can be used to allow migration of the consistent connection ID can be used to allow migration of the
connection to a new server IP address as well, since the Connection connection to a new server IP address as well, since the Connection
ID remains consistent across changes in the client's and the server's ID remains consistent across changes in the client's and the server's
network addresses. network addresses.
skipping to change at page 19, line 19 skipping to change at page 19, line 19
highest received packet number plus one. For example, if the highest highest received packet number plus one. For example, if the highest
successfully authenticated packet had a packet number of 0xaa82f30e, successfully authenticated packet had a packet number of 0xaa82f30e,
then a packet containing a 16-bit value of 0x1f94 will be decoded as then a packet containing a 16-bit value of 0x1f94 will be decoded as
0xaa831f94. 0xaa831f94.
The sender MUST use a packet number size able to represent more than The sender MUST use a packet number size able to represent more than
twice as large a range than the difference between the largest twice as large a range than the difference between the largest
acknowledged packet and packet number being sent. A peer receiving acknowledged packet and packet number being sent. A peer receiving
the packet will then correctly decode the packet number, unless the the packet will then correctly decode the packet number, unless the
packet is delayed in transit such that it arrives after many higher- packet is delayed in transit such that it arrives after many higher-
numbered packets have been received. An endpoint MAY use a larger numbered packets have been received. An endpoint SHOULD use a large
packet number size to safeguard against such reordering. enough packet number encoding to allow the packet number to be
recovered even if the packet arrives after packets that are sent
afterwards.
As a result, the size of the packet number encoding is at least one As a result, the size of the packet number encoding is at least one
more than the base 2 logarithm of the number of contiguous more than the base 2 logarithm of the number of contiguous
unacknowledged packet numbers, including the new packet. unacknowledged packet numbers, including the new packet.
For example, if an endpoint has received an acknowledgment for packet For example, if an endpoint has received an acknowledgment for packet
0x6afa2f, sending a packet with a number of 0x6b4264 requires a 0x6afa2f, sending a packet with a number of 0x6b4264 requires a
16-bit or larger packet number encoding; whereas a 32-bit packet 16-bit or larger packet number encoding; whereas a 32-bit packet
number is needed to send a packet with a number of 0x6bc107. number is needed to send a packet with a number of 0x6bc107.
skipping to change at page 26, line 34 skipping to change at page 26, line 34
} TransportParameter; } TransportParameter;
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: case client_hello:
QuicVersion negotiated_version; QuicVersion negotiated_version;
QuicVersion initial_version; QuicVersion initial_version;
case encrypted_extensions: case encrypted_extensions:
QuicVersion supported_versions<2..2^8-4>; QuicVersion supported_versions<2..2^8-4>;
case new_session_ticket:
struct {};
}; };
TransportParameter parameters<30..2^16-1>; TransportParameter parameters<30..2^16-1>;
} TransportParameters; } TransportParameters;
Figure 6: Definition of TransportParameters Figure 6: Definition of TransportParameters
The "extension_data" field of the quic_transport_parameters extension The "extension_data" field of the quic_transport_parameters extension
defined in [QUIC-TLS] contains a TransportParameters value. TLS defined in [QUIC-TLS] contains a TransportParameters value. TLS
encoding rules are therefore used to encode the transport parameters. encoding rules are therefore used to encode the transport parameters.
skipping to change at page 29, line 39 skipping to change at page 29, line 42
If the initial version is different from the negotiated_version, a If the initial version is different from the negotiated_version, a
stateless server MUST check that it would have sent a version stateless server MUST check that it would have sent a version
negotiation packet if it had received a packet with the indicated negotiation packet if it had received a packet with the indicated
initial_version. If a server would have accepted the version initial_version. If a server would have accepted the version
included in the initial_version and the value differs from the value included in the initial_version and the value differs from the value
of negotiated_version, the server MUST terminate the connection with of negotiated_version, the server MUST terminate the connection with
a QUIC_VERSION_NEGOTIATION_MISMATCH error. a QUIC_VERSION_NEGOTIATION_MISMATCH error.
The server includes a list of versions that it would send in any The server includes a list of versions that it would send in any
version negotiation packet (Section 5.3) in supported_versions. This version negotiation packet (Section 5.3) in supported_versions. The
value is set even if it did not send a version negotiation packet. server populates this field even if it did not send a version
negotiation packet. This field is absent if the parameters are
included in a NewSessionTicket message.
The client can validate that the negotiated_version is included in The client can validate that the negotiated_version is included in
the supported_versions list and - if version negotiation was the supported_versions list and - if version negotiation was
performed - that it would have selected the negotiated version. A performed - that it would have selected the negotiated version. A
client MUST terminate the connection with a client MUST terminate the connection with a
QUIC_VERSION_NEGOTIATION_MISMATCH error code if the QUIC_VERSION_NEGOTIATION_MISMATCH error code if the
negotiated_version value is not included in the supported_versions negotiated_version value is not included in the supported_versions
list. A client MUST terminate with a list. A client MUST terminate with a
QUIC_VERSION_NEGOTIATION_MISMATCH error code if version negotiation QUIC_VERSION_NEGOTIATION_MISMATCH error code if version negotiation
occurred but it would have selected a different version based on the occurred but it would have selected a different version based on the
skipping to change at page 36, line 32 skipping to change at page 36, line 38
Stream ID: The stream ID of the stream (see Section 10.1). Stream ID: The stream ID of the stream (see Section 10.1).
Offset: A variable-sized unsigned number specifying the byte offset Offset: A variable-sized unsigned number specifying the byte offset
in the stream for the data in this STREAM frame. When the offset in the stream for the data in this STREAM frame. When the offset
length is 0, the offset is 0. The first byte in the stream has an length is 0, the offset is 0. The first byte in the stream has an
offset of 0. The largest offset delivered on a stream - the sum offset of 0. The largest offset delivered on a stream - the sum
of the re-constructed offset and data length - MUST be less than of the re-constructed offset and data length - MUST be less than
2^64. 2^64.
Stream Data: The bytes from the designated stream to be delivered.
Data Length: An optional 16-bit unsigned number specifying the Data Length: An optional 16-bit unsigned number specifying the
length of the Stream Data field in this STREAM frame. This field length of the Stream Data field in this STREAM frame. This field
is present when the "D" bit is set to 1. is present when the "D" bit is set to 1.
A STREAM frame MUST have either non-zero data length or the FIN bit Stream Data: The bytes from the designated stream to be delivered.
A stream frame's payload MUST NOT be empty, unless the FIN bit is
set. When the FIN flag is sent on an empty STREAM frame, the offset set. When the FIN flag is sent on an empty STREAM frame, the offset
in the STREAM frame MUST be one greater than the last data byte sent in the STREAM frame MUST be one greater than the last data byte sent
on this stream. on this stream.
Stream multiplexing is achieved by interleaving STREAM frames from Stream multiplexing is achieved by interleaving STREAM frames from
multiple streams into one or more QUIC packets. A single QUIC packet multiple streams into one or more QUIC packets. A single QUIC packet
can include multiple STREAM frames from one or more streams. can include multiple STREAM frames from one or more streams.
Implementation note: One of the benefits of QUIC is avoidance of Implementation note: One of the benefits of QUIC is avoidance of
head-of-line blocking across multiple streams. When a packet loss head-of-line blocking across multiple streams. When a packet loss
skipping to change at page 37, line 35 skipping to change at page 37, line 41
send a PING frame once per RTT to solicit an acknowledgment. send a PING frame once per RTT to solicit an acknowledgment.
To limit receiver state or the size of ACK frames, a receiver MAY To limit receiver state or the size of ACK frames, a receiver MAY
limit the number of ACK blocks it sends. A receiver can do this even limit the number of ACK blocks it sends. A receiver can do this even
without receiving acknowledgment of its ACK frames, with the without receiving acknowledgment of its ACK frames, with the
knowledge this could cause the sender to unnecessarily retransmit knowledge this could cause the sender to unnecessarily retransmit
some data. When this is necessary, the receiver SHOULD acknowledge some data. When this is necessary, the receiver SHOULD acknowledge
newly received packets and stop acknowledging packets received in the newly received packets and stop acknowledging packets received in the
past. past.
Unlike TCP SACKs, QUIC ACK blocks are cumulative and therefore Unlike TCP SACKs, QUIC ACK blocks are irrevocable. Once a packet has
irrevocable. Once a packet has been acknowledged, even if it does been acknowledged, even if it does not appear in a future ACK frame,
not appear in a future ACK frame, it is assumed to be acknowledged. it remains acknowledged.
QUIC ACK frames contain a timestamp section with up to 255 QUIC ACK frames contain a timestamp section with up to 255
timestamps. Timestamps enable better congestion control, but are not timestamps. Timestamps enable better congestion control, but are not
required for correct loss recovery, and old timestamps are less required for correct loss recovery, and old timestamps are less
valuable, so it is not guaranteed every timestamp will be received by valuable, so it is not guaranteed every timestamp will be received by
the sender. A receiver SHOULD send a timestamp exactly once for each the sender. A receiver SHOULD send a timestamp exactly once for each
received packet containing retransmittable frames. A receiver MAY received packet containing retransmittable frames. A receiver MAY
send timestamps for non-retransmittable packets. A receiver MUST not send timestamps for non-retransmittable packets. A receiver MUST not
send timestamps in unprotected packets. send timestamps in unprotected packets.
skipping to change at page 38, line 15 skipping to change at page 38, line 20
effectively provides up to 8 bits of efficient entropy on demand, effectively provides up to 8 bits of efficient entropy on demand,
which should be adequate protection against most opportunistic which should be adequate protection against most opportunistic
acknowledgement attacks. acknowledgement attacks.
The type byte for a ACK frame contains embedded flags, and is The type byte for a ACK frame contains embedded flags, and is
formatted as "101NLLMM". These bits are parsed as follows: formatted as "101NLLMM". These bits are parsed as follows:
o The first three bits must be set to 101 indicating that this is an o The first three bits must be set to 101 indicating that this is an
ACK frame. ACK frame.
o The "N" bit indicates whether the frame has more than 1 range of o The "N" bit indicates whether the frame contains a Num Blocks
acknowledged packets (i.e., whether the ACK Block Section contains field.
a Num Blocks field).
o The two "LL" bits encode the length of the Largest Acknowledged o The two "LL" bits encode the length of the Largest Acknowledged
field. The values 00, 01, 02, and 03 indicate lengths of 8, 16, field. The values 00, 01, 02, and 03 indicate lengths of 8, 16,
32, and 48 bits respectively. 32, and 64 bits respectively.
o The two "MM" bits encode the length of the ACK Block Length o The two "MM" bits encode the length of the ACK Block Length
fields. The values 00, 01, 02, and 03 indicate lengths of 8, 16, fields. The values 00, 01, 02, and 03 indicate lengths of 8, 16,
32, and 48 bits respectively. 32, and 64 bits respectively.
An ACK frame is shown below. An ACK frame is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[Num Blocks(8)]| NumTS (8) | |[Num Blocks(8)]| NumTS (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Largest Acknowledged (8/16/32/48) ... | Largest Acknowledged (8/16/32/64) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Delay (16) | | ACK Delay (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK Block Section (*) ... | ACK Block Section (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Section (*) ... | Timestamp Section (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: ACK Frame Format Figure 8: ACK Frame Format
skipping to change at page 39, line 33 skipping to change at page 39, line 37
The ACK Block Section contains between one and 256 blocks of packet The ACK Block Section contains between one and 256 blocks of packet
numbers which have been successfully received. If the Num Blocks numbers which have been successfully received. If the Num Blocks
field is absent, only the First ACK Block length is present in this field is absent, only the First ACK Block length is present in this
section. Otherwise, the Num Blocks field indicates how many section. Otherwise, the Num Blocks field indicates how many
additional blocks follow the First ACK Block Length field. additional blocks follow the First ACK Block Length field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First ACK Block Length (8/16/32/48) ... | First ACK Block Length (8/16/32/64) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap 1 (8)] | [ACK Block 1 Length (8/16/32/48)] ... | [Gap 1 (8)] | [ACK Block 1 Length (8/16/32/64)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap 2 (8)] | [ACK Block 2 Length (8/16/32/48)] ... | [Gap 2 (8)] | [ACK Block 2 Length (8/16/32/64)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Gap N (8)] | [ACK Block N Length (8/16/32/48)] ... | [Gap N (8)] | [ACK Block N Length (8/16/32/64)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: ACK Block Section Figure 9: ACK Block Section
The fields in the ACK Block Section are: The fields in the ACK Block Section are:
First ACK Block Length: An unsigned packet number delta that First ACK Block Length: An unsigned packet number delta that
indicates the number of contiguous additional packets being indicates the number of contiguous additional packets being
acknowledged starting at the Largest Acknowledged. acknowledged starting at the Largest Acknowledged.
skipping to change at page 46, line 4 skipping to change at page 46, line 16
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (32) | | Stream ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (32) | | Error Code (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Final Offset (64) + + Final Offset (64) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are: The fields are:
Stream ID: The 32-bit Stream ID of the stream being terminated.
Error code: A 32-bit error code which indicates why the stream is Error code: A 32-bit error code which indicates why the stream is
being closed. being closed.
Stream ID: The 32-bit Stream ID of the stream being terminated.
Final offset: A 64-bit unsigned integer indicating the absolute byte Final offset: A 64-bit unsigned integer indicating the absolute byte
offset of the end of data written on this stream by the RST_STREAM offset of the end of data written on this stream by the RST_STREAM
sender. sender.
8.10. PADDING Frame 8.10. PADDING Frame
The PADDING frame (type=0x00) has no semantic value. PADDING frames The PADDING frame (type=0x00) has no semantic value. PADDING frames
can be used to increase the size of a packet. Padding can be used to can be used to increase the size of a packet. Padding can be used to
increase an initial client packet to the minimum required size, or to increase an initial client packet to the minimum required size, or to
provide protection against traffic analysis for protected packets. provide protection against traffic analysis for protected packets.
skipping to change at page 50, line 37 skipping to change at page 50, line 46
When a packet is detected as lost, the sender re-sends any frames as When a packet is detected as lost, the sender re-sends any frames as
necessary: necessary:
o All application data sent in STREAM frames MUST be retransmitted, o All application data sent in STREAM frames MUST be retransmitted,
unless the endpoint has sent a RST_STREAM for that stream. When unless the endpoint has sent a RST_STREAM for that stream. When
an endpoint sends a RST_STREAM frame, data outstanding on that an endpoint sends a RST_STREAM frame, data outstanding on that
stream SHOULD NOT be retransmitted, since subsequent data on this stream SHOULD NOT be retransmitted, since subsequent data on this
stream is expected to not be delivered by the receiver. stream is expected to not be delivered by the receiver.
o ACK and PADDING frames MUST NOT be retransmitted. ACK frames are o ACK and PADDING frames MUST NOT be retransmitted. ACK frames
cumulative, so new frames containing updated information will be containing updated information will be sent as described in
sent as described in Section 8.2. Section 8.2.
o All other frames MUST be retransmitted. o All other frames MUST be retransmitted.
Upon detecting losses, a sender MUST take appropriate congestion Upon detecting losses, a sender MUST take appropriate congestion
control action. The details of loss detection and congestion control control action. The details of loss detection and congestion control
are described in [QUIC-RECOVERY]. are described in [QUIC-RECOVERY].
A packet MUST NOT be acknowledged until packet protection has been A packet MUST NOT be acknowledged until packet protection has been
successfully removed and all frames contained in the packet have been successfully removed and all frames contained in the packet have been
processed. For STREAM frames, this means the data has been queued processed. For STREAM frames, this means the data has been queued
skipping to change at page 71, line 19 skipping to change at page 71, line 23
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <http://www.rfc-editor.org/info/rfc4821>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
15.2. Informative References 15.2. Informative References
[EARLY-DESIGN] [EARLY-DESIGN]
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>.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
skipping to change at page 73, line 5 skipping to change at page 73, line 5
discussions and public ones on the quic@ietf.org and proto- discussions and public ones on the quic@ietf.org and proto-
quic@chromium.org mailing lists. Our thanks to all. quic@chromium.org mailing lists. Our thanks to all.
Appendix C. Change Log Appendix C. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
C.1. Since draft-ietf-quic-transport-02 C.1. Since draft-ietf-quic-transport-03
o Change STREAM and RST_STREAM layout
o Add MAX_STREAM_ID settings
C.2. Since draft-ietf-quic-transport-02
o The size of the initial packet payload has a fixed minimum (#267, o The size of the initial packet payload has a fixed minimum (#267,
#472) #472)
o Define when Version Negotiation packets are ignored (#284, #294, o Define when Version Negotiation packets are ignored (#284, #294,
#241, #143, #474) #241, #143, #474)
o The 64-bit FNV-1a algorithm is used for integrity protection of o The 64-bit FNV-1a algorithm is used for integrity protection of
unprotected packets (#167, #480, #481, #517) unprotected packets (#167, #480, #481, #517)
skipping to change at page 73, line 44 skipping to change at page 73, line 50
* WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450) * WINDOW_UPDATE split into MAX_DATA and MAX_STREAM_DATA (#450)
* BLOCKED split to match WINDOW_UPDATE split (#454) * BLOCKED split to match WINDOW_UPDATE split (#454)
* Define STREAM_ID_NEEDED frame (#455) * Define STREAM_ID_NEEDED frame (#455)
o A NEW_CONNECTION_ID frame supports connection migration without o A NEW_CONNECTION_ID frame supports connection migration without
linkability (#232, #491, #496) linkability (#232, #491, #496)
o Transport parameters for 0-RTT are retained from a previous o Transport parameters for 0-RTT are retained from a previous
connection (#512) connection (#405, #513, #512)
* A client in 0-RTT no longer required to reset excess streams * A client in 0-RTT no longer required to reset excess streams
(#425, #479) (#425, #479)
o Expanded security considerations (#440, #444, #445, #448) o Expanded security considerations (#440, #444, #445, #448)
C.2. Since draft-ietf-quic-transport-01 C.3. Since draft-ietf-quic-transport-01
o Defined short and long packet headers (#40, #148, #361) o Defined short and long packet headers (#40, #148, #361)
o Defined a versioning scheme and stable fields (#51, #361) o Defined a versioning scheme and stable fields (#51, #361)
o Define reserved version values for "greasing" negotiation (#112, o Define reserved version values for "greasing" negotiation (#112,
#278) #278)
o The initial packet number is randomized (#35, #283) o The initial packet number is randomized (#35, #283)
skipping to change at page 76, line 5 skipping to change at page 76, line 8
o Remove error code and reason phrase from GOAWAY (#352, #355) o Remove error code and reason phrase from GOAWAY (#352, #355)
o GOAWAY includes a final stream number for both directions (#347) o GOAWAY includes a final stream number for both directions (#347)
o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a o Error codes for RST_STREAM and CONNECTION_CLOSE are now at a
consistent offset (#249) consistent offset (#249)
o Defined priority as the responsibility of the application protocol o Defined priority as the responsibility of the application protocol
(#104, #303) (#104, #303)
C.3. Since draft-ietf-quic-transport-00 C.4. Since draft-ietf-quic-transport-00
o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag o Replaced DIVERSIFICATION_NONCE flag with KEY_PHASE flag
o Defined versioning o Defined versioning
o Reworked description of packet and frame layout o Reworked description of packet and frame layout
o Error code space is divided into regions for each component o Error code space is divided into regions for each component
o Use big endian for all numeric values o Use big endian for all numeric values
C.4. Since draft-hamilton-quic-transport-protocol-01 C.5. Since draft-hamilton-quic-transport-protocol-01
o Adopted as base for draft-ietf-quic-tls o Adopted as base for draft-ietf-quic-tls
o Updated authors/editors list o Updated authors/editors list
o Added IANA Considerations section o Added IANA Considerations section
o Moved Contributors and Acknowledgments to appendices o Moved Contributors and Acknowledgments to appendices
Authors' Addresses Authors' Addresses
 End of changes. 38 change blocks. 
52 lines changed or deleted 65 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/