QUIC Acknowledgement 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 12 January 2023.¶

Copyright Notice

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

This document describes a QUIC extension for an endpoint to control its peer's delaying of acknowledgements.¶

2. Motivation

A receiver acknowledges received packets, but it can delay sending these acknowledgements. The delaying of acknowledgements 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 acknowledgement packets can improve connection and endpoint performance in the following ways:¶

• Sending UDP packets can be noticeably CPU intensive on some platforms. Reducing the number of packets that only contain acknowledgements can therefore reduce the amount of CPU consumed at a data receiver. Experience shows that this cost reduction can be significant for high bandwidth connections.¶
• Similarly, receiving and processing UDP packets can also be CPU intensive, and reducing acknowledgement frequency reduces this cost at a data sender.¶
• Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction becomes constrained when the reverse bandwidth is filled by acknowledgment packets. When traversing such links, reducing the number of acknowledgments allows connection throughput to scale much further.¶

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

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

3. Negotiating Extension Use

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 (0xff03de1a):

A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an acknowledgement. This limit could be based on the receiver's clock or timer granularity.¶

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 received 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 frames independent of whether it also sends the min_ack_delay transport parameter or not.¶

Receiving a min_ack_delay transport parameter indicates that the peer might send ACK_FREQUENCY frames in the future. Until an ACK_FREQUENCY frame is received, receiving this transport parameter does not cause the endpoint to change its acknowledgement behavior.¶

Endpoints MUST NOT remember the value of the min_ack_delay transport parameter they received. Consequently, ACK_FREQUENCY 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 acknowledgements 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),
  Request Max Ack Delay (i),
  Reserved (6),
  Ignore CE (1),
  Ignore Order (1)
}

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, see Section 5.¶

Ack-Eliciting Threshold:

A variable-length integer representing the maximum number of ack-eliciting packets the recipient of this frame can receive without sending an acknowledgment. In other words, an acknowledgement is sent when more than this number of ack-eliciting packets have been received. Since this is a maximum value, a receiver can send an acknowledgement earlier. A value of 0 results in a receiver immediately acknowledging every ack-eliciting packet.¶

Request 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. Sending a value smaller than the min_ack_delay advertised by the peer is invalid. Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION.¶

Reserved:

This field has no meaning in this version of ACK_FREQUENCY. The value of this field MUST be 0x00. Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR.¶

Ignore CE:

A 1-bit field representing a boolean truth value. This field is set to true by an endpoint that does not wish to receive an immediate acknowledgement when the peer receives CE-marked packets (Section 7.1). 0 represents 'false' and 1 represents 'true'.¶

Ignore Order:

A 1-bit field representing a boolean truth value. This field is set to true by an endpoint that does not wish to receive an immediate acknowledgement when the peer receives a packet out of order (Section 7.1). 0 represents 'false' and 1 represents 'true'.¶

ACK_FREQUENCY frames are ack-eliciting. However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger Sequence Number value has been sent.¶

An endpoint MAY send ACK_FREQUENCY frames multiple times during a connection and with different values.¶

An endpoint will have committed a max_ack_delay value to the peer, which specifies the maximum amount of time by which the endpoint will delay sending acknowledgments. When the endpoint receives an ACK_FREQUENCY frame, it MUST update this maximum time to the value proposed by the peer in the Request Max Ack Delay field.¶

5. Multiple ACK_FREQUENCY Frames

An endpoint can send multiple ACK_FREQUENCY frames, and each one of them can have different values in all fields. An endpoint MUST use a sequence number of 0 for the first ACK_FREQUENCY frame it constructs and sends, and a strictly increasing value thereafter.¶

An endpoint MUST allow reordered ACK_FREQUENCY frames to be received and processed, see Section 13.3 of [QUIC-TRANSPORT].¶

On the first received ACK_FREQUENCY frame in a connection, an endpoint MUST immediately record all values from the frame. The sequence number of the frame is recorded as the largest seen sequence number. The new Ack-Eliciting Threshold and Request Max Ack Delay values MUST be immediately used for delaying acknowledgements; see Section 7.¶

On a subsequently received ACK_FREQUENCY frame, the endpoint MUST check if this frame is more recent than any previous ones, as follows:¶

• If the frame's sequence number is not greater than the largest one seen so far, the endpoint MUST ignore this frame.¶
• If the frame's sequence number is greater than the largest one seen so far, the endpoint MUST immediately replace old recorded state with values received in this frame. The endpoint MUST start using the new values immediately for delaying acknowledgements; see Section 7. The endpoint MUST also replace the recorded sequence number.¶

6. IMMEDIATE_ACK Frame

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

An IMMEDIATE_ACK frame can be useful in other situations as well. For example, it can be used with a PING frame (Section 19.2 of [QUIC-TRANSPORT]) if a sender wants an immediate RTT measurement or if a sender wants to establish receiver liveness as quickly as possible.¶

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) = 0xac,
}

7. Sending Acknowledgments

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

On receiving an ACK_FREQUENCY frame and updating its recorded max_ack_delay and Ack-Eliciting Threshold values (Section 5), the endpoint MUST send an acknowledgement when one of the following conditions are met:¶

• Since the last acknowledgement was sent, the number of received ack-eliciting packets is greater than or equal to the recorded Ack-Eliciting Threshold.¶
• Since the last acknowledgement was sent, max_ack_delay amount of time has passed.¶

Section 7.1, Section 7.2, and Section 7.3 describe exceptions to this strategy.¶

An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all counters and timers related to delaying of acknowledgments are reset.¶

The receiver of an ACK_FREQUENCY frame can continue to process multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of [QUIC-TRANSPORT].¶

8. 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]. The endpoint MUST however wait until the ACK_FREQUENCY frame that carries this new value is acknowledged by the peer.¶

Until the 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 increases 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 acknowledgement. In such cases, the endpoint MAY therefore exclude the peer's 'max_ack_delay' from its PTO calculation. When Ignore Order is enabled and loss causes the peer to not receive enough packets to trigger an immediate acknowledgement, the receiver will wait 'max_ack_delay', increasing the chances of a premature PTO. Therefore, if Ignore Order is enabled, the PTO MUST be larger than the peer's 'max_ack_delay'.¶

9. Determining Acknowledgement 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.¶

10. Security Considerations

TBD.¶

11. IANA Considerations

TBD.¶

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