idnits 2.17.1 draft-ietf-quic-recovery-10.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 (March 05, 2018) is 2215 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 1123 -- Looks like a reference, but probably isn't: '2' on line 1125 -- Looks like a reference, but probably isn't: '3' on line 1127 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-10 ** Downref: Normative reference to an Experimental RFC: RFC 4653 ** Downref: Normative reference to an Experimental RFC: RFC 5827 -- Duplicate reference: draft-dukkipati-tcpm-tcp-loss-probe, mentioned in 'TLP', was also mentioned in 'LOSS-PROBE'. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 5 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: September 6, 2018 Google 6 March 05, 2018 8 QUIC Loss Detection and Congestion Control 9 draft-ietf-quic-recovery-10 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 September 6, 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 . . . . . . . . . . . . . . . . . 3 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 . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 5 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. Tail Loss Probe . . . . . . . . . . . . . . . . . . . 8 75 3.3.2. Retransmission Timeout . . . . . . . . . . . . . . . 9 76 3.3.3. Handshake Timeout . . . . . . . . . . . . . . . . . . 10 77 3.4. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.4.1. Constants of interest . . . . . . . . . . . . . . . . 11 79 3.4.2. Variables of interest . . . . . . . . . . . . . . . . 12 80 3.4.3. Initialization . . . . . . . . . . . . . . . . . . . 13 81 3.4.4. On Sending a Packet . . . . . . . . . . . . . . . . . 13 82 3.4.5. On Ack Receipt . . . . . . . . . . . . . . . . . . . 14 83 3.4.6. On Packet Acknowledgment . . . . . . . . . . . . . . 15 84 3.4.7. Setting the Loss Detection Alarm . . . . . . . . . . 16 85 3.4.8. On Alarm Firing . . . . . . . . . . . . . . . . . . . 17 86 3.4.9. Detecting Lost Packets . . . . . . . . . . . . . . . 18 87 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 19 88 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 19 89 4.1. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 20 90 4.2. Congestion Avoidance . . . . . . . . . . . . . . . . . . 20 91 4.3. Recovery Period . . . . . . . . . . . . . . . . . . . . . 20 92 4.4. Tail Loss Probe . . . . . . . . . . . . . . . . . . . . . 20 93 4.5. Retransmission Timeout . . . . . . . . . . . . . . . . . 20 94 4.6. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 4.7. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 21 96 4.7.1. Constants of interest . . . . . . . . . . . . . . . . 21 97 4.7.2. Variables of interest . . . . . . . . . . . . . . . . 21 98 4.7.3. Initialization . . . . . . . . . . . . . . . . . . . 22 99 4.7.4. On Packet Sent . . . . . . . . . . . . . . . . . . . 22 100 4.7.5. On Packet Acknowledgement . . . . . . . . . . . . . . 22 101 4.7.6. On Packets Lost . . . . . . . . . . . . . . . . . . . 23 102 4.7.7. On Retransmission Timeout Verified . . . . . . . . . 23 103 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 104 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 6.1. Normative References . . . . . . . . . . . . . . . . . . 24 106 6.2. Informative References . . . . . . . . . . . . . . . . . 25 107 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 108 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25 109 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 110 B.1. Since draft-ietf-quic-recovery-09 . . . . . . . . . . . . 25 111 B.2. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 26 112 B.3. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 26 113 B.4. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 26 114 B.5. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 26 115 B.6. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 26 116 B.7. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 26 117 B.8. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 26 118 B.9. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 26 119 B.10. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 27 120 B.11. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 27 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 123 1. Introduction 125 QUIC is a new multiplexed and secure transport atop UDP. QUIC builds 126 on decades of transport and security experience, and implements 127 mechanisms that make it attractive as a modern general-purpose 128 transport. The QUIC protocol is described in [QUIC-TRANSPORT]. 130 QUIC implements the spirit of known TCP loss recovery mechanisms, 131 described in RFCs, various Internet-drafts, and also those prevalent 132 in the Linux TCP implementation. This document describes QUIC 133 congestion control and loss recovery, and where applicable, 134 attributes the TCP equivalent in RFCs, Internet-drafts, academic 135 papers, and/or TCP implementations. 137 1.1. Notational Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 2. Design of the QUIC Transmission Machinery 147 All transmissions in QUIC are sent with a packet-level header, which 148 includes a packet sequence number (referred to below as a packet 149 number). These packet numbers never repeat in the lifetime of a 150 connection, and are monotonically increasing, which prevents 151 ambiguity. This fundamental design decision obviates the need for 152 disambiguating between transmissions and retransmissions and 153 eliminates significant complexity from QUIC's interpretation of TCP 154 loss detection mechanisms. 156 Every packet may contain several frames. We outline the frames that 157 are important to the loss detection and congestion control machinery 158 below. 160 o Retransmittable frames are frames requiring reliable delivery. 161 The most common are STREAM frames, which typically contain 162 application data. 164 o Crypto handshake data is sent on stream 0, and uses the 165 reliability machinery of QUIC underneath. 167 o ACK frames contain acknowledgment information. ACK frames contain 168 one or more ranges of acknowledged packets. 170 2.1. Relevant Differences Between QUIC and TCP 172 Readers familiar with TCP's loss detection and congestion control 173 will find algorithms here that parallel well-known TCP ones. 174 Protocol differences between QUIC and TCP however contribute to 175 algorithmic differences. We briefly describe these protocol 176 differences below. 178 2.1.1. Monotonically Increasing Packet Numbers 180 TCP conflates transmission sequence number at the sender with 181 delivery sequence number at the receiver, which results in 182 retransmissions of the same data carrying the same sequence number, 183 and consequently to problems caused by "retransmission ambiguity". 184 QUIC separates the two: QUIC uses a packet number for transmissions, 185 and any data that is to be delivered to the receiving application(s) 186 is sent in one or more streams, with delivery order determined by 187 stream offsets encoded within STREAM frames. 189 QUIC's packet number is strictly increasing, and directly encodes 190 transmission order. A higher QUIC packet number signifies that the 191 packet was sent later, and a lower QUIC packet number signifies that 192 the packet was sent earlier. When a packet containing frames is 193 deemed lost, QUIC rebundles necessary frames in a new packet with a 194 new packet number, removing ambiguity about which packet is 195 acknowledged when an ACK is received. Consequently, more accurate 196 RTT measurements can be made, spurious retransmissions are trivially 197 detected, and mechanisms such as Fast Retransmit can be applied 198 universally, based only on packet number. 200 This design point significantly simplifies loss detection mechanisms 201 for QUIC. Most TCP mechanisms implicitly attempt to infer 202 transmission ordering based on TCP sequence numbers - a non-trivial 203 task, especially when TCP timestamps are not available. 205 2.1.2. No Reneging 207 QUIC ACKs contain information that is similar to TCP SACK, but QUIC 208 does not allow any acked packet to be reneged, greatly simplifying 209 implementations on both sides and reducing memory pressure on the 210 sender. 212 2.1.3. More ACK Ranges 214 QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges. In 215 high loss environments, this speeds recovery, reduces spurious 216 retransmits, and ensures forward progress without relying on 217 timeouts. 219 2.1.4. Explicit Correction For Delayed Acks 221 QUIC ACKs explicitly encode the delay incurred at the receiver 222 between when a packet is received and when the corresponding ACK is 223 sent. This allows the receiver of the ACK to adjust for receiver 224 delays, specifically the delayed ack timer, when estimating the path 225 RTT. This mechanism also allows a receiver to measure and report the 226 delay from when a packet was received by the OS kernel, which is 227 useful in receivers which may incur delays such as context-switch 228 latency before a userspace QUIC receiver processes a received packet. 230 3. Loss Detection 232 QUIC senders use both ack information and timeouts to detect lost 233 packets, and this section provides a description of these algorithms. 234 Estimating the network round-trip time (RTT) is critical to these 235 algorithms and is described first. 237 3.1. Computing the RTT estimate 239 RTT is calculated when an ACK frame arrives by computing the 240 difference between the current time and the time the largest newly 241 acked packet was sent. If no packets are newly acknowledged, RTT 242 cannot be calculated. When RTT is calculated, the ack delay field 243 from the ACK frame SHOULD be subtracted from the RTT as long as the 244 result is larger than the Min RTT. If the result is smaller than the 245 min_rtt, the RTT should be used, but the ack delay field should be 246 ignored. 248 Like TCP, QUIC calculates both smoothed RTT and RTT variance as 249 specified in [RFC6298]. 251 Min RTT is the minimum RTT measured over the connection, prior to 252 adjusting by ack delay. Ignoring ack delay for min RTT prevents 253 intentional or unintentional underestimation of min RTT, which in 254 turn prevents underestimating smoothed RTT. 256 3.2. Ack-based Detection 258 Ack-based loss detection implements the spirit of TCP's Fast 259 Retransmit [RFC5681], Early Retransmit [RFC5827], FACK, and SACK loss 260 recovery [RFC6675]. This section provides an overview of how these 261 algorithms are implemented in QUIC. 263 (TODO: Define unacknowledged packet, ackable packet, outstanding 264 bytes.) 266 3.2.1. Fast Retransmit 268 An unacknowledged packet is marked as lost when an acknowledgment is 269 received for a packet that was sent a threshold number of packets 270 (kReorderingThreshold) after the unacknowledged packet. Receipt of 271 the ack indicates that a later packet was received, while 272 kReorderingThreshold provides some tolerance for reordering of 273 packets in the network. 275 The RECOMMENDED initial value for kReorderingThreshold is 3. 277 We derive this default from recommendations for TCP loss recovery 278 [RFC5681] [RFC6675]. It is possible for networks to exhibit higher 279 degrees of reordering, causing a sender to detect spurious losses. 280 Detecting spurious losses leads to unnecessary retransmissions and 281 may result in degraded performance due to the actions of the 282 congestion controller upon detecting loss. Implementers MAY use 283 algorithms developed for TCP, such as TCP-NCR [RFC4653], to improve 284 QUIC's reordering resilience, though care should be taken to map TCP 285 specifics to QUIC correctly. Similarly, using time-based loss 286 detection to deal with reordering, such as in PR-TCP, should be more 287 readily usable in QUIC. Making QUIC deal with such networks is 288 important open research, and implementers are encouraged to explore 289 this space. 291 3.2.2. Early Retransmit 293 Unacknowledged packets close to the tail may have fewer than 294 kReorderingThreshold number of ackable packets sent after them. Loss 295 of such packets cannot be detected via Fast Retransmit. To enable 296 ack-based loss detection of such packets, receipt of an 297 acknowledgment for the last outstanding ackable packet triggers the 298 Early Retransmit process, as follows. 300 If there are unacknowledged ackable packets still pending, they ought 301 to be marked as lost. To compensate for the reduced reordering 302 resilience, the sender SHOULD set an alarm for a small period of 303 time. If the unacknowledged ackable packets are not acknowledged 304 during this time, then these packets MUST be marked as lost. 306 An endpoint SHOULD set the alarm such that a packet is marked as lost 307 no earlier than 1.25 * max(SRTT, latest_RTT) since when it was sent. 309 Using max(SRTT, latest_RTT) protects from the two following cases: 311 o the latest RTT sample is lower than the SRTT, perhaps due to 312 reordering where packet whose ack triggered the Early Retransit 313 process encountered a shorter path; 315 o the latest RTT sample is higher than the SRTT, perhaps due to a 316 sustained increase in the actual RTT, but the smoothed SRTT has 317 not yet caught up. 319 The 1.25 multiplier increases reordering resilience. Implementers 320 MAY experiment with using other multipliers, bearing in mind that a 321 lower multiplier reduces reordering resilience and increases spurious 322 retransmissions, and a higher multipler increases loss recovery 323 delay. 325 This mechanism is based on Early Retransmit for TCP [RFC5827]. 326 However, [RFC5827] does not include the alarm described above. Early 327 Retransmit is prone to spurious retransmissions due to its reduced 328 reordering resilence without the alarm. This observation led Linux 329 TCP implementers to implement an alarm for TCP as well, and this 330 document incorporates this advancement. 332 3.3. Timer-based Detection 334 Timer-based loss detection implements the spirit of TCP's Tail Loss 335 Probe and Retransmission Timeout mechanisms. 337 3.3.1. Tail Loss Probe 339 The algorithm described in this section is an adaptation of the Tail 340 Loss Probe algorithm proposed for TCP [TLP]. 342 A packet sent at the tail is particularly vulnerable to slow loss 343 detection, since acks of subsequent packets are needed to trigger 344 ack-based detection. To ameliorate this weakness of tail packets, 345 the sender schedules an alarm when the last ackable packet before 346 quiescence is transmitted. When this alarm fires, a Tail Loss Probe 347 (TLP) packet is sent to evoke an acknowledgement from the receiver. 349 The alarm duration, or Probe Timeout (PTO), is set based on the 350 following conditions: 352 o PTO SHOULD be scheduled for max(1.5*SRTT+MaxAckDelay, 10ms) 354 o If RTO (Section 3.3.2) is earlier, schedule a TLP alarm in its 355 place. That is, PTO SHOULD be scheduled for min(RTO, PTO). 357 MaxAckDelay is the maximum ack delay supplied in an incoming ACK 358 frame. MaxAckDelay excludes ack delays that aren't included in an 359 RTT sample because they're too large and excludes those which 360 reference an ack-only packet. 362 QUIC diverges from TCP by calculating MaxAckDelay dynamically, 363 instead of assuming a constant delayed ack timeout for all 364 connections. QUIC includes this in all probe timeouts, because it 365 assume the ack delay may come into play, regardless of the number of 366 packets outstanding. TCP's TLP assumes if at least 2 packets are 367 outstanding, acks will not be delayed. 369 A PTO value of at least 1.5*SRTT ensures that the ACK is overdue. 370 The 1.5 is based on [LOSS-PROBE], but implementations MAY experiment 371 with other constants. 373 To reduce latency, it is RECOMMENDED that the sender set and allow 374 the TLP alarm to fire twice before setting an RTO alarm. In other 375 words, when the TLP alarm fires the first time, a TLP packet is sent, 376 and it is RECOMMENDED that the TLP alarm be scheduled for a second 377 time. When the TLP alarm fires the second time, a second TLP packet 378 is sent, and an RTO alarm SHOULD be scheduled Section 3.3.2. 380 A TLP packet SHOULD carry new data when possible. If new data is 381 unavailable or new data cannot be sent due to flow control, a TLP 382 packet MAY retransmit unacknowledged data to potentially reduce 383 recovery time. Since a TLP alarm is used to send a probe into the 384 network prior to establishing any packet loss, prior unacknowledged 385 packets SHOULD NOT be marked as lost when a TLP alarm fires. 387 A TLP packet MUST NOT be blocked by the sender's congestion 388 controller. The sender MUST however count these bytes as additional 389 bytes in flight, since a TLP adds network load without establishing 390 packet loss. 392 A sender may not know that a packet being sent is a tail packet. 393 Consequently, a sender may have to arm or adjust the TLP alarm on 394 every sent ackable packet. 396 3.3.2. Retransmission Timeout 398 A Retransmission Timeout (RTO) alarm is the final backstop for loss 399 detection. The algorithm used in QUIC is based on the RTO algorithm 400 for TCP [RFC5681] and is additionally resilient to spurious RTO 401 events [RFC5682]. 403 When the last TLP packet is sent, an alarm is scheduled for the RTO 404 period. When this alarm fires, the sender sends two packets, to 405 evoke acknowledgements from the receiver, and restarts the RTO alarm. 407 Similar to TCP [RFC6298], the RTO period is set based on the 408 following conditions: 410 o When the final TLP packet is sent, the RTO period is set to 411 max(SRTT + 4*RTTVAR + MaxAckDelay, minRTO) 413 o When an RTO alarm fires, the RTO period is doubled. 415 The sender typically has incurred a high latency penalty by the time 416 an RTO alarm fires, and this penalty increases exponentially in 417 subsequent consecutive RTO events. Sending a single packet on an RTO 418 event therefore makes the connection very sensitive to single packet 419 loss. Sending two packets instead of one significantly increases 420 resilience to packet drop in both directions, thus reducing the 421 probability of consecutive RTO events. 423 QUIC's RTO algorithm differs from TCP in that the firing of an RTO 424 alarm is not considered a strong enough signal of packet loss, so 425 does not result in an immediate change to congestion window or 426 recovery state. An RTO alarm fires only when there's a prolonged 427 period of network silence, which could be caused by a change in the 428 underlying network RTT. 430 QUIC also diverges from TCP by including MaxAckDelay in the RTO 431 period. QUIC is able to explicitly model delay at the receiver via 432 the ack delay field in the ACK frame. Since QUIC corrects for this 433 delay in its SRTT and RTTVAR computations, it is necessary to add 434 this delay explicitly in the TLP and RTO computation. 436 When an acknowledgment is received for a packet sent on an RTO event, 437 any unacknowledged packets with lower packet numbers than those 438 acknowledged MUST be marked as lost. 440 A packet sent when an RTO alarm fires MAY carry new data if available 441 or unacknowledged data to potentially reduce recovery time. Since 442 this packet is sent as a probe into the network prior to establishing 443 any packet loss, prior unacknowledged packets SHOULD NOT be marked as 444 lost. 446 A packet sent on an RTO alarm MUST NOT be blocked by the sender's 447 congestion controller. A sender MUST however count these bytes as 448 additional bytes in flight, since this packet adds network load 449 without establishing packet loss. 451 3.3.3. Handshake Timeout 453 Handshake packets, which contain STREAM frames for stream 0, are 454 critical to QUIC transport and crypto negotiation, so a separate 455 alarm is used for them. 457 The initial handshake timeout SHOULD be set to twice the initial RTT. 459 At the beginning, there are no prior RTT samples within a connection. 460 Resumed connections over the same network SHOULD use the previous 461 connection's final smoothed RTT value as the resumed connection's 462 initial RTT. 464 If no previous RTT is available, or if the network changes, the 465 initial RTT SHOULD be set to 100ms. 467 When the first handshake packet is sent, the sender SHOULD set an 468 alarm for the handshake timeout period. 470 When the alarm fires, the sender MUST retransmit all unacknowledged 471 handshake data. On each consecutive firing of the handshake alarm, 472 the sender SHOULD double the handshake timeout and set an alarm for 473 this period. 475 When an acknowledgement is received for a handshake packet, the new 476 RTT is computed and the alarm SHOULD be set for twice the newly 477 computed smoothed RTT. 479 Handshake data may be cancelled by handshake state transitions. In 480 particular, all non-protected data SHOULD no longer be transmitted 481 once packet protection is available. 483 (TODO: Work this section some more. Add text on client vs. server, 484 and on stateless retry.) 486 3.4. Pseudocode 488 3.4.1. Constants of interest 490 Constants used in loss recovery are based on a combination of RFCs, 491 papers, and common practice. Some may need to be changed or 492 negotiated in order to better suit a variety of environments. 494 kMaxTLPs (default 2): Maximum number of tail loss probes before an 495 RTO fires. 497 kReorderingThreshold (default 3): Maximum reordering in packet 498 number space before FACK style loss detection considers a packet 499 lost. 501 kTimeReorderingFraction (default 1/8): Maximum reordering in time 502 space before time based loss detection considers a packet lost. 503 In fraction of an RTT. 505 kUsingTimeLossDetection (default false): Whether time based loss 506 detection is in use. If false, uses FACK style loss detection. 508 kMinTLPTimeout (default 10ms): Minimum time in the future a tail 509 loss probe alarm may be set for. 511 kMinRTOTimeout (default 200ms): Minimum time in the future an RTO 512 alarm may be set for. 514 kDelayedAckTimeout (default 25ms): The length of the peer's delayed 515 ack timer. 517 kDefaultInitialRtt (default 100ms): The default RTT used before an 518 RTT sample is taken. 520 3.4.2. Variables of interest 522 Variables required to implement the congestion control mechanisms are 523 described in this section. 525 loss_detection_alarm: Multi-modal alarm used for loss detection. 527 handshake_count: The number of times the handshake packets have been 528 retransmitted without receiving an ack. 530 tlp_count: The number of times a tail loss probe has been sent 531 without receiving an ack. 533 rto_count: The number of times an rto has been sent without 534 receiving an ack. 536 largest_sent_before_rto: The last packet number sent prior to the 537 first retransmission timeout. 539 time_of_last_sent_packet: The time the most recent packet was sent. 541 largest_sent_packet: The packet number of the most recently sent 542 packet. 544 largest_acked_packet: The largest packet number acknowledged in an 545 ACK frame. 547 latest_rtt: The most recent RTT measurement made when receiving an 548 ack for a previously unacked packet. 550 smoothed_rtt: The smoothed RTT of the connection, computed as 551 described in [RFC6298] 553 rttvar: The RTT variance, computed as described in [RFC6298] 555 min_rtt: The minimum RTT seen in the connection, ignoring ack delay. 557 max_ack_delay: The maximum ack delay in an incoming ACK frame for 558 this connection. Excludes ack delays for ack only packets and 559 those that create an RTT sample less than min_rtt. 561 reordering_threshold: The largest delta between the largest acked 562 retransmittable packet and a packet containing retransmittable 563 frames before it's declared lost. 565 time_reordering_fraction: The reordering window as a fraction of 566 max(smoothed_rtt, latest_rtt). 568 loss_time: The time at which the next packet will be considered lost 569 based on early transmit or exceeding the reordering window in 570 time. 572 sent_packets: An association of packet numbers to information about 573 them, including a number field indicating the packet number, a 574 time field indicating the time a packet was sent, a boolean 575 indicating whether the packet is ack only, and a bytes field 576 indicating the packet's size. sent_packets is ordered by packet 577 number, and packets remain in sent_packets until acknowledged or 578 lost. 580 3.4.3. Initialization 582 At the beginning of the connection, initialize the loss detection 583 variables as follows: 585 loss_detection_alarm.reset() 586 handshake_count = 0 587 tlp_count = 0 588 rto_count = 0 589 if (kUsingTimeLossDetection) 590 reordering_threshold = infinite 591 time_reordering_fraction = kTimeReorderingFraction 592 else: 593 reordering_threshold = kReorderingThreshold 594 time_reordering_fraction = infinite 595 loss_time = 0 596 smoothed_rtt = 0 597 rttvar = 0 598 min_rtt = 0 599 max_ack_delay = 0 600 largest_sent_before_rto = 0 601 time_of_last_sent_packet = 0 602 largest_sent_packet = 0 604 3.4.4. On Sending a Packet 606 After any packet is sent, be it a new transmission or a rebundled 607 transmission, the following OnPacketSent function is called. The 608 parameters to OnPacketSent are as follows: 610 o packet_number: The packet number of the sent packet. 612 o is_ack_only: A boolean that indicates whether a packet only 613 contains an ACK frame. If true, it is still expected an ack will 614 be received for this packet, but it is not congestion controlled. 616 o sent_bytes: The number of bytes sent in the packet, not including 617 UDP or IP overhead, but including QUIC framing overhead. 619 Pseudocode for OnPacketSent follows: 621 OnPacketSent(packet_number, is_ack_only, sent_bytes): 622 time_of_last_sent_packet = now 623 largest_sent_packet = packet_number 624 sent_packets[packet_number].packet_number = packet_number 625 sent_packets[packet_number].time = now 626 sent_packets[packet_number].ack_only = is_ack_only 627 if !is_ack_only: 628 OnPacketSentCC(sent_bytes) 629 sent_packets[packet_number].bytes = sent_bytes 630 SetLossDetectionAlarm() 632 3.4.5. On Ack Receipt 634 When an ack is received, it may acknowledge 0 or more packets. 636 Pseudocode for OnAckReceived and UpdateRtt follow: 638 OnAckReceived(ack): 639 largest_acked_packet = ack.largest_acked 640 // If the largest acked is newly acked, update the RTT. 641 if (sent_packets[ack.largest_acked]): 642 latest_rtt = now - sent_packets[ack.largest_acked].time 643 UpdateRtt(latest_rtt, ack.ack_delay) 644 // Find all newly acked packets. 645 for acked_packet in DetermineNewlyAckedPackets(): 646 OnPacketAcked(acked_packet.packet_number) 648 DetectLostPackets(ack.largest_acked_packet) 649 SetLossDetectionAlarm() 651 UpdateRtt(latest_rtt, ack_delay): 652 // min_rtt ignores ack delay. 653 min_rtt = min(min_rtt, latest_rtt) 654 // Adjust for ack delay if it's plausible. 655 if (latest_rtt - min_rtt > ack_delay): 656 latest_rtt -= ack_delay 657 // Only save into max ack delay if it's used 658 // for rtt calculation and is not ack only. 659 if (!sent_packets[ack.largest_acked].ack_only) 660 max_ack_delay = max(max_ack_delay, ack_delay) 661 // Based on {{RFC6298}}. 662 if (smoothed_rtt == 0): 663 smoothed_rtt = latest_rtt 664 rttvar = latest_rtt / 2 665 else: 666 rttvar_sample = abs(smoothed_rtt - latest_rtt) 667 rttvar = 3/4 * rttvar + 1/4 * rttvar_sample 668 smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * latest_rtt 670 3.4.6. On Packet Acknowledgment 672 When a packet is acked for the first time, the following 673 OnPacketAcked function is called. Note that a single ACK frame may 674 newly acknowledge several packets. OnPacketAcked must be called once 675 for each of these newly acked packets. 677 OnPacketAcked takes one parameter, acked_packet_number, which is the 678 packet number of the newly acked packet, and returns a list of packet 679 numbers that are detected as lost. 681 If this is the first acknowledgement following RTO, check if the 682 smallest newly acknowledged packet is one sent by the RTO, and if so, 683 inform congestion control of a verified RTO, similar to F-RTO 684 [RFC5682] 685 Pseudocode for OnPacketAcked follows: 687 OnPacketAcked(acked_packet_number): 688 OnPacketAckedCC(acked_packet_number) 689 // If a packet sent prior to RTO was acked, then the RTO 690 // was spurious. Otherwise, inform congestion control. 691 if (rto_count > 0 && 692 acked_packet_number > largest_sent_before_rto) 693 OnRetransmissionTimeoutVerified() 694 handshake_count = 0 695 tlp_count = 0 696 rto_count = 0 697 sent_packets.remove(acked_packet_number) 699 3.4.7. Setting the Loss Detection Alarm 701 QUIC loss detection uses a single alarm for all timer-based loss 702 detection. The duration of the alarm is based on the alarm's mode, 703 which is set in the packet and timer events further below. The 704 function SetLossDetectionAlarm defined below shows how the single 705 timer is set based on the alarm mode. 707 3.4.7.1. Handshake Alarm 709 When a connection has unacknowledged handshake data, the handshake 710 alarm is set and when it expires, all unacknowledgedd handshake data 711 is retransmitted. 713 When stateless rejects are in use, the connection is considered 714 immediately closed once a reject is sent, so no timer is set to 715 retransmit the reject. 717 Version negotiation packets are always stateless, and MUST be sent 718 once per handshake packet that uses an unsupported QUIC version, and 719 MAY be sent in response to 0RTT packets. 721 3.4.7.2. Tail Loss Probe and Retransmission Alarm 723 Tail loss probes [LOSS-PROBE] and retransmission timeouts [RFC6298] 724 are an alarm based mechanism to recover from cases when there are 725 outstanding retransmittable packets, but an acknowledgement has not 726 been received in a timely manner. 728 The TLP and RTO timers are armed when there is not unacknowledged 729 handshake data. The TLP alarm is set until the max number of TLP 730 packets have been sent, and then the RTO timer is set. 732 3.4.7.3. Early Retransmit Alarm 734 Early retransmit [RFC5827] is implemented with a 1/4 RTT timer. It 735 is part of QUIC's time based loss detection, but is always enabled, 736 even when only packet reordering loss detection is enabled. 738 3.4.7.4. Pseudocode 740 Pseudocode for SetLossDetectionAlarm follows: 742 SetLossDetectionAlarm(): 743 // Don't arm the alarm if there are no packets with 744 // retransmittable data in flight. 745 if (num_retransmittable_packets_outstanding == 0): 746 loss_detection_alarm.cancel() 747 return 749 if (handshake packets are outstanding): 750 // Handshake retransmission alarm. 751 if (smoothed_rtt == 0): 752 alarm_duration = 2 * kDefaultInitialRtt 753 else: 754 alarm_duration = 2 * smoothed_rtt 755 alarm_duration = max(alarm_duration + max_ack_delay, 756 kMinTLPTimeout) 757 alarm_duration = alarm_duration * (2 ^ handshake_count) 758 else if (loss_time != 0): 759 // Early retransmit timer or time loss detection. 760 alarm_duration = loss_time - time_of_last_sent_packet 761 else if (tlp_count < kMaxTLPs): 762 // Tail Loss Probe 763 alarm_duration = max(1.5 * smoothed_rtt + max_ack_delay, 764 kMinTLPTimeout) 765 else: 766 // RTO alarm 767 alarm_duration = 768 smoothed_rtt + 4 * rttvar + max_ack_delay 769 alarm_duration = max(alarm_duration, kMinRTOTimeout) 770 alarm_duration = alarm_duration * (2 ^ rto_count) 772 loss_detection_alarm.set(time_of_last_sent_packet 773 + alarm_duration) 775 3.4.8. On Alarm Firing 777 QUIC uses one loss recovery alarm, which when set, can be in one of 778 several modes. When the alarm fires, the mode determines the action 779 to be performed. 781 Pseudocode for OnLossDetectionAlarm follows: 783 OnLossDetectionAlarm(): 784 if (handshake packets are outstanding): 785 // Handshake retransmission alarm. 786 RetransmitAllHandshakePackets() 787 handshake_count++ 788 else if (loss_time != 0): 789 // Early retransmit or Time Loss Detection 790 DetectLostPackets(largest_acked_packet) 791 else if (tlp_count < kMaxTLPs): 792 // Tail Loss Probe. 793 SendOnePacket() 794 tlp_count++ 795 else: 796 // RTO. 797 if (rto_count == 0) 798 largest_sent_before_rto = largest_sent_packet 799 SendTwoPackets() 800 rto_count++ 802 SetLossDetectionAlarm() 804 3.4.9. Detecting Lost Packets 806 Packets in QUIC are only considered lost once a larger packet number 807 is acknowledged. DetectLostPackets is called every time an ack is 808 received. If the loss detection alarm fires and the loss_time is 809 set, the previous largest acked packet is supplied. 811 3.4.9.1. Handshake Packets 813 The receiver MUST close the connection with an error of type 814 OPTIMISTIC_ACK when receiving an unprotected packet that acks 815 protected packets. The receiver MUST trust protected acks for 816 unprotected packets, however. Aside from this, loss detection for 817 handshake packets when an ack is processed is identical to other 818 packets. 820 3.4.9.2. Pseudocode 822 DetectLostPackets takes one parameter, acked, which is the largest 823 acked packet. 825 Pseudocode for DetectLostPackets follows: 827 DetectLostPackets(largest_acked): 828 loss_time = 0 829 lost_packets = {} 830 delay_until_lost = infinite 831 if (kUsingTimeLossDetection): 832 delay_until_lost = 833 (1 + time_reordering_fraction) * 834 max(latest_rtt, smoothed_rtt) 835 else if (largest_acked.packet_number == largest_sent_packet): 836 // Early retransmit alarm. 837 delay_until_lost = 5/4 * max(latest_rtt, smoothed_rtt) 838 foreach (unacked < largest_acked.packet_number): 839 time_since_sent = now() - unacked.time_sent 840 delta = largest_acked.packet_number - unacked.packet_number 841 if (time_since_sent > delay_until_lost): 842 lost_packets.insert(unacked) 843 else if (delta > reordering_threshold) 844 lost_packets.insert(unacked) 845 else if (loss_time == 0 && delay_until_lost != infinite): 846 loss_time = now() + delay_until_lost - time_since_sent 848 // Inform the congestion controller of lost packets and 849 // lets it decide whether to retransmit immediately. 850 if (!lost_packets.empty()) 851 OnPacketsLost(lost_packets) 852 foreach (packet in lost_packets) 853 sent_packets.remove(packet.packet_number) 855 3.5. Discussion 857 The majority of constants were derived from best common practices 858 among widely deployed TCP implementations on the internet. 859 Exceptions follow. 861 A shorter delayed ack time of 25ms was chosen because longer delayed 862 acks can delay loss recovery and for the small number of connections 863 where less than packet per 25ms is delivered, acking every packet is 864 beneficial to congestion control and loss recovery. 866 The default initial RTT of 100ms was chosen because it is slightly 867 higher than both the median and mean min_rtt typically observed on 868 the public internet. 870 4. Congestion Control 872 QUIC's congestion control is based on TCP NewReno [RFC6582] 873 congestion control to determine the congestion window. QUIC 874 congestion control is specified in bytes due to finer control and the 875 ease of appropriate byte counting [RFC3465]. 877 4.1. Slow Start 879 QUIC begins every connection in slow start and exits slow start upon 880 loss. QUIC re-enters slow start anytime the congestion window is 881 less than sshthresh, which typically only occurs after an RTO. While 882 in slow start, QUIC increases the congestion window by the number of 883 acknowledged bytes when each ack is processed. 885 4.2. Congestion Avoidance 887 Slow start exits to congestion avoidance. Congestion avoidance in 888 NewReno uses an additive increase multiplicative decrease (AIMD) 889 approach that increases the congestion window by one MSS of bytes per 890 congestion window acknowledged. When a loss is detected, NewReno 891 halves the congestion window and sets the slow start threshold to the 892 new congestion window. 894 4.3. Recovery Period 896 Recovery is a period of time beginning with detection of a lost 897 packet. Because QUIC retransmits stream data and control frames, not 898 packets, it defines the end of recovery as a packet sent after the 899 start of recovery being acknowledged. This is slightly different 900 from TCP's definition of recovery ending when the lost packet that 901 started recovery is acknowledged. 903 During recovery, the congestion window is not increased or decreased. 904 As such, multiple lost packets only decrease the congestion window 905 once as long as they're lost before exiting recovery. This causes 906 QUIC to decrease the congestion window multiple times if 907 retransmisions are lost, but limits the reduction to once per round 908 trip. 910 4.4. Tail Loss Probe 912 If recovery sends a tail loss probe, no change is made to the 913 congestion window. Acknowledgement or loss of tail loss probes are 914 treated like any other packet. 916 4.5. Retransmission Timeout 918 When retransmissions are sent due to a retransmission timeout alarm, 919 no change is made to the congestion window until the next 920 acknowledgement arrives. The retransmission timeout is considered 921 spurious when this acknowledgement acknowledges packets sent prior to 922 the first retransmission timeout. The retransmission timeout is 923 considered valid when this acknowledgement acknowledges no packets 924 sent prior to the first retransmission timeout. In this case, the 925 congestion window MUST be reduced to the minimum congestion window 926 and slow start is re-entered. 928 4.6. Pacing 930 It is RECOMMENDED that a sender pace sending of all data, 931 distributing the congestion window over the SRTT. This document does 932 not specify a pacer. As an example pacer, implementers are referred 933 to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards) 934 as a well-known and publicly available implementation of a flow 935 pacer. 937 4.7. Pseudocode 939 4.7.1. Constants of interest 941 Constants used in congestion control are based on a combination of 942 RFCs, papers, and common practice. Some may need to be changed or 943 negotiated in order to better suit a variety of environments. 945 kDefaultMss (default 1460 bytes): The default max packet size used 946 for calculating default and minimum congestion windows. 948 kInitialWindow (default 10 * kDefaultMss): Default limit on the 949 amount of outstanding data in bytes. 951 kMinimumWindow (default 2 * kDefaultMss): Default minimum congestion 952 window. 954 kLossReductionFactor (default 0.5): Reduction in congestion window 955 when a new loss event is detected. 957 4.7.2. Variables of interest 959 Variables required to implement the congestion control mechanisms are 960 described in this section. 962 bytes_in_flight: The sum of the size in bytes of all sent packets 963 that contain at least one retransmittable or PADDING frame, and 964 have not been acked or declared lost. The size does not include 965 IP or UDP overhead. Packets only containing ACK frames do not 966 count towards byte_in_flight to ensure congestion control does not 967 impede congestion feedback. 969 congestion_window: Maximum number of bytes in flight that may be 970 sent. 972 end_of_recovery: The largest packet number sent when QUIC detects a 973 loss. When a larger packet is acknowledged, QUIC exits recovery. 975 ssthresh: Slow start threshold in bytes. When the congestion window 976 is below ssthresh, the mode is slow start and the window grows by 977 the number of bytes acknowledged. 979 4.7.3. Initialization 981 At the beginning of the connection, initialize the congestion control 982 variables as follows: 984 congestion_window = kInitialWindow 985 bytes_in_flight = 0 986 end_of_recovery = 0 987 ssthresh = infinite 989 4.7.4. On Packet Sent 991 Whenever a packet is sent, and it contains non-ACK frames, the packet 992 increases bytes_in_flight. 994 OnPacketSentCC(bytes_sent): 995 bytes_in_flight += bytes_sent 997 4.7.5. On Packet Acknowledgement 999 Invoked from loss detection's OnPacketAcked and is supplied with 1000 acked_packet from sent_packets. 1002 InRecovery(packet_number) 1003 return packet_number <= end_of_recovery 1005 OnPacketAckedCC(acked_packet): 1006 // Remove from bytes_in_flight. 1007 bytes_in_flight -= acked_packet.bytes 1008 if (InRecovery(acked_packet.packet_number)): 1009 // Do not increase congestion window in recovery period. 1010 return 1011 if (congestion_window < ssthresh): 1012 // Slow start. 1013 congestion_window += acked_packet.bytes 1014 else: 1015 // Congestion avoidance. 1016 congestion_window += 1017 kDefaultMss * acked_packet.bytes / congestion_window 1019 4.7.6. On Packets Lost 1021 Invoked by loss detection from DetectLostPackets when new packets are 1022 detected lost. 1024 OnPacketsLost(lost_packets): 1025 // Remove lost packets from bytes_in_flight. 1026 for (lost_packet : lost_packets): 1027 bytes_in_flight -= lost_packet.bytes 1028 largest_lost_packet = lost_packets.last() 1029 // Start a new recovery epoch if the lost packet is larger 1030 // than the end of the previous recovery epoch. 1031 if (!InRecovery(largest_lost_packet.packet_number)): 1032 end_of_recovery = largest_sent_packet 1033 congestion_window *= kLossReductionFactor 1034 congestion_window = max(congestion_window, kMinimumWindow) 1035 ssthresh = congestion_window 1037 4.7.7. On Retransmission Timeout Verified 1039 QUIC decreases the congestion window to the minimum value once the 1040 retransmission timeout has been verified. 1042 OnRetransmissionTimeoutVerified() 1043 congestion_window = kMinimumWindow 1045 5. IANA Considerations 1047 This document has no IANA actions. Yet. 1049 6. References 1051 6.1. Normative References 1053 [QUIC-TRANSPORT] 1054 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1055 Multiplexed and Secure Transport", draft-ietf-quic- 1056 transport-10 (work in progress), March 2018. 1058 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1059 Requirement Levels", BCP 14, RFC 2119, 1060 DOI 10.17487/RFC2119, March 1997, 1061 . 1063 [RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, 1064 "Improving the Robustness of TCP to Non-Congestion 1065 Events", RFC 4653, DOI 10.17487/RFC4653, August 2006, 1066 . 1068 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1069 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 1070 . 1072 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 1073 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 1074 Spurious Retransmission Timeouts with TCP", RFC 5682, 1075 DOI 10.17487/RFC5682, September 2009, 1076 . 1078 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 1079 P. Hurtig, "Early Retransmit for TCP and Stream Control 1080 Transmission Protocol (SCTP)", RFC 5827, 1081 DOI 10.17487/RFC5827, May 2010, 1082 . 1084 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1085 "Computing TCP's Retransmission Timer", RFC 6298, 1086 DOI 10.17487/RFC6298, June 2011, 1087 . 1089 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 1090 and Y. Nishida, "A Conservative Loss Recovery Algorithm 1091 Based on Selective Acknowledgment (SACK) for TCP", 1092 RFC 6675, DOI 10.17487/RFC6675, August 2012, 1093 . 1095 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1096 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1097 May 2017, . 1099 6.2. Informative References 1101 [LOSS-PROBE] 1102 Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1103 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1104 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1105 in progress), February 2013. 1107 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 1108 Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 1109 2003, . 1111 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 1112 NewReno Modification to TCP's Fast Recovery Algorithm", 1113 RFC 6582, DOI 10.17487/RFC6582, April 2012, 1114 . 1116 [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1117 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1118 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1119 in progress), February 2013. 1121 6.3. URIs 1123 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1125 [2] https://github.com/quicwg 1127 [3] https://github.com/quicwg/base-drafts/labels/-recovery 1129 Appendix A. Acknowledgments 1131 Appendix B. Change Log 1133 *RFC Editor's Note:* Please remove this section prior to 1134 publication of a final version of this document. 1136 B.1. Since draft-ietf-quic-recovery-09 1138 No significant changes. 1140 B.2. Since draft-ietf-quic-recovery-08 1142 o Clarified pacing and RTO (#967, #977) 1144 B.3. Since draft-ietf-quic-recovery-07 1146 o Include Ack Delay in RTO(and TLP) computations (#981) 1148 o Ack Delay in SRTT computation (#961) 1150 o Default RTT and Slow Start (#590) 1152 o Many editorial fixes. 1154 B.4. Since draft-ietf-quic-recovery-06 1156 No significant changes. 1158 B.5. Since draft-ietf-quic-recovery-05 1160 o Add more congestion control text (#776) 1162 B.6. Since draft-ietf-quic-recovery-04 1164 No significant changes. 1166 B.7. Since draft-ietf-quic-recovery-03 1168 No significant changes. 1170 B.8. Since draft-ietf-quic-recovery-02 1172 o Integrate F-RTO (#544, #409) 1174 o Add congestion control (#545, #395) 1176 o Require connection abort if a skipped packet was acknowledged 1177 (#415) 1179 o Simplify RTO calculations (#142, #417) 1181 B.9. Since draft-ietf-quic-recovery-01 1183 o Overview added to loss detection 1185 o Changes initial default RTT to 100ms 1187 o Added time-based loss detection and fixes early retransmit 1188 o Clarified loss recovery for handshake packets 1190 o Fixed references and made TCP references informative 1192 B.10. Since draft-ietf-quic-recovery-00 1194 o Improved description of constants and ACK behavior 1196 B.11. Since draft-iyengar-quic-loss-recovery-01 1198 o Adopted as base for draft-ietf-quic-recovery 1200 o Updated authors/editors list 1202 o Added table of contents 1204 Authors' Addresses 1206 Jana Iyengar (editor) 1207 Fastly 1209 Email: jri.ietf@gmail.com 1211 Ian Swett (editor) 1212 Google 1214 Email: ianswett@google.com