Network Working Group Z. Li Internet-Draft Z. Du Intended status: Informational China Mobile Expires: 5 January 2027 J. Wang W. Cheng G. Zhang Centec X. Sun Inesa C. Zhao SAIA 4 July 2026 Coordinated Packet Loss Recovery and Congestion Control for High- Throughput WAN Transmission draft-li-hpwan-transmission-optimization-00 Abstract This document defines a coordinated mechanism between packet loss recovery (forward error correction) and congestion control for high- throughput WAN transmission. In high bandwidth-delay product (BDP) networks, loss recovery operations introduce additional processing delay at the receiver, which distorts the congestion controller's perception of network conditions. This mechanism addresses the problem by dynamically adjusting the ACK Delay field in acknowledgment packets to reflect loss recovery processing overhead, enabling the congestion control algorithm to accurately distinguish true network delay from recovery processing delay. The mechanism is applicable to QUIC, TCP, and RDMA transport protocols, and supports host-side, network-side, and coordinated deployment modes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Li, et al. Expires 5 January 2027 [Page 1] Internet-Draft HPWAN Transmission Optimization July 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 January 2027. Copyright Notice Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Loss Recovery Interference with Congestion Control . . . 4 3.2. Throughput Oscillation . . . . . . . . . . . . . . . . . 4 4. Coordinated ACK Delay Adjustment Mechanism . . . . . . . . . 4 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Service Type Adaptation . . . . . . . . . . . . . . . . . 5 4.3. ACK Delay Adjustment Rules . . . . . . . . . . . . . . . 5 4.3.1. No Loss Recovery Triggered . . . . . . . . . . . . . 5 4.3.2. Batch Recovery Scenario . . . . . . . . . . . . . . . 5 4.3.3. Frequent Recovery Scenario . . . . . . . . . . . . . 5 4.4. Deployment Modes . . . . . . . . . . . . . . . . . . . . 6 5. Packet Format Extensions . . . . . . . . . . . . . . . . . . 6 5.1. QUIC ACK Frame Extension . . . . . . . . . . . . . . . . 6 5.2. Applicability to Other Protocols . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Li, et al. Expires 5 January 2027 [Page 2] Internet-Draft HPWAN Transmission Optimization July 2026 1. Introduction Services such as bulk data transfer, inter-datacenter WAN interconnection, and large-scale distributed training and inference require high-throughput network transmission. While underlay network technology has advanced to 400G commercial capability and is evolving toward 800G and 1.6T, high bandwidth does not automatically translate to high throughput. The primary gap lies in the lack of transport- layer innovation for high-BDP, loss-prone network scenarios, particularly in the coordination between packet loss recovery and congestion control. Packet loss recovery mechanisms use redundancy coding algorithms (e.g., Reed-Solomon, Random Linear Codes, Tornado, Tetrys) to encode data packets with redundancy before transmission. When minor packet loss occurs, the receiver can reconstruct lost packets from redundant data without waiting for retransmission. Congestion control mechanisms detect network quality based on signals such as packet loss (e.g., CUBIC [CUBIC]), delay (e.g., Swift), or bottleneck bandwidth (e.g., BBR [BBR]), and adjust the congestion window (cwnd) and pacing rate to match network capacity. However, when both mechanisms operate simultaneously, the loss recovery module's processing delay interferes with the congestion controller's network quality assessment, leading to suboptimal cwnd and pacing rate calculations. This document proposes a coordination mechanism to resolve this interference. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology BDP (Bandwidth-Delay Product): The product of a link's bandwidth and its round-trip delay, representing the amount of data in flight. FEC (Forward Error Correction): Redundancy coding used for packet loss recovery without retransmission. cwnd (Congestion Window): The sender-side limit on the amount of data in flight. Li, et al. Expires 5 January 2027 [Page 3] Internet-Draft HPWAN Transmission Optimization July 2026 pacing rate: The rate at which the sender transmits packets. ACK Delay: A field in acknowledgment packets indicating the receiver's processing delay between packet reception and ACK generation. Defined in [RFC9000] Section 19.3, with loss detection and congestion control defined in [RFC9002]. RTT (Round-Trip Time): The time for a packet to travel from source to destination and back. Nmin: The minimum number of packets recovered in bulk that triggers batch recovery feedback adjustment. Tmax: The maximum inter-recovery interval that triggers frequent recovery feedback adjustment. S: A configurable constant representing the recovery delay compensation value. 3. Problem Statement 3.1. Loss Recovery Interference with Congestion Control When the loss recovery module operates, it introduces additional processing delay at the receiver. The receiver must wait for sufficient redundant data to arrive before performing decoding and recovery. This additional delay is included in end-to-end RTT measurements, causing the congestion control module to misinterpret it as increased network transmission delay and incorrectly reduce cwnd or pacing rate. 3.2. Throughput Oscillation The above misinterpretation causes unnecessary sender slowdown. Reduced sending rate may in turn cause insufficient redundant data at the receiver, leading to recovery failure, triggering retransmission, further increasing delay, and creating a negative feedback loop. This oscillation severely limits high-throughput transmission capability. 4. Coordinated ACK Delay Adjustment Mechanism Li, et al. Expires 5 January 2027 [Page 4] Internet-Draft HPWAN Transmission Optimization July 2026 4.1. Overview This mechanism adds loss-recovery delay awareness to the transport protocol's ACK mechanism. The receiver dynamically adjusts the ACK Delay field based on the actual operating intensity of the loss recovery module, providing the sender with accurate network delay feedback and eliminating recovery processing delay interference with congestion control. 4.2. Service Type Adaptation The working mode of loss recovery and congestion control SHOULD be selected based on service type. For High-Throughput, Non-Low-Latency Services: loss recovery SHOULD NOT be enabled; only congestion control and retransmission-based loss recovery are used, avoiding bandwidth waste from redundancy coding. For High-Throughput, Low- Latency Services: both loss recovery and congestion control MUST be enabled, coordinated by this mechanism. Upon packet loss, FEC-based recovery is attempted first; retransmission is used only if recovery fails. 4.3. ACK Delay Adjustment Rules The receiver MUST adjust the ACK Delay field based on the loss recovery module's operational state according to the following rules. 4.3.1. No Loss Recovery Triggered When loss recovery is not triggered, ACK Delay retains its standard definition: ACK_Delay = t2 - t1, where t1 is the packet reception time and t2 is the ACK generation and transmission time. 4.3.2. Batch Recovery Scenario When a large number of packets (n >= Nmin) are recovered via the loss recovery module: ACK_Delay = t2 - t1 + f1(n, ...), where f1() is a compensation function of recovered packet count n and other parameters. When the recovered packet count does not meet the batch threshold: ACK_Delay = t2 - t1 + S, where S is a configurable recovery delay compensation constant. 4.3.3. Frequent Recovery Scenario When packets are recovered frequently (inter-recovery interval t <= Tmax): ACK_Delay = t2 - t1 + f2(t, ...), where f2() is a compensation function of recovery interval t and other parameters. When the recovery frequency does not meet the threshold: ACK_Delay = t2 - t1 + S. Li, et al. Expires 5 January 2027 [Page 5] Internet-Draft HPWAN Transmission Optimization July 2026 4.4. Deployment Modes This mechanism supports three deployment modes: Host-Side Deployment -- the sending host/NIC performs FEC encoding and congestion control sending logic; the receiving host/NIC performs FEC decoding, ACK Delay adjustment, and congestion control receiving logic; no network- side changes required. Network-Side Deployment -- the sending gateway/router proxies sender traffic and performs FEC encoding and congestion control; the receiving gateway/router proxies receiver traffic and performs FEC decoding and ACK Delay adjustment; no host- side changes required. Coordinated Deployment -- host-side and network-side devices collaborate to perform the above functions. 5. Packet Format Extensions 5.1. QUIC ACK Frame Extension For QUIC [RFC9000], the ACK frame is extended with an optional TLV field to carry additional information from the receiver to the sender. New ACK frame type 0x04 and ACK_MP frame type 0xbaba02 are defined with an extended format that includes an optional TLV Extension carrying TLV Type, TLV Length, and TLV Value. The TLV Extension carries information such as recovery status, recovered packet count, and recovery interval. 5.2. Applicability to Other Protocols This mechanism MAY be adapted to TCP (via TCP Options extension) and RDMA (via CNP/NACK extension). The specific adaptation varies by protocol, but the core ACK Delay adjustment logic remains consistent. 6. Security Considerations ACK Delay Tampering: A malicious receiver could forge ACK Delay values to manipulate the sender's congestion control decisions. Senders SHOULD validate ACK Delay values for reasonableness and enforce upper-bound thresholds. TLV Injection: The new TLV fields in ACK frames could be exploited for malicious data injection. Implementations MUST strictly validate TLV content and enforce length checks. Network-Side Deployment Security: In gateway proxy mode, gateways can observe and modify transport-layer state. Gateway devices MUST implement strict access controls to prevent unauthorized modification. Li, et al. Expires 5 January 2027 [Page 6] Internet-Draft HPWAN Transmission Optimization July 2026 7. IANA Considerations This document requests IANA to allocate the following: (1) Registration of the extended ACK frame type 0x04 semantics and TLV sub-types in the QUIC Frame Types registry. (2) A formal QUIC frame type code point for ACK_MP frame type 0xbaba02. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9002] Iyengar, J. and I. Swett, "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . 9. Informative References [BBR] Cardwell, N., Cheng, Y., Gunn, C.S., Yeganeh, S.H., and V. Jacobson, "BBR: Congestion-Based Congestion Control", ACM Queue vol. 14, no. 5, 2016. [CUBIC] Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly high-speed TCP variant", ACM SIGOPS OSR vol. 42, no. 5, 2008. Authors' Addresses Zhiqiang Li China Mobile Beijing 100053 China Email: lizhiqiangyjy@chinamobile.com Li, et al. Expires 5 January 2027 [Page 7] Internet-Draft HPWAN Transmission Optimization July 2026 Zongpeng Du China Mobile Beijing 100053 China Email: duzongpeng@chinamobile.com Junjie Wang Centec Shanghai 201203 China Email: wangjj@centec.com Wei Cheng Centec Shanghai 201203 China Email: chengw@centec.com Guoying Zhang Centec Shanghai 201203 China Email: zhanggy@centec.com Xun Sun Inesa Shanghai 200030 China Email: sunxun@inesa.com Chunhao Zhao SAIA Shanghai 200125 China Email: chunhao.zhao@sh-aia.com Li, et al. Expires 5 January 2027 [Page 8]