draft-ietf-tcpm-rto-consider-07.txt   draft-ietf-tcpm-rto-consider-08.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-07.txt February 6, 2019 File: draft-ietf-tcpm-rto-consider-08.txt February 22, 2019
Intended Status: Best Current Practice Intended Status: Best Current Practice
Expires: August 6, 2019 Expires: August 22, 2019
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 April 19, 2019. This Internet-Draft will expire on August 22, 2019.
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 34 skipping to change at page 2, line 34
reliability is a timeout and re-try mechanism. That is, the sender reliability is a timeout and re-try mechanism. That is, the sender
sets some expectation for how long to wait for confirmation of sets some expectation for how long to wait for confirmation of
delivery for a given piece of data. When this time period passes delivery for a given piece of data. When this time period passes
without delivery confirmation the sender assumes the data was lost without delivery confirmation the sender assumes the data was lost
in transit and therefore schedules a retransmission. This process in transit and therefore schedules a retransmission. This process
of ensuring reliability via time-based loss detection and resending of ensuring reliability via time-based loss detection and resending
lost data is commonly referred to as a "retransmission timeout lost data is commonly referred to as a "retransmission timeout
(RTO)" mechanism. (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]). In this document, our
retransmission timeouts often represent a particular tradeoff use of "RTO" does not refer to any one specific scheme, but rather
between correctness and responsiveness [AP99]. In other words we is a generic term that includes all timer-based retransmission
want to simultaneously: mechanisms. The specifics of retransmission timeouts often
represent a particular tradeoff between correctness and
responsiveness [AP99]. In other words we 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
skipping to change at page 5, line 26 skipping to change at page 5, line 28
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.
E.g., some protocols may leverage more than one retransmission
timer simultaneously. In these cases, the general guidance in
this document can be applied to all such timers.
4 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,
skipping to change at page 8, line 53 skipping to change at page 9, line 5
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,
Jonathan Looney and Michael Scharf provided useful comments on a Nicolas Kuhn, 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. 6 change blocks. 
9 lines changed or deleted 15 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/