rfc8961xml2.original.xml   rfc8961.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.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/publ
ic/rfc/bibxml3/reference.I-D.dukkipati-tcpm-tcp-loss-probe.xml">
<!ENTITY I-D.ietf-quic-recovery SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibx
ml3/reference.I-D.ietf-quic-recovery.xml">
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.1034.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.1035.xml">
<!ENTITY RFC2018 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2018.xml">
<!ENTITY RFC2140 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2140.xml">
<!ENTITY RFC2883 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2883.xml">
<!ENTITY RFC3124 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3124.xml">
<!ENTITY RFC3261 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3261.xml">
<!ENTITY RFC3522 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3522.xml">
<!ENTITY RFC3708 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3708.xml">
<!ENTITY RFC4960 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4960.xml">
<!ENTITY RFC5681 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5681.xml">
<!ENTITY RFC5682 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5682.xml">
<!ENTITY RFC5740 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5740.xml">
<!ENTITY RFC6182 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6182.xml">
<!ENTITY RFC6298 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6298.xml">
<!ENTITY RFC6675 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6675.xml">
<!ENTITY RFC7323 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7323.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-tcpm-rto-consider-17" category="b
cp" 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"?>
<front>
<title abbrev="Requirements for Time-Based Loss Detecti">Requirements for
Time-Based Loss Detection</title>
<author initials="M." surname="Allman" fullname="Mark Allman">
<organization abbrev="ICSI">International Computer Science Institute</org
anization>
<address><postal><street>1947 Center St. Suite 600</street>
<city>Berkeley</city><region>CA</region><code>94704</code>
</postal>
<email>mallman@icir.org</email>
<uri>http://www.icir.org/mallman</uri>
</address>
</author>
<date year="2020" month="August"/> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<workgroup>Internet Engineering Task Force</workgroup> docName="draft-ietf-tcpm-rto-consider-17" number="8961"
submissionType="IETF" category="bcp" consensus="true" ipr="trust200902"
obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true"
tocInclude="true" version="3">
<!-- [rfced] Please insert any keywords (beyond those that appear in the title) <front>
for use on https://www.rfc-editor.org/search. --> <title abbrev="Requirements for Time-Based Loss Detection">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>2150 Shattuck Ave., Suite 1100</street>
<city>Berkeley</city>
<region>CA</region>
<country>United States of America</country>
<code>94704</code>
</postal>
<email>mallman@icir.org</email>
<uri>https://www.icir.org/mallman</uri>
</address>
</author>
<date year="2020" month="November"/>
<area>Transport</area>
<workgroup>TCPM</workgroup>
<keyword>example</keyword> <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 <abstract>
<t>Many protocols must detect packet loss for various reasons
(e.g., to ensure reliability using retransmissions or to understand the (e.g., to ensure reliability using retransmissions or to understand the
level of congestion along a network path). While many mechanisms have level of congestion along a network path). While many mechanisms have
been designed to detect loss, ultimately, protocols can only count on the been designed to detect loss, ultimately, protocols can only count on the
passage of time without delivery confirmation to declare a packet "lost". passage of time without delivery confirmation to declare a packet "lost".
Each implementation of a time-based loss detection mechanism represents a Each implementation of a time-based loss detection mechanism represents a
balance between correctness and timeliness and therefore no implementation balance between correctness and timeliness; therefore, no implementation
suits all situations. This document provides high-level requirements for suits all situations. This document provides high-level requirements for
time-based loss detectors appropriate for general use in unicast time-based loss detectors appropriate for general use in unicast
communication across the Internet. Within the requirements, communication across the Internet. Within the requirements,
implementations have latitude to define particulars that best address each implementations have latitude to define particulars that best address each
situation.</t></abstract> situation.</t>
</front> </abstract>
</front>
<middle> <middle>
<section title="Introduction" anchor="sect-1"><section title="Terminology <section anchor="sect-1" numbered="true" toc="default">
" anchor="sect-1.1"><t> <name>Introduction</name>
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>
<t> <t>
As a network of networks, the Internet consists of a large variety As a network of networks, the Internet consists of a large variety
of links and systems that support a wide variety of tasks and of links and systems that support a wide variety of tasks and
workloads. The service provided by the network varies from workloads. The service provided by the network varies from
best-effort delivery among loosely connected components to highly best-effort delivery among loosely connected components to highly
predictable delivery within controlled environments (e.g., between predictable delivery within controlled environments (e.g., between
physically connected nodes, within a tightly controlled data physically connected nodes, within a tightly controlled data
center). Each path through the network has a set of path center). Each path through the network has a set of path
properties---e.g., available capacity, delay, packet loss. Given properties, e.g., available capacity, delay, and packet loss. Given
the range of networks that make up the Internet, these properties the range of networks that make up the Internet, these properties
range from largely static to highly dynamic.</t> range from largely static to highly dynamic.</t>
<t>
<t> This document provides guidelines for developing an understanding of one
This document provides guidelines for developing an understanding of path property: packet loss. In particular, we offer guidelines for
one path property: packet loss. In particular, we offer guidelines developing and implementing time-based loss detectors that have been
for developing and implementing time-based loss detectors that have gradually learned over the last several decades. We focus on the general
been gradually learned over the last several decades. We focus on case where the loss properties of a path are (a) unknown a priori and (b)
the general case where the loss properties of a path are (a) unknown dynamically varying over time. Further, while there are numerous root
a priori and (b) dynamically vary over time. Further, while there causes of packet loss, we leverage the conservative notion that loss is an
are numerous root causes of packet loss, we leverage the implicit indication of congestion <xref target="RFC5681"
conservative notion that loss is an implicit indication of format="default"/>. While this stance is not always correct, as a general
congestion <xref target="RFC5681"/>. While this stance is not always correct assumption it has historically served us well <xref target="Jac88"
, as a format="default"/>. As we discuss further in <xref target="sect-2"/>, the
general assumption it has historically served us well <xref target="Jac88"/>. guidelines in this document should be viewed as a general default for
As unicast communication across best-effort networks and not as optimal -- or
we discuss further in section 2, the guidelines in this document even applicable -- for all situations.</t>
should be viewed as a general default for unicast communication <t>
across best-effort networks and not as optimal---or even
applicable---for all situations.</t>
<t>
Given that packet loss is routine in best-effort networks, loss Given that packet loss is routine in best-effort networks, loss
detection is a crucial activity for many protocols and applications detection is a crucial activity for many protocols and applications
and is generally undertaken for two major reasons: and is generally undertaken for two major reasons:
<list style="format (%d)"> </t>
<ol type="(%d)">
<t>Ensuring reliable data delivery. <li>
<t>Ensuring reliable data delivery</t>
<list style="empty"><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> Congestion control.
<list style="empty"><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>
<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>
</li>
<li>
<t> Congestion 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>
</li>
</ol>
<t>
Various mechanisms are used to detect losses in a packet stream. Various mechanisms are used to detect losses in a packet stream.
Often we use continuous or periodic acknowledgments from the Often, we use continuous or periodic acknowledgments from the
recipient to inform the sender's notion of which pieces of data are recipient to inform the sender's notion of which pieces of data are
missing. However, despite our best intentions and most robust missing. However, despite our best intentions and most robust
mechanisms we cannot place ultimate faith in receiving such mechanisms, we cannot place ultimate faith in receiving such
acknowledgments, but can only truly depend on the passage of time. acknowledgments but can only truly depend on the passage of time.
Therefore, our ultimate backstop to ensuring that we detect all loss Therefore, our ultimate backstop to ensuring that we detect all loss
is a timeout. That is, the sender sets some expectation for how 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. long to wait for confirmation of delivery for a given piece of data.
When this time period passes without delivery confirmation the When this time period passes without delivery confirmation, the
sender concludes the data was lost in transit. sender concludes the data was lost in transit.</t>
The specifics of time-based loss detection schemes represent a
tradeoff between correctness and responsiveness. In other words we
wish to simultaneously:</t>
<t><list style="symbols"><t>wait long enough to ensure the detection of l
oss is correct, and</t>
<t>minimize the amount of delay we impose on applications (before <t>The specifics of time-based loss detection schemes represent a
tradeoff between correctness and responsiveness. In other words, we
wish to simultaneously:</t>
<ul spacing="normal">
<li>wait long enough to ensure the detection of loss is correct,
and</li>
<li>minimize the amount of delay we impose on applications (before
repairing loss) and the network (before we reduce the repairing loss) and the network (before we reduce the
congestion).</t> congestion).</li>
</ul>
</list> <t>
</t> Serving both of these goals is difficult, as they pull in opposite
directions <xref target="AP99" format="default"/>. By not waiting long
<t> enough to accurately determine a packet has been lost, we may provide a
Serving both of these goals is difficult as they pull in opposite needed retransmission in a timely manner but risk both sending unnecessary
directions <xref target="AP99"/>. By not waiting long enough to accurately ("spurious") retransmissions and needlessly lowering the transmission rate.
determine a packet has been lost we may provide a needed By waiting long enough that we are unambiguously certain a packet has been
retransmission in a timely manner, but risk sending unnecessary lost, we cannot repair losses in a timely manner and we risk prolonging
("spurious") retransmissions and needlessly lowering the network congestion.</t>
transmission rate. By waiting long enough that we are unambiguously <t>
certain a packet has been lost we cannot repair losses in a timely Many protocols and applications -- such as TCP <xref target="RFC6298"
manner and we risk prolonging network congestion.</t> format="default"/>, SCTP <xref target="RFC4960" format="default"/>, and SIP
<xref target="RFC3261"
<t> format="default"/> -- use their own time-based loss detection mechanisms.
Many protocols and applications---such as TCP <xref target="RFC6298"/>, SCTP At
<xref target="RFC4960"/>, SIP <xref target="RFC3261"/>---use their own time-b this point, our experience leads to a recognition that often specific
ased loss detection tweaks that deviate from standardized time-based loss detectors do not
mechanisms. At this point, our experience leads to a recognition materially impact network safety with respect to congestion control <xref
that often specific tweaks that deviate from standardized time-based target="AP99" format="default"/>. Therefore, in this document we outline a
loss detectors do not materially impact network safety with respect set of high-level, protocol-agnostic requirements for time-based loss
to congestion control <xref target="AP99"/>. Therefore, in this document we detection. The intent is to provide a safe foundation on which
outline a set of high-level protocol-agnostic requirements for implementations have the flexibility to instantiate mechanisms that best
time-based loss detection. The intent is to provide a safe realize their specific goals.</t>
foundation on which implementations have the flexibility to
instantiate mechanisms that best realize their specific goals.</t>
</section> <section anchor="sect-1.1" numbered="true" toc="default">
<name>Terminology</name>
</section> <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&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section>
<section title="Context" anchor="sect-2"><t> </section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Context</name>
<t>
This document is different from the way we ideally like to engineer This document is different from the way we ideally like to engineer
systems. Usually, we strive to understand high-level requirements systems. Usually, we strive to understand high-level requirements
as a starting point. We then methodically engineer specific as a starting point. We then methodically engineer specific
protocols, algorithms and systems that meet these requirements. protocols, algorithms, and systems that meet these requirements.
Within the IETF standards process we have derived many time-based Within the IETF standards process, we have derived many time-based
loss detection schemes without benefit from some over-arching loss detection schemes without the benefit of some over-arching
requirements document---because we had no idea how to write such a requirements document -- because we had no idea how to write such a
document! Therefore, we made the best specific decisions we could document! Therefore, we made the best specific decisions we could
in response to specific needs.</t> in response to specific needs.</t>
<t>
<t>
At this point, however, the community's experience has matured to At this point, however, the community's experience has matured to
the point where we can define a set of general, high-level the point where we can define a set of general, high-level
requirements for time-based loss detection schemes. We now requirements for time-based loss detection schemes. We now
understand how to separate the strategies these mechanisms use that understand how to separate the strategies these mechanisms use that
are crucial for network safety from those small details that do not are crucial for network safety from those small details that do not
materially impact network safety. The requirements in this document materially impact network safety. The requirements in this document
may not be appropriate in all cases. In particular, the guidelines may not be appropriate in all cases. In particular, the guidelines
in section 4 are concerned with the general case, but specific in <xref target="sect-4"/> are concerned with the general case, but
specific
situations may allow for more flexibility in terms of loss detection situations may allow for more flexibility in terms of loss detection
because specific facets of the environment are known (e.g., when because specific facets of the environment are known (e.g., when
operating over a single physical link or within a tightly controlled operating over a single physical link or within a tightly controlled
data center). Therefore, variants, deviations or wholly different data center). Therefore, variants, deviations, or wholly different
time-based loss detectors may be necessary or useful in some cases. 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 The correct way to view this document is as the default case and not
as a one-size-fits-all that is optimal in all cases.</t> as one-size-fits-all guidance that is optimal in all cases.</t>
<t>
<t>
Adding a requirements umbrella to a body of existing specifications Adding a requirements umbrella to a body of existing specifications
is inherently messy and we run the risk of creating inconsistencies is inherently messy and we run the risk of creating inconsistencies
with both past and future mechanisms. Therefore, we make the with both past and future mechanisms. Therefore, we make the
following statements about the relationship of this document to past following statements about the relationship of this document to past
and future specifications:</t> and future specifications:</t>
<ul spacing="normal">
<t><list style="symbols"><t>This document does not update or obsolete any <li>This document does not update or obsolete any existing RFC. These
existing RFC. previous specifications -- while generally consistent with the
These previous specifications---while generally consistent with requirements in this document -- reflect community consensus, and this
the requirements in this document---reflect community consensus document does not change that consensus.</li>
and this document does not change that consensus.</t> <li>The requirements in this document are meant to provide for network
safety and, as such, <bcp14>SHOULD</bcp14> be used by all future
<t>The requirements in this document are meant to provide for time-based loss detection mechanisms.</li>
network safety and, as such, SHOULD be used by all future <li>The requirements in this document may not be appropriate in all
time-based loss detection mechanisms.</t> cases; therefore, deviations and variants may be necessary in the
future (hence the "<bcp14>SHOULD</bcp14>" in the last bullet).
<t>The requirements in this document may not be appropriate in all However, inconsistencies <bcp14>MUST</bcp14> be (a) explained and (b)
cases and, therefore, deviations and variants may be necessary gather consensus.</li>
in the future (hence the "SHOULD" in the last bullet). However, </ul>
inconsistencies MUST be (a) explained and (b) gather consensus.</t> </section>
<section anchor="sect-3" numbered="true" toc="default">
</list> <name>Scope</name>
</t> <t>
</section>
<section title="Scope" anchor="sect-3"><t>
The principles we outline in this document are protocol-agnostic and The principles we outline in this document are protocol-agnostic and
widely applicable. We make the following scope statements about widely applicable. We make the following scope statements about
the application of the requirements discussed in Section 4:</t> the application of the requirements discussed in <xref
target="sect-4"/>:</t>
<t><list style="hanging" hangIndent="6"> <ol type="(S.%d)" spacing="normal" indent="6">
<li>While there are a bevy of uses for timers in
<t hangText="(S.1)">While there are a bevy of uses for timers in protocols -- from rate-based pacing to connection failure detection
protocols---from rate-based pacing to connection failure detection and beyond -- this document is focused only on loss
and beyond---this document is focused only on loss detection.</t> detection.</li>
<li>
<t hangText="(S.2)"> The requirements for time-based loss detection <t> The requirements for time-based loss detection
mechanisms in this document are for the primary or "last resort" mechanisms in this document are for the primary or "last resort"
loss detection mechanism whether the mechanism is the sole loss loss detection mechanism, whether the mechanism is the sole loss
repair strategy or works in concert with other mechanisms. repair strategy or works in concert with other mechanisms.
<list style="empty"><t>While a straightforward time-based loss
detector is sufficient for simple protocols like DNS <xref
target="RFC1034"/>,<xref target="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 <xref
target="RFC2018"/>,<xref target="RFC4960"/>,<xref target="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, ultimately we 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 functions as a "last
resort".</t>
<t>Also, note, that some recent proposals have incorporated time as </t>
a component of advanced loss detection methods---either as an <t>
aggressive first loss detector in certain situations or in While a straightforward time-based loss detector is sufficient
conjunction with endpoint state sharing <xref for simple protocols like DNS <xref target="RFC1034"
target="I-D.dukkipati-tcpm-tcp-loss-probe"/>,<xref format="default"/> <xref target="RFC1035" format="default"/>, more
target="I-D.ietf-tcpm-rack"/>,<xref complex protocols often use more advanced loss detectors to aid
target="I-D.ietf-quic-recovery"/>. While these mechanisms can aid performance. For instance, TCP and SCTP have methods to detect
timely loss recovery, the protocol ultimately leans on another more (and repair) loss based on explicit endpoint state sharing <xref
conservative timer to ensure reliability when these mechanisms break target="RFC2018" format="default"/> <xref target="RFC4960"
down. The requirements in this document are only directly format="default"/> <xref target="RFC6675" format="default"/>.
applicable to last resort loss detection. However, we expect that Such mechanisms often provide more timely and precise loss
many of the requirements can serve as useful guidelines for more detection than time-based loss detectors. However, these
aggressive non-last resort timers, as well.</t></list></t> mechanisms do not obviate the need for a "retransmission timeout"
or "RTO" because, as we discuss in <xref target="sect-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".
</t>
<t>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 <xref
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 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.</t>
<t hangText="(S.3)"> The requirements in this document apply only to </li>
endpoint-to-endpoint unicast communication. Reliable multicast <li>
(e.g., <xref target="RFC5740"/>) protocols are explicitly outside <t> The requirements in this document apply only to
the scope of this document. endpoint-to-endpoint unicast communication. Reliable multicast
(e.g., <xref target="RFC5740" format="default"/>) protocols are
explicitly outside
the scope of this document.
<list style="empty"><t>Protocols such as SCTP <xref </t>
target="RFC4960"/> and MP-TCP <xref target="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.
I.e., 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.</t></list></t>
<t hangText="(S.4)"> There are cases where state is shared across <t>Protocols such as SCTP <xref target="RFC4960"
connections or flows (e.g., <xref target="RFC2140"/>, <xref format="default"/> and Multipath TCP (MP-TCP) <xref
target="RFC3124"/>). State pertaining to time-based loss detection target="RFC6182"
is often discussed as sharable. These situations raise issues that format="default"/> that communicate in a unicast fashion with
the simple flow-oriented time-based loss detection mechanism multiple specific endpoints can leverage the requirements in this
discussed in this document does not consider (e.g., how long to document provided they track state and follow the requirements for
preserve state between connections). Therefore, while the general each endpoint independently. That is, if host A communicates with
principles given in <xref target="sect-4"/> are likely applicable, addresses B and C, A needs to use independent time-based loss
sharing time-based loss detection information across flows is detector instances for traffic sent to B and C.</t>
outside the scope of this document.
</t>
</list> </li>
</t> <li> There are cases where state is shared across connections or flows
(e.g., <xref target="RFC2140" format="default"/> and <xref
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 <xref target="sect-4" format="default"/> are
likely applicable, sharing time-based loss detection information
across flows is outside the scope of this document.
</li>
</ol>
</section>
</section> <section anchor="sect-4" numbered="true" toc="default">
<name>Requirements</name>
<section title="Requirements" anchor="sect-4"><t> <t>
We now list the requirements that apply when designing primary or We now list the requirements that apply when designing primary or
last resort time-based loss detection mechanisms. For historical last-resort time-based loss detection mechanisms. For historical
reasons and ease of exposition, we refer to the time between sending 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 a packet and determining the packet has been lost due to lack of
delivery confirmation as the "retransmission timeout" or "RTO". delivery confirmation as the "retransmission timeout" or "RTO".
After the RTO passes without delivery confirmation, the sender may After the RTO passes without delivery confirmation, the sender may
safely assume the packet is lost. However, as discussed above, the safely assume the packet is lost. However, as discussed above, the
detected loss need not be repaired (i.e., the loss could be detected detected loss need not be repaired (i.e., the loss could be detected
only for congestion control and not reliability purposes). only for congestion control and not reliability purposes).
<list style="format (%d)"> </t>
<ol spacing="normal" type="(%d)">
<t>As we note above, loss detection happens when a sender does not <li>
<t>As we note above, loss detection happens when a sender does not
receive delivery confirmation within some expected period of receive delivery confirmation within some expected period of
time. In the absence of any knowledge about the latency of a time. In the absence of any knowledge about the latency of a
path, the initial RTO MUST be conservatively set to no less than path, the initial RTO <bcp14>MUST</bcp14> be conservatively set to no less
than
1 second. 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 loss detection can trigger spurious retransmits that
could cause issues when a network is already congested.</t>
<t>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 taken a relatively long time.</t>
<t>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.</t>
</list></t>
<t>The specific constant (1 second) comes from the analysis of Internet <t>Correctness is of the utmost importance when transmitting
RTTs found in Appendix A of <xref target="RFC6298"/>.</t> into a network with unknown properties because:
</list></t> </t>
<ul spacing="normal">
<li>Premature loss detection can trigger spurious retransmits
that could cause issues when a network is already
congested.</li>
<li>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.</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 the communication.</li>
</ul>
<t>
The specific constant (1 second) comes from the analysis of
Internet
round-trip times (RTTs) found in <xref target="RFC6298"
sectionFormat="of" section="A"/>.</t>
<t> We now specify four requirements that pertain to setting an </li>
expected time interval for delivery confirmation. <li>
<t> We now specify four requirements that pertain to setting an
expected time interval for delivery confirmation.
</t>
<list style="empty"> <t>
<t>Often measuring the time required for delivery confirmation is Often, measuring the time required for delivery confirmation is
framed as assessing the "round-trip time (RTT)" of the network path. framed as assessing the RTT of the network path.
The RTT is the minimum amount of time required to receive delivery The RTT is the minimum amount of time required to receive delivery
confirmation and also often follows protocol behavior whereby confirmation and also often follows protocol behavior whereby
acknowledgments are generated quickly after data arrives. For acknowledgments are generated quickly after data arrives. For
instance, this is the case for the RTO used by TCP <xref instance, this is the case for the RTO used by TCP <xref
target="RFC6298"/> and SCTP <xref target="RFC4960"/>. However, this target="RFC6298" format="default"/> and SCTP <xref target="RFC4960"
is somewhat mis-leading and the expected latency is better framed as format="default"/>. However, this
is somewhat misleading, and the expected latency is better framed as
the "feedback time" (FT). In other words, the expectation is not the "feedback time" (FT). In other words, the expectation is not
always simply a network property, but can include additional time always simply a network property; it can include additional time
before a sender should reasonably expect a response. </t> before a sender should reasonably expect a response.
</t>
<t>For instance, consider a UDP-based DNS request from a client to a <t>For instance, consider a UDP-based DNS request from a client to
recursive resolver <xref target="RFC1035"/>. When the request can be a
served from the resolver's cache the FT likely well approximates the recursive resolver <xref target="RFC1035" format="default"/>.
network RTT between the client and resolver. However, on a cache miss When the request can be
the resolver will request the needed information from one or more served from the resolver's cache, the feedback time (FT) likely
authoritative DNS servers, which will non-trivially increase the FT well approximates the
compared to the network RTT between the client and resolver.</t> network RTT between the client and resolver. However, on a cache
miss,
<t>Therefore, we express the requirements in terms of FT. Again, for the resolver will request the needed information from one or more
ease of exposition we use "RTO" to indicate the interval between a authoritative DNS servers, which will non-trivially increase the
packet transmission and the decision the packet has been FT
lost---regardless of whether the packet will be retransmitted.</t> compared to the network RTT between the client and resolver.</t>
<t>Therefore, we express the requirements in terms of FT. Again,
</list> for
ease of exposition, we use "RTO" to indicate the interval between
<list style="format (%c)"> a
packet transmission and the decision that the packet has been
<t>The RTO SHOULD be set based on multiple observations of the FT when lost, regardless of whether the packet will be retransmitted.</t>
available.
<list style="empty"> <ol spacing="normal" type="(%c)">
<t>In other words, the RTO should represent an empirically-derived <li>
<t>The RTO <bcp14>SHOULD</bcp14> be set based on multiple
observations of the FT when available.
</t>
<t>In other words, the RTO should represent an empirically
derived
reasonable amount of time that the sender should wait for delivery reasonable amount of time that the sender should wait for delivery
confirmation before deciding the given data is lost. Network paths are confirmation before deciding the given data is lost. Network paths are
inherently dynamic and therefore it is crucial to incorporate multiple inherently dynamic; therefore, it is crucial to incorporate multiple
recent FT samples in the RTO to take into account the delay variation recent FT samples in the RTO to take into account the delay variation
across time.</t> across time.</t>
<t>For example, TCP's RTO <xref target="RFC6298"
format="default"/> 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.</t>
<t>For example, TCP's RTO <xref target="RFC6298"/> would satisfy this <t>While multiple FT samples are crucial for capturing the
requirement due to its use of an exponentially-weighted delay
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 the 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 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 samples out of the RTO calculation -- as the particulars could depend on
the situation and/or goals of each specific loss detector.</t> the situation and/or goals of each specific loss detector.</t>
<t>Finally, FT samples come from packet exchanges between
<t>Finally, FT samples come from packet exchanges between peers. We peers. We
encourage protocol designers---especially for new protocols---to strive encourage protocol designers -- especially for new protocols -- to
strive
to ensure the feedback is not easily spoofable by on- or off-path 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. attackers such that they can perturb a host's notion of the FT.
Ideally, all messages would be cryptographically secure, but given that Ideally, all messages would be cryptographically secure, but given that
this is not always possible---especially in legacy protocols---using a this is not always possible -- especially in legacy protocols -- using a
healthy amount of randomness in the packets is encouraged.</t> healthy amount of randomness in the packets is encouraged.</t>
</list></t> </li>
<li>
<t>FT observations SHOULD be taken and incorporated into the RTO at <t>FT observations <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 least once per RTT or as frequently as data is exchanged in cases where
that happens less frequently than once per RTT. that happens less frequently than once per RTT.
<list style="empty"> </t>
<t>Internet measurements show that taking only a single FT sample per <t>Internet measurements show that taking only a single FT
sample per
TCP connection results in a relatively poorly performing RTO mechanism TCP connection results in a relatively poorly performing RTO mechanism
<xref target="AP99"/>, hence this requirement that the FT be sampled <xref target="AP99" format="default"/>, hence this requirement that the
FT be sampled
continuously throughout the lifetime of communication.</t> continuously throughout the lifetime of communication.</t>
<t>As an example, TCP takes an FT sample roughly once per RTT,
or, if using the timestamp option <xref target="RFC7323"
format="default"/>, on each acknowledgment arrival. <xref
target="AP99" format="default"/> shows that both these
approaches result in roughly equivalent performance for the
RTO estimator.</t>
<t>As an example, TCP takes an FT sample roughly once per RTT, or if </li>
using the timestamp option <xref target="RFC7323"/> on each <li>
acknowledgment arrival. <xref target="AP99"/> shows that both these <t>FT observations <bcp14>MAY</bcp14> be taken from non-data
approaches result in roughly equivalent performance for the RTO exchanges.
estimator.</t>
</list></t>
<t>FT observations MAY be taken from non-data exchanges.
<list style="empty"> </t>
<t>Some protocols use non-data exchanges for various reasons---e.g., <t>Some protocols use non-data exchanges for various reasons,
keepalives, heartbeats, control messages. To the extent that the e.g.,
keepalives, heartbeats, and control messages. To the extent that the
latency of these exchanges mirrors data exchange, they can be leveraged latency of these exchanges mirrors data exchange, they can be leveraged
to take FT samples within the RTO mechanism. Such samples can help to take FT samples within the RTO mechanism. Such samples can help
protocols keep their RTO accurate during lulls in data transmission. protocols keep their RTO accurate during lulls in data transmission.
However, given that these messages may not be subject to the same delays 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 as data transmission, we do not take a general view on whether this is
useful or not.</t> useful or not.</t>
</list></t> </li>
<li>
<t>An RTO mechanism MUST NOT use ambiguous FT samples. <t>An RTO mechanism <bcp14>MUST NOT</bcp14> use ambiguous FT
samples.
<list style="empty">
<t>Assume two copies of some packet X are transmitted at times t0 and t1 </t>
and 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 and 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 <xref target="KP87"/>,<xref target="RFC6298"/>).</t>
<t>There are cases where two copies of some data are <t>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 <bcp14>MUST
NOT</bcp14> use either version of the FT sample and hence not
update the RTO (as discussed in <xref 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 transmitted in a way whereby the sender can tell which is
being acknowledged by an incoming ACK. E.g., TCP's being acknowledged by an incoming ACK. For example, TCP's
timestamp option <xref target="RFC7323"/> allows for packets to be timestamp option <xref target="RFC7323" format="default"/> allows for
packets to be
uniquely identified and hence avoid the ambiguity. In such uniquely identified and hence avoid the ambiguity. In such
cases there is no ambiguity and the resulting samples can cases, there is no ambiguity and the resulting samples can
update the RTO.</t> update the RTO.</t>
</list></t> </li>
</ol>
</list></t> </li>
<li>
<t>Loss detected by the RTO mechanism MUST be taken as an indication of <t>Loss detected by the RTO mechanism <bcp14>MUST</bcp14> be taken
network congestion and the sending rate adapted using a standard as an indication of network congestion and the sending rate adapted
mechanism (e.g., TCP collapses the congestion window to one packet <xref using a standard mechanism (e.g., TCP collapses the congestion
target="RFC5681"/>). window to one packet <xref target="RFC5681" format="default"/>).
<list style="empty">
<t>This ensures network safety.</t> </t>
<t>An exception to this rule is if an IETF standardized mechanism <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 determines that a particular loss is due to a non-congestion event
(e.g., packet corruption). In such a case a congestion control action (e.g., packet corruption). In such a case, a congestion control action
is not required. Additionally, congestion control actions taken based is not required. Additionally, congestion control actions taken based
on time-based loss detection could be reversed when a standard mechanism on time-based loss detection could be reversed when a standard mechanism
post-facto determines that the cause of the loss was not congestion post facto determines that the cause of the loss was not congestion
(e.g., <xref target="RFC5682"/>).</t> (e.g., <xref target="RFC5682" format="default"/>).</t>
</list></t>
<t>Each time the RTO is used to detect a loss, the value of the RTO MUST </li>
<li>
<t>Each time the RTO is used to detect a loss, the value of the RTO
<bcp14>MUST</bcp14>
be exponentially backed off such that the next firing requires a longer be exponentially backed off such that the next firing requires a longer
interval. The backoff SHOULD be removed after either (a) the subsequent interval. The backoff <bcp14>SHOULD</bcp14> be removed after either (a)
the subsequent
successful transmission of non-retransmitted data, or (b) an RTO passes successful transmission of non-retransmitted data, or (b) an RTO passes
without detecting additional losses. The former will generally be without detecting additional losses. The former will generally be
quicker. The latter covers cases where loss is detected, but not quicker. The latter covers cases where loss is detected but not
repaired. repaired.
<list style="empty"> </t>
<t>A maximum value MAY be placed on the RTO. The maximum RTO MUST NOT
be less than 60 seconds (as specified in <xref target="RFC6298"/>).</t>
<t>This ensures network safety.</t>
<t>As with guideline (3), an exception to this rule exists if an IETF <t>A maximum value <bcp14>MAY</bcp14> be placed on the RTO. The
maximum RTO <bcp14>MUST NOT</bcp14> be less than 60 seconds (as
specified in <xref 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 standardized mechanism determines that a particular loss is not due to
congestion.</t> congestion.</t>
</list></t> </li>
</list></t> </ol>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
<name>Discussion</name>
<section title="Discussion" anchor="sect-5"><t> <t>
We note that research has shown the tension between the We note that research has shown the tension between the
responsiveness and correctness of time-based loss detection seems to responsiveness and correctness of time-based loss detection seems to
be a fundamental tradeoff in the context of TCP <xref target="AP99"/>. That be a fundamental tradeoff in the context of TCP <xref target="AP99"
is, format="default"/>. That is,
making the RTO more aggressive (e.g., via changing TCP's making the RTO more aggressive (e.g., via changing TCP's
exponentially weighted moving average (EWMA) gains, lowering the exponentially weighted moving average (EWMA) gains, lowering the
minimum RTO, etc.) can reduce the time required to detect actual minimum RTO, etc.) can reduce the time required to detect actual
loss. However, at the same time, such aggressiveness leads to more loss. However, at the same time, such aggressiveness leads to more
cases of mistakenly declaring packets lost that ultimately arrived cases of mistakenly declaring packets lost that ultimately arrived
at the receiver. Therefore, being as aggressive as the requirements at the receiver. Therefore, being as aggressive as the requirements
given in the previous section allow in any particular situation may given in the previous section allow in any particular situation may
not be the best course of action because detecting loss---even if not be the best course of action because detecting loss, even if
falsely---carries a requirement to invoke a congestion response falsely, carries a requirement to invoke a congestion response
which will ultimately reduce the transmission rate.</t> that will ultimately reduce the transmission rate.</t>
<t>
<t>
While the tradeoff between responsiveness and correctness seems While the tradeoff between responsiveness and correctness seems
fundamental, the tradeoff can be made less relevant if the sender fundamental, the tradeoff can be made less relevant if the sender can
can detect and recover from mistaken loss detection. Several detect and recover from mistaken loss detection. Several mechanisms have
mechanisms have been proposed for this purpose, such as Eifel been proposed for this purpose, such as Eifel <xref target="RFC3522"
<xref target="RFC3522"/>, F-RTO <xref target="RFC5682"/> and DSACK <xref format="default"/>, Forward RTO-Recovery (F-RTO) <xref target="RFC5682"
target="RFC2883"/>,<xref target="RFC3708"/>. Using such format="default"/>, and Duplicate Selective Acknowledgement (DSACK) <xref
mechanisms may allow a data originator to tip towards being more target="RFC2883"
responsive without incurring (as much of) the attendant costs of format="default"/> <xref target="RFC3708" format="default"/>. Using such
mistakenly declaring packets to be lost.</t> mechanisms may allow a data originator to tip towards being more responsive
without incurring (as much of) the attendant costs of mistakenly declaring
<t> packets to be lost.</t>
Also, note that, in addition to the experiments discussed in <xref target="AP <t>
99"/>, Also, note that, in addition to the experiments discussed in <xref
target="AP99" format="default"/>,
the Linux TCP implementation has been using various non-standard RTO the Linux TCP implementation has been using various non-standard RTO
mechanisms for many years seemingly without large-scale problems mechanisms for many years seemingly without large-scale problems
(e.g., using different EWMA gains than specified in <xref target="RFC6298"/>) (e.g., using different EWMA gains than specified in <xref target="RFC6298"
. format="default"/>).
Further, a number of TCP implementations use a steady-state minimum Further, a number of TCP implementations use a steady-state minimum
RTO that is less than the 1 second specified in <xref target="RFC6298"/>. Wh RTO that is less than the 1 second specified in <xref target="RFC6298"
ile format="default"/>. While
the implication of these deviations from the standard may be more the implication of these deviations from the standard may be more
spurious retransmits (per <xref target="AP99"/>), we are aware of no large-sc spurious retransmits (per <xref target="AP99" format="default"/>), we are
ale aware of no large-scale
network safety issues caused by this change to the minimum RTO. network safety issues caused by this change to the minimum RTO.
This informs the guidelines in the last section (e.g., there is no This informs the guidelines in the last section (e.g., there is no
minimum RTO specified).</t> minimum RTO specified).</t>
<t> <t>
Finally, we note that while allowing implementations to be more Finally, we note that while allowing implementations to be more
aggressive could in fact increase the number of needless aggressive could in fact increase the number of needless
retransmissions, the above requirements fail safe in that they retransmissions, the above requirements fail safely in that they
insist on exponential backoff and a transmission rate reduction. insist on exponential backoff and a transmission rate reduction.
Therefore, providing implementers more latitude than they have Therefore, providing implementers more latitude than they have
traditionally been given in IETF specifications of RTO mechanisms traditionally been given in IETF specifications of RTO mechanisms
does not somehow open the flood gates to aggressive behavior. Since does not somehow open the flood gates to aggressive behavior. Since
there is a downside to being aggressive, the incentives for proper there is a downside to being aggressive, the incentives for proper
behavior are retained in the mechanism.</t> behavior are retained in the mechanism.</t>
</section>
</section> <section anchor="sect-6" numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations" anchor="sect-6"><t> <t>
This document does not alter the security properties of time-based This document does not alter the security properties of time-based
loss detection mechanisms. See <xref target="RFC6298"/> for a discussion of loss detection mechanisms. See <xref target="RFC6298" format="default"/>
these for a discussion of these
within the context of TCP.</t> within the context of TCP.</t>
</section>
<section anchor="sect-7" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.</t>
</section>
</section> </middle>
<back>
<section title="IANA Considerations" anchor="sect-7"><t> <displayreference target="I-D.ietf-tcpm-rack" to="CCDJ20"/>
This document has no IANA considerations.</t> <displayreference target="I-D.dukkipati-tcpm-tcp-loss-probe" to="DCCM13"/>
<displayreference target="I-D.ietf-quic-recovery" to="IS20"/>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.x
ml"/>
</references>
<references>
<name>Informative References</name>
<section title="Acknowledgments" numbered="no" anchor="acknowledgments">< <reference anchor="AP99">
t> <front>
This document benefits from years of discussions with Ethan Blanton, <title>On Estimating End-to-End Network Path Properties</title>
Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the <author initials="M." surname="Allman" fullname="M. Allman">
members of the TCPM and TCP-IMPL working groups. Ran Atkinson, </author>
Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley <author initials="V." surname="Paxson" fullname="V. Paxson">
Eddy, Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja </author>
Kuhlewind, Nicolas Kuhn, Jonathan Looney and Michael Scharf provided <date month="September" year="1999"/>
useful comments on previous versions of this document.</t> </front>
<refcontent>Proceedings of the ACM SIGCOMM Technical Symposium</refcontent>
</reference>
</section> <xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf
-tcpm-rack.xml"/>
</middle> <xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.dukk
ipati-tcpm-tcp-loss-probe.xml"/>
<back> <reference anchor='I-D.ietf-quic-recovery'>
<references title="Normative References"> <front>
&RFC2119; <title>QUIC Loss Detection and Congestion Control</title>
&RFC8174;
</references>
<references title="Informative References">
<reference 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 initials='J' surname='Iyengar' fullname='Jana Iyengar' role='editor'>
</author> <organization />
</author>
<date month="September" year="1999"/> <author initials='I' surname='Swett' fullname='Ian Swett' role='editor'>
</front> <organization />
</author>
<seriesInfo name="Proceedings" value="of the ACM SIGCOMM Technical Sympos <date month='October' day='20' year='2020' />
ium"/>
</reference>
&I-D.ietf-tcpm-rack;
&I-D.dukkipati-tcpm-tcp-loss-probe;
&I-D.ietf-quic-recovery;
<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>
</front>
<seriesInfo name="ACM" value="SIGCOMM"/> <seriesInfo name='Internet-Draft' value='draft-ietf-quic-recovery-32' />
</reference> </reference>
<reference anchor="KP87"><front> <reference anchor="Jac88">
<title>Improving Round-Trip Time Estimates in Reliable Transport Protocol <front>
s</title> <title>Congestion avoidance and control</title>
<author initials="P." surname="Karn" fullname="P. Karn"></author> <author initials="V." surname="Jacobson" fullname="V. Jacobson">
<author initials="C." surname="Partridge" fullname="C. Partridge"></autho </author>
r> <date month="August" year="1988"/>
<date/> </front>
</front> <refcontent>ACM SIGCOMM</refcontent>
<seriesInfo name="DOI" value="10.1145/52325.52356"/>
<seriesInfo name="SIGCOMM" value="87"/> </reference>
</reference>
&RFC1034; <reference anchor="KP87">
&RFC1035; <front>
&RFC2018; <title>Improving Round-Trip Time Estimates in Reliable Transport
&RFC2140; Protocols</title>
&RFC2883; <author initials="P." surname="Karn" fullname="P. Karn"/>
&RFC3124; <author initials="C." surname="Partridge"
&RFC3261; fullname="C. Partridge"/>
&RFC3522; </front>
&RFC3708; <refcontent>SIGCOMM 87</refcontent>
&RFC4960; </reference>
&RFC5681;
&RFC5682;
&RFC5740;
&RFC6182;
&RFC6298;
&RFC6675;
&RFC7323;
</references>
</back>
</rfc> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2018.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2140.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2883.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3124.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3522.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3708.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5682.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5740.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6182.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6298.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6675.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.x
ml"/>
</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>
 End of changes. 104 change blocks. 
522 lines changed or deleted 515 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/