draft-ietf-tcpm-rto-consider-11.txt   draft-ietf-tcpm-rto-consider-12.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-11.txt April 30, 2020 File: draft-ietf-tcpm-rto-consider-12.txt May 4, 2020
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: October 30, 2020 Expires: November 4, 2020
Requirements for Time-Based Loss Detection Requirements for Time-Based Loss Detection
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
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 30, 2020. This Internet-Draft will expire on November 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 [AP99]. By not waiting long enough to accurately directions [AP99]. By not waiting long enough to accurately
determine a packet has been lost we risk sending unnecessary determine a packet has been lost we risk sending unnecessary
("spurious") retransmissions and needlessly lowering the ("spurious") retransmissions and needlessly lowering the
transmission rate. By waiting long enough that we are unambiguously transmission rate. By waiting long enough that we are unambiguously
certain a packet has been lost we cannot repair losses in a timely certain a packet has been lost we cannot repair losses in a timely
manner and we risk prolonging network congestion. manner and we risk prolonging network congestion.
Many protocols and applications use their own time-based loss Many protocols and applications use their own time-based loss
detection mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP detection mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP
[RFC3261]). At this point, our experience has lead to a recognition [RFC3261]). At this point, our experience leads to a recognition
that often specific tweaks that deviate from standardized time-based that often specific tweaks that deviate from standardized time-based
loss detectors do not materially impact network safety. Therefore, loss detectors do not materially impact network safety. Therefore,
in this document we outline a set of high-level protocol-agnostic in this document we outline a set of high-level protocol-agnostic
requirements for time-based loss detection. The intent is to requirements for time-based loss detection. The intent is to
provide a safe foundation on which implementations have the provide a safe foundation on which implementations have the
flexibility to instantiate mechanisms that best realize their flexibility to instantiate mechanisms that best realize their
specific goals. specific goals.
2 Context 2 Context
skipping to change at page 4, line 28 skipping to change at page 4, line 28
(S.2) The requirements in this document apply only to endpoint-to- (S.2) The requirements in this document apply only to endpoint-to-
endpoint unicast communication. Reliable multicast (e.g., endpoint unicast communication. Reliable multicast (e.g.,
[RFC5740]) protocols are explicitly outside the scope of this [RFC5740]) protocols are explicitly outside the scope of this
document. document.
Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that Protocols such as SCTP [RFC4960] and MP-TCP [RFC6182] that
communicate in a unicast fashion with multiple specific communicate in a unicast fashion with multiple specific
endpoints can leverage the requirements in this document endpoints can leverage the requirements in this document
provided they track state and follow the requirements for each provided they track state and follow the requirements for each
endpoint independently. I.e., if host A communicates with endpoint independently. I.e., if host A communicates with
hosts B and C, A needs to use independent time-based loss addresses B and C, A needs to use independent time-based loss
detector instances for traffic sent to B and C. detector instances for traffic sent to B and C.
(S.3) There are cases where state is shared across connections (S.3) There are cases where state is shared across connections
or flows (e.g., [RFC2140], [RFC3124]). State pertaining to or flows (e.g., [RFC2140], [RFC3124]). State pertaining to
time-based loss detection is often discussed as sharable. time-based loss detection is often discussed as sharable.
These situations raise issues that the simple flow-oriented These situations raise issues that the simple flow-oriented
time-based loss detection mechanism discussed in this document time-based loss detection mechanism discussed in this document
does not consider (e.g., how long to preserve state between does not consider (e.g., how long to preserve state between
connections). Therefore, while the general principles given connections). Therefore, while the general principles given
in Section 4 are likely applicable, sharing time-based loss in Section 4 are likely applicable, sharing time-based loss
skipping to change at page 8, line 7 skipping to change at page 8, line 7
event (e.g., packet corruption). In such a case a congestion event (e.g., packet corruption). In such a case a congestion
control action is not required. Additionally, congestion control action is not required. Additionally, congestion
control actions taken based on time-based loss detection could control actions taken based on time-based loss detection could
be reversed when a standard mechanism post-facto determines that be reversed when a standard mechanism post-facto determines that
the cause of the loss was not congestion (e.g., [RFC5682]). the cause of the loss was not congestion (e.g., [RFC5682]).
5 Discussion 5 Discussion
We note that research has shown the tension between the We note that research has shown the tension between the
responsiveness and correctness of time-based loss detection seems to responsiveness and correctness of time-based loss detection seems to
be a fundamental tradeoff in the context of TCP [AP99]. That is, be a fundamental tradeoff in the context of TCP [AP99]. That is,
making the RTO more aggressive (e.g., via changing TCP's EWMA gains, making the RTO more aggressive (e.g., via changing TCP's
lowering the minimum RTO, etc.) can reduce the time required to exponentially weighted moving average (EWMA) gains, lowering the
detect actual loss. However, at the same time, such aggressiveness minimum RTO, etc.) can reduce the time required to detect actual
leads to more cases of mistakenly declaring packets lost that loss. However, at the same time, such aggressiveness leads to more
ultimately arrived at the receiver. Therefore, being as aggressive cases of mistakenly declaring packets lost that ultimately arrived
as the requirements given in the previous section allow in any at the receiver. Therefore, being as aggressive as the requirements
particular situation may not be the best course of action because given in the previous section allow in any particular situation may
detecting loss---even if falsely---carries a requirement to invoke a not be the best course of action because detecting loss---even if
congestion response which will ultimately reduce the transmission falsely---carries a requirement to invoke a congestion response
rate. which will ultimately reduce the transmission rate.
While the tradeoff between responsiveness and correctness seems While the tradeoff between responsiveness and correctness seems
fundamental, the tradeoff can be made less relevant if the sender fundamental, the tradeoff can be made less relevant if the sender
can detect and recover from mistaken loss detection. Several can detect and recover from mistaken loss detection. Several
mechanisms have been proposed for this purpose, such as Eifel mechanisms have been proposed for this purpose, such as Eifel
[RFC3522], F-RTO [RFC5682] and DSACK [RFC2883,RFC3708]. Using such [RFC3522], F-RTO [RFC5682] and DSACK [RFC2883,RFC3708]. Using such
mechanisms may allow a data originator to tip towards being more mechanisms may allow a data originator to tip towards being more
responsive without incurring (as much of) the attendant costs of responsive without incurring (as much of) the attendant costs of
mistakenly declaring packets to be lost. mistakenly declaring packets to be lost.
Also, note, that in addition to the experiments discussed in [AP99], Also, note, that in addition to the experiments discussed in [AP99],
the Linux TCP implementation has been using various non-standard RTO the Linux TCP implementation has been using various non-standard RTO
mechanisms for many years seemingly without large scale problems mechanisms for many years seemingly without large scale problems
(e.g., using different EWMA gains than specified in [RFC6298]). (e.g., using different EWMA gains than specified in [RFC6298]).
Further, a number of implementations use minimum RTOs that are less Further, a number of implementations use a steady-state minimum RTO
than the 1 second specified in [RFC6298]. While the implication of that are less than the 1 second specified in [RFC6298] (which is
these deviations from the standard may be more spurious retransmits different from the initial RTO we specify in Section 4, Requirement
(per [AP99]), we are aware of no large scale network safety issues 1). While the implication of these deviations from the standard may
caused by this change to the minimum RTO. be more spurious retransmits (per [AP99]), we are aware of no large
scale network safety issues caused by this change to the minimum
RTO.
Finally, we note that while allowing implementations to be more Finally, we note that while allowing implementations to be more
aggressive could in fact increase the number of needless aggressive could in fact increase the number of needless
retransmissions the above requirements fail safe in that they insist retransmissions the above requirements fail safe in that they insist
on exponential backoff and a transmission rate reduction. on exponential backoff and a transmission rate reduction.
Therefore, providing implementers more latitude than they have Therefore, providing implementers more latitude than they have
traditionally been given in IETF specifications of RTO mechanisms traditionally been given in IETF specifications of RTO mechanisms
does not somehow open the flood gates to aggressive behavior. Since does not somehow open the flood gates to aggressive behavior. Since
there is a downside to being aggressive the incentives for proper there is a downside to being aggressive, the incentives for proper
behavior are retained in the mechanism. behavior are retained in the mechanism.
6 Security Considerations 6 Security Considerations
This document does not alter the security properties of time-based This document does not alter the security properties of time-based
loss detection mechanisms. See [RFC6298] for a discussion of these loss detection mechanisms. See [RFC6298] for a discussion of these
within the context of TCP. within the context of TCP.
Acknowledgments Acknowledgments
This document benefits from years of discussions with Ethan Blanton, This document benefits from years of discussions with Ethan Blanton,
Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, and the
members of the TCPM and TCP-IMPL working groups. Ran Atkinson, members of the TCPM and TCP-IMPL working groups. Ran Atkinson,
Yuchung Cheng, David Black, Gorry Fairhurst, Rahul Arvind Jadhav, Yuchung Cheng, David Black, Martin Duke, Gorry Fairhurst, Rahul
Mirja Kuhlewind, Nicolas Kuhn, Jonathan Looney and Michael Scharf Arvind Jadhav, Mirja Kuhlewind, Nicolas Kuhn, Jonathan Looney and
provided useful comments on previous versions of this document. Michael Scharf provided useful comments on previous versions of this
document.
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. 9 change blocks. 
24 lines changed or deleted 27 lines changed or added

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