idnits 2.17.1 draft-ietf-quic-recovery-09.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 (January 28, 2018) is 2279 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 1116 -- Looks like a reference, but probably isn't: '2' on line 1118 -- Looks like a reference, but probably isn't: '3' on line 1120 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-09 ** 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 I. Swett, Ed. 4 Intended status: Standards Track Google 5 Expires: August 1, 2018 January 28, 2018 7 QUIC Loss Detection and Congestion Control 8 draft-ietf-quic-recovery-09 10 Abstract 12 This document describes loss detection and congestion control 13 mechanisms for QUIC. 15 Note to Readers 17 Discussion of this draft takes place on the QUIC working group 18 mailing list (quic@ietf.org), which is archived at 19 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 21 Working Group information can be found at https://github.com/quicwg 22 [2]; source code and issues list for this draft can be found at 23 https://github.com/quicwg/base-drafts/labels/-recovery [3]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 1, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 61 2. Design of the QUIC Transmission Machinery . . . . . . . . . . 4 62 2.1. Relevant Differences Between QUIC and TCP . . . . . . . . 4 63 2.1.1. Monotonically Increasing Packet Numbers . . . . . . . 4 64 2.1.2. No Reneging . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.3. More ACK Ranges . . . . . . . . . . . . . . . . . . . 5 66 2.1.4. Explicit Correction For Delayed Acks . . . . . . . . 5 67 3. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Computing the RTT estimate . . . . . . . . . . . . . . . 6 69 3.2. Ack-based Detection . . . . . . . . . . . . . . . . . . . 6 70 3.2.1. Fast Retransmit . . . . . . . . . . . . . . . . . . . 6 71 3.2.2. Early Retransmit . . . . . . . . . . . . . . . . . . 7 72 3.3. Timer-based Detection . . . . . . . . . . . . . . . . . . 8 73 3.3.1. Tail Loss Probe . . . . . . . . . . . . . . . . . . . 8 74 3.3.2. Retransmission Timeout . . . . . . . . . . . . . . . 9 75 3.3.3. Handshake Timeout . . . . . . . . . . . . . . . . . . 10 76 3.4. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.4.1. Constants of interest . . . . . . . . . . . . . . . . 11 78 3.4.2. Variables of interest . . . . . . . . . . . . . . . . 12 79 3.4.3. Initialization . . . . . . . . . . . . . . . . . . . 13 80 3.4.4. On Sending a Packet . . . . . . . . . . . . . . . . . 13 81 3.4.5. On Ack Receipt . . . . . . . . . . . . . . . . . . . 14 82 3.4.6. On Packet Acknowledgment . . . . . . . . . . . . . . 15 83 3.4.7. Setting the Loss Detection Alarm . . . . . . . . . . 16 84 3.4.8. On Alarm Firing . . . . . . . . . . . . . . . . . . . 17 85 3.4.9. Detecting Lost Packets . . . . . . . . . . . . . . . 18 86 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 19 87 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 19 88 4.1. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 20 89 4.2. Congestion Avoidance . . . . . . . . . . . . . . . . . . 20 90 4.3. Recovery Period . . . . . . . . . . . . . . . . . . . . . 20 91 4.4. Tail Loss Probe . . . . . . . . . . . . . . . . . . . . . 20 92 4.5. Retransmission Timeout . . . . . . . . . . . . . . . . . 20 93 4.6. Pacing . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 4.7. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 21 95 4.7.1. Constants of interest . . . . . . . . . . . . . . . . 21 96 4.7.2. Variables of interest . . . . . . . . . . . . . . . . 21 97 4.7.3. Initialization . . . . . . . . . . . . . . . . . . . 22 98 4.7.4. On Packet Sent . . . . . . . . . . . . . . . . . . . 22 99 4.7.5. On Packet Acknowledgement . . . . . . . . . . . . . . 22 100 4.7.6. On Packets Lost . . . . . . . . . . . . . . . . . . . 23 101 4.7.7. On Retransmission Timeout Verified . . . . . . . . . 23 102 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 103 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 6.1. Normative References . . . . . . . . . . . . . . . . . . 23 105 6.2. Informative References . . . . . . . . . . . . . . . . . 24 106 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 107 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25 108 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 109 B.1. Since draft-ietf-quic-recovery-08 . . . . . . . . . . . . 25 110 B.2. Since draft-ietf-quic-recovery-07 . . . . . . . . . . . . 25 111 B.3. Since draft-ietf-quic-recovery-06 . . . . . . . . . . . . 25 112 B.4. Since draft-ietf-quic-recovery-05 . . . . . . . . . . . . 25 113 B.5. Since draft-ietf-quic-recovery-04 . . . . . . . . . . . . 25 114 B.6. Since draft-ietf-quic-recovery-03 . . . . . . . . . . . . 26 115 B.7. Since draft-ietf-quic-recovery-02 . . . . . . . . . . . . 26 116 B.8. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 26 117 B.9. Since draft-ietf-quic-recovery-00 . . . . . . . . . . . . 26 118 B.10. Since draft-iyengar-quic-loss-recovery-01 . . . . . . . . 26 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 121 1. Introduction 123 QUIC is a new multiplexed and secure transport atop UDP. QUIC builds 124 on decades of transport and security experience, and implements 125 mechanisms that make it attractive as a modern general-purpose 126 transport. The QUIC protocol is described in [QUIC-TRANSPORT]. 128 QUIC implements the spirit of known TCP loss recovery mechanisms, 129 described in RFCs, various Internet-drafts, and also those prevalent 130 in the Linux TCP implementation. This document describes QUIC 131 congestion control and loss recovery, and where applicable, 132 attributes the TCP equivalent in RFCs, Internet-drafts, academic 133 papers, and/or TCP implementations. 135 1.1. Notational Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2. Design of the QUIC Transmission Machinery 145 All transmissions in QUIC are sent with a packet-level header, which 146 includes a packet sequence number (referred to below as a packet 147 number). These packet numbers never repeat in the lifetime of a 148 connection, and are monotonically increasing, which prevents 149 ambiguity. This fundamental design decision obviates the need for 150 disambiguating between transmissions and retransmissions and 151 eliminates significant complexity from QUIC's interpretation of TCP 152 loss detection mechanisms. 154 Every packet may contain several frames. We outline the frames that 155 are important to the loss detection and congestion control machinery 156 below. 158 o Retransmittable frames are frames requiring reliable delivery. 159 The most common are STREAM frames, which typically contain 160 application data. 162 o Crypto handshake data is sent on stream 0, and uses the 163 reliability machinery of QUIC underneath. 165 o ACK frames contain acknowledgment information. ACK frames contain 166 one or more ranges of acknowledged packets. 168 2.1. Relevant Differences Between QUIC and TCP 170 Readers familiar with TCP's loss detection and congestion control 171 will find algorithms here that parallel well-known TCP ones. 172 Protocol differences between QUIC and TCP however contribute to 173 algorithmic differences. We briefly describe these protocol 174 differences below. 176 2.1.1. Monotonically Increasing Packet Numbers 178 TCP conflates transmission sequence number at the sender with 179 delivery sequence number at the receiver, which results in 180 retransmissions of the same data carrying the same sequence number, 181 and consequently to problems caused by "retransmission ambiguity". 182 QUIC separates the two: QUIC uses a packet number for transmissions, 183 and any data that is to be delivered to the receiving application(s) 184 is sent in one or more streams, with delivery order determined by 185 stream offsets encoded within STREAM frames. 187 QUIC's packet number is strictly increasing, and directly encodes 188 transmission order. A higher QUIC packet number signifies that the 189 packet was sent later, and a lower QUIC packet number signifies that 190 the packet was sent earlier. When a packet containing frames is 191 deemed lost, QUIC rebundles necessary frames in a new packet with a 192 new packet number, removing ambiguity about which packet is 193 acknowledged when an ACK is received. Consequently, more accurate 194 RTT measurements can be made, spurious retransmissions are trivially 195 detected, and mechanisms such as Fast Retransmit can be applied 196 universally, based only on packet number. 198 This design point significantly simplifies loss detection mechanisms 199 for QUIC. Most TCP mechanisms implicitly attempt to infer 200 transmission ordering based on TCP sequence numbers - a non-trivial 201 task, especially when TCP timestamps are not available. 203 2.1.2. No Reneging 205 QUIC ACKs contain information that is similar to TCP SACK, but QUIC 206 does not allow any acked packet to be reneged, greatly simplifying 207 implementations on both sides and reducing memory pressure on the 208 sender. 210 2.1.3. More ACK Ranges 212 QUIC supports many ACK ranges, opposed to TCP's 3 SACK ranges. In 213 high loss environments, this speeds recovery, reduces spurious 214 retransmits, and ensures forward progress without relying on 215 timeouts. 217 2.1.4. Explicit Correction For Delayed Acks 219 QUIC ACKs explicitly encode the delay incurred at the receiver 220 between when a packet is received and when the corresponding ACK is 221 sent. This allows the receiver of the ACK to adjust for receiver 222 delays, specifically the delayed ack timer, when estimating the path 223 RTT. This mechanism also allows a receiver to measure and report the 224 delay from when a packet was received by the OS kernel, which is 225 useful in receivers which may incur delays such as context-switch 226 latency before a userspace QUIC receiver processes a received packet. 228 3. Loss Detection 230 QUIC senders use both ack information and timeouts to detect lost 231 packets, and this section provides a description of these algorithms. 232 Estimating the network round-trip time (RTT) is critical to these 233 algorithms and is described first. 235 3.1. Computing the RTT estimate 237 RTT is calculated when an ACK frame arrives by computing the 238 difference between the current time and the time the largest newly 239 acked packet was sent. If no packets are newly acknowledged, RTT 240 cannot be calculated. When RTT is calculated, the ack delay field 241 from the ACK frame SHOULD be subtracted from the RTT as long as the 242 result is larger than the Min RTT. If the result is smaller than the 243 min_rtt, the RTT should be used, but the ack delay field should be 244 ignored. 246 Like TCP, QUIC calculates both smoothed RTT and RTT variance as 247 specified in [RFC6298]. 249 Min RTT is the minimum RTT measured over the connection, prior to 250 adjusting by ack delay. Ignoring ack delay for min RTT prevents 251 intentional or unintentional underestimation of min RTT, which in 252 turn prevents underestimating smoothed RTT. 254 3.2. Ack-based Detection 256 Ack-based loss detection implements the spirit of TCP's Fast 257 Retransmit [RFC5681], Early Retransmit [RFC5827], FACK, and SACK loss 258 recovery [RFC6675]. This section provides an overview of how these 259 algorithms are implemented in QUIC. 261 (TODO: Define unacknowledged packet, ackable packet, outstanding 262 bytes.) 264 3.2.1. Fast Retransmit 266 An unacknowledged packet is marked as lost when an acknowledgment is 267 received for a packet that was sent a threshold number of packets 268 (kReorderingThreshold) after the unacknowledged packet. Receipt of 269 the ack indicates that a later packet was received, while 270 kReorderingThreshold provides some tolerance for reordering of 271 packets in the network. 273 The RECOMMENDED initial value for kReorderingThreshold is 3. 275 We derive this default from recommendations for TCP loss recovery 276 [RFC5681] [RFC6675]. It is possible for networks to exhibit higher 277 degrees of reordering, causing a sender to detect spurious losses. 278 Detecting spurious losses leads to unnecessary retransmissions and 279 may result in degraded performance due to the actions of the 280 congestion controller upon detecting loss. Implementers MAY use 281 algorithms developed for TCP, such as TCP-NCR [RFC4653], to improve 282 QUIC's reordering resilience, though care should be taken to map TCP 283 specifics to QUIC correctly. Similarly, using time-based loss 284 detection to deal with reordering, such as in PR-TCP, should be more 285 readily usable in QUIC. Making QUIC deal with such networks is 286 important open research, and implementers are encouraged to explore 287 this space. 289 3.2.2. Early Retransmit 291 Unacknowledged packets close to the tail may have fewer than 292 kReorderingThreshold number of ackable packets sent after them. Loss 293 of such packets cannot be detected via Fast Retransmit. To enable 294 ack-based loss detection of such packets, receipt of an 295 acknowledgment for the last outstanding ackable packet triggers the 296 Early Retransmit process, as follows. 298 If there are unacknowledged ackable packets still pending, they ought 299 to be marked as lost. To compensate for the reduced reordering 300 resilience, the sender SHOULD set an alarm for a small period of 301 time. If the unacknowledged ackable packets are not acknowledged 302 during this time, then these packets MUST be marked as lost. 304 An endpoint SHOULD set the alarm such that a packet is marked as lost 305 no earlier than 1.25 * max(SRTT, latest_RTT) since when it was sent. 307 Using max(SRTT, latest_RTT) protects from the two following cases: 309 o the latest RTT sample is lower than the SRTT, perhaps due to 310 reordering where packet whose ack triggered the Early Retransit 311 process encountered a shorter path; 313 o the latest RTT sample is higher than the SRTT, perhaps due to a 314 sustained increase in the actual RTT, but the smoothed SRTT has 315 not yet caught up. 317 The 1.25 multiplier increases reordering resilience. Implementers 318 MAY experiment with using other multipliers, bearing in mind that a 319 lower multiplier reduces reordering resilience and increases spurious 320 retransmissions, and a higher multipler increases loss recovery 321 delay. 323 This mechanism is based on Early Retransmit for TCP [RFC5827]. 324 However, [RFC5827] does not include the alarm described above. Early 325 Retransmit is prone to spurious retransmissions due to its reduced 326 reordering resilence without the alarm. This observation led Linux 327 TCP implementers to implement an alarm for TCP as well, and this 328 document incorporates this advancement. 330 3.3. Timer-based Detection 332 Timer-based loss detection implements the spirit of TCP's Tail Loss 333 Probe and Retransmission Timeout mechanisms. 335 3.3.1. Tail Loss Probe 337 The algorithm described in this section is an adaptation of the Tail 338 Loss Probe algorithm proposed for TCP [TLP]. 340 A packet sent at the tail is particularly vulnerable to slow loss 341 detection, since acks of subsequent packets are needed to trigger 342 ack-based detection. To ameliorate this weakness of tail packets, 343 the sender schedules an alarm when the last ackable packet before 344 quiescence is transmitted. When this alarm fires, a Tail Loss Probe 345 (TLP) packet is sent to evoke an acknowledgement from the receiver. 347 The alarm duration, or Probe Timeout (PTO), is set based on the 348 following conditions: 350 o PTO SHOULD be scheduled for max(1.5*SRTT+MaxAckDelay, 10ms) 352 o If RTO (Section 3.3.2) is earlier, schedule a TLP alarm in its 353 place. That is, PTO SHOULD be scheduled for min(RTO, PTO). 355 MaxAckDelay is the maximum ack delay supplied in an incoming ACK 356 frame. MaxAckDelay excludes ack delays that aren't included in an 357 RTT sample because they're too large and excludes those which 358 reference an ack-only packet. 360 QUIC diverges from TCP by calculating MaxAckDelay dynamically, 361 instead of assuming a constant delayed ack timeout for all 362 connections. QUIC includes this in all probe timeouts, because it 363 assume the ack delay may come into play, regardless of the number of 364 packets outstanding. TCP's TLP assumes if at least 2 packets are 365 outstanding, acks will not be delayed. 367 A PTO value of at least 1.5*SRTT ensures that the ACK is overdue. 368 The 1.5 is based on [LOSS-PROBE], but implementations MAY experiment 369 with other constants. 371 To reduce latency, it is RECOMMENDED that the sender set and allow 372 the TLP alarm to fire twice before setting an RTO alarm. In other 373 words, when the TLP alarm fires the first time, a TLP packet is sent, 374 and it is RECOMMENDED that the TLP alarm be scheduled for a second 375 time. When the TLP alarm fires the second time, a second TLP packet 376 is sent, and an RTO alarm SHOULD be scheduled Section 3.3.2. 378 A TLP packet SHOULD carry new data when possible. If new data is 379 unavailable or new data cannot be sent due to flow control, a TLP 380 packet MAY retransmit unacknowledged data to potentially reduce 381 recovery time. Since a TLP alarm is used to send a probe into the 382 network prior to establishing any packet loss, prior unacknowledged 383 packets SHOULD NOT be marked as lost when a TLP alarm fires. 385 A TLP packet MUST NOT be blocked by the sender's congestion 386 controller. The sender MUST however count these bytes as additional 387 bytes in flight, since a TLP adds network load without establishing 388 packet loss. 390 A sender may not know that a packet being sent is a tail packet. 391 Consequently, a sender may have to arm or adjust the TLP alarm on 392 every sent ackable packet. 394 3.3.2. Retransmission Timeout 396 A Retransmission Timeout (RTO) alarm is the final backstop for loss 397 detection. The algorithm used in QUIC is based on the RTO algorithm 398 for TCP [RFC5681] and is additionally resilient to spurious RTO 399 events [RFC5682]. 401 When the last TLP packet is sent, an alarm is scheduled for the RTO 402 period. When this alarm fires, the sender sends two packets, to 403 evoke acknowledgements from the receiver, and restarts the RTO alarm. 405 Similar to TCP [RFC6298], the RTO period is set based on the 406 following conditions: 408 o When the final TLP packet is sent, the RTO period is set to 409 max(SRTT + 4*RTTVAR + MaxAckDelay, minRTO) 411 o When an RTO alarm fires, the RTO period is doubled. 413 The sender typically has incurred a high latency penalty by the time 414 an RTO alarm fires, and this penalty increases exponentially in 415 subsequent consecutive RTO events. Sending a single packet on an RTO 416 event therefore makes the connection very sensitive to single packet 417 loss. Sending two packets instead of one significantly increases 418 resilience to packet drop in both directions, thus reducing the 419 probability of consecutive RTO events. 421 QUIC's RTO algorithm differs from TCP in that the firing of an RTO 422 alarm is not considered a strong enough signal of packet loss, so 423 does not result in an immediate change to congestion window or 424 recovery state. An RTO alarm fires only when there's a prolonged 425 period of network silence, which could be caused by a change in the 426 underlying network RTT. 428 QUIC also diverges from TCP by including MaxAckDelay in the RTO 429 period. QUIC is able to explicitly model delay at the receiver via 430 the ack delay field in the ACK frame. Since QUIC corrects for this 431 delay in its SRTT and RTTVAR computations, it is necessary to add 432 this delay explicitly in the TLP and RTO computation. 434 When an acknowledgment is received for a packet sent on an RTO event, 435 any unacknowledged packets with lower packet numbers than those 436 acknowledged MUST be marked as lost. 438 A packet sent when an RTO alarm fires MAY carry new data if available 439 or unacknowledged data to potentially reduce recovery time. Since 440 this packet is sent as a probe into the network prior to establishing 441 any packet loss, prior unacknowledged packets SHOULD NOT be marked as 442 lost. 444 A packet sent on an RTO alarm MUST NOT be blocked by the sender's 445 congestion controller. A sender MUST however count these bytes as 446 additional bytes in flight, since this packet adds network load 447 without establishing packet loss. 449 3.3.3. Handshake Timeout 451 Handshake packets, which contain STREAM frames for stream 0, are 452 critical to QUIC transport and crypto negotiation, so a separate 453 alarm is used for them. 455 The initial handshake timeout SHOULD be set to twice the initial RTT. 457 At the beginning, there are no prior RTT samples within a connection. 458 Resumed connections over the same network SHOULD use the previous 459 connection's final smoothed RTT value as the resumed connection's 460 initial RTT. 462 If no previous RTT is available, or if the network changes, the 463 initial RTT SHOULD be set to 100ms. 465 When the first handshake packet is sent, the sender SHOULD set an 466 alarm for the handshake timeout period. 468 When the alarm fires, the sender MUST retransmit all unacknowledged 469 handshake data. On each consecutive firing of the handshake alarm, 470 the sender SHOULD double the handshake timeout and set an alarm for 471 this period. 473 When an acknowledgement is received for a handshake packet, the new 474 RTT is computed and the alarm SHOULD be set for twice the newly 475 computed smoothed RTT. 477 Handshake data may be cancelled by handshake state transitions. In 478 particular, all non-protected data SHOULD no longer be transmitted 479 once packet protection is available. 481 (TODO: Work this section some more. Add text on client vs. server, 482 and on stateless retry.) 484 3.4. Pseudocode 486 3.4.1. Constants of interest 488 Constants used in loss recovery are based on a combination of RFCs, 489 papers, and common practice. Some may need to be changed or 490 negotiated in order to better suit a variety of environments. 492 kMaxTLPs (default 2): Maximum number of tail loss probes before an 493 RTO fires. 495 kReorderingThreshold (default 3): Maximum reordering in packet 496 number space before FACK style loss detection considers a packet 497 lost. 499 kTimeReorderingFraction (default 1/8): Maximum reordering in time 500 space before time based loss detection considers a packet lost. 501 In fraction of an RTT. 503 kUsingTimeLossDetection (default false): Whether time based loss 504 detection is in use. If false, uses FACK style loss detection. 506 kMinTLPTimeout (default 10ms): Minimum time in the future a tail 507 loss probe alarm may be set for. 509 kMinRTOTimeout (default 200ms): Minimum time in the future an RTO 510 alarm may be set for. 512 kDelayedAckTimeout (default 25ms): The length of the peer's delayed 513 ack timer. 515 kDefaultInitialRtt (default 100ms): The default RTT used before an 516 RTT sample is taken. 518 3.4.2. Variables of interest 520 Variables required to implement the congestion control mechanisms are 521 described in this section. 523 loss_detection_alarm: Multi-modal alarm used for loss detection. 525 handshake_count: The number of times the handshake packets have been 526 retransmitted without receiving an ack. 528 tlp_count: The number of times a tail loss probe has been sent 529 without receiving an ack. 531 rto_count: The number of times an rto has been sent without 532 receiving an ack. 534 largest_sent_before_rto: The last packet number sent prior to the 535 first retransmission timeout. 537 time_of_last_sent_packet: The time the most recent packet was sent. 539 largest_sent_packet: The packet number of the most recently sent 540 packet. 542 largest_acked_packet: The largest packet number acknowledged in an 543 ACK frame. 545 latest_rtt: The most recent RTT measurement made when receiving an 546 ack for a previously unacked packet. 548 smoothed_rtt: The smoothed RTT of the connection, computed as 549 described in [RFC6298] 551 rttvar: The RTT variance, computed as described in [RFC6298] 553 min_rtt: The minimum RTT seen in the connection, ignoring ack delay. 555 max_ack_delay: The maximum ack delay in an incoming ACK frame for 556 this connection. Excludes ack delays for ack only packets and 557 those that create an RTT sample less than min_rtt. 559 reordering_threshold: The largest delta between the largest acked 560 retransmittable packet and a packet containing retransmittable 561 frames before it's declared lost. 563 time_reordering_fraction: The reordering window as a fraction of 564 max(smoothed_rtt, latest_rtt). 566 loss_time: The time at which the next packet will be considered lost 567 based on early transmit or exceeding the reordering window in 568 time. 570 sent_packets: An association of packet numbers to information about 571 them, including a number field indicating the packet number, a 572 time field indicating the time a packet was sent, a boolean 573 indicating whether the packet is ack only, and a bytes field 574 indicating the packet's size. sent_packets is ordered by packet 575 number, and packets remain in sent_packets until acknowledged or 576 lost. 578 3.4.3. Initialization 580 At the beginning of the connection, initialize the loss detection 581 variables as follows: 583 loss_detection_alarm.reset() 584 handshake_count = 0 585 tlp_count = 0 586 rto_count = 0 587 if (kUsingTimeLossDetection) 588 reordering_threshold = infinite 589 time_reordering_fraction = kTimeReorderingFraction 590 else: 591 reordering_threshold = kReorderingThreshold 592 time_reordering_fraction = infinite 593 loss_time = 0 594 smoothed_rtt = 0 595 rttvar = 0 596 min_rtt = 0 597 max_ack_delay = 0 598 largest_sent_before_rto = 0 599 time_of_last_sent_packet = 0 600 largest_sent_packet = 0 602 3.4.4. On Sending a Packet 604 After any packet is sent, be it a new transmission or a rebundled 605 transmission, the following OnPacketSent function is called. The 606 parameters to OnPacketSent are as follows: 608 o packet_number: The packet number of the sent packet. 610 o is_ack_only: A boolean that indicates whether a packet only 611 contains an ACK frame. If true, it is still expected an ack will 612 be received for this packet, but it is not congestion controlled. 614 o sent_bytes: The number of bytes sent in the packet, not including 615 UDP or IP overhead, but including QUIC framing overhead. 617 Pseudocode for OnPacketSent follows: 619 OnPacketSent(packet_number, is_ack_only, sent_bytes): 620 time_of_last_sent_packet = now 621 largest_sent_packet = packet_number 622 sent_packets[packet_number].packet_number = packet_number 623 sent_packets[packet_number].time = now 624 sent_packets[packet_number].ack_only = is_ack_only 625 if !is_ack_only: 626 OnPacketSentCC(sent_bytes) 627 sent_packets[packet_number].bytes = sent_bytes 628 SetLossDetectionAlarm() 630 3.4.5. On Ack Receipt 632 When an ack is received, it may acknowledge 0 or more packets. 634 Pseudocode for OnAckReceived and UpdateRtt follow: 636 OnAckReceived(ack): 637 largest_acked_packet = ack.largest_acked 638 // If the largest acked is newly acked, update the RTT. 639 if (sent_packets[ack.largest_acked]): 640 latest_rtt = now - sent_packets[ack.largest_acked].time 641 UpdateRtt(latest_rtt, ack.ack_delay) 642 // Find all newly acked packets. 643 for acked_packet in DetermineNewlyAckedPackets(): 644 OnPacketAcked(acked_packet.packet_number) 646 DetectLostPackets(ack.largest_acked_packet) 647 SetLossDetectionAlarm() 649 UpdateRtt(latest_rtt, ack_delay): 650 // min_rtt ignores ack delay. 651 min_rtt = min(min_rtt, latest_rtt) 652 // Adjust for ack delay if it's plausible. 653 if (latest_rtt - min_rtt > ack_delay): 654 latest_rtt -= ack_delay 655 // Only save into max ack delay if it's used 656 // for rtt calculation and is not ack only. 657 if (!sent_packets[ack.largest_acked].ack_only) 658 max_ack_delay = max(max_ack_delay, ack_delay) 659 // Based on {{RFC6298}}. 660 if (smoothed_rtt == 0): 661 smoothed_rtt = latest_rtt 662 rttvar = latest_rtt / 2 663 else: 664 rttvar_sample = abs(smoothed_rtt - latest_rtt) 665 rttvar = 3/4 * rttvar + 1/4 * rttvar_sample 666 smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * latest_rtt 668 3.4.6. On Packet Acknowledgment 670 When a packet is acked for the first time, the following 671 OnPacketAcked function is called. Note that a single ACK frame may 672 newly acknowledge several packets. OnPacketAcked must be called once 673 for each of these newly acked packets. 675 OnPacketAcked takes one parameter, acked_packet_number, which is the 676 packet number of the newly acked packet, and returns a list of packet 677 numbers that are detected as lost. 679 If this is the first acknowledgement following RTO, check if the 680 smallest newly acknowledged packet is one sent by the RTO, and if so, 681 inform congestion control of a verified RTO, similar to F-RTO 682 [RFC5682] 683 Pseudocode for OnPacketAcked follows: 685 OnPacketAcked(acked_packet_number): 686 OnPacketAckedCC(acked_packet_number) 687 // If a packet sent prior to RTO was acked, then the RTO 688 // was spurious. Otherwise, inform congestion control. 689 if (rto_count > 0 && 690 acked_packet_number > largest_sent_before_rto) 691 OnRetransmissionTimeoutVerified() 692 handshake_count = 0 693 tlp_count = 0 694 rto_count = 0 695 sent_packets.remove(acked_packet_number) 697 3.4.7. Setting the Loss Detection Alarm 699 QUIC loss detection uses a single alarm for all timer-based loss 700 detection. The duration of the alarm is based on the alarm's mode, 701 which is set in the packet and timer events further below. The 702 function SetLossDetectionAlarm defined below shows how the single 703 timer is set based on the alarm mode. 705 3.4.7.1. Handshake Alarm 707 When a connection has unacknowledged handshake data, the handshake 708 alarm is set and when it expires, all unacknowledgedd handshake data 709 is retransmitted. 711 When stateless rejects are in use, the connection is considered 712 immediately closed once a reject is sent, so no timer is set to 713 retransmit the reject. 715 Version negotiation packets are always stateless, and MUST be sent 716 once per handshake packet that uses an unsupported QUIC version, and 717 MAY be sent in response to 0RTT packets. 719 3.4.7.2. Tail Loss Probe and Retransmission Alarm 721 Tail loss probes [LOSS-PROBE] and retransmission timeouts [RFC6298] 722 are an alarm based mechanism to recover from cases when there are 723 outstanding retransmittable packets, but an acknowledgement has not 724 been received in a timely manner. 726 The TLP and RTO timers are armed when there is not unacknowledged 727 handshake data. The TLP alarm is set until the max number of TLP 728 packets have been sent, and then the RTO timer is set. 730 3.4.7.3. Early Retransmit Alarm 732 Early retransmit [RFC5827] is implemented with a 1/4 RTT timer. It 733 is part of QUIC's time based loss detection, but is always enabled, 734 even when only packet reordering loss detection is enabled. 736 3.4.7.4. Pseudocode 738 Pseudocode for SetLossDetectionAlarm follows: 740 SetLossDetectionAlarm(): 741 // Don't arm the alarm if there are no packets with 742 // retransmittable data in flight. 743 if (num_retransmittable_packets_outstanding == 0): 744 loss_detection_alarm.cancel() 745 return 747 if (handshake packets are outstanding): 748 // Handshake retransmission alarm. 749 if (smoothed_rtt == 0): 750 alarm_duration = 2 * kDefaultInitialRtt 751 else: 752 alarm_duration = 2 * smoothed_rtt 753 alarm_duration = max(alarm_duration, kMinTLPTimeout) 754 alarm_duration = alarm_duration * (2 ^ handshake_count) 755 else if (loss_time != 0): 756 // Early retransmit timer or time loss detection. 757 alarm_duration = loss_time - time_of_last_sent_packet 758 else if (tlp_count < kMaxTLPs): 759 // Tail Loss Probe 760 alarm_duration = max(1.5 * smoothed_rtt + max_ack_delay, 761 kMinTLPTimeout) 762 else: 763 // RTO alarm 764 alarm_duration = smoothed_rtt + 4 * rttvar 765 alarm_duration = max(alarm_duration, kMinRTOTimeout) 766 alarm_duration = alarm_duration * (2 ^ rto_count) 768 loss_detection_alarm.set(time_of_last_sent_packet 769 + alarm_duration) 771 3.4.8. On Alarm Firing 773 QUIC uses one loss recovery alarm, which when set, can be in one of 774 several modes. When the alarm fires, the mode determines the action 775 to be performed. 777 Pseudocode for OnLossDetectionAlarm follows: 779 OnLossDetectionAlarm(): 780 if (handshake packets are outstanding): 781 // Handshake retransmission alarm. 782 RetransmitAllHandshakePackets() 783 handshake_count++ 784 else if (loss_time != 0): 785 // Early retransmit or Time Loss Detection 786 DetectLostPackets(largest_acked_packet) 787 else if (tlp_count < kMaxTLPs): 788 // Tail Loss Probe. 789 SendOnePacket() 790 tlp_count++ 791 else: 792 // RTO. 793 if (rto_count == 0) 794 largest_sent_before_rto = largest_sent_packet 795 SendTwoPackets() 796 rto_count++ 798 SetLossDetectionAlarm() 800 3.4.9. Detecting Lost Packets 802 Packets in QUIC are only considered lost once a larger packet number 803 is acknowledged. DetectLostPackets is called every time an ack is 804 received. If the loss detection alarm fires and the loss_time is 805 set, the previous largest acked packet is supplied. 807 3.4.9.1. Handshake Packets 809 The receiver MUST close the connection with an error of type 810 OPTIMISTIC_ACK when receiving an unprotected packet that acks 811 protected packets. The receiver MUST trust protected acks for 812 unprotected packets, however. Aside from this, loss detection for 813 handshake packets when an ack is processed is identical to other 814 packets. 816 3.4.9.2. Pseudocode 818 DetectLostPackets takes one parameter, acked, which is the largest 819 acked packet. 821 Pseudocode for DetectLostPackets follows: 823 DetectLostPackets(largest_acked): 824 loss_time = 0 825 lost_packets = {} 826 delay_until_lost = infinite 827 if (kUsingTimeLossDetection): 828 delay_until_lost = 829 (1 + time_reordering_fraction) * 830 max(latest_rtt, smoothed_rtt) 831 else if (largest_acked.packet_number == largest_sent_packet): 832 // Early retransmit alarm. 833 delay_until_lost = 5/4 * max(latest_rtt, smoothed_rtt) 834 foreach (unacked < largest_acked.packet_number): 835 time_since_sent = now() - unacked.time_sent 836 delta = largest_acked.packet_number - unacked.packet_number 837 if (time_since_sent > delay_until_lost): 838 lost_packets.insert(unacked) 839 else if (delta > reordering_threshold) 840 lost_packets.insert(unacked) 841 else if (loss_time == 0 && delay_until_lost != infinite): 842 loss_time = now() + delay_until_lost - time_since_sent 844 // Inform the congestion controller of lost packets and 845 // lets it decide whether to retransmit immediately. 846 if (!lost_packets.empty()) 847 OnPacketsLost(lost_packets) 848 foreach (packet in lost_packets) 849 sent_packets.remove(packet.packet_number) 851 3.5. Discussion 853 The majority of constants were derived from best common practices 854 among widely deployed TCP implementations on the internet. 855 Exceptions follow. 857 A shorter delayed ack time of 25ms was chosen because longer delayed 858 acks can delay loss recovery and for the small number of connections 859 where less than packet per 25ms is delivered, acking every packet is 860 beneficial to congestion control and loss recovery. 862 The default initial RTT of 100ms was chosen because it is slightly 863 higher than both the median and mean min_rtt typically observed on 864 the public internet. 866 4. Congestion Control 868 QUIC's congestion control is based on TCP NewReno [RFC6582] 869 congestion control to determine the congestion window. QUIC 870 congestion control is specified in bytes due to finer control and the 871 ease of appropriate byte counting [RFC3465]. 873 4.1. Slow Start 875 QUIC begins every connection in slow start and exits slow start upon 876 loss. QUIC re-enters slow start anytime the congestion window is 877 less than sshthresh, which typically only occurs after an RTO. While 878 in slow start, QUIC increases the congestion window by the number of 879 acknowledged bytes when each ack is processed. 881 4.2. Congestion Avoidance 883 Slow start exits to congestion avoidance. Congestion avoidance in 884 NewReno uses an additive increase multiplicative decrease (AIMD) 885 approach that increases the congestion window by one MSS of bytes per 886 congestion window acknowledged. When a loss is detected, NewReno 887 halves the congestion window and sets the slow start threshold to the 888 new congestion window. 890 4.3. Recovery Period 892 Recovery is a period of time beginning with detection of a lost 893 packet. Because QUIC retransmits stream data and control frames, not 894 packets, it defines the end of recovery as a packet sent after the 895 start of recovery being acknowledged. This is slightly different 896 from TCP's definition of recovery ending when the lost packet that 897 started recovery is acknowledged. 899 During recovery, the congestion window is not increased or decreased. 900 As such, multiple lost packets only decrease the congestion window 901 once as long as they're lost before exiting recovery. This causes 902 QUIC to decrease the congestion window multiple times if 903 retransmisions are lost, but limits the reduction to once per round 904 trip. 906 4.4. Tail Loss Probe 908 If recovery sends a tail loss probe, no change is made to the 909 congestion window. Acknowledgement or loss of tail loss probes are 910 treated like any other packet. 912 4.5. Retransmission Timeout 914 When retransmissions are sent due to a retransmission timeout alarm, 915 no change is made to the congestion window until the next 916 acknowledgement arrives. The retransmission timeout is considered 917 spurious when this acknowledgement acknowledges packets sent prior to 918 the first retransmission timeout. The retransmission timeout is 919 considered valid when this acknowledgement acknowledges no packets 920 sent prior to the first retransmission timeout. In this case, the 921 congestion window MUST be reduced to the minimum congestion window 922 and slow start is re-entered. 924 4.6. Pacing 926 It is RECOMMENDED that a sender pace sending of all data, 927 distributing the congestion window over the SRTT. This document does 928 not specify a pacer. As an example pacer, implementers are referred 929 to the Fair Queue packet scheduler (fq qdisc) in Linux (3.11 onwards) 930 as a well-known and publicly available implementation of a flow 931 pacer. 933 4.7. Pseudocode 935 4.7.1. Constants of interest 937 Constants used in congestion control are based on a combination of 938 RFCs, papers, and common practice. Some may need to be changed or 939 negotiated in order to better suit a variety of environments. 941 kDefaultMss (default 1460 bytes): The default max packet size used 942 for calculating default and minimum congestion windows. 944 kInitialWindow (default 10 * kDefaultMss): Default limit on the 945 amount of outstanding data in bytes. 947 kMinimumWindow (default 2 * kDefaultMss): Default minimum congestion 948 window. 950 kLossReductionFactor (default 0.5): Reduction in congestion window 951 when a new loss event is detected. 953 4.7.2. Variables of interest 955 Variables required to implement the congestion control mechanisms are 956 described in this section. 958 bytes_in_flight: The sum of the size in bytes of all sent packets 959 that contain at least one retransmittable or PADDING frame, and 960 have not been acked or declared lost. The size does not include 961 IP or UDP overhead. Packets only containing ACK frames do not 962 count towards byte_in_flight to ensure congestion control does not 963 impede congestion feedback. 965 congestion_window: Maximum number of bytes in flight that may be 966 sent. 968 end_of_recovery: The largest packet number sent when QUIC detects a 969 loss. When a larger packet is acknowledged, QUIC exits recovery. 971 ssthresh: Slow start threshold in bytes. When the congestion window 972 is below ssthresh, the mode is slow start and the window grows by 973 the number of bytes acknowledged. 975 4.7.3. Initialization 977 At the beginning of the connection, initialize the congestion control 978 variables as follows: 980 congestion_window = kInitialWindow 981 bytes_in_flight = 0 982 end_of_recovery = 0 983 ssthresh = infinite 985 4.7.4. On Packet Sent 987 Whenever a packet is sent, and it contains non-ACK frames, the packet 988 increases bytes_in_flight. 990 OnPacketSentCC(bytes_sent): 991 bytes_in_flight += bytes_sent 993 4.7.5. On Packet Acknowledgement 995 Invoked from loss detection's OnPacketAcked and is supplied with 996 acked_packet from sent_packets. 998 OnPacketAckedCC(acked_packet): 999 // Remove from bytes_in_flight. 1000 bytes_in_flight -= acked_packet.bytes 1001 if (acked_packet.packet_number < end_of_recovery): 1002 // Do not increase congestion window in recovery period. 1003 return 1004 if (congestion_window < ssthresh): 1005 // Slow start. 1006 congestion_window += acked_packet.bytes 1007 else: 1008 // Congestion avoidance. 1009 congestion_window += 1010 kDefaultMss * acked_packet.bytes / congestion_window 1012 4.7.6. On Packets Lost 1014 Invoked by loss detection from DetectLostPackets when new packets are 1015 detected lost. 1017 OnPacketsLost(lost_packets): 1018 // Remove lost packets from bytes_in_flight. 1019 for (lost_packet : lost_packets): 1020 bytes_in_flight -= lost_packet.bytes 1021 largest_lost_packet = lost_packets.last() 1022 // Start a new recovery epoch if the lost packet is larger 1023 // than the end of the previous recovery epoch. 1024 if (end_of_recovery < largest_lost_packet.packet_number): 1025 end_of_recovery = largest_sent_packet 1026 congestion_window *= kLossReductionFactor 1027 congestion_window = max(congestion_window, kMinimumWindow) 1028 ssthresh = congestion_window 1030 4.7.7. On Retransmission Timeout Verified 1032 QUIC decreases the congestion window to the minimum value once the 1033 retransmission timeout has been verified. 1035 OnRetransmissionTimeoutVerified() 1036 congestion_window = kMinimumWindow 1038 5. IANA Considerations 1040 This document has no IANA actions. Yet. 1042 6. References 1044 6.1. Normative References 1046 [QUIC-TRANSPORT] 1047 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1048 Multiplexed and Secure Transport", draft-ietf-quic- 1049 transport-09 (work in progress), January 2018. 1051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1052 Requirement Levels", BCP 14, RFC 2119, 1053 DOI 10.17487/RFC2119, March 1997, 1054 . 1056 [RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, 1057 "Improving the Robustness of TCP to Non-Congestion 1058 Events", RFC 4653, DOI 10.17487/RFC4653, August 2006, 1059 . 1061 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1062 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 1063 . 1065 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 1066 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 1067 Spurious Retransmission Timeouts with TCP", RFC 5682, 1068 DOI 10.17487/RFC5682, September 2009, 1069 . 1071 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 1072 P. Hurtig, "Early Retransmit for TCP and Stream Control 1073 Transmission Protocol (SCTP)", RFC 5827, 1074 DOI 10.17487/RFC5827, May 2010, 1075 . 1077 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1078 "Computing TCP's Retransmission Timer", RFC 6298, 1079 DOI 10.17487/RFC6298, June 2011, 1080 . 1082 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 1083 and Y. Nishida, "A Conservative Loss Recovery Algorithm 1084 Based on Selective Acknowledgment (SACK) for TCP", 1085 RFC 6675, DOI 10.17487/RFC6675, August 2012, 1086 . 1088 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1089 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1090 May 2017, . 1092 6.2. Informative References 1094 [LOSS-PROBE] 1095 Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1096 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1097 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1098 in progress), February 2013. 1100 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 1101 Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 1102 2003, . 1104 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 1105 NewReno Modification to TCP's Fast Recovery Algorithm", 1106 RFC 6582, DOI 10.17487/RFC6582, April 2012, 1107 . 1109 [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1110 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1111 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1112 in progress), February 2013. 1114 6.3. URIs 1116 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 1118 [2] https://github.com/quicwg 1120 [3] https://github.com/quicwg/base-drafts/labels/-recovery 1122 Appendix A. Acknowledgments 1124 Appendix B. Change Log 1126 *RFC Editor's Note:* Please remove this section prior to 1127 publication of a final version of this document. 1129 B.1. Since draft-ietf-quic-recovery-08 1131 o Clarified pacing and RTO (#967, #977) 1133 B.2. Since draft-ietf-quic-recovery-07 1135 o Include Ack Delay in RTO(and TLP) computations (#981) 1137 o Ack Delay in SRTT computation (#961) 1139 o Default RTT and Slow Start (#590) 1141 o Many editorial fixes. 1143 B.3. Since draft-ietf-quic-recovery-06 1145 No significant changes. 1147 B.4. Since draft-ietf-quic-recovery-05 1149 o Add more congestion control text (#776) 1151 B.5. Since draft-ietf-quic-recovery-04 1153 No significant changes. 1155 B.6. Since draft-ietf-quic-recovery-03 1157 No significant changes. 1159 B.7. Since draft-ietf-quic-recovery-02 1161 o Integrate F-RTO (#544, #409) 1163 o Add congestion control (#545, #395) 1165 o Require connection abort if a skipped packet was acknowledged 1166 (#415) 1168 o Simplify RTO calculations (#142, #417) 1170 B.8. Since draft-ietf-quic-recovery-01 1172 o Overview added to loss detection 1174 o Changes initial default RTT to 100ms 1176 o Added time-based loss detection and fixes early retransmit 1178 o Clarified loss recovery for handshake packets 1180 o Fixed references and made TCP references informative 1182 B.9. Since draft-ietf-quic-recovery-00 1184 o Improved description of constants and ACK behavior 1186 B.10. Since draft-iyengar-quic-loss-recovery-01 1188 o Adopted as base for draft-ietf-quic-recovery 1190 o Updated authors/editors list 1192 o Added table of contents 1194 Authors' Addresses 1196 Jana Iyengar (editor) 1197 Google 1199 Email: jri@google.com 1200 Ian Swett (editor) 1201 Google 1203 Email: ianswett@google.com