idnits 2.17.1 draft-ietf-tcpm-rto-consider-14.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]), 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 (May 13, 2020) is 1442 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) == Missing Reference: 'RFC5681' is mentioned on line 377, but not defined == Unused Reference: 'RFC3940' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC4340' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'RFC6582' is defined on line 540, but no explicit reference was found in the text == 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 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 4 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-14.txt May 13, 2020 4 Intended Status: Best Current Practice 5 Expires: November 13, 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 November 13, 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", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in BCP 14, RFC 2119 65 [RFC2119]. 67 1 Introduction 69 Loss detection is a crucial activity for many protocols and 70 applications and is generally undertaken for two major reasons: 72 (1) Ensuring reliable data delivery. 74 This requires a data sender to develop an understanding of 75 which transmitted packets have not arrived at the receiver. 76 This knowledge allows the sender to retransmit missing data. 78 (2) Congestion control. 80 Packet loss is often taken as an indication that the sender 81 is transmitting too fast and is overwhelming some portion of 82 the network path. Data senders can therefore use loss to 83 trigger transmission rate reductions. 85 Various mechanisms are used to detect losses in a packet stream. 86 Often we use continuous or periodic acknowledgments from the 87 recipient to inform the sender's notion of which pieces of data are 88 missing. However, despite our best intentions and most robust 89 mechanisms we cannot place ultimate faith in receiving such 90 acknowledgments, but can only truly depend on the passage of time. 91 Therefore, our ultimate backstop to ensuring that we detect all loss 92 is a timeout. That is, the sender sets some expectation for how 93 long to wait for confirmation of delivery for a given piece of data. 94 When this time period passes without delivery confirmation the 95 sender concludes the data was lost in transit. 97 The specifics of time-based loss detection schemes represent a 98 tradeoff between correctness and responsiveness. In other words we 99 wish to simultaneously: 101 - wait long enough to ensure the detection of loss is correct, and 103 - minimize the amount of delay we impose on applications (before 104 repairing loss) and the network (before we reduce the 105 congestion). 107 Serving both of these goals is difficult as they pull in opposite 108 directions [AP99]. By not waiting long enough to accurately 109 determine a packet has been lost we risk sending unnecessary 110 ("spurious") retransmissions and needlessly lowering the 111 transmission rate. By waiting long enough that we are unambiguously 112 certain a packet has been lost we cannot repair losses in a timely 113 manner and we risk prolonging network congestion. 115 Many protocols and applications use their own time-based loss 116 detection mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP 117 [RFC3261]). At this point, our experience leads to a recognition 118 that often specific tweaks that deviate from standardized time-based 119 loss detectors do not materially impact network safety. Therefore, 120 in this document we outline a set of high-level protocol-agnostic 121 requirements for time-based loss detection. The intent is to 122 provide a safe foundation on which implementations have the 123 flexibility to instantiate mechanisms that best realize their 124 specific goals. 126 2 Context 128 This document is different from from the way we ideally like to 129 engineer systems. Usually, we strive to understand high-level 130 requirements as a starting point. We then methodically engineer 131 specific protocols, algorithms and systems that meet these 132 requirements. Within the standards process we have derived many 133 time-based loss detection schemes without benefit from some 134 over-arching requirements document---because we had no idea how to 135 write such a document! Therefore, we made the best specific 136 decisions we could in response to specific needs. 138 At this point, however, the community's experience has matured to 139 the point where we can define a set of high-level requirements for 140 time-based loss detection schemes. We now understand how to 141 separate the strategies these mechanisms use that are crucial for 142 network safety from those small details that do not materially 143 impact network safety. However, adding a requirements umbrella to a 144 body of existing specifications is inherently messy and we run the 145 risk of creating inconsistencies with both past and future 146 mechanisms. The correct way to view this document is as the default 147 case. Specifically: 149 - This document does not update or obsolete any existing RFC. 150 These previous specifications---while generally consistent with 151 the requirements in this document---reflect community consensus 152 and this document does not change that consensus. 154 - The requirements in this document are meant to provide for 155 network safety and, as such, SHOULD be used by all time-based 156 loss detection mechanisms. 158 - The requirements in this document may not be appropriate in all 159 cases and, therefore, inconsistent deviations may be necessary 160 (hence the "SHOULD" in the last bullet). However, 161 inconsistencies MUST be (a) explained and (b) gather consensus. 163 3 Scope 165 The principles we outline in this document are protocol-agnostic and 166 widely applicable. We make the following scope statements about 167 the application of the requirements discussed in Section 4: 169 (S.1) The requirements in this document apply only to the primary or 170 last resort time-based loss detection. 172 While there are a bevy of uses for timers in protocols---from 173 rate-based pacing to connection failure detection and 174 beyond---these are outside the scope of this document. 176 (S.2) The requirements for time-based loss detection mechanisms in 177 this document are for the primary or "last resort" loss 178 detection mechanism whether the mechanism is the sole loss 179 repair strategy or works in concert with other mechanisms. 181 While a straightforward time-based loss detector is sufficient 182 for simple protocols like DNS [RFC1034,RFC1035], more complex 183 protocols often use more advanced loss detectors to aid 184 performance. For instance, TCP and SCTP have methods to 185 detect (and repair) loss based on explicit endpoint state 186 sharing [RFC2018,RFC4960,RFC6675]. Such mechanisms often 187 provide more timely and precise results than time-based loss 188 detectors. However, these mechanisms do not obviate the need 189 for a "retransmission timeout" or "RTO" because---as we 190 discuss in Section 1---only the passage of time can ultimately 191 be relied upon to detect loss. In cases such as these, the 192 time-based loss detector functions as a "last resort". 194 Also, note, that some recent proposals have incorporated time 195 as a component of advanced loss detection methods---either as 196 an aggressive first loss detector or in conjunction with 197 endpoint state sharing [DCCM13,CCDJ20,IS20]. Since these 198 timers are not used as "last resort" the requirements in this 199 document need not be directly used in these cases. However, 200 we expect that many of the requirements are useful for these 201 situations, as well. 203 (S.3) The requirements in this document apply only to endpoint-to- 204 endpoint unicast communication. Reliable multicast (e.g., 205 [RFC5740]) protocols are explicitly outside the scope of this 206 document. 208 Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that 209 communicate in a unicast fashion with multiple specific 210 endpoints can leverage the requirements in this document 211 provided they track state and follow the requirements for each 212 endpoint independently. I.e., if host A communicates with 213 addresses B and C, A needs to use independent time-based loss 214 detector instances for traffic sent to B and C. 216 (S.4) There are cases where state is shared across connections 217 or flows (e.g., [RFC2140], [RFC3124]). State pertaining to 218 time-based loss detection is often discussed as sharable. 219 These situations raise issues that the simple flow-oriented 220 time-based loss detection mechanism discussed in this document 221 does not consider (e.g., how long to preserve state between 222 connections). Therefore, while the general principles given 223 in Section 4 are likely applicable, sharing time-based loss 224 detection information across flows is outside the scope of 225 this document. 227 4 Requirements 229 We now list the requirements that apply when designing primary or 230 last resort time-based loss detection mechanisms. For historical 231 reasons and ease of exposition, we refer to the time between sending 232 a packet and determining the packet has been lost due to lack of 233 delivery confirmation as the "retransmission timeout" or "RTO". 234 After the RTO passes without delivery confirmation, the sender may 235 safely assume the packet is lost. However, as discussed above, the 236 detected loss need not be repaired (i.e., the loss could be detected 237 only for congestion control and not reliability purposes). 239 (1) As we note above, loss detection happens when a sender does not 240 receive delivery confirmation within an some expected period of 241 time. In the absence of any knowledge about the latency of a 242 path, the initial RTO MUST be conservatively set to no less than 243 1 second. 245 Correctness is of the utmost importance when transmitting into a 246 network with unknown properties because: 248 - Premature loss detection can trigger spurious retransmits that 249 could cause issues when a network is already congested. 251 - Premature loss detection can needlessly cause congestion 252 control to dramatically lower the sender's allowed 253 transmission rate---especially since the rate is already 254 likely low at this stage of the communication. Recovering 255 from such a rate change can taken a relatively long time. 257 - Finally, as discussed below, sometimes using time-based 258 loss detection and retransmissions can cause ambiguities in 259 assessing the latency of a network path. Therefore, it is 260 especially important for the first latency sample to be free 261 of ambiguities such that there is a baseline for the remainder 262 of the communication. 264 The specific constant (1 second) comes from the analysis of 265 Internet RTTs found in Appendix A of [RFC6298]. 267 (2) We now specify four requirements that pertain to setting 268 an expected time interval for delivery confirmation. 270 Often measuring the time required for delivery confirmation is 271 is framed as assessing the "round-trip time (RTT)" of the 272 network path as this is the minimum amount of time required to 273 receive delivery confirmation and also often follows protocol 274 behavior whereby acknowledgments are generated quickly after 275 data arrives. For instance, this is the case for the RTO used 276 by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat 277 mis-leading and the expected latency is better framed as the 278 "feedback time" (FT). In other words, the expectation is not 279 always simply a network property, but can include additional 280 time before a sender should reasonably expect a response. 282 For instance, consider a UDP-based DNS request from a client to 283 a recursive resolver. When the request can be served from the 284 resolver's cache the FT likely well approximates the network RTT 285 between the client and resolver. However, on a cache miss the 286 resolver will request the needed information from one or more 287 authoritative DNS servers, which will non-trivially increase the 288 FT compared to the network RTT between the client and resolver. 290 Therefore, we express the requirements in terms of FT. Again, 291 for ease of exposition we use "RTO" to indicate the interval 292 between a packet transmission and the decision the packet has 293 been lost---regardless of whether the packet will be 294 retransmitted. 296 (a) If/when available, the RTO SHOULD be set based on multiple 297 observations of the FT. 299 In other words, the RTO should represent an empirically- 300 derived reasonable amount of time that the sender should 301 wait for delivery confirmation before deciding the given 302 data is lost. Network paths are inherently dynamic and 303 therefore it is crucial to incorporate multiple FT samples 304 in the RTO to take into account the delay variation across 305 time. 307 For example, TCP's RTO [RFC6298] would satisfy this 308 requirement due to its use of an EWMA to combine multiple FT 309 samples into a "smoothed RTT". In the name of 310 conservativeness, TCP goes further to also include an 311 explicit variance term when computing the RTO. 313 (b) FT observations SHOULD be taken and incorporated into the 314 RTO at least once per RTT or as frequently as data is 315 exchanged in cases where that happens less frequently than 316 once per RTT. 318 Internet measurements show that taking only a single FT 319 sample per TCP connection results in a relatively poorly 320 performing RTO mechanism [AP99], hence this requirement that 321 the FT be sampled continuously throughout the lifetime of 322 communication. 324 As an example, TCP takes an FT sample roughly once per RTT, 325 or if using the timestamp option [RFC7323] on each 326 acknowledgment arrival. [AP99] shows that both these 327 approaches result in roughly equivalent performance for the 328 RTO estimator. 330 (c) FT observations MAY be taken from non-data exchanges. 332 Some protocols use keepalives, heartbeats or other messages 333 to exchange control information. To the extent that the 334 latency of these transactions mirrors data exchange, they 335 can be leveraged to take FT samples within the RTO 336 mechanism. Such samples can help protocols keep their RTO 337 accurate during lulls in data transmission. However, given 338 that these messages may not be subject to the same delays as 339 data transmission, we do not take a general view on whether 340 this is useful or not. 342 (d) An RTO mechanism MUST NOT use ambiguous FT samples. 344 Assume two copies of some segment X are transmitted at times 345 t0 and t1 and then at time t2 the sender receives 346 confirmation that X in fact arrived. In some cases, it is 347 not clear which copy of X triggered the confirmation and 348 hence the actual FT is either t2-t1 or t2-t0, but which is a 349 mystery. Therefore, in this situation an implementation 350 MUST use Karn's algorithm [KP87,RFC6298] and use neither 351 version of the FT sample and hence not update the RTO. 353 There are cases where two copies of some data are 354 transmitted in a way whereby the sender can tell which is 355 being acknowledged by an incoming ACK. E.g., TCP's 356 timestamp option [RFC7323] allows for segments to be 357 uniquely identified and hence avoid the ambiguity. In such 358 cases there is no ambiguity and the resulting samples can 359 update the RTO. 361 (3) Each time the RTO is used to detect a loss, the value of the RTO 362 MUST be exponentially backed off such that the next firing 363 requires a longer interval. The backoff SHOULD be removed after 364 either (a) the subsequent successful transmission of 365 non-retransmitted data, or (b) an RTO passes without detecting 366 additional losses. The former will generally be quicker. The 367 latter covers cases where loss is detected, but not repaired. 369 A maximum value MAY be placed on the RTO. The maximum RTO MUST 370 NOT be less than 60 seconds (as specified in [RFC6298]). 372 This ensures network safety. 374 (4) Loss detected by the RTO mechanism MUST be taken as an 375 indication of network congestion and the sending rate adapted 376 using a standard mechanism (e.g., TCP collapses the congestion 377 window to one segment [RFC5681]). 379 This ensures network safety. 381 An exception to this rule is if an IETF standardized mechanism 382 determines that a particular loss is due to a non-congestion 383 event (e.g., packet corruption). In such a case a congestion 384 control action is not required. Additionally, congestion 385 control actions taken based on time-based loss detection could 386 be reversed when a standard mechanism post-facto determines that 387 the cause of the loss was not congestion (e.g., [RFC5682]). 389 5 Discussion 391 We note that research has shown the tension between the 392 responsiveness and correctness of time-based loss detection seems to 393 be a fundamental tradeoff in the context of TCP [AP99]. That is, 394 making the RTO more aggressive (e.g., via changing TCP's 395 exponentially weighted moving average (EWMA) gains, lowering the 396 minimum RTO, etc.) can reduce the time required to detect actual 397 loss. However, at the same time, such aggressiveness leads to more 398 cases of mistakenly declaring packets lost that ultimately arrived 399 at the receiver. Therefore, being as aggressive as the requirements 400 given in the previous section allow in any particular situation may 401 not be the best course of action because detecting loss---even if 402 falsely---carries a requirement to invoke a congestion response 403 which will ultimately reduce the transmission rate. 405 While the tradeoff between responsiveness and correctness seems 406 fundamental, the tradeoff can be made less relevant if the sender 407 can detect and recover from mistaken loss detection. Several 408 mechanisms have been proposed for this purpose, such as Eifel 409 [RFC3522], F-RTO [RFC5682] and DSACK [RFC2883,RFC3708]. Using such 410 mechanisms may allow a data originator to tip towards being more 411 responsive without incurring (as much of) the attendant costs of 412 mistakenly declaring packets to be lost. 414 Also, note, that in addition to the experiments discussed in [AP99], 415 the Linux TCP implementation has been using various non-standard RTO 416 mechanisms for many years seemingly without large scale problems 417 (e.g., using different EWMA gains than specified in [RFC6298]). 418 Further, a number of implementations use a steady-state minimum RTO 419 that are less than the 1 second specified in [RFC6298] (which is 420 different from the initial RTO we specify in Section 4, Requirement 421 1). While the implication of these deviations from the standard may 422 be more spurious retransmits (per [AP99]), we are aware of no large 423 scale network safety issues caused by this change to the minimum 424 RTO. 426 Finally, we note that while allowing implementations to be more 427 aggressive could in fact increase the number of needless 428 retransmissions the above requirements fail safe in that they insist 429 on exponential backoff and a transmission rate reduction. 430 Therefore, providing implementers more latitude than they have 431 traditionally been given in IETF specifications of RTO mechanisms 432 does not somehow open the flood gates to aggressive behavior. Since 433 there is a downside to being aggressive, the incentives for proper 434 behavior are retained in the mechanism. 436 6 Security Considerations 438 This document does not alter the security properties of time-based 439 loss detection mechanisms. See [RFC6298] for a discussion of these 440 within the context of TCP. 442 7 IANA Considerations 444 This document has no IANA considerations. 446 Acknowledgments 448 This document benefits from years of discussions with Ethan Blanton, 449 Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the 450 members of the TCPM and TCP-IMPL working groups. Ran Atkinson, 451 Yuchung Cheng, David Black, Martin Duke, Gorry Fairhurst, Rahul 452 Arvind Jadhav, Mirja Kuhlewind, Nicolas Kuhn, Jonathan Looney and 453 Michael Scharf provided useful comments on previous versions of this 454 document. 456 Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 Informative References 463 [AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path 464 Properties", Proceedings of the ACM SIGCOMM Technical Symposium, 465 September 1999. 467 [CCDJ20] Cheng, Y., N. Cardwell, N. Dukkipati, P. Jha, "RACK: a 468 time-based fast loss detection algorithm for TCP", 469 Internet-Draft draft-ietf-tcpm-rack-08.txt (work in progress), 470 March 2020. 472 [DCCM13] Dukkipati, N., N. Cardwell, Y. Cheng, M. Mathis, "Tail Loss 473 Probe (TLP): An Algorithm for Fast Recovery of Tail Losses", 474 Internet-Draft draft-dukkipati-tcpm-tcp-loss-probe-01.txt (work 475 in progress), February 2013. 477 [IS20] Iyengar, I., I. Swett, "QUIC Loss Detection and Congestion 478 Control", Internet-Draft 479 draft-ietf-quic-recovery-27.txt (work in progress), March 2020. 481 [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 482 Estimates in Reliable Transport Protocols", SIGCOMM 87. 484 [RFC1034] Mockapetris, P. "Domain Names - Concepts and Facilities", 485 RFC 1034, November 1987. 487 [RFC1035] Mockapetris, P. "Domain Names - Implementation and 488 Specification", RFC 1035, November 1987. 490 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 491 Selective Acknowledgment Options", RFC 2018, October 1996. 493 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 494 April 1997. 496 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 497 Extension to the Selective Acknowledgement (SACK) Option for 498 TCP", RFC 2883, July 2000. 500 [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC 501 2134, June 2001. 503 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 504 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 505 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 507 [RFC3522] Ludwig, R., M. Meyer, "The Eifel Detection Algorithm for 508 TCP", RFC 3522, april 2003. 510 [RFC3708] Blanton, E., M. Allman, "Using TCP Duplicate Selective 511 Acknowledgement (DSACKs) and Stream Control Transmission 512 Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) 513 to Detect Spurious Retransmissions", RFC 3708, February 2004. 515 [RFC3940] Adamson, B., C. Bormann, M. Handley, J. Macker, 516 "Negative-acknowledgment (NACK)-Oriented Reliable Multicast 517 (NORM) Protocol", November 2004, RFC 3940. 519 [RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion 520 Control Protocol (DCCP)", March 2006, RFC 4340. 522 [RFC4960] Stweart, R., "Stream Control Transmission Protocol", RFC 523 4960, September 2007. 525 [RFC5682] Sarolahti, P., M. Kojo, K. Yamamoto, M. Hata, "Forward 526 RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious 527 Retransmission Timeouts with TCP", RFC 5682, September 2009. 529 [RFC5740] Adamson, B., C. Bormann, M. Handley, J. Macker, 530 "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", 531 November 2009, RFC 5740. 533 [RFC6182] Ford, A., C. Raiciu, M. Handley, S. Barre, J. Iyengar, 534 "Architectural Guidelines for Multipath TCP Development", March 535 2011, RFC 6182. 537 [RFC6298] Paxson, V., M. Allman, H.K. Chu, M. Sargent, "Computing 538 TCP's Retransmission Timer", June 2011, RFC 6298. 540 [RFC6582] Henderson, T., S. Floyd, A. Gurtov, Y. Nishida, "The 541 NewReno Modification to TCP's Fast Recovery Algorithm", April 542 2012, RFC 6582. 544 [RFC6675] Blanton, E., M. Allman, L. Wang, I. Jarvinen, M. Kojo, 545 Y. Nishida, "A Conservative Loss Recovery Algorithm Based on 546 Selective Acknowledgment (SACK) for TCP", August 2012, RFC 6675. 548 [RFC7323] Borman D., B. Braden, V. Jacobson, R. Scheffenegger, "TCP 549 Extensions for High Performance", September 2014, RFC 7323. 551 Authors' Addresses 553 Mark Allman 554 International Computer Science Institute 555 1947 Center St. Suite 600 556 Berkeley, CA 94704 558 EMail: mallman@icir.org 559 http://www.icir.org/mallman