draft-ietf-quic-recovery-23.txt   draft-ietf-quic-recovery-latest.txt 
QUIC Working Group J. Iyengar, Ed. QUIC Working Group J. Iyengar, Ed.
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track I. Swett, Ed. Intended status: Standards Track I. Swett, Ed.
Expires: March 15, 2020 Google Expires: April 20, 2020 Google
September 12, 2019 October 18, 2019
QUIC Loss Detection and Congestion Control QUIC Loss Detection and Congestion Control
draft-ietf-quic-recovery-23 draft-ietf-quic-recovery-latest
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 42 skipping to change at page 1, line 42
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 March 15, 2020. This Internet-Draft will expire on April 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 10 5.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 10
5.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 11
5.3. Handshakes and New Paths . . . . . . . . . . . . . . . . 12 5.3. Handshakes and New Paths . . . . . . . . . . . . . . . . 12
5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 13 5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 13
5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 14 5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 14
5.4. Retry and Version Negotiation . . . . . . . . . . . . . . 14 5.4. Retry and Version Negotiation . . . . . . . . . . . . . . 14
5.5. Discarding Keys and Packet State . . . . . . . . . . . . 14 5.5. Discarding Keys and Packet State . . . . . . . . . . . . 14
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15
6.1. Explicit Congestion Notification . . . . . . . . . . . . 15 6.1. Explicit Congestion Notification . . . . . . . . . . . . 16
6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 16 6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 16
6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 16 6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 16
6.5. Ignoring Loss of Undecryptable Packets . . . . . . . . . 16 6.5. Ignoring Loss of Undecryptable Packets . . . . . . . . . 16
6.6. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Persistent Congestion . . . . . . . . . . . . . . . . . . 17 6.7. Persistent Congestion . . . . . . . . . . . . . . . . . . 17
6.8. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.8. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.9. Under-utilizing the Congestion Window . . . . . . . . . . 18 6.9. Under-utilizing the Congestion Window . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 19 7.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 19
7.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 19 7.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 19
7.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 19 7.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 20
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 22 Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 22
A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 22 A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 22
A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 22 A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 23
A.2. Constants of interest . . . . . . . . . . . . . . . . . . 23 A.2. Constants of interest . . . . . . . . . . . . . . . . . . 23
A.3. Variables of interest . . . . . . . . . . . . . . . . . . 23 A.3. Variables of interest . . . . . . . . . . . . . . . . . . 24
A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 24 A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 24
A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 25 A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 25
A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 25 A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 25
A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 26 A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 27
A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 27 A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 27
A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 29 A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 29
A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 29 A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 29
Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 30 Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 30
B.1. Constants of interest . . . . . . . . . . . . . . . . . . 30 B.1. Constants of interest . . . . . . . . . . . . . . . . . . 30
B.2. Variables of interest . . . . . . . . . . . . . . . . . . 31 B.2. Variables of interest . . . . . . . . . . . . . . . . . . 31
B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 32 B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 32
B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 32 B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 32
B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 32 B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 32
B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 33 B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 33
skipping to change at page 10, line 51 skipping to change at page 10, line 51
reordering resilience. reordering resilience.
5.1.2. Time Threshold 5.1.2. Time Threshold
Once a later packet packet within the same packet number space has Once a later packet packet within the same packet number space has
been acknowledged, an endpoint SHOULD declare an earlier packet lost been acknowledged, an endpoint SHOULD declare an earlier packet lost
if it was sent a threshold amount of time in the past. To avoid if it was sent a threshold amount of time in the past. To avoid
declaring packets as lost too early, this time threshold MUST be set declaring packets as lost too early, this time threshold MUST be set
to at least kGranularity. The time threshold is: to at least kGranularity. The time threshold is:
kTimeThreshold * max(SRTT, latest_RTT, kGranularity) kTimeThreshold * max(smoothed_rtt, latest_rtt, kGranularity)
If packets sent prior to the largest acknowledged packet cannot yet If packets sent prior to the largest acknowledged packet cannot yet
be declared lost, then a timer SHOULD be set for the remaining time. be declared lost, then a timer SHOULD be set for the remaining time.
Using max(SRTT, latest_RTT) protects from the two following cases: Using max(smoothed_rtt, latest_rtt) protects from the two following
cases:
o the latest RTT sample is lower than the SRTT, perhaps due to o the latest RTT sample is lower than the smoothed RTT, perhaps due
reordering where the acknowledgement encountered a shorter path; to reordering where the acknowledgement encountered a shorter
path;
o the latest RTT sample is higher than the SRTT, perhaps due to a o the latest RTT sample is higher than the smoothed RTT, perhaps due
sustained increase in the actual RTT, but the smoothed SRTT has to a sustained increase in the actual RTT, but the smoothed RTT
not yet caught up. has not yet caught up.
The RECOMMENDED time threshold (kTimeThreshold), expressed as a The RECOMMENDED time threshold (kTimeThreshold), expressed as a
round-trip time multiplier, is 9/8. round-trip time multiplier, is 9/8.
Implementations MAY experiment with absolute thresholds, thresholds Implementations MAY experiment with absolute thresholds, thresholds
from previous connections, adaptive thresholds, or including RTT from previous connections, adaptive thresholds, or including RTT
variance. Smaller thresholds reduce reordering resilience and variance. Smaller thresholds reduce reordering resilience and
increase spurious retransmissions, and larger thresholds increase increase spurious retransmissions, and larger thresholds increase
loss detection delay. loss detection delay.
skipping to change at page 14, line 4 skipping to change at page 14, line 7
connection recovery latency increases exponentially as packets connection recovery latency increases exponentially as packets
continue to be dropped in the network. Sending two packets on PTO continue to be dropped in the network. Sending two packets on PTO
expiration increases resilience to packet drops, thus reducing the expiration increases resilience to packet drops, thus reducing the
probability of consecutive PTO events. probability of consecutive PTO events.
Probe packets sent on a PTO MUST be ack-eliciting. A probe packet Probe packets sent on a PTO MUST be ack-eliciting. A probe packet
SHOULD carry new data when possible. A probe packet MAY carry SHOULD carry new data when possible. A probe packet MAY carry
retransmitted unacknowledged data when new data is unavailable, when retransmitted unacknowledged data when new data is unavailable, when
flow control does not permit new data to be sent, or to flow control does not permit new data to be sent, or to
opportunistically reduce loss recovery delay. Implementations MAY opportunistically reduce loss recovery delay. Implementations MAY
use alternate strategies for determining the content of probe use alternative strategies for determining the content of probe
packets, including sending new or retransmitted data based on the packets, including sending new or retransmitted data based on the
application's priorities. application's priorities.
When the PTO timer expires multiple times and new data cannot be When the PTO timer expires multiple times and new data cannot be
sent, implementations must choose between sending the same payload sent, implementations must choose between sending the same payload
every time or sending different payloads. Sending the same payload every time or sending different payloads. Sending the same payload
may be simpler and ensures the highest priority frames arrive first. may be simpler and ensures the highest priority frames arrive first.
Sending different payloads each time reduces the chances of spurious Sending different payloads each time reduces the chances of spurious
retransmission. retransmission.
skipping to change at page 17, line 33 skipping to change at page 17, line 35
are substantially delayed. This duration is computed as follows: are substantially delayed. This duration is computed as follows:
(smoothed_rtt + 4 * rttvar + max_ack_delay) * (smoothed_rtt + 4 * rttvar + max_ack_delay) *
kPersistentCongestionThreshold kPersistentCongestionThreshold
For example, assume: For example, assume:
smoothed_rtt = 1 rttvar = 0 max_ack_delay = 0 smoothed_rtt = 1 rttvar = 0 max_ack_delay = 0
kPersistentCongestionThreshold = 3 kPersistentCongestionThreshold = 3
If an eck-eliciting packet is sent at time = 0, the following If an ack-eliciting packet is sent at time = 0, the following
scenario would illustrate persistent congestion: scenario would illustrate persistent congestion:
+-----+------------------------+ +-----+------------------------+
| t=0 | Send Pkt #1 (App Data) | | t=0 | Send Pkt #1 (App Data) |
+-----+------------------------+ +-----+------------------------+
| t=1 | Send Pkt #2 (PTO 1) | | t=1 | Send Pkt #2 (PTO 1) |
| | | | | |
| t=3 | Send Pkt #3 (PTO 2) | | t=3 | Send Pkt #3 (PTO 2) |
| | | | | |
| t=7 | Send Pkt #4 (PTO 3) | | t=7 | Send Pkt #4 (PTO 3) |
skipping to change at page 18, line 20 skipping to change at page 18, line 23
(kMinimumWindow). This response of collapsing the congestion window (kMinimumWindow). This response of collapsing the congestion window
on persistent congestion is functionally similar to a sender's on persistent congestion is functionally similar to a sender's
response on a Retransmission Timeout (RTO) in TCP [RFC5681] after response on a Retransmission Timeout (RTO) in TCP [RFC5681] after
Tail Loss Probes (TLP) [TLP]. Tail Loss Probes (TLP) [TLP].
6.8. Pacing 6.8. Pacing
This document does not specify a pacer, but it is RECOMMENDED that a This document does not specify a pacer, but it is RECOMMENDED that a
sender pace sending of all in-flight packets based on input from the sender pace sending of all in-flight packets based on input from the
congestion controller. For example, a pacer might distribute the congestion controller. For example, a pacer might distribute the
congestion window over the SRTT when used with a window-based congestion window over the smoothed RTT when used with a window-based
controller, and a pacer might use the rate estimate of a rate-based controller, and a pacer might use the rate estimate of a rate-based
controller. controller.
An implementation should take care to architect its congestion An implementation should take care to architect its congestion
controller to work well with a pacer. For instance, a pacer might controller to work well with a pacer. For instance, a pacer might
wrap the congestion controller and control the availability of the wrap the congestion controller and control the availability of the
congestion window, or a pacer might pace out packets handed to it by congestion window, or a pacer might pace out packets handed to it by
the congestion controller. Timely delivery of ACK frames is the congestion controller. Timely delivery of ACK frames is
important for efficient loss recovery. Packets containing only ACK important for efficient loss recovery. Packets containing only ACK
frames should therefore not be paced, to avoid delaying their frames should therefore not be paced, to avoid delaying their
delivery to the peer. delivery to the peer.
Sending multiple packets into the network without any delay between
them creates a packet burst that might cause short-term congestion
and losses. Implementations MUST either use pacing or limit such
bursts to minimum of 10 * kMaxDatagramSize and max(2*
kMaxDatagramSize, 14720)), the same as the recommended initial
congestion window.
As an example of a well-known and publicly available implementation As an example of a well-known and publicly available implementation
of a flow pacer, implementers are referred to the Fair Queue packet of a flow pacer, implementers are referred to the Fair Queue packet
scheduler (fq qdisc) in Linux (3.11 onwards). scheduler (fq qdisc) in Linux (3.11 onwards).
6.9. Under-utilizing the Congestion Window 6.9. Under-utilizing the Congestion Window
A congestion window that is under-utilized SHOULD NOT be increased in When bytes in flight is smaller than the congestion window and
either slow start or congestion avoidance. This can happen due to sending is not pacing limited, the congestion window is under-
insufficient application data or flow control credit. utilized. When this occurs, the congestion window SHOULD NOT be
increased in either slow start or congestion avoidance. This can
happen due to insufficient application data or flow control credit.
A sender MAY use the pipeACK method described in section 4.3 of A sender MAY use the pipeACK method described in section 4.3 of
[RFC7661] to determine if the congestion window is sufficiently [RFC7661] to determine if the congestion window is sufficiently
utilized. utilized.
A sender that paces packets (see Section 6.8) might delay sending A sender that paces packets (see Section 6.8) might delay sending
packets and not fully utilize the congestion window due to this packets and not fully utilize the congestion window due to this
delay. A sender should not consider itself application limited if it delay. A sender should not consider itself application limited if it
would have fully utilized the congestion window without pacing delay. would have fully utilized the congestion window without pacing delay.
Bursting more than an initial window's worth of data into the network A sender MAY implement alternative mechanisms to update its
might cause short-term congestion and losses. Implemementations congestion window after periods of under-utilization, such as those
SHOULD either use pacing or reduce their congestion window to limit proposed for TCP in [RFC7661].
such bursts.
A sender MAY implement alternate mechanisms to update its congestion
window after periods of under-utilization, such as those proposed for
TCP in [RFC7661].
7. Security Considerations 7. Security Considerations
7.1. Congestion Signals 7.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. On-
path attackers can spoof or alter these signals. An attacker can 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.
skipping to change at page 20, line 17 skipping to change at page 20, line 23
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] [QUIC-TLS]
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", draft-ietf-quic-tls-23 (work in progress). QUIC", draft-ietf-quic-tls-latest (work in progress).
[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", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-23 (work in progress). transport-latest (work in progress).
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 End of changes. 19 change blocks. 
31 lines changed or deleted 37 lines changed or added

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