draft-ietf-tcpm-rto-consider-09.txt   draft-ietf-tcpm-rto-consider-10.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-09.txt December 2, 2019 File: draft-ietf-tcpm-rto-consider-10.txt February 4, 2020
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: June 2, 2020 Expires: August 4, 2020
Retransmission Timeout Requirements 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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 June 2, 2020. This Internet-Draft will expire on August 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
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
Ensuring reliable communication often manifests in a timeout and Many protocols must detect packet loss for various reasons (e.g., to
retry mechanism. Each implementation of a retransmission timeout ensure reliability using retransmissions or to understand the level
of congestion along a network path). While many mechanisms have
been designed to detect loss, protocols ultimately can only count on
the passage of time without delivery confirmation to declare a
packet "lost". Each implementation of a time-based loss detection
mechanism represents a balance between correctness and timeliness 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 retransmission timeout schemes provides high-level requirements for time-based loss detectors
appropriate for general use in the Internet. Within the appropriate for general use in the Internet. Within the
requirements, implementations have latitude to define particulars requirements, implementations have latitude to define particulars
that best address each situation. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
Editorial Note 1 Introduction
This version addresses Gorry's comments from the recent TCPM Loss detection is a crucial activity for many protocols and
meeting. The changes are fairly minor. applications and is generally undertaken for two major reasons:
Jana's suggestion of moving from dealing with loss recovery (1) Ensuring reliable data delivery.
("retransmissions") to loss detection is not reflected in this
revision. This change will require small changes throughout the
document. The goal of this version is to ensure Gorry's suggestions
are accurately taken into account before starting on Jana's.
--allman 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.
1 Introduction (2) Congestion control.
Reliable transmission is a key property for many network protocols Packet loss is often taken as an indication that the sender
and applications. Our protocols use various mechanisms to achieve is transmitting too fast and is overwhelming some portion of
reliable data transmission. Often we use continuous or periodic the network path. Data senders can therefore use loss to
acknowledgments from the recipient to inform the sender's notion of trigger transmission rate reductions.
which pieces of data are missing and need to be retransmitted to
ensure reliability. Alternatively, information coding---e.g.,
FEC---can be used to achieve probabilistic reliability without
retransmissions. However, despite our best intentions and most
robust mechanisms, the only thing we can truly depend on is the
passage of time and therefore our ultimate backstop to ensuring
reliability is a timeout and re-try mechanism. That is, the sender
sets some expectation for how long to wait for confirmation of
delivery for a given piece of data. When this time period passes
without delivery confirmation the sender assumes the data was lost
in transit and therefore schedules a retransmission. This process
of ensuring reliability via time-based loss detection and resending
lost data is commonly referred to as a "retransmission timeout
(RTO)" mechanism.
Various protocols have defined their own RTO mechanisms (e.g., TCP Various mechanisms are used to detect losses in a packet stream.
[RFC6298], SCTP [RFC4960], SIP [RFC3261]). In this document, our Often we use continuous or periodic acknowledgments from the
use of "RTO" does not refer to any one specific scheme, but rather recipient to inform the sender's notion of which pieces of data are
is a generic term that includes all timer-based retransmission missing. However, despite our best intentions and most robust
mechanisms. The specifics of retransmission timeouts often mechanisms we cannot place ultimate faith in receiving such
represent a particular tradeoff between correctness and acknowledgments, but can only truly depend on the passage of time.
responsiveness [AP99]. In other words we want to simultaneously: Therefore, our ultimate backstop to ensuring that we detect all loss
is a timeout. That is, the sender sets some expectation for how
long to wait for confirmation of delivery for a given piece of data.
When this time period passes without delivery confirmation the
sender concludes the data was lost in transit.
- wait long enough to ensure the detection of loss is correct and The specifics of time-based loss detection schemes represent a
therefore a retransmission is in fact needed, and tradeoff between correctness and responsiveness. In other words we
wish to simultaneously:
- bound the delay we impose on applications before repairing - wait long enough to ensure the detection of loss is correct, and
loss.
- minimize the amount of delay we impose on applications (before
repairing loss) and the network (before we reduce the
congestion).
Serving both of these goals is difficult as they pull in opposite Serving both of these goals is difficult as they pull in opposite
directions. I.e., towards either (a) withholding needed directions [AP99]. By not waiting long enough to accurately
retransmissions too long to ensure the original transmission is determine a packet has been lost we risk sending unnecessary
truly lost or (b) not waiting long enough---to help application ("spurious") retransmissions and needlessly lowering the
responsiveness---and hence sending unnecessary (often denoted transmission rate. By waiting long enough that we are unambiguously
"spurious") retransmissions. certain a packet has been lost we cannot repair losses in a timely
manner and we risk prolonging network congestion.
At this point, our experience has lead to a recognition that often Many protocols and applications use their own time-based loss
specific tweaks that deviate from standardized RTO mechanisms do not detection mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP
materially impact network safety. Therefore, in this document we [RFC3261]). At this point, our experience has lead to a recognition
outline a set of high-level protocol-agnostic requirements for RTO that often specific tweaks that deviate from standardized time-based
mechanisms. The intent is to provide a safe foundation on which loss detectors do not materially impact network safety. Therefore,
implementations have the flexibility to instantiate mechanisms that in this document we outline a set of high-level protocol-agnostic
best realize their specific goals. requirements for time-based loss detection. The intent is to
provide a safe foundation on which implementations have the
flexibility to instantiate mechanisms that best realize their
specific goals.
2 Context 2 Context
This document is a bit "weird" in that it is backwards from the way This document is different from other standards documents in that it
we generally like to engineer systems. Usually, we strive to is backwards from the way we generally like to engineer systems.
understand high-level requirements as a starting point. We then Usually, we strive to understand high-level requirements as a
methodically proceed to engineer specific protocols, algorithms and starting point. We then methodically engineer specific protocols,
systems that meet these requirements. Within the standards process algorithms and systems that meet these requirements. Within the
we have derived many retransmission timeouts without benefit from standards process we have derived many time-based loss detection
some over-arching requirements document---because we had no idea how schemes without benefit from some over-arching requirements
to write such a requirements document! Therefore, we made the best document---because we had no idea how to write such a document!
specific decisions we could in response to specific needs. Therefore, we made the best specific decisions we could in response
to specific needs.
At this point, however, we believe the community's experience has At this point, however, the community's experience has matured to
matured to the point where we can define a set of high-level the point where we can define a set of high-level requirements for
requirements for retransmission timers. That is, we now understand time-based loss detection schemes. We now understand how to
how to separate the aspects of retransmission timers that are separate the strategies these mechanisms use that are crucial for
crucial for network safety from those small details that do not network safety from those small details that do not materially
materially impact network safety. There are two basic benefits of impact network safety. However, adding a requirements umbrella to a
writing this high-level document post-facto: body of existing specifications is inherently messy and we run the
risk of creating inconsistencies with both past and future
mechanisms. The correct way to view this document is as the default
case. Specifically:
- Existing retransmission timer mechanisms may be revisited with - This document does not update or obsolete any existing RFC.
an eye towards changing the small and less crucial details to These previous specifications---while generally consistent with
facilitate some benefit (e.g., performance), while at the same the requirements in this document---reflect community consensus
time not sacrificing network safety. and this document does not change that consensus.
- Future retransmission timers will have a solid basis of - The requirements in this document are meant to provide for
experience to lean on rather than cobbling together a new network safety and, as such, SHOULD be used by all time-based
retransmission timer from scratch and/or pieces parts of other loss detection mechanisms.
specifications.
However, adding a requirements umbrella to a body of existing - The requirements in this document may not be appropriate in all
specific retransmission timer specifications is inherently messy and cases and, therefore, inconsistent deviations may be necessary
we run the risk of creating "inconsistencies". The correct way to (hence the "SHOULD" in the last bullet). However,
view this document is as the default case and these other inconsistencies MUST be (a) explained and (b) gather consensus.
specifications as agreed upon deviations from the default. For
instance, [RFC3261] uses a smaller initial timeout than this
document specifies (requirement (1) in section 4). This situation
does not render useless the general guidance in this document, but
rather develops an initial retransmission timeout that is
appropriate in a specific context. Likewise, TCP's retransmission
timer has a minimum value of 1 second [RFC6298], whereas this
document does not specify that a minimum retransmission timeout is
necessary at all. Again, this situation should be viewed as
[RFC6298] providing a refinement for a specific case.
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 timer-based (S.1) The requirements in this document apply only to time-based
loss detection and retransmission. loss detection.
While there are a bevy of uses for timers in protocols---from While there are a bevy of uses for timers in protocols---from
rate-based pacing to connection failure detection to making rate-based pacing to connection failure detection and
congestion control decisions and beyond---these are outside beyond---these are outside the scope of this document.
the scope of this document.
(S.2) The requirements in this document only apply to cases where
loss detected via a timer is repaired by a retransmission of
the original data.
Other cases are certainly possible---e.g., replacing the lost
data with an updated version---but fall outside the scope of
this document.
(S.3) The requirements in this document apply only to endpoint-to- (S.2) 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
endpoint independently. I.e., if host A communicates with endpoint independently. I.e., if host A communicates with
hosts B and C, A must use independent RTOs for traffic sent to hosts B and C, A needs to use independent time-based loss
B and C. detector instances for traffic sent to B and C.
(S.4) There are cases where state is shared across connections or (S.3) There are cases where state is shared across connections
flows (e.g., [RFC2140], [RFC3124]). The RTO is one piece or flows (e.g., [RFC2140], [RFC3124]). State pertaining to
state that is often discussed as sharable. These situations time-based loss detection is often discussed as sharable.
raise issues that the simple flow-oriented RTO mechanism These situations raise issues that the simple flow-oriented
discussed in this document does not consider (e.g., how long time-based loss detection mechanism discussed in this document
to preserve state between connections). Therefore, while the does not consider (e.g., how long to preserve state between
general principles given in Section 4 are likely applicable, connections). Therefore, while the general principles given
sharing RTOs across flows is outside the scope of this in Section 4 are likely applicable, sharing time-based loss
document. detection information across flows is outside the scope of
this document.
(S.5) The requirements in this document apply to reliable (S.4) The requirements for time-based loss detection mechanisms in
transmission, but do not assume that all data transmitted this document can be applied regardless of whether the
within a connection or flow is reliably sent. mechanism is the sole loss repair strategy or works in concert
with other mechanisms.
E.g., a protocol like DCCP [RFC4340] could leverage the E.g., for a simple protocol like UDP-based DNS
requirements in this document for the initial reliable [RFC1034,RFC1035] a timeout and re-try mechanism is likely to
handshake even though the protocol reverts to unreliable act alone to ensure reliability.
transmission after the handshake.
E.g., a protocol like SCTP [RFC4960] could leverage the E.g., complex protocols like TCP or SCTP have methods to
requirements for data that is sent only "partially reliably". detect (and repair) loss based on explicit endpoint state
In this case, the protocol uses two phases for each message. sharing [RFC2018,RFC4960,RFC6675]. These mechanisms are
In the first phase, the protocol attempts to ensure preferred over a time-based loss detection as they are often
reliability and can leverage the requirements in this more timely and precise than time-based schemes. In these
document. At some point the value of the data is gone and the cases, a time-based scheme---called a "retransmission timeout"
protocol transitions to the second phase where the data is or "RTO"---becomes a last resort when the more advanced
treated as unreliably transmitted and therefore the protocol mechanisms fail.
will no longer attempt to repair the loss---and hence there
are no more retransmissions and the requirements in this
document are moot.
(S.6) The requirements for RTO mechanisms in this document can be E.g., some protocols may leverage more than one time-based
applied regardless of whether the RTO mechanism is the sole loss detector simultaneously. In these cases, the general
loss repair strategy or works in concert with other guidance in this document can be applied to all such timers.
mechanisms.
E.g., for a simple protocol like UDP-based DNS [] a timeout 4 Requirements
and re-try mechanism is likely to act alone to ensure
reliability.
E.g., within a complex protocol like TCP or SCTP we have We now list the requirements that apply when designing time-based
designed methods to detect and repair loss based on explicit loss detection mechanisms. For historical reasons and ease of
endpoint state sharing [RFC2018,RFC4960,RFC6675]. These exposition, we refer to the time between sending a packet and
mechanisms are preferred over the RTO as they are often more determining the packet has been lost due to lack of delivery
timely and precise than the coarse-grained RTO. In these confirmation as the "retransmission timeout" or "RTO". However, the
cases, the RTO becomes a last resort when the more advanced detected loss need not be repaired (i.e., the loss could be detected
mechanisms fail. only for congestion control and not reliability purposes).
E.g., some protocols may leverage more than one retransmission (1) As we note above, loss detection happens when a sender does not
timer simultaneously. In these cases, the general guidance in receive delivery confirmation within an some expected period of
this document can be applied to all such timers. time. In the absence of any knowledge about the latency of a
path, the initial RTO MUST be conservatively set to no less than
1 second.
4 Requirements Correctness is of the utmost importance when transmitting into a
network with unknown properties because:
We now list the requirements that apply when designing - Premature loss detection can trigger spurious retransmits that
retransmission timeout (RTO) mechanisms. could cause issues when a network is already congested.
(1) In the absence of any knowledge about the latency of a path, the - Premature loss detection can needlessly cause congestion
RTO MUST be conservatively set to no less than 1 second. 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.
This requirement ensures two important aspects of the RTO. - Finally, as discussed below, sometimes using time-based
First, when transmitting into an unknown network, loss detection and retransmissions can cause ambiguities in
retransmissions will not be sent before an ACK would reasonably assessing the latency of a network path. Therefore, it is
be expected to arrive and hence possibly waste scarce network especially important for the first latency sample to be free
resources. Second, as noted below, sometimes retransmissions of ambiguities such that there is a baseline for the remainder
can lead to ambiguities in assessing the latency of a network of the communication.
path. Therefore, it is especially important for the first
latency sample to be free of ambiguities such that there is a
baseline for the remainder of the communication.
The specific constant (1 second) comes from the analysis of 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) As we note above, loss detection happens when a sender does not (2) We now specify four requirements that pertain to setting
receive delivery confirmation within an some expected period of an expected time interval for delivery confirmation.
time. We now specify four requirements that pertain to setting
the length of this expectation.
Often measuring the time required for delivery confirmation is Often measuring the time required for delivery confirmation is
is framed as involving the "round-trip time (RTT)" of the is framed as assessing the "round-trip time (RTT)" of the
network path as this is the minimum amount of time required to network path as this is the minimum amount of time required to
receive delivery confirmation and also often follows protocol receive delivery confirmation and also often follows protocol
behavior whereby acknowledgments are generated quickly after behavior whereby acknowledgments are generated quickly after
data arrives. For instance, this is the case for the RTO used data arrives. For instance, this is the case for the RTO used
by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat
mis-leading as 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 includes additional time always simply a network property, but can include additional
before a sender should reasonably expect a response to a query. 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. When the request can be served from the a recursive resolver. When the request can be served from the
resolver's cache the FT likely well approximates the network RTT resolver's cache the FT likely well approximates the network RTT
between the client and resolver. However, on a cache miss the between the client and resolver. However, on a cache miss the
resolver will request the needed information from one or more resolver will request the needed information from one or more
authoritative DNS servers, which will non-trivially increase the authoritative DNS servers, which will non-trivially increase the
FT compared to the RTT between the client and resolver. FT compared to the network RTT between the client and resolver.
Therefore, we express the following requirements in terms of FT: Therefore, we express the requirements in terms of FT. Again,
for ease of exposition we use "RTO" to indicate the interval
between a packet transmission and the decision the packet has
been lost---regardless of whether the packet will be
retransmitted.
(a) In steady state the RTO SHOULD be set based on observations (a) In steady state the RTO SHOULD be set based on observations
of both the FT and the variance of the FT. of both the FT and the variance of the FT.
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 retransmitting the wait for delivery confirmation before deciding the given
given data. data is lost. Networks are inherently dynamic and therefore
it is crucial to allow for some variance in the FT when
developing the expectation.
(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
skipping to change at page 7, line 42 skipping to change at page 7, line 28
version of the FT sample and hence not update the RTO. version of the FT sample and hence not update the RTO.
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 segments 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) Each time the RTO is used to detect a loss and a retransmission (3) Each time the RTO is used to detect a loss, the value of the RTO
is scheduled, the value of the RTO MUST be exponentially backed MUST be exponentially backed off such that the next firing
off such that the next firing requires a longer interval. The requires a longer interval. The backoff SHOULD be removed after
backoff SHOULD be removed after the successful repair of the the subsequent transmission of non-retransmitted data.
lost data and subsequent transmission of non-retransmitted data.
A maximum value MAY be placed on the RTO. The maximum RTO MUST A maximum value MAY be placed on the RTO. The maximum RTO MUST
NOT be less than 60 seconds (a la [RFC6298]). NOT be less than 60 seconds (as specified in [RFC6298]).
This ensures network safety. This ensures network safety.
(4) Loss detected by the RTO mechanism MUST be taken as an (4) 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 segment [RFC5681]).
This ensures network safety. This ensures network safety.
An exception could be made to this rule if an IETF standardized An exception to this rule is if an IETF standardized mechanism
mechanism is used to determine that a particular loss is due to determines that a particular loss is due to a non-congestion
a non-congestion event (e.g., packet corruption). In such a event (e.g., packet corruption). In such a case a congestion
case a congestion control action is not required. Additionally, control action is not required. Additionally, congestion
RTO-triggered congestion control actions may be reversed when a control actions taken based on time-based loss detection could
standard mechanism determines that the cause of the loss was not be reversed when a standard mechanism post-facto determines that
congestion after all (e.g., [RFC5682]). the cause of the loss was not congestion (e.g., [RFC5682]).
5 Discussion 5 Discussion
We note that research has shown the tension between the We note that research has shown the tension between the
responsiveness and correctness of retransmission timeouts seems to responsiveness and correctness of time-based loss detection seems to
be a fundamental tradeoff in the context of TCP [AP99]. That is, be a fundamental tradeoff in the context of TCP [AP99]. That is,
making the RTO more aggressive (e.g., via changing TCP's EWMA gains, making the RTO more aggressive (e.g., via changing TCP's EWMA gains,
lowering the minimum RTO, etc.) can reduce the time spent waiting on lowering the minimum RTO, etc.) can reduce the time required to
needed retransmissions. However, at the same time, such detect actual loss. However, at the same time, such aggressiveness
aggressiveness leads to more needless retransmissions. Therefore, leads to more cases of mistakenly declaring packets lost that
being as aggressive as the requirements given in the previous ultimately arrived at the receiver. Therefore, being as aggressive
section allow in any particular situation may not be the best course as the requirements given in the previous section allow in any
of action because an RTO expiration carries a requirement to invoke particular situation may not be the best course of action because
a congestion response and hence slow transmission down. detecting loss---even if falsely---carries a requirement to invoke a
congestion response which will ultimately reduce the transmission
rate.
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 spurious RTOs. Several mechanisms have can detect and recover from mistaken loss detection. Several
been proposed for this purpose, such as Eifel [RFC3522], F-RTO mechanisms have been proposed for this purpose, such as Eifel
[RFC5682] and DSACK [RFC2883,RFC3708]. Using such mechanisms may [RFC3522], F-RTO [RFC5682] and DSACK [RFC2883,RFC3708]. Using such
allow a data originator to tip towards being more responsive without mechanisms may allow a data originator to tip towards being more
incurring (as much of) the attendant costs of needless retransmits. responsive without incurring (as much of) the attendant costs of
mistakenly declaring packets to be lost.
Also, note, that in addition to the experiments discussed in [AP99], 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 minimum RTOs that are less Further, a number of implementations use minimum RTOs that are less
than the 1 second specified in [RFC6298]. While the implication of than the 1 second specified in [RFC6298]. While the implication of
these deviations from the standard may be more spurious retransmits these deviations from the standard may be more spurious retransmits
(per [AP99]), we are aware of no large scale network safety issues (per [AP99]), we are aware of no large scale network safety issues
caused by this change to the minimum RTO. caused by this change to the minimum RTO.
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 insist
on exponential backoff of the RTO and a transmission rate reduction. 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 This document does not alter the security properties of time-based
retransmission timeout mechanisms. See [RFC6298] for a discussion loss detection mechanisms. See [RFC6298] for a discussion of these
of these within the context of TCP. within the context of TCP.
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, Gorry Fairhurst, Mirja Kuhlewind, Yuchung Cheng, David Black, Gorry Fairhurst, Mirja Kuhlewind,
Nicolas Kuhn, Jonathan Looney and Michael Scharf provided useful Nicolas Kuhn, Jonathan Looney and Michael Scharf provided useful
comments on a previous version of this draft. comments on a previous version of this draft.
skipping to change at page 9, line 30 skipping to change at page 9, line 20
Informative References Informative References
[AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path [AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path
Properties", Proceedings of the ACM SIGCOMM Technical Symposium, Properties", Proceedings of the ACM SIGCOMM Technical Symposium,
September 1999. September 1999.
[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",
RFC 1034, November 1987.
[RFC1035] Mockapetris, P. "Domain Names - Implementation and
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.
 End of changes. 55 change blocks. 
213 lines changed or deleted 207 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/