draft-ietf-tcpm-rto-consider-04.txt   draft-ietf-tcpm-rto-consider-05.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-04.txt June 15, 2016 File: draft-ietf-tcpm-rto-consider-05.txt March 10, 2017
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: December 15, 2016 Expires: September 10, 2017
Retransmission Timeout Requirements 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 October 15, 2016. This Internet-Draft will expire on September 10, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 51 skipping to change at page 2, line 51
- wait long enough to ensure the detection of loss is correct and - wait long enough to ensure the detection of loss is correct and
therefore a retransmission is in fact needed, and therefore a retransmission is in fact needed, and
- bound the delay we impose on applications before repairing - bound the delay we impose on applications before repairing
loss. loss.
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. I.e., towards either (a) withholding needed
retransmissions too long to ensure the original transmission is retransmissions too long to ensure the original transmission is
truly lost or (b) not waiting long enough to help application truly lost or (b) not waiting long enough---to help application
responsiveness and hence sending unnecessary (often denoted responsiveness---and hence sending unnecessary (often denoted
"spurious") retransmissions. We have found that even though the RTO "spurious") retransmissions.
procedure is standardized for some protocols (e.g., TCP [RFC6298]),
implementations often add their own subtle imprint on the specifics We have found that even though the RTO procedure is standardized for
of the process to tilt the tradeoff between correctness and some protocols (e.g., TCP [RFC6298]), implementations often add
responsiveness in some particular way. their own subtle imprint on the specifics of the process to tilt the
tradeoff between correctness and responsiveness in some particular
way.
At this point we recognize that often these specific tweaks that At this point we recognize that often these specific tweaks that
deviate from standardized RTO mechanisms do not materially impact deviate from standardized RTO mechanisms do not materially impact
network safety. Therefore, in this document we outline a set of network safety. Therefore, in this document we outline a set of
high-level protocol-agnostic requirements for RTO mechanisms that high-level protocol-agnostic requirements for RTO mechanisms. The
provide a for network safety. The intent is to provide a safe intent is to provide a safe foundation on which implementations have
foundation on which implementations have the flexibility to the flexibility to instantiate mechanisms that best realize their
instantiate mechanisms that best realize their specific goals. specific goals.
2 Scope 2 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 3: the application of the requirements discussed in Section 3:
(S.1) The requirements in this document apply only to timer-based (S.1) The requirements in this document apply only to timer-based
loss detection and retransmission. loss detection and retransmission.
skipping to change at page 4, line 43 skipping to change at page 4, line 44
reliability. reliability.
E.g., within a complex protocol like TCP or SCTP we have E.g., within a complex protocol like TCP or SCTP we have
designed methods to detect and repair loss based on explicit designed methods to detect and repair loss based on explicit
endpoint state sharing [RFC2018,RFC4960,RFC6675]. These endpoint state sharing [RFC2018,RFC4960,RFC6675]. These
mechanisms are preferred over the RTO as they are often more mechanisms are preferred over the RTO as they are often more
timely and precise than the coarse-grained RTO. In these timely and precise than the coarse-grained RTO. In these
cases, the RTO becomes a last resort when the more advanced cases, the RTO becomes a last resort when the more advanced
mechanisms fail. 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 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,
skipping to change at page 5, line 47 skipping to change at page 5, line 13
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) As we note above, loss detection happens when a sender does not (2) 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 an some expected period of
time. We now specify three requirements that pertain to setting time. We now specify four requirements that pertain to setting
the length of this expectation. 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 the round-trip time (RTT) of the network path as is framed as involving the "round-trip time (RTT)" of the
this is the minimum amount of time required to receive delivery network path as this is the minimum amount of time required to
confirmation and also often follows protocol behavior whereby receive delivery confirmation and also often follows protocol
acknowledgments are generated quickly after data arrives. For behavior whereby acknowledgments are generated quickly after
instance, this is the case for the RTO used by TCP [RFC6298] and data arrives. For instance, this is the case for the RTO used
SCTP [RFC4960]. However, this is somewhat mis-leading as the by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat
expected latency is better framed as the "feedback time" (FT). mis-leading as the expected latency is better framed as the
"feedback time" (FT). In other words, the expectation is not
In other words, the expectation is not always simply a network always simply a network property, but includes additional time
property, but includes additional time before a sender should before a sender should reasonably expect a response to a query.
reasonably expect a response to a query.
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 resolver. When the request can be served from the resolver's a recursive resolver. When the request can be served from the
cache the FT likely well approximates the network RTT between resolver's cache the FT likely well approximates the network RTT
the client and resolver. However, on a cache miss the resolver between the client and resolver. However, on a cache miss the
will have to request the needed information from authoritative resolver will request the needed information from one or more
DNS servers, which will non-trivially increase the FT compared authoritative DNS servers, which will non-trivially increase the
to the RTT between the client and resolver. FT compared to the RTT between the client and resolver.
(a) In steady state the RTO MUST be set based on recent Therefore, we express the following requirements in terms of FT:
(a) In steady state the RTO SHOULD 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 delivery amount of time that the sender should wait for delivery
confirmation before retransmitting the given data. confirmation before retransmitting the given data.
(b) FT observations MUST be taken regularly. (b) FT observations SHOULD be taken regularly.
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 the requirement that performing RTO mechanism [AP99], hence this requirement that
the FT be sampled continuously throughout the lifetime of a the FT be sampled continuously throughout the lifetime of
connection. communication.
TCP takes an FT sample roughly once per RTT, or if using the
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 The notion of "regularly" SHOULD be defined as at least once
per RTT or as frequently as data is exchanged in cases where per RTT or as frequently as data is exchanged in cases where
that happens less frequently than once per RTT. However, we that happens less frequently than once per RTT. However, we
also recognize that it may not always be practical to take also recognize that it may not always be practical to take
an FT sample this often in all cases. Hence, this an FT sample this often in all cases. Hence, this
once-per-RTT definition of "regularly" is explicitly a once-per-RTT definition of "regularly" is explicitly a
"SHOULD" and not a "MUST". "SHOULD" and not a "MUST".
TCP takes an FT sample roughly once per RTT, or if using the
timestamp option [RFC7323] on each acknowledgment arrival.
[AP99] shows that both these approaches result in roughly
equivalent performance for the RTO estimator.
(c) FT observations MAY be taken from non-data exchanges. (c) FT observations MAY be taken from non-data exchanges.
Some protocols use keepalives, heartbeats or other messages Some protocols use keepalives, heartbeats or other messages
to exchange control information. To the extent that the to exchange control information. To the extent that the
latency of these transactions mirrors data exchange, they latency of these transactions mirrors data exchange, they
can be leveraged to take FT samples within the RTO can be leveraged to take FT samples within the RTO
mechanism. Such samples can help protocols keep their RTO mechanism. Such samples can help protocols keep their RTO
accurate during lulls in data transmission. However, given accurate during lulls in data transmission. However, given
that these messages may not be subject to the same delays as that these messages may not be subject to the same delays as
data transmission, we do not take a general view on whether data transmission, we do not take a general view on whether
skipping to change at page 7, line 22 skipping to change at page 6, line 43
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 detects a loss and a retransmission is (3) Each time the RTO is used to detect a loss and a retransmission
scheduled, the value of the RTO MUST be exponentially backed off is scheduled, the value of the RTO MUST be exponentially backed
such that the next firing requires a longer interval. The off such that the next firing requires a longer interval. The
backoff SHOULD be removed after the successful repair of the backoff SHOULD be removed after the successful repair of the
lost data and 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 (a la [RFC6298]).
This ensures network safety. This ensures network safety.
(4) Retransmissions triggered by the RTO mechanism MUST be taken as (4) Retransmissions triggered by the RTO mechanism MUST be taken as
indications of network congestion and the sending rate adapted indications of network congestion and the sending rate adapted
skipping to change at page 8, line 22 skipping to change at page 7, line 44
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 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 problems caused by this (per [AP99]), we are aware of no large scale network safety issues
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 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, 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.
skipping to change at page 8, line 36 skipping to change at page 8, line 4
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, 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.
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, David Black, Gorry Fairhurst, Jonathan Looney and Yuchung Cheng, David Black, Gorry Fairhurst, Mirja Kuhlewind,
Michael Scharf provided useful comments on a previous version of Jonathan Looney and Michael Scharf provided useful comments on a
this draft. 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,
 End of changes. 19 change blocks. 
89 lines changed or deleted 55 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/