<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY I-D.ietf-tcpm-rack SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-rack.xml"> <!ENTITY I-D.dukkipati-tcpm-tcp-loss-probe SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.dukkipati-tcpm-tcp-loss-probe.xml"> <!ENTITY I-D.ietf-quic-recovery SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-quic-recovery.xml"> <!ENTITY RFC1034 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"> <!ENTITY RFC1035 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"> <!ENTITY RFC2018 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2018.xml"> <!ENTITY RFC2140 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2140.xml"> <!ENTITY RFC2883 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2883.xml"> <!ENTITY RFC3124 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3124.xml"> <!ENTITY RFC3261 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"> <!ENTITY RFC3522 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3522.xml"> <!ENTITY RFC3708 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3708.xml"> <!ENTITY RFC4960 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"> <!ENTITY RFC5681 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"> <!ENTITY RFC5682 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5682.xml"> <!ENTITY RFC5740 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5740.xml"> <!ENTITY RFC6182 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6182.xml"> <!ENTITY RFC6298 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6298.xml"> <!ENTITY RFC6675 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6675.xml"> <!ENTITY RFC7323 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"> ]>"rfc2629-xhtml.ent"> <rfcsubmissionType="IETF"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-tcpm-rto-consider-17" number="8961" submissionType="IETF" category="bcp"ipr="trust200902"> <!-- Generated by id2xml 1.5.0 on 2020-08-06T21:02:19Z --> <?rfc strict="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc text-list-symbols="-"?> <?rfc toc="yes"?>consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3"> <front> <title abbrev="Requirements for Time-Based LossDetecti">RequirementsDetection">Requirements for Time-Based Loss Detection</title> <seriesInfo name="RFC" value="8961"/> <seriesInfo name="BCP" value="233"/> <author initials="M." surname="Allman" fullname="Mark Allman"> <organization abbrev="ICSI">International Computer Science Institute</organization><address><postal><street>1947 Center St.<address> <postal> <street>2150 Shattuck Ave., Suite600</street> <city>Berkeley</city><region>CA</region><code>94704</code>1100</street> <city>Berkeley</city> <region>CA</region> <country>United States of America</country> <code>94704</code> </postal> <email>mallman@icir.org</email><uri>http://www.icir.org/mallman</uri><uri>https://www.icir.org/mallman</uri> </address> </author> <date year="2020"month="August"/> <workgroup>Internet Engineering Task Force</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><t>Manymonth="November"/> <area>Transport</area> <workgroup>TCPM</workgroup> <keyword>retransmission timeout</keyword> <keyword>packet loss</keyword> <keyword>loss detection</keyword> <keyword>requirements</keyword> <abstract> <t>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 andtimeliness and thereforetimeliness; 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 eachsituation.</t></abstract>situation.</t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="sect-1"><section title="Terminology" anchor="sect-1.1"><t> 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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <t> 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 pathproperties---e.g.,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.</t> <t> 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) dynamicallyvaryvarying 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 <xreftarget="RFC5681"/>.target="RFC5681" format="default"/>. While this stance is not always correct, as a general assumption it has historically served us well <xreftarget="Jac88"/>.target="Jac88" format="default"/>. As we discuss further insection 2,<xref target="sect-2"/>, the guidelines in this document should be viewed as a general default for unicast communication across best-effort networks and not asoptimal---oroptimal -- or evenapplicable---forapplicable -- for all situations.</t> <t> 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:<list style="format (%d)"></t> <ol type="(%d)"> <li> <t>Ensuring reliable datadelivery. <list style="empty"><t>Thisdelivery</t> <t>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.</t></list></t></t> </li> <li> <t> Congestioncontrol. <list style="empty"><t>control </t> <t> 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.</t></list></t> </list></t> </li> </ol> <t> Various mechanisms are used to detect losses in a packet stream.OftenOften, 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 robustmechanismsmechanisms, we cannot place ultimate faith in receiving suchacknowledgments,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 deliveryconfirmationconfirmation, the sender concludes the data was lost intransit. Thetransit.</t> <t>The specifics of time-based loss detection schemes represent a tradeoff between correctness and responsiveness. In otherwordswords, we wish to simultaneously:</t><t><list style="symbols"><t>wait<ul spacing="normal"> <li>wait long enough to ensure the detection of loss is correct,and</t> <t>minimizeand</li> <li>minimize the amount of delay we impose on applications (before repairing loss) and the network (before we reduce thecongestion).</t> </list> </t>congestion).</li> </ul> <t> Serving both of these goals isdifficultdifficult, as they pull in opposite directions <xreftarget="AP99"/>.target="AP99" format="default"/>. By not waiting long enough to accurately determine a packet has beenlostlost, we may provide a needed retransmission in a timelymanner,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 beenlostlost, we cannot repair losses in a timely manner and we risk prolonging network congestion.</t> <t> Many protocols andapplications---suchapplications -- such as TCP <xreftarget="RFC6298"/>,target="RFC6298" format="default"/>, SCTP <xreftarget="RFC4960"/>,target="RFC4960" format="default"/>, and SIP <xreftarget="RFC3261"/>---usetarget="RFC3261" format="default"/> -- 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 <xreftarget="AP99"/>.target="AP99" format="default"/>. Therefore, in this document we outline a set ofhigh-levelhigh-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.</t> <section anchor="sect-1.1" numbered="true" toc="default"> <name>Terminology</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle="Context" anchor="sect-2"><t>anchor="sect-2" numbered="true" toc="default"> <name>Context</name> <t> 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,algorithmsalgorithms, and systems that meet these requirements. Within the IETF standardsprocessprocess, we have derived many time-based loss detection schemes without the benefitfromof some over-arching requirementsdocument---becausedocument -- 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.</t> <t> 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 insection 4<xref target="sect-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,deviationsdeviations, 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 asaone-size-fits-all guidance that is optimal in all cases.</t> <t> 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:</t><t><list style="symbols"><t>This<ul spacing="normal"> <li>This document does not update or obsolete any existing RFC. These previousspecifications---whilespecifications -- while generally consistent with the requirements in thisdocument---reflectdocument -- reflect communityconsensusconsensus, and this document does not change thatconsensus.</t> <t>Theconsensus.</li> <li>The requirements in this document are meant to provide for network safety and, as such,SHOULD<bcp14>SHOULD</bcp14> be used by all future time-based loss detectionmechanisms.</t> <t>Themechanisms.</li> <li>The requirements in this document may not be appropriate in allcases and,cases; therefore, deviations and variants may be necessary in the future (hence the"SHOULD""<bcp14>SHOULD</bcp14>" in the last bullet). However, inconsistenciesMUST<bcp14>MUST</bcp14> be (a) explained and (b) gatherconsensus.</t> </list> </t>consensus.</li> </ul> </section> <sectiontitle="Scope" anchor="sect-3"><t>anchor="sect-3" numbered="true" toc="default"> <name>Scope</name> <t> 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 inSection 4:</t> <t><list style="hanging" hangIndent="6"> <t hangText="(S.1)">While<xref target="sect-4"/>:</t> <ol type="(S.%d)" spacing="normal" indent="6"> <li>While there are a bevy of uses for timers inprotocols---fromprotocols -- from rate-based pacing to connection failure detection andbeyond---thisbeyond -- this document is focused only on lossdetection.</t> <t hangText="(S.2)">detection.</li> <li> <t> The requirements for time-based loss detection mechanisms in this document are for the primary or "last resort" loss detectionmechanismmechanism, whether the mechanism is the sole loss repair strategy or works in concert with other mechanisms.<list style="empty"><t>While</t> <t> While a straightforward time-based loss detector is sufficient for simple protocols like DNS <xreftarget="RFC1034"/>,<xref target="RFC1035"/>,target="RFC1034" format="default"/> <xref target="RFC1035" format="default"/>, 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 <xreftarget="RFC2018"/>,<xref target="RFC4960"/>,<xref target="RFC6675"/>.target="RFC2018" format="default"/> <xref target="RFC4960" format="default"/> <xref target="RFC6675" format="default"/>. 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---asbecause, as we discuss inSection 1---only<xref target="sect-1"/>, only the passage of time can ultimately be relied upon to detect loss. In other words,ultimatelywe ultimately cannot count on acknowledgments to arrive at the data sender to indicate which packets never arrived at the receiver. In cases such asthesethese, we need a time-based loss detector tofunctionsfunction as a "lastresort".</t>resort". </t> <t>Also,note,note that some recent proposals have incorporated time as a component of advanced loss detectionmethods---eithermethods either as an aggressive first loss detector in certain situations or in conjunction with endpoint state sharing <xreftarget="I-D.dukkipati-tcpm-tcp-loss-probe"/>,<xref target="I-D.ietf-tcpm-rack"/>,<xref target="I-D.ietf-quic-recovery"/>.target="I-D.dukkipati-tcpm-tcp-loss-probe" format="default"/> <xref target="I-D.ietf-tcpm-rack" format="default"/> <xref target="I-D.ietf-quic-recovery" format="default"/>. 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 tolast resortlast-resort loss detection. However, we expect that many of the requirements can serve as useful guidelines for more aggressivenon-last resort timers, as well.</t></list></t> <t hangText="(S.3)">non-last-resort timers as well.</t> </li> <li> <t> The requirements in this document apply only to endpoint-to-endpoint unicast communication. Reliable multicast (e.g., <xreftarget="RFC5740"/>)target="RFC5740" format="default"/>) protocols are explicitly outside the scope of this document.<list style="empty"><t>Protocols</t> <t>Protocols such as SCTP <xreftarget="RFC4960"/>target="RFC4960" format="default"/> andMP-TCPMultipath TCP (MP-TCP) <xreftarget="RFC6182"/>target="RFC6182" format="default"/> 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.I.e.,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 andC.</t></list></t> <t hangText="(S.4)">C.</t> </li> <li> There are cases where state is shared across connections or flows (e.g., <xreftarget="RFC2140"/>,target="RFC2140" format="default"/> and <xreftarget="RFC3124"/>).target="RFC3124" format="default"/>). 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 <xreftarget="sect-4"/>target="sect-4" format="default"/> are likely applicable, sharing time-based loss detection information across flows is outside the scope of this document.</t> </list> </t></li> </ol> </section> <sectiontitle="Requirements" anchor="sect-4"><t>anchor="sect-4" numbered="true" toc="default"> <name>Requirements</name> <t> We now list the requirements that apply when designing primary orlast resortlast-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).<list style="format (%d)"></t> <ol spacing="normal" type="(%d)"> <li> <t>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 RTOMUST<bcp14>MUST</bcp14> be conservatively set to no less than 1 second.<list style="empty"></t> <t>Correctness is of the utmost importance when transmitting into a network with unknown properties because:<list style="symbols"> <t>Premature</t> <ul spacing="normal"> <li>Premature loss detection can trigger spurious retransmits that could cause issues when a network is alreadycongested.</t> <t>Prematurecongested.</li> <li>Premature loss detection can needlessly cause congestion control to dramatically lower the sender's allowed transmissionrate---especiallyrate, especially since the rate is already likely low at this stage of the communication. Recovering from such a rate change cantakentake a relatively longtime.</t> <t>Finally,time.</li> <li>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 thecommunication.</t> </list></t> <t>Thecommunication.</li> </ul> <t> The specific constant (1 second) comes from the analysis of InternetRTTsround-trip times (RTTs) found inAppendix A of<xreftarget="RFC6298"/>.</t> </list></t>target="RFC6298" sectionFormat="of" section="A"/>.</t> </li> <li> <t> We now specify four requirements that pertain to setting an expected time interval for delivery confirmation.<list style="empty"> <t>Often</t> <t> Often, measuring the time required for delivery confirmation is framed as assessing the"round-trip time (RTT)"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 <xreftarget="RFC6298"/>target="RFC6298" format="default"/> and SCTP <xreftarget="RFC4960"/>.target="RFC4960" format="default"/>. However, this is somewhatmis-leadingmisleading, and the expected latency is better framed as the "feedback time" (FT). In other words, the expectation is not always simply a networkproperty, butproperty; it can include additional time before a sender should reasonably expect a response. </t> <t>For instance, consider a UDP-based DNS request from a client to a recursive resolver <xreftarget="RFC1035"/>.target="RFC1035" format="default"/>. When the request can be served from the resolver'scachecache, theFTfeedback time (FT) likely well approximates the network RTT between the client and resolver. However, on a cachemissmiss, 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.</t> <t>Therefore, we express the requirements in terms of FT. Again, for ease ofexpositionexposition, we use "RTO" to indicate the interval between a packet transmission and the decision that the packet has beenlost---regardlesslost, regardless of whether the packet will be retransmitted.</t></list> <list style="format (%c)"><ol spacing="normal" type="(%c)"> <li> <t>The RTOSHOULD<bcp14>SHOULD</bcp14> be set based on multiple observations of the FT when available.<list style="empty"></t> <t>In other words, the RTO should represent anempirically-derivedempirically derived reasonable amount of time that the sender should wait for delivery confirmation before deciding the given data is lost. Network paths are inherentlydynamic and thereforedynamic; therefore, it is crucial to incorporate multiple recent FT samples in the RTO to take into account the delay variation across time.</t> <t>For example, TCP's RTO <xreftarget="RFC6298"/>target="RFC6298" format="default"/> would satisfy this requirement due to its use of anexponentially-weightedexponentially 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.</t> <t>While multiple FT samples are crucial for capturing the delay dynamics of a path, we explicitly do not tightly specify theprocess---includingprocess -- including the number of FT samples to use and how/when to age samples out of the RTOcalculation---ascalculation -- as the particulars could depend on the situation and/or goals of each specific loss detector.</t> <t>Finally, FT samples come from packet exchanges between peers. We encourage protocoldesigners---especiallydesigners -- especially for newprotocols---toprotocols -- 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 alwayspossible---especiallypossible -- especially in legacyprotocols---usingprotocols -- using a healthy amount of randomness in the packets is encouraged.</t></list></t></li> <li> <t>FT observationsSHOULD<bcp14>SHOULD</bcp14> 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.<list style="empty"></t> <t>Internet measurements show that taking only a single FT sample per TCP connection results in a relatively poorly performing RTO mechanism <xreftarget="AP99"/>,target="AP99" format="default"/>, hence this requirement that the FT be sampled continuously throughout the lifetime of communication.</t> <t>As an example, TCP takes an FT sample roughly once per RTT,oror, if using the timestamp option <xreftarget="RFC7323"/>target="RFC7323" format="default"/>, on each acknowledgment arrival. <xreftarget="AP99"/>target="AP99" format="default"/> shows that both these approaches result in roughly equivalent performance for the RTO estimator.</t></list></t></li> <li> <t>FT observationsMAY<bcp14>MAY</bcp14> be taken from non-data exchanges.<list style="empty"></t> <t>Some protocols use non-data exchanges for variousreasons---e.g.,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.</t></list></t></li> <li> <t>An RTO mechanismMUST NOT<bcp14>MUST NOT</bcp14> use ambiguous FT samples.<list style="empty"></t> <t>Assume two copies of some packet X are transmitted at times t0 andt1 and thent1. Then, at timet2t2, the sender receives confirmation that X in fact arrived. In some cases, it is not clear which copy of X triggered theconfirmation and henceconfirmation; hence, the actual FT is either t2-t1 or t2-t0, but which is a mystery. Therefore, in thissituationsituation, an implementationMUST NOT<bcp14>MUST NOT</bcp14> use either version of the FT sample and hence not update the RTO (as discussed in <xreftarget="KP87"/>,<xref target="RFC6298"/>).</t>target="KP87" format="default"/> and <xref target="RFC6298" format="default"/>).</t> <t>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.E.g.,For example, TCP's timestamp option <xreftarget="RFC7323"/>target="RFC7323" format="default"/> allows for packets to be uniquely identified and hence avoid the ambiguity. In suchcasescases, there is no ambiguity and the resulting samples can update the RTO.</t></list></t> </list></t></li> </ol> </li> <li> <t>Loss detected by the RTO mechanismMUST<bcp14>MUST</bcp14> 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 <xreftarget="RFC5681"/>). <list style="empty">target="RFC5681" format="default"/>). </t> <t>This ensures network safety.</t> <t>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 acasecase, a congestion control action is not required. Additionally, congestion control actions taken based on time-based loss detection could be reversed when a standard mechanismpost-factopost facto determines that the cause of the loss was not congestion (e.g., <xreftarget="RFC5682"/>).</t> </list></t>target="RFC5682" format="default"/>).</t> </li> <li> <t>Each time the RTO is used to detect a loss, the value of the RTOMUST<bcp14>MUST</bcp14> be exponentially backed off such that the next firing requires a longer interval. The backoffSHOULD<bcp14>SHOULD</bcp14> 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 isdetected,detected but not repaired.<list style="empty"></t> <t>A maximum valueMAY<bcp14>MAY</bcp14> be placed on the RTO. The maximum RTOMUST NOT<bcp14>MUST NOT</bcp14> be less than 60 seconds (as specified in <xreftarget="RFC6298"/>).</t>target="RFC6298" format="default"/>).</t> <t>This ensures network safety.</t> <t>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.</t></list></t> </list></t></li> </ol> </section> <sectiontitle="Discussion" anchor="sect-5"><t>anchor="sect-5" numbered="true" toc="default"> <name>Discussion</name> <t> 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 <xreftarget="AP99"/>.target="AP99" format="default"/>. 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 detectingloss---evenloss, even iffalsely---carriesfalsely, carries a requirement to invoke a congestion responsewhichthat will ultimately reduce the transmission rate.</t> <t> 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 <xreftarget="RFC3522"/>, F-RTOtarget="RFC3522" format="default"/>, Forward RTO-Recovery (F-RTO) <xref target="RFC5682" format="default"/>, and Duplicate Selective Acknowledgement (DSACK) <xreftarget="RFC5682"/> and DSACKtarget="RFC2883" format="default"/> <xreftarget="RFC2883"/>,<xref target="RFC3708"/>.target="RFC3708" format="default"/>. 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.</t> <t> Also, note that, in addition to the experiments discussed in <xreftarget="AP99"/>,target="AP99" format="default"/>, 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 <xreftarget="RFC6298"/>).target="RFC6298" format="default"/>). Further, a number of TCP implementations use a steady-state minimum RTO that is less than the 1 second specified in <xreftarget="RFC6298"/>.target="RFC6298" format="default"/>. While the implication of these deviations from the standard may be more spurious retransmits (per <xreftarget="AP99"/>),target="AP99" format="default"/>), 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).</t> <t> Finally, we note that while allowing implementations to be more aggressive could in fact increase the number of needless retransmissions, the above requirements failsafesafely 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.</t> </section> <sectiontitle="Security Considerations" anchor="sect-6"><t>anchor="sect-6" numbered="true" toc="default"> <name>Security Considerations</name> <t> This document does not alter the security properties of time-based loss detection mechanisms. See <xreftarget="RFC6298"/>target="RFC6298" format="default"/> for a discussion of these within the context of TCP.</t> </section> <sectiontitle="IANA Considerations" anchor="sect-7"><t>anchor="sect-7" numbered="true" toc="default"> <name>IANA Considerations</name> <t> This document has no IANAconsiderations.</t> </section> <section title="Acknowledgments" numbered="no" anchor="acknowledgments"><t> 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 TCP-IMPL working groups. Ran Atkinson, Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley Eddy, Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja Kuhlewind, Nicolas Kuhn, Jonathan Looney and Michael Scharf provided useful comments on previous versions of this document.</t>actions.</t> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC8174;<displayreference target="I-D.ietf-tcpm-rack" to="CCDJ20"/> <displayreference target="I-D.dukkipati-tcpm-tcp-loss-probe" to="DCCM13"/> <displayreference target="I-D.ietf-quic-recovery" to="IS20"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references><references title="Informative References"><references> <name>Informative References</name> <referenceanchor="AP99"><front>anchor="AP99"> <front> <title>On Estimating End-to-End Network Path Properties</title> <author initials="M." surname="Allman" fullname="M. Allman"> </author> <author initials="V." surname="Paxson" fullname="V. Paxson"> </author> <date month="September" year="1999"/> </front><seriesInfo name="Proceedings" value="of<refcontent>Proceedings of the ACM SIGCOMM TechnicalSymposium"/>Symposium</refcontent> </reference>&I-D.ietf-tcpm-rack; &I-D.dukkipati-tcpm-tcp-loss-probe; &I-D.ietf-quic-recovery;<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tcpm-rack.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.dukkipati-tcpm-tcp-loss-probe.xml"/> <referenceanchor="Jac88"><front> <title>Congestion Avoidanceanchor='I-D.ietf-quic-recovery'> <front> <title>QUIC Loss Detection and Congestion Control</title> <author initials='J' surname='Iyengar' fullname='Jana Iyengar' role='editor'> <organization /> </author> <author initials='I' surname='Swett' fullname='Ian Swett' role='editor'> <organization /> </author> <date month='October' day='20' year='2020' /> </front> <seriesInfo name='Internet-Draft' value='draft-ietf-quic-recovery-32' /> </reference> <reference anchor="Jac88"> <front> <title>Congestion avoidance and control</title> <author initials="V." surname="Jacobson" fullname="V. Jacobson"> </author> <date month="August" year="1988"/> </front> <refcontent>ACM SIGCOMM</refcontent> <seriesInfoname="ACM" value="SIGCOMM"/>name="DOI" value="10.1145/52325.52356"/> </reference> <referenceanchor="KP87"><front>anchor="KP87"> <front> <title>Improving Round-Trip Time Estimates in Reliable Transport Protocols</title> <author initials="P." surname="Karn" fullname="P.Karn"></author>Karn"/> <author initials="C." surname="Partridge" fullname="C.Partridge"></author> <date/>Partridge"/> </front><seriesInfo name="SIGCOMM" value="87"/><refcontent>SIGCOMM 87</refcontent> </reference>&RFC1034; &RFC1035; &RFC2018; &RFC2140; &RFC2883; &RFC3124; &RFC3261; &RFC3522; &RFC3708; &RFC4960; &RFC5681; &RFC5682; &RFC5740; &RFC6182; &RFC6298; &RFC6675; &RFC7323;<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2018.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2140.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2883.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3124.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3522.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3708.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5682.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5740.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6182.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6298.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6675.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/> </references> </references> <section numbered="false" anchor="acknowledgments" toc="default"> <name>Acknowledgments</name> <t> This document benefits from years of discussions with <contact fullname="Ethan Blanton"/>, <contact fullname="Sally Floyd"/>, <contact fullname="Jana Iyengar"/>, <contact fullname="Shawn Ostermann"/>, <contact fullname="Vern Paxson"/>, and the members of the TCPM and TCPIMPL Working Groups. <contact fullname="Ran Atkinson"/>, <contact fullname="Yuchung Cheng"/>, <contact fullname="David Black"/>, <contact fullname="Stewart Bryant"/>, <contact fullname="Martin Duke"/>, <contact fullname="Wesley Eddy"/>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Rahul Arvind Jadhav"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Nicolas Kuhn"/>, <contact fullname="Jonathan Looney"/>, and <contact fullname="Michael Scharf"/> provided useful comments on previous draft versions of this document.</t> </section> </back> </rfc>