| Internet-Draft | Adjusting ACK Frequency in Receiver | March 2025 |
| Du | Expires 4 September 2025 | [Page] |
This document describes a mechanism for adjusting ACK frequency in the receiver.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
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 4 September 2025.¶
Copyright (c) 2025 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.¶
In [I-D.ietf-tcpm-ack-rate-request], it is allowed that a sender to request the ACK rate to be used by a receiver. It is a straightforward way to modify the frequency of ACK.¶
However, in some scenario, it would be useful to enable the receiver to modify the frequency of ACK directly without the need of the signal from the sender. For example, for a long fat flow, the receiver would receive packets of the flow continuingly. Thus, the receiver can predict the arrivals of the packets of the flow, and accordingly modify the frequency of ACK.¶
For a transport session with long duration and high bandwidth, the receiver can predict the arrivals of the packet of the flow. According to the statistic of the arrive time of the packets, the receiver can speculate about the network status for the flow.¶
If every packet arrives in order, and at a relatively reasonable interval, the receiver can adjust the ACK frequency. For example, the receiver typically sends an ACK for at least every second segment received in a stream of full-sized segments, and it can be changed to send an ACK at least every third segment received in a stream of full-sized segments. An even bigger value would also be possible here, for example four segments.¶
If all the packets of the stream have a large size, for example a full-sized one is about 1500 bytes, the above descriptions would be simpler. The receiver would typically return an ACK after receiving every two packets, and it can be changed to return an ACK after receiving every three or more packets.¶
As an option in this document, the receiver can predict the receiving time of each packet. If the next packet is received within the predicted time interval, we regards the prediction as verified. According to the prediction result, we can change the policy of responding ACK for the future packets. In a certain period, if all the predictions are verified, the ACK rate could decrease, and if not all the prediction are verified, the ACK rate would increase. Of course, if an out-of-order packet is detected, an ACK will be triggered immediately [RFC5681].¶
Hence, the policy of responding ACK in the receiver for a TCP stream could be self-adjusted. A general procedure is described as follows:¶
As usual, the receiver would return an ACK every two packets.¶
If the predictions of successive N packets are all verified, the receiver can change the policy of returning ACK to a less frequent one, for example, returning an ACK after receiving every three packets. N is an integer greater than 1.¶
If an out-of-order packet is detected, an ACK will be triggered immediately, and the policy is changed back to the traditional one. Normally, it will go back to step 1 after a few moment.¶
Alternatively, the receiver can also predict multiple packets would be received within a certain period, and afterwards trigger the modification of the policy of responding ACK for the packets of the stream that would be received in future. The procedure is similar to the above one.¶
TBD.¶
TBD.¶