Coordinated Packet Loss Recovery and Congestion Control for High-Throughput WAN Transmission

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 ), delay (e.g., Swift), or bottleneck bandwidth (e.g., 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.

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 when, and only when, they appear in all capitals, as shown here.

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.
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 Section 19.3, with loss detection and congestion control defined in .
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.

Problem Statement

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.

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.

Coordinated ACK Delay Adjustment Mechanism

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.

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.

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.

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.

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.

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.

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.

Packet Format Extensions

QUIC ACK Frame Extension For QUIC , 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.

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.

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.

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.