draft-ietf-tcpm-rto-consider-08.txt   draft-ietf-tcpm-rto-consider-09.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-08.txt February 22, 2019 File: draft-ietf-tcpm-rto-consider-09.txt December 2, 2019
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: August 22, 2019 Expires: June 2, 2020
Retransmission Timeout Requirements Retransmission Timeout Requirements
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 August 22, 2019. This Internet-Draft will expire on June 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
Editorial Note
This version addresses Gorry's comments from the recent TCPM
meeting. The changes are fairly minor.
Jana's suggestion of moving from dealing with loss recovery
("retransmissions") to loss detection is not reflected in this
revision. This change will require small changes throughout the
document. The goal of this version is to ensure Gorry's suggestions
are accurately taken into account before starting on Jana's.
--allman
1 Introduction 1 Introduction
Reliable transmission is a key property for many network protocols Reliable transmission is a key property for many network protocols
and applications. Our protocols use various mechanisms to achieve and applications. Our protocols use various mechanisms to achieve
reliable data transmission. Often we use continuous or periodic reliable data transmission. Often we use continuous or periodic
acknowledgments from the recipient to inform the sender's notion of acknowledgments from the recipient to inform the sender's notion of
which pieces of data are missing and need to be retransmitted to which pieces of data are missing and need to be retransmitted to
ensure reliability. Alternatively, information coding---e.g., ensure reliability. Alternatively, information coding---e.g.,
FEC---can be used to achieve probabilistic reliability without FEC---can be used to achieve probabilistic reliability without
retransmissions. However, despite our best intentions and most retransmissions. However, despite our best intentions and most
skipping to change at page 6, line 27 skipping to change at page 6, line 39
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. When the request can be served from the
resolver's cache the FT likely well approximates the network RTT resolver's cache the FT likely well approximates the network RTT
between the client and resolver. However, on a cache miss the between the client and resolver. However, on a cache miss the
resolver will request the needed information from one or more resolver will request the needed information from one or more
authoritative DNS servers, which will non-trivially increase the authoritative DNS servers, which will non-trivially increase the
FT compared to the RTT between the client and resolver. FT compared to the RTT between the client and resolver.
Therefore, we express the following requirements in terms of FT: Therefore, we express the following requirements in terms of FT:
(a) In steady state the RTO SHOULD be set based on recent (a) In steady state the RTO SHOULD be set based on observations
observations of both the FT and the variance of the FT. of both the FT and the variance of the FT.
In other words, the RTO should represent an In other words, the RTO should represent an empirically-
empirically-derived reasonable amount of time that the derived reasonable amount of time that the sender should
sender should wait for delivery confirmation before wait for delivery confirmation before retransmitting the
retransmitting the given data. given data.
(b) FT observations SHOULD be taken regularly. (b) FT observations SHOULD be taken and incorporated into the
RTO at least once per RTT or as frequently as data is
exchanged in cases where that happens less frequently than
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
communication. communication.
The notion of "regularly" SHOULD be defined as at least once
per RTT or as frequently as data is exchanged in cases where
that happens less frequently than once per RTT. However, we
also recognize that it may not always be practical to take
an FT sample this often in all cases. Hence, this
once-per-RTT definition of "regularly" is explicitly a
"SHOULD" and not a "MUST".
As an example, TCP takes an FT sample roughly once per RTT, As an example, TCP takes an FT sample roughly once per RTT,
or if using the timestamp option [RFC7323] on each or if using the timestamp option [RFC7323] on each
acknowledgment arrival. [AP99] shows that both these acknowledgment arrival. [AP99] shows that both these
approaches result in roughly equivalent performance for the approaches result in roughly equivalent performance for the
RTO estimator. 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
skipping to change at page 7, line 45 skipping to change at page 7, line 53
is scheduled, the value of the RTO MUST be exponentially backed is scheduled, the value of the RTO MUST be exponentially backed
off 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) Loss detected by the RTO mechanism MUST be taken as an
indications of network congestion and the sending rate adapted indication of network congestion and the sending rate adapted
using a standard mechanism (e.g., TCP collapses the congestion using a standard mechanism (e.g., TCP collapses the congestion
window to one segment [RFC5681]). window to one segment [RFC5681]).
This ensures network safety. This ensures network safety.
An exception could be made to this rule if an IETF standardized An exception could be made to this rule if an IETF standardized
mechanism is used to determine that a particular loss is due to mechanism is used to determine that a particular loss is due to
a non-congestion event (e.g., packet corruption). In such a a non-congestion event (e.g., packet corruption). In such a
case 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
skipping to change at page 8, line 38 skipping to change at page 8, line 46
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 network safety issues (per [AP99]), we are aware of no large scale network safety issues
caused by this 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 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 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.
6 Security Considerations 6 Security Considerations
skipping to change at page 10, line 31 skipping to change at page 10, line 39
[RFC6675] Blanton, E., M. Allman, L. Wang, I. Jarvinen, M. Kojo, [RFC6675] Blanton, E., M. Allman, L. Wang, I. Jarvinen, M. Kojo,
Y. Nishida, "A Conservative Loss Recovery Algorithm Based on Y. Nishida, "A Conservative Loss Recovery Algorithm Based on
Selective Acknowledgment (SACK) for TCP", August 2012, RFC 6675. Selective Acknowledgment (SACK) for TCP", August 2012, RFC 6675.
[RFC7323] Borman D., B. Braden, V. Jacobson, R. Scheffenegger, "TCP [RFC7323] Borman D., B. Braden, V. Jacobson, R. Scheffenegger, "TCP
Extensions for High Performance", September 2014, RFC 7323. Extensions for High Performance", September 2014, RFC 7323.
Authors' Addresses Authors' Addresses
Mark Allman Mark Allman
International Computer Science Institute International Computer Science Institute
1947 Center St. Suite 600 1947 Center St. Suite 600
Berkeley, CA 94704 Berkeley, CA 94704
EMail: mallman@icir.org EMail: mallman@icir.org
http://www.icir.org/mallman http://www.icir.org/mallman
 End of changes. 12 change blocks. 
25 lines changed or deleted 33 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/