| Internet-Draft | HPWAN Transmission Optimization | July 2026 |
| Li, et al. | Expires 5 January 2027 | [Page] |
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.¶
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/.¶
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 (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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The receiver MUST adjust the ACK Delay field based on the loss recovery module's operational state according to the following rules.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶