draft-ietf-quic-recovery-latest.txt   draft-ietf-quic-recovery-auth48.txt 
skipping to change at page 2, line 7 skipping to change at line 46
(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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions
3. Design of the QUIC Transmission Machinery . . . . . . . . . . 4 3. Design of the QUIC Transmission Machinery
4. Relevant Differences Between QUIC and TCP . . . . . . . . . . 5 4. Relevant Differences between QUIC and TCP
4.1. Separate Packet Number Spaces . . . . . . . . . . . . . . 5 4.1. Separate Packet Number Spaces
4.2. Monotonically Increasing Packet Numbers . . . . . . . . . 5 4.2. Monotonically Increasing Packet Numbers
4.3. Clearer Loss Epoch . . . . . . . . . . . . . . . . . . . 5 4.3. Clearer Loss Epoch
4.4. No Reneging . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. No Reneging
4.5. More ACK Ranges . . . . . . . . . . . . . . . . . . . . . 6 4.5. More ACK Ranges
4.6. Explicit Correction For Delayed Acknowledgments . . . . . 6 4.6. Explicit Correction for Delayed Acknowledgments
4.7. Probe Timeout Replaces RTO and TLP . . . . . . . . . . . 6 4.7. Probe Timeout Replaces RTO and TLP
4.8. The Minimum Congestion Window Is Two Packets . . . . . . 7 4.8. The Minimum Congestion Window Is Two Packets
4.9. Handshake Packets Are Not Special . . . . . . . . . . . . 7 4.9. Handshake Packets Are Not Special
5. Estimating the Round-Trip Time . . . . . . . . . . . . . . . 7 5. Estimating the Round-Trip Time
5.1. Generating RTT Samples . . . . . . . . . . . . . . . . . 7 5.1. Generating RTT Samples
5.2. Estimating min_rtt . . . . . . . . . . . . . . . . . . . 8 5.2. Estimating min_rtt
5.3. Estimating smoothed_rtt and rttvar . . . . . . . . . . . 9 5.3. Estimating smoothed_rtt and rttvar
6. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 11 6. Loss Detection
6.1. Acknowledgment-Based Detection . . . . . . . . . . . . . 11 6.1. Acknowledgment-Based Detection
6.1.1. Packet Threshold . . . . . . . . . . . . . . . . . . 12 6.1.1. Packet Threshold
6.1.2. Time Threshold . . . . . . . . . . . . . . . . . . . 12 6.1.2. Time Threshold
6.2. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Probe Timeout
6.2.1. Computing PTO . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Computing PTO
6.2.2. Handshakes and New Paths . . . . . . . . . . . . . . 15 6.2.2. Handshakes and New Paths
6.2.3. Speeding up Handshake Completion . . . . . . . . . . 16 6.2.3. Speeding up Handshake Completion
6.2.4. Sending Probe Packets . . . . . . . . . . . . . . . . 17 6.2.4. Sending Probe Packets
6.3. Handling Retry Packets . . . . . . . . . . . . . . . . . 18 6.3. Handling Retry Packets
6.4. Discarding Keys and Packet State . . . . . . . . . . . . 18 6.4. Discarding Keys and Packet State
7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 19 7. Congestion Control
7.1. Explicit Congestion Notification . . . . . . . . . . . . 19 7.1. Explicit Congestion Notification
7.2. Initial and Minimum Congestion Window . . . . . . . . . . 20 7.2. Initial and Minimum Congestion Window
7.3. Congestion Control States . . . . . . . . . . . . . . . . 20 7.3. Congestion Control States
7.3.1. Slow Start . . . . . . . . . . . . . . . . . . . . . 21 7.3.1. Slow Start
7.3.2. Recovery . . . . . . . . . . . . . . . . . . . . . . 21 7.3.2. Recovery
7.3.3. Congestion Avoidance . . . . . . . . . . . . . . . . 22 7.3.3. Congestion Avoidance
7.4. Ignoring Loss of Undecryptable Packets . . . . . . . . . 22 7.4. Ignoring Loss of Undecryptable Packets
7.5. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 23 7.5. Probe Timeout
7.6. Persistent Congestion . . . . . . . . . . . . . . . . . . 23 7.6. Persistent Congestion
7.6.1. Duration . . . . . . . . . . . . . . . . . . . . . . 23 7.6.1. Duration
7.6.2. Establishing Persistent Congestion . . . . . . . . . 24 7.6.2. Establishing Persistent Congestion
7.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25 7.6.3. Example
7.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.7. Pacing
7.8. Underutilizing the Congestion Window . . . . . . . . . . 27 7.8. Underutilizing the Congestion Window
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations
8.1. Loss and Congestion Signals . . . . . . . . . . . . . . . 27 8.1. Loss and Congestion Signals
8.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 27 8.2. Traffic Analysis
8.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 27 8.3. Misreporting ECN Markings
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 28 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 29 9.2. Informative References
Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 30 Appendix A. Loss Recovery Pseudocode
A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 31 A.1. Tracking Sent Packets
A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 31 A.1.1. Sent Packet Fields
A.2. Constants of Interest . . . . . . . . . . . . . . . . . . 31 A.2. Constants of Interest
A.3. Variables of Interest . . . . . . . . . . . . . . . . . . 32 A.3. Variables of Interest
A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 33 A.4. Initialization
A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 33 A.5. On Sending a Packet
A.6. On Receiving a Datagram . . . . . . . . . . . . . . . . . 34 A.6. On Receiving a Datagram
A.7. On Receiving an Acknowledgment . . . . . . . . . . . . . 34 A.7. On Receiving an Acknowledgment
A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 36 A.8. Setting the Loss Detection Timer
A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 37 A.9. On Timeout
A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 38 A.10. Detecting Lost Packets
A.11. Upon Dropping Initial or Handshake Keys . . . . . . . . . 39 A.11. Upon Dropping Initial or Handshake Keys
Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 40 Appendix B. Congestion Control Pseudocode
B.1. Constants of Interest . . . . . . . . . . . . . . . . . . 40 B.1. Constants of Interest
B.2. Variables of Interest . . . . . . . . . . . . . . . . . . 40 B.2. Variables of Interest
B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 41 B.3. Initialization
B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 41 B.4. On Packet Sent
B.5. On Packet Acknowledgment . . . . . . . . . . . . . . . . 41 B.5. On Packet Acknowledgment
B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 42 B.6. On New Congestion Event
B.7. Process ECN Information . . . . . . . . . . . . . . . . . 43 B.7. Process ECN Information
B.8. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 43 B.8. On Packets Lost
B.9. Removing Discarded Packets from Bytes in Flight . . . . . 43 B.9. Removing Discarded Packets from Bytes in Flight
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses
1. Introduction 1. Introduction
QUIC is a secure, general-purpose transport protocol, described in QUIC is a secure, general-purpose transport protocol, described in
[QUIC-TRANSPORT]. This document describes loss detection and [QUIC-TRANSPORT]. This document describes loss detection and
congestion control mechanisms for QUIC. congestion control mechanisms for QUIC.
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",
skipping to change at page 4, line 37 skipping to change at line 173
transmissions and retransmissions; this eliminates significant transmissions and retransmissions; this eliminates significant
complexity from QUIC's interpretation of TCP loss detection complexity from QUIC's interpretation of TCP loss detection
mechanisms. mechanisms.
QUIC packets can contain multiple frames of different types. The QUIC packets can contain multiple frames of different types. The
recovery mechanisms ensure that data and frames that need reliable recovery mechanisms ensure that data and frames that need reliable
delivery are acknowledged or declared lost and sent in new packets as delivery are acknowledged or declared lost and sent in new packets as
necessary. The types of frames contained in a packet affect recovery necessary. The types of frames contained in a packet affect recovery
and congestion control logic: and congestion control logic:
o All packets are acknowledged, though packets that contain no ack- * All packets are acknowledged, though packets that contain no ack-
eliciting frames are only acknowledged along with ack-eliciting eliciting frames are only acknowledged along with ack-eliciting
packets. packets.
o Long header packets that contain CRYPTO frames are critical to the * Long header packets that contain CRYPTO frames are critical to the
performance of the QUIC handshake and use shorter timers for performance of the QUIC handshake and use shorter timers for
acknowledgment. acknowledgment.
o Packets containing frames besides ACK or CONNECTION_CLOSE frames * Packets containing frames besides ACK or CONNECTION_CLOSE frames
count toward congestion control limits and are considered to be in count toward congestion control limits and are considered to be in
flight. flight.
o PADDING frames cause packets to contribute toward bytes in flight * PADDING frames cause packets to contribute toward bytes in flight
without directly causing an acknowledgment to be sent. without directly causing an acknowledgment to be sent.
4. Relevant Differences Between QUIC and TCP 4. Relevant Differences between QUIC and TCP
Readers familiar with TCP's loss detection and congestion control Readers familiar with TCP's loss detection and congestion control
will find algorithms here that parallel well-known TCP ones. will find algorithms here that parallel well-known TCP ones.
However, protocol differences between QUIC and TCP contribute to However, protocol differences between QUIC and TCP contribute to
algorithmic differences. These protocol differences are briefly algorithmic differences. These protocol differences are briefly
described below. described below.
4.1. Separate Packet Number Spaces 4.1. Separate Packet Number Spaces
QUIC uses separate packet number spaces for each encryption level, QUIC uses separate packet number spaces for each encryption level,
skipping to change at page 6, line 24 skipping to change at line 256
implementations on both sides and reducing memory pressure on the implementations on both sides and reducing memory pressure on the
sender. sender.
4.5. More ACK Ranges 4.5. More ACK Ranges
QUIC supports many ACK ranges, as opposed to TCP's three SACK ranges. QUIC supports many ACK ranges, as opposed to TCP's three SACK ranges.
In high-loss environments, this speeds recovery, reduces spurious In high-loss environments, this speeds recovery, reduces spurious
retransmits, and ensures forward progress without relying on retransmits, and ensures forward progress without relying on
timeouts. timeouts.
4.6. Explicit Correction For Delayed Acknowledgments 4.6. Explicit Correction for Delayed Acknowledgments
QUIC endpoints measure the delay incurred between when a packet is QUIC endpoints measure the delay incurred between when a packet is
received and when the corresponding acknowledgment is sent, allowing received and when the corresponding acknowledgment is sent, allowing
a peer to maintain a more accurate RTT estimate; see Section 13.2 of a peer to maintain a more accurate RTT estimate; see Section 13.2 of
[QUIC-TRANSPORT]. [QUIC-TRANSPORT].
4.7. Probe Timeout Replaces RTO and TLP 4.7. Probe Timeout Replaces RTO and TLP
QUIC uses a probe timeout (PTO; see Section 6.2), with a timer based QUIC uses a probe timeout (PTO; see Section 6.2), with a timer based
on TCP's retransmission timeout (RTO) computation; see [RFC6298]. on TCP's retransmission timeout (RTO) computation; see [RFC6298].
skipping to change at page 7, line 45 skipping to change at line 325
for each path: the minimum value over a period of time (min_rtt), an for each path: the minimum value over a period of time (min_rtt), an
exponentially weighted moving average (smoothed_rtt), and the mean exponentially weighted moving average (smoothed_rtt), and the mean
deviation (referred to as "variation" in the rest of this document) deviation (referred to as "variation" in the rest of this document)
in the observed RTT samples (rttvar). in the observed RTT samples (rttvar).
5.1. Generating RTT Samples 5.1. Generating RTT Samples
An endpoint generates an RTT sample on receiving an ACK frame that An endpoint generates an RTT sample on receiving an ACK frame that
meets the following two conditions: meets the following two conditions:
o the largest acknowledged packet number is newly acknowledged, and * the largest acknowledged packet number is newly acknowledged, and
o at least one of the newly acknowledged packets was ack-eliciting. * at least one of the newly acknowledged packets was ack-eliciting.
The RTT sample, latest_rtt, is generated as the time elapsed since The RTT sample, latest_rtt, is generated as the time elapsed since
the largest acknowledged packet was sent: the largest acknowledged packet was sent:
latest_rtt = ack_time - send_time_of_largest_acked latest_rtt = ack_time - send_time_of_largest_acked
An RTT sample is generated using only the largest acknowledged packet An RTT sample is generated using only the largest acknowledged packet
in the received ACK frame. This is because a peer reports in the received ACK frame. This is because a peer reports
acknowledgment delays for only the largest acknowledged packet in an acknowledgment delays for only the largest acknowledged packet in an
ACK frame. While the reported acknowledgment delay is not used by ACK frame. While the reported acknowledgment delay is not used by
the RTT sample measurement, it is used to adjust the RTT sample in the RTT sample measurement, it is used to adjust the RTT sample in
subsequent computations of smoothed_rtt and rttvar (Section 5.3). subsequent computations of smoothed_rtt and rttvar (Section 5.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.
skipping to change at page 10, line 8 skipping to change at line 433
by the peer that are greater than the peer's max_ack_delay are by the peer that are greater than the peer's max_ack_delay are
attributed to unintentional but potentially repeating delays, such as attributed to unintentional but potentially repeating delays, such as
scheduler latency at the peer or loss of previous acknowledgments. scheduler latency at the peer or loss of previous acknowledgments.
Excess delays could also be due to a noncompliant receiver. Excess delays could also be due to a noncompliant receiver.
Therefore, these extra delays are considered effectively part of path Therefore, these extra delays are considered effectively part of path
delay and incorporated into the RTT estimate. delay and incorporated into the RTT estimate.
Therefore, when adjusting an RTT sample using peer-reported Therefore, when adjusting an RTT sample using peer-reported
acknowledgment delays, an endpoint: acknowledgment delays, an endpoint:
o MAY ignore the acknowledgment delay for Initial packets, since * MAY ignore the acknowledgment delay for Initial packets, since
these acknowledgments are not delayed by the peer (Section 13.2.1 these acknowledgments are not delayed by the peer (Section 13.2.1
of [QUIC-TRANSPORT]); of [QUIC-TRANSPORT]);
o SHOULD ignore the peer's max_ack_delay until the handshake is * SHOULD ignore the peer's max_ack_delay until the handshake is
confirmed; confirmed;
o MUST use the lesser of the acknowledgment delay and the peer's * MUST use the lesser of the acknowledgment delay and the peer's
max_ack_delay after the handshake is confirmed; and max_ack_delay after the handshake is confirmed; and
o MUST NOT subtract the acknowledgment delay from the RTT sample if * MUST NOT subtract the acknowledgment delay from the RTT sample if
the resulting value is smaller than the min_rtt. This limits the the resulting value is smaller than the min_rtt. This limits the
underestimation of the smoothed_rtt due to a misreporting peer. underestimation of the smoothed_rtt due to a misreporting peer.
Additionally, an endpoint might postpone the processing of Additionally, an endpoint might postpone the processing of
acknowledgments when the corresponding decryption keys are not acknowledgments when the corresponding decryption keys are not
immediately available. For example, a client might receive an immediately available. For example, a client might receive an
acknowledgment for a 0-RTT packet that it cannot decrypt because acknowledgment for a 0-RTT packet that it cannot decrypt because
1-RTT packet protection keys are not yet available to it. In such 1-RTT packet protection keys are not yet available to it. In such
cases, an endpoint SHOULD subtract such local delays from its RTT cases, an endpoint SHOULD subtract such local delays from its RTT
sample until the handshake is confirmed. sample until the handshake is confirmed.
skipping to change at page 11, line 50 skipping to change at line 523
Acknowledgment-based loss detection implements the spirit of TCP's Acknowledgment-based loss detection implements the spirit of TCP's
Fast Retransmit [RFC5681], Early Retransmit [RFC5827], Forward Fast Retransmit [RFC5681], Early Retransmit [RFC5827], Forward
Acknowledgment [FACK], SACK loss recovery [RFC6675], and RACK-TLP Acknowledgment [FACK], SACK loss recovery [RFC6675], and RACK-TLP
[RFC8985]. This section provides an overview of how these algorithms [RFC8985]. This section provides an overview of how these algorithms
are implemented in QUIC. are implemented in QUIC.
A packet is declared lost if it meets all of the following A packet is declared lost if it meets all of the following
conditions: conditions:
o The packet is unacknowledged, in flight, and was sent prior to an * The packet is unacknowledged, in flight, and was sent prior to an
acknowledged packet. acknowledged packet.
o The packet was sent kPacketThreshold packets before an * The packet was sent kPacketThreshold packets before an
acknowledged packet (Section 6.1.1), or it was sent long enough in acknowledged packet (Section 6.1.1), or it was sent long enough in
the past (Section 6.1.2). the past (Section 6.1.2).
The acknowledgment indicates that a packet sent later was delivered, The acknowledgment indicates that a packet sent later was delivered,
and the packet and time thresholds provide some tolerance for packet and the packet and time thresholds provide some tolerance for packet
reordering. reordering.
Spuriously declaring packets as lost leads to unnecessary Spuriously declaring packets as lost leads to unnecessary
retransmissions and may result in degraded performance due to the retransmissions and may result in degraded performance due to the
actions of the congestion controller upon detecting loss. actions of the congestion controller upon detecting loss.
skipping to change at page 13, line 8 skipping to change at line 577
constant. The time threshold is: constant. The time threshold is:
max(kTimeThreshold * max(smoothed_rtt, latest_rtt), kGranularity) max(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(smoothed_rtt, latest_rtt) protects from the two following Using max(smoothed_rtt, latest_rtt) protects from the two following
cases: cases:
o the latest RTT sample is lower than the smoothed RTT, perhaps due * the latest RTT sample is lower than the smoothed RTT, perhaps due
to reordering where the acknowledgment encountered a shorter path; to reordering where the acknowledgment encountered a shorter path;
o the latest RTT sample is higher than the smoothed RTT, perhaps due * the latest RTT sample is higher than the smoothed RTT, perhaps due
to a sustained increase in the actual RTT, but the smoothed RTT to a sustained increase in the actual RTT, but the smoothed RTT
has not yet caught up. has not yet caught up.
The RECOMMENDED time threshold (kTimeThreshold), expressed as an RTT The RECOMMENDED time threshold (kTimeThreshold), expressed as an RTT
multiplier, is 9/8. The RECOMMENDED value of the timer granularity multiplier, is 9/8. The RECOMMENDED value of the timer granularity
(kGranularity) is 1 millisecond. (kGranularity) is 1 millisecond.
Note: TCP's RACK [RFC8985] specifies a slightly larger threshold, | Note: TCP's RACK [RFC8985] specifies a slightly larger
equivalent to 5/4, for a similar purpose. Experience with QUIC | threshold, equivalent to 5/4, for a similar purpose.
shows that 9/8 works well. | Experience with QUIC shows that 9/8 works well.
Implementations MAY experiment with absolute thresholds, thresholds Implementations MAY experiment with absolute thresholds, thresholds
from previous connections, adaptive thresholds, or the including of from previous connections, adaptive thresholds, or the including of
RTT variation. Smaller thresholds reduce reordering resilience and RTT variation. 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.
6.2. Probe Timeout 6.2. Probe Timeout
A Probe Timeout (PTO) triggers the sending of one or two probe A Probe Timeout (PTO) triggers the sending of one or two probe
skipping to change at page 24, line 16 skipping to change at line 1097
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 after the receipt of an A sender establishes persistent congestion after the receipt of an
acknowledgment if two packets that are ack-eliciting are declared acknowledgment if two packets that are ack-eliciting are declared
lost, and: lost, and:
o across all packet number spaces, none of the packets sent between * across all packet number spaces, none of the packets sent between
the send times of these two packets are acknowledged; the send times of these two packets are acknowledged;
o 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
o a prior RTT sample existed when these two 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 These two packets MUST be ack-eliciting, since a receiver is required
to acknowledge only ack-eliciting packets within its maximum to acknowledge only ack-eliciting packets within its maximum
acknowledgment delay; see Section 13.2 of [QUIC-TRANSPORT]. acknowledgment 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
skipping to change at page 25, line 15 skipping to change at line 1140
7.6.3. Example 7.6.3. Example
The following example illustrates how a sender might establish The following example illustrates how a sender might establish
persistent congestion. Assume: persistent congestion. Assume:
smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2 smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay = 2
kPersistentCongestionThreshold = 3 kPersistentCongestionThreshold = 3
Consider the following sequence of events: Consider the following sequence of events:
+--------+-----------------------------------+ +========+===================================+
| Time | Action | | Time | Action |
+--------+-----------------------------------+ +========+===================================+
| t=0 | Send packet #1 (application data) | | t=0 | Send packet #1 (application data) |
| | | +--------+-----------------------------------+
| t=1 | Send packet #2 (application data) | | t=1 | Send packet #2 (application data) |
| | | +--------+-----------------------------------+
| t=1.2 | Receive acknowledgment of #1 | | t=1.2 | Receive acknowledgment of #1 |
| | | +--------+-----------------------------------+
| t=2 | Send packet #3 (application data) | | t=2 | Send packet #3 (application data) |
| | | +--------+-----------------------------------+
| t=3 | Send packet #4 (application data) | | t=3 | Send packet #4 (application data) |
| | | +--------+-----------------------------------+
| t=4 | Send packet #5 (application data) | | t=4 | Send packet #5 (application data) |
| | | +--------+-----------------------------------+
| t=5 | Send packet #6 (application data) | | t=5 | Send packet #6 (application data) |
| | | +--------+-----------------------------------+
| t=6 | Send packet #7 (application data) | | t=6 | Send packet #7 (application data) |
| | | +--------+-----------------------------------+
| t=8 | Send packet #8 (PTO 1) | | t=8 | Send packet #8 (PTO 1) |
| | | +--------+-----------------------------------+
| t=12 | Send packet #9 (PTO 2) | | t=12 | Send packet #9 (PTO 2) |
| | | +--------+-----------------------------------+
| t=12.2 | Receive acknowledgment of #9 | | t=12.2 | Receive acknowledgment of #9 |
+--------+-----------------------------------+ +--------+-----------------------------------+
Table 1
Packets 2 through 8 are declared lost when the acknowledgment for Packets 2 through 8 are declared lost when the acknowledgment for
packet 9 is received at "t = 12.2". packet 9 is received at "t = 12.2".
The congestion period is calculated as the time between the oldest The congestion period is calculated as the time between the oldest
and newest lost packets: "8 - 1 = 7". The persistent congestion and newest lost packets: "8 - 1 = 7". The persistent congestion
duration is "2 * 3 = 6". Because the threshold was reached and duration is "2 * 3 = 6". Because the threshold was reached and
because none of the packets between the oldest and the newest lost because none of the packets between the oldest and the newest lost
packets were acknowledged, the network is considered to have packets were acknowledged, the network is considered to have
experienced persistent congestion. experienced persistent congestion.
skipping to change at page 28, line 22 skipping to change at line 1295
Endpoints choose the congestion controller that they use. Congestion Endpoints choose the congestion controller that they use. Congestion
controllers respond to reports of ECN-CE by reducing their rate, but controllers respond to reports of ECN-CE by reducing their rate, but
the response may vary. Markings can be treated as equivalent to loss the response may vary. Markings can be treated as equivalent to loss
[RFC3168], but other responses can be specified, such as [RFC8511] or [RFC3168], but other responses can be specified, such as [RFC8511] or
[RFC8311]. [RFC8311].
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", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>. <https://www.rfc-editor.org/info/rfc9001>.
[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", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 29, line 8 skipping to change at line 1326
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>.
[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>.
9.2. Informative References 9.2. Informative References
[FACK] Mathis, M. and J. Mahdavi, "Forward acknowledgement: [FACK] Mathis, M. and J. Mahdavi, "Forward acknowledgement:
Refining TCP Congestion Control", Refining TCP Congestion Control", ACM SIGCOMM Computer
DOI 10.1145/248157.248181, ACM SIGCOMM Computer Communication Review, DOI 10.1145/248157.248181, August
Communication Review, August 1996. 1996, <https://doi.org/10.1145/248157.248181>.
[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>.
[RETRANSMISSION] [RETRANSMISSION]
Karn, P. and C. Partridge, "Improving Round-Trip Time Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", Estimates in Reliable Transport Protocols", ACM
DOI 10.1145/118544.118549, ACM Transactions on Computer Transactions on Computer Systems,
Systems, November 1991. DOI 10.1145/118544.118549, November 1991,
<https://doi.org/10.1145/118544.118549>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>. <https://www.rfc-editor.org/info/rfc2018>.
[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>.
skipping to change at page 44, line 17 skipping to change at line 2040
foreach packet in discarded_packets: foreach packet in discarded_packets:
if packet.in_flight if packet.in_flight
bytes_in_flight -= size bytes_in_flight -= size
Contributors 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:
o Alessandro Ghedini * Alessandro Ghedini
* Benjamin Saunders
o Benjamin Saunders * Gorry Fairhurst
* 山本和彦 (Kazu Yamamoto)
o Gorry Fairhurst * 奥 一穂 (Kazuho Oku)
* Lars Eggert
o Kazu Yamamoto * Magnus Westerlund
* Marten Seemann
o Kazuho Oku * Martin Duke
* Martin Thomson
o Lars Eggert * Mirja Kühlewind
* Nick Banks
o Magnus Westerlund * Praveen Balasubramanian
o Marten Seemann
o Martin Duke
o Martin Thomson
o Mirja Kuehlewind
o Nick Banks
o Praveen Balasubramanian
Authors' Addresses Authors' Addresses
Jana Iyengar (editor) Jana Iyengar (editor)
Fastly Fastly
Email: jri.ietf@gmail.com Email: jri.ietf@gmail.com
Ian Swett (editor) Ian Swett (editor)
Google Google
 End of changes. 39 change blocks. 
141 lines changed or deleted 133 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/