Coordinated Packet Loss Recovery and Congestion Control for High-Throughput WAN Transmission
draft-li-hpwan-transmission-optimization-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9000]  Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May
              2021, <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9002]  Iyengar, J. and I. Swett, "QUIC Loss Detection and
              Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May
              2021, <https://www.rfc-editor.org/info/rfc9002>.

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]