draft-ietf-tcpm-rto-consider-05.txt   draft-ietf-tcpm-rto-consider-06.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-05.txt March 10, 2017 File: draft-ietf-tcpm-rto-consider-06.txt October 19, 2018
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: September 10, 2017 Expires: April 19, 2019
Retransmission Timeout Requirements Retransmission Timeout Requirements
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 September 10, 2017. This Internet-Draft will expire on April 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 2, line 21 skipping to change at page 2, line 21
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].
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
reports from the recipient to inform the sender's notion of which acknowledgments from the recipient to inform the sender's notion of
pieces of data are missing and need to be retransmitted to ensure which pieces of data are missing and need to be retransmitted to
reliability. Alternatively, information coding---e.g., FEC---can be ensure reliability. Alternatively, information coding---e.g.,
used to achieve probabilistic reliability without retransmissions. FEC---can be used to achieve probabilistic reliability without
However, despite our best intentions and most robust mechanisms, the retransmissions. However, despite our best intentions and most
only thing we can truly depend on is the passage of time and robust mechanisms, the only thing we can truly depend on is the
therefore our ultimate backstop to ensuring reliability is a timeout passage of time and therefore our ultimate backstop to ensuring
and re-try mechanism. That is, the sender sets some expectation for reliability is a timeout and re-try mechanism. That is, the sender
how long to wait for confirmation of delivery for a given piece of sets some expectation for how long to wait for confirmation of
data. When this time period passes without delivery confirmation delivery for a given piece of data. When this time period passes
the sender assumes the data was lost in transit and therefore without delivery confirmation the sender assumes the data was lost
schedules a retransmission. This process of ensuring reliability in transit and therefore schedules a retransmission. This process
via time-based loss detection and resending lost data is commonly of ensuring reliability via time-based loss detection and resending
referred to as a "retransmission timeout (RTO)" mechanism. lost data is commonly referred to as a "retransmission timeout
(RTO)" mechanism.
Various protocols have defined their own RTO mechanisms (e.g., TCP Various protocols have defined their own RTO mechanisms (e.g., TCP
[RFC6298], SCTP [RFC4960], SIP [RFC3261]). The specifics of [RFC6298], SCTP [RFC4960], SIP [RFC3261]). The specifics of
retransmission timeouts often represent a particular tradeoff retransmission timeouts often represent a particular tradeoff
between correctness and responsiveness [AP99]. In other words we between correctness and responsiveness [AP99]. In other words we
want to simultaneously: want to simultaneously:
- wait long enough to ensure the detection of loss is correct and - wait long enough to ensure the detection of loss is correct and
therefore a retransmission is in fact needed, and therefore a retransmission is in fact needed, and
- bound the delay we impose on applications before repairing - bound the delay we impose on applications before repairing
loss. loss.
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. I.e., towards either (a) withholding needed directions. I.e., towards either (a) withholding needed
retransmissions too long to ensure the original transmission is retransmissions too long to ensure the original transmission is
truly lost or (b) not waiting long enough---to help application truly lost or (b) not waiting long enough---to help application
responsiveness---and hence sending unnecessary (often denoted responsiveness---and hence sending unnecessary (often denoted
"spurious") retransmissions. "spurious") retransmissions.
We have found that even though the RTO procedure is standardized for At this point, our experience has lead to a recognition that often
some protocols (e.g., TCP [RFC6298]), implementations often add specific tweaks that deviate from standardized RTO mechanisms do not
their own subtle imprint on the specifics of the process to tilt the materially impact network safety. Therefore, in this document we
tradeoff between correctness and responsiveness in some particular outline a set of high-level protocol-agnostic requirements for RTO
way. mechanisms. The intent is to provide a safe foundation on which
implementations have the flexibility to instantiate mechanisms that
best realize their specific goals.
At this point we recognize that often these specific tweaks that 2 Context
deviate from standardized RTO mechanisms do not materially impact
network safety. Therefore, in this document we outline a set of
high-level protocol-agnostic requirements for RTO mechanisms. The
intent is to provide a safe foundation on which implementations have
the flexibility to instantiate mechanisms that best realize their
specific goals.
2 Scope This document is a bit "weird" in that it is backwards from the way
we generally like to engineer systems. Usually, we strive to
understand high-level requirements as a starting point. We then
methodically proceed to engineer specific protocols, algorithms and
systems that meet these requirements. Within the standards process
we have derived many retransmission timeouts without benefit from
some over-arching requirements document---because we had no idea how
to write such a requirements document! Therefore, we made the best
specific decisions we could in response to specific needs.
At this point, however, we believe the community's experience has
matured to the point where we can define a set of high-level
requirements for retransmission timers. That is, we now understand
how to separate the aspects of retransmission timers that are
crucial for network safety from those small details that do not
materially impact network safety. There are two basic benefits of
writing this high-level document post-facto:
- Existing retransmission timer mechanisms may be revisited with
an eye towards changing the small and less crucial details to
facilitate some benefit (e.g., performance), while at the same
time not sacrificing network safety.
- Future retransmission timers will have a solid basis of
experience to lean on rather than cobbling together a new
retransmission timer from scratch and/or pieces parts of other
specifications.
However, adding a requirements umbrella to a body of existing
specific retransmission timer specifications is inherently messy and
we run the risk of creating "inconsistencies". The correct way to
view this document is as the default case and these other
specifications as agreed upon deviations from the default. For
instance, [RFC3261] uses a smaller initial timeout than this
document specifies (requirement (1) in section 4). This situation
does not render useless the general guidance in this document, but
rather develops an initial retransmission timeout that is
appropriate in a specific context. Likewise, TCP's retransmission
timer has a minimum value of 1 second [RFC6298], whereas this
document does not specify that a minimum retransmission timeout is
necessary at all. Again, this situation should be viewed as
[RFC6298] providing a refinement for a specific case.
3 Scope
The principles we outline in this document are protocol-agnostic and The principles we outline in this document are protocol-agnostic and
widely applicable. We make the following scope statements about widely applicable. We make the following scope statements about
the application of the requirements discussed in Section 3: the application of the requirements discussed in Section 4:
(S.1) The requirements in this document apply only to timer-based (S.1) The requirements in this document apply only to timer-based
loss detection and retransmission. loss detection and retransmission.
While there are a bevy of uses for timers in protocols---from While there are a bevy of uses for timers in protocols---from
rate-based pacing to connection failure detection to making rate-based pacing to connection failure detection to making
congestion control decisions and beyond---these are outside congestion control decisions and beyond---these are outside
the scope of this document. the scope of this document.
(S.2) The requirements in this document only apply to cases where (S.2) The requirements in this document only apply to cases where
skipping to change at page 3, line 56 skipping to change at page 4, line 42
endpoint independently. I.e., if host A communicates with endpoint independently. I.e., if host A communicates with
hosts B and C, A must use independent RTOs for traffic sent to hosts B and C, A must use independent RTOs for traffic sent to
B and C. B and C.
(S.4) There are cases where state is shared across connections or (S.4) There are cases where state is shared across connections or
flows (e.g., [RFC2140], [RFC3124]). The RTO is one piece flows (e.g., [RFC2140], [RFC3124]). The RTO is one piece
state that is often discussed as sharable. These situations state that is often discussed as sharable. These situations
raise issues that the simple flow-oriented RTO mechanism raise issues that the simple flow-oriented RTO mechanism
discussed in this document does not consider (e.g., how long discussed in this document does not consider (e.g., how long
to preserve state between connections). Therefore, while the to preserve state between connections). Therefore, while the
general principles given in Section 3 are likely applicable, general principles given in Section 4 are likely applicable,
sharing RTOs across flows is outside the scope of this sharing RTOs across flows is outside the scope of this
document. document.
(S.5) The requirements in this document apply to reliable (S.5) The requirements in this document apply to reliable
transmission, but do not assume that all data transmitted transmission, but do not assume that all data transmitted
within a connection or flow is reliably sent. within a connection or flow is reliably sent.
E.g., a protocol like DCCP [RFC4340] could leverage the E.g., a protocol like DCCP [RFC4340] could leverage the
requirements in this document for the initial reliable requirements in this document for the initial reliable
handshake even though the protocol reverts to unreliable handshake even though the protocol reverts to unreliable
skipping to change at page 4, line 44 skipping to change at page 5, line 31
reliability. reliability.
E.g., within a complex protocol like TCP or SCTP we have E.g., within a complex protocol like TCP or SCTP we have
designed methods to detect and repair loss based on explicit designed methods to detect and repair loss based on explicit
endpoint state sharing [RFC2018,RFC4960,RFC6675]. These endpoint state sharing [RFC2018,RFC4960,RFC6675]. These
mechanisms are preferred over the RTO as they are often more mechanisms are preferred over the RTO as they are often more
timely and precise than the coarse-grained RTO. In these timely and precise than the coarse-grained RTO. In these
cases, the RTO becomes a last resort when the more advanced cases, the RTO becomes a last resort when the more advanced
mechanisms fail. mechanisms fail.
3 Requirements 4 Requirements
We now list the requirements that apply when designing We now list the requirements that apply when designing
retransmission timeout (RTO) mechanisms. retransmission timeout (RTO) mechanisms.
(1) In the absence of any knowledge about the latency of a path, the (1) In the absence of any knowledge about the latency of a path, the
RTO MUST be conservatively set to no less than 1 second. RTO MUST be conservatively set to no less than 1 second.
This requirement ensures two important aspects of the RTO. This requirement ensures two important aspects of the RTO.
First, when transmitting into an unknown network, First, when transmitting into an unknown network,
retransmissions will not be sent before an ACK would reasonably retransmissions will not be sent before an ACK would reasonably
skipping to change at page 5, line 41 skipping to change at page 6, line 27
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 recent
observations of both the FT and the variance of the FT. observations of both the FT and the variance of the FT.
In other words, the RTO should be based on a reasonable In other words, the RTO should represent an
amount of time that the sender should wait for delivery empirically-derived reasonable amount of time that the
confirmation before retransmitting the given data. sender should wait for delivery confirmation before
retransmitting the given data.
(b) FT observations SHOULD be taken regularly. (b) FT observations SHOULD be taken regularly.
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 The notion of "regularly" SHOULD be defined as at least once
per RTT or as frequently as data is exchanged in cases where per RTT or as frequently as data is exchanged in cases where
that happens less frequently than once per RTT. However, we that happens less frequently than once per RTT. However, we
also recognize that it may not always be practical to take also recognize that it may not always be practical to take
an FT sample this often in all cases. Hence, this an FT sample this often in all cases. Hence, this
once-per-RTT definition of "regularly" is explicitly a once-per-RTT definition of "regularly" is explicitly a
"SHOULD" and not a "MUST". "SHOULD" and not a "MUST".
TCP takes an FT sample roughly once per RTT, or if using the As an example, TCP takes an FT sample roughly once per RTT,
timestamp option [RFC7323] on each acknowledgment arrival. or if using the timestamp option [RFC7323] on each
[AP99] shows that both these approaches result in roughly acknowledgment arrival. [AP99] shows that both these
equivalent performance for the RTO estimator. approaches result in roughly equivalent performance for the
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
latency of these transactions mirrors data exchange, they latency of these transactions mirrors data exchange, they
can be leveraged to take FT samples within the RTO can be leveraged to take FT samples within the RTO
mechanism. Such samples can help protocols keep their RTO mechanism. Such samples can help protocols keep their RTO
accurate during lulls in data transmission. However, given accurate during lulls in data transmission. However, given
that these messages may not be subject to the same delays as that these messages may not be subject to the same delays as
skipping to change at page 7, line 7 skipping to change at page 7, line 49
This ensures network safety. This ensures network safety.
(4) Retransmissions triggered by the RTO mechanism MUST be taken as (4) Retransmissions triggered by the RTO mechanism MUST be taken as
indications of network congestion and the sending rate adapted indications 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.
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
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 (e.g., [RFC5682]). congestion after all (e.g., [RFC5682]).
4 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 retransmission timeouts seems to responsiveness and correctness of retransmission timeouts 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 EWMA gains,
lowering the minimum RTO, etc.) can reduce the time spent waiting on lowering the minimum RTO, etc.) can reduce the time spent waiting on
needed retransmissions. However, at the same time, such needed retransmissions. However, at the same time, such
aggressiveness leads to more needless retransmissions. Therefore, aggressiveness leads to more needless retransmissions. Therefore,
being as aggressive as the requirements given in the previous being as aggressive as the requirements given in the previous
section allow in any particular situation may not be the best course section allow in any particular situation may not be the best course
of action because an RTO expiration carries a requirement to invoke of action because an RTO expiration carries a requirement to invoke
skipping to change at page 7, line 57 skipping to change at page 8, line 44
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 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.
5 Security Considerations 6 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, 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, Mirja Kuhlewind, Yuchung Cheng, David Black, Gorry Fairhurst, Mirja Kuhlewind,
 End of changes. 16 change blocks. 
45 lines changed or deleted 87 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/