draft-ietf-tcpm-rto-consider-01.txt   draft-ietf-tcpm-rto-consider-02.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-01.txt February 29, 2016 File: draft-ietf-tcpm-rto-consider-02.txt April 5, 2016
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: August 29, 2016 Expires: October 5, 2016
Retransmission Timeout Considerations Retransmission Timeout Considerations
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 May 2, 2016. This Internet-Draft will expire on October 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 3, line 12 skipping to change at page 3, line 12
own subtle imprint on the specifics of the process to tilt the own subtle imprint on the specifics of the process to tilt the
tradeoff between correctness and responsiveness in some particular tradeoff between correctness and responsiveness in some particular
way. way.
At this point we recognize that often these specific tweaks are not At this point we recognize that often these specific tweaks are not
crucial for network safety. Hence, in this document we outline the crucial for network safety. Hence, in this document we outline the
high-level principles that are crucial for any retransmission high-level principles that are crucial for any retransmission
timeout scheme to follow. The intent is to then allow timeout scheme to follow. The intent is to then allow
implementations of protocols and applications to instantiate implementations of protocols and applications to instantiate
mechanisms that best realize their specific goals within this mechanisms that best realize their specific goals within this
framework. These specific mechanisms could be standardized or framework. These specific mechanisms could be standardized by the
ad-hoc, but as long as they adhere to the guidelines given in this IETF or ad-hoc, but as long as they adhere to the guidelines given
document they would be considered consistent with the standards. in this document they would be considered consistent with the
standards.
A non-goal of this document is to in any way specify individual A non-goal of this document is to in any way specify individual
deviations from standard RTO specifications that any particular deviations from current IETF standardized RTO specifications that
implementation may exhibit. Rather, we provide a set of any particular implementation may exhibit. Rather, we provide a set
over-arching guidelines that all RTO mechanisms should follow. of over-arching guidelines that all RTO mechanisms should follow.
Finally, we note the guidelines in this document are applicable to Finally, we note the guidelines in this document are applicable to
any protocol that uses an RTO mechanism. The examples and any protocol that uses an RTO mechanism. The examples and
discussion are framed in terms of TCP, however, that is an artifact 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 of where much of our experience with RTOs comes from and should not
be read as narrowing the scope of the guidelines. be read as narrowing the scope of the guidelines.
2 Guidelines 2 Guidelines
We now list the four guidelines that apply when utilizing a We now list the four guidelines that apply when utilizing a
skipping to change at page 4, line 21 skipping to change at page 4, line 21
data. data.
(b) FT observations MUST be taken regularly. (b) FT observations MUST be taken regularly.
The exact definition of "regularly" is deliberately left The exact definition of "regularly" is deliberately left
vague. TCP takes a FT sample roughly once per RTT, or if vague. TCP takes a FT sample roughly once per RTT, or if
using the timestamp option [RFC7323] on each acknowledgment using the timestamp option [RFC7323] on each acknowledgment
arrival. [AP99] shows that both these approaches result in arrival. [AP99] shows that both these approaches result in
roughly equivalent performance for the RTO estimator. roughly equivalent performance for the RTO estimator.
Additionally, [AP99] shows that taking only a single FT Additionally, [AP99] shows that taking only a single FT
sample per TCP connection is suboptimal. Therefore, for the sample per TCP connection is suboptimal and hence the
purpose of this guideline we state that FT samples SHOULD be requirement that the FT be sampled continuously throughout
taken at least once per RTT or as frequently as data is the lifetime of a connection. For the purpose of this
exchanged and ACKed if that happens less frequently than guideline, we state that FT samples SHOULD be taken at least
every RTT. However, we also recognize that it may not once per RTT or as frequently as data is exchanged and ACKed
always be practical to take a FT sample this often in all if that happens less frequently than every RTT. However, we
cases and hence this requirement is explicitly a "SHOULD" also recognize that it may not always be practical to take a
and not a "MUST". FT sample this often in all cases and hence this requirement
is explicitly a "SHOULD" and not a "MUST".
(c) FT samples used in the computation of the RTO MUST NOT be (c) FT samples used in the computation of the RTO MUST NOT be
ambiguous. ambiguous.
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 segment X is acknowledged at time t2. In
some cases, it is not clear which copy of X triggered the some cases, it is not clear which copy of X triggered the
ACK and hence the actual FT is either t2-t1 or t2-t0, but ACK and hence the actual FT is either t2-t1 or t2-t0, but
which is a mystery. Therefore, in this situation an which is a mystery. Therefore, in this situation an
implementation MUST use Karn's algorithm [KP87,RFC6298] and implementation MUST use Karn's algorithm [KP87,RFC6298] and
skipping to change at page 5, line 12 skipping to change at page 5, line 14
This ensures network safety. This ensures network safety.
(4) Retransmission timeouts MUST be taken as indications of (4) Retransmission timeouts MUST be taken as indications of
congestion in the network and the sending rate adapted using a congestion in the network and the sending rate adapted using a
standard mechanism (e.g., TCP collapses the congestion window to standard mechanism (e.g., TCP collapses the congestion window to
one segment [RFC5681]). one segment [RFC5681]).
This ensures network safety. This ensures network safety.
An exception is made to this rule if a standard mechanism is An exception is made to this rule if an IETF standardized
used to determine that a particular loss is due to a mechanism is used to determine that a particular loss is due to
non-congestion event (e.g., packet corruption). In such a case a non-congestion event (e.g., packet corruption). In such a
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.
3 Discussion 3 Discussion
We note that research has shown the tension between responsiveness We note that research has shown the tension between responsiveness
and correctness of TCP's RTO seems to be a fundamental tradeoff and correctness of TCP's RTO seems to be a fundamental tradeoff
[AP99]. That is, making TCP's RTO more aggressive (via the EWMA [AP99]. That is, making TCP's RTO more aggressive (via the EWMA
gains, lowering the minimum RTO, etc.) can reduce the time spent gains, lowering the minimum RTO, etc.) can reduce the time spent
skipping to change at page 5, line 44 skipping to change at page 5, line 46
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). Also, a number of (e.g., using different EWMA gains). Further, a number of
implementations use minimum RTOs that are less than the 1 second implementations use minimum RTOs that are less than the 1 second
specified in [RFC6298]. While the precise implications of this may specified in [RFC6298]. While the implication of these deviations
show more spurious retransmits (per [AP99]) we are aware of no large from the standard may be more spurious retransmits (per [AP99]), we
scale problems caused by this change to the minimum RTO. are aware of no large scale problems 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 guidelines fail safe in that they insist retransmissions the above guidelines 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, allowing implementers latitude in their instantiations of
an RTO mechanism does not somehow open the flood gates to aggressive an RTO mechanism does not somehow open the flood gates to aggressive
behavior. Since there is a downside to being aggressive the behavior. Since there is a downside to being aggressive the
incentives for proper behavior are retained in the mechanism. incentives for proper behavior are retained in the mechanism.
4 Security Considerations 4 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, Shawn Ostermann, Vern Paxson and the members of the Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson and the
TCPM and TCP-IMPL working groups. Ran Atkinson, Yuchung Cheng, members of the TCPM and TCP-IMPL working groups. Ran Atkinson,
Jonathan Looney and Michael Scharf provided useful comments on a Yuchung Cheng, Jonathan Looney and Michael Scharf provided useful
previous version of this draft. 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,
 End of changes. 11 change blocks. 
30 lines changed or deleted 33 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/