draft-ietf-tcpm-rto-consider-15.txt   draft-ietf-tcpm-rto-consider-16.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-15.txt June 8, 2020 File: draft-ietf-tcpm-rto-consider-16.txt June 19, 2020
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: December 8, 2020 Expires: December 19, 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 December 8, 2020. This Internet-Draft will expire on December 19, 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 2, line 12 skipping to change at page 2, line 12
mechanism represents a balance between correctness and timeliness mechanism represents a balance between correctness and timeliness
and therefore no implementation suits all situations. This document and therefore no implementation suits all situations. This document
provides high-level requirements for time-based loss detectors provides high-level requirements for time-based loss detectors
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14, RFC 2119 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1 Introduction 1 Introduction
As a network of networks, the Internet consists of a large variety As a network of networks, the Internet consists of a large variety
of links and systems that combine to form "best effort" network of links and systems that support a wide variety of tasks and
paths. The path that traffic takes through the network is generally workloads. The service provided by the network varies from best
unknown a priori. Further, the path and the path properties that effort delivery among loosely connected components to highly
traffic experiences dynamically vary over time. As two examples, predictable delivery within constrained environments (e.g., between
consider delay and loss. In the general case, delay across a physically connected nodes, within a tightly controlled data
network path depends not only on distance, but also a number of center). Each path through the network has a set of path
variable components such as the route and the level of buffering in properties---e.g., available capacity, delay, packet loss. Given
intermediate devices. Since our wide-area network paths are best the range of networks that make up the Internet, these properties
effort, packet loss is a regular occurrence. While there are range from largely static to highly dynamic.
numerous causes of packet loss, the conservative general approach
that has historically served us well---and we use in this This document provides guidelines for developing an understanding of
document---is to treat loss as an implicit indication of network one path property: loss. In particular, we offer guidelines for
congestion. developing and implementing time-based loss detectors that have been
gradually learned over the last several decades. We focus on the
general case where the loss properties of a path are (a) unknown a
priori and (b) dynamically vary over time. Further, while there are
numerous root causes of packet loss, we leverage the conservative
notion that loss is an implicit indication of congestion. While
this stance is not always correct, as a general assumption it has
historically served us well. As we discuss further in section 2,
the guidelines in this document should be viewed as a general
default for best effort networks and not as optimal---or even
applicable---for all situations.
Given that packet loss is routine in best effort networks, loss Given that packet loss is routine in best effort networks, loss
detection is a crucial activity for many protocols and applications detection is a crucial activity for many protocols and applications
and is generally undertaken for two major reasons: and is generally undertaken for two major reasons:
(1) Ensuring reliable data delivery. (1) Ensuring reliable data delivery.
This requires a data sender to develop an understanding of This requires a data sender to develop an understanding of
which transmitted packets have not arrived at the receiver. which transmitted packets have not arrived at the receiver.
This knowledge allows the sender to retransmit missing data. This knowledge allows the sender to retransmit missing data.
skipping to change at page 3, line 41 skipping to change at page 3, line 52
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 with respect loss detectors do not materially impact network safety with respect
to congestion control. Therefore, in this document we outline a set to congestion control. Therefore, in this document we outline a set
of high-level protocol-agnostic requirements for time-based loss of high-level protocol-agnostic requirements for time-based loss
detection. The intent is to provide a safe foundation on which detection. The intent is to provide a safe foundation on which
implementations have the flexibility to instantiate mechanisms that implementations have the flexibility to instantiate mechanisms that
best realize their specific goals. best realize their specific goals.
2 Context 2 Context
This document is different from from the way we ideally like to This document is different from the way we ideally like to engineer
engineer systems. Usually, we strive to understand high-level systems. Usually, we strive to understand high-level requirements
requirements as a starting point. We then methodically engineer as a starting point. We then methodically engineer specific
specific protocols, algorithms and systems that meet these protocols, algorithms and systems that meet these requirements.
requirements. Within the IETF standards process we have derived Within the IETF standards process we have derived many time-based
many time-based loss detection schemes without benefit from some loss detection schemes without benefit from some over-arching
over-arching requirements document---because we had no idea how to requirements document---because we had no idea how to write such a
write such a document! Therefore, we made the best specific document! Therefore, we made the best specific decisions we could
decisions we could in response to specific needs. in response to specific needs.
At this point, however, the community's experience has matured to At this point, however, the community's experience has matured to
the point where we can define a set of general, high-level the point where we can define a set of general, high-level
requirements for time-based loss detection schemes. We now requirements for time-based loss detection schemes. We now
understand how to separate the strategies these mechanisms use that understand how to separate the strategies these mechanisms use that
are crucial for network safety from those small details that do not are crucial for network safety from those small details that do not
materially impact network safety. The requirements in this document materially impact network safety. The requirements in this document
may not be appropriate in all cases. In particular, the guidelines may not be appropriate in all cases. In particular, the guidelines
in section 4 are concerned with the general case, but specific in section 4 are concerned with the general case, but specific
situations may allow for more flexibility in terms of loss detection situations may allow for more flexibility in terms of loss detection
skipping to change at page 6, line 45 skipping to change at page 6, line 56
receive delivery confirmation and also often follows protocol receive delivery confirmation and also often follows protocol
behavior whereby acknowledgments are generated quickly after behavior whereby acknowledgments are generated quickly after
data arrives. For instance, this is the case for the RTO used data arrives. For instance, this is the case for the RTO used
by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat by TCP [RFC6298] and SCTP [RFC4960]. However, this is somewhat
mis-leading and the expected latency is better framed as the mis-leading and the expected latency is better framed as the
"feedback time" (FT). In other words, the expectation is not "feedback time" (FT). In other words, the expectation is not
always simply a network property, but can include additional always simply a network property, but can include additional
time before a sender should reasonably expect a response. time before a sender should reasonably expect a response.
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 recursive resolver. When the request can be served from the a recursive resolver [RFC1035]. When the request can be served
resolver's cache the FT likely well approximates the network RTT from the resolver's cache the FT likely well approximates the
between the client and resolver. However, on a cache miss the network RTT between the client and resolver. However, on a
resolver will request the needed information from one or more cache miss the resolver will request the needed information from
authoritative DNS servers, which will non-trivially increase the one or more authoritative DNS servers, which will non-trivially
FT compared to the network RTT between the client and resolver. increase the FT compared to the network RTT between the client
and resolver.
Therefore, we express the requirements in terms of FT. Again, Therefore, we express the requirements in terms of FT. Again,
for ease of exposition we use "RTO" to indicate the interval for ease of exposition we use "RTO" to indicate the interval
between a packet transmission and the decision the packet has between a packet transmission and the decision the packet has
been lost---regardless of whether the packet will be been lost---regardless of whether the packet will be
retransmitted. retransmitted.
(a) If/when available, the RTO SHOULD be set based on multiple (a) If/when available, the RTO SHOULD be set based on multiple
observations of the FT. observations of the FT.
In other words, the RTO should represent an empirically- In other words, the RTO should represent an empirically-
derived reasonable amount of time that the sender should derived reasonable amount of time that the sender should
wait for delivery confirmation before deciding the given wait for delivery confirmation before deciding the given
data is lost. Network paths are inherently dynamic and data is lost. Network paths are inherently dynamic and
therefore it is crucial to incorporate multiple FT samples therefore it is crucial to incorporate multiple FT samples
in the RTO to take into account the delay variation across in the RTO to take into account the delay variation across
time. time.
For example, TCP's RTO [RFC6298] would satisfy this For example, TCP's RTO [RFC6298] would satisfy this
requirement due to its use of an EWMA to combine multiple FT requirement due to its use of an exponentially-weighted
samples into a "smoothed RTT". In the name of moving average (EWMA) to combine multiple FT samples into a
conservativeness, TCP goes further to also include an "smoothed RTT". In the name of conservativeness, TCP goes
explicit variance term when computing the RTO. further to also include an explicit variance term when
computing the RTO.
(b) FT observations SHOULD be taken and incorporated into the (b) FT observations SHOULD be taken and incorporated into the
RTO at least once per RTT or as frequently as data is RTO at least once per RTT or as frequently as data is
exchanged in cases where that happens less frequently than exchanged in cases where that happens less frequently than
once per RTT. once per RTT.
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 this requirement that performing RTO mechanism [AP99], hence this requirement that
the FT be sampled continuously throughout the lifetime of the FT be sampled continuously throughout the lifetime of
skipping to change at page 9, line 55 skipping to change at page 10, line 14
7 IANA Considerations 7 IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
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, Martin Duke, Gorry Fairhurst, Rahul Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Gorry
Arvind Jadhav, Mirja Kuhlewind, Nicolas Kuhn, Jonathan Looney and Fairhurst, Rahul Arvind Jadhav, Mirja Kuhlewind, Nicolas Kuhn,
Michael Scharf provided useful comments on previous versions of this Jonathan Looney and Michael Scharf provided useful comments on
document. 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.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
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.
[CCDJ20] Cheng, Y., N. Cardwell, N. Dukkipati, P. Jha, "RACK: a [CCDJ20] Cheng, Y., N. Cardwell, N. Dukkipati, P. Jha, "RACK: a
time-based fast loss detection algorithm for TCP", time-based fast loss detection algorithm for TCP",
Internet-Draft draft-ietf-tcpm-rack-08.txt (work in progress), Internet-Draft draft-ietf-tcpm-rack-08.txt (work in progress),
March 2020. March 2020.
 End of changes. 10 change blocks. 
42 lines changed or deleted 58 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/