draft-ietf-tcpm-rto-consider-03.txt   draft-ietf-tcpm-rto-consider-04.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-03.txt April 15, 2016 File: draft-ietf-tcpm-rto-consider-04.txt June 15, 2016
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: October 15, 2016 Expires: December 15, 2016
Retransmission Timeout Considerations Retransmission Timeout Requirements
Status of this Memo Status of this Memo
This document may not be modified, and derivative works of it may This document may not be modified, and derivative works of it may
not be created, except to format it for publication as an RFC or to not be created, except to format it for publication as an RFC or to
translate it into languages other than English. translate it into languages other than English.
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,
skipping to change at page 1, line 53 skipping to change at page 1, line 53
(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
Each implementation of a retransmission timeout mechanism represents Ensuring reliable communication often manifests in a timeout and
a balance between correctness and timeliness and therefore no retry mechanism. Each implementation of a retransmission timeout
implementation suits all situations. This document provides mechanism represents a balance between correctness and timeliness
high-level requirements for retransmission timeout schemes and therefore no implementation suits all situations. This document
provides high-level requirements for retransmission timeout schemes
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].
1 Introduction 1 Introduction
Despite our best intentions and most robust mechanisms, reliability Reliable transmission is a key property for many network protocols
in networking ultimately requires a timeout and re-try mechanism. and applications. Our protocols use various mechanisms to achieve
Often there are more timely and precise mechanisms than a timeout reliable data transmission. Often we use continuous or periodic
for repairing loss (e.g., TCP's fast retransmit [RFC5681], NewReno reports from the recipient to inform the sender's notion of which
[RFC6582] or selective acknowledgment scheme [RFC2018,RFC6675]) pieces of data are missing and need to be retransmitted to ensure
which require information exchange between components in the system. reliability. Alternatively, information coding---e.g., FEC---can be
Such communication cannot be guaranteed. Alternatively, information used to achieve probabilistic reliability without retransmissions.
coding---e.g., FEC---can allow the recipient to recover from some However, despite our best intentions and most robust mechanisms, the
amount of lost information without use of a retransmission. This only thing we can truly depend on is the passage of time and
latter provides probabilistic reliability. Finally, negative therefore our ultimate backstop to ensuring reliability is a timeout
acknowledgment schemes exist that do not depend on continuous and re-try mechanism. That is, the sender sets some expectation for
feedback to trigger retransmissions (e.g., [RFC3940]). However, how long to wait for confirmation of delivery for a given piece of
regardless of these useful alternatives, the only thing we can truly data. When this time period passes without delivery confirmation
depend on is the passage of time and therefore our ultimate backstop the sender assumes the data was lost in transit and therefore
to ensuring reliability is a timeout. (Note: There is a case when schedules a retransmission. This process of ensuring reliability
we cannot count on the passage of time, but in this case we believe via time-based loss detection and resending lost data is commonly
repairing loss will be a moot point and hence we do not further referred to as a "retransmission timeout (RTO)" mechanism.
consider this case in this document.)
Various protocols have defined their own timeout mechanisms (e.g., Various protocols have defined their own RTO mechanisms (e.g., TCP
TCP [RFC6298], SCTP [RFC4960], SIP [RFC3261]). Ideally, if we know [RFC6298], SCTP [RFC4960], SIP [RFC3261]). The specifics of
a segment will be lost before reaching the destination, a second retransmission timeouts often represent a particular tradeoff
copy of it would be sent immediately after the first transmission. between correctness and responsiveness [AP99]. In other words we
However, in reality the specifics of retransmission timeouts often want to simultaneously:
represent a particular tradeoff between correctness and
responsiveness [AP99]. In other words we want to simultaneously:
- Wait long enough to ensure the decision to retransmit is - wait long enough to ensure the detection of loss is correct and
correct. therefore a retransmission is in fact needed, and
- Bound the delay we impose on applications before - bound the delay we impose on applications before repairing
retransmitting. loss.
However, serving both of these goals is difficult as they pull in Serving both of these goals is difficult as they pull in opposite
opposite directions. I.e., towards either (a) withholding needed directions. I.e., towards either (a) withholding needed
retransmissions too long to ensure the retransmissions are truly retransmissions too long to ensure the original transmission is
needed or (b) not waiting long enough to help application truly lost or (b) not waiting long enough to help application
responsiveness and sending spurious retransmissions. Given this responsiveness and hence sending unnecessary (often denoted
fundamental tradeoff [AP99], we have found that even though the "spurious") retransmissions. We have found that even though the RTO
retransmission timeout (RTO) procedures are standardized, procedure is standardized for some protocols (e.g., TCP [RFC6298]),
implementations often add their own subtle imprint on the specifics implementations often add their own subtle imprint on the specifics
of the process to tilt the tradeoff between correctness and of the process to tilt the tradeoff between correctness and
responsiveness in some particular way. responsiveness in some particular way.
At this point we recognize that often these specific tweaks are not At this point we recognize that often these specific tweaks that
crucial for network safety. Hence, in this document we outline the deviate from standardized RTO mechanisms do not materially impact
high-level requirements that are crucial for any retransmission network safety. Therefore, in this document we outline a set of
timeout scheme to follow. The intent is to then allow high-level protocol-agnostic requirements for RTO mechanisms that
implementations to instantiate mechanisms that best realize their provide a for network safety. The intent is to provide a safe
specific goals within this framework. These specific mechanisms foundation on which implementations have the flexibility to
could be standardized by the IETF or ad-hoc, but as long as they instantiate mechanisms that best realize their specific goals.
adhere to the requirements given in this document they would be
considered consistent with the standards.
Finally, we note the requirements in this document are applicable to
any protocol that uses a retransmission timeout mechanism. The
examples and discussion are framed in terms of TCP, however, that is
an artifact of where much of our experience with RTOs comes from and
should not be read as narrowing the scope of the requirements.
2 Scope 2 Scope
This document offers high-level requirements based on experience The principles we outline in this document are protocol-agnostic and
with retransmission timer algorithms. However, this document widely applicable. We make the following scope statements about
explicitly does not update or obsolete currently standardized the application of the requirements discussed in Section 3:
algorithms nor limit future standardization of specific RTO
mechanisms. Specifically:
(a) RTO mechanisms that are currently standardized are not updated (S.1) The requirements in this document apply only to timer-based
or obsoleted by this document. This holds even in cases where loss detection and retransmission.
the existing specification differs from the requirements in this
document (e.g., [RFC3261] uses a smaller initial RTO than this
document specifies). Existing standard specifications enjoy
their own consensus which this document does not change.
(b) Future standardization efforts that specify RTO mechanisms While there are a bevy of uses for timers in protocols---from
SHOULD follow the requirements in this document. This follows rate-based pacing to connection failure detection to making
the definition of "SHOULD" [RFC2119] and is explicitly not a congestion control decisions and beyond---these are outside
"MUST". That is, the requirements in this document hold unless the scope of this document.
the community has consensus that specific deviations in a
particular context are warranted.
(c) RTO mechanisms that are not standardized but adhere to the (S.2) The requirements in this document only apply to cases where
requirements in the following section are deemed consistent with loss detected via a timer is repaired by a retransmission of
the standards. This includes RTO mechanisms that are deviations the original data.
from a specific standardized algorithm, but are still within the
requirements below.
More colloquially we note that each RTO implementation can be placed Other cases are certainly possible---e.g., replacing the lost
into one of the following four categories: data with an updated version---but fall outside the scope of
this document.
- The implementation precisely follows a standard RTO mechanism (S.3) The requirements in this document apply only to endpoint-to-
(e.g., [RFC6298]), as well as adhering to the requirements in this endpoint unicast communication. Reliable multicast (e.g.,
document. [RFC5740]) protocols are explicitly outside the scope of this
document.
This document represents no change for this situation as such an Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that
implementation is clearly standards compliant. 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
hosts B and C, A must use independent RTOs for traffic sent to
B and C.
- The implementation does not precisely follow a standard RTO (S.4) There are cases where state is shared across connections or
mechanism and does not adhere to the requirements in this flows (e.g., [RFC2140], [RFC3124]). The RTO is one piece
document. state that is often discussed as sharable. These situations
raise issues that the simple flow-oriented RTO mechanism
discussed in this document does not consider (e.g., how long
to preserve state between connections). Therefore, while the
general principles given in Section 3 are likely applicable,
sharing RTOs across flows is outside the scope of this
document.
This document makes no change to this situation as such an (S.5) The requirements in this document apply to reliable
implementation is clearly not standards compliant. transmission, but do not assume that all data transmitted
within a connection or flow is reliably sent.
- The implementation precisely follows a standard RTO mechanism E.g., a protocol like DCCP [RFC4340] could leverage the
(e.g., [RFC3261]), but does not precisely adhere to the requirements in this document for the initial reliable
requirements in this document. handshake even though the protocol reverts to unreliable
transmission after the handshake.
This document represents no change for this situation as such an E.g., a protocol like SCTP [RFC4960] could leverage the
implementation is considered standards compliant by virtue of requirements for data that is sent only "partially reliably".
precisely implementing a standard mechanism that has community In this case, the protocol uses two phases for each message.
consensus as a reasonable approach. That is, this document's In the first phase, the protocol attempts to ensure
stance is to not limit the community's ability to make exceptions reliability and can leverage the requirements in this
to the requirements herein for particular cases. document. At some point the value of the data is gone and the
protocol transitions to the second phase where the data is
treated as unreliably transmitted and therefore the protocol
will no longer attempt to repair the loss---and hence there
are no more retransmissions and the requirements in this
document are moot.
- The implementation does not precisely follow a standard RTO (S.6) The requirements for RTO mechanisms in this document can be
mechanism, yet does adhere to the requirements in this document. applied regardless of whether the RTO mechanism is the sole
loss repair strategy or works in concert with other
mechanisms.
This document represents a change for these implementations and E.g., for a simple protocol like UDP-based DNS [] a timeout
considers them to be consistent with the standards by virtue of and re-try mechanism is likely to act alone to ensure
following the requirements herein that provide for an RTO safe for reliability.
operation in the Internet.
In other words, the requirements in this document can be viewed as E.g., within a complex protocol like TCP or SCTP we have
specifying the default properties of an RTO mechanism. designed methods to detect and repair loss based on explicit
Specifications can more concretely nail down specifics within these endpoint state sharing [RFC2018,RFC4960,RFC6675]. These
defaults or work outside the defaults as necessary. However, mechanisms are preferred over the RTO as they are often more
implementations that fall within the defaults do not require timely and precise than the coarse-grained RTO. In these
explicit specifications to be considered consistent with the cases, the RTO becomes a last resort when the more advanced
standards. mechanisms fail.
Additionally, the following statements detail the relationship of
the requirements in this document to other specifications and
implementations:
(R.1) RTO mechanisms that are currently standardized are not updated
or obsoleted by this document. Implementations are free to
use these existing specifications as they do now.
This holds even in cases where the existing specification
differs from the requirements in this document (e.g.,
[RFC3261] uses a smaller initial timeout than this document
specifies). Existing standard specifications enjoy their own
consensus which this document does not change.
(R.2) Future standardization efforts that specify RTO mechanisms
SHOULD follow the requirements in this document.
There may be reasons for future RTO mechanisms to deviate from
the requirements in Section 3. In these cases, we expect only
that the standards process does so after reasonable
deliberation and with good reason.
(R.3) Alternatively, future RTO mechanism implementations may be
made directly against the requirements in Section 3 without
another protocol-specific specification.
(R.4) There will no doubt be cases where applying the requirements
in this document directly is not possible due to the structure
or operation of a protocol. For instance, a case where a
timeout is used to detect loss, but the loss is not repaired
with a direct retransmission of the original data. In these
situations, an alternate specification is required. We
encourage such future efforts to leverage the spirit of the
requirements in this document to inform alternate
specifications.
3 Requirements 3 Requirements
We now list the requirements that SHOULD apply when designing We now list the requirements that apply when designing
retransmission timeout (RTO) mechanisms. retransmission timeout (RTO) mechanisms.
(1) In the absence of any knowledge about the latency of a path, the (1) In the absence of any knowledge about the latency of a path, the
RTO MUST be conservatively set to no less than 1 second. RTO MUST be conservatively set to no less than 1 second.
This requirement ensures two important aspects of the RTO. This requirement ensures two important aspects of the RTO.
First, when transmitting into an unknown network, First, when transmitting into an unknown network,
retransmissions will not be sent before an ACK would reasonably retransmissions will not be sent before an ACK would reasonably
be expected to arrive and hence possibly waste scarce network be expected to arrive and hence possibly waste scarce network
resources. Second, as noted below, sometimes retransmissions resources. Second, as noted below, sometimes retransmissions
can lead to ambiguities in assessing the latency of a network can lead to ambiguities in assessing the latency of a network
path. Therefore, it is especially important for the first path. Therefore, it is especially important for the first
latency sample to be free of ambiguities such that there is a latency sample to be free of ambiguities such that there is a
baseline for the remainder of the communication. 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) We specify three requirements that pertain to the sampling of (2) As we note above, loss detection happens when a sender does not
the latency across a path. receive delivery confirmation within an some expected period of
time. We now specify three requirements that pertain to setting
the length of this expectation.
Often measuring the latency is framed as assessing the Often measuring the time required for delivery confirmation is
round-trip time (RTT)---e.g., in TCP's RTO computation is framed as the round-trip time (RTT) of the network path as
specification [RFC6298]. This is somewhat mis-leading as the this is the minimum amount of time required to receive delivery
latency is better framed as the "feedback time" (FT). In other confirmation and also often follows protocol behavior whereby
words, it is not simply a network property, but the length of acknowledgments are generated quickly after data arrives. For
time before a sender should reasonably expect a response to a instance, this is the case for the RTO used by TCP [RFC6298] and
query. SCTP [RFC4960]. However, this is somewhat mis-leading as the
expected latency is better framed as the "feedback time" (FT).
For instance, consider a DNS request from a client to a In other words, the expectation is not always simply a network
resolver. When the request can be served from the resolver's property, but includes additional time before a sender should
reasonably expect a response to a query.
For instance, consider a UDP-based DNS request from a client to
a resolver. When the request can be served from the resolver's
cache the FT likely well approximates the network RTT between cache the FT likely well approximates the network RTT between
the client and resolver. However, on a cache miss the resolver the client and resolver. However, on a cache miss the resolver
will have to request the needed information from authoritative will have to request the needed information from authoritative
DNS servers, which will non-trivially increase the FT and DNS servers, which will non-trivially increase the FT compared
therefore the FT between the client and resolver does not well to the RTT between the client and resolver.
match the network-based RTT between the two hosts.
(a) In steady state the RTO MUST be set based on recent (a) In steady state the RTO MUST be set based on recent
observations of both the FT and the variance of the FT. observations of both the FT and the variance of the FT.
In other words, the RTO should be based on a reasonable In other words, the RTO should be based on a reasonable
amount of time that the sender should wait for an amount of time that the sender should wait for delivery
acknowledgment of the data before retransmitting the given confirmation before retransmitting the given data.
data.
(b) FT observations MUST be taken regularly. (b) FT observations MUST be taken regularly.
The exact definition of "regularly" is deliberately left Internet measurements show that taking only a single FT
vague. TCP takes a FT sample roughly once per RTT, or if sample per TCP connection results in a relatively poorly
using the timestamp option [RFC7323] on each acknowledgment performing RTO mechanism [AP99], hence the requirement that
arrival. [AP99] shows that both these approaches result in the FT be sampled continuously throughout the lifetime of a
roughly equivalent performance for the RTO estimator. connection.
Additionally, [AP99] shows that taking only a single FT
sample per TCP connection is suboptimal and hence the
requirement that the FT be sampled continuously throughout
the lifetime of a connection. For the purpose of this
requirement, we state that FT samples SHOULD be taken at
least once per RTT or as frequently as data is exchanged and
ACKed if that happens less frequently than every RTT.
However, we also recognize that it may not always be
practical to take a FT sample this often in all cases.
Hence, this once-per-RTT sampling requirement is explicitly
a "SHOULD" and not a "MUST".
(c) FT samples used in the computation of the RTO MUST NOT be TCP takes an FT sample roughly once per RTT, or if using the
ambiguous. timestamp option [RFC7323] on each acknowledgment arrival.
[AP99] shows that both these approaches result in roughly
equivalent performance for the RTO estimator.
Therefore, "regularly" SHOULD be defined as at least once
per RTT or as frequently as data is exchanged in cases where
that happens less frequently than once per RTT. However, we
also recognize that it may not always be practical to take
an FT sample this often in all cases. Hence, this
once-per-RTT definition of "regularly" is explicitly a
"SHOULD" and not a "MUST".
(c) FT observations MAY be taken from non-data exchanges.
Some protocols use keepalives, heartbeats or other messages
to exchange control information. To the extent that the
latency of these transactions mirrors data exchange, they
can be leveraged to take FT samples within the RTO
mechanism. Such samples can help protocols keep their RTO
accurate during lulls in data transmission. However, given
that these messages may not be subject to the same delays as
data transmission, we do not take a general view on whether
this is useful or not.
(d) An RTO mechanism MUST NOT use ambiguous FT samples.
Assume two copies of some segment X are transmitted at times Assume two copies of some segment X are transmitted at times
t0 and t1 and then segment X is acknowledged at time t2. In t0 and t1 and then at time t2 the sender receives
some cases, it is not clear which copy of X triggered the confirmation that X in fact arrived. In some cases, it is
ACK and hence the actual FT is either t2-t1 or t2-t0, but not clear which copy of X triggered the confirmation and
which is a mystery. Therefore, in this situation an hence the actual FT is either t2-t1 or t2-t0, but which is a
implementation MUST use Karn's algorithm [KP87,RFC6298] and mystery. Therefore, in this situation an implementation
use neither version of the FT sample and hence not update MUST use Karn's algorithm [KP87,RFC6298] and use neither
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 fires and causes a retransmission the value of (3) Each time the RTO detects a loss and a retransmission is
the RTO MUST be exponentially backed off such that the next scheduled, the value of the RTO MUST be exponentially backed off
firing requires a longer interval. The backoff may be removed such that the next firing requires a longer interval. The
after the successful transmission of non-retransmitted data. backoff SHOULD be removed after the successful repair of the
lost data and subsequent transmission of non-retransmitted data.
A maximum value MAY be placed on the RTO provided it is at least A maximum value MAY be placed on the RTO. The maximum RTO MUST
60 seconds (a la [RFC6298]). NOT be less than 60 seconds (a la [RFC6298]).
This ensures network safety. This ensures network safety.
(4) Retransmission timeouts MUST be taken as indications of (4) Retransmissions triggered by the RTO mechanism MUST be taken as
congestion in the network and the sending rate adapted using a indications of network congestion and the sending rate adapted
standard mechanism (e.g., TCP collapses the congestion window to using a standard mechanism (e.g., TCP collapses the congestion
one segment [RFC5681]). window to one segment [RFC5681]).
This ensures network safety. This ensures network safety.
An exception is made to this rule if an IETF standardized Exception could be made to this rule if an IETF standardized
mechanism is used to determine that a particular loss is due to mechanism is used to determine that a particular loss is due to
a non-congestion event (e.g., packet corruption). In such a a non-congestion event (e.g., packet corruption). In such a
case a congestion control action is not required. Additionally, case a congestion control action is not required. Additionally,
RTO-triggered congestion control actions may be reversed when a RTO-triggered congestion control actions may be reversed when a
standard mechanism determines that the cause of the loss was not standard mechanism determines that the cause of the loss was not
congestion after all. congestion after all (e.g., [RFC5682]).
4 Discussion 4 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 retransmission timeouts seems to
be a fundamental tradeoff [AP99]. That is, making the RTO more be a fundamental tradeoff in the context of TCP [AP99]. That is,
aggressive (e.g., via changing TCP's EWMA gains, lowering the making the RTO more aggressive (e.g., via changing TCP's EWMA gains,
minimum RTO, etc.) can reduce the time spent waiting on needed lowering the minimum RTO, etc.) can reduce the time spent waiting on
retransmissions. However, at the same time, such aggressiveness needed retransmissions. However, at the same time, such
leads to more needless retransmissions. Therefore, being as aggressiveness leads to more needless retransmissions. Therefore,
aggressive as the requirements given in the previous section allow being as aggressive as the requirements given in the previous
in any particular situation may not be the best course of action section allow in any particular situation may not be the best course
because an RTO expiration carries a requirement to slow down. of action because an RTO expiration carries a requirement to invoke
a congestion response and hence slow transmission down.
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 spurious RTOs. Several mechanisms have
been proposed for this purpose, such as Eifel [RFC3522], F-RTO been proposed for this purpose, such as Eifel [RFC3522], F-RTO
[RFC5682] and DSACK [RFC2883,RFC3708]. Using such mechanisms may [RFC5682] and DSACK [RFC2883,RFC3708]. Using such mechanisms may
allow a data originator to tip towards being more responsive without allow a data originator to tip towards being more responsive without
incurring (as much of) the attendant costs of needless retransmits. incurring (as much of) the attendant costs of needless retransmits.
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). Further, a number of (e.g., using different EWMA gains than specified in [RFC6298]).
implementations use minimum RTOs that are less than the 1 second Further, a number of implementations use minimum RTOs that are less
specified in [RFC6298]. While the implication of these deviations than the 1 second specified in [RFC6298]. While the implication of
from the standard may be more spurious retransmits (per [AP99]), we these deviations from the standard may be more spurious retransmits
are aware of no large scale problems caused by this change to the (per [AP99]), we are aware of no large scale problems caused by this
minimum RTO. 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 may in fact increase the number of needless aggressive may 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 of the RTO and a transmission rate reduction.
Therefore, allowing implementers latitude in their instantiations of Therefore, providing implementers more latitude than they have
an RTO mechanism does not somehow open the flood gates to aggressive traditionally been given in IETF specifications of RTO mechanisms
behavior. Since there is a downside to being aggressive the does not somehow open the flood gates to aggressive behavior. Since
incentives for proper behavior are retained in the mechanism. there is a downside to being aggressive the incentives for proper
behavior are retained in the mechanism.
5 Security Considerations 5 Security Considerations
This document does not alter the security properties of This document does not alter the security properties of
retransmission timeout mechanisms. See [RFC6298] for a discussion retransmission timeout mechanisms. See [RFC6298] for a discussion
of these within the context of TCP. of these 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, Jonathan Looney and Michael Scharf provided useful Yuchung Cheng, David Black, Gorry Fairhurst, Jonathan Looney and
comments on a previous version of this draft. Michael Scharf provided useful comments on a previous version of
this draft.
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.
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.
[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,
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
2134, 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
Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs)
to Detect Spurious Retransmissions", RFC 3708, February 2004. to Detect Spurious Retransmissions", RFC 3708, February 2004.
[RFC3940] Adamson, B., C. Bormann, M. Handley, J. Macker, [RFC3940] Adamson, B., C. Bormann, M. Handley, J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable Multicast "Negative-acknowledgment (NACK)-Oriented Reliable Multicast
(NORM) Protocol", November 2004, RFC 3940. (NORM) Protocol", November 2004, RFC 3940.
[RFC4340] Kohler, E., M. Handley, S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", March 2006, RFC 4340.
[RFC4960] Stweart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stweart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
[RFC5682] Sarolahti, P., M. Kojo, K. Yamamoto, M. Hata, "Forward [RFC5682] Sarolahti, P., M. Kojo, K. Yamamoto, M. Hata, "Forward
RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious
Retransmission Timeouts with TCP", RFC 5682, September 2009. Retransmission Timeouts with TCP", RFC 5682, September 2009.
[RFC5740] Adamson, B., C. Bormann, M. Handley, J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport Protocol",
November 2009, RFC 5740.
[RFC6182] Ford, A., C. Raiciu, M. Handley, S. Barre, J. Iyengar,
"Architectural Guidelines for Multipath TCP Development", March
2011, RFC 6182.
[RFC6298] Paxson, V., M. Allman, H.K. Chu, M. Sargent, "Computing [RFC6298] Paxson, V., M. Allman, H.K. Chu, M. Sargent, "Computing
TCP's Retransmission Timer", June 2011, RFC 6298. TCP's Retransmission Timer", June 2011, RFC 6298.
[RFC6582] Henderson, T., S. Floyd, A. Gurtov, Y. Nishida, "The [RFC6582] Henderson, T., S. Floyd, A. Gurtov, Y. Nishida, "The
NewReno Modification to TCP's Fast Recovery Algorithm", April NewReno Modification to TCP's Fast Recovery Algorithm", April
2012, RFC 6582. 2012, RFC 6582.
[RFC6675] Blanton, E., M. Allman, L. Wang, I. Jarvinen, M. Kojo, [RFC6675] Blanton, E., M. Allman, L. Wang, I. Jarvinen, M. Kojo,
Y. Nishida, "A Conservative Loss Recovery Algorithm Based on Y. Nishida, "A Conservative Loss Recovery Algorithm Based on
Selective Acknowledgment (SACK) for TCP", August 2012, RFC 6675. Selective Acknowledgment (SACK) for TCP", August 2012, RFC 6675.
 End of changes. 46 change blocks. 
189 lines changed or deleted 265 lines changed or added

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