| draft-ietf-quic-recovery-25.txt | draft-ietf-quic-recovery-26.txt | |||
|---|---|---|---|---|
| QUIC J. Iyengar, Ed. | QUIC J. Iyengar, Ed. | |||
| Internet-Draft Fastly | Internet-Draft Fastly | |||
| Intended status: Standards Track I. Swett, Ed. | Intended status: Standards Track I. Swett, Ed. | |||
| Expires: 25 July 2020 Google | Expires: 24 August 2020 Google | |||
| 22 January 2020 | 21 February 2020 | |||
| QUIC Loss Detection and Congestion Control | QUIC Loss Detection and Congestion Control | |||
| draft-ietf-quic-recovery-25 | draft-ietf-quic-recovery-26 | |||
| Abstract | Abstract | |||
| This document describes loss detection and congestion control | This document describes loss detection and congestion control | |||
| mechanisms for QUIC. | mechanisms for QUIC. | |||
| Note to Readers | Note to Readers | |||
| Discussion of this draft takes place on the QUIC working group | Discussion of this draft takes place on the QUIC working group | |||
| mailing list (quic@ietf.org), which is archived at | mailing list (quic@ietf.org), which is archived at | |||
| skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 25 July 2020. | This Internet-Draft will expire on 24 August 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 47 ¶ | skipping to change at page 2, line 47 ¶ | |||
| 5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 14 | 5.3.1. Sending Probe Packets . . . . . . . . . . . . . . . . 14 | |||
| 5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 15 | 5.3.2. Loss Detection . . . . . . . . . . . . . . . . . . . 15 | |||
| 5.4. Handling Retry Packets . . . . . . . . . . . . . . . . . 15 | 5.4. Handling Retry Packets . . . . . . . . . . . . . . . . . 15 | |||
| 5.5. Discarding Keys and Packet State . . . . . . . . . . . . 15 | 5.5. Discarding Keys and Packet State . . . . . . . . . . . . 15 | |||
| 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 16 | 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 6.1. Explicit Congestion Notification . . . . . . . . . . . . 16 | 6.1. Explicit Congestion Notification . . . . . . . . . . . . 16 | |||
| 6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 17 | 6.2. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 17 | 6.3. Congestion Avoidance . . . . . . . . . . . . . . . . . . 17 | |||
| 6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 17 | 6.4. Recovery Period . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 6.5. Ignoring Loss of Undecryptable Packets . . . . . . . . . 17 | 6.5. Ignoring Loss of Undecryptable Packets . . . . . . . . . 17 | |||
| 6.6. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 17 | 6.6. Probe Timeout . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 6.7. Persistent Congestion . . . . . . . . . . . . . . . . . . 18 | 6.7. Persistent Congestion . . . . . . . . . . . . . . . . . . 18 | |||
| 6.8. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 6.8. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 6.9. Under-utilizing the Congestion Window . . . . . . . . . . 19 | 6.9. Under-utilizing the Congestion Window . . . . . . . . . . 20 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
| 7.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 20 | 7.1. Congestion Signals . . . . . . . . . . . . . . . . . . . 20 | |||
| 7.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 20 | 7.2. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 20 | |||
| 7.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 20 | 7.3. Misreporting ECN Markings . . . . . . . . . . . . . . . . 20 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 21 | 9.2. Informative References . . . . . . . . . . . . . . . . . 21 | |||
| Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 23 | Appendix A. Loss Recovery Pseudocode . . . . . . . . . . . . . . 23 | |||
| A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 23 | A.1. Tracking Sent Packets . . . . . . . . . . . . . . . . . . 23 | |||
| A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 23 | A.1.1. Sent Packet Fields . . . . . . . . . . . . . . . . . 24 | |||
| A.2. Constants of interest . . . . . . . . . . . . . . . . . . 24 | A.2. Constants of interest . . . . . . . . . . . . . . . . . . 24 | |||
| A.3. Variables of interest . . . . . . . . . . . . . . . . . . 24 | A.3. Variables of interest . . . . . . . . . . . . . . . . . . 25 | |||
| A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 25 | A.4. Initialization . . . . . . . . . . . . . . . . . . . . . 25 | |||
| A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 25 | A.5. On Sending a Packet . . . . . . . . . . . . . . . . . . . 26 | |||
| A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 26 | A.6. On Receiving an Acknowledgment . . . . . . . . . . . . . 26 | |||
| A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 27 | A.7. On Packet Acknowledgment . . . . . . . . . . . . . . . . 28 | |||
| A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 28 | A.8. Setting the Loss Detection Timer . . . . . . . . . . . . 28 | |||
| A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 30 | A.9. On Timeout . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 30 | A.10. Detecting Lost Packets . . . . . . . . . . . . . . . . . 30 | |||
| Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 31 | Appendix B. Congestion Control Pseudocode . . . . . . . . . . . 31 | |||
| B.1. Constants of interest . . . . . . . . . . . . . . . . . . 31 | B.1. Constants of interest . . . . . . . . . . . . . . . . . . 31 | |||
| B.2. Variables of interest . . . . . . . . . . . . . . . . . . 32 | B.2. Variables of interest . . . . . . . . . . . . . . . . . . 32 | |||
| B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 33 | B.3. Initialization . . . . . . . . . . . . . . . . . . . . . 33 | |||
| B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 33 | B.4. On Packet Sent . . . . . . . . . . . . . . . . . . . . . 33 | |||
| B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 33 | B.5. On Packet Acknowledgement . . . . . . . . . . . . . . . . 33 | |||
| B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 34 | B.6. On New Congestion Event . . . . . . . . . . . . . . . . . 34 | |||
| B.7. Process ECN Information . . . . . . . . . . . . . . . . . 34 | B.7. Process ECN Information . . . . . . . . . . . . . . . . . 34 | |||
| B.8. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 35 | B.8. On Packets Lost . . . . . . . . . . . . . . . . . . . . . 35 | |||
| Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 | Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 | |||
| C.1. Since draft-ietf-quic-recovery-24 . . . . . . . . . . . . 35 | C.1. Since draft-ietf-quic-recovery-25 . . . . . . . . . . . . 35 | |||
| C.2. Since draft-ietf-quic-recovery-23 . . . . . . . . . . . . 35 | C.2. Since draft-ietf-quic-recovery-24 . . . . . . . . . . . . 35 | |||
| C.3. Since draft-ietf-quic-recovery-22 . . . . . . . . . . . . 36 | C.3. Since draft-ietf-quic-recovery-23 . . . . . . . . . . . . 35 | |||
| C.4. Since draft-ietf-quic-recovery-21 . . . . . . . . . . . . 36 | C.4. Since draft-ietf-quic-recovery-22 . . . . . . . . . . . . 36 | |||
| C.5. Since draft-ietf-quic-recovery-20 . . . . . . . . . . . . 36 | C.5. Since draft-ietf-quic-recovery-21 . . . . . . . . . . . . 36 | |||
| C.6. Since draft-ietf-quic-recovery-19 . . . . . . . . . . . . 36 | C.6. Since draft-ietf-quic-recovery-20 . . . . . . . . . . . . 36 | |||
| C.7. Since draft-ietf-quic-recovery-18 . . . . . . . . . . . . 37 | C.7. Since draft-ietf-quic-recovery-19 . . . . . . . . . . . . 36 | |||
| C.8. Since draft-ietf-quic-recovery-17 . . . . . . . . . . . . 37 | C.8. Since draft-ietf-quic-recovery-18 . . . . . . . . . . . . 37 | |||
| C.9. Since draft-ietf-quic-recovery-16 . . . . . . . . . . . . 37 | C.9. Since draft-ietf-quic-recovery-17 . . . . . . . . . . . . 37 | |||
| C.10. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 38 | C.10. Since draft-ietf-quic-recovery-16 . . . . . . . . . . . . 38 | |||
| C.11. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 38 | C.11. Since draft-ietf-quic-recovery-14 . . . . . . . . . . . . 38 | |||
| C.12. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 39 | C.12. Since draft-ietf-quic-recovery-13 . . . . . . . . . . . . 38 | |||
| C.13. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 39 | C.13. Since draft-ietf-quic-recovery-12 . . . . . . . . . . . . 39 | |||
| C.14. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 39 | C.14. Since draft-ietf-quic-recovery-11 . . . . . . . . . . . . 39 | |||
| C.15. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 39 | C.15. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 39 | |||
| C.16. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 39 | C.16. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 39 | |||
| C.17. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 39 | C.17. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 39 | |||
| C.18. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 39 | C.18. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 39 | |||
| C.19. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 40 | C.19. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 40 | |||
| C.20. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 40 | C.20. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 40 | |||
| C.21. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 40 | C.21. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 40 | |||
| C.22. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 40 | C.22. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 40 | |||
| C.23. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 40 | C.23. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 40 | |||
| C.24. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 40 | C.24. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 40 | |||
| C.25. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 40 | C.25. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 40 | |||
| C.26. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 41 | ||||
| Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 41 | Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 41 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| 1. Introduction | 1. Introduction | |||
| QUIC is a new multiplexed and secure transport atop UDP. QUIC builds | QUIC is a new multiplexed and secure transport atop UDP. QUIC builds | |||
| on decades of transport and security experience, and implements | on decades of transport and security experience, and implements | |||
| mechanisms that make it attractive as a modern general-purpose | mechanisms that make it attractive as a modern general-purpose | |||
| transport. The QUIC protocol is described in [QUIC-TRANSPORT]. | transport. The QUIC protocol is described in [QUIC-TRANSPORT]. | |||
| skipping to change at page 4, line 37 ¶ | skipping to change at page 4, line 38 ¶ | |||
| 2. Conventions and Definitions | 2. Conventions and Definitions | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| Definitions of terms that are used in this document: | Definitions of terms that are used in this document: | |||
| ACK-only: Any packet containing only one or more ACK frame(s). | ||||
| In-flight: Packets are considered in-flight when they have been sent | ||||
| and are not ACK-only, and they are not acknowledged, declared | ||||
| lost, or abandoned along with old keys. | ||||
| Ack-eliciting Frames: All frames other than ACK, PADDING, and | Ack-eliciting Frames: All frames other than ACK, PADDING, and | |||
| CONNECTION_CLOSE are considered ack-eliciting. | CONNECTION_CLOSE are considered ack-eliciting. | |||
| Ack-eliciting Packets: Packets that contain ack-eliciting frames | Ack-eliciting Packets: Packets that contain ack-eliciting frames | |||
| elicit an ACK from the receiver within the maximum ack delay and | elicit an ACK from the receiver within the maximum ack delay and | |||
| are called ack-eliciting packets. | are called ack-eliciting packets. | |||
| In-flight: Packets are considered in-flight when they are ack- | ||||
| eliciting or contain a PADDING frame, and they have been sent but | ||||
| are not acknowledged, declared lost, or abandoned along with old | ||||
| keys. | ||||
| 3. Design of the QUIC Transmission Machinery | 3. Design of the QUIC Transmission Machinery | |||
| All transmissions in QUIC are sent with a packet-level header, which | All transmissions in QUIC are sent with a packet-level header, which | |||
| indicates the encryption level and includes a packet sequence number | indicates the encryption level and includes a packet sequence number | |||
| (referred to below as a packet number). The encryption level | (referred to below as a packet number). The encryption level | |||
| indicates the packet number space, as described in [QUIC-TRANSPORT]. | indicates the packet number space, as described in [QUIC-TRANSPORT]. | |||
| Packet numbers never repeat within a packet number space for the | Packet numbers never repeat within a packet number space for the | |||
| lifetime of a connection. Packet numbers are sent in monotonically | lifetime of a connection. Packet numbers are sent in monotonically | |||
| increasing order within a space, preventing ambiguity. | increasing order within a space, preventing ambiguity. | |||
| skipping to change at page 6, line 20 ¶ | skipping to change at page 6, line 20 ¶ | |||
| of packets sent with one level of encryption will not cause spurious | of packets sent with one level of encryption will not cause spurious | |||
| retransmission of packets sent with a different encryption level. | retransmission of packets sent with a different encryption level. | |||
| Congestion control and round-trip time (RTT) measurement are unified | Congestion control and round-trip time (RTT) measurement are unified | |||
| across packet number spaces. | across packet number spaces. | |||
| 3.1.2. Monotonically Increasing Packet Numbers | 3.1.2. Monotonically Increasing Packet Numbers | |||
| TCP conflates transmission order at the sender with delivery order at | TCP conflates transmission order at the sender with delivery order at | |||
| the receiver, which results in retransmissions of the same data | the receiver, which results in retransmissions of the same data | |||
| carrying the same sequence number, and consequently leads to | carrying the same sequence number, and consequently leads to | |||
| "retransmission ambiguity". QUIC separates the two: QUIC uses a | "retransmission ambiguity". QUIC separates the two. QUIC uses a | |||
| packet number to indicate transmission order, and any application | packet number to indicate transmission order. Application data is | |||
| data is sent in one or more streams, with delivery order determined | sent in one or more streams and delivery order is determined by | |||
| by stream offsets encoded within STREAM frames. | stream offsets encoded within STREAM frames. | |||
| QUIC's packet number is strictly increasing within a packet number | QUIC's packet number is strictly increasing within a packet number | |||
| space, and directly encodes transmission order. A higher packet | space, and directly encodes transmission order. A higher packet | |||
| number signifies that the packet was sent later, and a lower packet | number signifies that the packet was sent later, and a lower packet | |||
| number signifies that the packet was sent earlier. When a packet | number signifies that the packet was sent earlier. When a packet | |||
| containing ack-eliciting frames is detected lost, QUIC rebundles | containing ack-eliciting frames is detected lost, QUIC rebundles | |||
| necessary frames in a new packet with a new packet number, removing | necessary frames in a new packet with a new packet number, removing | |||
| ambiguity about which packet is acknowledged when an ACK is received. | ambiguity about which packet is acknowledged when an ACK is received. | |||
| Consequently, more accurate RTT measurements can be made, spurious | Consequently, more accurate RTT measurements can be made, spurious | |||
| retransmissions are trivially detected, and mechanisms such as Fast | retransmissions are trivially detected, and mechanisms such as Fast | |||
| skipping to change at page 8, line 17 ¶ | skipping to change at page 8, line 17 ¶ | |||
| reported ACK delay is not used by the RTT sample measurement, it is | reported ACK delay is not used by the RTT sample measurement, it is | |||
| used to adjust the RTT sample in subsequent computations of | used to adjust the RTT sample in subsequent computations of | |||
| smoothed_rtt and rttvar Section 4.3. | smoothed_rtt and rttvar Section 4.3. | |||
| To avoid generating multiple RTT samples for a single packet, an ACK | To avoid generating multiple RTT samples for a single packet, an ACK | |||
| frame SHOULD NOT be used to update RTT estimates if it does not newly | frame SHOULD NOT be used to update RTT estimates if it does not newly | |||
| acknowledge the largest acknowledged packet. | acknowledge the largest acknowledged packet. | |||
| An RTT sample MUST NOT be generated on receiving an ACK frame that | An RTT sample MUST NOT be generated on receiving an ACK frame that | |||
| does not newly acknowledge at least one ack-eliciting packet. A peer | does not newly acknowledge at least one ack-eliciting packet. A peer | |||
| does not send an ACK frame on receiving only non-ack-eliciting | usually does not send an ACK frame when only non-ack-eliciting | |||
| packets, so an ACK frame that is subsequently sent can include an | packets are received. Therefore an ACK frame that contains | |||
| arbitrarily large Ack Delay field. Ignoring such ACK frames avoids | acknowledgements for only non-ack-eliciting packets could include an | |||
| arbitrarily large Ack Delay value. Ignoring such ACK frames avoids | ||||
| complications in subsequent smoothed_rtt and rttvar computations. | complications in subsequent smoothed_rtt and rttvar computations. | |||
| A sender might generate multiple RTT samples per RTT when multiple | A sender might generate multiple RTT samples per RTT when multiple | |||
| ACK frames are received within an RTT. As suggested in [RFC6298], | ACK frames are received within an RTT. As suggested in [RFC6298], | |||
| doing so might result in inadequate history in smoothed_rtt and | doing so might result in inadequate history in smoothed_rtt and | |||
| rttvar. Ensuring that RTT estimates retain sufficient history is an | rttvar. Ensuring that RTT estimates retain sufficient history is an | |||
| open research question. | open research question. | |||
| 4.2. Estimating min_rtt | 4.2. Estimating min_rtt | |||
| skipping to change at page 9, line 12 ¶ | skipping to change at page 9, line 12 ¶ | |||
| adapt to it, allowing future RTT samples that are smaller than the | adapt to it, allowing future RTT samples that are smaller than the | |||
| new RTT be included in smoothed_rtt. | new RTT be included in smoothed_rtt. | |||
| 4.3. Estimating smoothed_rtt and rttvar | 4.3. Estimating smoothed_rtt and rttvar | |||
| smoothed_rtt is an exponentially-weighted moving average of an | smoothed_rtt is an exponentially-weighted moving average of an | |||
| endpoint's RTT samples, and rttvar is the variation in the RTT | endpoint's RTT samples, and rttvar is the variation in the RTT | |||
| samples, estimated using a mean variation. | samples, estimated using a mean variation. | |||
| The calculation of smoothed_rtt uses path latency after adjusting RTT | The calculation of smoothed_rtt uses path latency after adjusting RTT | |||
| samples for ACK delays. For packets sent in the ApplicationData | samples for acknowledgement delays. These delays are computed using | |||
| packet number space, a peer limits any delay in sending an | the ACK Delay field of the ACK frame as described in Section 19.3 of | |||
| acknowledgement for an ack-eliciting packet to no greater than the | [QUIC-TRANSPORT]. For packets sent in the ApplicationData packet | |||
| value it advertised in the max_ack_delay transport parameter. | number space, a peer limits any delay in sending an acknowledgement | |||
| Consequently, when a peer reports an Ack Delay that is greater than | for an ack-eliciting packet to no greater than the value it | |||
| its max_ack_delay, the delay is attributed to reasons out of the | advertised in the max_ack_delay transport parameter. Consequently, | |||
| peer's control, such as scheduler latency at the peer or loss of | when a peer reports an Ack Delay that is greater than its | |||
| previous ACK frames. Any delays beyond the peer's max_ack_delay are | max_ack_delay, the delay is attributed to reasons out of the peer's | |||
| therefore considered effectively part of path delay and incorporated | control, such as scheduler latency at the peer or loss of previous | |||
| into the smoothed_rtt estimate. | ACK frames. Any delays beyond the peer's max_ack_delay are therefore | |||
| considered effectively part of path delay and incorporated into the | ||||
| smoothed_rtt estimate. | ||||
| When adjusting an RTT sample using peer-reported acknowledgement | When adjusting an RTT sample using peer-reported acknowledgement | |||
| delays, an endpoint: | delays, an endpoint: | |||
| * MUST ignore the Ack Delay field of the ACK frame for packets sent | * MUST ignore the Ack Delay field of the ACK frame for packets sent | |||
| in the Initial and Handshake packet number space. | in the Initial and Handshake packet number space. | |||
| * MUST use the lesser of the value reported in Ack Delay field of | * MUST use the lesser of the value reported in Ack Delay field of | |||
| the ACK frame and the peer's max_ack_delay transport parameter. | the ACK frame and the peer's max_ack_delay transport parameter. | |||
| skipping to change at page 10, line 16 ¶ | skipping to change at page 10, line 16 ¶ | |||
| adjusted_rtt = latest_rtt | adjusted_rtt = latest_rtt | |||
| if (min_rtt + ack_delay < latest_rtt): | if (min_rtt + ack_delay < latest_rtt): | |||
| adjusted_rtt = latest_rtt - ack_delay | adjusted_rtt = latest_rtt - ack_delay | |||
| smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt | smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * adjusted_rtt | |||
| rttvar_sample = abs(smoothed_rtt - adjusted_rtt) | rttvar_sample = abs(smoothed_rtt - adjusted_rtt) | |||
| rttvar = 3/4 * rttvar + 1/4 * rttvar_sample | rttvar = 3/4 * rttvar + 1/4 * rttvar_sample | |||
| 5. Loss Detection | 5. Loss Detection | |||
| QUIC senders use acknowledgements to detect lost packets, and a probe | QUIC senders use acknowledgements to detect lost packets, and a probe | |||
| time out Section 5.2 to ensure acknowledgements are received. This | time out (see Section 5.2) to ensure acknowledgements are received. | |||
| section provides a description of these algorithms. | This section provides a description of these algorithms. | |||
| If a packet is lost, the QUIC transport needs to recover from that | If a packet is lost, the QUIC transport needs to recover from that | |||
| loss, such as by retransmitting the data, sending an updated frame, | loss, such as by retransmitting the data, sending an updated frame, | |||
| or abandoning the frame. For more information, see Section 13.3 of | or abandoning the frame. For more information, see Section 13.3 of | |||
| [QUIC-TRANSPORT]. | [QUIC-TRANSPORT]. | |||
| 5.1. Acknowledgement-based Detection | 5.1. Acknowledgement-based Detection | |||
| Acknowledgement-based loss detection implements the spirit of TCP's | Acknowledgement-based loss detection implements the spirit of TCP's | |||
| Fast Retransmit [RFC5681], Early Retransmit [RFC5827], FACK [FACK], | Fast Retransmit [RFC5681], Early Retransmit [RFC5827], FACK [FACK], | |||
| skipping to change at page 12, line 35 ¶ | skipping to change at page 12, line 35 ¶ | |||
| kGranularity, smoothed_rtt, rttvar, and max_ack_delay are defined in | kGranularity, smoothed_rtt, rttvar, and max_ack_delay are defined in | |||
| Appendix A.2 and Appendix A.3. | Appendix A.2 and Appendix A.3. | |||
| The PTO period is the amount of time that a sender ought to wait for | The PTO period is the amount of time that a sender ought to wait for | |||
| an acknowledgement of a sent packet. This time period includes the | an acknowledgement of a sent packet. This time period includes the | |||
| estimated network roundtrip-time (smoothed_rtt), the variation in the | estimated network roundtrip-time (smoothed_rtt), the variation in the | |||
| estimate (4*rttvar), and max_ack_delay, to account for the maximum | estimate (4*rttvar), and max_ack_delay, to account for the maximum | |||
| time by which a receiver might delay sending an acknowledgement. | time by which a receiver might delay sending an acknowledgement. | |||
| When the PTO is armed for Initial or Handshake packet number spaces, | When the PTO is armed for Initial or Handshake packet number spaces, | |||
| the max_ack_delay is 0, as specified in 13.2.5 of [QUIC-TRANSPORT]. | the max_ack_delay is 0, as specified in 13.2.1 of [QUIC-TRANSPORT]. | |||
| The PTO value MUST be set to at least kGranularity, to avoid the | The PTO value MUST be set to at least kGranularity, to avoid the | |||
| timer expiring immediately. | timer expiring immediately. | |||
| A sender computes its PTO timer every time an ack-eliciting packet is | A sender computes its PTO timer every time an ack-eliciting packet is | |||
| sent. When ack-eliciting packets are in-flight in multiple packet | sent. When ack-eliciting packets are in-flight in multiple packet | |||
| number spaces, the timer MUST be set for the packet number space with | number spaces, the timer MUST be set for the packet number space with | |||
| the earliest timeout, except for ApplicationData, which MUST be | the earliest timeout, except for ApplicationData, which MUST be | |||
| ignored until the handshake completes; see Section 4.1.1 of | ignored until the handshake completes; see Section 4.1.1 of | |||
| [QUIC-TLS]. Not arming the PTO for ApplicationData prioritizes | [QUIC-TLS]. Not arming the PTO for ApplicationData prioritizes | |||
| skipping to change at page 13, line 14 ¶ | skipping to change at page 13, line 14 ¶ | |||
| or acknowledgements due to severe congestion. Even when there are | or acknowledgements due to severe congestion. Even when there are | |||
| ack-eliciting packets in-flight in multiple packet number spaces, the | ack-eliciting packets in-flight in multiple packet number spaces, the | |||
| exponential increase in probe timeout occurs across all spaces to | exponential increase in probe timeout occurs across all spaces to | |||
| prevent excess load on the network. For example, a timeout in the | prevent excess load on the network. For example, a timeout in the | |||
| Initial packet number space doubles the length of the timeout in the | Initial packet number space doubles the length of the timeout in the | |||
| Handshake packet number space. | Handshake packet number space. | |||
| The life of a connection that is experiencing consecutive PTOs is | The life of a connection that is experiencing consecutive PTOs is | |||
| limited by the endpoint's idle timeout. | limited by the endpoint's idle timeout. | |||
| The probe timer is not set if the time threshold Section 5.1.2 loss | The probe timer MUST NOT be set if the time threshold Section 5.1.2 | |||
| detection timer is set. The time threshold loss detection timer is | loss detection timer is set. The time threshold loss detection timer | |||
| expected to both expire earlier than the PTO and be less likely to | is expected to both expire earlier than the PTO and be less likely to | |||
| spuriously retransmit data. | spuriously retransmit data. | |||
| 5.3. Handshakes and New Paths | 5.3. Handshakes and New Paths | |||
| The initial probe timeout for a new connection or new path SHOULD be | The initial probe timeout for a new connection or new path SHOULD be | |||
| set to twice the initial RTT. Resumed connections over the same | set to twice the initial RTT. Resumed connections over the same | |||
| network SHOULD use the previous connection's final smoothed RTT value | network SHOULD use the previous connection's final smoothed RTT value | |||
| as the resumed connection's initial RTT. If no previous RTT is | as the resumed connection's initial RTT. If no previous RTT is | |||
| available, the initial RTT SHOULD be set to 500ms, resulting in a 1 | available, the initial RTT SHOULD be set to 500ms, resulting in a 1 | |||
| second initial timeout as recommended in [RFC6298]. | second initial timeout as recommended in [RFC6298]. | |||
| skipping to change at page 17, line 25 ¶ | skipping to change at page 17, line 25 ¶ | |||
| Slow start exits to congestion avoidance. Congestion avoidance in | Slow start exits to congestion avoidance. Congestion avoidance in | |||
| NewReno uses an additive increase multiplicative decrease (AIMD) | NewReno uses an additive increase multiplicative decrease (AIMD) | |||
| approach that increases the congestion window by one maximum packet | approach that increases the congestion window by one maximum packet | |||
| size per congestion window acknowledged. When a loss is detected, | size per congestion window acknowledged. When a loss is detected, | |||
| NewReno halves the congestion window and sets the slow start | NewReno halves the congestion window and sets the slow start | |||
| threshold to the new congestion window. | threshold to the new congestion window. | |||
| 6.4. Recovery Period | 6.4. Recovery Period | |||
| Recovery is a period of time beginning with detection of a lost | A recovery period is entered when loss or ECN-CE marking of a packet | |||
| packet or an increase in the ECN-CE counter. Because QUIC does not | is detected. A recovery period ends when a packet sent during the | |||
| retransmit packets, it defines the end of recovery as a packet sent | recovery period is acknowledged. This is slightly different from | |||
| after the start of recovery being acknowledged. This is slightly | TCP's definition of recovery, which ends when the lost packet that | |||
| different from TCP's definition of recovery, which ends when the lost | started recovery is acknowledged. | |||
| packet that started recovery is acknowledged. | ||||
| The recovery period limits congestion window reduction to once per | The recovery period limits congestion window reduction to once per | |||
| round trip. During recovery, the congestion window remains unchanged | round trip. During recovery, the congestion window remains unchanged | |||
| irrespective of new losses or increases in the ECN-CE counter. | irrespective of new losses or increases in the ECN-CE counter. | |||
| 6.5. Ignoring Loss of Undecryptable Packets | 6.5. Ignoring Loss of Undecryptable Packets | |||
| During the handshake, some packet protection keys might not be | During the handshake, some packet protection keys might not be | |||
| available when a packet arrives. In particular, Handshake and 0-RTT | available when a packet arrives. In particular, Handshake and 0-RTT | |||
| packets cannot be processed until the Initial packets arrive, and | packets cannot be processed until the Initial packets arrive, and | |||
| skipping to change at page 21, line 17 ¶ | skipping to change at page 21, line 28 ¶ | |||
| 8. IANA Considerations | 8. IANA Considerations | |||
| This document has no IANA actions. Yet. | This document has no IANA actions. Yet. | |||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure | [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure | |||
| QUIC", Work in Progress, Internet-Draft, draft-ietf-quic- | QUIC", Work in Progress, Internet-Draft, draft-ietf-quic- | |||
| tls-25, 22 January 2020, | tls-26, 21 February 2020, | |||
| <https://tools.ietf.org/html/draft-ietf-quic-tls-25>. | <https://tools.ietf.org/html/draft-ietf-quic-tls-26>. | |||
| [QUIC-TRANSPORT] | [QUIC-TRANSPORT] | |||
| Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
| Multiplexed and Secure Transport", Work in Progress, | Multiplexed and Secure Transport", Work in Progress, | |||
| Internet-Draft, draft-ietf-quic-transport-25, 22 January | Internet-Draft, draft-ietf-quic-transport-26, 21 February | |||
| 2020, <https://tools.ietf.org/html/draft-ietf-quic- | 2020, <https://tools.ietf.org/html/draft-ietf-quic- | |||
| transport-25>. | transport-26>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | |||
| Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, | Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, | |||
| March 2017, <https://www.rfc-editor.org/info/rfc8085>. | March 2017, <https://www.rfc-editor.org/info/rfc8085>. | |||
| skipping to change at page 35, line 37 ¶ | skipping to change at page 35, line 37 ¶ | |||
| if (InPersistentCongestion(largest_lost_packet)): | if (InPersistentCongestion(largest_lost_packet)): | |||
| congestion_window = kMinimumWindow | congestion_window = kMinimumWindow | |||
| Appendix C. Change Log | Appendix C. Change Log | |||
| *RFC Editor's Note:* Please remove this section prior to | *RFC Editor's Note:* Please remove this section prior to | |||
| publication of a final version of this document. | publication of a final version of this document. | |||
| Issue and pull request numbers are listed with a leading octothorp. | Issue and pull request numbers are listed with a leading octothorp. | |||
| C.1. Since draft-ietf-quic-recovery-24 | C.1. Since draft-ietf-quic-recovery-25 | |||
| No significant changes. | ||||
| C.2. Since draft-ietf-quic-recovery-24 | ||||
| * Require congestion control of some sort (#3247, #3244, #3248) | * Require congestion control of some sort (#3247, #3244, #3248) | |||
| * Set a minimum reordering threshold (#3256, #3240) | * Set a minimum reordering threshold (#3256, #3240) | |||
| * PTO is specific to a packet number space (#3067, #3074, #3066) | * PTO is specific to a packet number space (#3067, #3074, #3066) | |||
| C.2. Since draft-ietf-quic-recovery-23 | C.3. Since draft-ietf-quic-recovery-23 | |||
| * Define under-utilizing the congestion window (#2630, #2686, #2675) | * Define under-utilizing the congestion window (#2630, #2686, #2675) | |||
| * PTO MUST send data if possible (#3056, #3057) | * PTO MUST send data if possible (#3056, #3057) | |||
| * Connection Close is not ack-eliciting (#3097, #3098) | * Connection Close is not ack-eliciting (#3097, #3098) | |||
| * MUST limit bursts to the initial congestion window (#3160) | * MUST limit bursts to the initial congestion window (#3160) | |||
| * Define the current max_datagram_size for congestion control | * Define the current max_datagram_size for congestion control | |||
| (#3041, #3167) | (#3041, #3167) | |||
| C.3. Since draft-ietf-quic-recovery-22 | C.4. Since draft-ietf-quic-recovery-22 | |||
| * PTO should always send an ack-eliciting packet (#2895) | * PTO should always send an ack-eliciting packet (#2895) | |||
| * Unify the Handshake Timer with the PTO timer (#2648, #2658, #2886) | * Unify the Handshake Timer with the PTO timer (#2648, #2658, #2886) | |||
| * Move ACK generation text to transport draft (#1860, #2916) | * Move ACK generation text to transport draft (#1860, #2916) | |||
| C.4. Since draft-ietf-quic-recovery-21 | C.5. Since draft-ietf-quic-recovery-21 | |||
| * No changes | * No changes | |||
| C.5. Since draft-ietf-quic-recovery-20 | C.6. Since draft-ietf-quic-recovery-20 | |||
| * Path validation can be used as initial RTT value (#2644, #2687) | * Path validation can be used as initial RTT value (#2644, #2687) | |||
| * max_ack_delay transport parameter defaults to 0 (#2638, #2646) | * max_ack_delay transport parameter defaults to 0 (#2638, #2646) | |||
| * Ack Delay only measures intentional delays induced by the | * Ack Delay only measures intentional delays induced by the | |||
| implementation (#2596, #2786) | implementation (#2596, #2786) | |||
| C.6. Since draft-ietf-quic-recovery-19 | C.7. Since draft-ietf-quic-recovery-19 | |||
| * Change kPersistentThreshold from an exponent to a multiplier | * Change kPersistentThreshold from an exponent to a multiplier | |||
| (#2557) | (#2557) | |||
| * Send a PING if the PTO timer fires and there's nothing to send | * Send a PING if the PTO timer fires and there's nothing to send | |||
| (#2624) | (#2624) | |||
| * Set loss delay to at least kGranularity (#2617) | * Set loss delay to at least kGranularity (#2617) | |||
| * Merge application limited and sending after idle sections. Always | * Merge application limited and sending after idle sections. Always | |||
| skipping to change at page 37, line 7 ¶ | skipping to change at page 37, line 13 ¶ | |||
| packet is ack-eliciting but the largest_acked is not (#2592) | packet is ack-eliciting but the largest_acked is not (#2592) | |||
| * Don't arm the handshake timer if there is no handshake data | * Don't arm the handshake timer if there is no handshake data | |||
| (#2590) | (#2590) | |||
| * Clarify that the time threshold loss alarm takes precedence over | * Clarify that the time threshold loss alarm takes precedence over | |||
| the crypto handshake timer (#2590, #2620) | the crypto handshake timer (#2590, #2620) | |||
| * Change initial RTT to 500ms to align with RFC6298 (#2184) | * Change initial RTT to 500ms to align with RFC6298 (#2184) | |||
| C.7. Since draft-ietf-quic-recovery-18 | C.8. Since draft-ietf-quic-recovery-18 | |||
| * Change IW byte limit to 14720 from 14600 (#2494) | * Change IW byte limit to 14720 from 14600 (#2494) | |||
| * Update PTO calculation to match RFC6298 (#2480, #2489, #2490) | * Update PTO calculation to match RFC6298 (#2480, #2489, #2490) | |||
| * Improve loss detection's description of multiple packet number | * Improve loss detection's description of multiple packet number | |||
| spaces and pseudocode (#2485, #2451, #2417) | spaces and pseudocode (#2485, #2451, #2417) | |||
| * Declare persistent congestion even if non-probe packets are sent | * Declare persistent congestion even if non-probe packets are sent | |||
| and don't make persistent congestion more aggressive than RTO | and don't make persistent congestion more aggressive than RTO | |||
| verified was (#2365, #2244) | verified was (#2365, #2244) | |||
| * Move pseudocode to the appendices (#2408) | * Move pseudocode to the appendices (#2408) | |||
| * What to send on multiple PTOs (#2380) | * What to send on multiple PTOs (#2380) | |||
| C.8. Since draft-ietf-quic-recovery-17 | C.9. Since draft-ietf-quic-recovery-17 | |||
| * After Probe Timeout discard in-flight packets or send another | * After Probe Timeout discard in-flight packets or send another | |||
| (#2212, #1965) | (#2212, #1965) | |||
| * Endpoints discard initial keys as soon as handshake keys are | * Endpoints discard initial keys as soon as handshake keys are | |||
| available (#1951, #2045) | available (#1951, #2045) | |||
| * 0-RTT state is discarded when 0-RTT is rejected (#2300) | * 0-RTT state is discarded when 0-RTT is rejected (#2300) | |||
| * Loss detection timer is cancelled when ack-eliciting frames are in | * Loss detection timer is cancelled when ack-eliciting frames are in | |||
| skipping to change at page 37, line 50 ¶ | skipping to change at page 38, line 8 ¶ | |||
| controller (#2138, 2187) | controller (#2138, 2187) | |||
| * Process ECN counts before marking packets lost (#2142) | * Process ECN counts before marking packets lost (#2142) | |||
| * Mark packets lost before resetting crypto_count and pto_count | * Mark packets lost before resetting crypto_count and pto_count | |||
| (#2208, #2209) | (#2208, #2209) | |||
| * Congestion and loss recovery state are discarded when keys are | * Congestion and loss recovery state are discarded when keys are | |||
| discarded (#2327) | discarded (#2327) | |||
| C.9. Since draft-ietf-quic-recovery-16 | C.10. Since draft-ietf-quic-recovery-16 | |||
| * Unify TLP and RTO into a single PTO; eliminate min RTO, min TLP | * Unify TLP and RTO into a single PTO; eliminate min RTO, min TLP | |||
| and min crypto timeouts; eliminate timeout validation (#2114, | and min crypto timeouts; eliminate timeout validation (#2114, | |||
| #2166, #2168, #1017) | #2166, #2168, #1017) | |||
| * Redefine how congestion avoidance in terms of when the period | * Redefine how congestion avoidance in terms of when the period | |||
| starts (#1928, #1930) | starts (#1928, #1930) | |||
| * Document what needs to be tracked for packets that are in flight | * Document what needs to be tracked for packets that are in flight | |||
| (#765, #1724, #1939) | (#765, #1724, #1939) | |||
| skipping to change at page 38, line 33 ¶ | skipping to change at page 38, line 39 ¶ | |||
| * Limit ack_delay by max_ack_delay (#2060, #2099) | * Limit ack_delay by max_ack_delay (#2060, #2099) | |||
| * Initial keys are discarded once Handshake keys are available | * Initial keys are discarded once Handshake keys are available | |||
| (#1951, #2045) | (#1951, #2045) | |||
| * Reorder ECN and loss detection in pseudocode (#2142) | * Reorder ECN and loss detection in pseudocode (#2142) | |||
| * Only cancel loss detection timer if ack-eliciting packets are in | * Only cancel loss detection timer if ack-eliciting packets are in | |||
| flight (#2093, #2117) | flight (#2093, #2117) | |||
| C.10. Since draft-ietf-quic-recovery-14 | C.11. Since draft-ietf-quic-recovery-14 | |||
| * Used max_ack_delay from transport params (#1796, #1782) | * Used max_ack_delay from transport params (#1796, #1782) | |||
| * Merge ACK and ACK_ECN (#1783) | * Merge ACK and ACK_ECN (#1783) | |||
| C.11. Since draft-ietf-quic-recovery-13 | C.12. Since draft-ietf-quic-recovery-13 | |||
| * Corrected the lack of ssthresh reduction in CongestionEvent | * Corrected the lack of ssthresh reduction in CongestionEvent | |||
| pseudocode (#1598) | pseudocode (#1598) | |||
| * Considerations for ECN spoofing (#1426, #1626) | * Considerations for ECN spoofing (#1426, #1626) | |||
| * Clarifications for PADDING and congestion control (#837, #838, | * Clarifications for PADDING and congestion control (#837, #838, | |||
| #1517, #1531, #1540) | #1517, #1531, #1540) | |||
| * Reduce early retransmission timer to RTT/8 (#945, #1581) | * Reduce early retransmission timer to RTT/8 (#945, #1581) | |||
| * Packets are declared lost after an RTO is verified (#935, #1582) | * Packets are declared lost after an RTO is verified (#935, #1582) | |||
| C.12. Since draft-ietf-quic-recovery-12 | C.13. Since draft-ietf-quic-recovery-12 | |||
| * Changes to manage separate packet number spaces and encryption | * Changes to manage separate packet number spaces and encryption | |||
| levels (#1190, #1242, #1413, #1450) | levels (#1190, #1242, #1413, #1450) | |||
| * Added ECN feedback mechanisms and handling; new ACK_ECN frame | * Added ECN feedback mechanisms and handling; new ACK_ECN frame | |||
| (#804, #805, #1372) | (#804, #805, #1372) | |||
| C.13. Since draft-ietf-quic-recovery-11 | C.14. Since draft-ietf-quic-recovery-11 | |||
| No significant changes. | No significant changes. | |||
| C.14. Since draft-ietf-quic-recovery-10 | C.15. Since draft-ietf-quic-recovery-10 | |||
| * Improved text on ack generation (#1139, #1159) | * Improved text on ack generation (#1139, #1159) | |||
| * Make references to TCP recovery mechanisms informational (#1195) | * Make references to TCP recovery mechanisms informational (#1195) | |||
| * Define time_of_last_sent_handshake_packet (#1171) | * Define time_of_last_sent_handshake_packet (#1171) | |||
| * Added signal from TLS the data it includes needs to be sent in a | * Added signal from TLS the data it includes needs to be sent in a | |||
| Retry packet (#1061, #1199) | Retry packet (#1061, #1199) | |||
| * Minimum RTT (min_rtt) is initialized with an infinite value | * Minimum RTT (min_rtt) is initialized with an infinite value | |||
| (#1169) | (#1169) | |||
| C.15. Since draft-ietf-quic-recovery-09 | C.16. Since draft-ietf-quic-recovery-09 | |||
| No significant changes. | No significant changes. | |||
| C.16. Since draft-ietf-quic-recovery-08 | C.17. Since draft-ietf-quic-recovery-08 | |||
| * Clarified pacing and RTO (#967, #977) | * Clarified pacing and RTO (#967, #977) | |||
| C.17. Since draft-ietf-quic-recovery-07 | C.18. Since draft-ietf-quic-recovery-07 | |||
| * Include Ack Delay in RTO(and TLP) computations (#981) | * Include Ack Delay in RTO(and TLP) computations (#981) | |||
| * Ack Delay in SRTT computation (#961) | * Ack Delay in SRTT computation (#961) | |||
| * Default RTT and Slow Start (#590) | * Default RTT and Slow Start (#590) | |||
| * Many editorial fixes. | * Many editorial fixes. | |||
| C.18. Since draft-ietf-quic-recovery-06 | C.19. Since draft-ietf-quic-recovery-06 | |||
| No significant changes. | No significant changes. | |||
| C.19. Since draft-ietf-quic-recovery-05 | C.20. Since draft-ietf-quic-recovery-05 | |||
| * Add more congestion control text (#776) | * Add more congestion control text (#776) | |||
| C.20. Since draft-ietf-quic-recovery-04 | C.21. Since draft-ietf-quic-recovery-04 | |||
| No significant changes. | No significant changes. | |||
| C.21. Since draft-ietf-quic-recovery-03 | C.22. Since draft-ietf-quic-recovery-03 | |||
| No significant changes. | No significant changes. | |||
| C.22. Since draft-ietf-quic-recovery-02 | C.23. Since draft-ietf-quic-recovery-02 | |||
| * Integrate F-RTO (#544, #409) | * Integrate F-RTO (#544, #409) | |||
| * Add congestion control (#545, #395) | * Add congestion control (#545, #395) | |||
| * Require connection abort if a skipped packet was acknowledged | * Require connection abort if a skipped packet was acknowledged | |||
| (#415) | (#415) | |||
| * Simplify RTO calculations (#142, #417) | * Simplify RTO calculations (#142, #417) | |||
| C.23. Since draft-ietf-quic-recovery-01 | C.24. Since draft-ietf-quic-recovery-01 | |||
| * Overview added to loss detection | * Overview added to loss detection | |||
| * Changes initial default RTT to 100ms | * Changes initial default RTT to 100ms | |||
| * Added time-based loss detection and fixes early retransmit | * Added time-based loss detection and fixes early retransmit | |||
| * Clarified loss recovery for handshake packets | * Clarified loss recovery for handshake packets | |||
| * Fixed references and made TCP references informative | * Fixed references and made TCP references informative | |||
| C.24. Since draft-ietf-quic-recovery-00 | C.25. Since draft-ietf-quic-recovery-00 | |||
| * Improved description of constants and ACK behavior | * Improved description of constants and ACK behavior | |||
| C.25. Since draft-iyengar-quic-loss-recovery-01 | C.26. Since draft-iyengar-quic-loss-recovery-01 | |||
| * Adopted as base for draft-ietf-quic-recovery | * Adopted as base for draft-ietf-quic-recovery | |||
| * Updated authors/editors list | * Updated authors/editors list | |||
| * Added table of contents | * Added table of contents | |||
| Appendix D. Contributors | Appendix D. Contributors | |||
| The IETF QUIC Working Group received an enormous amount of support | The IETF QUIC Working Group received an enormous amount of support | |||
| End of changes. 51 change blocks. | ||||
| 102 lines changed or deleted | 107 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||