Requirements for Time-Based Loss Detection
RFC 8961
Document | Type |
RFC - Best Current Practice
(November 2020; No errata)
Also known as BCP 233
|
|
---|---|---|---|
Author | Mark Allman | ||
Last updated | 2020-11-23 | ||
Replaces | draft-allman-tcpm-rto-consider | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication (wg milestone: May 2020 - Submit document on R... ) | |
Document shepherd | Yoshifumi Nishida | ||
Shepherd write-up | Show (last changed 2020-06-22) | ||
IESG | IESG state | RFC 8961 (Best Current Practice) | |
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Martin Duke | ||
Send notices to | Yoshifumi Nishida <nsd.ietf@gmail.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) M. Allman Request for Comments: 8961 ICSI BCP: 233 November 2020 Category: Best Current Practice ISSN: 2070-1721 Requirements for Time-Based Loss Detection Abstract Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations. This document provides high- level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8961. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Terminology 2. Context 3. Scope 4. Requirements 5. Discussion 6. Security Considerations 7. IANA Considerations 8. References 8.1. Normative References 8.2. Informative References Acknowledgments Author's Address 1. Introduction As a network of networks, the Internet consists of a large variety of links and systems that support a wide variety of tasks and workloads. The service provided by the network varies from best-effort delivery among loosely connected components to highly predictable delivery within controlled environments (e.g., between physically connected nodes, within a tightly controlled data center). Each path through the network has a set of path properties, e.g., available capacity, delay, and packet loss. Given the range of networks that make up the Internet, these properties range from largely static to highly dynamic. This document provides guidelines for developing an understanding of one path property: packet loss. In particular, we offer guidelines for 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 varying 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 [RFC5681]. While this stance is not always correct, as a general assumption it has historically served us well [Jac88]. As we discuss further in Section 2, the guidelines in this document should be viewed as a general default for unicast communication across best-effort networks and not as optimal -- or even applicable -- for all situations. Given that packet loss is routine in best-effort networks, loss detection is a crucial activity for many protocols and applications and is generally undertaken for two major reasons: (1) Ensuring reliable data delivery This requires a data sender to develop an understanding of which transmitted packets have not arrived at the receiver. This knowledge allows the sender to retransmit missing data. (2) Congestion control As we mention above, packet loss is often taken as an implicit indication that the sender is transmitting too fast and is overwhelming some portion of the network path. Data senders canShow full document text