draft-ietf-quic-recovery-15.txt   draft-ietf-quic-recovery-16.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: April 6, 2019 Google Expires: April 26, 2019 Google
October 03, 2018 October 23, 2018
QUIC Loss Detection and Congestion Control QUIC Loss Detection and Congestion Control
draft-ietf-quic-recovery-15 draft-ietf-quic-recovery-16
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 April 6, 2019. This Internet-Draft will expire on April 26, 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 . . . . . . . 5 3.1.2. Monotonically Increasing Packet Numbers . . . . . . . 6
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.2. Ack-based Detection . . . . . . . . . . . . . . . . . . . 7 4.2. Ack-based Detection . . . . . . . . . . . . . . . . . . . 7
4.2.1. Fast Retransmit . . . . . . . . . . . . . . . . . . . 7 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 Retransmission 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 . . . . . . . . . . . . . . . . 12 4.4.1. Crypto Handshake Data . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Constants of interest . . . . . . . . . . . . . . . . 13 4.5.1. Constants of interest . . . . . . . . . . . . . . . . 14
4.5.2. Variables of interest . . . . . . . . . . . . . . . . 14 4.5.2. Variables of interest . . . . . . . . . . . . . . . . 14
4.5.3. Initialization . . . . . . . . . . . . . . . . . . . 15 4.5.3. Initialization . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . 20
4.5.9. Detecting Lost Packets . . . . . . . . . . . . . . . 22 4.5.9. Detecting Lost Packets . . . . . . . . . . . . . . . 21
4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 23 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 22
5. Congestion Control . . . . . . . . . . . . . . . . . . . . . 23 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . 22
5.1. Explicit Congestion Notification . . . . . . . . . . . . 24 5.1. Explicit Congestion Notification . . . . . . . . . . . . 23
5.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 24 5.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 23
5.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 24 5.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 23
5.5. Tail Loss Probe . . . . . . . . . . . . . . . . . . . . . 25 5.5. Tail Loss Probe . . . . . . . . . . . . . . . . . . . . . 24
5.6. Retransmission Timeout . . . . . . . . . . . . . . . . . 25 5.6. Retransmission Timeout . . . . . . . . . . . . . . . . . 24
5.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.7. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 26 5.8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 25
5.8.1. Constants of interest . . . . . . . . . . . . . . . . 26 5.8.1. Constants of interest . . . . . . . . . . . . . . . . 25
5.8.2. Variables of interest . . . . . . . . . . . . . . . . 26 5.8.2. Variables of interest . . . . . . . . . . . . . . . . 25
5.8.3. Initialization . . . . . . . . . . . . . . . . . . . 27 5.8.3. Initialization . . . . . . . . . . . . . . . . . . . 26
5.8.4. On Packet Sent . . . . . . . . . . . . . . . . . . . 27 5.8.4. On Packet Sent . . . . . . . . . . . . . . . . . . . 26
5.8.5. On Packet Acknowledgement . . . . . . . . . . . . . . 27 5.8.5. On Packet Acknowledgement . . . . . . . . . . . . . . 26
5.8.6. On New Congestion Event . . . . . . . . . . . . . . . 28 5.8.6. On New Congestion Event . . . . . . . . . . . . . . . 27
5.8.7. Process ECN Information . . . . . . . . . . . . . . . 28 5.8.7. Process ECN Information . . . . . . . . . . . . . . . 27
5.8.8. On Packets Lost . . . . . . . . . . . . . . . . . . . 28 5.8.8. On Packets Lost . . . . . . . . . . . . . . . . . . . 27
5.8.9. On Retransmission Timeout Verified . . . . . . . . . 29 5.8.9. On Retransmission Timeout Verified . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 29 6.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 28
6.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 29 6.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 28
6.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 29 6.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 29
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31
A.1. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 32 A.1. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 31
A.2. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 32 A.2. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 31
A.3. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 32 A.3. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 31
A.4. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 32 A.4. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 31
A.5. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 32 A.5. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 31
A.6. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 33 A.6. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 32
A.7. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 33 A.7. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 32
A.8. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 33 A.8. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 32
A.9. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 33 A.9. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 32
A.10. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 33 A.10. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 32
A.11. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 33 A.11. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 32
A.12. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 33 A.12. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 32
A.13. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 33 A.13. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 32
A.14. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 34 A.14. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 33
A.15. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 34 A.15. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 33
A.16. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 34 A.16. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 33
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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].
QUIC implements the spirit of known TCP loss recovery mechanisms, QUIC implements the spirit of known TCP loss recovery mechanisms,
described in RFCs, various Internet-drafts, and also those prevalent described in RFCs, various Internet-drafts, and also those prevalent
skipping to change at page 4, line 42 skipping to change at page 4, line 42
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 or PADDING are Retransmittable Frames: All frames besides ACK or PADDING 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.
Crypto Packets: Packets containing CRYPTO data sent in Initial or
Handshake 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
indicates the packet number space, as described in [QUIC-TRANSPORT]. indicates the packet number space, as described in [QUIC-TRANSPORT].
Packet numbers never repeat within a packet number space for the Packet numbers never repeat within a packet number space for the
lifetime of a connection. Packet numbers monotonically increase lifetime of a connection. Packet numbers monotonically increase
within a space, preventing ambiguity. within a space, preventing ambiguity.
skipping to change at page 9, line 11 skipping to change at page 9, line 16
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
Timer-based loss detection recovers from losses that cannot be Timer-based loss detection recovers from losses that cannot be
handled by ack-based loss detection. It uses a single timer which handled by ack-based loss detection. It uses a single timer which
switches between a handshake retransmission timer, a Tail Loss Probe switches between a crypto retransmission timer, a Tail Loss Probe
timer and Retransmission Timeout mechanisms. timer and Retransmission Timeout mechanisms.
4.3.1. Crypto Handshake Timeout 4.3.1. Crypto Retransmission Timeout
Data in CRYPTO frames is critical to QUIC transport and crypto Data in CRYPTO frames is critical to QUIC transport and crypto
negotiation, so a more aggressive timeout is used to retransmit it. negotiation, so a more aggressive timeout is used to retransmit it.
Below, the term "handshake packet" is used to refer to packets
containing CRYPTO frames, not packets with the specific long header
packet type Handshake.
The initial handshake timeout SHOULD be set to twice the initial RTT. The initial crypto retransmission timeout SHOULD be set to twice the
initial RTT.
At the beginning, there are no prior RTT samples within a connection. At the beginning, there are no prior RTT samples within a connection.
Resumed connections over the same network SHOULD use the previous Resumed connections over the same network SHOULD use the previous
connection's final smoothed RTT value as the resumed connection's connection's final smoothed RTT value as the resumed connection's
initial RTT. initial RTT. If no previous RTT is available, or if the network
changes, the initial RTT SHOULD be set to 100ms. When an
acknowledgement is received, a new RTT is computed and the timer
SHOULD be set for twice the newly computed smoothed RTT.
If no previous RTT is available, or if the network changes, the When crypto packets are sent, the sender MUST set a timer for the
initial RTT SHOULD be set to 100ms. crypto timeout period. Upon timeout, the sender MUST retransmit all
unacknowledged CRYPTO data if possible.
When CRYPTO frames are sent, the sender SHOULD set a timer for the Until the server has validated the client's address on the path, the
handshake timeout period. Upon timeout, the sender MUST retransmit number of bytes it can send is limited, as specified in
all unacknowledged CRYPTO data by calling [QUIC-TRANSPORT]. If not all unacknowledged CRYPTO data can be sent,
RetransmitAllUnackedHandshakeData(). On each consecutive expiration then all unacknowledged CRYPTO data sent in Initial packets should be
of the handshake timer without receiving an acknowledgement for a new retransmitted. If no bytes can be sent, then no alarm should be
packet, the sender SHOULD double the handshake timeout and set a armed until bytes have been received from the client.
timer for this period.
When CRYPTO frames are outstanding, the TLP and RTO timers are not Because the server could be blocked until more packets are received,
active unless the CRYPTO frames were sent at 1-RTT encryption. the client MUST start the crypto retransmission timer even if there
is no unacknowledged CRYPTO data. If the timer expires and the
client has no CRYPTO data to retransmit and does not have Handshake
keys, it SHOULD send an Initial packet in a UDP datagram of at least
1200 octets. If the client has Handshake keys, it SHOULD send a
Handshake packet.
When an acknowledgement is received for a handshake packet, the new On each consecutive expiration of the crypto timer without receiving
RTT is computed and the timer SHOULD be set for twice the newly an acknowledgement for a new packet, the sender SHOULD double the
computed smoothed RTT. crypto retransmission timeout and set a timer for this period.
When crypto packets are outstanding, the TLP and RTO timers are not
active.
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.
Either packet indicates that the Initial was received but not Either packet indicates that the Initial was received but not
processed. Neither packet can be treated as an acknowledgment for processed. Neither packet can be treated as an acknowledgment for
the Initial, but they MAY be used to improve the RTT estimate. the Initial, but they MAY be used to improve the RTT estimate.
skipping to change at page 12, line 49 skipping to change at page 13, line 13
reduce the peer's response time to congestion events. reduce the peer's response time to congestion events.
As an optimization, a receiver MAY process multiple packets before As an optimization, a receiver MAY process multiple packets before
sending any ACK frames in response. In this case they can determine sending any ACK frames in response. In this case they can determine
whether an immediate or delayed acknowledgement should be generated whether an immediate or delayed acknowledgement should be generated
after processing incoming packets. after processing incoming packets.
4.4.1. Crypto Handshake Data 4.4.1. Crypto Handshake Data
In order to quickly complete the handshake and avoid spurious In order to quickly complete the handshake and avoid spurious
retransmissions due to handshake timeouts, handshake packets SHOULD retransmissions due to crypto retransmission timeouts, crypto packets
use a very short ack delay, such as 1ms. ACK frames MAY be sent SHOULD use a very short ack delay, such as 1ms. ACK frames MAY be
immediately when the crypto stack indicates all data for that sent immediately when the crypto stack indicates all data for that
encryption level has been received. encryption level has been received.
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
skipping to change at page 14, line 36 skipping to change at page 14, line 47
kInitialRtt: The RTT used before an RTT sample is taken. The kInitialRtt: The RTT used before an RTT sample is taken. The
RECOMMENDED value is 100ms. 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 crypto_count: The number of times all unacknowledged CRYPTO data has
data has been retransmitted without receiving an ack. 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_crypto_packet: The time the most recent crypto
containing a CRYPTO frame was sent. packet was sent.
largest_sent_packet: The packet number of the most recently sent largest_sent_packet: The packet number of the most recently sent
packet. packet.
largest_acked_packet: The largest packet number acknowledged in an largest_acked_packet: The largest packet number acknowledged in an
ACK frame. ACK frame.
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.
skipping to change at page 16, line 6 skipping to change at page 16, line 16
number, and packets remain in sent_packets until acknowledged or number, and packets remain in sent_packets until acknowledged or
lost. A sent_packets data structure is maintained per packet lost. A sent_packets data structure is maintained per packet
number space, and ACK processing only applies to a single space. number space, and ACK processing only applies to a single space.
4.5.3. Initialization 4.5.3. Initialization
At the beginning of the connection, initialize the loss detection At the beginning of the connection, initialize the loss detection
variables as follows: variables as follows:
loss_detection_timer.reset() loss_detection_timer.reset()
handshake_count = 0 crypto_count = 0
tlp_count = 0 tlp_count = 0
rto_count = 0 rto_count = 0
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
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_crypto_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:
o packet_number: The packet number of the sent packet. o packet_number: The packet number of the sent packet.
o ack_only: A boolean that indicates whether a packet contains only o ack_only: A boolean that indicates whether a packet contains only
ACK or PADDING frame(s). If true, it is still expected an ack ACK or PADDING frame(s). If true, it is still expected an ack
will be received for this packet, but it is not retransmittable. will be received for this packet, but it is not retransmittable.
o in_flight: A boolean that indicates whether the packet counts o in_flight: A boolean that indicates whether the packet counts
towards bytes in flight. towards bytes in flight.
o is_handshake_packet: A boolean that indicates whether the packet o is_crypto_packet: A boolean that indicates whether the packet
contains cryptographic handshake messages critical to the contains cryptographic handshake messages critical to the
completion of the QUIC handshake. In this version of QUIC, this completion of the QUIC handshake. In this version of QUIC, this
includes any packet with the long header that includes a CRYPTO includes any packet with the long header that includes a CRYPTO
frame. frame.
o sent_bytes: The number of bytes sent in the packet, not including o sent_bytes: The number of bytes sent in the packet, not including
UDP or IP overhead, but including QUIC framing overhead. UDP or IP overhead, but including QUIC framing overhead.
Pseudocode for OnPacketSent follows: Pseudocode for OnPacketSent follows:
OnPacketSent(packet_number, ack_only, in_flight, OnPacketSent(packet_number, ack_only, in_flight,
is_handshake_packet, sent_bytes): is_crypto_packet, sent_bytes):
largest_sent_packet = packet_number largest_sent_packet = packet_number
sent_packets[packet_number].packet_number = packet_number sent_packets[packet_number].packet_number = packet_number
sent_packets[packet_number].time = now sent_packets[packet_number].time = now
sent_packets[packet_number].ack_only = ack_only sent_packets[packet_number].ack_only = ack_only
sent_packets[packet_number].in_flight = in_flight sent_packets[packet_number].in_flight = in_flight
if !ack_only: if !ack_only:
if is_handshake_packet: if is_crypto_packet:
time_of_last_sent_handshake_packet = now time_of_last_sent_crypto_packet = now
time_of_last_sent_retransmittable_packet = now time_of_last_sent_retransmittable_packet = now
OnPacketSentCC(sent_bytes) OnPacketSentCC(sent_bytes)
sent_packets[packet_number].bytes = sent_bytes sent_packets[packet_number].bytes = sent_bytes
SetLossDetectionTimer() SetLossDetectionTimer()
4.5.5. On Receiving an Acknowledgment 4.5.5. On Receiving an Acknowledgment
When an ACK frame is received, it may newly acknowledge any number of When an ACK frame is received, it may newly acknowledge any number of
packets. packets.
skipping to change at page 18, line 27 skipping to change at page 18, line 27
if !newly_acked_packets.empty(): if !newly_acked_packets.empty():
// Find the smallest newly acknowledged packet // Find the smallest newly acknowledged packet
smallest_newly_acked = smallest_newly_acked =
FindSmallestNewlyAcked(newly_acked_packets) FindSmallestNewlyAcked(newly_acked_packets)
// If any packets sent prior to RTO were acked, then the // If any packets sent prior to RTO were acked, then the
// RTO was spurious. Otherwise, inform congestion control. // RTO was spurious. Otherwise, inform congestion control.
if (rto_count > 0 && if (rto_count > 0 &&
smallest_newly_acked > largest_sent_before_rto): smallest_newly_acked > largest_sent_before_rto):
OnRetransmissionTimeoutVerified(smallest_newly_acked) OnRetransmissionTimeoutVerified(smallest_newly_acked)
handshake_count = 0 crypto_count = 0
tlp_count = 0 tlp_count = 0
rto_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)
skipping to change at page 19, line 35 skipping to change at page 19, line 35
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.
4.5.7.1. Handshake Timer
When a connection has unacknowledged handshake data, the handshake
timer is set and when it expires, all unacknowledgedd handshake data
is retransmitted.
When stateless rejects are in use, the connection is considered
immediately closed once a reject is sent, so no timer is set to
retransmit the reject.
Version negotiation packets are always stateless, and MUST be sent
once per handshake packet that uses an unsupported QUIC version, and
MAY be sent in response to 0-RTT packets.
4.5.7.2. Tail Loss Probe and Retransmission Timer
Tail loss probes [TLP] and retransmission timeouts [RFC6298] are
timer based mechanisms to recover from cases when there are
outstanding retransmittable packets, but an acknowledgement has not
been received in a timely manner.
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
packets have been sent, and then the RTO timer is set.
4.5.7.3. Early Retransmit Timer
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,
even when only packet reordering loss detection is enabled.
4.5.7.4. Pseudocode
Pseudocode for SetLossDetectionTimer follows: Pseudocode for SetLossDetectionTimer follows:
SetLossDetectionTimer(): SetLossDetectionTimer():
// Don't arm timer if there are no retransmittable packets // Don't arm timer if there are no retransmittable packets
// in flight. // in flight.
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 (crypto packets are outstanding):
// Handshake retransmission timer. // Crypto 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, kMinTLPTimeout) timeout = max(timeout, kMinTLPTimeout)
timeout = timeout * (2 ^ handshake_count) timeout = timeout * (2 ^ crypto_count)
loss_detection_timer.set( loss_detection_timer.set(
time_of_last_sent_handshake_packet + timeout) time_of_last_sent_crypto_packet + timeout)
return; return
else if (loss_time != 0): 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
// Calculate RTO duration // Calculate RTO duration
timeout = timeout =
smoothed_rtt + 4 * rttvar + max_ack_delay smoothed_rtt + 4 * rttvar + max_ack_delay
timeout = max(timeout, kMinRTOTimeout) timeout = max(timeout, kMinRTOTimeout)
timeout = timeout * (2 ^ rto_count) timeout = timeout * (2 ^ rto_count)
skipping to change at page 21, line 45 skipping to change at page 20, line 45
// Tail Loss Probe // Tail Loss Probe
tlp_timeout = max(1.5 * smoothed_rtt tlp_timeout = max(1.5 * smoothed_rtt
+ max_ack_delay, kMinTLPTimeout) + max_ack_delay, kMinTLPTimeout)
timeout = min(tlp_timeout, timeout) timeout = min(tlp_timeout, timeout)
loss_detection_timer.set( loss_detection_timer.set(
time_of_last_sent_retransmittable_packet + timeout) time_of_last_sent_retransmittable_packet + timeout)
4.5.8. On Timeout 4.5.8. On Timeout
QUIC uses one loss recovery timer, which when set, can be in one of When the loss detection timer expires, the timer's mode determines
several modes. When the timer expires, the mode determines the the action to be performed.
action to be performed.
Pseudocode for OnLossDetectionTimeout follows: Pseudocode for OnLossDetectionTimeout follows:
OnLossDetectionTimeout(): OnLossDetectionTimeout():
if (handshake packets are outstanding): if (crypto packets are outstanding):
// Handshake timeout. // Crypto retransmission timeout.
RetransmitAllUnackedHandshakeData() RetransmitUnackedCryptoData()
handshake_count++ crypto_count++
else if (loss_time != 0): else if (loss_time != 0):
// Early retransmit or Time Loss Detection // Early retransmit or Time Loss Detection
DetectLostPackets(largest_acked_packet) DetectLostPackets(largest_acked_packet)
else if (tlp_count < kMaxTLPs): else if (tlp_count < kMaxTLPs):
// Tail Loss Probe. // Tail Loss Probe.
SendOnePacket() SendOnePacket()
tlp_count++ tlp_count++
else: else:
// RTO. // RTO.
if (rto_count == 0) if (rto_count == 0)
skipping to change at page 29, line 16 skipping to change at page 28, line 16
QUIC decreases the congestion window to the minimum value once the QUIC decreases the congestion window to the minimum value once the
retransmission timeout has been verified and removes any packets sent retransmission timeout has been verified and removes any packets sent
before the newly acknowledged RTO packet. before the newly acknowledged RTO packet.
OnRetransmissionTimeoutVerified(packet_number) OnRetransmissionTimeoutVerified(packet_number)
congestion_window = kMinimumWindow congestion_window = kMinimumWindow
// Declare all packets prior to packet_number lost. // Declare all packets prior to packet_number lost.
for (sent_packet: sent_packets): for (sent_packet: sent_packets):
if (sent_packet.packet_number < packet_number): if (sent_packet.packet_number < packet_number):
bytes_in_flight -= lost_packet.bytes bytes_in_flight -= sent_packet.bytes
sent_packets.remove(sent_packet.packet_number) sent_packets.remove(sent_packet.packet_number)
6. Security Considerations 6. Security Considerations
6.1. Congestion Signals 6.1. Congestion Signals
Congestion control fundamentally involves the consumption of signals Congestion control fundamentally involves the consumption of signals
- both loss and ECN codepoints - from unauthenticated entities. On- - both loss and ECN codepoints - from unauthenticated entities. On-
path attackers can spoof or alter these signals. An attacker can path attackers can spoof or alter these signals. An attacker can
cause endpoints to reduce their sending rate by dropping packets, or cause endpoints to reduce their sending rate by dropping packets, or
skipping to change at page 30, line 22 skipping to change at page 29, 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-15 (work in progress), October 2018. transport-16 (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>.
 End of changes. 36 change blocks. 
142 lines changed or deleted 120 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/