idnits 2.17.1 draft-ietf-quic-recovery-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2018) is 2200 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1215 -- Looks like a reference, but probably isn't: '2' on line 1217 -- Looks like a reference, but probably isn't: '3' on line 1219 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-11 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC J. Iyengar, Ed. 3 Internet-Draft Fastly 4 Intended status: Standards Track I. Swett, Ed. 5 Expires: October 19, 2018 Google 6 April 17, 2018 8 QUIC Loss Detection and Congestion Control 9 draft-ietf-quic-recovery-11 11 Abstract 13 This document describes loss detection and congestion control 14 mechanisms for QUIC. 16 Note to Readers 18 Discussion of this draft takes place on the QUIC working group 19 mailing list (quic@ietf.org), which is archived at 20 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 22 Working Group information can be found at https://github.com/quicwg 23 [2]; source code and issues list for this draft can be found at 24 https://github.com/quicwg/base-drafts/labels/-recovery [3]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 19, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 62 2. Design of the QUIC Transmission Machinery . . . . . . . . . . 4 63 2.1. Relevant Differences Between QUIC and TCP . . . . . . . . 4 64 2.1.1. Monotonically Increasing Packet Numbers . . . . . . . 5 65 2.1.2. No Reneging . . . . . . . . . . . . . . . . . . . . . 5 66 2.1.3. More ACK Ranges . . . . . . . . . . . . . . . . . . . 5 67 2.1.4. Explicit Correction For Delayed ACKs . . . . . . . . 5 68 3. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Computing the RTT estimate . . . . . . . . . . . . . . . 6 70 3.2. Ack-based Detection . . . . . . . . . . . . . . . . . . . 6 71 3.2.1. Fast Retransmit . . . . . . . . . . . . . . . . . . . 6 72 3.2.2. Early Retransmit . . . . . . . . . . . . . . . . . . 7 73 3.3. Timer-based Detection . . . . . . . . . . . . . . . . . . 8 74 3.3.1. Handshake Timeout . . . . . . . . . . . . . . . . . . 8 75 3.3.2. Tail Loss Probe . . . . . . . . . . . . . . . . . . . 9 76 3.3.3. Retransmission Timeout . . . . . . . . . . . . . . . 10 77 3.4. Generating Acknowledgements . . . . . . . . . . . . . . . 11 78 3.4.1. ACK Ranges . . . . . . . . . . . . . . . . . . . . . 11 79 3.4.2. Receiver Tracking of ACK Frames . . . . . . . . . . . 12 80 3.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.5.1. Constants of interest . . . . . . . . . . . . . . . . 12 82 3.5.2. Variables of interest . . . . . . . . . . . . . . . . 13 83 3.5.3. Initialization . . . . . . . . . . . . . . . . . . . 14 84 3.5.4. On Sending a Packet . . . . . . . . . . . . . . . . . 15 85 3.5.5. On Ack Receipt . . . . . . . . . . . . . . . . . . . 16 86 3.5.6. On Packet Acknowledgment . . . . . . . . . . . . . . 17 87 3.5.7. Setting the Loss Detection Alarm . . . . . . . . . . 18 88 3.5.8. On Alarm Firing . . . . . . . . . . . . . . . . . . . 20 89 3.5.9. Detecting Lost Packets . . . . . . . . . . . . . . . 20 90 3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 21 91 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 22 92 4.1. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 22 93 4.2. Congestion Avoidance . . . . . . . . . . . . . . . . . . 22 94 4.3. Recovery Period . . . . . . . . . . . . . . . . . . . . . 22 95 4.4. Tail Loss Probe . . . . . . . . . . . . . . . . . . . . . 23 96 4.5. Retransmission Timeout . . . . . . . . . . . . . . . . . 23 97 4.6. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 4.7. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 24 99 4.7.1. Constants of interest . . . . . . . . . . . . . . . . 24 100 4.7.2. Variables of interest . . . . . . . . . . . . . . . . 24 101 4.7.3. Initialization . . . . . . . . . . . . . . . . . . . 24 102 4.7.4. On Packet Sent . . . . . . . . . . . . . . . . . . . 25 103 4.7.5. On Packet Acknowledgement . . . . . . . . . . . . . . 25 104 4.7.6. On Packets Lost . . . . . . . . . . . . . . . . . . . 25 105 4.7.7. On Retransmission Timeout Verified . . . . . . . . . 26 106 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 107 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 6.1. Normative References . . . . . . . . . . . . . . . . . . 26 109 6.2. Informative References . . . . . . . . . . . . . . . . . 26 110 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 27 111 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 28 112 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 113 B.1. Since draft-ietf-quic-recovery-10 . . . . . . . . . . . . 28 114 B.2. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 28 115 B.3. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 28 116 B.4. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 28 117 B.5. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 28 118 B.6. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 29 119 B.7. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 29 120 B.8. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 29 121 B.9. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 29 122 B.10. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 29 123 B.11. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 29 124 B.12. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 29 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 127 1. Introduction 129 QUIC is a new multiplexed and secure transport atop UDP. QUIC builds 130 on decades of transport and security experience, and implements 131 mechanisms that make it attractive as a modern general-purpose 132 transport. The QUIC protocol is described in [QUIC-TRANSPORT]. 134 QUIC implements the spirit of known TCP loss recovery mechanisms, 135 described in RFCs, various Internet-drafts, and also those prevalent 136 in the Linux TCP implementation. This document describes QUIC 137 congestion control and loss recovery, and where applicable, 138 attributes the TCP equivalent in RFCs, Internet-drafts, academic 139 papers, and/or TCP implementations. 141 1.1. Notational Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. Design of the QUIC Transmission Machinery 151 All transmissions in QUIC are sent with a packet-level header, which 152 includes a packet sequence number (referred to below as a packet 153 number). These packet numbers never repeat in the lifetime of a 154 connection, and are monotonically increasing, which prevents 155 ambiguity. This fundamental design decision obviates the need for 156 disambiguating between transmissions and retransmissions and 157 eliminates significant complexity from QUIC's interpretation of TCP 158 loss detection mechanisms. 160 Every packet may contain several frames. We outline the frames that 161 are important to the loss detection and congestion control machinery 162 below. 164 o Retransmittable frames are those that count towards bytes in 165 flight and need acknowledgement. The most common are STREAM 166 frames, which typically contain application data. 168 o Retransmittable packets are those that contain at least one 169 retransmittable frame. 171 o Crypto handshake data is sent on stream 0, and uses the 172 reliability machinery of QUIC underneath. 174 o ACK frames contain acknowledgment information. ACK frames contain 175 one or more ranges of acknowledged packets. 177 2.1. Relevant Differences Between QUIC and TCP 179 Readers familiar with TCP's loss detection and congestion control 180 will find algorithms here that parallel well-known TCP ones. 181 Protocol differences between QUIC and TCP however contribute to 182 algorithmic differences. We briefly describe these protocol 183 differences below. 185 2.1.1. Monotonically Increasing Packet Numbers 187 TCP conflates transmission sequence number at the sender with 188 delivery sequence number at the receiver, which results in 189 retransmissions of the same data carrying the same sequence number, 190 and consequently to problems caused by "retransmission ambiguity". 191 QUIC separates the two: QUIC uses a packet number for transmissions, 192 and any data that is to be delivered to the receiving application(s) 193 is sent in one or more streams, with delivery order determined by 194 stream offsets encoded within STREAM frames. 196 QUIC's packet number is strictly increasing, and directly encodes 197 transmission order. A higher QUIC packet number signifies that the 198 packet was sent later, and a lower QUIC packet number signifies that 199 the packet was sent earlier. When a packet containing frames is 200 deemed lost, QUIC rebundles necessary frames in a new packet with a 201 new packet number, removing ambiguity about which packet is 202 acknowledged when an ACK is received. Consequently, more accurate 203 RTT measurements can be made, spurious retransmissions are trivially 204 detected, and mechanisms such as Fast Retransmit can be applied 205 universally, based only on packet number. 207 This design point significantly simplifies loss detection mechanisms 208 for QUIC. Most TCP mechanisms implicitly attempt to infer 209 transmission ordering based on TCP sequence numbers - a non-trivial 210 task, especially when TCP timestamps are not available. 212 2.1.2. No Reneging 214 QUIC ACKs contain information that is similar to TCP SACK, but QUIC 215 does not allow any acked packet to be reneged, greatly simplifying 216 implementations on both sides and reducing memory pressure on the 217 sender. 219 2.1.3. More ACK Ranges 221 QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges. In 222 high loss environments, this speeds recovery, reduces spurious 223 retransmits, and ensures forward progress without relying on 224 timeouts. 226 2.1.4. Explicit Correction For Delayed ACKs 228 QUIC ACKs explicitly encode the delay incurred at the receiver 229 between when a packet is received and when the corresponding ACK is 230 sent. This allows the receiver of the ACK to adjust for receiver 231 delays, specifically the delayed ack timer, when estimating the path 232 RTT. This mechanism also allows a receiver to measure and report the 233 delay from when a packet was received by the OS kernel, which is 234 useful in receivers which may incur delays such as context-switch 235 latency before a userspace QUIC receiver processes a received packet. 237 3. Loss Detection 239 QUIC senders use both ack information and timeouts to detect lost 240 packets, and this section provides a description of these algorithms. 241 Estimating the network round-trip time (RTT) is critical to these 242 algorithms and is described first. 244 3.1. Computing the RTT estimate 246 RTT is calculated when an ACK frame arrives by computing the 247 difference between the current time and the time the largest newly 248 acked packet was sent. If no packets are newly acknowledged, RTT 249 cannot be calculated. When RTT is calculated, the ack delay field 250 from the ACK frame SHOULD be subtracted from the RTT as long as the 251 result is larger than the Min RTT. If the result is smaller than the 252 min_rtt, the RTT should be used, but the ack delay field should be 253 ignored. 255 Like TCP, QUIC calculates both smoothed RTT and RTT variance similar 256 to those specified in [RFC6298]. 258 Min RTT is the minimum RTT measured over the connection, prior to 259 adjusting by ack delay. Ignoring ack delay for min RTT prevents 260 intentional or unintentional underestimation of min RTT, which in 261 turn prevents underestimating smoothed RTT. 263 3.2. Ack-based Detection 265 Ack-based loss detection implements the spirit of TCP's Fast 266 Retransmit [RFC5681], Early Retransmit [RFC5827], FACK, and SACK loss 267 recovery [RFC6675]. This section provides an overview of how these 268 algorithms are implemented in QUIC. 270 3.2.1. Fast Retransmit 272 An unacknowledged packet is marked as lost when an acknowledgment is 273 received for a packet that was sent a threshold number of packets 274 (kReorderingThreshold) after the unacknowledged packet. Receipt of 275 the ack indicates that a later packet was received, while 276 kReorderingThreshold provides some tolerance for reordering of 277 packets in the network. 279 The RECOMMENDED initial value for kReorderingThreshold is 3. 281 We derive this default from recommendations for TCP loss recovery 282 [RFC5681] [RFC6675]. It is possible for networks to exhibit higher 283 degrees of reordering, causing a sender to detect spurious losses. 284 Detecting spurious losses leads to unnecessary retransmissions and 285 may result in degraded performance due to the actions of the 286 congestion controller upon detecting loss. Implementers MAY use 287 algorithms developed for TCP, such as TCP-NCR [RFC4653], to improve 288 QUIC's reordering resilience, though care should be taken to map TCP 289 specifics to QUIC correctly. Similarly, using time-based loss 290 detection to deal with reordering, such as in PR-TCP, should be more 291 readily usable in QUIC. Making QUIC deal with such networks is 292 important open research, and implementers are encouraged to explore 293 this space. 295 3.2.2. Early Retransmit 297 Unacknowledged packets close to the tail may have fewer than 298 kReorderingThreshold retransmittable packets sent after them. Loss 299 of such packets cannot be detected via Fast Retransmit. To enable 300 ack-based loss detection of such packets, receipt of an 301 acknowledgment for the last outstanding retransmittable packet 302 triggers the Early Retransmit process, as follows. 304 If there are unacknowledged retransmittable packets still pending, 305 they should be marked as lost. To compensate for the reduced 306 reordering resilience, the sender SHOULD set an alarm for a small 307 period of time. If the unacknowledged retransmittable packets are 308 not acknowledged during this time, then these packets MUST be marked 309 as lost. 311 An endpoint SHOULD set the alarm such that a packet is marked as lost 312 no earlier than 1.25 * max(SRTT, latest_RTT) since when it was sent. 314 Using max(SRTT, latest_RTT) protects from the two following cases: 316 o the latest RTT sample is lower than the SRTT, perhaps due to 317 reordering where packet whose ack triggered the Early Retransit 318 process encountered a shorter path; 320 o the latest RTT sample is higher than the SRTT, perhaps due to a 321 sustained increase in the actual RTT, but the smoothed SRTT has 322 not yet caught up. 324 The 1.25 multiplier increases reordering resilience. Implementers 325 MAY experiment with using other multipliers, bearing in mind that a 326 lower multiplier reduces reordering resilience and increases spurious 327 retransmissions, and a higher multipler increases loss recovery 328 delay. 330 This mechanism is based on Early Retransmit for TCP [RFC5827]. 331 However, [RFC5827] does not include the alarm described above. Early 332 Retransmit is prone to spurious retransmissions due to its reduced 333 reordering resilence without the alarm. This observation led Linux 334 TCP implementers to implement an alarm for TCP as well, and this 335 document incorporates this advancement. 337 3.3. Timer-based Detection 339 Timer-based loss detection implements a handshake retransmission 340 timer that is optimized for QUIC as well as the spirit of TCP's Tail 341 Loss Probe and Retransmission Timeout mechanisms. 343 3.3.1. Handshake Timeout 345 Handshake packets, which contain STREAM frames for stream 0, are 346 critical to QUIC transport and crypto negotiation, so a separate 347 alarm is used for them. 349 The initial handshake timeout SHOULD be set to twice the initial RTT. 351 At the beginning, there are no prior RTT samples within a connection. 352 Resumed connections over the same network SHOULD use the previous 353 connection's final smoothed RTT value as the resumed connection's 354 initial RTT. 356 If no previous RTT is available, or if the network changes, the 357 initial RTT SHOULD be set to 100ms. 359 When a handshake packet is sent, the sender SHOULD set an alarm for 360 the handshake timeout period. 362 When the alarm fires, the sender MUST retransmit all unacknowledged 363 handshake data, by calling RetransmitAllUnackedHandshakeData(). On 364 each consecutive firing of the handshake alarm, the sender SHOULD 365 double the handshake timeout and set an alarm for this period. 367 When an acknowledgement is received for a handshake packet, the new 368 RTT is computed and the alarm SHOULD be set for twice the newly 369 computed smoothed RTT. 371 Handshake data may be cancelled by handshake state transitions. In 372 particular, all non-protected data SHOULD no longer be transmitted 373 once packet protection is available. 375 (TODO: Work this section some more. Add text on client vs. server, 376 and on stateless retry.) 378 3.3.2. Tail Loss Probe 380 The algorithm described in this section is an adaptation of the Tail 381 Loss Probe algorithm proposed for TCP [TLP]. 383 A packet sent at the tail is particularly vulnerable to slow loss 384 detection, since acks of subsequent packets are needed to trigger 385 ack-based detection. To ameliorate this weakness of tail packets, 386 the sender schedules an alarm when the last retransmittable packet 387 before quiescence is transmitted. When this alarm fires, a Tail Loss 388 Probe (TLP) packet is sent to evoke an acknowledgement from the 389 receiver. 391 The alarm duration, or Probe Timeout (PTO), is set based on the 392 following conditions: 394 o PTO SHOULD be scheduled for max(1.5*SRTT+MaxAckDelay, 395 kMinTLPTimeout) 397 o If RTO (Section 3.3.3) is earlier, schedule a TLP alarm in its 398 place. That is, PTO SHOULD be scheduled for min(RTO, PTO). 400 MaxAckDelay is the maximum ack delay supplied in an incoming ACK 401 frame. MaxAckDelay excludes ack delays that aren't included in an 402 RTT sample because they're too large and excludes those which 403 reference an ack-only packet. 405 QUIC diverges from TCP by calculating MaxAckDelay dynamically, 406 instead of assuming a constant delayed ack timeout for all 407 connections. QUIC includes this in all probe timeouts, because it 408 assume the ack delay may come into play, regardless of the number of 409 packets outstanding. TCP's TLP assumes if at least 2 packets are 410 outstanding, acks will not be delayed. 412 A PTO value of at least 1.5*SRTT ensures that the ACK is overdue. 413 The 1.5 is based on [TLP], but implementations MAY experiment with 414 other constants. 416 To reduce latency, it is RECOMMENDED that the sender set and allow 417 the TLP alarm to fire twice before setting an RTO alarm. In other 418 words, when the TLP alarm fires the first time, a TLP packet is sent, 419 and it is RECOMMENDED that the TLP alarm be scheduled for a second 420 time. When the TLP alarm fires the second time, a second TLP packet 421 is sent, and an RTO alarm SHOULD be scheduled Section 3.3.3. 423 A TLP packet SHOULD carry new data when possible. If new data is 424 unavailable or new data cannot be sent due to flow control, a TLP 425 packet MAY retransmit unacknowledged data to potentially reduce 426 recovery time. Since a TLP alarm is used to send a probe into the 427 network prior to establishing any packet loss, prior unacknowledged 428 packets SHOULD NOT be marked as lost when a TLP alarm fires. 430 A sender may not know that a packet being sent is a tail packet. 431 Consequently, a sender may have to arm or adjust the TLP alarm on 432 every sent retransmittable packet. 434 3.3.3. Retransmission Timeout 436 A Retransmission Timeout (RTO) alarm is the final backstop for loss 437 detection. The algorithm used in QUIC is based on the RTO algorithm 438 for TCP [RFC5681] and is additionally resilient to spurious RTO 439 events [RFC5682]. 441 When the last TLP packet is sent, an alarm is scheduled for the RTO 442 period. When this alarm fires, the sender sends two packets, to 443 evoke acknowledgements from the receiver, and restarts the RTO alarm. 445 Similar to TCP [RFC6298], the RTO period is set based on the 446 following conditions: 448 o When the final TLP packet is sent, the RTO period is set to 449 max(SRTT + 4*RTTVAR + MaxAckDelay, kMinRTOTimeout) 451 o When an RTO alarm fires, the RTO period is doubled. 453 The sender typically has incurred a high latency penalty by the time 454 an RTO alarm fires, and this penalty increases exponentially in 455 subsequent consecutive RTO events. Sending a single packet on an RTO 456 event therefore makes the connection very sensitive to single packet 457 loss. Sending two packets instead of one significantly increases 458 resilience to packet drop in both directions, thus reducing the 459 probability of consecutive RTO events. 461 QUIC's RTO algorithm differs from TCP in that the firing of an RTO 462 alarm is not considered a strong enough signal of packet loss, so 463 does not result in an immediate change to congestion window or 464 recovery state. An RTO alarm fires only when there's a prolonged 465 period of network silence, which could be caused by a change in the 466 underlying network RTT. 468 QUIC also diverges from TCP by including MaxAckDelay in the RTO 469 period. QUIC is able to explicitly model delay at the receiver via 470 the ack delay field in the ACK frame. Since QUIC corrects for this 471 delay in its SRTT and RTTVAR computations, it is necessary to add 472 this delay explicitly in the TLP and RTO computation. 474 When an acknowledgment is received for a packet sent on an RTO event, 475 any unacknowledged packets with lower packet numbers than those 476 acknowledged MUST be marked as lost. 478 A packet sent when an RTO alarm fires MAY carry new data if available 479 or unacknowledged data to potentially reduce recovery time. Since 480 this packet is sent as a probe into the network prior to establishing 481 any packet loss, prior unacknowledged packets SHOULD NOT be marked as 482 lost. 484 A packet sent on an RTO alarm MUST NOT be blocked by the sender's 485 congestion controller. A sender MUST however count these bytes as 486 additional bytes in flight, since this packet adds network load 487 without establishing packet loss. 489 3.4. Generating Acknowledgements 491 QUIC SHOULD delay sending acknowledgements in response to packets, 492 but MUST NOT excessively delay acknowledgements of packets containing 493 non-ack frames. Specifically, implementaions MUST attempt to enforce 494 a maximum ack delay to avoid causing the peer spurious timeouts. The 495 default maximum ack delay in QUIC is 25ms. 497 An acknowledgement MAY be sent for every second full-sized packet, as 498 TCP does [RFC5681], or may be sent less frequently, as long as the 499 delay does not exceed the maximum ack delay. QUIC recovery 500 algorithms do not assume the peer generates an acknowledgement 501 immediately when receiving a second full-sized packet. 503 Out-of-order packets SHOULD be acknowledged more quickly, in order to 504 accelerate loss recovery. The receiver SHOULD send an immediate ACK 505 when it receives a new packet which is not one greater than the 506 largest received packet number. 508 As an optimization, a receiver MAY process multiple packets before 509 sending any ACK frames in response. In this case they can determine 510 whether an immediate or delayed acknowledgement should be generated 511 after processing incoming packets. 513 3.4.1. ACK Ranges 515 When an ACK frame is sent, one or more ranges of acknowledged packets 516 are included. Including older packets reduces the chance of spurious 517 retransmits caused by losing previously sent ACK frames, at the cost 518 of larger ACK frames. 520 ACK frames SHOULD always acknowledge the most recently received 521 packets, and the more out-of-order the packets are, the more 522 important it is to send an updated ACK frame quickly, to prevent the 523 peer from declaring a packet as lost and spuriusly retransmitting the 524 frames it contains. 526 Below is one recommended approach for determining what packets to 527 include in an ACK frame. 529 3.4.2. Receiver Tracking of ACK Frames 531 When a packet containing an ACK frame is sent, the largest 532 acknowledged in that frame may be saved. When a packet containing an 533 ACK frame is acknowledged, the receiver can stop acknowledging 534 packets less than or equal to the largest acknowledged in the sent 535 ACK frame. 537 In cases without ACK frame loss, this algorithm allows for a minimum 538 of 1 RTT of reordering. In cases with ACK frame loss, this approach 539 does not guarantee that every acknowledgement is seen by the sender 540 before it is no longer included in the ACK frame. Packets could be 541 received out of order and all subsequent ACK frames containing them 542 could be lost. In this case, the loss recovery algorithm may cause 543 spurious retransmits, but the sender will continue making forward 544 progress. 546 3.5. Pseudocode 548 3.5.1. Constants of interest 550 Constants used in loss recovery are based on a combination of RFCs, 551 papers, and common practice. Some may need to be changed or 552 negotiated in order to better suit a variety of environments. 554 kMaxTLPs (default 2): Maximum number of tail loss probes before an 555 RTO fires. 557 kReorderingThreshold (default 3): Maximum reordering in packet 558 number space before FACK style loss detection considers a packet 559 lost. 561 kTimeReorderingFraction (default 1/8): Maximum reordering in time 562 space before time based loss detection considers a packet lost. 563 In fraction of an RTT. 565 kUsingTimeLossDetection (default false): Whether time based loss 566 detection is in use. If false, uses FACK style loss detection. 568 kMinTLPTimeout (default 10ms): Minimum time in the future a tail 569 loss probe alarm may be set for. 571 kMinRTOTimeout (default 200ms): Minimum time in the future an RTO 572 alarm may be set for. 574 kDelayedAckTimeout (default 25ms): The length of the peer's delayed 575 ack timer. 577 kDefaultInitialRtt (default 100ms): The default RTT used before an 578 RTT sample is taken. 580 3.5.2. Variables of interest 582 Variables required to implement the congestion control mechanisms are 583 described in this section. 585 loss_detection_alarm: Multi-modal alarm used for loss detection. 587 handshake_count: The number of times the handshake packets have been 588 retransmitted without receiving an ack. 590 tlp_count: The number of times a tail loss probe has been sent 591 without receiving an ack. 593 rto_count: The number of times an rto has been sent without 594 receiving an ack. 596 largest_sent_before_rto: The last packet number sent prior to the 597 first retransmission timeout. 599 time_of_last_sent_retransmittable_packet: The time the most recent 600 retransmittable packet was sent. 602 time_of_last_sent_handshake_packet: The time the most recent packet 603 containing handshake data was sent. 605 largest_sent_packet: The packet number of the most recently sent 606 packet. 608 largest_acked_packet: The largest packet number acknowledged in an 609 ACK frame. 611 latest_rtt: The most recent RTT measurement made when receiving an 612 ack for a previously unacked packet. 614 smoothed_rtt: The smoothed RTT of the connection, computed as 615 described in [RFC6298] 617 rttvar: The RTT variance, computed as described in [RFC6298] 618 min_rtt: The minimum RTT seen in the connection, ignoring ack delay. 620 max_ack_delay: The maximum ack delay in an incoming ACK frame for 621 this connection. Excludes ack delays for ack only packets and 622 those that create an RTT sample less than min_rtt. 624 reordering_threshold: The largest packet number gap between the 625 largest acked retransmittable packet and an unacknowledged 626 retransmittable packet before it is declared lost. 628 time_reordering_fraction: The reordering window as a fraction of 629 max(smoothed_rtt, latest_rtt). 631 loss_time: The time at which the next packet will be considered lost 632 based on early transmit or exceeding the reordering window in 633 time. 635 sent_packets: An association of packet numbers to information about 636 them, including a number field indicating the packet number, a 637 time field indicating the time a packet was sent, a boolean 638 indicating whether the packet is ack only, and a bytes field 639 indicating the packet's size. sent_packets is ordered by packet 640 number, and packets remain in sent_packets until acknowledged or 641 lost. 643 3.5.3. Initialization 645 At the beginning of the connection, initialize the loss detection 646 variables as follows: 648 loss_detection_alarm.reset() 649 handshake_count = 0 650 tlp_count = 0 651 rto_count = 0 652 if (kUsingTimeLossDetection) 653 reordering_threshold = infinite 654 time_reordering_fraction = kTimeReorderingFraction 655 else: 656 reordering_threshold = kReorderingThreshold 657 time_reordering_fraction = infinite 658 loss_time = 0 659 smoothed_rtt = 0 660 rttvar = 0 661 min_rtt = infinite 662 max_ack_delay = 0 663 largest_sent_before_rto = 0 664 time_of_last_sent_retransmittable_packet = 0 665 time_of_last_sent_handshake_packet = 0 666 largest_sent_packet = 0 668 3.5.4. On Sending a Packet 670 After any packet is sent, be it a new transmission or a rebundled 671 transmission, the following OnPacketSent function is called. The 672 parameters to OnPacketSent are as follows: 674 o packet_number: The packet number of the sent packet. 676 o is_ack_only: A boolean that indicates whether a packet only 677 contains an ACK frame. If true, it is still expected an ack will 678 be received for this packet, but it is not retransmittable. 680 o is_handshake_packet: A boolean that indicates whether a packet 681 contains handshake data. 683 o sent_bytes: The number of bytes sent in the packet, not including 684 UDP or IP overhead, but including QUIC framing overhead. 686 Pseudocode for OnPacketSent follows: 688 OnPacketSent(packet_number, is_ack_only, is_handshake_packet, 689 sent_bytes): 690 largest_sent_packet = packet_number 691 sent_packets[packet_number].packet_number = packet_number 692 sent_packets[packet_number].time = now 693 sent_packets[packet_number].ack_only = is_ack_only 694 if !is_ack_only: 695 if is_handshake_packet: 696 time_of_last_sent_handshake_packet = now 697 time_of_last_sent_retransmittable_packet = now 698 OnPacketSentCC(sent_bytes) 699 sent_packets[packet_number].bytes = sent_bytes 700 SetLossDetectionAlarm() 702 3.5.5. On Ack Receipt 704 When an ack is received, it may acknowledge 0 or more packets. 706 Pseudocode for OnAckReceived and UpdateRtt follow: 708 OnAckReceived(ack): 709 largest_acked_packet = ack.largest_acked 710 // If the largest acked is newly acked, update the RTT. 711 if (sent_packets[ack.largest_acked]): 712 latest_rtt = now - sent_packets[ack.largest_acked].time 713 UpdateRtt(latest_rtt, ack.ack_delay) 714 // Find all newly acked packets. 715 for acked_packet in DetermineNewlyAckedPackets(): 716 OnPacketAcked(acked_packet.packet_number) 718 DetectLostPackets(ack.largest_acked_packet) 719 SetLossDetectionAlarm() 721 UpdateRtt(latest_rtt, ack_delay): 722 // min_rtt ignores ack delay. 723 min_rtt = min(min_rtt, latest_rtt) 724 // Adjust for ack delay if it's plausible. 725 if (latest_rtt - min_rtt > ack_delay): 726 latest_rtt -= ack_delay 727 // Only save into max ack delay if it's used 728 // for rtt calculation and is not ack only. 729 if (!sent_packets[ack.largest_acked].ack_only) 730 max_ack_delay = max(max_ack_delay, ack_delay) 731 // Based on {{RFC6298}}. 732 if (smoothed_rtt == 0): 733 smoothed_rtt = latest_rtt 734 rttvar = latest_rtt / 2 735 else: 736 rttvar_sample = abs(smoothed_rtt - latest_rtt) 737 rttvar = 3/4 * rttvar + 1/4 * rttvar_sample 738 smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * latest_rtt 740 3.5.6. On Packet Acknowledgment 742 When a packet is acked for the first time, the following 743 OnPacketAcked function is called. Note that a single ACK frame may 744 newly acknowledge several packets. OnPacketAcked must be called once 745 for each of these newly acked packets. 747 OnPacketAcked takes one parameter, acked_packet, which is the struct 748 of the newly acked packet. 750 If this is the first acknowledgement following RTO, check if the 751 smallest newly acknowledged packet is one sent by the RTO, and if so, 752 inform congestion control of a verified RTO, similar to F-RTO 753 [RFC5682] 754 Pseudocode for OnPacketAcked follows: 756 OnPacketAcked(acked_packet): 757 if (!acked_packet.is_ack_only): 758 OnPacketAckedCC(acked_packet) 759 // If a packet sent prior to RTO was acked, then the RTO 760 // was spurious. Otherwise, inform congestion control. 761 if (rto_count > 0 && 762 acked_packet.packet_number > largest_sent_before_rto) 763 OnRetransmissionTimeoutVerified() 764 handshake_count = 0 765 tlp_count = 0 766 rto_count = 0 767 sent_packets.remove(acked_packet.packet_number) 769 3.5.7. Setting the Loss Detection Alarm 771 QUIC loss detection uses a single alarm for all timer-based loss 772 detection. The duration of the alarm is based on the alarm's mode, 773 which is set in the packet and timer events further below. The 774 function SetLossDetectionAlarm defined below shows how the single 775 timer is set based on the alarm mode. 777 3.5.7.1. Handshake Alarm 779 When a connection has unacknowledged handshake data, the handshake 780 alarm is set and when it expires, all unacknowledgedd handshake data 781 is retransmitted. 783 When stateless rejects are in use, the connection is considered 784 immediately closed once a reject is sent, so no timer is set to 785 retransmit the reject. 787 Version negotiation packets are always stateless, and MUST be sent 788 once per handshake packet that uses an unsupported QUIC version, and 789 MAY be sent in response to 0RTT packets. 791 3.5.7.2. Tail Loss Probe and Retransmission Alarm 793 Tail loss probes [TLP] and retransmission timeouts [RFC6298] are an 794 alarm based mechanism to recover from cases when there are 795 outstanding retransmittable packets, but an acknowledgement has not 796 been received in a timely manner. 798 The TLP and RTO timers are armed when there is not unacknowledged 799 handshake data. The TLP alarm is set until the max number of TLP 800 packets have been sent, and then the RTO timer is set. 802 3.5.7.3. Early Retransmit Alarm 804 Early retransmit [RFC5827] is implemented with a 1/4 RTT timer. It 805 is part of QUIC's time based loss detection, but is always enabled, 806 even when only packet reordering loss detection is enabled. 808 3.5.7.4. Pseudocode 810 Pseudocode for SetLossDetectionAlarm follows: 812 SetLossDetectionAlarm(): 813 // Don't arm the alarm if there are no packets with 814 // retransmittable data in flight. 815 if (bytes_in_flight == 0): 816 loss_detection_alarm.cancel() 817 return 819 if (handshake packets are outstanding): 820 // Handshake retransmission alarm. 821 if (smoothed_rtt == 0): 822 alarm_duration = 2 * kDefaultInitialRtt 823 else: 824 alarm_duration = 2 * smoothed_rtt 825 alarm_duration = max(alarm_duration + max_ack_delay, 826 kMinTLPTimeout) 827 alarm_duration = alarm_duration * (2 ^ handshake_count) 828 loss_detection_alarm.set( 829 time_of_last_sent_handshake_packet + alarm_duration) 830 return; 831 else if (loss_time != 0): 832 // Early retransmit timer or time loss detection. 833 alarm_duration = loss_time - 834 time_of_last_sent_retransmittable_packet 835 else: 836 // RTO or TLP alarm 837 // Calculate RTO duration 838 alarm_duration = 839 smoothed_rtt + 4 * rttvar + max_ack_delay 840 alarm_duration = max(alarm_duration, kMinRTOTimeout) 841 alarm_duration = alarm_duration * (2 ^ rto_count) 842 if (tlp_count < kMaxTLPs): 843 // Tail Loss Probe 844 tlp_alarm_duration = max(1.5 * smoothed_rtt 845 + max_ack_delay, kMinTLPTimeout) 846 alarm_duration = min(tlp_alarm_duration, alarm_duration) 848 loss_detection_alarm.set( 849 time_of_last_sent_retransmittable_packet + alarm_duration) 851 3.5.8. On Alarm Firing 853 QUIC uses one loss recovery alarm, which when set, can be in one of 854 several modes. When the alarm fires, the mode determines the action 855 to be performed. 857 Pseudocode for OnLossDetectionAlarm follows: 859 OnLossDetectionAlarm(): 860 if (handshake packets are outstanding): 861 // Handshake retransmission alarm. 862 RetransmitAllUnackedHandshakeData() 863 handshake_count++ 864 else if (loss_time != 0): 865 // Early retransmit or Time Loss Detection 866 DetectLostPackets(largest_acked_packet) 867 else if (tlp_count < kMaxTLPs): 868 // Tail Loss Probe. 869 SendOnePacket() 870 tlp_count++ 871 else: 872 // RTO. 873 if (rto_count == 0) 874 largest_sent_before_rto = largest_sent_packet 875 SendTwoPackets() 876 rto_count++ 878 SetLossDetectionAlarm() 880 3.5.9. Detecting Lost Packets 882 Packets in QUIC are only considered lost once a larger packet number 883 is acknowledged. DetectLostPackets is called every time an ack is 884 received. If the loss detection alarm fires and the loss_time is 885 set, the previous largest acked packet is supplied. 887 3.5.9.1. Handshake Packets 889 The receiver MUST close the connection with an error of type 890 OPTIMISTIC_ACK when receiving an unprotected packet that acks 891 protected packets. The receiver MUST trust protected acks for 892 unprotected packets, however. Aside from this, loss detection for 893 handshake packets when an ack is processed is identical to other 894 packets. 896 3.5.9.2. Pseudocode 898 DetectLostPackets takes one parameter, acked, which is the largest 899 acked packet. 901 Pseudocode for DetectLostPackets follows: 903 DetectLostPackets(largest_acked): 904 loss_time = 0 905 lost_packets = {} 906 delay_until_lost = infinite 907 if (kUsingTimeLossDetection): 908 delay_until_lost = 909 (1 + time_reordering_fraction) * 910 max(latest_rtt, smoothed_rtt) 911 else if (largest_acked.packet_number == largest_sent_packet): 912 // Early retransmit alarm. 913 delay_until_lost = 5/4 * max(latest_rtt, smoothed_rtt) 914 foreach (unacked < largest_acked.packet_number): 915 time_since_sent = now() - unacked.time_sent 916 delta = largest_acked.packet_number - unacked.packet_number 917 if (time_since_sent > delay_until_lost || 918 delta > reordering_threshold): 919 sent_packets.remove(unacked.packet_number) 920 if (!unacked.is_ack_only): 921 lost_packets.insert(unacked) 922 else if (loss_time == 0 && delay_until_lost != infinite): 923 loss_time = now() + delay_until_lost - time_since_sent 925 // Inform the congestion controller of lost packets and 926 // lets it decide whether to retransmit immediately. 927 if (!lost_packets.empty()): 928 OnPacketsLost(lost_packets) 930 3.6. Discussion 932 The majority of constants were derived from best common practices 933 among widely deployed TCP implementations on the internet. 934 Exceptions follow. 936 A shorter delayed ack time of 25ms was chosen because longer delayed 937 acks can delay loss recovery and for the small number of connections 938 where less than packet per 25ms is delivered, acking every packet is 939 beneficial to congestion control and loss recovery. 941 The default initial RTT of 100ms was chosen because it is slightly 942 higher than both the median and mean min_rtt typically observed on 943 the public internet. 945 4. Congestion Control 947 QUIC's congestion control is based on TCP NewReno [RFC6582] 948 congestion control to determine the congestion window. QUIC 949 congestion control is specified in bytes due to finer control and the 950 ease of appropriate byte counting [RFC3465]. 952 QUIC hosts MUST NOT send packets if they would increase 953 bytes_in_flight (defined in Section 4.7.2) beyond the available 954 congestion window, unless the packet is a probe packet sent after the 955 TLP or RTO alarm fires, as described in Section 3.3.2 and 956 Section 3.3.3. 958 4.1. Slow Start 960 QUIC begins every connection in slow start and exits slow start upon 961 loss. QUIC re-enters slow start anytime the congestion window is 962 less than sshthresh, which typically only occurs after an RTO. While 963 in slow start, QUIC increases the congestion window by the number of 964 acknowledged bytes when each ack is processed. 966 4.2. Congestion Avoidance 968 Slow start exits to congestion avoidance. Congestion avoidance in 969 NewReno uses an additive increase multiplicative decrease (AIMD) 970 approach that increases the congestion window by one MSS of bytes per 971 congestion window acknowledged. When a loss is detected, NewReno 972 halves the congestion window and sets the slow start threshold to the 973 new congestion window. 975 4.3. Recovery Period 977 Recovery is a period of time beginning with detection of a lost 978 packet. Because QUIC retransmits stream data and control frames, not 979 packets, it defines the end of recovery as a packet sent after the 980 start of recovery being acknowledged. This is slightly different 981 from TCP's definition of recovery ending when the lost packet that 982 started recovery is acknowledged. 984 During recovery, the congestion window is not increased or decreased. 985 As such, multiple lost packets only decrease the congestion window 986 once as long as they're lost before exiting recovery. This causes 987 QUIC to decrease the congestion window multiple times if 988 retransmisions are lost, but limits the reduction to once per round 989 trip. 991 4.4. Tail Loss Probe 993 A TLP packet MUST NOT be blocked by the sender's congestion 994 controller. The sender MUST however count these bytes as additional 995 bytes-in-flight, since a TLP adds network load without establishing 996 packet loss. 998 Acknowledgement or loss of tail loss probes are treated like any 999 other packet. 1001 4.5. Retransmission Timeout 1003 When retransmissions are sent due to a retransmission timeout alarm, 1004 no change is made to the congestion window until the next 1005 acknowledgement arrives. The retransmission timeout is considered 1006 spurious when this acknowledgement acknowledges packets sent prior to 1007 the first retransmission timeout. The retransmission timeout is 1008 considered valid when this acknowledgement acknowledges no packets 1009 sent prior to the first retransmission timeout. In this case, the 1010 congestion window MUST be reduced to the minimum congestion window 1011 and slow start is re-entered. 1013 4.6. Pacing 1015 This document does not specify a pacer, but it is RECOMMENDED that a 1016 sender pace sending of all retransmittable packets based on input 1017 from the congestion controller. For example, a pacer might 1018 distribute the congestion window over the SRTT when used with a 1019 window-based controller, and a pacer might use the rate estimate of a 1020 rate-based controller. 1022 An implementation should take care to architect its congestion 1023 controller to work well with a pacer. For instance, a pacer might 1024 wrap the congestion controller and control the availability of the 1025 congestion window, or a pacer might pace out packets handed to it by 1026 the congestion controller. Timely delivery of ACK frames is 1027 important for efficient loss recovery. Packets containing only ACK 1028 frames should therefore not be paced, to avoid delaying their 1029 delivery to the peer. 1031 As an example of a well-known and publicly available implementation 1032 of a flow pacer, implementers are referred to the Fair Queue packet 1033 scheduler (fq qdisc) in Linux (3.11 onwards). 1035 4.7. Pseudocode 1037 4.7.1. Constants of interest 1039 Constants used in congestion control are based on a combination of 1040 RFCs, papers, and common practice. Some may need to be changed or 1041 negotiated in order to better suit a variety of environments. 1043 kDefaultMss (default 1460 bytes): The default max packet size used 1044 for calculating default and minimum congestion windows. 1046 kInitialWindow (default 10 * kDefaultMss): Default limit on the 1047 amount of outstanding data in bytes. 1049 kMinimumWindow (default 2 * kDefaultMss): Default minimum congestion 1050 window. 1052 kLossReductionFactor (default 0.5): Reduction in congestion window 1053 when a new loss event is detected. 1055 4.7.2. Variables of interest 1057 Variables required to implement the congestion control mechanisms are 1058 described in this section. 1060 bytes_in_flight: The sum of the size in bytes of all sent packets 1061 that contain at least one retransmittable frame, and have not been 1062 acked or declared lost. The size does not include IP or UDP 1063 overhead. Packets only containing ACK frames do not count towards 1064 bytes_in_flight to ensure congestion control does not impede 1065 congestion feedback. 1067 congestion_window: Maximum number of bytes-in-flight that may be 1068 sent. 1070 end_of_recovery: The largest packet number sent when QUIC detects a 1071 loss. When a larger packet is acknowledged, QUIC exits recovery. 1073 ssthresh: Slow start threshold in bytes. When the congestion window 1074 is below ssthresh, the mode is slow start and the window grows by 1075 the number of bytes acknowledged. 1077 4.7.3. Initialization 1079 At the beginning of the connection, initialize the congestion control 1080 variables as follows: 1082 congestion_window = kInitialWindow 1083 bytes_in_flight = 0 1084 end_of_recovery = 0 1085 ssthresh = infinite 1087 4.7.4. On Packet Sent 1089 Whenever a packet is sent, and it contains non-ACK frames, the packet 1090 increases bytes_in_flight. 1092 OnPacketSentCC(bytes_sent): 1093 bytes_in_flight += bytes_sent 1095 4.7.5. On Packet Acknowledgement 1097 Invoked from loss detection's OnPacketAcked and is supplied with 1098 acked_packet from sent_packets. 1100 InRecovery(packet_number) 1101 return packet_number <= end_of_recovery 1103 OnPacketAckedCC(acked_packet): 1104 // Remove from bytes_in_flight. 1105 bytes_in_flight -= acked_packet.bytes 1106 if (InRecovery(acked_packet.packet_number)): 1107 // Do not increase congestion window in recovery period. 1108 return 1109 if (congestion_window < ssthresh): 1110 // Slow start. 1111 congestion_window += acked_packet.bytes 1112 else: 1113 // Congestion avoidance. 1114 congestion_window += 1115 kDefaultMss * acked_packet.bytes / congestion_window 1117 4.7.6. On Packets Lost 1119 Invoked by loss detection from DetectLostPackets when new packets are 1120 detected lost. 1122 OnPacketsLost(lost_packets): 1123 // Remove lost packets from bytes_in_flight. 1124 for (lost_packet : lost_packets): 1125 bytes_in_flight -= lost_packet.bytes 1126 largest_lost_packet = lost_packets.last() 1127 // Start a new recovery epoch if the lost packet is larger 1128 // than the end of the previous recovery epoch. 1129 if (!InRecovery(largest_lost_packet.packet_number)): 1130 end_of_recovery = largest_sent_packet 1131 congestion_window *= kLossReductionFactor 1132 congestion_window = max(congestion_window, kMinimumWindow) 1133 ssthresh = congestion_window 1135 4.7.7. On Retransmission Timeout Verified 1137 QUIC decreases the congestion window to the minimum value once the 1138 retransmission timeout has been verified. 1140 OnRetransmissionTimeoutVerified() 1141 congestion_window = kMinimumWindow 1143 5. IANA Considerations 1145 This document has no IANA actions. Yet. 1147 6. References 1149 6.1. Normative References 1151 [QUIC-TRANSPORT] 1152 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1153 Multiplexed and Secure Transport", draft-ietf-quic- 1154 transport-11 (work in progress), April 2018. 1156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1157 Requirement Levels", BCP 14, RFC 2119, 1158 DOI 10.17487/RFC2119, March 1997, 1159 . 1161 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1162 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1163 May 2017, . 1165 6.2. Informative References 1167 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 1168 Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 1169 2003, . 1171 [RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, 1172 "Improving the Robustness of TCP to Non-Congestion 1173 Events", RFC 4653, DOI 10.17487/RFC4653, August 2006, 1174 . 1176 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1177 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 1178 . 1180 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 1181 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 1182 Spurious Retransmission Timeouts with TCP", RFC 5682, 1183 DOI 10.17487/RFC5682, September 2009, 1184 . 1186 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 1187 P. Hurtig, "Early Retransmit for TCP and Stream Control 1188 Transmission Protocol (SCTP)", RFC 5827, 1189 DOI 10.17487/RFC5827, May 2010, 1190 . 1192 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1193 "Computing TCP's Retransmission Timer", RFC 6298, 1194 DOI 10.17487/RFC6298, June 2011, 1195 . 1197 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 1198 NewReno Modification to TCP's Fast Recovery Algorithm", 1199 RFC 6582, DOI 10.17487/RFC6582, April 2012, 1200 . 1202 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 1203 and Y. Nishida, "A Conservative Loss Recovery Algorithm 1204 Based on Selective Acknowledgment (SACK) for TCP", 1205 RFC 6675, DOI 10.17487/RFC6675, August 2012, 1206 . 1208 [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1209 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1210 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1211 in progress), February 2013. 1213 6.3. URIs 1215 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1217 [2] https://github.com/quicwg 1219 [3] https://github.com/quicwg/base-drafts/labels/-recovery 1221 Appendix A. Acknowledgments 1223 Appendix B. Change Log 1225 *RFC Editor's Note:* Please remove this section prior to 1226 publication of a final version of this document. 1228 B.1. Since draft-ietf-quic-recovery-10 1230 o Improved text on ack generation (#1139, #1159) 1232 o Make references to TCP recovery mechanisms informational (#1195) 1234 o Define time_of_last_sent_handshake_packet (#1171) 1236 o Added signal from TLS the data it includes needs to be sent in a 1237 Retry packet (#1061, #1199) 1239 o Minimum RTT (min_rtt) is initialized with an infinite value 1240 (#1169) 1242 B.2. Since draft-ietf-quic-recovery-09 1244 No significant changes. 1246 B.3. Since draft-ietf-quic-recovery-08 1248 o Clarified pacing and RTO (#967, #977) 1250 B.4. Since draft-ietf-quic-recovery-07 1252 o Include Ack Delay in RTO(and TLP) computations (#981) 1254 o Ack Delay in SRTT computation (#961) 1256 o Default RTT and Slow Start (#590) 1258 o Many editorial fixes. 1260 B.5. Since draft-ietf-quic-recovery-06 1262 No significant changes. 1264 B.6. Since draft-ietf-quic-recovery-05 1266 o Add more congestion control text (#776) 1268 B.7. Since draft-ietf-quic-recovery-04 1270 No significant changes. 1272 B.8. Since draft-ietf-quic-recovery-03 1274 No significant changes. 1276 B.9. Since draft-ietf-quic-recovery-02 1278 o Integrate F-RTO (#544, #409) 1280 o Add congestion control (#545, #395) 1282 o Require connection abort if a skipped packet was acknowledged 1283 (#415) 1285 o Simplify RTO calculations (#142, #417) 1287 B.10. Since draft-ietf-quic-recovery-01 1289 o Overview added to loss detection 1291 o Changes initial default RTT to 100ms 1293 o Added time-based loss detection and fixes early retransmit 1295 o Clarified loss recovery for handshake packets 1297 o Fixed references and made TCP references informative 1299 B.11. Since draft-ietf-quic-recovery-00 1301 o Improved description of constants and ACK behavior 1303 B.12. Since draft-iyengar-quic-loss-recovery-01 1305 o Adopted as base for draft-ietf-quic-recovery 1307 o Updated authors/editors list 1309 o Added table of contents 1311 Authors' Addresses 1313 Jana Iyengar (editor) 1314 Fastly 1316 Email: jri.ietf@gmail.com 1318 Ian Swett (editor) 1319 Google 1321 Email: ianswett@google.com