diff options
Diffstat (limited to 'doc/rfc/rfc8961.txt')
| -rw-r--r-- | doc/rfc/rfc8961.txt | 672 |
1 files changed, 672 insertions, 0 deletions
diff --git a/doc/rfc/rfc8961.txt b/doc/rfc/rfc8961.txt new file mode 100644 index 0000000..85471c7 --- /dev/null +++ b/doc/rfc/rfc8961.txt @@ -0,0 +1,672 @@ + + + + +Internet Engineering Task Force (IETF) M. Allman +Request for Comments: 8961 ICSI +BCP: 233 November 2020 +Category: Best Current Practice +ISSN: 2070-1721 + + + Requirements for Time-Based Loss Detection + +Abstract + + Many protocols must detect packet loss for various reasons (e.g., to + ensure reliability using retransmissions or to understand the level + of congestion along a network path). While many mechanisms have been + designed to detect loss, ultimately, protocols can only count on the + passage of time without delivery confirmation to declare a packet + "lost". Each implementation of a time-based loss detection mechanism + represents a balance between correctness and timeliness; therefore, + no implementation suits all situations. This document provides high- + level requirements for time-based loss detectors appropriate for + general use in unicast communication across the Internet. Within the + requirements, implementations have latitude to define particulars + that best address each situation. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8961. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 1.1. Terminology + 2. Context + 3. Scope + 4. Requirements + 5. Discussion + 6. Security Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgments + Author's Address + +1. Introduction + + As a network of networks, the Internet consists of a large variety of + links and systems that support a wide variety of tasks and workloads. + The service provided by the network varies from best-effort delivery + among loosely connected components to highly predictable delivery + within controlled environments (e.g., between physically connected + nodes, within a tightly controlled data center). Each path through + the network has a set of path properties, e.g., available capacity, + delay, and packet loss. Given the range of networks that make up the + Internet, these properties range from largely static to highly + dynamic. + + This document provides guidelines for developing an understanding of + one path property: packet loss. In particular, we offer guidelines + for developing and implementing time-based loss detectors that have + been gradually learned over the last several decades. We focus on + the general case where the loss properties of a path are (a) unknown + a priori and (b) dynamically varying over time. Further, while there + are numerous root causes of packet loss, we leverage the conservative + notion that loss is an implicit indication of congestion [RFC5681]. + While this stance is not always correct, as a general assumption it + has historically served us well [Jac88]. As we discuss further in + Section 2, the guidelines in this document should be viewed as a + general default for unicast communication across best-effort networks + and not as optimal -- or even applicable -- for all situations. + + Given that packet loss is routine in best-effort networks, loss + detection is a crucial activity for many protocols and applications + and is generally undertaken for two major reasons: + + (1) Ensuring reliable data delivery + + This requires a data sender to develop an understanding of which + transmitted packets have not arrived at the receiver. This + knowledge allows the sender to retransmit missing data. + + (2) Congestion control + + As we mention above, packet loss is often taken as an implicit + indication that the sender is transmitting too fast and is + overwhelming some portion of the network path. Data senders can + therefore use loss to trigger transmission rate reductions. + + Various mechanisms are used to detect losses in a packet stream. + Often, we use continuous or periodic acknowledgments from the + recipient to inform the sender's notion of which pieces of data are + missing. However, despite our best intentions and most robust + mechanisms, we cannot place ultimate faith in receiving such + acknowledgments but can only truly depend on the passage of time. + Therefore, our ultimate backstop to ensuring that we detect all loss + is a timeout. That is, the sender sets some expectation for how long + to wait for confirmation of delivery for a given piece of data. When + this time period passes without delivery confirmation, the sender + concludes the data was lost in transit. + + The specifics of time-based loss detection schemes represent a + tradeoff between correctness and responsiveness. In other words, we + wish to simultaneously: + + * wait long enough to ensure the detection of loss is correct, and + + * minimize the amount of delay we impose on applications (before + repairing loss) and the network (before we reduce the congestion). + + Serving both of these goals is difficult, as they pull in opposite + directions [AP99]. By not waiting long enough to accurately + determine a packet has been lost, we may provide a needed + retransmission in a timely manner but risk both sending unnecessary + ("spurious") retransmissions and needlessly lowering the transmission + rate. By waiting long enough that we are unambiguously certain a + packet has been lost, we cannot repair losses in a timely manner and + we risk prolonging network congestion. + + Many protocols and applications -- such as TCP [RFC6298], SCTP + [RFC4960], and SIP [RFC3261] -- use their own time-based loss + detection mechanisms. At this point, our experience leads to a + recognition that often specific tweaks that deviate from standardized + time-based loss detectors do not materially impact network safety + with respect to congestion control [AP99]. Therefore, in this + document we outline a set of high-level, protocol-agnostic + requirements for time-based loss detection. The intent is to provide + a safe foundation on which implementations have the flexibility to + instantiate mechanisms that best realize their specific goals. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Context + + This document is different from the way we ideally like to engineer + systems. Usually, we strive to understand high-level requirements as + a starting point. We then methodically engineer specific protocols, + algorithms, and systems that meet these requirements. Within the + IETF standards process, we have derived many time-based loss + detection schemes without the benefit of some over-arching + requirements document -- because we had no idea how to write such a + document! Therefore, we made the best specific decisions we could in + response to specific needs. + + At this point, however, the community's experience has matured to the + point where we can define a set of general, high-level requirements + for time-based loss detection schemes. We now understand how to + separate the strategies these mechanisms use that are crucial for + network safety from those small details that do not materially impact + network safety. The requirements in this document may not be + appropriate in all cases. In particular, the guidelines in Section 4 + are concerned with the general case, but specific situations may + allow for more flexibility in terms of loss detection because + specific facets of the environment are known (e.g., when operating + over a single physical link or within a tightly controlled data + center). Therefore, variants, deviations, or wholly different time- + based loss detectors may be necessary or useful in some cases. The + correct way to view this document is as the default case and not as + one-size-fits-all guidance that is optimal in all cases. + + Adding a requirements umbrella to a body of existing specifications + is inherently messy and we run the risk of creating inconsistencies + with both past and future mechanisms. Therefore, we make the + following statements about the relationship of this document to past + and future specifications: + + * This document does not update or obsolete any existing RFC. These + previous specifications -- while generally consistent with the + requirements in this document -- reflect community consensus, and + this document does not change that consensus. + + * The requirements in this document are meant to provide for network + safety and, as such, SHOULD be used by all future time-based loss + detection mechanisms. + + * The requirements in this document may not be appropriate in all + cases; therefore, deviations and variants may be necessary in the + future (hence the "SHOULD" in the last bullet). However, + inconsistencies MUST be (a) explained and (b) gather consensus. + +3. Scope + + The principles we outline in this document are protocol-agnostic and + widely applicable. We make the following scope statements about the + application of the requirements discussed in Section 4: + + (S.1) While there are a bevy of uses for timers in protocols -- from + rate-based pacing to connection failure detection and beyond -- + this document is focused only on loss detection. + + (S.2) The requirements for time-based loss detection mechanisms in + this document are for the primary or "last resort" loss + detection mechanism, whether the mechanism is the sole loss + repair strategy or works in concert with other mechanisms. + + While a straightforward time-based loss detector is sufficient + for simple protocols like DNS [RFC1034] [RFC1035], more complex + protocols often use more advanced loss detectors to aid + performance. For instance, TCP and SCTP have methods to detect + (and repair) loss based on explicit endpoint state sharing + [RFC2018] [RFC4960] [RFC6675]. Such mechanisms often provide + more timely and precise loss detection than time-based loss + detectors. However, these mechanisms do not obviate the need + for a "retransmission timeout" or "RTO" because, as we discuss + in Section 1, only the passage of time can ultimately be relied + upon to detect loss. In other words, we ultimately cannot + count on acknowledgments to arrive at the data sender to + indicate which packets never arrived at the receiver. In cases + such as these, we need a time-based loss detector to function + as a "last resort". + + Also, note that some recent proposals have incorporated time as + a component of advanced loss detection methods either as an + aggressive first loss detector in certain situations or in + conjunction with endpoint state sharing [DCCM13] [CCDJ20] + [IS20]. While these mechanisms can aid timely loss recovery, + the protocol ultimately leans on another more conservative + timer to ensure reliability when these mechanisms break down. + The requirements in this document are only directly applicable + to last-resort loss detection. However, we expect that many of + the requirements can serve as useful guidelines for more + aggressive non-last-resort timers as well. + + (S.3) The requirements in this document apply only to endpoint-to- + endpoint unicast communication. Reliable multicast (e.g., + [RFC5740]) protocols are explicitly outside the scope of this + document. + + Protocols such as SCTP [RFC4960] and Multipath TCP (MP-TCP) + [RFC6182] that communicate in a unicast fashion with multiple + specific endpoints can leverage the requirements in this + document provided they track state and follow the requirements + for each endpoint independently. That is, if host A + communicates with addresses B and C, A needs to use independent + time-based loss detector instances for traffic sent to B and C. + + (S.4) There are cases where state is shared across connections or + flows (e.g., [RFC2140] and [RFC3124]). State pertaining to + time-based loss detection is often discussed as sharable. + These situations raise issues that the simple flow-oriented + time-based loss detection mechanism discussed in this document + does not consider (e.g., how long to preserve state between + connections). Therefore, while the general principles given in + Section 4 are likely applicable, sharing time-based loss + detection information across flows is outside the scope of this + document. + +4. Requirements + + We now list the requirements that apply when designing primary or + last-resort time-based loss detection mechanisms. For historical + reasons and ease of exposition, we refer to the time between sending + a packet and determining the packet has been lost due to lack of + delivery confirmation as the "retransmission timeout" or "RTO". + After the RTO passes without delivery confirmation, the sender may + safely assume the packet is lost. However, as discussed above, the + detected loss need not be repaired (i.e., the loss could be detected + only for congestion control and not reliability purposes). + + (1) As we note above, loss detection happens when a sender does not + receive delivery confirmation within some expected period of + time. In the absence of any knowledge about the latency of a + path, the initial RTO MUST be conservatively set to no less than + 1 second. + + Correctness is of the utmost importance when transmitting into a + network with unknown properties because: + + * Premature loss detection can trigger spurious retransmits + that could cause issues when a network is already congested. + + * Premature loss detection can needlessly cause congestion + control to dramatically lower the sender's allowed + transmission rate, especially since the rate is already + likely low at this stage of the communication. Recovering + from such a rate change can take a relatively long time. + + * Finally, as discussed below, sometimes using time-based loss + detection and retransmissions can cause ambiguities in + assessing the latency of a network path. Therefore, it is + especially important for the first latency sample to be free + of ambiguities such that there is a baseline for the + remainder of the communication. + + The specific constant (1 second) comes from the analysis of + Internet round-trip times (RTTs) found in Appendix A of + [RFC6298]. + + (2) We now specify four requirements that pertain to setting an + expected time interval for delivery confirmation. + + Often, measuring the time required for delivery confirmation is + framed as assessing the RTT of the network path. The RTT is the + minimum amount of time required to receive delivery confirmation + and also often follows protocol behavior whereby acknowledgments + are generated quickly after data arrives. For instance, this is + the case for the RTO used by TCP [RFC6298] and SCTP [RFC4960]. + However, this is somewhat misleading, and the expected latency + is better framed as the "feedback time" (FT). In other words, + the expectation is not always simply a network property; it can + include additional time before a sender should reasonably expect + a response. + + For instance, consider a UDP-based DNS request from a client to + a recursive resolver [RFC1035]. When the request can be served + from the resolver's cache, the feedback time (FT) likely well + approximates the network RTT between the client and resolver. + However, on a cache miss, the resolver will request the needed + information from one or more authoritative DNS servers, which + will non-trivially increase the FT compared to the network RTT + between the client and resolver. + + Therefore, we express the requirements in terms of FT. Again, + for ease of exposition, we use "RTO" to indicate the interval + between a packet transmission and the decision that the packet + has been lost, regardless of whether the packet will be + retransmitted. + + (a) The RTO SHOULD be set based on multiple observations of the + FT when available. + + In other words, the RTO should represent an empirically + derived reasonable amount of time that the sender should + wait for delivery confirmation before deciding the given + data is lost. Network paths are inherently dynamic; + therefore, it is crucial to incorporate multiple recent FT + samples in the RTO to take into account the delay variation + across time. + + For example, TCP's RTO [RFC6298] would satisfy this + requirement due to its use of an exponentially weighted + moving average (EWMA) to combine multiple FT samples into a + "smoothed RTT". In the name of conservativeness, TCP goes + further to also include an explicit variance term when + computing the RTO. + + While multiple FT samples are crucial for capturing the + delay dynamics of a path, we explicitly do not tightly + specify the process -- including the number of FT samples + to use and how/when to age samples out of the RTO + calculation -- as the particulars could depend on the + situation and/or goals of each specific loss detector. + + Finally, FT samples come from packet exchanges between + peers. We encourage protocol designers -- especially for + new protocols -- to strive to ensure the feedback is not + easily spoofable by on- or off-path attackers such that + they can perturb a host's notion of the FT. Ideally, all + messages would be cryptographically secure, but given that + this is not always possible -- especially in legacy + protocols -- using a healthy amount of randomness in the + packets is encouraged. + + (b) FT observations SHOULD be taken and incorporated into the + RTO at least once per RTT or as frequently as data is + exchanged in cases where that happens less frequently than + once per RTT. + + Internet measurements show that taking only a single FT + sample per TCP connection results in a relatively poorly + performing RTO mechanism [AP99], hence this requirement + that the FT be sampled continuously throughout the lifetime + of communication. + + As an example, TCP takes an FT sample roughly once per RTT, + or, if using the timestamp option [RFC7323], on each + acknowledgment arrival. [AP99] shows that both these + approaches result in roughly equivalent performance for the + RTO estimator. + + (c) FT observations MAY be taken from non-data exchanges. + + Some protocols use non-data exchanges for various reasons, + e.g., keepalives, heartbeats, and control messages. To the + extent that the latency of these exchanges mirrors data + exchange, they can be leveraged to take FT samples within + the RTO mechanism. Such samples can help protocols keep + their RTO accurate during lulls in data transmission. + However, given that these messages may not be subject to + the same delays as data transmission, we do not take a + general view on whether this is useful or not. + + (d) An RTO mechanism MUST NOT use ambiguous FT samples. + + Assume two copies of some packet X are transmitted at times + t0 and t1. Then, at time t2, the sender receives + confirmation that X in fact arrived. In some cases, it is + not clear which copy of X triggered the confirmation; + hence, the actual FT is either t2-t1 or t2-t0, but which is + a mystery. Therefore, in this situation, an implementation + MUST NOT use either version of the FT sample and hence not + update the RTO (as discussed in [KP87] and [RFC6298]). + + There are cases where two copies of some data are + transmitted in a way whereby the sender can tell which is + being acknowledged by an incoming ACK. For example, TCP's + timestamp option [RFC7323] allows for packets to be + uniquely identified and hence avoid the ambiguity. In such + cases, there is no ambiguity and the resulting samples can + update the RTO. + + (3) Loss detected by the RTO mechanism MUST be taken as an + indication of network congestion and the sending rate adapted + using a standard mechanism (e.g., TCP collapses the congestion + window to one packet [RFC5681]). + + This ensures network safety. + + An exception to this rule is if an IETF standardized mechanism + determines that a particular loss is due to a non-congestion + event (e.g., packet corruption). In such a case, a congestion + control action is not required. Additionally, congestion + control actions taken based on time-based loss detection could + be reversed when a standard mechanism post facto determines that + the cause of the loss was not congestion (e.g., [RFC5682]). + + (4) Each time the RTO is used to detect a loss, the value of the RTO + MUST be exponentially backed off such that the next firing + requires a longer interval. The backoff SHOULD be removed after + either (a) the subsequent successful transmission of non- + retransmitted data, or (b) an RTO passes without detecting + additional losses. The former will generally be quicker. The + latter covers cases where loss is detected but not repaired. + + A maximum value MAY be placed on the RTO. The maximum RTO MUST + NOT be less than 60 seconds (as specified in [RFC6298]). + + This ensures network safety. + + As with guideline (3), an exception to this rule exists if an + IETF standardized mechanism determines that a particular loss is + not due to congestion. + +5. Discussion + + We note that research has shown the tension between the + responsiveness and correctness of time-based loss detection seems to + be a fundamental tradeoff in the context of TCP [AP99]. That is, + making the RTO more aggressive (e.g., via changing TCP's + exponentially weighted moving average (EWMA) gains, lowering the + minimum RTO, etc.) can reduce the time required to detect actual + loss. However, at the same time, such aggressiveness leads to more + cases of mistakenly declaring packets lost that ultimately arrived at + the receiver. Therefore, being as aggressive as the requirements + given in the previous section allow in any particular situation may + not be the best course of action because detecting loss, even if + falsely, carries a requirement to invoke a congestion response that + will ultimately reduce the transmission rate. + + While the tradeoff between responsiveness and correctness seems + fundamental, the tradeoff can be made less relevant if the sender can + detect and recover from mistaken loss detection. Several mechanisms + have been proposed for this purpose, such as Eifel [RFC3522], Forward + RTO-Recovery (F-RTO) [RFC5682], and Duplicate Selective + Acknowledgement (DSACK) [RFC2883] [RFC3708]. Using such mechanisms + may allow a data originator to tip towards being more responsive + without incurring (as much of) the attendant costs of mistakenly + declaring packets to be lost. + + Also, note that, in addition to the experiments discussed in [AP99], + the Linux TCP implementation has been using various non-standard RTO + mechanisms for many years seemingly without large-scale problems + (e.g., using different EWMA gains than specified in [RFC6298]). + Further, a number of TCP implementations use a steady-state minimum + RTO that is less than the 1 second specified in [RFC6298]. While the + implication of these deviations from the standard may be more + spurious retransmits (per [AP99]), we are aware of no large-scale + network safety issues caused by this change to the minimum RTO. This + informs the guidelines in the last section (e.g., there is no minimum + RTO specified). + + Finally, we note that while allowing implementations to be more + aggressive could in fact increase the number of needless + retransmissions, the above requirements fail safely in that they + insist on exponential backoff and a transmission rate reduction. + Therefore, providing implementers more latitude than they have + traditionally been given in IETF specifications of RTO mechanisms + does not somehow open the flood gates to aggressive behavior. Since + there is a downside to being aggressive, the incentives for proper + behavior are retained in the mechanism. + +6. Security Considerations + + This document does not alter the security properties of time-based + loss detection mechanisms. See [RFC6298] for a discussion of these + within the context of TCP. + +7. IANA Considerations + + This document has no IANA actions. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +8.2. Informative References + + [AP99] Allman, M. and V. Paxson, "On Estimating End-to-End + Network Path Properties", Proceedings of the ACM SIGCOMM + Technical Symposium, September 1999. + + [CCDJ20] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The + RACK-TLP loss detection algorithm for TCP", Work in + Progress, Internet-Draft, draft-ietf-tcpm-rack-13, 2 + November 2020, + <https://tools.ietf.org/html/draft-ietf-tcpm-rack-13>. + + [DCCM13] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, + "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of + Tail Losses", Work in Progress, Internet-Draft, draft- + dukkipati-tcpm-tcp-loss-probe-01, 25 February 2013, + <https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp- + loss-probe-01>. + + [IS20] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection + and Congestion Control", Work in Progress, Internet-Draft, + draft-ietf-quic-recovery-32, 20 October 2020, + <https://tools.ietf.org/html/draft-ietf-quic-recovery-32>. + + [Jac88] Jacobson, V., "Congestion avoidance and control", ACM + SIGCOMM, DOI 10.1145/52325.52356, August 1988, + <https://doi.org/10.1145/52325.52356>. + + [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time + Estimates in Reliable Transport Protocols", SIGCOMM 87. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + <https://www.rfc-editor.org/info/rfc1034>. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <https://www.rfc-editor.org/info/rfc1035>. + + [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP + Selective Acknowledgment Options", RFC 2018, + DOI 10.17487/RFC2018, October 1996, + <https://www.rfc-editor.org/info/rfc2018>. + + [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, + DOI 10.17487/RFC2140, April 1997, + <https://www.rfc-editor.org/info/rfc2140>. + + [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An + Extension to the Selective Acknowledgement (SACK) Option + for TCP", RFC 2883, DOI 10.17487/RFC2883, July 2000, + <https://www.rfc-editor.org/info/rfc2883>. + + [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", + RFC 3124, DOI 10.17487/RFC3124, June 2001, + <https://www.rfc-editor.org/info/rfc3124>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm + for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, + <https://www.rfc-editor.org/info/rfc3522>. + + [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective + Acknowledgement (DSACKs) and Stream Control Transmission + Protocol (SCTP) Duplicate Transmission Sequence Numbers + (TSNs) to Detect Spurious Retransmissions", RFC 3708, + DOI 10.17487/RFC3708, February 2004, + <https://www.rfc-editor.org/info/rfc3708>. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <https://www.rfc-editor.org/info/rfc4960>. + + [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion + Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, + <https://www.rfc-editor.org/info/rfc5681>. + + [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, + "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting + Spurious Retransmission Timeouts with TCP", RFC 5682, + DOI 10.17487/RFC5682, September 2009, + <https://www.rfc-editor.org/info/rfc5682>. + + [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, + "NACK-Oriented Reliable Multicast (NORM) Transport + Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, + <https://www.rfc-editor.org/info/rfc5740>. + + [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. + Iyengar, "Architectural Guidelines for Multipath TCP + Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, + <https://www.rfc-editor.org/info/rfc6182>. + + [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, + "Computing TCP's Retransmission Timer", RFC 6298, + DOI 10.17487/RFC6298, June 2011, + <https://www.rfc-editor.org/info/rfc6298>. + + [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., + and Y. Nishida, "A Conservative Loss Recovery Algorithm + Based on Selective Acknowledgment (SACK) for TCP", + RFC 6675, DOI 10.17487/RFC6675, August 2012, + <https://www.rfc-editor.org/info/rfc6675>. + + [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. + Scheffenegger, Ed., "TCP Extensions for High Performance", + RFC 7323, DOI 10.17487/RFC7323, September 2014, + <https://www.rfc-editor.org/info/rfc7323>. + +Acknowledgments + + This document benefits from years of discussions with Ethan Blanton, + Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the + members of the TCPM and TCPIMPL Working Groups. Ran Atkinson, + Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley Eddy, + Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja + Kühlewind, Nicolas Kuhn, Jonathan Looney, and Michael Scharf provided + useful comments on previous draft versions of this document. + +Author's Address + + Mark Allman + International Computer Science Institute + 2150 Shattuck Ave., Suite 1100 + Berkeley, CA 94704 + United States of America + + Email: mallman@icir.org + URI: https://www.icir.org/mallman |