draft-ietf-quic-recovery-32.txt   draft-ietf-quic-recovery-33.txt 
QUIC J. Iyengar, Ed. QUIC J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track I. Swett, Ed. Intended status: Standards Track I. Swett, Ed.
Expires: 23 April 2021 Google Expires: 16 June 2021 Google
20 October 2020 13 December 2020
QUIC Loss Detection and Congestion Control QUIC Loss Detection and Congestion Control
draft-ietf-quic-recovery-32 draft-ietf-quic-recovery-33
Abstract Abstract
This document describes loss detection and congestion control This document describes loss detection and congestion control
mechanisms for QUIC. mechanisms for QUIC.
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
mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
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 23 April 2021. This Internet-Draft will expire on 16 June 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Design of the QUIC Transmission Machinery . . . . . . . . . . 5 3. Design of the QUIC Transmission Machinery . . . . . . . . . . 5
4. Relevant Differences Between QUIC and TCP . . . . . . . . . . 6 4. Relevant Differences Between QUIC and TCP . . . . . . . . . . 5
4.1. Separate Packet Number Spaces . . . . . . . . . . . . . . 6 4.1. Separate Packet Number Spaces . . . . . . . . . . . . . . 6
4.2. Monotonically Increasing Packet Numbers . . . . . . . . . 6 4.2. Monotonically Increasing Packet Numbers . . . . . . . . . 6
4.3. Clearer Loss Epoch . . . . . . . . . . . . . . . . . . . 7 4.3. Clearer Loss Epoch . . . . . . . . . . . . . . . . . . . 6
4.4. No Reneging . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. No Reneging . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. More ACK Ranges . . . . . . . . . . . . . . . . . . . . . 7 4.5. More ACK Ranges . . . . . . . . . . . . . . . . . . . . . 7
4.6. Explicit Correction For Delayed Acknowledgements . . . . 7 4.6. Explicit Correction For Delayed Acknowledgements . . . . 7
4.7. Probe Timeout Replaces RTO and TLP . . . . . . . . . . . 7 4.7. Probe Timeout Replaces RTO and TLP . . . . . . . . . . . 7
4.8. The Minimum Congestion Window is Two Packets . . . . . . 8 4.8. The Minimum Congestion Window is Two Packets . . . . . . 8
5. Estimating the Round-Trip Time . . . . . . . . . . . . . . . 8 5. Estimating the Round-Trip Time . . . . . . . . . . . . . . . 8
5.1. Generating RTT samples . . . . . . . . . . . . . . . . . 8 5.1. Generating RTT samples . . . . . . . . . . . . . . . . . 8
5.2. Estimating min_rtt . . . . . . . . . . . . . . . . . . . 9 5.2. Estimating min_rtt . . . . . . . . . . . . . . . . . . . 9
5.3. Estimating smoothed_rtt and rttvar . . . . . . . . . . . 10 5.3. Estimating smoothed_rtt and rttvar . . . . . . . . . . . 10
6. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 12 6. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Acknowledgement-Based Detection . . . . . . . . . . . . . 12 6.1. Acknowledgement-Based Detection . . . . . . . . . . . . . 12
6.1.1. Packet Threshold . . . . . . . . . . . . . . . . . . 13 6.1.1. Packet Threshold . . . . . . . . . . . . . . . . . . 13
6.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 13 6.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 13
6.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 14
6.2.2. Handshakes and New Paths . . . . . . . . . . . . . . 16 6.2.2. Handshakes and New Paths . . . . . . . . . . . . . . 16
6.2.3. Speeding Up Handshake Completion . . . . . . . . . . 17 6.2.3. Speeding Up Handshake Completion . . . . . . . . . . 17
6.2.4. Sending Probe Packets . . . . . . . . . . . . . . . . 18 6.2.4. Sending Probe Packets . . . . . . . . . . . . . . . . 18
6.3. Handling Retry Packets . . . . . . . . . . . . . . . . . 19 6.3. Handling Retry Packets . . . . . . . . . . . . . . . . . 19
6.4. Discarding Keys and Packet State . . . . . . . . . . . . 19 6.4. Discarding Keys and Packet State . . . . . . . . . . . . 19
7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 20 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 20
7.1. Explicit Congestion Notification . . . . . . . . . . . . 20 7.1. Explicit Congestion Notification . . . . . . . . . . . . 20
7.2. Initial and Minimum Congestion Window . . . . . . . . . . 21 7.2. Initial and Minimum Congestion Window . . . . . . . . . . 21
7.3. Congestion Control States . . . . . . . . . . . . . . . . 21 7.3. Congestion Control States . . . . . . . . . . . . . . . . 21
7.3.1. Slow Start . . . . . . . . . . . . . . . . . . . . . 22 7.3.1. Slow Start . . . . . . . . . . . . . . . . . . . . . 22
7.3.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 22 7.3.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 22
7.3.3. Congestion Avoidance . . . . . . . . . . . . . . . . 23 7.3.3. Congestion Avoidance . . . . . . . . . . . . . . . . 23
7.4. Ignoring Loss of Undecryptable Packets . . . . . . . . . 23 7.4. Ignoring Loss of Undecryptable Packets . . . . . . . . . 23
7.5. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 24 7.5. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 24
7.6. Persistent Congestion . . . . . . . . . . . . . . . . . . 24 7.6. Persistent Congestion . . . . . . . . . . . . . . . . . . 24
7.6.1. Duration . . . . . . . . . . . . . . . . . . . . . . 24 7.6.1. Duration . . . . . . . . . . . . . . . . . . . . . . 24
7.6.2. Establishing Persistent Congestion . . . . . . . . . 25 7.6.2. Establishing Persistent Congestion . . . . . . . . . 25
7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25 7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25
7.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.8. Under-utilizing the Congestion Window . . . . . . . . . . 28 7.8. Under-utilizing the Congestion Window . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 28 8.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 28
8.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 28 8.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 28
8.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 28 8.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 31 Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 31
skipping to change at page 3, line 35 skipping to change at page 3, line 35
A.7. On Receiving an Acknowledgment . . . . . . . . . . . . . 35 A.7. On Receiving an Acknowledgment . . . . . . . . . . . . . 35
A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 37 A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 37
A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 38 A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 38
A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 39 A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 39
A.11. Upon Dropping Initial or Handshake Keys . . . . . . . . . 40 A.11. Upon Dropping Initial or Handshake Keys . . . . . . . . . 40
Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 41 Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 41
B.1. Constants of interest . . . . . . . . . . . . . . . . . . 41 B.1. Constants of interest . . . . . . . . . . . . . . . . . . 41
B.2. Variables of interest . . . . . . . . . . . . . . . . . . 41 B.2. Variables of interest . . . . . . . . . . . . . . . . . . 41
B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 42 B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 42
B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 42 B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 42
B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 43 B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 42
B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 43 B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 43
B.7. Process ECN Information . . . . . . . . . . . . . . . . . 44 B.7. Process ECN Information . . . . . . . . . . . . . . . . . 44
B.8. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 44 B.8. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 44
B.9. Removing Discarded Packets From Bytes In Flight . . . . . 45 B.9. Removing Discarded Packets From Bytes In Flight . . . . . 45
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 45 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 45
C.1. Since draft-ietf-quic-recovery-31 . . . . . . . . . . . . 45 C.1. Since draft-ietf-quic-recovery-32 . . . . . . . . . . . . 45
C.2. Since draft-ietf-quic-recovery-30 . . . . . . . . . . . . 45 C.2. Since draft-ietf-quic-recovery-31 . . . . . . . . . . . . 46
C.3. Since draft-ietf-quic-recovery-29 . . . . . . . . . . . . 45 C.3. Since draft-ietf-quic-recovery-30 . . . . . . . . . . . . 46
C.4. Since draft-ietf-quic-recovery-28 . . . . . . . . . . . . 46 C.4. Since draft-ietf-quic-recovery-29 . . . . . . . . . . . . 46
C.5. Since draft-ietf-quic-recovery-27 . . . . . . . . . . . . 46 C.5. Since draft-ietf-quic-recovery-28 . . . . . . . . . . . . 46
C.6. Since draft-ietf-quic-recovery-26 . . . . . . . . . . . . 46 C.6. Since draft-ietf-quic-recovery-27 . . . . . . . . . . . . 46
C.7. Since draft-ietf-quic-recovery-25 . . . . . . . . . . . . 46 C.7. Since draft-ietf-quic-recovery-26 . . . . . . . . . . . . 47
C.8. Since draft-ietf-quic-recovery-24 . . . . . . . . . . . . 46 C.8. Since draft-ietf-quic-recovery-25 . . . . . . . . . . . . 47
C.9. Since draft-ietf-quic-recovery-23 . . . . . . . . . . . . 46 C.9. Since draft-ietf-quic-recovery-24 . . . . . . . . . . . . 47
C.10. Since draft-ietf-quic-recovery-22 . . . . . . . . . . . . 47 C.10. Since draft-ietf-quic-recovery-23 . . . . . . . . . . . . 47
C.11. Since draft-ietf-quic-recovery-21 . . . . . . . . . . . . 47 C.11. Since draft-ietf-quic-recovery-22 . . . . . . . . . . . . 47
C.12. Since draft-ietf-quic-recovery-20 . . . . . . . . . . . . 47 C.12. Since draft-ietf-quic-recovery-21 . . . . . . . . . . . . 48
C.13. Since draft-ietf-quic-recovery-19 . . . . . . . . . . . . 47 C.13. Since draft-ietf-quic-recovery-20 . . . . . . . . . . . . 48
C.14. Since draft-ietf-quic-recovery-18 . . . . . . . . . . . . 48 C.14. Since draft-ietf-quic-recovery-19 . . . . . . . . . . . . 48
C.15. Since draft-ietf-quic-recovery-17 . . . . . . . . . . . . 48 C.15. Since draft-ietf-quic-recovery-18 . . . . . . . . . . . . 48
C.16. Since draft-ietf-quic-recovery-16 . . . . . . . . . . . . 49 C.16. Since draft-ietf-quic-recovery-17 . . . . . . . . . . . . 49
C.17. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 49 C.17. Since draft-ietf-quic-recovery-16 . . . . . . . . . . . . 49
C.18. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 49 C.18. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 50
C.19. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 50 C.19. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 50
C.20. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 50 C.20. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 50
C.21. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 50 C.21. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 50
C.22. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 50 C.22. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 51
C.23. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 50 C.23. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 51
C.24. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 50 C.24. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 51
C.25. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 51 C.25. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 51
C.26. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 51 C.26. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 51
C.27. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 51 C.27. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 51
C.28. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 51 C.28. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 51
C.29. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 51 C.29. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 51
C.30. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 51 C.30. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 52
C.31. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 51 C.31. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 52
C.32. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 51 C.32. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 52
C.33. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 52
Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 52 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 52
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 52 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
QUIC is a new multiplexed and secure transport protocol atop UDP, QUIC is a secure general-purpose transport protocol, described in
specified in [QUIC-TRANSPORT]. This document describes congestion [QUIC-TRANSPORT]). This document describes loss detection and
control and loss recovery for QUIC. Mechanisms described in this congestion control mechanisms for QUIC.
document follow the spirit of existing TCP congestion control and
loss recovery mechanisms, described in RFCs, various Internet-drafts,
or academic papers, and also those prevalent in TCP implementations.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Definitions of terms that are used in this document: Definitions of terms that are used in this document:
Ack-eliciting frames: All frames other than ACK, PADDING, and Ack-eliciting frames: All frames other than ACK, PADDING, and
CONNECTION_CLOSE are considered ack-eliciting. CONNECTION_CLOSE are considered ack-eliciting.
Ack-eliciting packets: Packets that contain ack-eliciting frames Ack-eliciting packets: Packets that contain ack-eliciting frames
elicit an ACK from the receiver within the maximum acknowledgement elicit an ACK from the receiver within the maximum acknowledgement
delay and are called ack-eliciting packets. delay and are called ack-eliciting packets.
In-flight: Packets are considered in-flight when they are ack- In-flight packets: Packets are considered in-flight when they are
eliciting or contain a PADDING frame, and they have been sent but ack-eliciting or contain a PADDING frame, and they have been sent
are not acknowledged, declared lost, or discarded along with old but are not acknowledged, declared lost, or discarded along with
keys. old keys.
3. Design of the QUIC Transmission Machinery 3. Design of the QUIC Transmission Machinery
All transmissions in QUIC are sent with a packet-level header, which All transmissions in QUIC are sent with a packet-level header, which
indicates the encryption level and includes a packet sequence number indicates the encryption level and includes a packet sequence number
(referred to below as a packet number). The encryption level (referred to below as a packet number). The encryption level
indicates the packet number space, as described in [QUIC-TRANSPORT]. indicates the packet number space, as described in [QUIC-TRANSPORT].
Packet numbers never repeat within a packet number space for the Packet numbers never repeat within a packet number space for the
lifetime of a connection. Packet numbers are sent in monotonically lifetime of a connection. Packet numbers are sent in monotonically
increasing order within a space, preventing ambiguity. increasing order within a space, preventing ambiguity.
skipping to change at page 6, line 26 skipping to change at page 6, line 18
except 0-RTT and all generations of 1-RTT keys use the same packet except 0-RTT and all generations of 1-RTT keys use the same packet
number space. Separate packet number spaces ensures acknowledgement number space. Separate packet number spaces ensures acknowledgement
of packets sent with one level of encryption will not cause spurious of packets sent with one level of encryption will not cause spurious
retransmission of packets sent with a different encryption level. retransmission of packets sent with a different encryption level.
Congestion control and round-trip time (RTT) measurement are unified Congestion control and round-trip time (RTT) measurement are unified
across packet number spaces. across packet number spaces.
4.2. Monotonically Increasing Packet Numbers 4.2. Monotonically Increasing Packet Numbers
TCP conflates transmission order at the sender with delivery order at TCP conflates transmission order at the sender with delivery order at
the receiver, which results in retransmissions of the same data the receiver, resulting in the retransmission ambiguity problem
carrying the same sequence number, and consequently leads to ([RETRANSMISSION]). QUIC separates transmission order from delivery
"retransmission ambiguity". QUIC separates the two. QUIC uses a order: packet numbers indicate transmission order, and delivery order
packet number to indicate transmission order. Application data is is determined by the stream offsets in STREAM frames.
sent in one or more streams and delivery order is determined by
stream offsets encoded within STREAM frames.
QUIC's packet number is strictly increasing within a packet number QUIC's packet number is strictly increasing within a packet number
space, and directly encodes transmission order. A higher packet space, and directly encodes transmission order. A higher packet
number signifies that the packet was sent later, and a lower packet number signifies that the packet was sent later, and a lower packet
number signifies that the packet was sent earlier. When a packet number signifies that the packet was sent earlier. When a packet
containing ack-eliciting frames is detected lost, QUIC includes containing ack-eliciting frames is detected lost, QUIC includes
necessary frames in a new packet with a new packet number, removing necessary frames in a new packet with a new packet number, removing
ambiguity about which packet is acknowledged when an ACK is received. ambiguity about which packet is acknowledged when an ACK is received.
Consequently, more accurate RTT measurements can be made, spurious Consequently, more accurate RTT measurements can be made, spurious
retransmissions are trivially detected, and mechanisms such as Fast retransmissions are trivially detected, and mechanisms such as Fast
Retransmit can be applied universally, based only on packet number. Retransmit can be applied universally, based only on packet number.
This design point significantly simplifies loss detection mechanisms This design point significantly simplifies loss detection mechanisms
for QUIC. Most TCP mechanisms implicitly attempt to infer for QUIC. Most TCP mechanisms implicitly attempt to infer
transmission ordering based on TCP sequence numbers - a non-trivial transmission ordering based on TCP sequence numbers - a non-trivial
task, especially when TCP timestamps are not available. task, especially when TCP timestamps are not available.
4.3. Clearer Loss Epoch 4.3. Clearer Loss Epoch
QUIC starts a loss epoch when a packet is lost and ends one when any QUIC starts a loss epoch when a packet is lost. The loss epoch ends
packet sent after the epoch starts is acknowledged. TCP waits for when any packet sent after the start of the epoch is acknowledged.
the gap in the sequence number space to be filled, and so if a TCP waits for the gap in the sequence number space to be filled, and
segment is lost multiple times in a row, the loss epoch may not end so if a segment is lost multiple times in a row, the loss epoch may
for several round trips. Because both should reduce their congestion not end for several round trips. Because both should reduce their
windows only once per epoch, QUIC will do it once for every round congestion windows only once per epoch, QUIC will do it once for
trip that experiences loss, while TCP may only do it once across every round trip that experiences loss, while TCP may only do it once
multiple round trips. across multiple round trips.
4.4. No Reneging 4.4. No Reneging
QUIC ACKs contain information that is similar to TCP SACK, but QUIC QUIC ACKs contain information that is similar to TCP SACK, but QUIC
does not allow any acknowledged packet to be reneged, greatly does not allow any acknowledged packet to be reneged, greatly
simplifying implementations on both sides and reducing memory simplifying implementations on both sides and reducing memory
pressure on the sender. pressure on the sender.
4.5. More ACK Ranges 4.5. More ACK Ranges
skipping to change at page 16, line 38 skipping to change at page 16, line 27
The PTO timer MUST NOT be set if a timer is set for time threshold The PTO timer MUST NOT be set if a timer is set for time threshold
loss detection; see Section 6.1.2. A timer that is set for time loss detection; see Section 6.1.2. A timer that is set for time
threshold loss detection will expire earlier than the PTO timer in threshold loss detection will expire earlier than the PTO timer in
most cases and is less likely to spuriously retransmit data. most cases and is less likely to spuriously retransmit data.
6.2.2. Handshakes and New Paths 6.2.2. Handshakes and New Paths
Resumed connections over the same network MAY use the previous Resumed connections over the same network MAY use the previous
connection's final smoothed RTT value as the resumed connection's connection's final smoothed RTT value as the resumed connection's
initial RTT. When no previous RTT is available, the initial RTT initial RTT. When no previous RTT is available, the initial RTT
SHOULD be set to 333ms, resulting in a 1 second initial timeout, as SHOULD be set to 333ms. This results in handshakes starting with a
recommended in [RFC6298]. PTO of 1 second, as recommended for TCP's initial retransmission
timeout; see Section 2 of [RFC6298].
A connection MAY use the delay between sending a PATH_CHALLENGE and A connection MAY use the delay between sending a PATH_CHALLENGE and
receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in receiving a PATH_RESPONSE to set the initial RTT (see kInitialRtt in
Appendix A.2) for a new path, but the delay SHOULD NOT be considered Appendix A.2) for a new path, but the delay SHOULD NOT be considered
an RTT sample. an RTT sample.
Initial packets and Handshake packets could be never acknowledged, Initial packets and Handshake packets could be never acknowledged,
but they are removed from bytes in flight when the Initial and but they are removed from bytes in flight when the Initial and
Handshake keys are discarded, as described below in Section 6.4. Handshake keys are discarded, as described below in Section 6.4.
When Initial or Handshake keys are discarded, the PTO and loss When Initial or Handshake keys are discarded, the PTO and loss
skipping to change at page 24, line 20 skipping to change at page 24, line 20
Probe packets MUST NOT be blocked by the congestion controller. A Probe packets MUST NOT be blocked by the congestion controller. A
sender MUST however count these packets as being additionally in sender MUST however count these packets as being additionally in
flight, since these packets add network load without establishing flight, since these packets add network load without establishing
packet loss. Note that sending probe packets might cause the packet loss. Note that sending probe packets might cause the
sender's bytes in flight to exceed the congestion window until an sender's bytes in flight to exceed the congestion window until an
acknowledgement is received that establishes loss or delivery of acknowledgement is received that establishes loss or delivery of
packets. packets.
7.6. Persistent Congestion 7.6. Persistent Congestion
When a sender establishes loss of all in-flight packets sent over a When a sender establishes loss of all packets sent over a long enough
long enough duration, the network is considered to be experiencing duration, the network is considered to be experiencing persistent
persistent congestion. congestion.
7.6.1. Duration 7.6.1. Duration
The persistent congestion duration is computed as follows: The persistent congestion duration is computed as follows:
(smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) * (smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay) *
kPersistentCongestionThreshold kPersistentCongestionThreshold
Unlike the PTO computation in Section 6.2, this duration includes the Unlike the PTO computation in Section 6.2, this duration includes the
max_ack_delay irrespective of the packet number spaces in which max_ack_delay irrespective of the packet number spaces in which
skipping to change at page 25, line 12 skipping to change at page 25, line 12
persistent congestion, since application patterns impact PTO persistent congestion, since application patterns impact PTO
expirations. For example, a sender that sends small amounts of data expirations. For example, a sender that sends small amounts of data
with silence periods between them restarts the PTO timer every time with silence periods between them restarts the PTO timer every time
it sends, potentially preventing the PTO timer from expiring for a it sends, potentially preventing the PTO timer from expiring for a
long period of time, even when no acknowledgments are being received. long period of time, even when no acknowledgments are being received.
The use of a duration enables a sender to establish persistent The use of a duration enables a sender to establish persistent
congestion without depending on PTO expiration. congestion without depending on PTO expiration.
7.6.2. Establishing Persistent Congestion 7.6.2. Establishing Persistent Congestion
A sender establishes persistent congestion on receiving an A sender establishes persistent congestion after the receipt of an
acknowledgement if at least two ack-eliciting packets are declared acknowledgement if two packets that are ack-eliciting are declared
lost, and: lost, and:
* all packets, across all packet number spaces, sent between these * across all packet number spaces, none of the packets sent between
two send times are declared lost; the send times of these two packets are acknowledged;
* the duration between the send times of these two packets exceeds * the duration between the send times of these two packets exceeds
the persistent congestion duration (Section 7.6.1); and the persistent congestion duration (Section 7.6.1); and
* a prior RTT sample existed when both packets were sent. * a prior RTT sample existed when these two packets were sent.
These two packets MUST be ack-eliciting, since a receiver is required
to acknowledge only ack-eliciting packets within its maximum ack
delay; see Section 13.2 of [QUIC-TRANSPORT].
The persistent congestion period SHOULD NOT start until there is at The persistent congestion period SHOULD NOT start until there is at
least one RTT sample. Before the first RTT sample, a sender arms its least one RTT sample. Before the first RTT sample, a sender arms its
PTO timer based on the initial RTT (Section 6.2.2), which could be PTO timer based on the initial RTT (Section 6.2.2), which could be
substantially larger than the actual RTT. Requiring a prior RTT substantially larger than the actual RTT. Requiring a prior RTT
sample prevents a sender from establishing persistent congestion with sample prevents a sender from establishing persistent congestion with
potentially too few probes. potentially too few probes.
Since network congestion is not affected by packet number spaces, Since network congestion is not affected by packet number spaces,
persistent congestion SHOULD consider packets sent across packet persistent congestion SHOULD consider packets sent across packet
skipping to change at page 28, line 27 skipping to change at page 28, line 27
A sender MAY implement alternative mechanisms to update its A sender MAY implement alternative mechanisms to update its
congestion window after periods of under-utilization, such as those congestion window after periods of under-utilization, such as those
proposed for TCP in [RFC7661]. proposed for TCP in [RFC7661].
8. Security Considerations 8. Security Considerations
8.1. Congestion Signals 8.1. Congestion Signals
Congestion control fundamentally involves the consumption of signals Congestion control fundamentally involves the consumption of signals
- both loss and ECN codepoints - from unauthenticated entities. On- -- both loss and ECN codepoints -- from unauthenticated entities.
path attackers can spoof or alter these signals. An attacker can On-path attackers can spoof or alter these signals. An attacker can
cause endpoints to reduce their sending rate by dropping packets, or cause endpoints to reduce their sending rate by dropping packets, or
alter send rate by changing ECN codepoints. alter send rate by changing ECN codepoints.
8.2. Traffic Analysis 8.2. Traffic Analysis
Packets that carry only ACK frames can be heuristically identified by Packets that carry only ACK frames can be heuristically identified by
observing packet size. Acknowledgement patterns may expose observing packet size. Acknowledgement patterns may expose
information about link characteristics or application behavior. To information about link characteristics or application behavior. To
reduce leaked information, endpoints can bundle acknowledgments with reduce leaked information, endpoints can bundle acknowledgments with
other frames, or they can use PADDING frames at a potential cost to other frames, or they can use PADDING frames at a potential cost to
skipping to change at page 29, line 33 skipping to change at page 29, line 33
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", Work in Progress, Internet-Draft, draft-ietf-quic- QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-
tls-32, 20 October 2020, tls-33, 13 December 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-32>. <https://tools.ietf.org/html/draft-ietf-quic-tls-33>.
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", Work in Progress, Multiplexed and Secure Transport", Work in Progress,
Internet-Draft, draft-ietf-quic-transport-32, 20 October Internet-Draft, draft-ietf-quic-transport-33, 13 December
2020, <https://tools.ietf.org/html/draft-ietf-quic- 2020, <https://tools.ietf.org/html/draft-ietf-quic-
transport-32>. transport-33>.
[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>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 30, line 25 skipping to change at page 30, line 25
[FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement: [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement:
Refining TCP Congestion Control", ACM SIGCOMM , August Refining TCP Congestion Control", ACM SIGCOMM , August
1996. 1996.
[PRR] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional [PRR] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional
Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937, Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937,
May 2013, <https://www.rfc-editor.org/info/rfc6937>. May 2013, <https://www.rfc-editor.org/info/rfc6937>.
[RACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The [RACK] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
RACK-TLP loss detection algorithm for TCP", Work in RACK-TLP loss detection algorithm for TCP", Work in
Progress, Internet-Draft, draft-ietf-tcpm-rack-11, 30 Progress, Internet-Draft, draft-ietf-tcpm-rack-14, 2
September 2020, <http://www.ietf.org/internet-drafts/ December 2020, <http://www.ietf.org/internet-drafts/draft-
draft-ietf-tcpm-rack-11.txt>. ietf-tcpm-rack-14.txt>.
[RETRANSMISSION]
Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", ACM SIGCOMM
CCR , January 1995.
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February
2003, <https://www.rfc-editor.org/info/rfc3465>. 2003, <https://www.rfc-editor.org/info/rfc3465>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,
skipping to change at page 34, line 46 skipping to change at page 34, line 46
Pseudocode for OnPacketSent follows: Pseudocode for OnPacketSent follows:
OnPacketSent(packet_number, pn_space, ack_eliciting, OnPacketSent(packet_number, pn_space, ack_eliciting,
in_flight, sent_bytes): in_flight, sent_bytes):
sent_packets[pn_space][packet_number].packet_number = sent_packets[pn_space][packet_number].packet_number =
packet_number packet_number
sent_packets[pn_space][packet_number].time_sent = now() sent_packets[pn_space][packet_number].time_sent = now()
sent_packets[pn_space][packet_number].ack_eliciting = sent_packets[pn_space][packet_number].ack_eliciting =
ack_eliciting ack_eliciting
sent_packets[pn_space][packet_number].in_flight = in_flight sent_packets[pn_space][packet_number].in_flight = in_flight
sent_packets[pn_space][packet_number].sent_bytes = sent_bytes
if (in_flight): if (in_flight):
if (ack_eliciting): if (ack_eliciting):
time_of_last_ack_eliciting_packet[pn_space] = now() time_of_last_ack_eliciting_packet[pn_space] = now()
OnPacketSentCC(sent_bytes) OnPacketSentCC(sent_bytes)
sent_packets[pn_space][packet_number].sent_bytes =
sent_bytes
SetLossDetectionTimer() SetLossDetectionTimer()
A.6. On Receiving a Datagram A.6. On Receiving a Datagram
When a server is blocked by anti-amplification limits, receiving a When a server is blocked by anti-amplification limits, receiving a
datagram unblocks it, even if none of the packets in the datagram are datagram unblocks it, even if none of the packets in the datagram are
successfully processed. In such a case, the PTO timer will need to successfully processed. In such a case, the PTO timer will need to
be re-armed. be re-armed.
Pseudocode for OnDatagramReceived follows: Pseudocode for OnDatagramReceived follows:
skipping to change at page 40, line 8 skipping to change at page 40, line 8
DetectAndRemoveLostPackets is called every time an ACK is received or DetectAndRemoveLostPackets is called every time an ACK is received or
the time threshold loss detection timer expires. This function the time threshold loss detection timer expires. This function
operates on the sent_packets for that packet number space and returns operates on the sent_packets for that packet number space and returns
a list of packets newly detected as lost. a list of packets newly detected as lost.
Pseudocode for DetectAndRemoveLostPackets follows: Pseudocode for DetectAndRemoveLostPackets follows:
DetectAndRemoveLostPackets(pn_space): DetectAndRemoveLostPackets(pn_space):
assert(largest_acked_packet[pn_space] != infinite) assert(largest_acked_packet[pn_space] != infinite)
loss_time[pn_space] = 0 loss_time[pn_space] = 0
lost_packets = {} lost_packets = []
loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt) loss_delay = kTimeThreshold * max(latest_rtt, smoothed_rtt)
// Minimum time of kGranularity before packets are deemed lost. // Minimum time of kGranularity before packets are deemed lost.
loss_delay = max(loss_delay, kGranularity) loss_delay = max(loss_delay, kGranularity)
// Packets sent before this time are deemed lost. // Packets sent before this time are deemed lost.
lost_send_time = now() - loss_delay lost_send_time = now() - loss_delay
foreach unacked in sent_packets[pn_space]: foreach unacked in sent_packets[pn_space]:
if (unacked.packet_number > largest_acked_packet[pn_space]): if (unacked.packet_number > largest_acked_packet[pn_space]):
continue continue
// Mark packet as lost, or set time when it should be marked. // Mark packet as lost, or set time when it should be marked.
// Note: The use of kPacketThreshold here assumes that there // Note: The use of kPacketThreshold here assumes that there
// were no sender-induced gaps in the packet number space. // were no sender-induced gaps in the packet number space.
if (unacked.time_sent <= lost_send_time || if (unacked.time_sent <= lost_send_time ||
largest_acked_packet[pn_space] >= largest_acked_packet[pn_space] >=
unacked.packet_number + kPacketThreshold): unacked.packet_number + kPacketThreshold):
sent_packets[pn_space].remove(unacked.packet_number) sent_packets[pn_space].remove(unacked.packet_number)
if (unacked.in_flight): lost_packets.insert(unacked)
lost_packets.insert(unacked)
else: else:
if (loss_time[pn_space] == 0): if (loss_time[pn_space] == 0):
loss_time[pn_space] = unacked.time_sent + loss_delay loss_time[pn_space] = unacked.time_sent + loss_delay
else: else:
loss_time[pn_space] = min(loss_time[pn_space], loss_time[pn_space] = min(loss_time[pn_space],
unacked.time_sent + loss_delay) unacked.time_sent + loss_delay)
return lost_packets return lost_packets
A.11. Upon Dropping Initial or Handshake Keys A.11. Upon Dropping Initial or Handshake Keys
skipping to change at page 42, line 50 skipping to change at page 42, line 43
congestion_recovery_start_time = 0 congestion_recovery_start_time = 0
ssthresh = infinite ssthresh = infinite
for pn_space in [ Initial, Handshake, ApplicationData ]: for pn_space in [ Initial, Handshake, ApplicationData ]:
ecn_ce_counters[pn_space] = 0 ecn_ce_counters[pn_space] = 0
B.4. On Packet Sent B.4. On Packet Sent
Whenever a packet is sent, and it contains non-ACK frames, the packet Whenever a packet is sent, and it contains non-ACK frames, the packet
increases bytes_in_flight. increases bytes_in_flight.
OnPacketSentCC(bytes_sent): OnPacketSentCC(sent_bytes):
bytes_in_flight += bytes_sent bytes_in_flight += sent_bytes
B.5. On Packet Acknowledgement B.5. On Packet Acknowledgement
Invoked from loss detection's OnAckReceived and is supplied with the Invoked from loss detection's OnAckReceived and is supplied with the
newly acked_packets from sent_packets. newly acked_packets from sent_packets.
In congestion avoidance, implementers that use an integer In congestion avoidance, implementers that use an integer
representation for congestion_window should be careful with division, representation for congestion_window should be careful with division,
and can use the alternative approach suggested in Section 2.1 of and can use the alternative approach suggested in Section 2.1 of
[RFC3465]. [RFC3465].
InCongestionRecovery(sent_time): InCongestionRecovery(sent_time):
return sent_time <= congestion_recovery_start_time return sent_time <= congestion_recovery_start_time
OnPacketsAcked(acked_packets): OnPacketsAcked(acked_packets):
for acked_packet in acked_packets: for acked_packet in acked_packets:
OnPacketAcked(acked_packet) OnPacketAcked(acked_packet)
OnPacketAcked(acked_packet): OnPacketAcked(acked_packet):
if (!acked_packet.in_flight):
return;
// Remove from bytes_in_flight. // Remove from bytes_in_flight.
bytes_in_flight -= acked_packet.sent_bytes bytes_in_flight -= acked_packet.sent_bytes
// Do not increase congestion_window if application // Do not increase congestion_window if application
// limited or flow control limited. // limited or flow control limited.
if (IsAppOrFlowControlLimited()) if (IsAppOrFlowControlLimited())
return return
// Do not increase congestion window in recovery period. // Do not increase congestion window in recovery period.
if (InCongestionRecovery(acked_packet.time_sent)): if (InCongestionRecovery(acked_packet.time_sent)):
return return
if (congestion_window < ssthresh): if (congestion_window < ssthresh):
skipping to change at page 44, line 35 skipping to change at page 45, line 6
if (ack.ce_counter > ecn_ce_counters[pn_space]): if (ack.ce_counter > ecn_ce_counters[pn_space]):
ecn_ce_counters[pn_space] = ack.ce_counter ecn_ce_counters[pn_space] = ack.ce_counter
sent_time = sent_packets[ack.largest_acked].time_sent sent_time = sent_packets[ack.largest_acked].time_sent
OnCongestionEvent(sent_time) OnCongestionEvent(sent_time)
B.8. On Packets Lost B.8. On Packets Lost
Invoked when DetectAndRemoveLostPackets deems packets lost. Invoked when DetectAndRemoveLostPackets deems packets lost.
OnPacketsLost(lost_packets): OnPacketsLost(lost_packets):
sent_time_of_last_loss = 0
// Remove lost packets from bytes_in_flight. // Remove lost packets from bytes_in_flight.
for lost_packet in lost_packets: for lost_packet in lost_packets:
bytes_in_flight -= lost_packet.sent_bytes if lost_packet.in_flight:
OnCongestionEvent(lost_packets.largest().time_sent) bytes_in_flight -= lost_packet.sent_bytes
sent_time_of_last_loss =
max(sent_time_of_last_loss, lost_packet.time_sent)
// Congestion event if in-flight packets were lost
if (sent_time_of_last_loss != 0):
OnCongestionEvent(sent_time_of_last_loss)
// Reset the congestion window if the loss of these // Reset the congestion window if the loss of these
// packets indicates persistent congestion. // packets indicates persistent congestion.
// Only consider packets sent after getting an RTT sample. // Only consider packets sent after getting an RTT sample.
if (first_rtt_sample == 0): if (first_rtt_sample == 0):
return return
pc_lost = {} pc_lost = []
for lost in lost_packets: for lost in lost_packets:
if lost.time_sent > first_rtt_sample: if lost.time_sent > first_rtt_sample:
pc_lost.insert(lost) pc_lost.insert(lost)
if (InPersistentCongestion(pc_lost)): if (InPersistentCongestion(pc_lost)):
congestion_window = kMinimumWindow congestion_window = kMinimumWindow
congestion_recovery_start_time = 0 congestion_recovery_start_time = 0
B.9. Removing Discarded Packets From Bytes In Flight B.9. Removing Discarded Packets From Bytes In Flight
When Initial or Handshake keys are discarded, packets sent in that When Initial or Handshake keys are discarded, packets sent in that
skipping to change at page 45, line 25 skipping to change at page 45, line 50
if packet.in_flight if packet.in_flight
bytes_in_flight -= size bytes_in_flight -= size
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-recovery-31 C.1. Since draft-ietf-quic-recovery-32
* Clarifications to definition of persistent congestion (#4413,
#4414, #4421, #4429, #4437)
C.2. Since draft-ietf-quic-recovery-31
* Limit the number of Initial packets sent in response to * Limit the number of Initial packets sent in response to
unauthenticated packets (#4183, #4188) unauthenticated packets (#4183, #4188)
C.2. Since draft-ietf-quic-recovery-30 C.3. Since draft-ietf-quic-recovery-30
Editorial changes only. Editorial changes only.
C.3. Since draft-ietf-quic-recovery-29 C.4. Since draft-ietf-quic-recovery-29
* Allow caching of packets that can't be decrypted, by allowing the * Allow caching of packets that can't be decrypted, by allowing the
reported acknowledgment delay to exceed max_ack_delay prior to reported acknowledgment delay to exceed max_ack_delay prior to
confirming the handshake (#3821, #3980, #4035, #3874) confirming the handshake (#3821, #3980, #4035, #3874)
* Persistent congestion cannot include packets sent before the first * Persistent congestion cannot include packets sent before the first
RTT sample for the path (#3875, #3889) RTT sample for the path (#3875, #3889)
* Recommend reset of min_rtt in persistent congestion (#3927, #3975) * Recommend reset of min_rtt in persistent congestion (#3927, #3975)
* Persistent congestion is independent of packet number space * Persistent congestion is independent of packet number space
(#3939, #3961) (#3939, #3961)
* Only limit bursts to the initial window without information about * Only limit bursts to the initial window without information about
the path (#3892, #3936) the path (#3892, #3936)
* Add normative requirements for increasing and reducing the * Add normative requirements for increasing and reducing the
congestion window (#3944, #3978, #3997, #3998) congestion window (#3944, #3978, #3997, #3998)
C.4. Since draft-ietf-quic-recovery-28 C.5. Since draft-ietf-quic-recovery-28
* Refactored pseudocode to correct PTO calculation (#3564, #3674, * Refactored pseudocode to correct PTO calculation (#3564, #3674,
#3681) #3681)
C.5. Since draft-ietf-quic-recovery-27 C.6. Since draft-ietf-quic-recovery-27
* Added recommendations for speeding up handshake under some loss * Added recommendations for speeding up handshake under some loss
conditions (#3078, #3080) conditions (#3078, #3080)
* PTO count is reset when handshake progress is made (#3272, #3415) * PTO count is reset when handshake progress is made (#3272, #3415)
* PTO count is not reset by a client when the server might be * PTO count is not reset by a client when the server might be
awaiting address validation (#3546, #3551) awaiting address validation (#3546, #3551)
* Recommend repairing losses immediately after entering the recovery * Recommend repairing losses immediately after entering the recovery
period (#3335, #3443) period (#3335, #3443)
* Clarified what loss conditions can be ignored during the handshake * Clarified what loss conditions can be ignored during the handshake
(#3456, #3450) (#3456, #3450)
* Allow, but don't recommend, using RTT from previous connection to * Allow, but don't recommend, using RTT from previous connection to
seed RTT (#3464, #3496) seed RTT (#3464, #3496)
* Recommend use of adaptive loss detection thresholds (#3571, #3572) * Recommend use of adaptive loss detection thresholds (#3571, #3572)
C.6. Since draft-ietf-quic-recovery-26 C.7. Since draft-ietf-quic-recovery-26
No changes. No changes.
C.7. Since draft-ietf-quic-recovery-25 C.8. Since draft-ietf-quic-recovery-25
No significant changes. No significant changes.
C.8. Since draft-ietf-quic-recovery-24 C.9. Since draft-ietf-quic-recovery-24
* Require congestion control of some sort (#3247, #3244, #3248) * Require congestion control of some sort (#3247, #3244, #3248)
* Set a minimum reordering threshold (#3256, #3240) * Set a minimum reordering threshold (#3256, #3240)
* PTO is specific to a packet number space (#3067, #3074, #3066) * PTO is specific to a packet number space (#3067, #3074, #3066)
C.9. Since draft-ietf-quic-recovery-23 C.10. Since draft-ietf-quic-recovery-23
* Define under-utilizing the congestion window (#2630, #2686, #2675) * Define under-utilizing the congestion window (#2630, #2686, #2675)
* PTO MUST send data if possible (#3056, #3057) * PTO MUST send data if possible (#3056, #3057)
* Connection Close is not ack-eliciting (#3097, #3098) * Connection Close is not ack-eliciting (#3097, #3098)
* MUST limit bursts to the initial congestion window (#3160) * MUST limit bursts to the initial congestion window (#3160)
* Define the current max_datagram_size for congestion control * Define the current max_datagram_size for congestion control
(#3041, #3167) (#3041, #3167)
C.10. Since draft-ietf-quic-recovery-22 C.11. Since draft-ietf-quic-recovery-22
* PTO should always send an ack-eliciting packet (#2895) * PTO should always send an ack-eliciting packet (#2895)
* Unify the Handshake Timer with the PTO timer (#2648, #2658, #2886) * Unify the Handshake Timer with the PTO timer (#2648, #2658, #2886)
* Move ACK generation text to transport draft (#1860, #2916) * Move ACK generation text to transport draft (#1860, #2916)
C.11. Since draft-ietf-quic-recovery-21 C.12. Since draft-ietf-quic-recovery-21
* No changes * No changes
C.12. Since draft-ietf-quic-recovery-20 C.13. Since draft-ietf-quic-recovery-20
* Path validation can be used as initial RTT value (#2644, #2687) * Path validation can be used as initial RTT value (#2644, #2687)
* max_ack_delay transport parameter defaults to 0 (#2638, #2646) * max_ack_delay transport parameter defaults to 0 (#2638, #2646)
* ACK delay only measures intentional delays induced by the * ACK delay only measures intentional delays induced by the
implementation (#2596, #2786) implementation (#2596, #2786)
C.13. Since draft-ietf-quic-recovery-19 C.14. Since draft-ietf-quic-recovery-19
* Change kPersistentThreshold from an exponent to a multiplier * Change kPersistentThreshold from an exponent to a multiplier
(#2557) (#2557)
* Send a PING if the PTO timer fires and there's nothing to send * Send a PING if the PTO timer fires and there's nothing to send
(#2624) (#2624)
* Set loss delay to at least kGranularity (#2617) * Set loss delay to at least kGranularity (#2617)
* Merge application limited and sending after idle sections. Always * Merge application limited and sending after idle sections. Always
skipping to change at page 48, line 10 skipping to change at page 48, line 43
packet is ack-eliciting but the largest_acked is not (#2592) packet is ack-eliciting but the largest_acked is not (#2592)
* Don't arm the handshake timer if there is no handshake data * Don't arm the handshake timer if there is no handshake data
(#2590) (#2590)
* Clarify that the time threshold loss alarm takes precedence over * Clarify that the time threshold loss alarm takes precedence over
the crypto handshake timer (#2590, #2620) the crypto handshake timer (#2590, #2620)
* Change initial RTT to 500ms to align with RFC6298 (#2184) * Change initial RTT to 500ms to align with RFC6298 (#2184)
C.14. Since draft-ietf-quic-recovery-18 C.15. Since draft-ietf-quic-recovery-18
* Change IW byte limit to 14720 from 14600 (#2494) * Change IW byte limit to 14720 from 14600 (#2494)
* Update PTO calculation to match RFC6298 (#2480, #2489, #2490) * Update PTO calculation to match RFC6298 (#2480, #2489, #2490)
* Improve loss detection's description of multiple packet number * Improve loss detection's description of multiple packet number
spaces and pseudocode (#2485, #2451, #2417) spaces and pseudocode (#2485, #2451, #2417)
* Declare persistent congestion even if non-probe packets are sent * Declare persistent congestion even if non-probe packets are sent
and don't make persistent congestion more aggressive than RTO and don't make persistent congestion more aggressive than RTO
verified was (#2365, #2244) verified was (#2365, #2244)
* Move pseudocode to the appendices (#2408) * Move pseudocode to the appendices (#2408)
* What to send on multiple PTOs (#2380) * What to send on multiple PTOs (#2380)
C.15. Since draft-ietf-quic-recovery-17 C.16. Since draft-ietf-quic-recovery-17
* After Probe Timeout discard in-flight packets or send another * After Probe Timeout discard in-flight packets or send another
(#2212, #1965) (#2212, #1965)
* Endpoints discard initial keys as soon as handshake keys are * Endpoints discard initial keys as soon as handshake keys are
available (#1951, #2045) available (#1951, #2045)
* 0-RTT state is discarded when 0-RTT is rejected (#2300) * 0-RTT state is discarded when 0-RTT is rejected (#2300)
* Loss detection timer is cancelled when ack-eliciting frames are in * Loss detection timer is cancelled when ack-eliciting frames are in
skipping to change at page 49, line 5 skipping to change at page 49, line 39
controller (#2138, 2187) controller (#2138, 2187)
* Process ECN counts before marking packets lost (#2142) * Process ECN counts before marking packets lost (#2142)
* Mark packets lost before resetting crypto_count and pto_count * Mark packets lost before resetting crypto_count and pto_count
(#2208, #2209) (#2208, #2209)
* Congestion and loss recovery state are discarded when keys are * Congestion and loss recovery state are discarded when keys are
discarded (#2327) discarded (#2327)
C.16. Since draft-ietf-quic-recovery-16 C.17. Since draft-ietf-quic-recovery-16
* Unify TLP and RTO into a single PTO; eliminate min RTO, min TLP * Unify TLP and RTO into a single PTO; eliminate min RTO, min TLP
and min crypto timeouts; eliminate timeout validation (#2114, and min crypto timeouts; eliminate timeout validation (#2114,
#2166, #2168, #1017) #2166, #2168, #1017)
* Redefine how congestion avoidance in terms of when the period * Redefine how congestion avoidance in terms of when the period
starts (#1928, #1930) starts (#1928, #1930)
* Document what needs to be tracked for packets that are in flight * Document what needs to be tracked for packets that are in flight
(#765, #1724, #1939) (#765, #1724, #1939)
skipping to change at page 49, line 36 skipping to change at page 50, line 21
* Limit ack_delay by max_ack_delay (#2060, #2099) * Limit ack_delay by max_ack_delay (#2060, #2099)
* Initial keys are discarded once Handshake keys are available * Initial keys are discarded once Handshake keys are available
(#1951, #2045) (#1951, #2045)
* Reorder ECN and loss detection in pseudocode (#2142) * Reorder ECN and loss detection in pseudocode (#2142)
* Only cancel loss detection timer if ack-eliciting packets are in * Only cancel loss detection timer if ack-eliciting packets are in
flight (#2093, #2117) flight (#2093, #2117)
C.17. Since draft-ietf-quic-recovery-14 C.18. Since draft-ietf-quic-recovery-14
* Used max_ack_delay from transport params (#1796, #1782) * Used max_ack_delay from transport params (#1796, #1782)
* Merge ACK and ACK_ECN (#1783) * Merge ACK and ACK_ECN (#1783)
C.18. Since draft-ietf-quic-recovery-13 C.19. Since draft-ietf-quic-recovery-13
* Corrected the lack of ssthresh reduction in CongestionEvent * Corrected the lack of ssthresh reduction in CongestionEvent
pseudocode (#1598) pseudocode (#1598)
* Considerations for ECN spoofing (#1426, #1626) * Considerations for ECN spoofing (#1426, #1626)
* Clarifications for PADDING and congestion control (#837, #838, * Clarifications for PADDING and congestion control (#837, #838,
#1517, #1531, #1540) #1517, #1531, #1540)
* Reduce early retransmission timer to RTT/8 (#945, #1581) * Reduce early retransmission timer to RTT/8 (#945, #1581)
skipping to change at page 50, line 4 skipping to change at page 50, line 38
* Corrected the lack of ssthresh reduction in CongestionEvent * Corrected the lack of ssthresh reduction in CongestionEvent
pseudocode (#1598) pseudocode (#1598)
* Considerations for ECN spoofing (#1426, #1626) * Considerations for ECN spoofing (#1426, #1626)
* Clarifications for PADDING and congestion control (#837, #838, * Clarifications for PADDING and congestion control (#837, #838,
#1517, #1531, #1540) #1517, #1531, #1540)
* Reduce early retransmission timer to RTT/8 (#945, #1581) * Reduce early retransmission timer to RTT/8 (#945, #1581)
* Packets are declared lost after an RTO is verified (#935, #1582) * Packets are declared lost after an RTO is verified (#935, #1582)
C.19. Since draft-ietf-quic-recovery-12 C.20. Since draft-ietf-quic-recovery-12
* Changes to manage separate packet number spaces and encryption * Changes to manage separate packet number spaces and encryption
levels (#1190, #1242, #1413, #1450) levels (#1190, #1242, #1413, #1450)
* Added ECN feedback mechanisms and handling; new ACK_ECN frame * Added ECN feedback mechanisms and handling; new ACK_ECN frame
(#804, #805, #1372) (#804, #805, #1372)
C.20. Since draft-ietf-quic-recovery-11 C.21. Since draft-ietf-quic-recovery-11
No significant changes. No significant changes.
C.21. Since draft-ietf-quic-recovery-10 C.22. Since draft-ietf-quic-recovery-10
* Improved text on ack generation (#1139, #1159) * Improved text on ack generation (#1139, #1159)
* Make references to TCP recovery mechanisms informational (#1195) * Make references to TCP recovery mechanisms informational (#1195)
* Define time_of_last_sent_handshake_packet (#1171) * Define time_of_last_sent_handshake_packet (#1171)
* Added signal from TLS the data it includes needs to be sent in a * Added signal from TLS the data it includes needs to be sent in a
Retry packet (#1061, #1199) Retry packet (#1061, #1199)
* Minimum RTT (min_rtt) is initialized with an infinite value * Minimum RTT (min_rtt) is initialized with an infinite value
(#1169) (#1169)
C.22. Since draft-ietf-quic-recovery-09 C.23. Since draft-ietf-quic-recovery-09
No significant changes. No significant changes.
C.23. Since draft-ietf-quic-recovery-08 C.24. Since draft-ietf-quic-recovery-08
* Clarified pacing and RTO (#967, #977) * Clarified pacing and RTO (#967, #977)
C.24. Since draft-ietf-quic-recovery-07 C.25. Since draft-ietf-quic-recovery-07
* Include ACK delay in RTO(and TLP) computations (#981) * Include ACK delay in RTO(and TLP) computations (#981)
* ACK delay in SRTT computation (#961) * ACK delay in SRTT computation (#961)
* Default RTT and Slow Start (#590) * Default RTT and Slow Start (#590)
* Many editorial fixes. * Many editorial fixes.
C.25. Since draft-ietf-quic-recovery-06 C.26. Since draft-ietf-quic-recovery-06
No significant changes. No significant changes.
C.26. Since draft-ietf-quic-recovery-05 C.27. Since draft-ietf-quic-recovery-05
* Add more congestion control text (#776) * Add more congestion control text (#776)
C.27. Since draft-ietf-quic-recovery-04 C.28. Since draft-ietf-quic-recovery-04
No significant changes. No significant changes.
C.28. Since draft-ietf-quic-recovery-03 C.29. Since draft-ietf-quic-recovery-03
No significant changes. No significant changes.
C.29. Since draft-ietf-quic-recovery-02 C.30. Since draft-ietf-quic-recovery-02
* Integrate F-RTO (#544, #409) * Integrate F-RTO (#544, #409)
* Add congestion control (#545, #395) * Add congestion control (#545, #395)
* Require connection abort if a skipped packet was acknowledged * Require connection abort if a skipped packet was acknowledged
(#415) (#415)
* Simplify RTO calculations (#142, #417) * Simplify RTO calculations (#142, #417)
C.30. Since draft-ietf-quic-recovery-01 C.31. Since draft-ietf-quic-recovery-01
* Overview added to loss detection * Overview added to loss detection
* Changes initial default RTT to 100ms * Changes initial default RTT to 100ms
* Added time-based loss detection and fixes early retransmit * Added time-based loss detection and fixes early retransmit
* Clarified loss recovery for handshake packets * Clarified loss recovery for handshake packets
* Fixed references and made TCP references informative * Fixed references and made TCP references informative
C.31. Since draft-ietf-quic-recovery-00 C.32. Since draft-ietf-quic-recovery-00
* Improved description of constants and ACK behavior * Improved description of constants and ACK behavior
C.32. Since draft-iyengar-quic-loss-recovery-01 C.33. Since draft-iyengar-quic-loss-recovery-01
* Adopted as base for draft-ietf-quic-recovery * Adopted as base for draft-ietf-quic-recovery
* Updated authors/editors list * Updated authors/editors list
* Added table of contents * Added table of contents
Appendix D. Contributors Appendix D. Contributors
The IETF QUIC Working Group received an enormous amount of support The IETF QUIC Working Group received an enormous amount of support
from many people. The following people provided substantive from many people. The following people provided substantive
contributions to this document: contributions to this document:
* Alessandro Ghedini * Alessandro Ghedini
 End of changes. 68 change blocks. 
128 lines changed or deleted 147 lines changed or added

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