idnits 2.17.1 draft-ietf-tcpm-rto-consider-16.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 abstract seems to contain references ([RFC2119], [RFC8174]), 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 (June 19, 2020) is 1405 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-tcpm-rack-08 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-27 -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M. Allman 2 INTERNET-DRAFT ICSI 3 File: draft-ietf-tcpm-rto-consider-16.txt June 19, 2020 4 Intended Status: Best Current Practice 5 Expires: December 19, 2020 7 Requirements for Time-Based Loss Detection 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 This Internet-Draft will expire on December 19, 2020. 30 Copyright Notice 32 Copyright (c) 2020 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with 40 respect to this document. Code Components extracted from this 41 document must include Simplified BSD License text as described in 42 Section 4.e of the Trust Legal Provisions and are provided without 43 warranty as described in the Simplified BSD License. 45 Abstract 47 Many protocols must detect packet loss for various reasons (e.g., to 48 ensure reliability using retransmissions or to understand the level 49 of congestion along a network path). While many mechanisms have 50 been designed to detect loss, protocols ultimately can only count on 51 the passage of time without delivery confirmation to declare a 52 packet "lost". Each implementation of a time-based loss detection 53 mechanism represents a balance between correctness and timeliness 54 and therefore no implementation suits all situations. This document 55 provides high-level requirements for time-based loss detectors 56 appropriate for general use in the Internet. Within the 57 requirements, implementations have latitude to define particulars 58 that best address each situation. 60 Terminology 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 64 "OPTIONAL" in this document are to be interpreted as described in 65 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 66 capitals, as shown here. 68 1 Introduction 70 As a network of networks, the Internet consists of a large variety 71 of links and systems that support a wide variety of tasks and 72 workloads. The service provided by the network varies from best 73 effort delivery among loosely connected components to highly 74 predictable delivery within constrained environments (e.g., between 75 physically connected nodes, within a tightly controlled data 76 center). Each path through the network has a set of path 77 properties---e.g., available capacity, delay, packet loss. Given 78 the range of networks that make up the Internet, these properties 79 range from largely static to highly dynamic. 81 This document provides guidelines for developing an understanding of 82 one path property: loss. In particular, we offer guidelines for 83 developing and implementing time-based loss detectors that have been 84 gradually learned over the last several decades. We focus on the 85 general case where the loss properties of a path are (a) unknown a 86 priori and (b) dynamically vary over time. Further, while there are 87 numerous root causes of packet loss, we leverage the conservative 88 notion that loss is an implicit indication of congestion. While 89 this stance is not always correct, as a general assumption it has 90 historically served us well. As we discuss further in section 2, 91 the guidelines in this document should be viewed as a general 92 default for best effort networks and not as optimal---or even 93 applicable---for all situations. 95 Given that packet loss is routine in best effort networks, loss 96 detection is a crucial activity for many protocols and applications 97 and is generally undertaken for two major reasons: 99 (1) Ensuring reliable data delivery. 101 This requires a data sender to develop an understanding of 102 which transmitted packets have not arrived at the receiver. 103 This knowledge allows the sender to retransmit missing data. 105 (2) Congestion control. 107 As we mention above, packet loss is often taken as an 108 implicit indication that the sender is transmitting too fast 109 and is overwhelming some portion of the network path. Data 110 senders can therefore use loss to trigger transmission rate 111 reductions. 113 Various mechanisms are used to detect losses in a packet stream. 114 Often we use continuous or periodic acknowledgments from the 115 recipient to inform the sender's notion of which pieces of data are 116 missing. However, despite our best intentions and most robust 117 mechanisms we cannot place ultimate faith in receiving such 118 acknowledgments, but can only truly depend on the passage of time. 119 Therefore, our ultimate backstop to ensuring that we detect all loss 120 is a timeout. That is, the sender sets some expectation for how 121 long to wait for confirmation of delivery for a given piece of data. 122 When this time period passes without delivery confirmation the 123 sender concludes the data was lost in transit. 125 The specifics of time-based loss detection schemes represent a 126 tradeoff between correctness and responsiveness. In other words we 127 wish to simultaneously: 129 - wait long enough to ensure the detection of loss is correct, and 131 - minimize the amount of delay we impose on applications (before 132 repairing loss) and the network (before we reduce the 133 congestion). 135 Serving both of these goals is difficult as they pull in opposite 136 directions [AP99]. By not waiting long enough to accurately 137 determine a packet has been lost we may provide a needed 138 retransmission in a timely manner, but risk sending unnecessary 139 ("spurious") retransmissions and needlessly lowering the 140 transmission rate. By waiting long enough that we are unambiguously 141 certain a packet has been lost we cannot repair losses in a timely 142 manner and we risk prolonging network congestion. 144 Many protocols and applications use their own time-based loss 145 detection mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP 146 [RFC3261]). At this point, our experience leads to a recognition 147 that often specific tweaks that deviate from standardized time-based 148 loss detectors do not materially impact network safety with respect 149 to congestion control. Therefore, in this document we outline a set 150 of high-level protocol-agnostic requirements for time-based loss 151 detection. The intent is to provide a safe foundation on which 152 implementations have the flexibility to instantiate mechanisms that 153 best realize their specific goals. 155 2 Context 157 This document is different from the way we ideally like to engineer 158 systems. Usually, we strive to understand high-level requirements 159 as a starting point. We then methodically engineer specific 160 protocols, algorithms and systems that meet these requirements. 161 Within the IETF standards process we have derived many time-based 162 loss detection schemes without benefit from some over-arching 163 requirements document---because we had no idea how to write such a 164 document! Therefore, we made the best specific decisions we could 165 in response to specific needs. 167 At this point, however, the community's experience has matured to 168 the point where we can define a set of general, high-level 169 requirements for time-based loss detection schemes. We now 170 understand how to separate the strategies these mechanisms use that 171 are crucial for network safety from those small details that do not 172 materially impact network safety. The requirements in this document 173 may not be appropriate in all cases. In particular, the guidelines 174 in section 4 are concerned with the general case, but specific 175 situations may allow for more flexibility in terms of loss detection 176 because specific facets of the environment are known (e.g., when 177 operating over a single physical link or within a tightly controlled 178 data center). Therefore, variants, deviations or wholly different 179 time-based loss detectors may be necessary or useful in some cases. 180 The correct way to view this document is as the default case and not 181 as a one-size-fits-all that is optimal in all cases. 183 Adding a requirements umbrella to a body of existing specifications 184 is inherently messy and we run the risk of creating inconsistencies 185 with both past and future mechanisms. Therefore, we make the 186 following statements about the relationship of this document to past 187 and future specifications: 189 - This document does not update or obsolete any existing RFC. 190 These previous specifications---while generally consistent with 191 the requirements in this document---reflect community consensus 192 and this document does not change that consensus. 194 - The requirements in this document are meant to provide for 195 network safety and, as such, SHOULD be used by all time-based 196 loss detection mechanisms. 198 - The requirements in this document may not be appropriate in all 199 cases and, therefore, inconsistent deviations and variants may 200 be necessary (hence the "SHOULD" in the last bullet). However, 201 inconsistencies MUST be (a) explained and (b) gather consensus. 203 3 Scope 205 The principles we outline in this document are protocol-agnostic and 206 widely applicable. We make the following scope statements about 207 the application of the requirements discussed in Section 4: 209 (S.1) The requirements in this document apply only to the primary or 210 last resort time-based loss detection. 212 While there are a bevy of uses for timers in protocols---from 213 rate-based pacing to connection failure detection and 214 beyond---these are outside the scope of this document. 216 (S.2) The requirements for time-based loss detection mechanisms in 217 this document are for the primary or "last resort" loss 218 detection mechanism whether the mechanism is the sole loss 219 repair strategy or works in concert with other mechanisms. 221 While a straightforward time-based loss detector is sufficient 222 for simple protocols like DNS [RFC1034,RFC1035], more complex 223 protocols often use more advanced loss detectors to aid 224 performance. For instance, TCP and SCTP have methods to 225 detect (and repair) loss based on explicit endpoint state 226 sharing [RFC2018,RFC4960,RFC6675]. Such mechanisms often 227 provide more timely and precise results than time-based loss 228 detectors. However, these mechanisms do not obviate the need 229 for a "retransmission timeout" or "RTO" because---as we 230 discuss in Section 1---only the passage of time can ultimately 231 be relied upon to detect loss. In cases such as these, the 232 time-based loss detector functions as a "last resort". 234 Also, note, that some recent proposals have incorporated time 235 as a component of advanced loss detection methods---either as 236 an aggressive first loss detector or in conjunction with 237 endpoint state sharing [DCCM13,CCDJ20,IS20]. Since these 238 timers are not used as "last resort" the requirements in this 239 document need not be directly used in these cases. However, 240 we expect that many of the requirements are useful for these 241 situations, as well. 243 (S.3) The requirements in this document apply only to endpoint-to- 244 endpoint unicast communication. Reliable multicast (e.g., 245 [RFC5740]) protocols are explicitly outside the scope of this 246 document. 248 Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that 249 communicate in a unicast fashion with multiple specific 250 endpoints can leverage the requirements in this document 251 provided they track state and follow the requirements for each 252 endpoint independently. I.e., if host A communicates with 253 addresses B and C, A needs to use independent time-based loss 254 detector instances for traffic sent to B and C. 256 (S.4) There are cases where state is shared across connections 257 or flows (e.g., [RFC2140], [RFC3124]). State pertaining to 258 time-based loss detection is often discussed as sharable. 259 These situations raise issues that the simple flow-oriented 260 time-based loss detection mechanism discussed in this document 261 does not consider (e.g., how long to preserve state between 262 connections). Therefore, while the general principles given 263 in Section 4 are likely applicable, sharing time-based loss 264 detection information across flows is outside the scope of 265 this document. 267 4 Requirements 269 We now list the requirements that apply when designing primary or 270 last resort time-based loss detection mechanisms. For historical 271 reasons and ease of exposition, we refer to the time between sending 272 a packet and determining the packet has been lost due to lack of 273 delivery confirmation as the "retransmission timeout" or "RTO". 274 After the RTO passes without delivery confirmation, the sender may 275 safely assume the packet is lost. However, as discussed above, the 276 detected loss need not be repaired (i.e., the loss could be detected 277 only for congestion control and not reliability purposes). 279 (1) As we note above, loss detection happens when a sender does not 280 receive delivery confirmation within an some expected period of 281 time. In the absence of any knowledge about the latency of a 282 path, the initial RTO MUST be conservatively set to no less than 283 1 second. 285 Correctness is of the utmost importance when transmitting into a 286 network with unknown properties because: 288 - Premature loss detection can trigger spurious retransmits that 289 could cause issues when a network is already congested. 291 - Premature loss detection can needlessly cause congestion 292 control to dramatically lower the sender's allowed 293 transmission rate---especially since the rate is already 294 likely low at this stage of the communication. Recovering 295 from such a rate change can taken a relatively long time. 297 - Finally, as discussed below, sometimes using time-based 298 loss detection and retransmissions can cause ambiguities in 299 assessing the latency of a network path. Therefore, it is 300 especially important for the first latency sample to be free 301 of ambiguities such that there is a baseline for the remainder 302 of the communication. 304 The specific constant (1 second) comes from the analysis of 305 Internet RTTs found in Appendix A of [RFC6298]. 307 (2) We now specify four requirements that pertain to setting 308 an expected time interval for delivery confirmation. 310 Often measuring the time required for delivery confirmation is 311 is framed as assessing the "round-trip time (RTT)" of the 312 network path as this is the minimum amount of time required to 313 receive delivery confirmation and also often follows protocol 314 behavior whereby acknowledgments are generated quickly after 315 data arrives. For instance, this is the case for the RTO used 316 by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat 317 mis-leading and the expected latency is better framed as the 318 "feedback time" (FT). In other words, the expectation is not 319 always simply a network property, but can include additional 320 time before a sender should reasonably expect a response. 322 For instance, consider a UDP-based DNS request from a client to 323 a recursive resolver [RFC1035]. When the request can be served 324 from the resolver's cache the FT likely well approximates the 325 network RTT between the client and resolver. However, on a 326 cache miss the resolver will request the needed information from 327 one or more authoritative DNS servers, which will non-trivially 328 increase the FT compared to the network RTT between the client 329 and resolver. 331 Therefore, we express the requirements in terms of FT. Again, 332 for ease of exposition we use "RTO" to indicate the interval 333 between a packet transmission and the decision the packet has 334 been lost---regardless of whether the packet will be 335 retransmitted. 337 (a) If/when available, the RTO SHOULD be set based on multiple 338 observations of the FT. 340 In other words, the RTO should represent an empirically- 341 derived reasonable amount of time that the sender should 342 wait for delivery confirmation before deciding the given 343 data is lost. Network paths are inherently dynamic and 344 therefore it is crucial to incorporate multiple FT samples 345 in the RTO to take into account the delay variation across 346 time. 348 For example, TCP's RTO [RFC6298] would satisfy this 349 requirement due to its use of an exponentially-weighted 350 moving average (EWMA) to combine multiple FT samples into a 351 "smoothed RTT". In the name of conservativeness, TCP goes 352 further to also include an explicit variance term when 353 computing the RTO. 355 (b) FT observations SHOULD be taken and incorporated into the 356 RTO at least once per RTT or as frequently as data is 357 exchanged in cases where that happens less frequently than 358 once per RTT. 360 Internet measurements show that taking only a single FT 361 sample per TCP connection results in a relatively poorly 362 performing RTO mechanism [AP99], hence this requirement that 363 the FT be sampled continuously throughout the lifetime of 364 communication. 366 As an example, TCP takes an FT sample roughly once per RTT, 367 or if using the timestamp option [RFC7323] on each 368 acknowledgment arrival. [AP99] shows that both these 369 approaches result in roughly equivalent performance for the 370 RTO estimator. 372 (c) FT observations MAY be taken from non-data exchanges. 374 Some protocols use non-data exchanges for various 375 reasons---e.g., keepalives, heartbeats, control messages. 376 To the extent that the latency of these exchanges mirrors 377 data exchange, they can be leveraged to take FT samples 378 within the RTO mechanism. Such samples can help protocols 379 keep their RTO accurate during lulls in data transmission. 380 However, given that these messages may not be subject to the 381 same delays as data transmission, we do not take a general 382 view on whether this is useful or not. 384 (d) An RTO mechanism MUST NOT use ambiguous FT samples. 386 Assume two copies of some segment X are transmitted at times 387 t0 and t1 and then at time t2 the sender receives 388 confirmation that X in fact arrived. In some cases, it is 389 not clear which copy of X triggered the confirmation and 390 hence the actual FT is either t2-t1 or t2-t0, but which is a 391 mystery. Therefore, in this situation an implementation 392 MUST use Karn's algorithm [KP87,RFC6298] and use neither 393 version of the FT sample and hence not update the RTO. 395 There are cases where two copies of some data are 396 transmitted in a way whereby the sender can tell which is 397 being acknowledged by an incoming ACK. E.g., TCP's 398 timestamp option [RFC7323] allows for segments to be 399 uniquely identified and hence avoid the ambiguity. In such 400 cases there is no ambiguity and the resulting samples can 401 update the RTO. 403 (3) Loss detected by the RTO mechanism MUST be taken as an 404 indication of network congestion and the sending rate adapted 405 using a standard mechanism (e.g., TCP collapses the congestion 406 window to one segment [RFC5681]). 408 This ensures network safety. 410 An exception to this rule is if an IETF standardized mechanism 411 determines that a particular loss is due to a non-congestion 412 event (e.g., packet corruption). In such a case a congestion 413 control action is not required. Additionally, congestion 414 control actions taken based on time-based loss detection could 415 be reversed when a standard mechanism post-facto determines that 416 the cause of the loss was not congestion (e.g., [RFC5682]). 418 (4) Each time the RTO is used to detect a loss, the value of the RTO 419 MUST be exponentially backed off such that the next firing 420 requires a longer interval. The backoff SHOULD be removed after 421 either (a) the subsequent successful transmission of 422 non-retransmitted data, or (b) an RTO passes without detecting 423 additional losses. The former will generally be quicker. The 424 latter covers cases where loss is detected, but not repaired. 426 A maximum value MAY be placed on the RTO. The maximum RTO MUST 427 NOT be less than 60 seconds (as specified in [RFC6298]). 429 This ensures network safety. 431 As with guideline (3), an exception to this rule exists if an 432 IETF standardized mechanism determines that a particular loss is 433 not due to congestion. 435 5 Discussion 437 We note that research has shown the tension between the 438 responsiveness and correctness of time-based loss detection seems to 439 be a fundamental tradeoff in the context of TCP [AP99]. That is, 440 making the RTO more aggressive (e.g., via changing TCP's 441 exponentially weighted moving average (EWMA) gains, lowering the 442 minimum RTO, etc.) can reduce the time required to detect actual 443 loss. However, at the same time, such aggressiveness leads to more 444 cases of mistakenly declaring packets lost that ultimately arrived 445 at the receiver. Therefore, being as aggressive as the requirements 446 given in the previous section allow in any particular situation may 447 not be the best course of action because detecting loss---even if 448 falsely---carries a requirement to invoke a congestion response 449 which will ultimately reduce the transmission rate. 451 While the tradeoff between responsiveness and correctness seems 452 fundamental, the tradeoff can be made less relevant if the sender 453 can detect and recover from mistaken loss detection. Several 454 mechanisms have been proposed for this purpose, such as Eifel 455 [RFC3522], F-RTO [RFC5682] and DSACK [RFC2883,RFC3708]. Using such 456 mechanisms may allow a data originator to tip towards being more 457 responsive without incurring (as much of) the attendant costs of 458 mistakenly declaring packets to be lost. 460 Also, note, that in addition to the experiments discussed in [AP99], 461 the Linux TCP implementation has been using various non-standard RTO 462 mechanisms for many years seemingly without large scale problems 463 (e.g., using different EWMA gains than specified in [RFC6298]). 464 Further, a number of implementations use a steady-state minimum RTO 465 that are less than the 1 second specified in [RFC6298] (which is 466 different from the initial RTO we specify in Section 4, Requirement 467 1). While the implication of these deviations from the standard may 468 be more spurious retransmits (per [AP99]), we are aware of no large 469 scale network safety issues caused by this change to the minimum 470 RTO. 472 Finally, we note that while allowing implementations to be more 473 aggressive could in fact increase the number of needless 474 retransmissions the above requirements fail safe in that they insist 475 on exponential backoff and a transmission rate reduction. 476 Therefore, providing implementers more latitude than they have 477 traditionally been given in IETF specifications of RTO mechanisms 478 does not somehow open the flood gates to aggressive behavior. Since 479 there is a downside to being aggressive, the incentives for proper 480 behavior are retained in the mechanism. 482 6 Security Considerations 484 This document does not alter the security properties of time-based 485 loss detection mechanisms. See [RFC6298] for a discussion of these 486 within the context of TCP. 488 7 IANA Considerations 490 This document has no IANA considerations. 492 Acknowledgments 494 This document benefits from years of discussions with Ethan Blanton, 495 Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the 496 members of the TCPM and TCP-IMPL working groups. Ran Atkinson, 497 Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Gorry 498 Fairhurst, Rahul Arvind Jadhav, Mirja Kuhlewind, Nicolas Kuhn, 499 Jonathan Looney and Michael Scharf provided useful comments on 500 previous versions of this document. 502 Normative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", RFC 8174, May 2017. 510 Informative References 512 [AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path 513 Properties", Proceedings of the ACM SIGCOMM Technical Symposium, 514 September 1999. 516 [CCDJ20] Cheng, Y., N. Cardwell, N. Dukkipati, P. Jha, "RACK: a 517 time-based fast loss detection algorithm for TCP", 518 Internet-Draft draft-ietf-tcpm-rack-08.txt (work in progress), 519 March 2020. 521 [DCCM13] Dukkipati, N., N. Cardwell, Y. Cheng, M. Mathis, "Tail Loss 522 Probe (TLP): An Algorithm for Fast Recovery of Tail Losses", 523 Internet-Draft draft-dukkipati-tcpm-tcp-loss-probe-01.txt (work 524 in progress), February 2013. 526 [IS20] Iyengar, I., I. Swett, "QUIC Loss Detection and Congestion 527 Control", Internet-Draft 528 draft-ietf-quic-recovery-27.txt (work in progress), March 2020. 530 [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 531 Estimates in Reliable Transport Protocols", SIGCOMM 87. 533 [RFC1034] Mockapetris, P. "Domain Names - Concepts and Facilities", 534 RFC 1034, November 1987. 536 [RFC1035] Mockapetris, P. "Domain Names - Implementation and 537 Specification", RFC 1035, November 1987. 539 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 540 Selective Acknowledgment Options", RFC 2018, October 1996. 542 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 543 April 1997. 545 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 546 Extension to the Selective Acknowledgement (SACK) Option for 547 TCP", RFC 2883, July 2000. 549 [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC 550 2134, June 2001. 552 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 553 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 554 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 556 [RFC3522] Ludwig, R., M. Meyer, "The Eifel Detection Algorithm for 557 TCP", RFC 3522, april 2003. 559 [RFC3708] Blanton, E., M. Allman, "Using TCP Duplicate Selective 560 Acknowledgement (DSACKs) and Stream Control Transmission 561 Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) 562 to Detect Spurious Retransmissions", RFC 3708, February 2004. 564 [RFC4960] Stweart, R., "Stream Control Transmission Protocol", RFC 565 4960, September 2007. 567 [RFC5681] Allman, M., V. Paxson, E. Blanton, "TCP Congestion 568 Control", RFC 5681, September 2009. 570 [RFC5682] Sarolahti, P., M. Kojo, K. Yamamoto, M. Hata, "Forward 571 RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious 572 Retransmission Timeouts with TCP", RFC 5682, September 2009. 574 [RFC5740] Adamson, B., C. Bormann, M. Handley, J. Macker, 575 "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", 576 RFC 5740, November 2009. 578 [RFC6182] Ford, A., C. Raiciu, M. Handley, S. Barre, J. Iyengar, 579 "Architectural Guidelines for Multipath TCP Development", March 580 2011, RFC 6182. 582 [RFC6298] Paxson, V., M. Allman, H.K. Chu, M. Sargent, "Computing 583 TCP's Retransmission Timer", June 2011, RFC 6298. 585 [RFC6675] Blanton, E., M. Allman, L. Wang, I. Jarvinen, M. Kojo, 586 Y. Nishida, "A Conservative Loss Recovery Algorithm Based on 587 Selective Acknowledgment (SACK) for TCP", August 2012, RFC 6675. 589 [RFC7323] Borman D., B. Braden, V. Jacobson, R. Scheffenegger, "TCP 590 Extensions for High Performance", September 2014, RFC 7323. 592 Authors' Addresses 594 Mark Allman 595 International Computer Science Institute 596 1947 Center St. Suite 600 597 Berkeley, CA 94704 599 EMail: mallman@icir.org 600 http://www.icir.org/mallman