The RACK-TLP Loss Detection Algorithm for TCP
RFC 8985

Document Type RFC - Proposed Standard (February 2021; No errata)
Authors Yuchung Cheng  , Neal Cardwell  , Nandita Dukkipati  , Priyaranjan Jha 
Last updated 2021-02-20
Replaces draft-cheng-tcpm-rack
Stream Internent Engineering Task Force (IETF)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication (wg milestone: Apr 2020 - Submit document on a... )
Document shepherd Michael Tüxen
Shepherd write-up Show (last changed 2020-11-05)
IESG IESG state RFC 8985 (Proposed Standard)
Action Holders
(None)
Consensus Boilerplate Yes
Telechat date
Responsible AD Martin Duke
Send notices to draft-ietf-tcpm-rack.all@ietf.org
IANA IANA review state IANA OK - No Actions Needed
IANA action state No IANA Actions


Internet Engineering Task Force (IETF)                          Y. Cheng
Request for Comments: 8985                                   N. Cardwell
Category: Standards Track                                   N. Dukkipati
ISSN: 2070-1721                                                   P. Jha
                                                            Google, Inc.
                                                           February 2021

             The RACK-TLP Loss Detection Algorithm for TCP

Abstract

   This document presents the RACK-TLP loss detection algorithm for TCP.
   RACK-TLP uses per-segment transmit timestamps and selective
   acknowledgments (SACKs) and has two parts.  Recent Acknowledgment
   (RACK) starts fast recovery quickly using time-based inferences
   derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP)
   leverages RACK and sends a probe packet to trigger ACK feedback to
   avoid retransmission timeout (RTO) events.  Compared to the widely
   used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP
   detects losses more efficiently when there are application-limited
   flights of data, lost retransmissions, or data packet reordering
   events.  It is intended to be an alternative to the DupAck threshold
   approach.

Status of This Memo

   This is an Internet Standards Track document.

   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
   Internet Standards 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/rfc8985.

Copyright Notice

   Copyright (c) 2021 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.  Background
     1.2.  Motivation
   2.  Terminology
   3.  RACK-TLP High-Level Design
     3.1.  RACK: Time-Based Loss Inferences from ACKs
     3.2.  TLP: Sending One Segment to Probe Losses Quickly with RACK
     3.3.  RACK-TLP: Reordering Resilience with a Time Threshold
       3.3.1.  Reordering Design Rationale
       3.3.2.  Reordering Window Adaptation
     3.4.  An Example of RACK-TLP in Action: Fast Recovery
     3.5.  An Example of RACK-TLP in Action: RTO
     3.6.  Design Summary
   4.  Requirements
   5.  Definitions
     5.1.  Terms
     5.2.  Per-Segment Variables
     5.3.  Per-Connection Variables
     5.4.  Per-Connection Timers
   6.  RACK Algorithm Details
     6.1.  Upon Transmitting a Data Segment
     6.2.  Upon Receiving an ACK
     6.3.  Upon RTO Expiration
   7.  TLP Algorithm Details
     7.1.  Initializing State
     7.2.  Scheduling a Loss Probe
     7.3.  Sending a Loss Probe upon PTO Expiration
     7.4.  Detecting Losses Using the ACK of the Loss Probe
       7.4.1.  General Case: Detecting Packet Losses Using RACK
       7.4.2.  Special Case: Detecting a Single Loss Repaired by the
               Loss Probe
   8.  Managing RACK-TLP Timers
   9.  Discussion
     9.1.  Advantages and Disadvantages
     9.2.  Relationships with Other Loss Recovery Algorithms
     9.3.  Interaction with Congestion Control
     9.4.  TLP Recovery Detection with Delayed ACKs
     9.5.  RACK-TLP for Other Transport Protocols
   10. Security Considerations
   11. IANA Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Acknowledgments
   Authors' Addresses

1.  Introduction

   This document presents RACK-TLP, a TCP loss detection algorithm that
   improves upon the widely implemented duplicate acknowledgment
   (DupAck) counting approach described in [RFC5681] and [RFC6675]; it
   is RECOMMENDED as an alternative to that earlier approach.  RACK-TLP
   has two parts.  Recent Acknowledgment (RACK) detects losses quickly
   using time-based inferences derived from ACK feedback.  Tail Loss
   Probe (TLP) triggers ACK feedback by quickly sending a probe segment
   to avoid retransmission timeout (RTO) events.

1.1.  Background

   In traditional TCP loss recovery algorithms [RFC5681] [RFC6675], a
   sender starts fast recovery when the number of DupAcks received
   reaches a threshold (DupThresh) that defaults to 3 (this approach is
Show full document text