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/ |