Requirements for Time-Based Loss Detection
RFC 8961

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17



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 can