draft-ietf-quic-recovery-25.txt   draft-ietf-quic-recovery-26.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: 25 July 2020 Google Expires: 24 August 2020 Google
22 January 2020 21 February 2020
QUIC Loss Detection and Congestion Control QUIC Loss Detection and Congestion Control
draft-ietf-quic-recovery-25 draft-ietf-quic-recovery-26
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), which is archived at mailing list (quic@ietf.org), which is archived at
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 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 25 July 2020. This Internet-Draft will expire on 24 August 2020.
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
skipping to change at page 2, line 47 skipping to change at page 2, line 47
5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 14 5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 14
5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 15 5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 15
5.4. Handling Retry Packets . . . . . . . . . . . . . . . . . 15 5.4. Handling Retry Packets . . . . . . . . . . . . . . . . . 15
5.5. Discarding Keys and Packet State . . . . . . . . . . . . 15 5.5. Discarding Keys and Packet State . . . . . . . . . . . . 15
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 16 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 16
6.1. Explicit Congestion Notification . . . . . . . . . . . . 16 6.1. Explicit Congestion Notification . . . . . . . . . . . . 16
6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 17 6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 17
6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 17 6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 17
6.5. Ignoring Loss of Undecryptable Packets . . . . . . . . . 17 6.5. Ignoring Loss of Undecryptable Packets . . . . . . . . . 17
6.6. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 18
6.7. Persistent Congestion . . . . . . . . . . . . . . . . . . 18 6.7. Persistent Congestion . . . . . . . . . . . . . . . . . . 18
6.8. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.8. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.9. Under-utilizing the Congestion Window . . . . . . . . . . 19 6.9. Under-utilizing the Congestion Window . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 20 7.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 20
7.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 20 7.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 20
7.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 20 7.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 23 Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 23
A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 23 A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 23
A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 23 A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 24
A.2. Constants of interest . . . . . . . . . . . . . . . . . . 24 A.2. Constants of interest . . . . . . . . . . . . . . . . . . 24
A.3. Variables of interest . . . . . . . . . . . . . . . . . . 24 A.3. Variables of interest . . . . . . . . . . . . . . . . . . 25
A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 25 A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 25
A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 25 A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 26
A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 26 A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 26
A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 27 A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 28
A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 28 A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 28
A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 30 A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 30
A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 30 A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 30
Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 31 Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 31
B.1. Constants of interest . . . . . . . . . . . . . . . . . . 31 B.1. Constants of interest . . . . . . . . . . . . . . . . . . 31
B.2. Variables of interest . . . . . . . . . . . . . . . . . . 32 B.2. Variables of interest . . . . . . . . . . . . . . . . . . 32
B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 33 B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 33
B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 33 B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 33
B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 33 B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 33
B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 34 B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 34
B.7. Process ECN Information . . . . . . . . . . . . . . . . . 34 B.7. Process ECN Information . . . . . . . . . . . . . . . . . 34
B.8. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 35 B.8. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35
C.1. Since draft-ietf-quic-recovery-24 . . . . . . . . . . . . 35 C.1. Since draft-ietf-quic-recovery-25 . . . . . . . . . . . . 35
C.2. Since draft-ietf-quic-recovery-23 . . . . . . . . . . . . 35 C.2. Since draft-ietf-quic-recovery-24 . . . . . . . . . . . . 35
C.3. Since draft-ietf-quic-recovery-22 . . . . . . . . . . . . 36 C.3. Since draft-ietf-quic-recovery-23 . . . . . . . . . . . . 35
C.4. Since draft-ietf-quic-recovery-21 . . . . . . . . . . . . 36 C.4. Since draft-ietf-quic-recovery-22 . . . . . . . . . . . . 36
C.5. Since draft-ietf-quic-recovery-20 . . . . . . . . . . . . 36 C.5. Since draft-ietf-quic-recovery-21 . . . . . . . . . . . . 36
C.6. Since draft-ietf-quic-recovery-19 . . . . . . . . . . . . 36 C.6. Since draft-ietf-quic-recovery-20 . . . . . . . . . . . . 36
C.7. Since draft-ietf-quic-recovery-18 . . . . . . . . . . . . 37 C.7. Since draft-ietf-quic-recovery-19 . . . . . . . . . . . . 36
C.8. Since draft-ietf-quic-recovery-17 . . . . . . . . . . . . 37 C.8. Since draft-ietf-quic-recovery-18 . . . . . . . . . . . . 37
C.9. Since draft-ietf-quic-recovery-16 . . . . . . . . . . . . 37 C.9. Since draft-ietf-quic-recovery-17 . . . . . . . . . . . . 37
C.10. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 38 C.10. Since draft-ietf-quic-recovery-16 . . . . . . . . . . . . 38
C.11. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 38 C.11. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 38
C.12. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 39 C.12. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 38
C.13. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 39 C.13. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 39
C.14. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 39 C.14. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 39
C.15. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 39 C.15. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 39
C.16. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 39 C.16. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 39
C.17. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 39 C.17. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 39
C.18. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 39 C.18. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 39
C.19. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 40 C.19. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 40
C.20. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 40 C.20. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 40
C.21. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 40 C.21. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 40
C.22. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 40 C.22. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 40
C.23. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 40 C.23. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 40
C.24. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 40 C.24. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 40
C.25. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 40 C.25. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 40
C.26. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 41
Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 41 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
QUIC is a new multiplexed and secure transport atop UDP. QUIC builds QUIC is a new multiplexed and secure transport atop UDP. QUIC builds
on decades of transport and security experience, and implements on decades of transport and security experience, and implements
mechanisms that make it attractive as a modern general-purpose mechanisms that make it attractive as a modern general-purpose
transport. The QUIC protocol is described in [QUIC-TRANSPORT]. transport. The QUIC protocol is described in [QUIC-TRANSPORT].
skipping to change at page 4, line 37 skipping to change at page 4, line 38
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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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-only: Any packet containing only one or more ACK frame(s).
In-flight: Packets are considered in-flight when they have been sent
and are not ACK-only, and they are not acknowledged, declared
lost, or abandoned along with old keys.
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 ack delay and elicit an ACK from the receiver within the maximum ack delay and
are called ack-eliciting packets. are called ack-eliciting packets.
In-flight: Packets are considered in-flight when they are ack-
eliciting or contain a PADDING frame, and they have been sent but
are not acknowledged, declared lost, or abandoned along with 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 20 skipping to change at page 6, line 20
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.
3.1.2. Monotonically Increasing Packet Numbers 3.1.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, which results in retransmissions of the same data
carrying the same sequence number, and consequently leads to carrying the same sequence number, and consequently leads to
"retransmission ambiguity". QUIC separates the two: QUIC uses a "retransmission ambiguity". QUIC separates the two. QUIC uses a
packet number to indicate transmission order, and any application packet number to indicate transmission order. Application data is
data is sent in one or more streams, with delivery order determined sent in one or more streams and delivery order is determined by
by stream offsets encoded within STREAM frames. 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 rebundles containing ack-eliciting frames is detected lost, QUIC rebundles
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
skipping to change at page 8, line 17 skipping to change at page 8, line 17
reported ACK delay is not used by the RTT sample measurement, it is reported ACK delay is not used by the RTT sample measurement, it is
used to adjust the RTT sample in subsequent computations of used to adjust the RTT sample in subsequent computations of
smoothed_rtt and rttvar Section 4.3. smoothed_rtt and rttvar Section 4.3.
To avoid generating multiple RTT samples for a single packet, an ACK To avoid generating multiple RTT samples for a single packet, an ACK
frame SHOULD NOT be used to update RTT estimates if it does not newly frame SHOULD NOT be used to update RTT estimates if it does not newly
acknowledge the largest acknowledged packet. acknowledge the largest acknowledged packet.
An RTT sample MUST NOT be generated on receiving an ACK frame that An RTT sample MUST NOT be generated on receiving an ACK frame that
does not newly acknowledge at least one ack-eliciting packet. A peer does not newly acknowledge at least one ack-eliciting packet. A peer
does not send an ACK frame on receiving only non-ack-eliciting usually does not send an ACK frame when only non-ack-eliciting
packets, so an ACK frame that is subsequently sent can include an packets are received. Therefore an ACK frame that contains
arbitrarily large Ack Delay field. Ignoring such ACK frames avoids acknowledgements for only non-ack-eliciting packets could include an
arbitrarily large Ack Delay value. Ignoring such ACK frames avoids
complications in subsequent smoothed_rtt and rttvar computations. complications in subsequent smoothed_rtt and rttvar computations.
A sender might generate multiple RTT samples per RTT when multiple A sender might generate multiple RTT samples per RTT when multiple
ACK frames are received within an RTT. As suggested in [RFC6298], ACK frames are received within an RTT. As suggested in [RFC6298],
doing so might result in inadequate history in smoothed_rtt and doing so might result in inadequate history in smoothed_rtt and
rttvar. Ensuring that RTT estimates retain sufficient history is an rttvar. Ensuring that RTT estimates retain sufficient history is an
open research question. open research question.
4.2. Estimating min_rtt 4.2. Estimating min_rtt
skipping to change at page 9, line 12 skipping to change at page 9, line 12
adapt to it, allowing future RTT samples that are smaller than the adapt to it, allowing future RTT samples that are smaller than the
new RTT be included in smoothed_rtt. new RTT be included in smoothed_rtt.
4.3. Estimating smoothed_rtt and rttvar 4.3. Estimating smoothed_rtt and rttvar
smoothed_rtt is an exponentially-weighted moving average of an smoothed_rtt is an exponentially-weighted moving average of an
endpoint's RTT samples, and rttvar is the variation in the RTT endpoint's RTT samples, and rttvar is the variation in the RTT
samples, estimated using a mean variation. samples, estimated using a mean variation.
The calculation of smoothed_rtt uses path latency after adjusting RTT The calculation of smoothed_rtt uses path latency after adjusting RTT
samples for ACK delays. For packets sent in the ApplicationData samples for acknowledgement delays. These delays are computed using
packet number space, a peer limits any delay in sending an the ACK Delay field of the ACK frame as described in Section 19.3 of
acknowledgement for an ack-eliciting packet to no greater than the [QUIC-TRANSPORT]. For packets sent in the ApplicationData packet
value it advertised in the max_ack_delay transport parameter. number space, a peer limits any delay in sending an acknowledgement
Consequently, when a peer reports an Ack Delay that is greater than for an ack-eliciting packet to no greater than the value it
its max_ack_delay, the delay is attributed to reasons out of the advertised in the max_ack_delay transport parameter. Consequently,
peer's control, such as scheduler latency at the peer or loss of when a peer reports an Ack Delay that is greater than its
previous ACK frames. Any delays beyond the peer's max_ack_delay are max_ack_delay, the delay is attributed to reasons out of the peer's
therefore considered effectively part of path delay and incorporated control, such as scheduler latency at the peer or loss of previous
into the smoothed_rtt estimate. ACK frames. Any delays beyond the peer's max_ack_delay are therefore
considered effectively part of path delay and incorporated into the
smoothed_rtt estimate.
When adjusting an RTT sample using peer-reported acknowledgement When adjusting an RTT sample using peer-reported acknowledgement
delays, an endpoint: delays, an endpoint:
* MUST ignore the Ack Delay field of the ACK frame for packets sent * MUST ignore the Ack Delay field of the ACK frame for packets sent
in the Initial and Handshake packet number space. in the Initial and Handshake packet number space.
* MUST use the lesser of the value reported in Ack Delay field of * MUST use the lesser of the value reported in Ack Delay field of
the ACK frame and the peer's max_ack_delay transport parameter. the ACK frame and the peer's max_ack_delay transport parameter.
skipping to change at page 10, line 16 skipping to change at page 10, line 16
adjusted_rtt = latest_rtt adjusted_rtt = latest_rtt
if (min_rtt + ack_delay < latest_rtt): if (min_rtt + ack_delay < latest_rtt):
adjusted_rtt = latest_rtt - ack_delay adjusted_rtt = latest_rtt - ack_delay
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt
rttvar_sample = abs(smoothed_rtt - adjusted_rtt) rttvar_sample = abs(smoothed_rtt - adjusted_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
5. Loss Detection 5. Loss Detection
QUIC senders use acknowledgements to detect lost packets, and a probe QUIC senders use acknowledgements to detect lost packets, and a probe
time out Section 5.2 to ensure acknowledgements are received. This time out (see Section 5.2) to ensure acknowledgements are received.
section provides a description of these algorithms. This section provides a description of these algorithms.
If a packet is lost, the QUIC transport needs to recover from that If a packet is lost, the QUIC transport needs to recover from that
loss, such as by retransmitting the data, sending an updated frame, loss, such as by retransmitting the data, sending an updated frame,
or abandoning the frame. For more information, see Section 13.3 of or abandoning the frame. For more information, see Section 13.3 of
[QUIC-TRANSPORT]. [QUIC-TRANSPORT].
5.1. Acknowledgement-based Detection 5.1. Acknowledgement-based Detection
Acknowledgement-based loss detection implements the spirit of TCP's Acknowledgement-based loss detection implements the spirit of TCP's
Fast Retransmit [RFC5681], Early Retransmit [RFC5827], FACK [FACK], Fast Retransmit [RFC5681], Early Retransmit [RFC5827], FACK [FACK],
skipping to change at page 12, line 35 skipping to change at page 12, line 35
kGranularity, smoothed_rtt, rttvar, and max_ack_delay are defined in kGranularity, smoothed_rtt, rttvar, and max_ack_delay are defined in
Appendix A.2 and Appendix A.3. Appendix A.2 and Appendix A.3.
The PTO period is the amount of time that a sender ought to wait for The PTO period is the amount of time that a sender ought to wait for
an acknowledgement of a sent packet. This time period includes the an acknowledgement of a sent packet. This time period includes the
estimated network roundtrip-time (smoothed_rtt), the variation in the estimated network roundtrip-time (smoothed_rtt), the variation in the
estimate (4*rttvar), and max_ack_delay, to account for the maximum estimate (4*rttvar), and max_ack_delay, to account for the maximum
time by which a receiver might delay sending an acknowledgement. time by which a receiver might delay sending an acknowledgement.
When the PTO is armed for Initial or Handshake packet number spaces, When the PTO is armed for Initial or Handshake packet number spaces,
the max_ack_delay is 0, as specified in 13.2.5 of [QUIC-TRANSPORT]. the max_ack_delay is 0, as specified in 13.2.1 of [QUIC-TRANSPORT].
The PTO value MUST be set to at least kGranularity, to avoid the The PTO value MUST be set to at least kGranularity, to avoid the
timer expiring immediately. timer expiring immediately.
A sender computes its PTO timer every time an ack-eliciting packet is A sender computes its PTO timer every time an ack-eliciting packet is
sent. When ack-eliciting packets are in-flight in multiple packet sent. When ack-eliciting packets are in-flight in multiple packet
number spaces, the timer MUST be set for the packet number space with number spaces, the timer MUST be set for the packet number space with
the earliest timeout, except for ApplicationData, which MUST be the earliest timeout, except for ApplicationData, which MUST be
ignored until the handshake completes; see Section 4.1.1 of ignored until the handshake completes; see Section 4.1.1 of
[QUIC-TLS]. Not arming the PTO for ApplicationData prioritizes [QUIC-TLS]. Not arming the PTO for ApplicationData prioritizes
skipping to change at page 13, line 14 skipping to change at page 13, line 14
or acknowledgements due to severe congestion. Even when there are or acknowledgements due to severe congestion. Even when there are
ack-eliciting packets in-flight in multiple packet number spaces, the ack-eliciting packets in-flight in multiple packet number spaces, the
exponential increase in probe timeout occurs across all spaces to exponential increase in probe timeout occurs across all spaces to
prevent excess load on the network. For example, a timeout in the prevent excess load on the network. For example, a timeout in the
Initial packet number space doubles the length of the timeout in the Initial packet number space doubles the length of the timeout in the
Handshake packet number space. Handshake packet number space.
The life of a connection that is experiencing consecutive PTOs is The life of a connection that is experiencing consecutive PTOs is
limited by the endpoint's idle timeout. limited by the endpoint's idle timeout.
The probe timer is not set if the time threshold Section 5.1.2 loss The probe timer MUST NOT be set if the time threshold Section 5.1.2
detection timer is set. The time threshold loss detection timer is loss detection timer is set. The time threshold loss detection timer
expected to both expire earlier than the PTO and be less likely to is expected to both expire earlier than the PTO and be less likely to
spuriously retransmit data. spuriously retransmit data.
5.3. Handshakes and New Paths 5.3. Handshakes and New Paths
The initial probe timeout for a new connection or new path SHOULD be The initial probe timeout for a new connection or new path SHOULD be
set to twice the initial RTT. Resumed connections over the same set to twice the initial RTT. Resumed connections over the same
network SHOULD use the previous connection's final smoothed RTT value network SHOULD use the previous connection's final smoothed RTT value
as the resumed connection's initial RTT. If no previous RTT is as the resumed connection's initial RTT. If no previous RTT is
available, the initial RTT SHOULD be set to 500ms, resulting in a 1 available, the initial RTT SHOULD be set to 500ms, resulting in a 1
second initial timeout as recommended in [RFC6298]. second initial timeout as recommended in [RFC6298].
skipping to change at page 17, line 25 skipping to change at page 17, line 25
Slow start exits to congestion avoidance. Congestion avoidance in Slow start exits to congestion avoidance. Congestion avoidance in
NewReno uses an additive increase multiplicative decrease (AIMD) NewReno uses an additive increase multiplicative decrease (AIMD)
approach that increases the congestion window by one maximum packet approach that increases the congestion window by one maximum packet
size per congestion window acknowledged. When a loss is detected, size per congestion window acknowledged. When a loss is detected,
NewReno halves the congestion window and sets the slow start NewReno halves the congestion window and sets the slow start
threshold to the new congestion window. threshold to the new congestion window.
6.4. Recovery Period 6.4. Recovery Period
Recovery is a period of time beginning with detection of a lost A recovery period is entered when loss or ECN-CE marking of a packet
packet or an increase in the ECN-CE counter. Because QUIC does not is detected. A recovery period ends when a packet sent during the
retransmit packets, it defines the end of recovery as a packet sent recovery period is acknowledged. This is slightly different from
after the start of recovery being acknowledged. This is slightly TCP's definition of recovery, which ends when the lost packet that
different from TCP's definition of recovery, which ends when the lost started recovery is acknowledged.
packet that started recovery is acknowledged.
The recovery period limits congestion window reduction to once per The recovery period limits congestion window reduction to once per
round trip. During recovery, the congestion window remains unchanged round trip. During recovery, the congestion window remains unchanged
irrespective of new losses or increases in the ECN-CE counter. irrespective of new losses or increases in the ECN-CE counter.
6.5. Ignoring Loss of Undecryptable Packets 6.5. Ignoring Loss of Undecryptable Packets
During the handshake, some packet protection keys might not be During the handshake, some packet protection keys might not be
available when a packet arrives. In particular, Handshake and 0-RTT available when a packet arrives. In particular, Handshake and 0-RTT
packets cannot be processed until the Initial packets arrive, and packets cannot be processed until the Initial packets arrive, and
skipping to change at page 21, line 17 skipping to change at page 21, line 28
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. Yet. This document has no IANA actions. Yet.
9. References 9. References
9.1. Normative References 9.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-25, 22 January 2020, tls-26, 21 February 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-25>. <https://tools.ietf.org/html/draft-ietf-quic-tls-26>.
[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-25, 22 January Internet-Draft, draft-ietf-quic-transport-26, 21 February
2020, <https://tools.ietf.org/html/draft-ietf-quic- 2020, <https://tools.ietf.org/html/draft-ietf-quic-
transport-25>. transport-26>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
skipping to change at page 35, line 37 skipping to change at page 35, line 37
if (InPersistentCongestion(largest_lost_packet)): if (InPersistentCongestion(largest_lost_packet)):
congestion_window = kMinimumWindow congestion_window = kMinimumWindow
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-24 C.1. Since draft-ietf-quic-recovery-25
No significant changes.
C.2. 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.2. Since draft-ietf-quic-recovery-23 C.3. 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.3. Since draft-ietf-quic-recovery-22 C.4. 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.4. Since draft-ietf-quic-recovery-21 C.5. Since draft-ietf-quic-recovery-21
* No changes * No changes
C.5. Since draft-ietf-quic-recovery-20 C.6. 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.6. Since draft-ietf-quic-recovery-19 C.7. 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 37, line 7 skipping to change at page 37, line 13
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.7. Since draft-ietf-quic-recovery-18 C.8. 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.8. Since draft-ietf-quic-recovery-17 C.9. 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 37, line 50 skipping to change at page 38, line 8
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.9. Since draft-ietf-quic-recovery-16 C.10. 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 38, line 33 skipping to change at page 38, line 39
* 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.10. Since draft-ietf-quic-recovery-14 C.11. 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.11. Since draft-ietf-quic-recovery-13 C.12. 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)
* Packets are declared lost after an RTO is verified (#935, #1582) * Packets are declared lost after an RTO is verified (#935, #1582)
C.12. Since draft-ietf-quic-recovery-12 C.13. 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.13. Since draft-ietf-quic-recovery-11 C.14. Since draft-ietf-quic-recovery-11
No significant changes. No significant changes.
C.14. Since draft-ietf-quic-recovery-10 C.15. 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.15. Since draft-ietf-quic-recovery-09 C.16. Since draft-ietf-quic-recovery-09
No significant changes. No significant changes.
C.16. Since draft-ietf-quic-recovery-08 C.17. Since draft-ietf-quic-recovery-08
* Clarified pacing and RTO (#967, #977) * Clarified pacing and RTO (#967, #977)
C.17. Since draft-ietf-quic-recovery-07 C.18. 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.18. Since draft-ietf-quic-recovery-06 C.19. Since draft-ietf-quic-recovery-06
No significant changes. No significant changes.
C.19. Since draft-ietf-quic-recovery-05 C.20. Since draft-ietf-quic-recovery-05
* Add more congestion control text (#776) * Add more congestion control text (#776)
C.20. Since draft-ietf-quic-recovery-04 C.21. Since draft-ietf-quic-recovery-04
No significant changes. No significant changes.
C.21. Since draft-ietf-quic-recovery-03 C.22. Since draft-ietf-quic-recovery-03
No significant changes. No significant changes.
C.22. Since draft-ietf-quic-recovery-02 C.23. 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.23. Since draft-ietf-quic-recovery-01 C.24. 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.24. Since draft-ietf-quic-recovery-00 C.25. Since draft-ietf-quic-recovery-00
* Improved description of constants and ACK behavior * Improved description of constants and ACK behavior
C.25. Since draft-iyengar-quic-loss-recovery-01 C.26. 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
 End of changes. 51 change blocks. 
102 lines changed or deleted 107 lines changed or added

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