tcpm G. Zhao Internet-Draft R. Li Intended status: Informational China Mobile Expires: 18 April 2026 15 October 2025 ACK Frequency Adjustment Strategy Based on Congestion Control Algorithms draft-zhao-tcpm-ack-freq-adjustment-00 Abstract TCP Delayed ACK is a widely deployed mechanism that can effectively reduce protocol overhead in many scenarios. The TARR option has been defined, which allows a sender to request a specific ACK frequency from a receiver. However, there is no clear method for adjusting the ACK frequency during data transmission over a TCP connection. This document provides a method for adjusting the ACK frequency by considering the different phases of congestion control algorithms. 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/. 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 18 April 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Zhao & Li Expires 18 April 2026 [Page 1] Internet-Draft AFAS October 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. ACK frequency Adjustment Strategy Based on Congestion Control Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Adjusting ACK Frequency According to BBR Congestion Control Phases . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Adjusting ACK Frequency According to Reno-like Congestion Control Phases . . . . . . . . . . . . . . . . . . . . . 5 3. Experiment . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction The TCP Delayed ACKs mechanism, specified in [RFC1122], aims to reduce protocol overhead. This design allows combining multiple segments and saves ACK packets under many traffic patterns, leading to its widespread deployment. A TCP connection has different requirements for ACK feedback frequency during different congestion control phases. Effectively adjusting the ACK frequency plays a crucial role in calculating RTT and improving congestion control performance. TCP congestion control algorithms slide the congestion window upon receiving ACKs to regulate the sending rate. Currently, widely used congestion control algorithms include CUBIC and BBR[I-D.ietf-ccwg-bbr] . CUBIC is a typical RENO-type congestion control algorithm and is the default in operating systems like Linux and Windows. It uses a cubic function as the congestion window growth function during the congestion avoidance phase to improve network bandwidth utilization. RENO-type congestion control algorithms control the sending rate based on received ACK packets, Zhao & Li Expires 18 April 2026 [Page 2] Internet-Draft AFAS October 2025 adjust the congestion window to regulate the sending rate, and use lost packets as congestion signals to perform network congestion control. Their characteristics include slow start, congestion avoidance, fast retransmit, and fast recovery. The BBR congestion control algorithm primarily works by periodically probing the bottleneck bandwidth (bandwidth and delay) of the link and adjusting the congestion window size based on this information to achieve high bandwidth utilization and low transmission latency. BBR consists mainly of four phases: Startup, Drain, Probe Bandwidth, and Probe RTT. Startup phase: The main task of this phase is to rapidly increase the sending rate until the link's bottleneck bandwidth is reached. Drain phase: The main task of this phase is to drain the backlog of packets in the link to reduce network latency. Probe Bandwidth phase: The main task of this phase is to probe the link's bottleneck bandwidth to determine the optimal sending rate. Probe RTT phase: The main task of this phase is to probe the network's Round-Trip Time (RTT) to determine network stability. The latest versions of the BBR algorithm have introduced new phases, including cruise, refill, up, and down, to improve the design of the Probe Bandwidth phase. These enhancements aim to improve the fairness of BBR flows when sharing network capacity with other traffic and also include improved handling of packet loss. 2. ACK frequency Adjustment Strategy Based on Congestion Control Algorithms 2.1. Adjusting ACK Frequency According to BBR Congestion Control Phases 1. Startup Phase In the Startup phase, the sender needs to rapidly increase its sending rate to quickly reach the link's bottleneck bandwidth. To accelerate the rate increase, the ACK feedback frequency should be set to a high value to ensure the sender quickly receives acknowledgments from the receiver. Set the ACK feedback frequency to provide an immediate ACK after each data packet is received, meaning the receiver sends an ACK immediately for every data packet. 2. Drain Phase Zhao & Li Expires 18 April 2026 [Page 3] Internet-Draft AFAS October 2025 In the Drain phase, the sender's main task is to drain the backlog of packets in the link to reduce network latency. Since frequent sending rate adjustments are not necessary in this phase, the ACK feedback frequency should be set to a lower value to reduce unnecessary computational and bandwidth resource consumption.The ACK frequency can be determined according to the following formula[TACK]: f = min{bw/(L * MSS), β / RTT_min} Formula (1) Where: f is the current ACK feedback frequency. bw is the available bandwidth of the current network link. L is a constant, with a default value. MSS is the Maximum Segment Size. β is the number of packets sent per RTT_min. RTT_min is the minimum delay measured on the path of the transmission connection, corresponding to the BBR.min_rtt parameter measured by the BBR algorithm. This RTT value determines the minimum amount of time required for the connection to sustain transmission at the bottleneck bandwidth rate, thus determining the minimum amount of data required for the connection to achieve full utilization. 3. Probe Bandwidth Phase In the Probe Bandwidth phase, the sender's main tasks are to probe the link's bottleneck bandwidth to determine the optimal sending rate and to send data steadily at the current rate. BBRv1 Version:During the 1.25x speed-up phase, obtain one ACK per data packet and calculate the bottleneck bandwidth of the link.In other phases, calculate and adjust the ACK acquisition frequency according to Formula (1). BBRv2, BBRv3 Versions:The corresponding bandwidth probing phase is the "up" phase. During this phase, obtain one ACK per data packet and calculate the bottleneck bandwidth of the link. 4. Probe RTT Phase In the Probe RTT phase, the sender's main task is to probe the network's RTT to determine network stability. In the BBRv1 version, the sending rate or congestion window is reduced to 4 packets, and Zhao & Li Expires 18 April 2026 [Page 4] Internet-Draft AFAS October 2025 one ACK is obtained per data packet. In BBRv2 and v3 versions, the sending rate or congestion window is reduced to half of its original size, and one ACK is obtained per data packet. 5. Other Phases TBD. 2.2. Adjusting ACK Frequency According to Reno-like Congestion Control Phases TBD. 3. Experiment TBD. 4. IANA Considerations TBD. 5. Security Considerations TBD. 6. Contributors The following people have substantially contributed to this document: Zhiqiang Li lizhiqiangyjy@chinamobile.com Hongwei Yang yanghongwei@chinamoblie.com 7. Acknowledgements TBD. 8. References 8.1. 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, . Zhao & Li Expires 18 April 2026 [Page 5] Internet-Draft AFAS October 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [TACK] Li, T. and K. Zheng, "TACK: Improving Wireless Transport Performance by Taming Acknowledgments", Proceedings of the 2020 Conference of the ACM Special Interest Group on Data Communication (ACM SIGCOMM) , August 2020. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [I-D.ietf-ccwg-bbr] Cardwell, N., Swett, I., and J. Beshay, "BBR Congestion Control", Work in Progress, Internet-Draft, draft-ietf- ccwg-bbr-03, 7 July 2025, . Authors' Addresses Guangyu Zhao China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: zhaoguangyu@chinamobile.com Ruifeng Li China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: liruifengyjy@chinamobile.com Zhao & Li Expires 18 April 2026 [Page 6]