idnits 2.17.1 draft-ietf-tcpm-rto-consider-17.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 (July 27, 2020) is 1359 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-17.txt July 27, 2020 4 Intended Status: Best Current Practice 5 Expires: January 27, 2021 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 January 27, 2021. 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, ultimately, protocols can only count 51 on 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 unicast communication across the 57 Internet. Within the requirements, implementations have latitude to 58 define particulars 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 73 best-effort delivery among loosely connected components to highly 74 predictable delivery within controlled 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: packet loss. In particular, we offer guidelines 83 for developing and implementing time-based loss detectors that have 84 been gradually learned over the last several decades. We focus on 85 the general case where the loss properties of a path are (a) unknown 86 a priori and (b) dynamically vary over time. Further, while there 87 are numerous root causes of packet loss, we leverage the 88 conservative notion that loss is an implicit indication of 89 congestion [RFC5681]. While this stance is not always correct, as a 90 general assumption it has historically served us well [Jac88]. As 91 we discuss further in section 2, the guidelines in this document 92 should be viewed as a general default for unicast communication 93 across best-effort networks and not as optimal---or even 94 applicable---for all situations. 96 Given that packet loss is routine in best-effort networks, loss 97 detection is a crucial activity for many protocols and applications 98 and is generally undertaken for two major reasons: 100 (1) Ensuring reliable data delivery. 102 This requires a data sender to develop an understanding of 103 which transmitted packets have not arrived at the receiver. 104 This knowledge allows the sender to retransmit missing data. 106 (2) Congestion control. 108 As we mention above, packet loss is often taken as an 109 implicit indication that the sender is transmitting too fast 110 and is overwhelming some portion of the network path. Data 111 senders can therefore use loss to trigger transmission rate 112 reductions. 114 Various mechanisms are used to detect losses in a packet stream. 115 Often we use continuous or periodic acknowledgments from the 116 recipient to inform the sender's notion of which pieces of data are 117 missing. However, despite our best intentions and most robust 118 mechanisms we cannot place ultimate faith in receiving such 119 acknowledgments, but can only truly depend on the passage of time. 120 Therefore, our ultimate backstop to ensuring that we detect all loss 121 is a timeout. That is, the sender sets some expectation for how 122 long to wait for confirmation of delivery for a given piece of data. 123 When this time period passes without delivery confirmation the 124 sender concludes the data was lost in transit. 126 The specifics of time-based loss detection schemes represent a 127 tradeoff between correctness and responsiveness. In other words we 128 wish to simultaneously: 130 - wait long enough to ensure the detection of loss is correct, and 132 - minimize the amount of delay we impose on applications (before 133 repairing loss) and the network (before we reduce the 134 congestion). 136 Serving both of these goals is difficult as they pull in opposite 137 directions [AP99]. By not waiting long enough to accurately 138 determine a packet has been lost we may provide a needed 139 retransmission in a timely manner, but risk sending unnecessary 140 ("spurious") retransmissions and needlessly lowering the 141 transmission rate. By waiting long enough that we are unambiguously 142 certain a packet has been lost we cannot repair losses in a timely 143 manner and we risk prolonging network congestion. 145 Many protocols and applications---such as TCP [RFC6298], SCTP 146 [RFC4960], SIP [RFC3261]---use their own time-based loss detection 147 mechanisms. At this point, our experience leads to a recognition 148 that often specific tweaks that deviate from standardized time-based 149 loss detectors do not materially impact network safety with respect 150 to congestion control [AP99]. Therefore, in this document we 151 outline a set of high-level protocol-agnostic requirements for 152 time-based loss detection. The intent is to provide a safe 153 foundation on which implementations have the flexibility to 154 instantiate mechanisms that best realize their specific goals. 156 2 Context 158 This document is different from the way we ideally like to engineer 159 systems. Usually, we strive to understand high-level requirements 160 as a starting point. We then methodically engineer specific 161 protocols, algorithms and systems that meet these requirements. 162 Within the IETF standards process we have derived many time-based 163 loss detection schemes without benefit from some over-arching 164 requirements document---because we had no idea how to write such a 165 document! Therefore, we made the best specific decisions we could 166 in response to specific needs. 168 At this point, however, the community's experience has matured to 169 the point where we can define a set of general, high-level 170 requirements for time-based loss detection schemes. We now 171 understand how to separate the strategies these mechanisms use that 172 are crucial for network safety from those small details that do not 173 materially impact network safety. The requirements in this document 174 may not be appropriate in all cases. In particular, the guidelines 175 in section 4 are concerned with the general case, but specific 176 situations may allow for more flexibility in terms of loss detection 177 because specific facets of the environment are known (e.g., when 178 operating over a single physical link or within a tightly controlled 179 data center). Therefore, variants, deviations or wholly different 180 time-based loss detectors may be necessary or useful in some cases. 181 The correct way to view this document is as the default case and not 182 as a one-size-fits-all that is optimal in all cases. 184 Adding a requirements umbrella to a body of existing specifications 185 is inherently messy and we run the risk of creating inconsistencies 186 with both past and future mechanisms. Therefore, we make the 187 following statements about the relationship of this document to past 188 and future specifications: 190 - This document does not update or obsolete any existing RFC. 191 These previous specifications---while generally consistent with 192 the requirements in this document---reflect community consensus 193 and this document does not change that consensus. 195 - The requirements in this document are meant to provide for 196 network safety and, as such, SHOULD be used by all future 197 time-based loss detection mechanisms. 199 - The requirements in this document may not be appropriate in all 200 cases and, therefore, deviations and variants may be necessary 201 in the future (hence the "SHOULD" in the last bullet). However, 202 inconsistencies MUST be (a) explained and (b) gather consensus. 204 3 Scope 206 The principles we outline in this document are protocol-agnostic and 207 widely applicable. We make the following scope statements about 208 the application of the requirements discussed in Section 4: 210 (S.1) While there are a bevy of uses for timers in protocols---from 211 rate-based pacing to connection failure detection and 212 beyond---this document is focused only on loss detection. 214 (S.2) The requirements for time-based loss detection mechanisms in 215 this document are for the primary or "last resort" loss 216 detection mechanism whether the mechanism is the sole loss 217 repair strategy or works in concert with other mechanisms. 219 While a straightforward time-based loss detector is sufficient 220 for simple protocols like DNS [RFC1034,RFC1035], more complex 221 protocols often use more advanced loss detectors to aid 222 performance. For instance, TCP and SCTP have methods to 223 detect (and repair) loss based on explicit endpoint state 224 sharing [RFC2018,RFC4960,RFC6675]. Such mechanisms often 225 provide more timely and precise loss detection than time-based 226 loss detectors. However, these mechanisms do not obviate the 227 need for a "retransmission timeout" or "RTO" because---as we 228 discuss in Section 1---only the passage of time can ultimately 229 be relied upon to detect loss. In other words, ultimately we 230 cannot count on acknowledgments to arrive at the data sender 231 to indicate which packets never arrived at the receiver. In 232 cases such as these we need a time-based loss detector to 233 functions as a "last resort". 235 Also, note, that some recent proposals have incorporated time 236 as a component of advanced loss detection methods---either as 237 an aggressive first loss detector in certain situations or in 238 conjunction with endpoint state sharing [DCCM13,CCDJ20,IS20]. 239 While these mechanisms can aid timely loss recovery, the 240 protocol ultimately leans on another more conservative timer 241 to ensure reliability when these mechanisms break down. The 242 requirements in this document are only directly applicable to 243 last resort loss detection. However, we expect that many of 244 the requirements can serve as useful guidelines for more 245 aggressive non-last resort timers, as well. 247 (S.3) The requirements in this document apply only to endpoint-to- 248 endpoint unicast communication. Reliable multicast (e.g., 249 [RFC5740]) protocols are explicitly outside the scope of this 250 document. 252 Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that 253 communicate in a unicast fashion with multiple specific 254 endpoints can leverage the requirements in this document 255 provided they track state and follow the requirements for each 256 endpoint independently. I.e., if host A communicates with 257 addresses B and C, A needs to use independent time-based loss 258 detector instances for traffic sent to B and C. 260 (S.4) There are cases where state is shared across connections 261 or flows (e.g., [RFC2140], [RFC3124]). State pertaining to 262 time-based loss detection is often discussed as sharable. 263 These situations raise issues that the simple flow-oriented 264 time-based loss detection mechanism discussed in this document 265 does not consider (e.g., how long to preserve state between 266 connections). Therefore, while the general principles given 267 in Section 4 are likely applicable, sharing time-based loss 268 detection information across flows is outside the scope of 269 this document. 271 4 Requirements 273 We now list the requirements that apply when designing primary or 274 last resort time-based loss detection mechanisms. For historical 275 reasons and ease of exposition, we refer to the time between sending 276 a packet and determining the packet has been lost due to lack of 277 delivery confirmation as the "retransmission timeout" or "RTO". 278 After the RTO passes without delivery confirmation, the sender may 279 safely assume the packet is lost. However, as discussed above, the 280 detected loss need not be repaired (i.e., the loss could be detected 281 only for congestion control and not reliability purposes). 283 (1) As we note above, loss detection happens when a sender does not 284 receive delivery confirmation within some expected period of 285 time. In the absence of any knowledge about the latency of a 286 path, the initial RTO MUST be conservatively set to no less than 287 1 second. 289 Correctness is of the utmost importance when transmitting into a 290 network with unknown properties because: 292 - Premature loss detection can trigger spurious retransmits that 293 could cause issues when a network is already congested. 295 - Premature loss detection can needlessly cause congestion 296 control to dramatically lower the sender's allowed 297 transmission rate---especially since the rate is already 298 likely low at this stage of the communication. Recovering 299 from such a rate change can taken a relatively long time. 301 - Finally, as discussed below, sometimes using time-based 302 loss detection and retransmissions can cause ambiguities in 303 assessing the latency of a network path. Therefore, it is 304 especially important for the first latency sample to be free 305 of ambiguities such that there is a baseline for the remainder 306 of the communication. 308 The specific constant (1 second) comes from the analysis of 309 Internet RTTs found in Appendix A of [RFC6298]. 311 (2) We now specify four requirements that pertain to setting 312 an expected time interval for delivery confirmation. 314 Often measuring the time required for delivery confirmation is 315 framed as assessing the "round-trip time (RTT)" of the network 316 path. The RTT is the minimum amount of time required to receive 317 delivery confirmation and also often follows protocol behavior 318 whereby acknowledgments are generated quickly after data 319 arrives. For instance, this is the case for the RTO used by TCP 320 [RFC6298] and SCTP [RFC4960]. However, this is somewhat 321 mis-leading and the expected latency is better framed as the 322 "feedback time" (FT). In other words, the expectation is not 323 always simply a network property, but can include additional 324 time before a sender should reasonably expect a response. 326 For instance, consider a UDP-based DNS request from a client to 327 a recursive resolver [RFC1035]. When the request can be served 328 from the resolver's cache the FT likely well approximates the 329 network RTT between the client and resolver. However, on a 330 cache miss the resolver will request the needed information from 331 one or more authoritative DNS servers, which will non-trivially 332 increase the FT compared to the network RTT between the client 333 and resolver. 335 Therefore, we express the requirements in terms of FT. Again, 336 for ease of exposition we use "RTO" to indicate the interval 337 between a packet transmission and the decision the packet has 338 been lost---regardless of whether the packet will be 339 retransmitted. 341 (a) The RTO SHOULD be set based on multiple observations of the 342 FT when available. 344 In other words, the RTO should represent an empirically- 345 derived reasonable amount of time that the sender should 346 wait for delivery confirmation before deciding the given 347 data is lost. Network paths are inherently dynamic and 348 therefore it is crucial to incorporate multiple recent FT 349 samples in the RTO to take into account the delay variation 350 across time. 352 For example, TCP's RTO [RFC6298] would satisfy this 353 requirement due to its use of an exponentially-weighted 354 moving average (EWMA) to combine multiple FT samples into a 355 "smoothed RTT". In the name of conservativeness, TCP goes 356 further to also include an explicit variance term when 357 computing the RTO. 359 While multiple FT samples are crucial for capturing the 360 delay dynamics of a path, we explicitly do not tightly 361 specify the process---including the number of FT samples to 362 use and how/when to age samples out of the RTO 363 calculation---as the particulars could depend on the 364 situation and/or goals of each specific loss detector. 366 Finally, FT samples come from packet exchanges between 367 peers. We encourage protocol designers---especially for new 368 protocols---to strive to ensure the feedback is not easily 369 spoofable by on- or off-path attackers such that they can 370 perturb a host's notion of the FT. Ideally, all messages 371 would be cryptographically secure, but given that this is 372 not always possible---especially in legacy protocols---using 373 a healthy amount of randomness in the packets is encouraged. 375 (b) FT observations SHOULD be taken and incorporated into the 376 RTO at least once per RTT or as frequently as data is 377 exchanged in cases where that happens less frequently than 378 once per RTT. 380 Internet measurements show that taking only a single FT 381 sample per TCP connection results in a relatively poorly 382 performing RTO mechanism [AP99], hence this requirement that 383 the FT be sampled continuously throughout the lifetime of 384 communication. 386 As an example, TCP takes an FT sample roughly once per RTT, 387 or if using the timestamp option [RFC7323] on each 388 acknowledgment arrival. [AP99] shows that both these 389 approaches result in roughly equivalent performance for the 390 RTO estimator. 392 (c) FT observations MAY be taken from non-data exchanges. 394 Some protocols use non-data exchanges for various 395 reasons---e.g., keepalives, heartbeats, control messages. 396 To the extent that the latency of these exchanges mirrors 397 data exchange, they can be leveraged to take FT samples 398 within the RTO mechanism. Such samples can help protocols 399 keep their RTO accurate during lulls in data transmission. 400 However, given that these messages may not be subject to the 401 same delays as data transmission, we do not take a general 402 view on whether this is useful or not. 404 (d) An RTO mechanism MUST NOT use ambiguous FT samples. 406 Assume two copies of some packet X are transmitted at times 407 t0 and t1 and then at time t2 the sender receives 408 confirmation that X in fact arrived. In some cases, it is 409 not clear which copy of X triggered the confirmation and 410 hence the actual FT is either t2-t1 or t2-t0, but which is a 411 mystery. Therefore, in this situation an implementation 412 MUST NOT use either version of the FT sample and hence not 413 update the RTO (as discussed in [KP87,RFC6298]). 415 There are cases where two copies of some data are 416 transmitted in a way whereby the sender can tell which is 417 being acknowledged by an incoming ACK. E.g., TCP's 418 timestamp option [RFC7323] allows for packets to be 419 uniquely identified and hence avoid the ambiguity. In such 420 cases there is no ambiguity and the resulting samples can 421 update the RTO. 423 (3) Loss detected by the RTO mechanism MUST be taken as an 424 indication of network congestion and the sending rate adapted 425 using a standard mechanism (e.g., TCP collapses the congestion 426 window to one packet [RFC5681]). 428 This ensures network safety. 430 An exception to this rule is if an IETF standardized mechanism 431 determines that a particular loss is due to a non-congestion 432 event (e.g., packet corruption). In such a case a congestion 433 control action is not required. Additionally, congestion 434 control actions taken based on time-based loss detection could 435 be reversed when a standard mechanism post-facto determines that 436 the cause of the loss was not congestion (e.g., [RFC5682]). 438 (4) Each time the RTO is used to detect a loss, the value of the RTO 439 MUST be exponentially backed off such that the next firing 440 requires a longer interval. The backoff SHOULD be removed after 441 either (a) the subsequent successful transmission of 442 non-retransmitted data, or (b) an RTO passes without detecting 443 additional losses. The former will generally be quicker. The 444 latter covers cases where loss is detected, but not repaired. 446 A maximum value MAY be placed on the RTO. The maximum RTO MUST 447 NOT be less than 60 seconds (as specified in [RFC6298]). 449 This ensures network safety. 451 As with guideline (3), an exception to this rule exists if an 452 IETF standardized mechanism determines that a particular loss is 453 not due to congestion. 455 5 Discussion 457 We note that research has shown the tension between the 458 responsiveness and correctness of time-based loss detection seems to 459 be a fundamental tradeoff in the context of TCP [AP99]. That is, 460 making the RTO more aggressive (e.g., via changing TCP's 461 exponentially weighted moving average (EWMA) gains, lowering the 462 minimum RTO, etc.) can reduce the time required to detect actual 463 loss. However, at the same time, such aggressiveness leads to more 464 cases of mistakenly declaring packets lost that ultimately arrived 465 at the receiver. Therefore, being as aggressive as the requirements 466 given in the previous section allow in any particular situation may 467 not be the best course of action because detecting loss---even if 468 falsely---carries a requirement to invoke a congestion response 469 which will ultimately reduce the transmission rate. 471 While the tradeoff between responsiveness and correctness seems 472 fundamental, the tradeoff can be made less relevant if the sender 473 can detect and recover from mistaken loss detection. Several 474 mechanisms have been proposed for this purpose, such as Eifel 475 [RFC3522], F-RTO [RFC5682] and DSACK [RFC2883,RFC3708]. Using such 476 mechanisms may allow a data originator to tip towards being more 477 responsive without incurring (as much of) the attendant costs of 478 mistakenly declaring packets to be lost. 480 Also, note that, in addition to the experiments discussed in [AP99], 481 the Linux TCP implementation has been using various non-standard RTO 482 mechanisms for many years seemingly without large-scale problems 483 (e.g., using different EWMA gains than specified in [RFC6298]). 484 Further, a number of TCP implementations use a steady-state minimum 485 RTO that is less than the 1 second specified in [RFC6298]. While 486 the implication of these deviations from the standard may be more 487 spurious retransmits (per [AP99]), we are aware of no large-scale 488 network safety issues caused by this change to the minimum RTO. 489 This informs the guidelines in the last section (e.g., there is no 490 minimum RTO specified). 492 Finally, we note that while allowing implementations to be more 493 aggressive could in fact increase the number of needless 494 retransmissions, the above requirements fail safe in that they 495 insist on exponential backoff and a transmission rate reduction. 496 Therefore, providing implementers more latitude than they have 497 traditionally been given in IETF specifications of RTO mechanisms 498 does not somehow open the flood gates to aggressive behavior. Since 499 there is a downside to being aggressive, the incentives for proper 500 behavior are retained in the mechanism. 502 6 Security Considerations 504 This document does not alter the security properties of time-based 505 loss detection mechanisms. See [RFC6298] for a discussion of these 506 within the context of TCP. 508 7 IANA Considerations 510 This document has no IANA considerations. 512 Acknowledgments 514 This document benefits from years of discussions with Ethan Blanton, 515 Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the 516 members of the TCPM and TCP-IMPL working groups. Ran Atkinson, 517 Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley 518 Eddy, Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja 519 Kuhlewind, Nicolas Kuhn, Jonathan Looney and Michael Scharf provided 520 useful comments on previous versions of this document. 522 Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 528 2119 Key Words", RFC 8174, May 2017. 530 Informative References 532 [AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path 533 Properties", Proceedings of the ACM SIGCOMM Technical Symposium, 534 September 1999. 536 [CCDJ20] Cheng, Y., N. Cardwell, N. Dukkipati, P. Jha, "RACK: a 537 time-based fast loss detection algorithm for TCP", 538 Internet-Draft draft-ietf-tcpm-rack-08.txt (work in progress), 539 March 2020. 541 [DCCM13] Dukkipati, N., N. Cardwell, Y. Cheng, M. Mathis, "Tail Loss 542 Probe (TLP): An Algorithm for Fast Recovery of Tail Losses", 543 Internet-Draft draft-dukkipati-tcpm-tcp-loss-probe-01.txt (work 544 in progress), February 2013. 546 [IS20] Iyengar, I., I. Swett, "QUIC Loss Detection and Congestion 547 Control", Internet-Draft 548 draft-ietf-quic-recovery-27.txt (work in progress), March 2020. 550 [Jac88] Jacobson, V., "Congestion Avoidance and Control", ACM 551 SIGCOMM, August 1988. 553 [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 554 Estimates in Reliable Transport Protocols", SIGCOMM 87. 556 [RFC1034] Mockapetris, P. "Domain Names - Concepts and Facilities", 557 RFC 1034, November 1987. 559 [RFC1035] Mockapetris, P. "Domain Names - Implementation and 560 Specification", RFC 1035, November 1987. 562 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 563 Selective Acknowledgment Options", RFC 2018, October 1996. 565 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 566 April 1997. 568 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 569 Extension to the Selective Acknowledgement (SACK) Option for 570 TCP", RFC 2883, July 2000. 572 [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC 573 3124, June 2001. 575 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 576 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 577 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 579 [RFC3522] Ludwig, R., M. Meyer, "The Eifel Detection Algorithm for 580 TCP", RFC 3522, april 2003. 582 [RFC3708] Blanton, E., M. Allman, "Using TCP Duplicate Selective 583 Acknowledgement (DSACKs) and Stream Control Transmission 584 Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) 585 to Detect Spurious Retransmissions", RFC 3708, February 2004. 587 [RFC4960] Stweart, R., "Stream Control Transmission Protocol", RFC 588 4960, September 2007. 590 [RFC5681] Allman, M., V. Paxson, E. Blanton, "TCP Congestion 591 Control", RFC 5681, September 2009. 593 [RFC5682] Sarolahti, P., M. Kojo, K. Yamamoto, M. Hata, "Forward 594 RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious 595 Retransmission Timeouts with TCP", RFC 5682, September 2009. 597 [RFC5740] Adamson, B., C. Bormann, M. Handley, J. Macker, 598 "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", 599 RFC 5740, November 2009. 601 [RFC6182] Ford, A., C. Raiciu, M. Handley, S. Barre, J. Iyengar, 602 "Architectural Guidelines for Multipath TCP Development", March 603 2011, RFC 6182. 605 [RFC6298] Paxson, V., M. Allman, H.K. Chu, M. Sargent, "Computing 606 TCP's Retransmission Timer", June 2011, RFC 6298. 608 [RFC6675] Blanton, E., M. Allman, L. Wang, I. Jarvinen, M. Kojo, 609 Y. Nishida, "A Conservative Loss Recovery Algorithm Based on 610 Selective Acknowledgment (SACK) for TCP", August 2012, RFC 6675. 612 [RFC7323] Borman D., B. Braden, V. Jacobson, R. Scheffenegger, "TCP 613 Extensions for High Performance", September 2014, RFC 7323. 615 Authors' Addresses 617 Mark Allman 618 International Computer Science Institute 619 1947 Center St. Suite 600 620 Berkeley, CA 94704 622 EMail: mallman@icir.org 623 http://www.icir.org/mallman