idnits 2.17.1 draft-ietf-quic-recovery-02.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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2017) is 2599 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC-TRANSPORT' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: September 14, 2017 March 13, 2017 7 QUIC Loss Detection and Congestion Control 8 draft-ietf-quic-recovery-02 10 Abstract 12 QUIC is a new multiplexed and secure transport atop UDP. QUIC builds 13 on decades of transport and security experience, and implements 14 mechanisms that make it attractive as a modern general-purpose 15 transport. QUIC implements the spirit of known TCP loss detection 16 mechanisms, described in RFCs, various Internet-drafts, and also 17 those prevalent in the Linux TCP implementation. This document 18 describes QUIC loss detection and congestion control, and attributes 19 the TCP equivalent in RFCs, Internet-drafts, academic papers, and TCP 20 implementations. 22 Note to Readers 24 Discussion of this draft takes place on the QUIC working group 25 mailing list (quic@ietf.org), which is archived at 26 https://mailarchive.ietf.org/arch/search/?email_list=quic . 28 Working Group information can be found at https://github.com/quicwg ; 29 source code and issues list for this draft can be found at 30 https://github.com/quicwg/base-drafts/labels/recovery . 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 14, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 68 2. Design of the QUIC Transmission Machinery . . . . . . . . . . 3 69 2.1. Relevant Differences Between QUIC and TCP . . . . . . . . 4 70 2.1.1. Monotonically Increasing Packet Numbers . . . . . . . 4 71 2.1.2. No Reneging . . . . . . . . . . . . . . . . . . . . . 4 72 2.1.3. More ACK Ranges . . . . . . . . . . . . . . . . . . . 5 73 2.1.4. Explicit Correction For Delayed Acks . . . . . . . . 5 74 3. Loss Detection . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Constants of interest . . . . . . . . . . . . . . . . . . 5 76 3.2. Variables of interest . . . . . . . . . . . . . . . . . . 6 77 3.3. Initialization . . . . . . . . . . . . . . . . . . . . . 7 78 3.4. On Sending a Packet . . . . . . . . . . . . . . . . . . . 7 79 3.5. On Ack Receipt . . . . . . . . . . . . . . . . . . . . . 8 80 3.6. On Packet Acknowledgment . . . . . . . . . . . . . . . . 8 81 3.7. Setting the Loss Detection Alarm . . . . . . . . . . . . 9 82 3.7.1. Handshake Packets . . . . . . . . . . . . . . . . . . 9 83 3.7.2. Tail Loss Probe and Retransmission Timeout . . . . . 9 84 3.7.3. Early Retransmit . . . . . . . . . . . . . . . . . . 9 85 3.7.4. Pseudocode . . . . . . . . . . . . . . . . . . . . . 10 86 3.8. On Alarm Firing . . . . . . . . . . . . . . . . . . . . . 10 87 3.9. Detecting Lost Packets . . . . . . . . . . . . . . . . . 11 88 3.9.1. Handshake Packets . . . . . . . . . . . . . . . . . . 11 89 3.9.2. Pseudocode . . . . . . . . . . . . . . . . . . . . . 11 90 4. Congestion Control . . . . . . . . . . . . . . . . . . . . . 12 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 94 6.2. Informative References . . . . . . . . . . . . . . . . . 13 95 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 96 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 13 97 B.1. Since draft-ietf-quic-recovery-01 . . . . . . . . . . . . 14 98 B.2. Since draft-ietf-quic-recovery-00: . . . . . . . . . . . 14 99 B.3. Since draft-iyengar-quic-loss-recovery-01: . . . . . . . 14 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 102 1. Introduction 104 QUIC is a new multiplexed and secure transport atop UDP. QUIC builds 105 on decades of transport and security experience, and implements 106 mechanisms that make it attractive as a modern general-purpose 107 transport. The QUIC protocol is described in [QUIC-TRANSPORT]. 109 QUIC implements the spirit of known TCP loss recovery mechanisms, 110 described in RFCs, various Internet-drafts, and also those prevalent 111 in the Linux TCP implementation. This document describes QUIC 112 congestion control and loss recovery, and where applicable, 113 attributes the TCP equivalent in RFCs, Internet-drafts, academic 114 papers, and/or TCP implementations. 116 This document first describes pre-requisite parts of the QUIC 117 transmission machinery, then discusses QUIC's default congestion 118 control and loss detection mechanisms, and finally lists the various 119 TCP mechanisms that QUIC loss detection implements (in spirit.) 121 1.1. Notational Conventions 123 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 124 document. It's not shouting; when they are capitalized, they have 125 the special meaning defined in [RFC2119]. 127 2. Design of the QUIC Transmission Machinery 129 All transmissions in QUIC are sent with a packet-level header, which 130 includes a packet sequence number (referred to below as a packet 131 number). These packet numbers never repeat in the lifetime of a 132 connection, and are monotonically increasing, which makes duplicate 133 detection trivial. This fundamental design decision obviates the 134 need for disambiguating between transmissions and retransmissions and 135 eliminates significant complexity from QUIC's interpretation of TCP 136 loss detection mechanisms. 138 Every packet may contain several frames. We outline the frames that 139 are important to the loss detection and congestion control machinery 140 below. 142 o Retransmittable frames are frames requiring reliable delivery. 143 The most common are STREAM frames, which typically contain 144 application data. 146 o Crypto handshake data is also sent as STREAM data, and uses the 147 reliability machinery of QUIC underneath. 149 o ACK frames contain acknowledgment information. QUIC uses a SACK- 150 based scheme, where acks express up to 256 ranges. The ACK frame 151 also includes a receive timestamp for each packet newly acked. 153 2.1. Relevant Differences Between QUIC and TCP 155 There are some notable differences between QUIC and TCP which are 156 important for reasoning about the differences between the loss 157 recovery mechanisms employed by the two protocols. We briefly 158 describe these differences below. 160 2.1.1. Monotonically Increasing Packet Numbers 162 TCP conflates transmission sequence number at the sender with 163 delivery sequence number at the receiver, which results in 164 retransmissions of the same data carrying the same sequence number, 165 and consequently to problems caused by "retransmission ambiguity". 166 QUIC separates the two: QUIC uses a packet sequence number (referred 167 to as the "packet number") for transmissions, and any data that is to 168 be delivered to the receiving application(s) is sent in one or more 169 streams, with stream offsets encoded within STREAM frames inside of 170 packets that determine delivery order. 172 QUIC's packet number is strictly increasing, and directly encodes 173 transmission order. A higher QUIC packet number signifies that the 174 packet was sent later, and a lower QUIC packet number signifies that 175 the packet was sent earlier. When a packet containing frames is 176 deemed lost, QUIC rebundles necessary frames in a new packet with a 177 new packet number, removing ambiguity about which packet is 178 acknowledged when an ACK is received. Consequently, more accurate 179 RTT measurements can be made, spurious retransmissions are trivially 180 detected, and mechanisms such as Fast Retransmit can be applied 181 universally, based only on packet number. 183 This design point significantly simplifies loss detection mechanisms 184 for QUIC. Most TCP mechanisms implicitly attempt to infer 185 transmission ordering based on TCP sequence numbers - a non-trivial 186 task, especially when TCP timestamps are not available. 188 2.1.2. No Reneging 190 QUIC ACKs contain information that is equivalent to TCP SACK, but 191 QUIC does not allow any acked packet to be reneged, greatly 192 simplifying implementations on both sides and reducing memory 193 pressure on the sender. 195 2.1.3. More ACK Ranges 197 QUIC supports up to 256 ACK ranges, opposed to TCP's 3 SACK ranges. 198 In high loss environments, this speeds recovery. 200 2.1.4. Explicit Correction For Delayed Acks 202 QUIC ACKs explicitly encode the delay incurred at the receiver 203 between when a packet is received and when the corresponding ACK is 204 sent. This allows the receiver of the ACK to adjust for receiver 205 delays, specifically the delayed ack timer, when estimating the path 206 RTT. This mechanism also allows a receiver to measure and report the 207 delay from when a packet was received by the OS kernel, which is 208 useful in receivers which may incur delays such as context-switch 209 latency before a userspace QUIC receiver processes a received packet. 211 3. Loss Detection 213 We now describe QUIC's loss detection as functions that should be 214 called on packet transmission, when a packet is acked, and timer 215 expiration events. 217 3.1. Constants of interest 219 Constants used in loss recovery and congestion control are based on a 220 combination of RFCs, papers, and common practice. Some may need to 221 be changed or negotiated in order to better suit a variety of 222 environments. 224 kMaxTLPs (default 2): Maximum number of tail loss probes before an 225 RTO fires. 227 kReorderingThreshold (default 3): Maximum reordering in packet 228 number space before FACK style loss detection considers a packet 229 lost. 231 kTimeReorderingFraction (default 1/8): Maximum reordering in time 232 sapce before time based loss detection considers a packet lost. 233 In fraction of an RTT. 235 kMinTLPTimeout (default 10ms): Minimum time in the future a tail 236 loss probe alarm may be set for. 238 kMinRTOTimeout (default 200ms): Minimum time in the future an RTO 239 alarm may be set for. 241 kDelayedAckTimeout (default 25ms): The length of the peer's delayed 242 ack timer. 244 kDefaultInitialRtt (default 100ms): The default RTT used before an 245 RTT sample is taken. 247 3.2. Variables of interest 249 We first describe the variables required to implement the loss 250 detection mechanisms described in this section. 252 loss_detection_alarm: Multi-modal alarm used for loss detection. 254 handshake_count: The number of times the handshake packets have been 255 retransmitted without receiving an ack. 257 tlp_count: The number of times a tail loss probe has been sent 258 without receiving an ack. 260 rto_count: The number of times an rto has been sent without 261 receiving an ack. 263 smoothed_rtt: The smoothed RTT of the connection, computed as 264 described in [RFC6298] 266 rttvar: The RTT variance, computed as described in [RFC6298] 268 initial_rtt: The initial RTT used before any RTT measurements have 269 been made. 271 reordering_threshold: The largest delta between the largest acked 272 retransmittable packet and a packet containing retransmittable 273 frames before it's declared lost. 275 time_reordering_fraction: The reordering window as a fraction of 276 max(smoothed_rtt, latest_rtt). 278 loss_time: The time at which the next packet will be considered lost 279 based on early transmit or exceeding the reordering window in 280 time. 282 sent_packets: An association of packet numbers to information about 283 them, including a number field indicating the packet number, a 284 time field indicating the time a packet was sent, and a bytes 285 field indicating the packet's size. sent_packets is ordered by 286 packet number, and packets remain in sent_packets until 287 acknowledged or lost. 289 3.3. Initialization 291 At the beginning of the connection, initialize the loss detection 292 variables as follows: 294 loss_detection_alarm.reset() 295 handshake_count = 0 296 tlp_count = 0 297 rto_count = 0 298 if (UsingTimeLossDetection()) 299 reordering_threshold = infinite 300 time_reordering_fraction = kTimeReorderingFraction 301 else: 302 reordering_threshold = kReorderingThreshold 303 time_reordering_fraction = infinite 304 loss_time = 0 305 smoothed_rtt = 0 306 rttvar = 0 307 initial_rtt = kDefaultInitialRtt 309 3.4. On Sending a Packet 311 After any packet is sent, be it a new transmission or a rebundled 312 transmission, the following OnPacketSent function is called. The 313 parameters to OnPacketSent are as follows: 315 o packet_number: The packet number of the sent packet. 317 o is_retransmittble: A boolean that indicates whether the packet 318 contains at least one frame requiring reliable deliver. The 319 retransmittability of various QUIC frames is described in 320 [QUIC-TRANSPORT]. If false, it is still acceptable for an ack to 321 be received for this packet. However, a caller MUST NOT set 322 is_retransmittable to true if an ack is not expected. 324 o sent_bytes: The number of bytes sent in the packet. 326 Pseudocode for OnPacketSent follows: 328 OnPacketSent(packet_number, is_retransmittable, sent_bytes): 329 sent_packets[packet_number].packet_number = packet_number 330 sent_packets[packet_number].time = now 331 if is_retransmittable: 332 sent_packets[packet_number].bytes = sent_bytes 333 SetLossDetectionAlarm() 335 3.5. On Ack Receipt 337 When an ack is received, it may acknowledge 0 or more packets. 339 Pseudocode for OnAckReceived and UpdateRtt follow: 341 OnAckReceived(ack): 342 // If the largest acked is newly acked, update the RTT. 343 if (sent_packets[ack.largest_acked]): 344 rtt_sample = now - sent_packets[ack.largest_acked].time 345 if (rtt_sample > ack.ack_delay): 346 rtt_sample -= ack.delay 347 UpdateRtt(rtt_sample) 348 // Find all newly acked packets. 349 for acked_packet_number in DetermineNewlyAckedPackets(): 350 OnPacketAcked(acked_packet_number) 352 DetectLostPackets(ack.largest_acked_packet) 353 SetLossDetectionAlarm() 355 UpdateRtt(rtt_sample): 356 // Based on {{RFC6298}}. 357 if (smoothed_rtt == 0): 358 smoothed_rtt = rtt_sample 359 rttvar = rtt_sample / 2 360 else: 361 rttvar = 3/4 * rttvar + 1/4 * (smoothed_rtt - rtt_sample) 362 smoothed_rtt = 7/8 * smoothed_rtt + 1/8 * rtt_sample 364 3.6. On Packet Acknowledgment 366 When a packet is acked for the first time, the following 367 OnPacketAcked function is called. Note that a single ACK frame may 368 newly acknowledge several packets. OnPacketAcked must be called once 369 for each of these newly acked packets. 371 OnPacketAcked takes one parameter, acked_packet, which is the packet 372 number of the newly acked packet, and returns a list of packet 373 numbers that are detected as lost. 375 Pseudocode for OnPacketAcked follows: 377 OnPacketAcked(acked_packet_number): 378 handshake_count = 0 379 tlp_count = 0 380 rto_count = 0 381 sent_packets.remove(acked_packet_number) 383 3.7. Setting the Loss Detection Alarm 385 QUIC loss detection uses a single alarm for all timer-based loss 386 detection. The duration of the alarm is based on the alarm's mode, 387 which is set in the packet and timer events further below. The 388 function SetLossDetectionAlarm defined below shows how the single 389 timer is set based on the alarm mode. 391 3.7.1. Handshake Packets 393 The initial flight has no prior RTT sample. A client SHOULD remember 394 the previous RTT it observed when resumption is attempted and use 395 that for an initial RTT value. If no previous RTT is available, the 396 initial RTT defaults to 200ms. Once an RTT measurement is taken, it 397 MUST replace initial_rtt. 399 Endpoints MUST retransmit handshake frames if not acknowledged within 400 a time limit. This time limit will start as the largest of twice the 401 rtt value and MinTLPTimeout. Each consecutive handshake 402 retransmission doubles the time limit, until an acknowledgement is 403 received. 405 Handshake frames may be cancelled by handshake state transitions. In 406 particular, all non-protected frames SHOULD be no longer be 407 transmitted once packet protection is available. 409 When stateless rejects are in use, the connection is considered 410 immediately closed once a reject is sent, so no timer is set to 411 retransmit the reject. 413 Version negotiation packets are always stateless, and MUST be sent 414 once per per handshake packet that uses an unsupported QUIC version, 415 and MAY be sent in response to 0RTT packets. 417 3.7.2. Tail Loss Probe and Retransmission Timeout 419 Tail loss probes [I-D.dukkipati-tcpm-tcp-loss-probe] and 420 retransmission timeouts[RFC6298] are an alarm based mechanism to 421 recover from cases when there are outstanding retransmittable 422 packets, but an acknowledgement has not been received in a timely 423 manner. 425 3.7.3. Early Retransmit 427 Early retransmit [RFC5827] is implemented with a 1/4 RTT timer. It 428 is part of QUIC's time based loss detection, but is always enabled, 429 even when only packet reordering loss detection is enabled. 431 3.7.4. Pseudocode 433 Pseudocode for SetLossDetectionAlarm follows: 435 SetLossDetectionAlarm(): 436 if (retransmittable packets are not outstanding): 437 loss_detection_alarm.cancel(); 438 return 440 if (handshake packets are outstanding): 441 // Handshake retransmission alarm. 442 if (smoothed_rtt == 0): 443 alarm_duration = 2 * initial_rtt 444 else: 445 alarm_duration = 2 * smoothed_rtt 446 alarm_duration = max(alarm_duration, kMinTLPTimeout) 447 alarm_duration = alarm_duration << handshake_count 448 else if (loss_time != 0): 449 // Early retransmit timer or time loss detection. 450 alarm_duration = loss_time - now 451 else if (tlp_count < kMaxTLPs): 452 // Tail Loss Probe 453 if (retransmittable_packets_outstanding = 1): 454 alarm_duration = 1.5 * smoothed_rtt + kDelayedAckTimeout 455 else: 456 alarm_duration = kMinTLPTimeout 457 alarm_duration = max(alarm_duration, 2 * smoothed_rtt) 458 else: 459 // RTO alarm 460 if (rto_count = 0): 461 alarm_duration = smoothed_rtt + 4 * rttvar 462 alarm_duration = max(alarm_duration, kMinRTOTimeout) 463 else: 464 alarm_duration = loss_detection_alarm.get_delay() << 1 466 loss_detection_alarm.set(now + alarm_duration) 468 3.8. On Alarm Firing 470 QUIC uses one loss recovery alarm, which when set, can be in one of 471 several modes. When the alarm fires, the mode determines the action 472 to be performed. 474 Pseudocode for OnLossDetectionAlarm follows: 476 OnLossDetectionAlarm(): 477 if (handshake packets are outstanding): 478 // Handshake retransmission alarm. 479 RetransmitAllHandshakePackets(); 480 handshake_count++; 481 // TODO: Clarify early retransmit and time loss. 482 else if (loss_time != 0): 483 // Early retransmit or Time Loss Detection 484 DetectLostPackets(largest_acked_packet) 485 else if (tlp_count < kMaxTLPs): 486 // Tail Loss Probe. 487 if (HasNewDataToSend()): 488 SendOnePacketOfNewData() 489 else: 490 RetransmitOldestPacket() 491 tlp_count++ 492 else: 493 // RTO. 494 RetransmitOldestTwoPackets() 495 rto_count++ 497 SetLossDetectionAlarm() 499 3.9. Detecting Lost Packets 501 Packets in QUIC are only considered lost once a larger packet number 502 is acknowledged. DetectLostPackets is called every time an ack is 503 received. If the loss detection alarm fires and the loss_time is 504 set, the previous largest acked packet is supplied. 506 3.9.1. Handshake Packets 508 The receiver MUST ignore unprotected packets that ack protected 509 packets. The receiver MUST trust protected acks for unprotected 510 packets, however. Aside from this, loss detection for handshake 511 packets when an ack is processed is identical to other packets. 513 3.9.2. Pseudocode 515 DetectLostPackets takes one parameter, acked, which is the largest 516 acked packet. 518 Pseudocode for DetectLostPackets follows: 520 DetectLostPackets(largest_acked): 521 loss_time = 0 522 lost_packets = {} 523 delay_until_lost = infinite; 524 if (time_reordering_fraction != infinite): 525 delay_until_lost = 526 (1 + time_reordering_fraction) * max(latest_rtt, smoothed_rtt) 527 else if (largest_acked.packet_number == largest_sent_packet): 528 // Early retransmit alarm. 529 delay_until_lost = 9/8 * max(latest_rtt, smoothed_rtt) 530 foreach (unacked less than largest_acked.packet_number): 531 time_since_sent = now() - unacked.time_sent 532 packet_delta = largest_acked.packet_number - unacked.packet_number 533 if (time_since_sent > delay_until_lost): 534 lost_packets.insert(unacked) 535 else if (packet_delta > reordering_threshold) 536 lost_packets.insert(unacked) 537 else if (loss_time == 0 && delay_until_lost != infinite): 538 loss_time = delay_until_lost - time_since_sent 540 // Inform the congestion controller of lost packets and 541 // lets it decide whether to retransmit immediately. 542 OnPacketsLost(lost_packets) 543 foreach (packet in lost_packets) 544 sent_packets.remove(packet.packet_number) 546 4. Congestion Control 548 (describe NewReno-style congestion control [RFC6582] for QUIC.) 549 (describe appropriate byte counting.) (define recovery based on 550 packet numbers.) (describe min_rtt based hystart.) (describe how 551 QUIC's F-RTO [RFC5682] delays reducing CWND.) (describe PRR 552 [RFC6937]) 554 5. IANA Considerations 556 This document has no IANA actions. Yet. 558 6. References 560 6.1. Normative References 562 [QUIC-TRANSPORT] 563 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 564 Multiplexed and Secure Transport". 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, 568 DOI 10.17487/RFC2119, March 1997, 569 . 571 6.2. Informative References 573 [I-D.dukkipati-tcpm-tcp-loss-probe] 574 Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 575 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 576 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 577 in progress), February 2013. 579 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 580 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 581 Spurious Retransmission Timeouts with TCP", RFC 5682, 582 DOI 10.17487/RFC5682, September 2009, 583 . 585 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 586 P. Hurtig, "Early Retransmit for TCP and Stream Control 587 Transmission Protocol (SCTP)", RFC 5827, 588 DOI 10.17487/RFC5827, May 2010, 589 . 591 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 592 "Computing TCP's Retransmission Timer", RFC 6298, 593 DOI 10.17487/RFC6298, June 2011, 594 . 596 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 597 NewReno Modification to TCP's Fast Recovery Algorithm", 598 RFC 6582, DOI 10.17487/RFC6582, April 2012, 599 . 601 [RFC6937] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional 602 Rate Reduction for TCP", RFC 6937, DOI 10.17487/RFC6937, 603 May 2013, . 605 Appendix A. Acknowledgments 607 Appendix B. Change Log 609 *RFC Editor's Note:* Please remove this section prior to 610 publication of a final version of this document. 612 B.1. Since draft-ietf-quic-recovery-01 614 o Changes initial default RTT to 100ms 616 o Added time-based loss detection and fixes early retransmit 618 o Clarified loss recovery for handshake packets 620 o Fixed references and made TCP references informative 622 B.2. Since draft-ietf-quic-recovery-00: 624 o Improved description of constants and ACK behavior 626 B.3. Since draft-iyengar-quic-loss-recovery-01: 628 o Adopted as base for draft-ietf-quic-recovery. 630 o Updated authors/editors list. 632 o Added table of contents. 634 Authors' Addresses 636 Jana Iyengar (editor) 637 Google 639 Email: jri@google.com 641 Ian Swett (editor) 642 Google 644 Email: ianswett@google.com