From 90c7080c072907bff0b71a9c1c1dd0dad1ad5efc Mon Sep 17 00:00:00 2001 From: ID Bot Date: Mon, 1 Apr 2024 10:10:23 +0000 Subject: [PATCH] Script updating gh-pages from e8ef5bd. [ci skip] --- .../draft-ietf-quic-ack-frequency.html | 2034 +++++++++++++++++ .../draft-ietf-quic-ack-frequency.txt | 771 +++++++ ianswett-tweak-motivation/index.html | 45 + index.html | 8 + 4 files changed, 2858 insertions(+) create mode 100644 ianswett-tweak-motivation/draft-ietf-quic-ack-frequency.html create mode 100644 ianswett-tweak-motivation/draft-ietf-quic-ack-frequency.txt create mode 100644 ianswett-tweak-motivation/index.html diff --git a/ianswett-tweak-motivation/draft-ietf-quic-ack-frequency.html b/ianswett-tweak-motivation/draft-ietf-quic-ack-frequency.html new file mode 100644 index 0000000..f7e9468 --- /dev/null +++ b/ianswett-tweak-motivation/draft-ietf-quic-ack-frequency.html @@ -0,0 +1,2034 @@ + + + + + + +QUIC Acknowledgment Frequency + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftQUIC Acknowledgment FrequencyApril 2024
Iyengar, et al.Expires 3 October 2024[Page]
+
+
+
+
Workgroup:
+
QUIC
+
Internet-Draft:
+
draft-ietf-quic-ack-frequency-latest
+
Published:
+
+ +
+
Intended Status:
+
Standards Track
+
Expires:
+
+
Authors:
+
+
+
J. Iyengar
+
Fastly
+
+
+
I. Swett
+
Google
+
+
+
M. Kühlewind
+
Ericsson
+
+
+
+
+

QUIC Acknowledgment Frequency

+
+

Abstract

+

This document specifies an extension to QUIC that permits an endpoint to +request that its peer changes its behavior when sending or delaying acknowledgments.

+
+
+

+Note to Readers +

+

Discussion of this draft takes place on the QUIC working group mailing list +(quic@ietf.org), which is archived at +https://mailarchive.ietf.org/arch/search/?email_list=quic. Source +code and issues list for this draft can be found at +https://github.com/quicwg/ack-frequency.

+

Working Group information can be found at https://github.com/quicwg.

+
+
+
+

+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 3 October 2024.

+
+
+ +
+
+ ▲

+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.

+
+
+

+1.1. Terms and Definitions +

+

The keywords "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.

+

In the rest of this document, "sender" refers to a QUIC data sender (and +acknowledgment receiver). Similarly, "receiver" refers to a QUIC data receiver +(and acknowledgment sender).

+

This document uses terms, definitions, and notational conventions described in +Section 1.2 and Section 1.3 of [QUIC-TRANSPORT].

+
+
+
+
+
+
+

+2. Motivation +

+

A receiver acknowledges received packets, but can delay sending these +acknowledgments. Delaying acknowledgments can impact a data sender's +throughput, loss detection and congestion controller performance, as well +as CPU utilization at both endpoints.

+

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

+
    +
  • +

    Sending UDP datagrams is very CPU intensive on some platforms. A data +receiver can decrease its CPU usage by reducing the number of +acknowledgement-only packets sent. 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 also reduces the data sender's CPU usage because +it receives and processes 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.

    +
    • +
+

However, As discussed in Section 8, a unilateral reduction in +acknowledgement frequency can lead to undesirable consequences for congestion +control and loss recovery.

+

[QUIC-TRANSPORT] specifies a simple delayed acknowledgment mechanism +(Section 13.2.1 of [QUIC-TRANSPORT]). A data sender's constraints on the +acknowledgment frequency need to be taken into account to maximize +congestion controller and loss recovery performance. This extension provides +a mechanism for a data sender to signal its preferences and constraints.

+
+
+
+
+

+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.

+
+
+

+6.1. Response to long idle periods +

+

It is important to receive timely feedback after long idle periods, +e.g. update stale RTT measurements. When no acknowledgment has been sent in +over one smoothed round trip time, receivers are encouraged to send an +acknowledgment soon after receiving an ack-eliciting packet. This is not an +issue specific to this document, but the mechanisms specified herein could +create excessive delays.

+
+
+
+
+

+6.2. Response to Out-of-Order Packets +

+

As specified in Section 13.2.1 of [QUIC-TRANSPORT], endpoints are expected to +send an acknowledgment immediately on receipt of a reordered ack-eliciting +packet with a smaller packet number than the highest-numbered ack-eliciting packet +or with a higher packet number when there are missing packets between that packet +and the highest-numbered ack-eliciting packet. +This extension modifies that behavior when an ACK_FREQUENCY frame with +a Reordering Threshold value other than 1 has been received.

+

If the most recent ACK_FREQUENCY frame received from the peer has a Reordering +Threshold value of 0, the endpoint SHOULD NOT send an immediate +acknowledgment in response to packets received out of order, and instead +rely on the peer's Ack-Eliciting Threshold and Requested Max Ack Delay +for sending acknowledgments.

+

If the most recent ACK_FREQUENCY frame received from the peer has a Reordering +Threshold value larger than 1, the endpoint tests the amount of reordering +before deciding to send an acknowledgment. The specification uses the following +definitions:

+
+
Largest Unacked:
+
+

The largest packet number among all received ack-eliciting packets.

+
+
+
Largest Acked:
+
+

The Largest Acknowledged value sent in an ACK frame.

+
+
+
Largest Reported:
+
+

The largest packet number that could be declared lost with the specified +Reordering Threshold, which is Largest Acked - Reordering Threshold + 1.

+
+
+
Unreported Missing:
+
+

Packets with packet numbers between the Largest Unacked and Largest Reported +that have not yet been received.

+
+
+
+

An endpoint that receives an ACK_FREQUENCY frame with a non-zero Reordering +Threshold value SHOULD send an immediate ACK when the gap +between the smallest Unreported Missing packet and the Largest Unacked is greater +than or equal to the Reordering Threshold value. Sending this additional ACK will +reset the max_ack_delay timer and Ack-Eliciting Threshold counter (as any ACK +would do).

+

See Section 6.2.1 for examples explaining this behavior. See Section 6.3 +for guidance on how to choose the reordering threshold value when sending +ACK_FREQUENCY frames.

+
+
+

+6.2.1. Examples +

+

When the reordering threshold is 1, any time a packet is received +and there is a missing packet, an immediate acknowledgement is sent.

+

If the reordering theshold is 3 and acknowledgements are only sent due to reordering:

+
+
+  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
+
+
+

Note that in this example, the receipt of packet 9 triggers an ACK +that reports both packets 6 and 7 as missing. However, +the receipt of packet 10 needs to trigger another immediate ACK +because only with the reporting of the successful receiption of +packet 10, the sender will be able to declare packet 7 as lost +(with a reordering threshold of 3).

+

If the reordering threshold is 5 and acknowledgements are only sent due to reordering:

+
+
+  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
+
+
+
+
+
+
+
+
+

+6.3. Setting the Reordering Threshold value +

+

To ensure timely loss detection, it is optimal to send a Reordering +Threshold value of 1 less than the packet threshold used by the data sender for +loss detection. If the threshold is smaller, an acknowledgement is (unnecessarily) sent before the +packet can be declared lost based on the packet threshold. If the value is +larger, it causes unnecessary delays. (Section 18.2 of [QUIC-RECOVERY]) +recommends a default packet threshold for loss detection of 3, equivalent to +a Reordering Threshold of 2.

+
+
+
+
+

+6.4. Expediting Explicit Congestion Notification (ECN) Signals +

+

If the Ack-Eliciting Threshold is larger than 1, an endpoint SHOULD send +an immediate acknowledgement when a packet marked with the ECN Congestion +Experienced (CE) [RFC3168] codepoint in the IP header is received and +the previously received packet was not marked CE. From there on, if multiple +CE-marked packets are received in a row or only non-CE-marked packet received, +the endpoint resumes sending acknowledgements based on the Ack-Eliciting +Threshold or max_ack_delay. This results in sending an immediate +acknowledgement only when there is a transition from non-CE-marked +to CE-marked.

+

Doing this maintains the peer's response time to congestion events, while also +reducing the ACK rate compared to Section 13.2.1 of [QUIC-TRANSPORT] during +extreme congestion or when peers are using DCTCP [RFC8257] or other +congestion controllers (e.g. [I-D.ietf-tsvwg-aqm-dualq-coupled]) that mark +more frequently than classic ECN [RFC3168].

+
+
+
+
+

+6.5. Batch Processing of Packets +

+

To avoid sending multiple acknowledgments in rapid succession, an endpoint can +process all packets in a batch before determining whether to send an ACK frame +in response, as stated in Section 13.2.2 of [QUIC-TRANSPORT].

+
+
+
+
+
+
+

+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.

+
+
+

+8.1. Congestion Control +

+

A sender needs to be responsive to notifications of congestion, such as +a packet loss or an ECN CE marking. Decreasing the acknowledgment frequency +can delay a sender's response to network congestion or cause it to underutilize +the available bandwidth.

+

To limit the consequences of reduced acknowledgment frequency, a sender +can use the extension in this draft to request a receiver +to send an acknowledgment at least once per round trip, +when there are ack-eliciting packets in flight, in the following ways:

+

A sender can set the Requested Max Ack Delay value +to no more than the estimated round trip time. +The sender can also improve feedback and robustness to +variation in the path RTT by setting the Ack-Eliciting Threshold +to a value no larger than number of maximum-sized packets that fit +into the current congestion window. +Alternatively, a sender can send an IMMEDIATE_ACK frame if no acknowledgement +has been received for more than one round trip time. Although if the +packet containing an IMMEDIATE_ACK is lost, detection of that loss +will be delayed by the Reordering Threshold or Requested Max Ack Delay.

+

When setting the Requested Max Ack Delay as a function of the RTT, it is usually +better to use the Smoothed RTT (smoothed_rtt) (Section 5.3 of [QUIC-RECOVERY]) or another +estimate of the typical RTT, but not the minimum RTT (min_rtt) +(Section 5.2 of [QUIC-RECOVERY]). This avoids eliciting an +unnecessarily high number of acknowledgments when min_rtt is much smaller than +smoothed_rtt.

+

Note that the congestion window and the RTT estimate change over the lifetime of a +connection and therefore might require sending updates in an ACK_FREQUENCY frames to +ensure optimal performance, though not every change should trigger an update. +Usually, it is not necessary to send an ACK_FREQUENCY frame more than once per +RTT and likely it needs to be sent even less frequently. +Ideally, an ACK_FREQUENCY frame is sent only when a relevant change +in the congestion window or smoothed RTT is detected that impacts the local +setting of the reordering threshold or locally-selected calculation of the +either Ack-Eliciting Threshold or the Requested Max Ack Delay.

+

It is possible that the RTT is smaller than the receiver's timer granularity, +as communicated via the min_ack_delay transport parameter, preventing the +receiver from sending an acknowledgment every RTT in time unless packets are +acknowledged immediately. In these cases, Reordering Threshold values other than 1 +can delay loss detection more than an RTT.

+
+
+

+8.1.1. Application-Limited Connections +

+

A congestion controller that is limited by the congestion window relies upon receiving +acknowledgments to send additional data into the network. An increase in +acknowledgment delay increases the delay in sending data, which can reduce the +achieved throughput. Congestion window growth can also depend upon receiving +acknowledgments. This can be particularly significant in slow start +(Section 7.3.1 of [QUIC-RECOVERY]), when delaying acknowledgments can delay +the increase in congestion window and can create larger packet bursts.

+

If the sender is application-limited, acknowledgments can be delayed +unnecessarily when entering idle periods. Therefore, if no further data is +buffered to be sent, a sender can send an IMMEDIATE_ACK frame with the last data +packet before an idle period to avoid waiting for the ack delay.

+

If there are no inflight packets, no acknowledgments will be received for at least +a round trip when sending resumes. The max_ack_delay and Ack-Eliciting Threshold +values used by the receiver can further delay acknowledgments. In this case, the +sender can include an IMMEDIATE_ACK or ACK_FREQUENCY frame in the first +Ack-Eliciting packet to avoid waiting for substantially more than a round trip +for an acknowledgment.

+
+
+
+
+
+
+

+8.2. Burst Mitigation +

+

Receiving an acknowledgment can allow a sender to release new packets into the +network. If a sender is designed to rely on the timing of peer acknowledgments +("ACK clock"), delaying acknowledgments can cause undesirable bursts of data +into the network. In keeping with Section 7.7 of [QUIC-RECOVERY], a sender +can either employ pacing or limit bursts to the initial congestion window.

+
+
+
+
+

+8.3. Loss Detection and Timers +

+

Acknowledgments are fundamental to reliability in QUIC. Consequently, +delaying or reducing the frequency of acknowledgments can cause loss detection +at the sender to be delayed.

+

A QUIC sender detects loss using packet thresholds on receiving an +acknowledgment (Section 6.1.1 of [QUIC-RECOVERY]); delaying the +acknowledgment therefore delays this method of detecting losses.

+

Reducing acknowledgment frequency reduces the number of RTT samples that a +sender receives (Section 5 of [QUIC-RECOVERY]), making a sender's RTT estimate +less responsive to changes in the path's RTT. As a result, any mechanisms that +rely on an accurate RTT estimate, such as time-threshold-based loss detection (Section 6.1.2 of [QUIC-RECOVERY]) or the Probe Timeout (PTO) (Section 6.2 of [QUIC-RECOVERY]), +will be less responsive to changes in the path's RTT, resulting in either +delayed or unnecessary packet transmissions.

+

A sender might use timers to detect loss of PMTU probe packets +(Section 14 of [QUIC-TRANSPORT]). A sender MAY +bundle an IMMEDIATE_ACK frame with any PMTU probes to avoid triggering such +timers.

+
+
+
+
+

+8.4. Connection Migration +

+

To avoid additional delays to connection migration confirmation when using this +extension, a client can bundle an IMMEDIATE_ACK frame with the first non-probing +frame (Section 9.2 of [QUIC-TRANSPORT]) it sends or it can send only an +IMMEDIATE_ACK frame, which is a non-probing frame.

+

An endpoint's congestion controller and RTT estimator are reset upon +confirmation of migration (Section 9.4 of [QUIC-TRANSPORT]); +this changes the pattern of acknowledgments received after migration.

+

Therefore, an endpoint that has sent an ACK_FREQUENCY frame earlier in the +connection ought to send a new ACK_FREQUENCY frame upon confirmation of +connection migration with updated information, e.g. to consider the new RTT estimate.

+
+
+
+
+
+
+

+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.

+
+
+

+10.1. QUIC Transport Parameter +

+

The following entry in Table 1 has been requested to be provisionally added to +the "QUIC Transport Parameters" registry under the "QUIC Protocol" heading.

+
+ + + + + + + + + + + + + + + + +
+Table 1: +Addition to QUIC Transport Parameters Entries +
ValueParameter Name.Specification
0xff04de1bmin_ack_delay + Section 3 +
+
+

When this document is approved, IANA is requested to assign a permanent allocation +of a codepoint in the 0-63 range to replace the provisional codepoint described above.

+
+
+
+
+

+10.2. QUIC Frame Types +

+

The following frame types have requested to be provisionally added to the "QUIC Frame Types" +registry under the "QUIC Protocol" heading.

+
+ + + + + + + + + + + + + + + + + + + + + +
+Table 2: +Addition to QUIC Frame Types Entries +
ValueFrame NameSpecification
0xafACK_FREQUENCY + Section 4 +
0x1fIMMEDIATE_ACK + Section 5 +
+
+

When this document is approved, IANA is requested to change the registration to +a permanent allocation of these frame types with the values described above.

+
+
+
+
+
+

+11. References +

+
+
+

+11.1. Normative References +

+
+
[QUIC-TRANSPORT]
+
+Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/rfc/rfc9000>.
+
+
[QUIC-RECOVERY]
+
+Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, , <https://www.rfc-editor.org/rfc/rfc9002>.
+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
+
+
[RFC8174]
+
+Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
+
+
+
+
+
+
+

+11.2. Informative References +

+
+
[Cus22]
+
+Custura, A., Jones, T., Secchi, R., and G. Fairhurst, "Reducing the acknowledgement frequency in IETF QUIC", DOI 10.1002/sat.1466, name IJSCN, , <https://doi.org/10.1002/sat.1466>.
+
+
[RFC3449]
+
+Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, , <https://www.rfc-editor.org/rfc/rfc3449>.
+
+
[RFC3168]
+
+Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, , <https://www.rfc-editor.org/rfc/rfc3168>.
+
+
[RFC8257]
+
+Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, , <https://www.rfc-editor.org/rfc/rfc8257>.
+
+
[I-D.ietf-tsvwg-aqm-dualq-coupled]
+
+De Schepper, K., Briscoe, B., and G. White, "Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)", Work in Progress, Internet-Draft, draft-ietf-tsvwg-aqm-dualq-coupled-25, , <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-25>.
+
+
+
+
+
+
+
+

+Acknowledgments +

+

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

+

Thanks for the in-depth reviews by Lucas Pardue, Martin Thomson, +Magnus Westerlund, Kazuho Oku, Marten Seemann, Gorry Fairhurst and +Ingemar Johansson.

+
+
+
+
+

+Authors' Addresses +

+
+
Jana Iyengar
+
Fastly
+ +
+
+
Ian Swett
+
Google
+ +
+
+
Mirja Kühlewind
+
Ericsson
+ +
+
+
+ + + diff --git a/ianswett-tweak-motivation/draft-ietf-quic-ack-frequency.txt b/ianswett-tweak-motivation/draft-ietf-quic-ack-frequency.txt new file mode 100644 index 0000000..d303c02 --- /dev/null +++ b/ianswett-tweak-motivation/draft-ietf-quic-ack-frequency.txt @@ -0,0 +1,771 @@ + + + + +QUIC J. Iyengar +Internet-Draft Fastly +Intended status: Standards Track I. Swett +Expires: 3 October 2024 Google + M. Kühlewind + Ericsson + 1 April 2024 + + + QUIC Acknowledgment Frequency + draft-ietf-quic-ack-frequency-latest + +Abstract + + This document specifies an extension to QUIC that permits an endpoint + to request that its peer changes its behavior when sending or + delaying acknowledgments. + +Note to Readers + + Discussion of this draft takes place on the QUIC working group + mailing list (quic@ietf.org), which is archived at + https://mailarchive.ietf.org/arch/search/?email_list=quic. Source + code and issues list for this draft can be found at + https://github.com/quicwg/ack-frequency. + + Working Group information can be found at https://github.com/quicwg. + +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 3 October 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 + 1.1. Terms and Definitions + 2. Motivation + 3. Negotiating Extension Use + 4. ACK_FREQUENCY Frame + 5. IMMEDIATE_ACK Frame + 6. Sending Acknowledgments + 6.1. Response to long idle periods + 6.2. Response to Out-of-Order Packets + 6.2.1. Examples + 6.3. Setting the Reordering Threshold value + 6.4. Expediting Explicit Congestion Notification (ECN) Signals + 6.5. Batch Processing of Packets + 7. Computation of Probe Timeout Period + 8. Determining Acknowledgment Frequency + 8.1. Congestion Control + 8.1.1. Application-Limited Connections + 8.2. Burst Mitigation + 8.3. Loss Detection and Timers + 8.4. Connection Migration + 9. Security Considerations + 10. IANA Considerations + 10.1. QUIC Transport Parameter + 10.2. QUIC Frame Types + 11. References + 11.1. Normative References + 11.2. Informative References + Acknowledgments + Authors' Addresses + +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. + +1.1. Terms and Definitions + + The keywords "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. + + In the rest of this document, "sender" refers to a QUIC data sender + (and acknowledgment receiver). Similarly, "receiver" refers to a + QUIC data receiver (and acknowledgment sender). + + This document uses terms, definitions, and notational conventions + described in Section 1.2 and Section 1.3 of [QUIC-TRANSPORT]. + +2. Motivation + + A receiver acknowledges received packets, but can delay sending these + acknowledgments. Delaying acknowledgments can impact a data sender's + throughput, loss detection and congestion controller performance, as + well as CPU utilization at both endpoints. + + Reducing the frequency of acknowledgments can improve connection and + endpoint performance in the following ways: + + * Sending UDP datagrams is very CPU intensive on some platforms. A + data receiver can decrease its CPU usage by reducing the number of + acknowledgement-only packets sent. 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 also reduces the data + sender's CPU usage because it receives and processes 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. + + However, As discussed in Section 8, a unilateral reduction in + acknowledgement frequency can lead to undesirable consequences for + congestion control and loss recovery. + + [QUIC-TRANSPORT] specifies a simple delayed acknowledgment mechanism + (Section 13.2.1 of [QUIC-TRANSPORT]). A data sender's constraints on + the acknowledgment frequency need to be taken into account to + maximize congestion controller and loss recovery performance. This + extension provides a mechanism for a data sender to signal its + preferences and constraints. + +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. + +6.1. Response to long idle periods + + It is important to receive timely feedback after long idle periods, + e.g. update stale RTT measurements. When no acknowledgment has been + sent in over one smoothed round trip time, receivers are encouraged + to send an acknowledgment soon after receiving an ack-eliciting + packet. This is not an issue specific to this document, but the + mechanisms specified herein could create excessive delays. + +6.2. Response to Out-of-Order Packets + + As specified in Section 13.2.1 of [QUIC-TRANSPORT], endpoints are + expected to send an acknowledgment immediately on receipt of a + reordered ack-eliciting packet with a smaller packet number than the + highest-numbered ack-eliciting packet or with a higher packet number + when there are missing packets between that packet and the highest- + numbered ack-eliciting packet. This extension modifies that behavior + when an ACK_FREQUENCY frame with a Reordering Threshold value other + than 1 has been received. + + If the most recent ACK_FREQUENCY frame received from the peer has a + Reordering Threshold value of 0, the endpoint SHOULD NOT send an + immediate acknowledgment in response to packets received out of + order, and instead rely on the peer's Ack-Eliciting Threshold and + Requested Max Ack Delay for sending acknowledgments. + + If the most recent ACK_FREQUENCY frame received from the peer has a + Reordering Threshold value larger than 1, the endpoint tests the + amount of reordering before deciding to send an acknowledgment. The + specification uses the following definitions: + + Largest Unacked: The largest packet number among all received ack- + eliciting packets. + + Largest Acked: The Largest Acknowledged value sent in an ACK frame. + + Largest Reported: The largest packet number that could be declared + lost with the specified Reordering Threshold, which is Largest + Acked - Reordering Threshold + 1. + + Unreported Missing: Packets with packet numbers between the Largest + Unacked and Largest Reported that have not yet been received. + + An endpoint that receives an ACK_FREQUENCY frame with a non-zero + Reordering Threshold value SHOULD send an immediate ACK when the gap + between the smallest Unreported Missing packet and the Largest + Unacked is greater than or equal to the Reordering Threshold value. + Sending this additional ACK will reset the max_ack_delay timer and + Ack-Eliciting Threshold counter (as any ACK would do). + + See Section 6.2.1 for examples explaining this behavior. See + Section 6.3 for guidance on how to choose the reordering threshold + value when sending ACK_FREQUENCY frames. + +6.2.1. Examples + + When the reordering threshold is 1, any time a packet is received and + there is a missing packet, an immediate acknowledgement is sent. + + If the reordering theshold is 3 and acknowledgements are only sent + due to reordering: + + 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 + + Note that in this example, the receipt of packet 9 triggers an ACK + that reports both packets 6 and 7 as missing. However, the receipt + of packet 10 needs to trigger another immediate ACK because only with + the reporting of the successful receiption of packet 10, the sender + will be able to declare packet 7 as lost (with a reordering threshold + of 3). + + If the reordering threshold is 5 and acknowledgements are only sent + due to reordering: + + 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 + +6.3. Setting the Reordering Threshold value + + To ensure timely loss detection, it is optimal to send a Reordering + Threshold value of 1 less than the packet threshold used by the data + sender for loss detection. If the threshold is smaller, an + acknowledgement is (unnecessarily) sent before the packet can be + declared lost based on the packet threshold. If the value is larger, + it causes unnecessary delays. (Section 18.2 of [QUIC-RECOVERY]) + recommends a default packet threshold for loss detection of 3, + equivalent to a Reordering Threshold of 2. + +6.4. Expediting Explicit Congestion Notification (ECN) Signals + + If the Ack-Eliciting Threshold is larger than 1, an endpoint SHOULD + send an immediate acknowledgement when a packet marked with the ECN + Congestion Experienced (CE) [RFC3168] codepoint in the IP header is + received and the previously received packet was not marked CE. From + there on, if multiple CE-marked packets are received in a row or only + non-CE-marked packet received, the endpoint resumes sending + acknowledgements based on the Ack-Eliciting Threshold or + max_ack_delay. This results in sending an immediate acknowledgement + only when there is a transition from non-CE-marked to CE-marked. + + Doing this maintains the peer's response time to congestion events, + while also reducing the ACK rate compared to Section 13.2.1 of + [QUIC-TRANSPORT] during extreme congestion or when peers are using + DCTCP [RFC8257] or other congestion controllers (e.g. + [I-D.ietf-tsvwg-aqm-dualq-coupled]) that mark more frequently than + classic ECN [RFC3168]. + +6.5. Batch Processing of Packets + + To avoid sending multiple acknowledgments in rapid succession, an + endpoint can process all packets in a batch before determining + whether to send an ACK frame in response, as stated in Section 13.2.2 + of [QUIC-TRANSPORT]. + +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. + +8.1. Congestion Control + + A sender needs to be responsive to notifications of congestion, such + as a packet loss or an ECN CE marking. Decreasing the acknowledgment + frequency can delay a sender's response to network congestion or + cause it to underutilize the available bandwidth. + + To limit the consequences of reduced acknowledgment frequency, a + sender can use the extension in this draft to request a receiver to + send an acknowledgment at least once per round trip, when there are + ack-eliciting packets in flight, in the following ways: + + A sender can set the Requested Max Ack Delay value to no more than + the estimated round trip time. The sender can also improve feedback + and robustness to variation in the path RTT by setting the Ack- + Eliciting Threshold to a value no larger than number of maximum-sized + packets that fit into the current congestion window. Alternatively, + a sender can send an IMMEDIATE_ACK frame if no acknowledgement has + been received for more than one round trip time. Although if the + packet containing an IMMEDIATE_ACK is lost, detection of that loss + will be delayed by the Reordering Threshold or Requested Max Ack + Delay. + + When setting the Requested Max Ack Delay as a function of the RTT, it + is usually better to use the Smoothed RTT (smoothed_rtt) (Section 5.3 + of [QUIC-RECOVERY]) or another estimate of the typical RTT, but not + the minimum RTT (min_rtt) (Section 5.2 of [QUIC-RECOVERY]). This + avoids eliciting an unnecessarily high number of acknowledgments when + min_rtt is much smaller than smoothed_rtt. + + Note that the congestion window and the RTT estimate change over the + lifetime of a connection and therefore might require sending updates + in an ACK_FREQUENCY frames to ensure optimal performance, though not + every change should trigger an update. Usually, it is not necessary + to send an ACK_FREQUENCY frame more than once per RTT and likely it + needs to be sent even less frequently. Ideally, an ACK_FREQUENCY + frame is sent only when a relevant change in the congestion window or + smoothed RTT is detected that impacts the local setting of the + reordering threshold or locally-selected calculation of the either + Ack-Eliciting Threshold or the Requested Max Ack Delay. + + It is possible that the RTT is smaller than the receiver's timer + granularity, as communicated via the min_ack_delay transport + parameter, preventing the receiver from sending an acknowledgment + every RTT in time unless packets are acknowledged immediately. In + these cases, Reordering Threshold values other than 1 can delay loss + detection more than an RTT. + +8.1.1. Application-Limited Connections + + A congestion controller that is limited by the congestion window + relies upon receiving acknowledgments to send additional data into + the network. An increase in acknowledgment delay increases the delay + in sending data, which can reduce the achieved throughput. + Congestion window growth can also depend upon receiving + acknowledgments. This can be particularly significant in slow start + (Section 7.3.1 of [QUIC-RECOVERY]), when delaying acknowledgments can + delay the increase in congestion window and can create larger packet + bursts. + + If the sender is application-limited, acknowledgments can be delayed + unnecessarily when entering idle periods. Therefore, if no further + data is buffered to be sent, a sender can send an IMMEDIATE_ACK frame + with the last data packet before an idle period to avoid waiting for + the ack delay. + + If there are no inflight packets, no acknowledgments will be received + for at least a round trip when sending resumes. The max_ack_delay + and Ack-Eliciting Threshold values used by the receiver can further + delay acknowledgments. In this case, the sender can include an + IMMEDIATE_ACK or ACK_FREQUENCY frame in the first Ack-Eliciting + packet to avoid waiting for substantially more than a round trip for + an acknowledgment. + +8.2. Burst Mitigation + + Receiving an acknowledgment can allow a sender to release new packets + into the network. If a sender is designed to rely on the timing of + peer acknowledgments ("ACK clock"), delaying acknowledgments can + cause undesirable bursts of data into the network. In keeping with + Section 7.7 of [QUIC-RECOVERY], a sender can either employ pacing or + limit bursts to the initial congestion window. + +8.3. Loss Detection and Timers + + Acknowledgments are fundamental to reliability in QUIC. + Consequently, delaying or reducing the frequency of acknowledgments + can cause loss detection at the sender to be delayed. + + A QUIC sender detects loss using packet thresholds on receiving an + acknowledgment (Section 6.1.1 of [QUIC-RECOVERY]); delaying the + acknowledgment therefore delays this method of detecting losses. + + Reducing acknowledgment frequency reduces the number of RTT samples + that a sender receives (Section 5 of [QUIC-RECOVERY]), making a + sender's RTT estimate less responsive to changes in the path's RTT. + As a result, any mechanisms that rely on an accurate RTT estimate, + such as time-threshold-based loss detection (Section 6.1.2 of + [QUIC-RECOVERY]) or the Probe Timeout (PTO) (Section 6.2 of + [QUIC-RECOVERY]), will be less responsive to changes in the path's + RTT, resulting in either delayed or unnecessary packet transmissions. + + A sender might use timers to detect loss of PMTU probe packets + (Section 14 of [QUIC-TRANSPORT]). A sender MAY bundle an + IMMEDIATE_ACK frame with any PMTU probes to avoid triggering such + timers. + +8.4. Connection Migration + + To avoid additional delays to connection migration confirmation when + using this extension, a client can bundle an IMMEDIATE_ACK frame with + the first non-probing frame (Section 9.2 of [QUIC-TRANSPORT]) it + sends or it can send only an IMMEDIATE_ACK frame, which is a non- + probing frame. + + An endpoint's congestion controller and RTT estimator are reset upon + confirmation of migration (Section 9.4 of [QUIC-TRANSPORT]); this + changes the pattern of acknowledgments received after migration. + + Therefore, an endpoint that has sent an ACK_FREQUENCY frame earlier + in the connection ought to send a new ACK_FREQUENCY frame upon + confirmation of connection migration with updated information, e.g. + to consider the new RTT estimate. + +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 + (https://www.iana.org/assignments/quic/quic.xhtml). + +10.1. QUIC Transport Parameter + + The following entry in Table 1 has been requested to be provisionally + added to the "QUIC Transport Parameters" registry under the "QUIC + Protocol" heading. + + +============+=================+===============+ + | Value | Parameter Name. | Specification | + +============+=================+===============+ + | 0xff04de1b | min_ack_delay | Section 3 | + +------------+-----------------+---------------+ + + Table 1: Addition to QUIC Transport + Parameters Entries + + When this document is approved, IANA is requested to assign a + permanent allocation of a codepoint in the 0-63 range to replace the + provisional codepoint described above. + +10.2. QUIC Frame Types + + The following frame types have requested to be provisionally added to + the "QUIC Frame Types" registry under the "QUIC Protocol" heading. + + +=======+===============+===============+ + | Value | Frame Name | Specification | + +=======+===============+===============+ + | 0xaf | ACK_FREQUENCY | Section 4 | + +-------+---------------+---------------+ + | 0x1f | IMMEDIATE_ACK | Section 5 | + +-------+---------------+---------------+ + + Table 2: Addition to QUIC Frame Types + Entries + + When this document is approved, IANA is requested to change the + registration to a permanent allocation of these frame types with the + values described above. + +11. References + +11.1. Normative References + + [QUIC-TRANSPORT] + Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + . + + [QUIC-RECOVERY] + Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection + and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, + May 2021, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +11.2. Informative References + + [Cus22] Custura, A., Jones, T., Secchi, R., and G. Fairhurst, + "Reducing the acknowledgement frequency in IETF QUIC", + DOI 10.1002/sat.1466, name IJSCN, October 2022, + . + + [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. + Sooriyabandara, "TCP Performance Implications of Network + Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, + December 2002, . + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, + . + + [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., + and G. Judd, "Data Center TCP (DCTCP): TCP Congestion + Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, + October 2017, . + + [I-D.ietf-tsvwg-aqm-dualq-coupled] + De Schepper, K., Briscoe, B., and G. White, "Dual-Queue + Coupled Active Queue Management (AQM) for Low Latency, Low + Loss, and Scalable Throughput (L4S)", Work in Progress, + Internet-Draft, draft-ietf-tsvwg-aqm-dualq-coupled-25, 29 + August 2022, . + +Acknowledgments + + The following people directly contributed key ideas that shaped this + draft: Bob Briscoe, Kazuho Oku, Marten Seemann. + + Thanks for the in-depth reviews by Lucas Pardue, Martin Thomson, + Magnus Westerlund, Kazuho Oku, Marten Seemann, Gorry Fairhurst and + Ingemar Johansson. + +Authors' Addresses + + Jana Iyengar + Fastly + Email: jri.ietf@gmail.com + + + Ian Swett + Google + Email: ianswett@google.com + + + Mirja Kühlewind + Ericsson + Email: mirja.kuehlewind@ericsson.com diff --git a/ianswett-tweak-motivation/index.html b/ianswett-tweak-motivation/index.html new file mode 100644 index 0000000..be7ccf5 --- /dev/null +++ b/ianswett-tweak-motivation/index.html @@ -0,0 +1,45 @@ + + + + quicwg/ack-frequency ianswett-tweak-motivation preview + + + + +

Editor's drafts for ianswett-tweak-motivation branch of quicwg/ack-frequency

+ + + + + + +
QUIC Acknowledgment Frequencyplain textsame as main
+ + + diff --git a/index.html b/index.html index 2fac4b3..976c408 100644 --- a/index.html +++ b/index.html @@ -41,6 +41,14 @@

Preview for branch mirjak-patch-41

diff with main +

Preview for branch ianswett-tweak-motivation

+ + + + + + +
QUIC Acknowledgment Frequencyplain textdiff with main

Preview for branch mirjak-patch-39