draft-ietf-quic-recovery-14.txt   draft-ietf-quic-recovery-15.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: February 16, 2019 Google Expires: April 6, 2019 Google
August 15, 2018 October 03, 2018
QUIC Loss Detection and Congestion Control QUIC Loss Detection and Congestion Control
draft-ietf-quic-recovery-14 draft-ietf-quic-recovery-15
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 February 16, 2019. This Internet-Draft will expire on April 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Design of the QUIC Transmission Machinery . . . . . . . . . . 4 3. Design of the QUIC Transmission Machinery . . . . . . . . . . 4
3.1. Relevant Differences Between QUIC and TCP . . . . . . . . 5 3.1. Relevant Differences Between QUIC and TCP . . . . . . . . 5
3.1.1. Separate Packet Number Spaces . . . . . . . . . . . . 5 3.1.1. Separate Packet Number Spaces . . . . . . . . . . . . 5
3.1.2. Monotonically Increasing Packet Numbers . . . . . . . 6 3.1.2. Monotonically Increasing Packet Numbers . . . . . . . 5
3.1.3. No Reneging . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. No Reneging . . . . . . . . . . . . . . . . . . . . . 6
3.1.4. More ACK Ranges . . . . . . . . . . . . . . . . . . . 6 3.1.4. More ACK Ranges . . . . . . . . . . . . . . . . . . . 6
3.1.5. Explicit Correction For Delayed ACKs . . . . . . . . 6 3.1.5. Explicit Correction For Delayed ACKs . . . . . . . . 6
4. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 7 4. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Computing the RTT estimate . . . . . . . . . . . . . . . 7 4.1. Computing the RTT estimate . . . . . . . . . . . . . . . 7
4.1.1. Maximum Ack Delay . . . . . . . . . . . . . . . . . . 7
4.2. Ack-based Detection . . . . . . . . . . . . . . . . . . . 7 4.2. Ack-based Detection . . . . . . . . . . . . . . . . . . . 7
4.2.1. Fast Retransmit . . . . . . . . . . . . . . . . . . . 8 4.2.1. Fast Retransmit . . . . . . . . . . . . . . . . . . . 7
4.2.2. Early Retransmit . . . . . . . . . . . . . . . . . . 8 4.2.2. Early Retransmit . . . . . . . . . . . . . . . . . . 8
4.3. Timer-based Detection . . . . . . . . . . . . . . . . . . 9 4.3. Timer-based Detection . . . . . . . . . . . . . . . . . . 9
4.3.1. Crypto Handshake Timeout . . . . . . . . . . . . . . 9 4.3.1. Crypto Handshake Timeout . . . . . . . . . . . . . . 9
4.3.2. Tail Loss Probe . . . . . . . . . . . . . . . . . . . 10 4.3.2. Tail Loss Probe . . . . . . . . . . . . . . . . . . . 10
4.3.3. Retransmission Timeout . . . . . . . . . . . . . . . 11 4.3.3. Retransmission Timeout . . . . . . . . . . . . . . . 11
4.4. Generating Acknowledgements . . . . . . . . . . . . . . . 12 4.4. Generating Acknowledgements . . . . . . . . . . . . . . . 12
4.4.1. Crypto Handshake Data . . . . . . . . . . . . . . . . 13 4.4.1. Crypto Handshake Data . . . . . . . . . . . . . . . . 12
4.4.2. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 13 4.4.2. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 13
4.4.3. Receiver Tracking of ACK Frames . . . . . . . . . . . 13 4.4.3. Receiver Tracking of ACK Frames . . . . . . . . . . . 13
4.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 13
4.5.1. Constants of interest . . . . . . . . . . . . . . . . 14 4.5.1. Constants of interest . . . . . . . . . . . . . . . . 13
4.5.2. Variables of interest . . . . . . . . . . . . . . . . 14 4.5.2. Variables of interest . . . . . . . . . . . . . . . . 14
4.5.3. Initialization . . . . . . . . . . . . . . . . . . . 16 4.5.3. Initialization . . . . . . . . . . . . . . . . . . . 15
4.5.4. On Sending a Packet . . . . . . . . . . . . . . . . . 16 4.5.4. On Sending a Packet . . . . . . . . . . . . . . . . . 16
4.5.5. On Receiving an Acknowledgment . . . . . . . . . . . 17 4.5.5. On Receiving an Acknowledgment . . . . . . . . . . . 17
4.5.6. On Packet Acknowledgment . . . . . . . . . . . . . . 18 4.5.6. On Packet Acknowledgment . . . . . . . . . . . . . . 19
4.5.7. Setting the Loss Detection Timer . . . . . . . . . . 19 4.5.7. Setting the Loss Detection Timer . . . . . . . . . . 19
4.5.8. On Timeout . . . . . . . . . . . . . . . . . . . . . 21 4.5.8. On Timeout . . . . . . . . . . . . . . . . . . . . . 21
4.5.9. Detecting Lost Packets . . . . . . . . . . . . . . . 22 4.5.9. Detecting Lost Packets . . . . . . . . . . . . . . . 22
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 23 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 23
5. Congestion Control . . . . . . . . . . . . . . . . . . . . . 23 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . 23
5.1. Explicit Congestion Notification . . . . . . . . . . . . 24 5.1. Explicit Congestion Notification . . . . . . . . . . . . 24
5.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 24 5.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 24
5.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 24 5.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 24
5.5. Tail Loss Probe . . . . . . . . . . . . . . . . . . . . . 25 5.5. Tail Loss Probe . . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 19 skipping to change at page 3, line 18
5.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 26 5.8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 26
5.8.1. Constants of interest . . . . . . . . . . . . . . . . 26 5.8.1. Constants of interest . . . . . . . . . . . . . . . . 26
5.8.2. Variables of interest . . . . . . . . . . . . . . . . 26 5.8.2. Variables of interest . . . . . . . . . . . . . . . . 26
5.8.3. Initialization . . . . . . . . . . . . . . . . . . . 27 5.8.3. Initialization . . . . . . . . . . . . . . . . . . . 27
5.8.4. On Packet Sent . . . . . . . . . . . . . . . . . . . 27 5.8.4. On Packet Sent . . . . . . . . . . . . . . . . . . . 27
5.8.5. On Packet Acknowledgement . . . . . . . . . . . . . . 27 5.8.5. On Packet Acknowledgement . . . . . . . . . . . . . . 27
5.8.6. On New Congestion Event . . . . . . . . . . . . . . . 28 5.8.6. On New Congestion Event . . . . . . . . . . . . . . . 28
5.8.7. Process ECN Information . . . . . . . . . . . . . . . 28 5.8.7. Process ECN Information . . . . . . . . . . . . . . . 28
5.8.8. On Packets Lost . . . . . . . . . . . . . . . . . . . 28 5.8.8. On Packets Lost . . . . . . . . . . . . . . . . . . . 28
5.8.9. On Retransmission Timeout Verified . . . . . . . . . 28 5.8.9. On Retransmission Timeout Verified . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 29 6.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 29
6.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 29 6.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 29
6.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 29 6.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 30
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32
A.1. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 32 A.1. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 32
A.2. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 32 A.2. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 32
A.3. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 32 A.3. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 32
A.4. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 32 A.4. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 32
A.5. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 32 A.5. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 32
A.6. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 33 A.6. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 33
A.7. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 33 A.7. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 33
A.8. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 33 A.8. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 33
A.9. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 33 A.9. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 33
A.10. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 33 A.10. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 33
A.11. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 33 A.11. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 33
A.12. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 33 A.12. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 33
A.13. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 33 A.13. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 33
A.14. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 34 A.14. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 34
A.15. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 34 A.15. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 34
A.16. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 29 skipping to change at page 4, line 29
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 frames: ACK frames refer to both ACK and ACK_ECN frames in this ACK-only: Any packet containing only an ACK frame.
document.
ACK-only: Any packet containing only an ACK or ACK_ECN frame.
In-flight: Packets are considered in-flight when they have been sent In-flight: Packets are considered in-flight when they have been sent
and neither acknowledged nor declared lost, and they are not ACK- and neither acknowledged nor declared lost, and they are not ACK-
only. only.
Retransmittable Frames: All frames besides ACK, ACK_ECN, or PADDING Retransmittable Frames: All frames besides ACK or PADDING are
are considered retransmittable. considered retransmittable.
Retransmittable Packets: Packets that contain retransmittable frames Retransmittable Packets: Packets that contain retransmittable frames
elicit an ACK from the receiver and are called retransmittable elicit an ACK from the receiver and are called retransmittable
packets. packets.
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
skipping to change at page 5, line 18 skipping to change at page 5, line 16
transmissions and retransmissions and eliminates significant transmissions and retransmissions and 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 only o All packets are acknowledged, though packets that contain only ACK
ACK, ACK_ECN, and PADDING frames are not acknowledged immediately. and PADDING frames are not acknowledged immediately.
o Long header packets that contain CRYPTO frames are critical to the o 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
acknowledgement and retransmission. acknowledgement and retransmission.
o Packets that contain only ACK and ACK_ECN frames do not count o Packets that contain only ACK frames do not count toward
toward congestion control limits and are not considered in-flight. congestion control limits and are not considered in-flight. Note
Note that this means PADDING frames cause packets to contribute that this means PADDING frames cause packets to contribute toward
toward bytes in flight without directly causing an acknowledgment bytes in flight without directly causing an acknowledgment to be
to be sent. sent.
3.1. Relevant Differences Between QUIC and TCP 3.1. 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.
Protocol differences between QUIC and TCP however contribute to Protocol differences between QUIC and TCP however contribute to
algorithmic differences. We briefly describe these protocol algorithmic differences. We briefly describe these protocol
differences below. differences below.
3.1.1. Separate Packet Number Spaces 3.1.1. Separate Packet Number Spaces
skipping to change at page 7, line 34 skipping to change at page 7, line 31
ignored. ignored.
Like TCP, QUIC calculates both smoothed RTT and RTT variance similar Like TCP, QUIC calculates both smoothed RTT and RTT variance similar
to those specified in [RFC6298]. to those specified in [RFC6298].
Min RTT is the minimum RTT measured over the connection, prior to Min RTT is the minimum RTT measured over the connection, prior to
adjusting by ack delay. Ignoring ack delay for min RTT prevents adjusting by ack delay. Ignoring ack delay for min RTT prevents
intentional or unintentional underestimation of min RTT, which in intentional or unintentional underestimation of min RTT, which in
turn prevents underestimating smoothed RTT. turn prevents underestimating smoothed RTT.
4.1.1. Maximum Ack Delay
QUIC is able to explicitly model delay at the receiver via the ack
delay field in the ACK frame. Therefore, QUIC diverges from TCP by
calculating a MaxAckDelay dynamically, instead of assuming a constant
delayed ack timeout for all connections.
MaxAckDelay is the maximum ack delay supplied in an all incoming ACK
frames. MaxAckDelay excludes ack delays that aren't included in an
RTT sample because they're too large or the largest acknowledged has
already been acknowledged. MaxAckDelay also excludes ack delays
where the largest acknowledged references an ACK-only packet.
4.2. Ack-based Detection 4.2. Ack-based Detection
Ack-based loss detection implements the spirit of TCP's Fast Ack-based loss detection implements the spirit of TCP's Fast
Retransmit [RFC5681], Early Retransmit [RFC5827], FACK, and SACK loss Retransmit [RFC5681], Early Retransmit [RFC5827], FACK, and SACK loss
recovery [RFC6675]. This section provides an overview of how these recovery [RFC6675]. This section provides an overview of how these
algorithms are implemented in QUIC. algorithms are implemented in QUIC.
4.2.1. Fast Retransmit 4.2.1. Fast Retransmit
An unacknowledged packet is marked as lost when an acknowledgment is An unacknowledged packet is marked as lost when an acknowledgment is
skipping to change at page 9, line 16 skipping to change at page 8, line 45
reordering where packet whose ack triggered the Early Retransit reordering where packet whose ack triggered the Early Retransit
process encountered a shorter path; process 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 SRTT, perhaps due to a
sustained increase in the actual RTT, but the smoothed SRTT has sustained increase in the actual RTT, but the smoothed SRTT has
not yet caught up. not yet caught up.
The 1.125 multiplier increases reordering resilience. Implementers The 1.125 multiplier increases reordering resilience. Implementers
MAY experiment with using other multipliers, bearing in mind that a MAY experiment with using other multipliers, bearing in mind that a
lower multiplier reduces reordering resilience and increases spurious lower multiplier reduces reordering resilience and increases spurious
retransmissions, and a higher multipler increases loss recovery retransmissions, and a higher multiplier increases loss recovery
delay. delay.
This mechanism is based on Early Retransmit for TCP [RFC5827]. This mechanism is based on Early Retransmit for TCP [RFC5827].
However, [RFC5827] does not include the timer described above. Early However, [RFC5827] does not include the timer described above. Early
Retransmit is prone to spurious retransmissions due to its reduced Retransmit is prone to spurious retransmissions due to its reduced
reordering resilence without the timer. This observation led Linux reordering resilence without the timer. This observation led Linux
TCP implementers to implement a timer for TCP as well, and this TCP implementers to implement a timer for TCP as well, and this
document incorporates this advancement. document incorporates this advancement.
4.3. Timer-based Detection 4.3. Timer-based Detection
skipping to change at page 10, line 11 skipping to change at page 9, line 41
When CRYPTO frames are sent, the sender SHOULD set a timer for the When CRYPTO frames are sent, the sender SHOULD set a timer for the
handshake timeout period. Upon timeout, the sender MUST retransmit handshake timeout period. Upon timeout, the sender MUST retransmit
all unacknowledged CRYPTO data by calling all unacknowledged CRYPTO data by calling
RetransmitAllUnackedHandshakeData(). On each consecutive expiration RetransmitAllUnackedHandshakeData(). On each consecutive expiration
of the handshake timer without receiving an acknowledgement for a new of the handshake timer without receiving an acknowledgement for a new
packet, the sender SHOULD double the handshake timeout and set a packet, the sender SHOULD double the handshake timeout and set a
timer for this period. timer for this period.
When CRYPTO frames are outstanding, the TLP and RTO timers are not When CRYPTO frames are outstanding, the TLP and RTO timers are not
active unless the CRYPTO frames were sent at 1RTT encryption. active unless the CRYPTO frames were sent at 1-RTT encryption.
When an acknowledgement is received for a handshake packet, the new When an acknowledgement is received for a handshake packet, the new
RTT is computed and the timer SHOULD be set for twice the newly RTT is computed and the timer SHOULD be set for twice the newly
computed smoothed RTT. computed smoothed RTT.
4.3.1.1. Retry and Version Negotiation 4.3.1.1. Retry and Version Negotiation
A Retry or Version Negotiation packet causes a client to send another A Retry or Version Negotiation packet causes a client to send another
Initial packet, effectively restarting the connection process. Initial packet, effectively restarting the connection process.
skipping to change at page 12, line 21 skipping to change at page 11, line 50
period of network silence, which could be caused by a change in the period of network silence, which could be caused by a change in the
underlying network RTT. underlying network RTT.
QUIC also diverges from TCP by including MaxAckDelay in the RTO QUIC also diverges from TCP by including MaxAckDelay in the RTO
period. Since QUIC corrects for this delay in its SRTT and RTTVAR period. Since QUIC corrects for this delay in its SRTT and RTTVAR
computations, it is necessary to add this delay explicitly in the TLP computations, it is necessary to add this delay explicitly in the TLP
and RTO computation. and RTO computation.
When an acknowledgment is received for a packet sent on an RTO event, When an acknowledgment is received for a packet sent on an RTO event,
any unacknowledged packets with lower packet numbers than those any unacknowledged packets with lower packet numbers than those
acknowledged MUST be marked as lost. acknowledged MUST be marked as lost. If an acknowledgement for a
packet sent on an RTO is received at the same time packets sent prior
to the first RTO are acknowledged, the RTO is considered spurious and
standard loss detection rules apply.
A packet sent when an RTO timer expires MAY carry new data if A packet sent when an RTO timer expires MAY carry new data if
available or unacknowledged data to potentially reduce recovery time. available or unacknowledged data to potentially reduce recovery time.
Since this packet is sent as a probe into the network prior to Since this packet is sent as a probe into the network prior to
establishing any packet loss, prior unacknowledged packets SHOULD NOT establishing any packet loss, prior unacknowledged packets SHOULD NOT
be marked as lost. be marked as lost.
A packet sent on an RTO timer MUST NOT be blocked by the sender's A packet sent on an RTO timer MUST NOT be blocked by the sender's
congestion controller. A sender MUST however count these bytes as congestion controller. A sender MUST however count these bytes as
additional bytes in flight, since this packet adds network load additional bytes in flight, since this packet adds network load
without establishing packet loss. without establishing packet loss.
4.4. Generating Acknowledgements 4.4. Generating Acknowledgements
QUIC SHOULD delay sending acknowledgements in response to packets, QUIC SHOULD delay sending acknowledgements in response to packets,
but MUST NOT excessively delay acknowledgements of packets containing but MUST NOT excessively delay acknowledgements of packets containing
frames other than ACK or ACN_ECN. Specifically, implementaions MUST frames other than ACK. Specifically, implementations MUST attempt to
attempt to enforce a maximum ack delay to avoid causing the peer enforce a maximum ack delay to avoid causing the peer spurious
spurious timeouts. The RECOMMENDED maximum ack delay in QUIC is timeouts. The maximum ack delay is communicated in the
25ms. "max_ack_delay" transport parameter and the default value is 25ms.
An acknowledgement MAY be sent for every second full-sized packet, as An acknowledgement SHOULD be sent immediately upon receipt of a
TCP does [RFC5681], or may be sent less frequently, as long as the second packet but the delay SHOULD NOT exceed the maximum ack delay.
delay does not exceed the maximum ack delay. QUIC recovery QUIC recovery algorithms do not assume the peer generates an
algorithms do not assume the peer generates an acknowledgement acknowledgement immediately when receiving a second full-packet.
immediately when receiving a second full-sized packet.
Out-of-order packets SHOULD be acknowledged more quickly, in order to Out-of-order packets SHOULD be acknowledged more quickly, in order to
accelerate loss recovery. The receiver SHOULD send an immediate ACK accelerate loss recovery. The receiver SHOULD send an immediate ACK
when it receives a new packet which is not one greater than the when it receives a new packet which is not one greater than the
largest received packet number. largest received packet number.
Similarly, packets marked with the ECN Congestion Experienced (CE) Similarly, packets marked with the ECN Congestion Experienced (CE)
codepoint in the IP header SHOULD be acknowledged immediately, to codepoint in the IP header SHOULD be acknowledged immediately, to
reduce the peer's response time to congestion events. reduce the peer's response time to congestion events.
skipping to change at page 13, line 34 skipping to change at page 13, line 17
4.4.2. ACK Ranges 4.4.2. ACK Ranges
When an ACK frame is sent, one or more ranges of acknowledged packets When an ACK frame is sent, one or more ranges of acknowledged packets
are included. Including older packets reduces the chance of spurious are included. Including older packets reduces the chance of spurious
retransmits caused by losing previously sent ACK frames, at the cost retransmits caused by losing previously sent ACK frames, at the cost
of larger ACK frames. of larger ACK frames.
ACK frames SHOULD always acknowledge the most recently received ACK frames SHOULD always acknowledge the most recently received
packets, and the more out-of-order the packets are, the more packets, and the more out-of-order the packets are, the more
important it is to send an updated ACK frame quickly, to prevent the important it is to send an updated ACK frame quickly, to prevent the
peer from declaring a packet as lost and spuriusly retransmitting the peer from declaring a packet as lost and spuriously retransmitting
frames it contains. the frames it contains.
Below is one recommended approach for determining what packets to Below is one recommended approach for determining what packets to
include in an ACK frame. include in an ACK frame.
4.4.3. Receiver Tracking of ACK Frames 4.4.3. Receiver Tracking of ACK Frames
When a packet containing an ACK frame is sent, the largest When a packet containing an ACK frame is sent, the largest
acknowledged in that frame may be saved. When a packet containing an acknowledged in that frame may be saved. When a packet containing an
ACK frame is acknowledged, the receiver can stop acknowledging ACK frame is acknowledged, the receiver can stop acknowledging
packets less than or equal to the largest acknowledged in the sent packets less than or equal to the largest acknowledged in the sent
skipping to change at page 14, line 17 skipping to change at page 13, line 48
progress. progress.
4.5. Pseudocode 4.5. Pseudocode
4.5.1. Constants of interest 4.5.1. Constants of interest
Constants used in loss recovery are based on a combination of RFCs, Constants used in loss recovery are based on a combination of RFCs,
papers, and common practice. Some may need to be changed or papers, and common practice. Some may need to be changed or
negotiated in order to better suit a variety of environments. negotiated in order to better suit a variety of environments.
kMaxTLPs (RECOMMENDED 2): Maximum number of tail loss probes before kMaxTLPs: Maximum number of tail loss probes before an RTO expires.
an RTO expires. The RECOMMENDED value is 2.
kReorderingThreshold (RECOMMENDED 3): Maximum reordering in packet kReorderingThreshold: Maximum reordering in packet number space
number space before FACK style loss detection considers a packet before FACK style loss detection considers a packet lost. The
lost. RECOMMENDED value is 3.
kTimeReorderingFraction (RECOMMENDED 1/8): Maximum reordering in kTimeReorderingFraction: Maximum reordering in time space before
time space before time based loss detection considers a packet time based loss detection considers a packet lost. In fraction of
lost. In fraction of an RTT. an RTT. The RECOMMENDED value is 1/8.
kUsingTimeLossDetection (RECOMMENDED false): Whether time based loss kUsingTimeLossDetection: Whether time based loss detection is in
detection is in use. If false, uses FACK style loss detection. use. If false, uses FACK style loss detection. The RECOMMENDED
value is false.
kMinTLPTimeout (RECOMMENDED 10ms): Minimum time in the future a tail kMinTLPTimeout: Minimum time in the future a tail loss probe timer
loss probe timer may be set for. may be set for. The RECOMMENDED value is 10ms.
kMinRTOTimeout (RECOMMENDED 200ms): Minimum time in the future an kMinRTOTimeout: Minimum time in the future an RTO timer may be set
RTO timer may be set for. for. The RECOMMENDED value is 200ms.
kDelayedAckTimeout (RECOMMENDED 25ms): The length of the peer's kDelayedAckTimeout: The length of the peer's delayed ack timer. The
delayed ack timer. RECOMMENDED value is 25ms.
kInitialRtt (RECOMMENDED 100ms): The RTT used before an RTT sample kInitialRtt: The RTT used before an RTT sample is taken. The
is taken. RECOMMENDED value is 100ms.
4.5.2. Variables of interest 4.5.2. Variables of interest
Variables required to implement the congestion control mechanisms are Variables required to implement the congestion control mechanisms are
described in this section. described in this section.
loss_detection_timer: Multi-modal timer used for loss detection. loss_detection_timer: Multi-modal timer used for loss detection.
handshake_count: The number of times all unacknowledged handshake handshake_count: The number of times all unacknowledged handshake
data has been retransmitted without receiving an ack. data has been retransmitted without receiving an ack.
tlp_count: The number of times a tail loss probe has been sent tlp_count: The number of times a tail loss probe has been sent
without receiving an ack. without receiving an ack.
rto_count: The number of times an rto has been sent without rto_count: The number of times an RTO has been sent without
receiving an ack. receiving an ack.
largest_sent_before_rto: The last packet number sent prior to the largest_sent_before_rto: The last packet number sent prior to the
first retransmission timeout. first retransmission timeout.
time_of_last_sent_retransmittable_packet: The time the most recent time_of_last_sent_retransmittable_packet: The time the most recent
retransmittable packet was sent. retransmittable packet was sent.
time_of_last_sent_handshake_packet: The time the most recent packet time_of_last_sent_handshake_packet: The time the most recent packet
containing a CRYPTO frame was sent. containing a CRYPTO frame was sent.
skipping to change at page 15, line 36 skipping to change at page 15, line 21
latest_rtt: The most recent RTT measurement made when receiving an latest_rtt: The most recent RTT measurement made when receiving an
ack for a previously unacked packet. ack for a previously unacked packet.
smoothed_rtt: The smoothed RTT of the connection, computed as smoothed_rtt: The smoothed RTT of the connection, computed as
described in [RFC6298] described in [RFC6298]
rttvar: The RTT variance, computed as described in [RFC6298] rttvar: The RTT variance, computed as described in [RFC6298]
min_rtt: The minimum RTT seen in the connection, ignoring ack delay. min_rtt: The minimum RTT seen in the connection, ignoring ack delay.
max_ack_delay: The maximum ack delay in an incoming ACK frame for max_ack_delay: The maximum amount of time by which the receiver
this connection. Excludes ack delays for non-retransmittable intends to delay acknowledgments, in milliseconds. The actual
packets and those that create an RTT sample less than min_rtt. ack_delay in a received ACK frame may be larger due to late
timers, reordering, or lost ACKs.
reordering_threshold: The largest packet number gap between the reordering_threshold: The largest packet number gap between the
largest acknowledged retransmittable packet and an unacknowledged largest acknowledged retransmittable packet and an unacknowledged
retransmittable packet before it is declared lost. retransmittable packet before it is declared lost.
time_reordering_fraction: The reordering window as a fraction of time_reordering_fraction: The reordering window as a fraction of
max(smoothed_rtt, latest_rtt). max(smoothed_rtt, latest_rtt).
loss_time: The time at which the next packet will be considered lost loss_time: The time at which the next packet will be considered lost
based on early transmit or exceeding the reordering window in based on early transmit or exceeding the reordering window in
skipping to change at page 16, line 31 skipping to change at page 16, line 19
if (kUsingTimeLossDetection) if (kUsingTimeLossDetection)
reordering_threshold = infinite reordering_threshold = infinite
time_reordering_fraction = kTimeReorderingFraction time_reordering_fraction = kTimeReorderingFraction
else: else:
reordering_threshold = kReorderingThreshold reordering_threshold = kReorderingThreshold
time_reordering_fraction = infinite time_reordering_fraction = infinite
loss_time = 0 loss_time = 0
smoothed_rtt = 0 smoothed_rtt = 0
rttvar = 0 rttvar = 0
min_rtt = infinite min_rtt = infinite
max_ack_delay = 0
largest_sent_before_rto = 0 largest_sent_before_rto = 0
time_of_last_sent_retransmittable_packet = 0 time_of_last_sent_retransmittable_packet = 0
time_of_last_sent_handshake_packet = 0 time_of_last_sent_handshake_packet = 0
largest_sent_packet = 0 largest_sent_packet = 0
4.5.4. On Sending a Packet 4.5.4. On Sending a Packet
After any packet is sent, be it a new transmission or a rebundled After any packet is sent, be it a new transmission or a rebundled
transmission, the following OnPacketSent function is called. The transmission, the following OnPacketSent function is called. The
parameters to OnPacketSent are as follows: parameters to OnPacketSent are as follows:
skipping to change at page 18, line 12 skipping to change at page 18, line 12
Pseudocode for OnAckReceived and UpdateRtt follow: Pseudocode for OnAckReceived and UpdateRtt follow:
OnAckReceived(ack): OnAckReceived(ack):
largest_acked_packet = ack.largest_acked largest_acked_packet = ack.largest_acked
// If the largest acknowledged is newly acked, // If the largest acknowledged is newly acked,
// update the RTT. // update the RTT.
if (sent_packets[ack.largest_acked]): if (sent_packets[ack.largest_acked]):
latest_rtt = now - sent_packets[ack.largest_acked].time latest_rtt = now - sent_packets[ack.largest_acked].time
UpdateRtt(latest_rtt, ack.ack_delay) UpdateRtt(latest_rtt, ack.ack_delay)
// Find all newly acked packets.
for acked_packet in DetermineNewlyAckedPackets(): // Find all newly acked packets in this ACK frame
newly_acked_packets = DetermineNewlyAckedPackets(ack)
for acked_packet in newly_acked_packets:
OnPacketAcked(acked_packet.packet_number) OnPacketAcked(acked_packet.packet_number)
if !newly_acked_packets.empty():
// Find the smallest newly acknowledged packet
smallest_newly_acked =
FindSmallestNewlyAcked(newly_acked_packets)
// If any packets sent prior to RTO were acked, then the
// RTO was spurious. Otherwise, inform congestion control.
if (rto_count > 0 &&
smallest_newly_acked > largest_sent_before_rto):
OnRetransmissionTimeoutVerified(smallest_newly_acked)
handshake_count = 0
tlp_count = 0
rto_count = 0
DetectLostPackets(ack.largest_acked_packet) DetectLostPackets(ack.largest_acked_packet)
SetLossDetectionTimer() SetLossDetectionTimer()
// Process ECN information if present. // Process ECN information if present.
if (ACK frame contains ECN information): if (ACK frame contains ECN information):
ProcessECN(ack) ProcessECN(ack)
UpdateRtt(latest_rtt, ack_delay): UpdateRtt(latest_rtt, ack_delay):
// min_rtt ignores ack delay. // min_rtt ignores ack delay.
min_rtt = min(min_rtt, latest_rtt) min_rtt = min(min_rtt, latest_rtt)
// Adjust for ack delay if it's plausible. // Adjust for ack delay if it's plausible.
if (latest_rtt - min_rtt > ack_delay): if (latest_rtt - min_rtt > ack_delay):
latest_rtt -= ack_delay latest_rtt -= ack_delay
// Only save into max ack delay if it's used
// for rtt calculation and is not ack-only.
if (!sent_packets[ack.largest_acked].ack_only)
max_ack_delay = max(max_ack_delay, ack_delay)
// Based on {{RFC6298}}. // Based on {{RFC6298}}.
if (smoothed_rtt == 0): if (smoothed_rtt == 0):
smoothed_rtt = latest_rtt smoothed_rtt = latest_rtt
rttvar = latest_rtt / 2 rttvar = latest_rtt / 2
else: else:
rttvar_sample = abs(smoothed_rtt - latest_rtt) rttvar_sample = abs(smoothed_rtt - latest_rtt)
rttvar = 3/4 * rttvar + 1/4 * rttvar_sample rttvar = 3/4 * rttvar + 1/4 * rttvar_sample
smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * latest_rtt smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * latest_rtt
4.5.6. On Packet Acknowledgment 4.5.6. On Packet Acknowledgment
skipping to change at page 19, line 15 skipping to change at page 19, line 25
If this is the first acknowledgement following RTO, check if the If this is the first acknowledgement following RTO, check if the
smallest newly acknowledged packet is one sent by the RTO, and if so, smallest newly acknowledged packet is one sent by the RTO, and if so,
inform congestion control of a verified RTO, similar to F-RTO inform congestion control of a verified RTO, similar to F-RTO
[RFC5682]. [RFC5682].
Pseudocode for OnPacketAcked follows: Pseudocode for OnPacketAcked follows:
OnPacketAcked(acked_packet): OnPacketAcked(acked_packet):
if (!acked_packet.is_ack_only): if (!acked_packet.is_ack_only):
OnPacketAckedCC(acked_packet) OnPacketAckedCC(acked_packet)
// If a packet sent prior to RTO was acked, then the RTO
// was spurious. Otherwise, inform congestion control.
if (rto_count > 0 &&
acked_packet.packet_number > largest_sent_before_rto):
OnRetransmissionTimeoutVerified(
acket_packet.packet_number)
handshake_count = 0
tlp_count = 0
rto_count = 0
sent_packets.remove(acked_packet.packet_number) sent_packets.remove(acked_packet.packet_number)
4.5.7. Setting the Loss Detection Timer 4.5.7. Setting the Loss Detection Timer
QUIC loss detection uses a single timer for all timer-based loss QUIC loss detection uses a single timer for all timer-based loss
detection. The duration of the timer is based on the timer's mode, detection. The duration of the timer is based on the timer's mode,
which is set in the packet and timer events further below. The which is set in the packet and timer events further below. The
function SetLossDetectionTimer defined below shows how the single function SetLossDetectionTimer defined below shows how the single
timer is set. timer is set.
skipping to change at page 19, line 50 skipping to change at page 20, line 7
When stateless rejects are in use, the connection is considered When stateless rejects are in use, the connection is considered
immediately closed once a reject is sent, so no timer is set to immediately closed once a reject is sent, so no timer is set to
retransmit the reject. retransmit the reject.
Version negotiation packets are always stateless, and MUST be sent Version negotiation packets are always stateless, and MUST be sent
once per handshake packet that uses an unsupported QUIC version, and once per handshake packet that uses an unsupported QUIC version, and
MAY be sent in response to 0-RTT packets. MAY be sent in response to 0-RTT packets.
4.5.7.2. Tail Loss Probe and Retransmission Timer 4.5.7.2. Tail Loss Probe and Retransmission Timer
Tail loss probes [TLP] and retransmission timeouts [RFC6298] are a Tail loss probes [TLP] and retransmission timeouts [RFC6298] are
timer based mechanism to recover from cases when there are timer based mechanisms to recover from cases when there are
outstanding retransmittable packets, but an acknowledgement has not outstanding retransmittable packets, but an acknowledgement has not
been received in a timely manner. been received in a timely manner.
The TLP and RTO timers are armed when there is not unacknowledged The TLP and RTO timers are armed when there is no unacknowledged
handshake data. The TLP timer is set until the max number of TLP handshake data. The TLP timer is set until the max number of TLP
packets have been sent, and then the RTO timer is set. packets have been sent, and then the RTO timer is set.
4.5.7.3. Early Retransmit Timer 4.5.7.3. Early Retransmit Timer
Early retransmit [RFC5827] is implemented with a 1/4 RTT timer. It Early retransmit [RFC5827] is implemented with a 1/4 RTT timer. It
is part of QUIC's time based loss detection, but is always enabled, is part of QUIC's time based loss detection, but is always enabled,
even when only packet reordering loss detection is enabled. even when only packet reordering loss detection is enabled.
4.5.7.4. Pseudocode 4.5.7.4. Pseudocode
skipping to change at page 21, line 18 skipping to change at page 21, line 18
if (bytes_in_flight == 0): if (bytes_in_flight == 0):
loss_detection_timer.cancel() loss_detection_timer.cancel()
return return
if (handshake packets are outstanding): if (handshake packets are outstanding):
// Handshake retransmission timer. // Handshake retransmission timer.
if (smoothed_rtt == 0): if (smoothed_rtt == 0):
timeout = 2 * kInitialRtt timeout = 2 * kInitialRtt
else: else:
timeout = 2 * smoothed_rtt timeout = 2 * smoothed_rtt
timeout = max(timeout + max_ack_delay, kMinTLPTimeout) timeout = max(timeout, kMinTLPTimeout)
timeout = timeout * (2 ^ handshake_count) timeout = timeout * (2 ^ handshake_count)
loss_detection_timer.set( loss_detection_timer.set(
time_of_last_sent_handshake_packet + timeout) time_of_last_sent_handshake_packet + timeout)
return; return;
else if (loss_time != 0): else if (loss_time != 0):
// Early retransmit timer or time loss detection. // Early retransmit timer or time loss detection.
timeout = loss_time - timeout = loss_time -
time_of_last_sent_retransmittable_packet time_of_last_sent_retransmittable_packet
else: else:
// RTO or TLP timer // RTO or TLP timer
skipping to change at page 26, line 13 skipping to change at page 26, line 13
scheduler (fq qdisc) in Linux (3.11 onwards). scheduler (fq qdisc) in Linux (3.11 onwards).
5.8. Pseudocode 5.8. Pseudocode
5.8.1. Constants of interest 5.8.1. Constants of interest
Constants used in congestion control are based on a combination of Constants used in congestion control are based on a combination of
RFCs, papers, and common practice. Some may need to be changed or RFCs, papers, and common practice. Some may need to be changed or
negotiated in order to better suit a variety of environments. negotiated in order to better suit a variety of environments.
kMaxDatagramSize (RECOMMENDED 1200 bytes): The sender's maximum kMaxDatagramSize: The sender's maximum payload size. Does not
payload size. Does not include UDP or IP overhead. The max include UDP or IP overhead. The max packet size is used for
packet size is used for calculating initial and minimum congestion calculating initial and minimum congestion windows. The
windows. RECOMMENDED value is 1200 bytes.
kInitialWindow (RECOMMENDED min(10 * kMaxDatagramSize,
max(2* kMaxDatagramSize, 14600))): kInitialWindow: Default limit on the initial amount of outstanding
Default limit on the initial amount of outstanding data in bytes. data in bytes. Taken from [RFC6928]. The RECOMMENDED value is
Taken from [RFC6928]. the minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize,
14600)).
kMinimumWindow (RECOMMENDED 2 * kMaxDatagramSize): Minimum kMinimumWindow: Minimum congestion window in bytes. The RECOMMENDED
congestion window in bytes. value is 2 * kMaxDatagramSize.
kLossReductionFactor (RECOMMENDED 0.5): Reduction in congestion kLossReductionFactor: Reduction in congestion window when a new loss
window when a new loss event is detected. event is detected. The RECOMMENDED value is 0.5.
5.8.2. Variables of interest 5.8.2. Variables of interest
Variables required to implement the congestion control mechanisms are Variables required to implement the congestion control mechanisms are
described in this section. described in this section.
ecn_ce_counter: The highest value reported for the ECN-CE counter by ecn_ce_counter: The highest value reported for the ECN-CE counter by
the peer in an ACK_ECN frame. This variable is used to detect the peer in an ACK frame. This variable is used to detect
increases in the reported ECN-CE counter. increases in the reported ECN-CE counter.
bytes_in_flight: The sum of the size in bytes of all sent packets bytes_in_flight: The sum of the size in bytes of all sent packets
that contain at least one retransmittable or PADDING frame, and that contain at least one retransmittable or PADDING frame, and
have not been acked or declared lost. The size does not include have not been acked or declared lost. The size does not include
IP or UDP overhead, but does include the QUIC header and AEAD IP or UDP overhead, but does include the QUIC header and AEAD
overhead. Packets only containing ACK frames do not count towards overhead. Packets only containing ACK frames do not count towards
bytes_in_flight to ensure congestion control does not impede bytes_in_flight to ensure congestion control does not impede
congestion feedback. congestion feedback.
skipping to change at page 28, line 22 skipping to change at page 28, line 22
// Start a new congestion event if packet_number // Start a new congestion event if packet_number
// is larger than the end of the previous recovery epoch. // is larger than the end of the previous recovery epoch.
if (!InRecovery(packet_number)): if (!InRecovery(packet_number)):
end_of_recovery = largest_sent_packet end_of_recovery = largest_sent_packet
congestion_window *= kLossReductionFactor congestion_window *= kLossReductionFactor
congestion_window = max(congestion_window, kMinimumWindow) congestion_window = max(congestion_window, kMinimumWindow)
ssthresh = congestion_window ssthresh = congestion_window
5.8.7. Process ECN Information 5.8.7. Process ECN Information
Invoked when an ACK_ECN frame is received from the peer. Invoked when an ACK frame with an ECN section is received from the
peer.
ProcessECN(ack): ProcessECN(ack):
// If the ECN-CE counter reported by the peer has increased, // If the ECN-CE counter reported by the peer has increased,
// this could be a new congestion event. // this could be a new congestion event.
if (ack.ce_counter > ecn_ce_counter): if (ack.ce_counter > ecn_ce_counter):
ecn_ce_counter = ack.ce_counter ecn_ce_counter = ack.ce_counter
// Start a new congestion event if the last acknowledged // Start a new congestion event if the last acknowledged
// packet is past the end of the previous recovery epoch. // packet is past the end of the previous recovery epoch.
CongestionEvent(ack.largest_acked_packet) CongestionEvent(ack.largest_acked_packet)
skipping to change at page 30, line 16 skipping to change at page 30, line 22
This document has no IANA actions. Yet. This document has no IANA actions. Yet.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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-14 (work in progress), August 2018. transport-15 (work in progress), October 2018.
[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>.
skipping to change at page 32, line 5 skipping to change at page 32, line 10
[2] https://github.com/quicwg [2] https://github.com/quicwg
[3] https://github.com/quicwg/base-drafts/labels/-recovery [3] https://github.com/quicwg/base-drafts/labels/-recovery
Appendix A. Change Log Appendix A. 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.
A.1. Since draft-ietf-quic-recovery-13 A.1. Since draft-ietf-quic-recovery-14
o Used max_ack_delay from transport params (#1796, #1782)
o Merge ACK and ACK_ECN (#1783)
A.2. Since draft-ietf-quic-recovery-13
o Corrected the lack of ssthresh reduction in CongestionEvent o Corrected the lack of ssthresh reduction in CongestionEvent
pseudocode (#1598) pseudocode (#1598)
o Considerations for ECN spoofing (#1426, #1626) o Considerations for ECN spoofing (#1426, #1626)
o Clarifications for PADDING and congestion control (#837, #838, o Clarifications for PADDING and congestion control (#837, #838,
#1517, #1531, #1540) #1517, #1531, #1540)
o Reduce early retransmission timer to RTT/8 (#945, #1581) o Reduce early retransmission timer to RTT/8 (#945, #1581)
o Packets are declared lost after an RTO is verified (#935, #1582) o Packets are declared lost after an RTO is verified (#935, #1582)
A.2. Since draft-ietf-quic-recovery-12 A.3. Since draft-ietf-quic-recovery-12
o Changes to manage separate packet number spaces and encryption o Changes to manage separate packet number spaces and encryption
levels (#1190, #1242, #1413, #1450) levels (#1190, #1242, #1413, #1450)
o Added ECN feedback mechanisms and handling; new ACK_ECN frame o Added ECN feedback mechanisms and handling; new ACK_ECN frame
(#804, #805, #1372) (#804, #805, #1372)
A.3. Since draft-ietf-quic-recovery-11 A.4. Since draft-ietf-quic-recovery-11
No significant changes. No significant changes.
A.4. Since draft-ietf-quic-recovery-10 A.5. Since draft-ietf-quic-recovery-10
o Improved text on ack generation (#1139, #1159) o Improved text on ack generation (#1139, #1159)
o Make references to TCP recovery mechanisms informational (#1195) o Make references to TCP recovery mechanisms informational (#1195)
o Define time_of_last_sent_handshake_packet (#1171) o Define time_of_last_sent_handshake_packet (#1171)
o Added signal from TLS the data it includes needs to be sent in a o Added signal from TLS the data it includes needs to be sent in a
Retry packet (#1061, #1199) Retry packet (#1061, #1199)
o Minimum RTT (min_rtt) is initialized with an infinite value o Minimum RTT (min_rtt) is initialized with an infinite value
(#1169) (#1169)
A.5. Since draft-ietf-quic-recovery-09 A.6. Since draft-ietf-quic-recovery-09
No significant changes. No significant changes.
A.6. Since draft-ietf-quic-recovery-08 A.7. Since draft-ietf-quic-recovery-08
o Clarified pacing and RTO (#967, #977) o Clarified pacing and RTO (#967, #977)
A.7. Since draft-ietf-quic-recovery-07 A.8. Since draft-ietf-quic-recovery-07
o Include Ack Delay in RTO(and TLP) computations (#981) o Include Ack Delay in RTO(and TLP) computations (#981)
o Ack Delay in SRTT computation (#961) o Ack Delay in SRTT computation (#961)
o Default RTT and Slow Start (#590) o Default RTT and Slow Start (#590)
o Many editorial fixes. o Many editorial fixes.
A.8. Since draft-ietf-quic-recovery-06 A.9. Since draft-ietf-quic-recovery-06
No significant changes. No significant changes.
A.9. Since draft-ietf-quic-recovery-05 A.10. Since draft-ietf-quic-recovery-05
o Add more congestion control text (#776) o Add more congestion control text (#776)
A.10. Since draft-ietf-quic-recovery-04 A.11. Since draft-ietf-quic-recovery-04
No significant changes. No significant changes.
A.11. Since draft-ietf-quic-recovery-03 A.12. Since draft-ietf-quic-recovery-03
No significant changes. No significant changes.
A.12. Since draft-ietf-quic-recovery-02 A.13. Since draft-ietf-quic-recovery-02
o Integrate F-RTO (#544, #409) o Integrate F-RTO (#544, #409)
o Add congestion control (#545, #395) o Add congestion control (#545, #395)
o Require connection abort if a skipped packet was acknowledged o Require connection abort if a skipped packet was acknowledged
(#415) (#415)
o Simplify RTO calculations (#142, #417) o Simplify RTO calculations (#142, #417)
A.13. Since draft-ietf-quic-recovery-01 A.14. Since draft-ietf-quic-recovery-01
o Overview added to loss detection o Overview added to loss detection
o Changes initial default RTT to 100ms o Changes initial default RTT to 100ms
o Added time-based loss detection and fixes early retransmit o Added time-based loss detection and fixes early retransmit
o Clarified loss recovery for handshake packets o Clarified loss recovery for handshake packets
o Fixed references and made TCP references informative o Fixed references and made TCP references informative
A.14. Since draft-ietf-quic-recovery-00 A.15. Since draft-ietf-quic-recovery-00
o Improved description of constants and ACK behavior o Improved description of constants and ACK behavior
A.15. Since draft-iyengar-quic-loss-recovery-01 A.16. Since draft-iyengar-quic-loss-recovery-01
o Adopted as base for draft-ietf-quic-recovery o Adopted as base for draft-ietf-quic-recovery
o Updated authors/editors list o Updated authors/editors list
o Added table of contents o Added table of contents
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
 End of changes. 64 change blocks. 
142 lines changed or deleted 138 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/