draft-ietf-tcpm-rto-consider-16.txt   draft-ietf-tcpm-rto-consider-17.txt 
Internet Engineering Task Force M. Allman Internet Engineering Task Force M. Allman
INTERNET-DRAFT ICSI INTERNET-DRAFT ICSI
File: draft-ietf-tcpm-rto-consider-16.txt June 19, 2020 File: draft-ietf-tcpm-rto-consider-17.txt July 27, 2020
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: December 19, 2020 Expires: January 27, 2021
Requirements for Time-Based Loss Detection Requirements for Time-Based Loss Detection
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 19, 2020. This Internet-Draft will expire on January 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 1, line 52 skipping to change at page 1, line 52
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Many protocols must detect packet loss for various reasons (e.g., to Many protocols must detect packet loss for various reasons (e.g., to
ensure reliability using retransmissions or to understand the level ensure reliability using retransmissions or to understand the level
of congestion along a network path). While many mechanisms have of congestion along a network path). While many mechanisms have
been designed to detect loss, protocols ultimately can only count on been designed to detect loss, ultimately, protocols can only count
the passage of time without delivery confirmation to declare a on the passage of time without delivery confirmation to declare a
packet "lost". Each implementation of a time-based loss detection packet "lost". Each implementation of a time-based loss detection
mechanism represents a balance between correctness and timeliness mechanism represents a balance between correctness and timeliness
and therefore no implementation suits all situations. This document and therefore no implementation suits all situations. This document
provides high-level requirements for time-based loss detectors provides high-level requirements for time-based loss detectors
appropriate for general use in the Internet. Within the appropriate for general use in unicast communication across the
requirements, implementations have latitude to define particulars Internet. Within the requirements, implementations have latitude to
that best address each situation. define particulars that best address each situation.
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1 Introduction 1 Introduction
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 best workloads. The service provided by the network varies from
effort delivery among loosely connected components to highly best-effort delivery among loosely connected components to highly
predictable delivery within constrained 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, 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. range from largely static to highly dynamic.
This document provides guidelines for developing an understanding of This document provides guidelines for developing an understanding of
one path property: 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 been gradually learned over the last several decades. We focus on
general case where the loss properties of a path are (a) unknown a the general case where the loss properties of a path are (a) unknown
priori and (b) dynamically vary over time. Further, while there are a priori and (b) dynamically vary over time. Further, while there
numerous root causes of packet loss, we leverage the conservative are numerous root causes of packet loss, we leverage the
notion that loss is an implicit indication of congestion. While conservative notion that loss is an implicit indication of
this stance is not always correct, as a general assumption it has congestion [RFC5681]. While this stance is not always correct, as a
historically served us well. As we discuss further in section 2, general assumption it has historically served us well [Jac88]. As
the guidelines in this document should be viewed as a general we discuss further in section 2, the guidelines in this document
default for best effort networks and not as optimal---or even should be viewed as a general default for unicast communication
across best-effort networks and not as optimal---or even
applicable---for all situations. applicable---for all situations.
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:
(1) Ensuring reliable data delivery. (1) Ensuring reliable data delivery.
This requires a data sender to develop an understanding of This requires a data sender to develop an understanding of
which transmitted packets have not arrived at the receiver. which transmitted packets have not arrived at the receiver.
This knowledge allows the sender to retransmit missing data. This knowledge allows the sender to retransmit missing data.
(2) Congestion control. (2) Congestion control.
skipping to change at page 3, line 39 skipping to change at page 3, line 40
Serving both of these goals is difficult as they pull in opposite Serving both of these goals is difficult as they pull in opposite
directions [AP99]. By not waiting long enough to accurately directions [AP99]. By not waiting long enough to accurately
determine a packet has been lost we may provide a needed determine a packet has been lost we may provide a needed
retransmission in a timely manner, but risk sending unnecessary retransmission in a timely manner, but risk sending unnecessary
("spurious") retransmissions and needlessly lowering the ("spurious") retransmissions and needlessly lowering the
transmission rate. By waiting long enough that we are unambiguously transmission rate. By waiting long enough that we are unambiguously
certain a packet has been lost we cannot repair losses in a timely certain a packet has been lost we cannot repair losses in a timely
manner and we risk prolonging network congestion. manner and we risk prolonging network congestion.
Many protocols and applications use their own time-based loss Many protocols and applications---such as TCP [RFC6298], SCTP
detection mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP [RFC4960], SIP [RFC3261]---use their own time-based loss detection
[RFC3261]). At this point, our experience leads to a recognition mechanisms. At this point, our experience leads to a recognition
that often specific tweaks that deviate from standardized time-based that often specific tweaks that deviate from standardized time-based
loss detectors do not materially impact network safety with respect loss detectors do not materially impact network safety with respect
to congestion control. Therefore, in this document we outline a set to congestion control [AP99]. Therefore, in this document we
of high-level protocol-agnostic requirements for time-based loss outline a set of high-level protocol-agnostic requirements for
detection. The intent is to provide a safe foundation on which time-based loss detection. The intent is to provide a safe
implementations have the flexibility to instantiate mechanisms that foundation on which implementations have the flexibility to
best realize their specific goals. instantiate mechanisms that best realize their specific goals.
2 Context 2 Context
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 benefit from 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
skipping to change at page 4, line 36 skipping to change at page 4, line 37
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: and future specifications:
- This document does not update or obsolete any existing RFC. - This document does not update or obsolete any existing RFC.
These previous specifications---while generally consistent with These previous specifications---while generally consistent with
the requirements in this document---reflect community consensus the requirements in this document---reflect community consensus
and this document does not change that consensus. and this document does not change that consensus.
- The requirements in this document are meant to provide for - The requirements in this document are meant to provide for
network safety and, as such, SHOULD be used by all time-based network safety and, as such, SHOULD be used by all future
loss detection mechanisms. time-based loss detection mechanisms.
- The requirements in this document may not be appropriate in all - The requirements in this document may not be appropriate in all
cases and, therefore, inconsistent deviations and variants may cases and, therefore, deviations and variants may be necessary
be necessary (hence the "SHOULD" in the last bullet). However, in the future (hence the "SHOULD" in the last bullet). However,
inconsistencies MUST be (a) explained and (b) gather consensus. inconsistencies MUST be (a) explained and (b) gather consensus.
3 Scope 3 Scope
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: the application of the requirements discussed in Section 4:
(S.1) The requirements in this document apply only to the primary or (S.1) While there are a bevy of uses for timers in protocols---from
last resort time-based loss detection.
While there are a bevy of uses for timers in protocols---from
rate-based pacing to connection failure detection and rate-based pacing to connection failure detection and
beyond---these are outside the scope of this document. beyond---this document is focused only on loss detection.
(S.2) The requirements for time-based loss detection mechanisms in (S.2) The requirements for time-based loss detection mechanisms in
this document are for the primary or "last resort" loss this document are for the primary or "last resort" loss
detection mechanism whether the mechanism is the sole 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.
While a straightforward time-based loss detector is sufficient While a straightforward time-based loss detector is sufficient
for simple protocols like DNS [RFC1034,RFC1035], more complex for simple protocols like DNS [RFC1034,RFC1035], more complex
protocols often use more advanced loss detectors to aid protocols often use more advanced loss detectors to aid
performance. For instance, TCP and SCTP have methods to performance. For instance, TCP and SCTP have methods to
detect (and repair) loss based on explicit endpoint state detect (and repair) loss based on explicit endpoint state
sharing [RFC2018,RFC4960,RFC6675]. Such mechanisms often sharing [RFC2018,RFC4960,RFC6675]. Such mechanisms often
provide more timely and precise results than time-based loss provide more timely and precise loss detection than time-based
detectors. However, these mechanisms do not obviate the need loss detectors. However, these mechanisms do not obviate the
for a "retransmission timeout" or "RTO" because---as we need for a "retransmission timeout" or "RTO" because---as we
discuss in Section 1---only the passage of time can ultimately discuss in Section 1---only the passage of time can ultimately
be relied upon to detect loss. In cases such as these, the be relied upon to detect loss. In other words, ultimately we
time-based loss detector functions as a "last resort". 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".
Also, note, that some recent proposals have incorporated time Also, note, that some recent proposals have incorporated time
as a component of advanced loss detection methods---either as as a component of advanced loss detection methods---either as
an aggressive first loss detector or in conjunction with an aggressive first loss detector in certain situations or in
endpoint state sharing [DCCM13,CCDJ20,IS20]. Since these conjunction with endpoint state sharing [DCCM13,CCDJ20,IS20].
timers are not used as "last resort" the requirements in this While these mechanisms can aid timely loss recovery, the
document need not be directly used in these cases. However, protocol ultimately leans on another more conservative timer
we expect that many of the requirements are useful for these to ensure reliability when these mechanisms break down. The
situations, as well. requirements in this document are only directly applicable to
last resort loss detection. However, we expect that many of
the requirements can serve as useful guidelines for more
aggressive non-last resort timers, as well.
(S.3) The requirements in this document apply only to endpoint-to- (S.3) The requirements in this document apply only to endpoint-to-
endpoint unicast communication. Reliable multicast (e.g., endpoint unicast communication. Reliable multicast (e.g.,
[RFC5740]) protocols are explicitly outside the scope of this [RFC5740]) protocols are explicitly outside the scope of this
document. document.
Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that
communicate in a unicast fashion with multiple specific communicate in a unicast fashion with multiple specific
endpoints can leverage the requirements in this document endpoints can leverage the requirements in this document
provided they track state and follow the requirements for each provided they track state and follow the requirements for each
skipping to change at page 6, line 13 skipping to change at page 6, line 18
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).
(1) As we note above, loss detection happens when a sender does not (1) As we note above, loss detection happens when a sender does not
receive delivery confirmation within an 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 MUST be conservatively set to no less than
1 second. 1 second.
Correctness is of the utmost importance when transmitting into a Correctness is of the utmost importance when transmitting into a
network with unknown properties because: network with unknown properties because:
- Premature loss detection can trigger spurious retransmits that - Premature loss detection can trigger spurious retransmits that
could cause issues when a network is already congested. could cause issues when a network is already congested.
skipping to change at page 6, line 44 skipping to change at page 6, line 49
of ambiguities such that there is a baseline for the remainder of ambiguities such that there is a baseline for the remainder
of the communication. of the communication.
The specific constant (1 second) comes from the analysis of The specific constant (1 second) comes from the analysis of
Internet RTTs found in Appendix A of [RFC6298]. Internet RTTs found in Appendix A of [RFC6298].
(2) We now specify four requirements that pertain to setting (2) We now specify four requirements that pertain to setting
an expected time interval for delivery confirmation. an expected time interval for delivery confirmation.
Often measuring the time required for delivery confirmation is Often measuring the time required for delivery confirmation is
is framed as assessing the "round-trip time (RTT)" of the framed as assessing the "round-trip time (RTT)" of the network
network path as this is the minimum amount of time required to path. The RTT is the minimum amount of time required to receive
receive delivery confirmation and also often follows protocol delivery confirmation and also often follows protocol behavior
behavior whereby acknowledgments are generated quickly after whereby acknowledgments are generated quickly after data
data arrives. For instance, this is the case for the RTO used arrives. For instance, this is the case for the RTO used by TCP
by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat [RFC6298] and SCTP [RFC4960]. However, this is somewhat
mis-leading and the expected latency is better framed as the mis-leading and the expected latency is better framed as the
"feedback time" (FT). In other words, the expectation is not "feedback time" (FT). In other words, the expectation is not
always simply a network property, but can include additional always simply a network property, but can include additional
time before a sender should reasonably expect a response. time before a sender should reasonably expect a response.
For instance, consider a UDP-based DNS request from a client to For instance, consider a UDP-based DNS request from a client to
a recursive resolver [RFC1035]. When the request can be served a recursive resolver [RFC1035]. When the request can be served
from the resolver's cache the FT likely well approximates the from the resolver's cache the FT likely well approximates the
network RTT between the client and resolver. However, on a network RTT between the client and resolver. However, on a
cache miss the resolver will request the needed information from cache miss the resolver will request the needed information from
one or more authoritative DNS servers, which will non-trivially one or more authoritative DNS servers, which will non-trivially
increase the FT compared to the network RTT between the client increase the FT compared to the network RTT between the client
and resolver. and resolver.
Therefore, we express the requirements in terms of FT. Again, Therefore, we express the requirements in terms of FT. Again,
for ease of exposition we use "RTO" to indicate the interval for ease of exposition we use "RTO" to indicate the interval
between a packet transmission and the decision the packet has between a packet transmission and the decision the packet has
been lost---regardless of whether the packet will be been lost---regardless of whether the packet will be
retransmitted. retransmitted.
(a) If/when available, the RTO SHOULD be set based on multiple (a) The RTO SHOULD be set based on multiple observations of the
observations of the FT. FT when available.
In other words, the RTO should represent an empirically- In other words, the RTO should represent an empirically-
derived reasonable amount of time that the sender should derived reasonable amount of time that the sender should
wait for delivery confirmation before deciding the given wait for delivery confirmation before deciding the given
data is lost. Network paths are inherently dynamic and data is lost. Network paths are inherently dynamic and
therefore it is crucial to incorporate multiple FT samples therefore it is crucial to incorporate multiple recent FT
in the RTO to take into account the delay variation across samples in the RTO to take into account the delay variation
time. across time.
For example, TCP's RTO [RFC6298] would satisfy this For example, TCP's RTO [RFC6298] would satisfy this
requirement due to its use of an exponentially-weighted requirement due to its use of an exponentially-weighted
moving average (EWMA) to combine multiple FT samples into a moving average (EWMA) to combine multiple FT samples into a
"smoothed RTT". In the name of conservativeness, TCP goes "smoothed RTT". In the name of conservativeness, TCP goes
further to also include an explicit variance term when further to also include an explicit variance term when
computing the RTO. computing the RTO.
While multiple FT samples are crucial for capturing the
delay dynamics of a path, we explicitly do not tightly
specify the process---including the number of FT samples to
use and how/when to age samples out of the RTO
calculation---as the particulars could depend on the
situation and/or goals of each specific loss detector.
Finally, FT samples come from packet exchanges between
peers. We encourage protocol designers---especially for new
protocols---to strive to ensure the feedback is not easily
spoofable by on- or off-path attackers such that they can
perturb a host's notion of the FT. Ideally, all messages
would be cryptographically secure, but given that this is
not always possible---especially in legacy protocols---using
a healthy amount of randomness in the packets is encouraged.
(b) FT observations SHOULD be taken and incorporated into the (b) FT observations SHOULD be taken and incorporated into the
RTO at least once per RTT or as frequently as data is RTO at least once per RTT or as frequently as data is
exchanged in cases where that happens less frequently than exchanged in cases where that happens less frequently than
once per RTT. once per RTT.
Internet measurements show that taking only a single FT Internet measurements show that taking only a single FT
sample per TCP connection results in a relatively poorly sample per TCP connection results in a relatively poorly
performing RTO mechanism [AP99], hence this requirement that performing RTO mechanism [AP99], hence this requirement that
the FT be sampled continuously throughout the lifetime of the FT be sampled continuously throughout the lifetime of
communication. communication.
skipping to change at page 8, line 11 skipping to change at page 8, line 31
To the extent that the latency of these exchanges mirrors To the extent that the latency of these exchanges mirrors
data exchange, they can be leveraged to take FT samples data exchange, they can be leveraged to take FT samples
within the RTO mechanism. Such samples can help protocols within the RTO mechanism. Such samples can help protocols
keep their RTO accurate during lulls in data transmission. keep their RTO accurate during lulls in data transmission.
However, given that these messages may not be subject to the However, given that these messages may not be subject to the
same delays as data transmission, we do not take a general same delays as data transmission, we do not take a general
view on whether this is useful or not. view on whether this is useful or not.
(d) An RTO mechanism MUST NOT use ambiguous FT samples. (d) An RTO mechanism MUST NOT use ambiguous FT samples.
Assume two copies of some segment X are transmitted at times Assume two copies of some packet X are transmitted at times
t0 and t1 and then at time t2 the sender receives t0 and t1 and then at time t2 the sender receives
confirmation that X in fact arrived. In some cases, it is confirmation that X in fact arrived. In some cases, it is
not clear which copy of X triggered the confirmation and 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 hence the actual FT is either t2-t1 or t2-t0, but which is a
mystery. Therefore, in this situation an implementation mystery. Therefore, in this situation an implementation
MUST use Karn's algorithm [KP87,RFC6298] and use neither MUST NOT use either version of the FT sample and hence not
version of the FT sample and hence not update the RTO. update the RTO (as discussed in [KP87,RFC6298]).
There are cases where two copies of some data are 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. E.g., TCP's
timestamp option [RFC7323] allows for segments to be timestamp option [RFC7323] 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. update the RTO.
(3) Loss detected by the RTO mechanism MUST be taken as an (3) Loss detected by the RTO mechanism MUST be taken as an
indication of network congestion and the sending rate adapted indication of network congestion and the sending rate adapted
using a standard mechanism (e.g., TCP collapses the congestion using a standard mechanism (e.g., TCP collapses the congestion
window to one segment [RFC5681]). window to one packet [RFC5681]).
This ensures network safety. This ensures network safety.
An exception to this rule is if an IETF standardized mechanism An exception to this rule is if an IETF standardized mechanism
determines that a particular loss is due to a non-congestion determines that a particular loss is due to a non-congestion
event (e.g., packet corruption). In such a case a congestion event (e.g., packet corruption). In such a case a congestion
control action is not required. Additionally, congestion control action is not required. Additionally, congestion
control actions taken based on time-based loss detection could control actions taken based on time-based loss detection could
be reversed when a standard mechanism post-facto determines that be reversed when a standard mechanism post-facto determines that
the cause of the loss was not congestion (e.g., [RFC5682]). the cause of the loss was not congestion (e.g., [RFC5682]).
skipping to change at page 9, line 31 skipping to change at page 9, line 51
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 detect and recover from mistaken loss detection. Several can detect and recover from mistaken loss detection. Several
mechanisms have been proposed for this purpose, such as Eifel mechanisms have been proposed for this purpose, such as Eifel
[RFC3522], F-RTO [RFC5682] and DSACK [RFC2883,RFC3708]. Using such [RFC3522], F-RTO [RFC5682] and DSACK [RFC2883,RFC3708]. Using such
mechanisms may allow a data originator to tip towards being more mechanisms may allow a data originator to tip towards being more
responsive without incurring (as much of) the attendant costs of responsive without incurring (as much of) the attendant costs of
mistakenly declaring packets to be lost. mistakenly declaring packets to be lost.
Also, note, that in addition to the experiments discussed in [AP99], Also, note that, in addition to the experiments discussed in [AP99],
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 [RFC6298]). (e.g., using different EWMA gains than specified in [RFC6298]).
Further, a number of implementations use a steady-state minimum RTO Further, a number of TCP implementations use a steady-state minimum
that are less than the 1 second specified in [RFC6298] (which is RTO that is less than the 1 second specified in [RFC6298]. While
different from the initial RTO we specify in Section 4, Requirement the implication of these deviations from the standard may be more
1). While the implication of these deviations from the standard may spurious retransmits (per [AP99]), we are aware of no large-scale
be more spurious retransmits (per [AP99]), we are aware of no large network safety issues caused by this change to the minimum RTO.
scale network safety issues caused by this change to the minimum This informs the guidelines in the last section (e.g., there is no
RTO. minimum RTO specified).
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 insist retransmissions, the above requirements fail safe in that they
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. behavior are retained in the mechanism.
6 Security Considerations 6 Security Considerations
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 [RFC6298] for a discussion of these loss detection mechanisms. See [RFC6298] for a discussion of these
skipping to change at page 10, line 14 skipping to change at page 10, line 34
7 IANA Considerations 7 IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
Acknowledgments Acknowledgments
This document benefits from years of discussions with Ethan Blanton, This document benefits from years of discussions with Ethan Blanton,
Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the
members of the TCPM and TCP-IMPL working groups. Ran Atkinson, members of the TCPM and TCP-IMPL working groups. Ran Atkinson,
Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Gorry Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley
Fairhurst, Rahul Arvind Jadhav, Mirja Kuhlewind, Nicolas Kuhn, Eddy, Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja
Jonathan Looney and Michael Scharf provided useful comments on Kuhlewind, Nicolas Kuhn, Jonathan Looney and Michael Scharf provided
previous versions of this document. useful comments on previous versions of this document.
Normative References Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017. 2119 Key Words", RFC 8174, May 2017.
Informative References Informative References
skipping to change at page 10, line 47 skipping to change at page 11, line 14
[DCCM13] Dukkipati, N., N. Cardwell, Y. Cheng, M. Mathis, "Tail Loss [DCCM13] Dukkipati, N., N. Cardwell, Y. Cheng, M. Mathis, "Tail Loss
Probe (TLP): An Algorithm for Fast Recovery of Tail Losses", Probe (TLP): An Algorithm for Fast Recovery of Tail Losses",
Internet-Draft draft-dukkipati-tcpm-tcp-loss-probe-01.txt (work Internet-Draft draft-dukkipati-tcpm-tcp-loss-probe-01.txt (work
in progress), February 2013. in progress), February 2013.
[IS20] Iyengar, I., I. Swett, "QUIC Loss Detection and Congestion [IS20] Iyengar, I., I. Swett, "QUIC Loss Detection and Congestion
Control", Internet-Draft Control", Internet-Draft
draft-ietf-quic-recovery-27.txt (work in progress), March 2020. draft-ietf-quic-recovery-27.txt (work in progress), March 2020.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", ACM
SIGCOMM, August 1988.
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM 87. Estimates in Reliable Transport Protocols", SIGCOMM 87.
[RFC1034] Mockapetris, P. "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P. "Domain Names - Concepts and Facilities",
RFC 1034, November 1987. RFC 1034, November 1987.
[RFC1035] Mockapetris, P. "Domain Names - Implementation and [RFC1035] Mockapetris, P. "Domain Names - Implementation and
Specification", RFC 1035, November 1987. Specification", RFC 1035, November 1987.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140,
April 1997. April 1997.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000. TCP", RFC 2883, July 2000.
[RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC
2134, June 2001. 3124, June 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002. "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3522] Ludwig, R., M. Meyer, "The Eifel Detection Algorithm for [RFC3522] Ludwig, R., M. Meyer, "The Eifel Detection Algorithm for
TCP", RFC 3522, april 2003. TCP", RFC 3522, april 2003.
[RFC3708] Blanton, E., M. Allman, "Using TCP Duplicate Selective [RFC3708] Blanton, E., M. Allman, "Using TCP Duplicate Selective
Acknowledgement (DSACKs) and Stream Control Transmission Acknowledgement (DSACKs) and Stream Control Transmission
 End of changes. 33 change blocks. 
84 lines changed or deleted 107 lines changed or added

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