QUIC Acknowledgment Frequency

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 5 September 2024.¶

Copyright Notice

Copyright (c) 2024 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

The QUIC transport protocol recommends to send an ACK frame after receiving at least two ack-eliciting packets; see Section 13.2 of [QUIC-TRANSPORT]. However, it leaves the determination of how frequently to send acknowledgments in response to ack-eliciting packets to the data receiver without any ability for the data sender to impact this behavior. This document specifies an extension to QUIC that permits an endpoint to request that its peer changes its behavior when sending or delaying acknowledgments.¶

This document defines a new transport parameter to announce the support of this extension and specifies two new frame types to request changes to the peer's acknowledgement behavior.¶

2. Motivation

A receiver acknowledges received packets, but it can delay sending these acknowledgments. Delaying acknowledgments can impact connection throughput, loss detection and congestion controller performance at a data sender, and CPU utilization at both a data sender and a data receiver.¶

Reducing the frequency of acknowledgments can improve connection and endpoint performance in the following ways:¶

• Sending UDP datagrams can be very CPU intensive on some platforms. A data receiver can decrease its CPU usage by reducing the number of acknowledgement-only packets that it sends. Experience shows that this reduction can be critical for high bandwidth connections.¶

• Similarly, receiving UDP datagrams can also be CPU intensive. Reducing the acknowledgement frequency therefore also reduces the CPU usage at the data sender as it has to receive and process fewer acknowledgment-only packets.¶

• For asymmetric link technologies, such as DOCSIS, LTE, and satellite, connection throughput in the forward path can become constrained when the reverse path is filled by acknowledgment packets [RFC3449]. When traversing such links, reducing the number of acknowledgments can achieve higher connection throughput, lower the impact on other flows or optimise the overall use of transmission resources [Cus22].¶

• The rate of acknowledgment packets can reduce link efficiency, including transmission opportunities or battery life, as well as transmission opportunities available to other flows sharing the same link.¶

As discussed in Section 8 however, there can be undesirable consequences to congestion control and loss recovery if a receiver unilaterally reduces the acknowledgment frequency. A sender's constraints on the acknowledgment frequency need to be taken into account to maximize congestion controller and loss recovery performance.¶

[QUIC-TRANSPORT] specifies a simple delayed acknowledgment mechanism that a receiver can use: send an acknowledgment for every other packet, and for every packet that is received out of order (Section 13.2.1 of [QUIC-TRANSPORT]). This does not allow a sender to signal its preferences or constraints. This extension provides a mechanism to solve this problem.¶

3. Negotiating Extension Use

After the successful negotiation of this extension two new frames can be used to provide guidance about delaying and sending of ACK frames to its peer. These frames are the ACK_FREQUENCY frame (see Section 4) and the IMMEDIATE_ACK frame (see Section 5).¶

Endpoints advertise their support of the extension described in this document by sending the following transport parameter (Section 7.2 of [QUIC-TRANSPORT]):¶

min_ack_delay (0xff04de1b):

A variable-length integer representing the minimum amount of time in microseconds by which the endpoint that is sending this value is able to delay an acknowledgment. This limit could be based on the receiver's clock or timer granularity. min_ack_delay is used by the peer to avoid requesting too small a value in the Requested Max Ack Delay field of the ACK_FREQUENCY frame.¶

An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay. Endpoints that support this extension MUST treat receipt of a min_ack_delay that is greater than the max_ack_delay as a connection error of type TRANSPORT_PARAMETER_ERROR. Note that while the endpoint's max_ack_delay transport parameter is in milliseconds (Section 18.2 of [QUIC-TRANSPORT]), min_ack_delay is specified in microseconds.¶

The min_ack_delay transport parameter is a unilateral indication of support for receiving ACK_FREQUENCY frames. If an endpoint sends the transport parameter, the peer is allowed to send ACK_FREQUENCY and IMMEDIATE_ACK frames independent of whether it also sends the min_ack_delay transport parameter or not.¶

Until an ACK_FREQUENCY or IMMEDIATE_ACK frame is received, sending the min_ack_delay transport parameter does not cause the endpoint to change its acknowledgment behavior.¶

Endpoints MUST NOT remember the value of the min_ack_delay transport parameter they received for use in a subsequent connection. Consequently, ACK_FREQUENCY and IMMEDIATE_ACK frames cannot be sent in 0-RTT packets, as per Section 7.4.1 of [QUIC-TRANSPORT].¶

This Transport Parameter is encoded as per Section 18 of [QUIC-TRANSPORT].¶

4. ACK_FREQUENCY Frame

Delaying acknowledgments as much as possible reduces both work done by the endpoints and network load. An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this delay at the peer. An endpoint signals the frequency it wants to receive ACK frames to its peer using an ACK_FREQUENCY frame, shown below:¶

ACK_FREQUENCY Frame {
  Type (i) = 0xaf,
  Sequence Number (i),
  Ack-Eliciting Threshold (i),
  Requested Max Ack Delay (i),
  Reordering Threshold (i),
}

Following the common frame format described in Section 12.4 of [QUIC-TRANSPORT], ACK_FREQUENCY frames have a type of 0xaf, and contain the following fields:¶

Sequence Number:

A variable-length integer representing the sequence number assigned to the ACK_FREQUENCY frame by the sender to allow receivers to ignore obsolete frames. A sending endpoint MUST send monotonically increasing values in the Sequence Number field to allow obsolete ACK_FREQUENCY frames to be ignored when packets are processed out of order.¶

Ack-Eliciting Threshold:

A variable-length integer representing the maximum number of ack-eliciting packets the recipient of this frame receives before sending an acknowledgment. A receiving endpoint SHOULD send at least one ACK frame when more than this number of ack-eliciting packets have been received. A value of 0 results in a receiver immediately acknowledging every ack-eliciting packet. By default, an endpoint sends an ACK frame for every other ack-eliciting packet, as specified in Section 13.2.2 of [QUIC-TRANSPORT], which corresponds to a value of 1.¶

Requested Max Ack Delay:

A variable-length integer representing the value to which the endpoint requests the peer update its max_ack_delay (Section 18.2 of [QUIC-TRANSPORT]). The value of this field is in microseconds, unlike the max_ack_delay transport parameter, which is in milliseconds. On receipt of a valid value, the endpoint SHOULD update its max_ack_delay to the value provided by the peer. Note that values of 2^14 or greater are invalid for max_ack_delay. A value smaller than the min_ack_delay advertised by the peer is also invalid. Receipt of an invalid value MUST be treated as a connection error of type FRAME_ENCODING_ERROR.¶

Reordering Threshold:

A variable-length integer that indicates the maximum packet reordering before eliciting an immediate ACK, as specified in Section 6.2. If no ACK_FREQUENCY frames have been received, the endpoint immediately acknowledges any subsequent packets that are received out-of-order, as specified in Section 13.2 of [QUIC-TRANSPORT], corresponding to a default value of 1. A value of 0 indicates out-of-order packets do not elicit an immediate ACK.¶

ACK_FREQUENCY frames are ack-eliciting and congestion controlled. When an ACK_FREQUENCY frame is lost, the sender is encouraged to send another ACK_FREQUENCY frame, unless an ACK_FREQUENCY frame with a larger Sequence Number value has already been sent. However, it is not forbidden to retransmit the lost frame (see Section 13.3 of [QUIC-TRANSPORT]), because the receiver will ignore duplicate or out-of-order ACK_FREQUENCY frames based on the Sequence Number.¶

A receiving endpoint MUST ignore a received ACK_FREQUENCY frame unless the Sequence Number value in the frame is greater than the largest processed value.¶

5. IMMEDIATE_ACK Frame

A sender can use an ACK_FREQUENCY frame to reduce the number of acknowledgments sent by a receiver, but doing so increases the likelihood that time-sensitive feedback is delayed as well. For example, as described in Section 8.3, delaying acknowledgments can increase the time it takes for a sender to detect packet loss. Sending an IMMEDIATE_ACK frame can help mitigate this problem.¶

An IMMEDIATE_ACK frame can be useful in other situations as well. For example, if a sender wants an immediate RTT measurement or if a sender wants to establish receiver liveness as quickly as possible. PING frames (Section 19.2 of [QUIC-TRANSPORT]) are ack-eliciting, but if a PING frame is sent without an IMMEDIATE_ACK frame, the receiver might not immediately send an ACK based on its local ACK strategy.¶

By definition IMMEDIATE_ACK frames are ack-eliciting and they are also congestion controlled. An endpoint SHOULD send a packet containing an ACK frame immediately upon receiving an IMMEDIATE_ACK frame. An endpoint MAY delay sending an ACK frame despite receiving an IMMEDIATE_ACK frame. For example, an endpoint might do this if a large number of received packets contain an IMMEDIATE_ACK or if the endpoint is under heavy load.¶

IMMEDIATE_ACK Frame {
  Type (i) = 0x1f,
}

6. Sending Acknowledgments

Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgments as specified in Section 13.2.1 of [QUIC-TRANSPORT].¶

On receiving an ACK_FREQUENCY frame and updating its max_ack_delay and Ack-Eliciting Threshold values (Section 4), the endpoint sends an acknowledgment when one of the following conditions are met:¶

• Since the last acknowledgment was sent, the number of received ack-eliciting packets is greater than the Ack-Eliciting Threshold.¶

• Since the last acknowledgment was sent, max_ack_delay amount of time has passed.¶

Further, the enpoint may send an acknowledgment earlier based on the value of the Reordering Threshold when a gap in the packet number order is detected, see Section 6.2.¶

Section 6.4 and Section 6.5 describe exceptions to this strategy.¶

  Receive 1
  Receive 3 -> 2 Missing
  Receive 4 -> 2 Missing
  Receive 5 -> Send ACK because of 2
  Receive 8 -> 6,7 Missing
  Receive 9 -> Send ACK because of 6, 7 Missing
  Receive 10 -> Send ACK because of 7

  Receive 1
  Receive 3 -> 2 Missing
  Receive 5 -> 2 Missing, 4 Missing
  Receive 6 -> 2 Missing, 4 Missing
  Receive 7 -> Send ACK because of 2, 4 Missing
  Receive 8 -> 4 Missing
  Receive 9 -> Send ACK because of 4

7. Computation of Probe Timeout Period

On sending an update to the peer's max_ack_delay, an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see Section 5.2.1 of [QUIC-RECOVERY].¶

Until the packet carrying the ACK_FREQUENCY frame is acknowledged, the endpoint MUST use the greater of the current max_ack_delay and the value that is in flight when computing the PTO period. Doing so avoids spurious PTOs that can be caused by an update that decreases the peer's max_ack_delay.¶

While it is expected that endpoints will have only one ACK_FREQUENCY frame in flight at any given time, this extension does not prohibit having more than one in flight. When using max_ack_delay for PTO computations, endpoints MUST use the maximum of the current value and all those in flight.¶

When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its max_ack_delay period before sending an acknowledgment. In such cases, the endpoint MAY therefore exclude the peer's max_ack_delay from its PTO calculation. When Reordering Threshold is set to 0 and loss causes the peer to not receive enough packets to trigger an immediate acknowledgment, the receiver will wait max_ack_delay, increasing the chances of a premature PTO. Therefore, if Reordering Threshold is set to 0, the PTO MUST be larger than the peer's max_ack_delay.¶

When sending PTO packets, one can include an IMMEDIATE_ACK frame to elicit an immediate acknowledgment. This avoids waiting the ack delay for acknowledgments of PTO packets, reducing tail latency and allowing the sender to exclude the peer's max_ack_delay from subsequent PTO calculations.¶

8. Determining Acknowledgment Frequency

This section provides some guidance on a sender's choice of acknowledgment frequency and discusses some additional considerations. Implementers can select an appropriate strategy to meet the needs of their applications and congestion controllers.¶

9. Security Considerations

An improperly configured or malicious data sender could request a data receiver to acknowledge more frequently than its available resources permit. However, there are two limits that make such an attack largely inconsequential. First, the acknowledgment rate is bounded by the rate at which data is received. Second, ACK_FREQUENCY and IMMEDIATE_ACK frames can only request an increase in the acknowledgment rate, but cannot enforce it.¶

Section 21.9 of [QUIC-TRANSPORT] provides further guidance on peer denial of service attacks that could abuse control frames, including ACK frames as well as the newly herein specified ACK_FREQUENCY and IMMEDIATE_ACK frames, to cause disproportional processing costs without observable impact on the state of the connection. Especially, the IMMEDIATE_ACK frame does not only imply processing cost for receiving and processing the control frame itself but can also cause additional sending of packets. However, in general, with this extension, a sender cannot force a receiver to acknowledge more frequently than the receiver considers safe based on its resource constraints.¶

10. IANA Considerations

This document defines a new transport parameter to advertise support of the extension described in this document and two new frame types to registered by IANQ in the respective "QUIC Protocol" registries under https://www.iana.org/assignments/quic/quic.xhtml.¶

Appendix A. Change Log

• RFC Editor's Note: Please remove this section prior to publication of a final version of this document.¶

Acknowledgments

The following people directly contributed key ideas that shaped this draft: Bob Briscoe, Kazuho Oku, Marten Seemann.¶

Authors' Addresses