idnits 2.17.1 draft-ietf-quic-ack-frequency-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (12 July 2021) is 1011 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC J. Iyengar 3 Internet-Draft Fastly 4 Intended status: Standards Track I. Swett 5 Expires: 13 January 2022 Google 6 12 July 2021 8 QUIC Acknowledgement Frequency 9 draft-ietf-quic-ack-frequency-00 11 Abstract 13 This document describes a QUIC extension for an endpoint to control 14 its peer's delaying of acknowledgements. 16 Note to Readers 18 Discussion of this draft takes place on the QUIC working group 19 mailing list (quic@ietf.org), which is archived at 20 https://mailarchive.ietf.org/arch/search/?email_list=quic 21 (https://mailarchive.ietf.org/arch/search/?email_list=quic). Source 22 code and issues list for this draft can be found at 23 https://github.com/quicwg/ack-frequency (https://github.com/quicwg/ 24 ack-frequency). 26 Working Group information can be found at https://github.com/quicwg 27 (https://github.com/quicwg); 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 13 January 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 3 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Negotiating Extension Use . . . . . . . . . . . . . . . . . . 4 66 4. ACK_FREQUENCY Frame . . . . . . . . . . . . . . . . . . . . . 5 67 5. Multiple ACK_FREQUENCY Frames . . . . . . . . . . . . . . . . 6 68 6. Sending Acknowledgments . . . . . . . . . . . . . . . . . . . 7 69 6.1. Response to Reordering . . . . . . . . . . . . . . . . . 7 70 6.2. Expediting Congestion Signals . . . . . . . . . . . . . . 8 71 6.3. Batch Processing of Packets . . . . . . . . . . . . . . . 8 72 7. Computation of Probe Timeout Period . . . . . . . . . . . . . 8 73 8. Implementation Considerations . . . . . . . . . . . . . . . . 9 74 8.1. Loss Detection . . . . . . . . . . . . . . . . . . . . . 9 75 8.2. New Connections . . . . . . . . . . . . . . . . . . . . . 9 76 8.3. Window-based Congestion Controllers . . . . . . . . . . . 9 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 80 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 This document describes a QUIC extension for an endpoint to control 87 its peer's delaying of acknowledgements. 89 1.1. Terms and Definitions 91 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 In the rest of this document, "sender" refers to a QUIC data sender 98 (and acknowledgement receiver). Similarly, "receiver" refers to a 99 QUIC data receiver (and acknowledgement sender). 101 An "acknowledgement packet" refers to a QUIC packet that contains 102 only an ACK frame. 104 This document uses terms, definitions, and notational conventions 105 described in Section 1.2 and Section 1.3 of [QUIC-TRANSPORT]. 107 2. Motivation 109 A receiver acknowledges received packets, but it can delay sending 110 these acknowledgements. The delaying of acknowledgements can impact 111 connection throughput, loss detection and congestion controller 112 performance at a data sender, and CPU utilization at both a data 113 sender and a data receiver. 115 Reducing the frequency of acknowledgement packets can improve 116 connection and endpoint performance in the following ways: 118 * Sending UDP packets can be noticeably CPU intensive on some 119 platforms. Reducing the number of packets that only contain 120 acknowledgements can therefore reduce the amount of CPU consumed 121 at a data receiver. Experience shows that this cost reduction can 122 be significant for high bandwidth connections. 124 * Similarly, receiving and processing UDP packets can also be CPU 125 intensive, and reducing acknowledgement frequency reduces this 126 cost at a data sender. 128 * Severely asymmetric link technologies, such as DOCSIS, LTE, and 129 satellite links, connection throughput in the data direction 130 becomes constrained when the reverse bandwidth is filled by 131 acknowledgment packets. When traversing such links, reducing the 132 number of acknowledgments allows connection throughput to scale 133 much further. 135 As discussed in Section 8 however, there are undesirable consequences 136 to congestion control and loss recovery if a receiver uniltaerally 137 reduces the acknowledgment frequency. A sender's constraints on the 138 acknowledgement frequency need to be taken into account to maximize 139 congestion controller and loss recovery performance. 141 [QUIC-TRANSPORT] currently specifies a simple delayed acknowledgement 142 mechanism that a receiver can use: send an acknowledgement for every 143 other packet, and for every packet when reordering is observed. This 144 simple mechanism does not allow a sender to signal its constraints. 145 This extension provides a mechanism to solve this problem. 147 3. Negotiating Extension Use 149 Endpoints advertise their support of the extension described in this 150 document by sending the following transport parameter (Section 7.2 of 151 [QUIC-TRANSPORT]): 153 min_ack_delay (0xff02de1a): A variable-length integer representing 154 the minimum amount of time in microseconds by which the endpoint 155 can delay an acknowledgement. Values of 2^24 or greater are 156 invalid, and receipt of these values MUST be treated as a 157 connection error of type TRANSPORT_PARAMETER_ERROR. 159 An endpoint's min_ack_delay MUST NOT be greater than its 160 max_ack_delay. Endpoints that support this extension MUST treat 161 receipt of a min_ack_delay that is greater than the received 162 max_ack_delay as a connection error of type 163 TRANSPORT_PARAMETER_ERROR. Note that while the endpoint's 164 max_ack_delay transport parameter is in milliseconds (Section 18.2 of 165 [QUIC-TRANSPORT]), min_ack_delay is specified in microseconds. 167 The min_ack_delay transport parameter is a unilateral indication of 168 support for receiving ACK_FREQUENCY frames. If an endpoint sends the 169 transport parameter, the peer is allowed to send ACK_FREQUENCY frames 170 independent of whether it also sends the min_ack_delay transport 171 parameter or not. 173 This Transport Parameter is encoded as per Section 18 of 174 [QUIC-TRANSPORT]. 176 4. ACK_FREQUENCY Frame 178 Delaying acknowledgements as much as possible reduces both work done 179 by the endpoints and network load. An endpoint's loss detection and 180 congestion control mechanisms however need to be tolerant of this 181 delay at the peer. An endpoint signals the frequency it wants to 182 receive ACK frames to its peer using an ACK_FREQUENCY frame, shown 183 below: 185 0 1 2 3 186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | 0xaf (i) ... 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Sequence Number (i) ... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | ACK-eliciting threshold (i) ... 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Update Max Ack Delay (i) ... 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Ignore Order (8)| 197 +-+-+-+-+-+-+-+-+-+ 199 Following the common frame format described in Section 12.4 of 200 [QUIC-TRANSPORT], ACK_FREQUENCY frames have a type of 0xaf, and 201 contain the following fields: 203 Sequence Number: A variable-length integer representing the sequence 204 number assigned to the ACK_FREQUENCY frame by the sender to allow 205 receivers to ignore obsolete frames, see Section 5. 207 ACK-eliciting threshold: A variable-length integer representing the 208 maximum number of ack-eliciting packets after which the receiver 209 sends an acknowledgement. A value of 1 will result in an 210 acknowledgement being sent for every ack-eliciting packet 211 received. A value of 0 is invalid. Receipt of an invalid value 212 MUST be treated as a connection error of type 213 FRAME_ENCODING_ERROR. 215 Update Max Ack Delay: A variable-length integer representing an 216 update to the peer's "max_ack_delay" transport parameter 217 (Section 18.2 of [QUIC-TRANSPORT]). The value of this field is in 218 microseconds. Any value smaller than the "min_ack_delay" 219 advertised by this endpoint is invalid. Receipt of an invalid 220 value MUST be treated as a connection error of type 221 PROTOCOL_VIOLATION. 223 Ignore Order: An 8-bit field representing a boolean truth value. 225 This field MUST have the value 0x00 (representing "false") or 0x01 226 (representing "true"). This field can be set to "true" by an 227 endpoint that does not wish to receive an immediate 228 acknowledgement when the peer observes reordering (Section 6.1). 229 Receipt of any other value MUST be treated as a connection error 230 of type FRAME_ENCODING_ERROR. 232 ACK_FREQUENCY frames are ack-eliciting. However, their loss does not 233 require retransmission if an ACK_FREQUENCY frame with a larger 234 Sequence Number value has been sent. 236 An endpoint MAY send ACK_FREQUENCY frames multiple times during a 237 connection and with different values. 239 An endpoint will have committed a "max_ack_delay" value to the peer, 240 which specifies the maximum amount of time by which the endpoint will 241 delay sending acknowledgments. When the endpoint receives an 242 ACK_FREQUENCY frame, it MUST update this maximum time to the value 243 proposed by the peer in the Update Max Ack Delay field. 245 5. Multiple ACK_FREQUENCY Frames 247 An endpoint can send multiple ACK_FREQUENCY frames, and each one of 248 them can have different values in all fields. An endpoint MUST use a 249 sequence number of 0 for the first ACK_FREQUENCY frame it constructs 250 and sends, and a strictly increasing value thereafter. 252 An endpoint MUST allow reordered ACK_FREQUENCY frames to be received 253 and processed, see Section 13.3 of [QUIC-TRANSPORT]. 255 On the first received ACK_FREQUENCY frame in a connection, an 256 endpoint MUST immediately record all values from the frame. The 257 sequence number of the frame is recorded as the largest seen sequence 258 number. The new ACK-eliciting Threshold and Update Max Ack Delay 259 values MUST be immediately used for delaying acknowledgements; see 260 Section 6. 262 On a subsequently received ACK_FREQUENCY frame, the endpoint MUST 263 check if this frame is more recent than any previous ones, as 264 follows: 266 * If the frame's sequence number is not greater than the largest one 267 seen so far, the endpoint MUST ignore this frame. 269 * If the frame's sequence number is greater than the largest one 270 seen so far, the endpoint MUST immediately replace old recorded 271 state with values received in this frame. The endpoint MUST start 272 using the new values immediately for delaying acknowledgements; 273 see Section 6. The endpoint MUST also replace the recorded 274 sequence number. 276 6. Sending Acknowledgments 278 Prior to receiving an ACK_FREQUENCY frame, endpoints send 279 acknowledgements as specified in Section 13.2.1 of [QUIC-TRANSPORT]. 281 On receiving an ACK_FREQUENCY frame and updating its recorded 282 "max_ack_delay" and "ACK-eliciting threshold" values (Section 5), the 283 endpoint MUST send an acknowledgement when one of the following 284 conditions are met: 286 * Since the last acknowledgement was sent, the number of received 287 ack-eliciting packets is greater than or equal to the recorded 288 "ACK-eliciting threshold". 290 * Since the last acknowledgement was sent, "max_ack_delay" amount of 291 time has passed. 293 Section 6.1, Section 6.2, and Section 6.3 describe exceptions to this 294 strategy. 296 An endpoint is expected to bundle acknowledgements when possible. 297 Every time an acknowledgement is sent, bundled or otherwise, all 298 counters and timers related to delaying of acknowledgments are reset. 300 6.1. Response to Reordering 302 As specified in Section 13.2.1 of [QUIC-TRANSPORT], endpoints are 303 expected to send an acknowledgement immediately on receiving a 304 reordered ack-eliciting packet. This extension modifies this 305 behavior. 307 If the endpoint has not yet received an ACK_FREQUENCY frame, or if 308 the most recent frame received from the peer has an "Ignore Order" 309 value of "false" (0x00), the endpoint MUST immediately acknowledge 310 any subsequent packets that are received out of order. 312 If the most recent ACK_FREQUENCY frame received from the peer has an 313 "Ignore Order" value of "true" (0x01), the endpoint does not make 314 this exception. That is, the endpoint MUST NOT send an immediate 315 acknowledgement in response to packets received out of order, and 316 instead continues to use the peer's "ACK-eliciting threshold" and 317 "max_ack_delay" thresholds for sending acknowledgements. 319 6.2. Expediting Congestion Signals 321 As specified in Section 13.2.1 of [QUIC-TRANSPORT], an endpoint 322 SHOULD immediately acknowledge packets marked with the ECN Congestion 323 Experienced (CE) codepoint in the IP header. Doing so reduces the 324 peer's response time to congestion events. 326 6.3. Batch Processing of Packets 328 For performance reasons, an endpoint can receive incoming packets 329 from the underlying platform in a batch of multiple packets. This 330 batch can contain enough packets to cause multiple acknowledgements 331 to be sent. 333 To avoid sending multiple acknowledgements in rapid succession, an 334 endpoint MAY process all packets in a batch before determining 335 whether a threshold has been met and an acknowledgement is to be sent 336 in response. 338 7. Computation of Probe Timeout Period 340 On sending an update to the peer's "max_ack_delay", an endpoint can 341 use this new value in later computations of its Probe Timeout (PTO) 342 period; see Section 5.2.1 of [QUIC-RECOVERY]. The endpoint MUST 343 however wait until the ACK_FREQUENCY frame that carries this new 344 value is acknowledged by the peer. 346 Until the frame is acknowledged, the endpoint MUST use the greater of 347 the current "max_ack_delay" and the value that is in flight when 348 computing the PTO period. Doing so avoids spurious PTOs that can be 349 caused by an update that increases the peer's "max_ack_delay". 351 While it is expected that endpoints will have only one ACK_FREQUENCY 352 frame in flight at any given time, this extension does not prohibit 353 having more than one in flight. Generally, when using 354 "max_ack_delay" for PTO computations, endpoints MUST use the maximum 355 of the current value and all those in flight. 357 8. Implementation Considerations 359 There are tradeoffs inherent in a sender sending an ACK_FREQUENCY 360 frame to the receiver. As such it is recommended that implementers 361 experiment with different strategies and find those which best suit 362 their applications and congestion controllers. There are, however, 363 noteworthy considerations when devising strategies for sending 364 ACK_FREQUENCY frames. 366 8.1. Loss Detection 368 A sender relies on receipt of acknowledgements to determine the 369 amount of data in flight and to detect losses, e.g. when packets 370 experience reordering, see [QUIC-RECOVERY]. Consequently, how often 371 a receiver sends acknowledgments determines how long it takes for 372 losses to be detected at the sender. 374 8.2. New Connections 376 Many congestion control algorithms have a startup mechanism during 377 the beginning phases of a connection. It is typical that in this 378 period the congestion controller will quickly increase the amount of 379 data in the network until it is signalled to stop. While the 380 mechanism used to achieve this increase varies, acknowledgments by 381 the peer are generally critical during this phase to drive the 382 congestion controller's machinery. A sender can send ACK_FREQUENCY 383 frames while its congestion controller is in this state, ensuring 384 that the receiver will send acknowledgments at a rate which is 385 optimal for the the sender's congestion controller. 387 8.3. Window-based Congestion Controllers 389 Congestion controllers that are purely window-based and strictly 390 adherent to packet conservation, such as the one defined in 391 [QUIC-RECOVERY], rely on receipt of acknowledgments to move the 392 congestion window forward and send additional data into the network. 393 Such controllers will suffer degraded performance if acknowledgments 394 are delayed excessively. Similarly, if these controllers rely on the 395 timing of peer acknowledgments (an "ACK clock"), delaying 396 acknowledgments will cause undesirable bursts of data into the 397 network. 399 9. Security Considerations 401 TBD. 403 10. IANA Considerations 405 TBD. 407 11. Normative References 409 [QUIC-RECOVERY] 410 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 411 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 412 May 2021, . 414 [QUIC-TRANSPORT] 415 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 416 Multiplexed and Secure Transport", RFC 9000, 417 DOI 10.17487/RFC9000, May 2021, 418 . 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 427 May 2017, . 429 Appendix A. Change Log 431 *RFC Editor's Note:* Please remove this section prior to 432 publication of a final version of this document. 434 Acknowledgments 436 The following people directly contributed key ideas that shaped this 437 draft: Bob Briscoe, Kazuho Oku, Marten Seemann. 439 Authors' Addresses 441 Jana Iyengar 442 Fastly 444 Email: jri.ietf@gmail.com 446 Ian Swett 447 Google 449 Email: ian.swett@google.com