The RACK-TLP Loss Detection Algorithm for TCP
RFC 8985
Document | Type |
RFC - Proposed Standard
(February 2021; No errata)
Was draft-ietf-tcpm-rack (tcpm WG)
|
|
---|---|---|---|
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 isShow full document text