idnits 2.17.1 draft-li-quic-optimizing-ack-in-wlan-04.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 date (12 May 2022) is 715 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-fairhurst-quic-ack-scaling-03 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 T. Li 3 Internet-Draft Renmin University of China 4 Intended status: Experimental K. Zheng 5 Expires: 13 November 2022 R.A. Jadhav 6 J. Kang 7 Huawei 8 12 May 2022 10 Optimizing ACK mechanism for QUIC 11 draft-li-quic-optimizing-ack-in-wlan-04 13 Abstract 15 The dependence on frequent acknowledgments (ACKs) is an artifact of 16 current transport protocol designs rather than a fundamental 17 requirement. This document analyzes the problems caused by 18 contentions and collisions on wireless medium between data packets 19 and ACKs in WLAN and it proposes an ACK mechanism that minimizes the 20 intensity of ACK Frame in QUIC, improving the performance of 21 transport layer connection. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 13 November 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Overview of Standards on ACK Mechanism . . . . . . . . . . . 3 59 4. Optimized ACK Mechanism for QUIC . . . . . . . . . . . . . . 4 60 4.1. Reducing ACK intensity . . . . . . . . . . . . . . . . . 4 61 4.2. OWD-based RTTmin estimation . . . . . . . . . . . . . . . 5 62 4.3. Sender-Side Operation . . . . . . . . . . . . . . . . . . 6 63 4.4. Receiver-side Operation . . . . . . . . . . . . . . . . . 7 64 4.5. Generating ACK . . . . . . . . . . . . . . . . . . . . . 8 65 4.6. Modification to QUIC Protocol . . . . . . . . . . . . . . 8 66 4.6.1. Transport Parameter: ack-intensity-support . . . . . 8 67 4.6.2. ACK-INTENSITY Frame . . . . . . . . . . . . . . . . . 8 68 4.6.3. TIMESTAMP Frame . . . . . . . . . . . . . . . . . . . 9 69 4.6.4. ACK Delay Redefinition . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 7.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 2. Problem Statement 85 High-throughput transport over wireless local area network (WLAN) 86 becomes a demanding requirement with the emergence of 4K wireless 87 projection, VR/AR-based interactive gaming, Metaverse, and more. 88 However, the shared nature of the wireless medium induces contention 89 between data transport and backward signaling, such as 90 acknowledgment. ACKs share the same medium route with data packets, 91 causing similar medium access overhead despite the much smaller size 92 of the ACKs. Contentions and collisions, as well as the wasted 93 wireless resources by ACKs, lead to significant throughput decline on 94 the data path. This draft follows the roadmap as depicted in [AOD] 96 3. Overview of Standards on ACK Mechanism 98 RFC 9000 [RFC9000] specifies a simple delayed ACK mechanism that a 99 receiver can send an ACK for every other packet, and for every packet 100 when reordering is observed, or when the max_ack_delay timer expires. 101 However, this ACK mechanism may not match the number of ACKs to the 102 transport's required intensity under different network conditions. 103 For example, when the data throughput of a WLAN transport is 104 extremely high, QUIC will generate a large number of ACKs. In this 105 case, minimizing the ACK intensity of QUIC is not only a win for data 106 throughput improvement but also a win for energy and CPU efficiency. 108 RFC 1122 [RFC1122] and RFC 5681 [RFC5681] were two core functionality 109 standards that introduced delayed ACK, which was the default 110 acknowledgment mechanism in most Linux distributions. RFC 4341 111 [RFC4341] and RFC 5690 [RFC5690] described an acknowledgment 112 congestion control mechanism in which the minimum ACK frequency 113 allowed is twice per send window. RFC 3449 [RFC3449] discussed the 114 imperfection and variability of TCP's acknowledgment mechanism 115 because of asymmetric effects and recommended scaling ACK frequency 116 as a mitigation to these effects. These RFCs reveal that the 117 dependence on frequent ACKs is an artifact of current transport 118 protocol designs rather than a fundamental requirement. Based on 119 this insight, some work-in-progress IETF drafts have paid great 120 attention to ACK scaling technologies in both TCP and QUIC working 121 groups. 123 First of all, [ACK-PULL] proposed the TCP ACK pull mechanism, which 124 allows a sender to request the ACK for a data segment to be sent 125 without additional delay by the receiver. This helps in some cases 126 when the delayed ACKs degrade transport performance. 128 Instead of pulling more ACKs, [QUIC-SCALING] recommended that 129 reducing the ACK frequency by sending an ACK for at least every 10 130 received packets and [QUIC-SATCOM] recommended an ACK frequency of 131 four ACKs every round-trip time (RTT), aiming to reduce link 132 transmission costs for asymmetric paths. 134 Different from using an empirical value of ACK frequency, instead, we 135 try to improve the scalability by proposing a novel ACK mechanism 136 named Tame ACK (TACK), whose frequency is a function of bandwidth- 137 delay product of network connections. The detailed TCP-based 138 implementation (i.e., TCP-TACK) details and evaluation results have 139 been shown in our prior work [Tong]. TCP-based implementation 140 depends on the middleboxes to permit the extended-option-packets 141 through, which might limit applicable scenarios. While QUIC is a 142 flexible framework of transport protocol that uses UDP as a substrate 143 to avoid requiring changes to legacy operating systems and 144 middleboxes, and encrypts most of the packets including ACKs to avoid 145 incurring a dependency on middleboxes. Hence, this draft focuses on 146 applying TACK to optimize the ACK mechanism for QUIC. 148 It is worth noting that [IYENGAR-ACK] has proposed an extension of 149 sender controlled ACK-FREQUENCY frame for QUIC, which is possible to 150 be reused to help the sender sync the dynamically adjusted TACK 151 frequency with the receiver in this case. 153 4. Optimized ACK Mechanism for QUIC 155 4.1. Reducing ACK intensity 157 ACK intensity can be quantified by the unit of Hz, i.e., number of 158 ACKs per second. Byte-counting ACK and periodic ACK are two 159 fundamental ways to reduce ACK intensity on the transport layer. 161 1. Byte-counting ACK: ACK intensity is controlled by sending an ACK 162 for every L (L >= 2) incoming full-sized packets, in which the packet 163 size equals to the Max Packet Size (set in the max_packet_size 164 parameter in QUIC). The intensity of byte-counting ACK (f_b) is 165 proportional to data throughput (bw): 167 f_b = bw/L*max_packet_size (1) 169 In general, f_b can be reduced by setting a large value of L. 170 However, for a given L, f_b increases with bw. This means when data 171 throughput is extremely high, the ACK intensity still might be 172 comparatively large. In other words, the intensity of byte-counting 173 ACK changes proportionately with bandwidth. 175 2. Periodic ACK: Byte-counting ACK's unbounded intensity can be 176 attributed to the coupling between ACK sending and packet arrivals. 177 Periodic ACK can decouple ACK intensity from packet arrivals, 178 achieving a bounded ACK intensity when bw is high. The intensity of 179 periodic ACK (f_pack) is: 181 f_pack = 1/alpha (2) 183 Where alpha is the time interval between two ACKs and is a function 184 of RTT. However, when bw is extremely low, the ACK intensity is 185 always as high as that in the case of a high throughput. In other 186 words, the intensity of periodic ACK is unadaptable to bandwidth 187 change, which wastes resources. 189 Following the design of TACK [Tong], we combine the above two ways, 190 and set the minimum ACK intensity in a QUIC connection as f_quic = 191 min{f_b,f_pack}. Through Equations (1) and (2), we have 192 f_quic = min{bw/(L*max_packet_size), 1/alpha} (3) 194 We set alpha = RTTmin/beta, which means sending beta ACKs per RTTmin. 195 RTTmin is the minimum RTT observed for a given network path. As a 196 consequence, the minimum ACK intensity in a QUIC connection can be 197 given as follow: 199 f_quic = min{bw/(L*max_packet_size), beta/RTTmin} (4) 201 where beta indicates the number of ACKs per RTT, and L indicates the 202 number of full-sized data packets counted before sending an ACK. To 203 minimize the ACK intensity, a smaller beta or a larger L is expected. 204 Sara Landstrom et al. has given a lower bound of beta in [Sara], 205 i.e., beta >= 2. We have further given an upper bound of L, which 206 can be derived according to the loss rate on the data path (plr_data) 207 and the ack path (plr_ack), i.e., L <= 208 feedback_info/(plr_data*plr_ack). Where feedback_info denotes the 209 amount of information carried by an ACK. The detailed derivation can 210 be refered in [Tong]. 212 Qualitatively, periodic ACK is applied when bandwidth-delay product 213 (bdp) is large (i.e., bdp >= beta*L* max_packet_size), and byte- 214 counting ACK is applied when bdp is small (i.e., bdp < beta*L* 215 max_packet_size). 217 In terms of a transport with a large bdp, beta = 2 should be 218 sufficient to ensure utilization, but the large bottleneck buffer 219 (i.e., one bdp) makes it necessary to acknowledge data more often. 220 In general, the minimum send window (SWNDmin) can be roughly 221 estimated as follow: 223 SWNDmin = beta*bdp/(beta-1) (5) 225 Ideally, the bottleneck buffer requirement is decided by the minimum 226 send window, i.e., SWNDmin - bdp. Since doubling the ACK frequency 227 reduces the bottleneck buffer requirement substantially from 1 bdp to 228 0.33 bdp, beta = 4 is RECOMMENDED to provide redundancy [Sara], being 229 more robust in practice. 231 4.2. OWD-based RTTmin estimation 233 In this document, the RTTmin is the minimum RTT samples observed at 234 the sender for a given network path during a period of time, and 235 OWDmin is the minimum OWD samples observed on the same network path 236 during a period of time. 238 An RTT estimation system contains a sender and a receiver. The 239 sender can hardly generate per-packet RTT samples, which is the root 240 cause of the minimum RTT estimation biases in the case of sending 241 fewer ACKs. When multiple packets carrying departure timestamps are 242 transported between endpoints via the same path , an RTT of this path 243 can be sampled at the sender upon receiving an ACK frame. However, 244 when sending fewer ACK frames, more data packets might be received 245 during the ACK interval, generating only one RTT sample among 246 multiple packets is likely to result in biases. For example, a 247 larger minimum RTT estimate. In general, the higher the throughput, 248 the larger the biases. One alternative way to reduce biases can be 249 that, each ACK frame carries multiple timestamps (as well as ACK 250 delays in RFC 9002 [RFC9002]) for the sender to generate more RTT 251 samples. However, (1) the overhead is high, which is unacceptable 252 especially for high-bandwidth transport. Also, (2) the number of 253 data packets might be far more than the maximum number of timestamps 254 that an ACK frame is capable of carrying. Since the receiver is 255 capable to monitor per-packet state, the one-way delay (OWD) of each 256 packet can be easily computed according to the departure timestamps 257 (carried in the packet) and the arrival timestamps of each packet. 258 In this case, QUIC SHOULD adopt the OWD-based RTTmin estimation. The 259 rationale is that the variation of OWD reflects the variation of RTT 260 over near-symmetric links. The OWD-based RTTmin estimation requires 261 the sender to record the departure timestamp in each ack-eliciting 262 packet. Meanwhile, at the receiver, the per-packet OWD samples 263 SHOULD be computed upon packet arrivals and a function of computing 264 the minimum OWD SHOULD be newly added. The receiver then generates 265 an ACK frame to the sender, in which the ACK delay and departure 266 timestamp for the packet that achieves the minimum OWD is reported. 267 The ACK delay is defined as the delay incurred between when the 268 packet is received and when the ACK frame is sent. Based on the 269 information reported by the incoming ACK frames and the ACK arrival 270 timestamps, the sender can generate RTT samples and then compute 271 RTTmin accordingly. 273 In this document, RTTmin is used to update the ACK intensity. In 274 general, RTTmin can also be used by other modules. For example, some 275 congestion controllers depends on RTTmin to estimate the congestion 276 window [Neal]. RTTmin is also used by QUIC loss detection to reject 277 implausibly small rtt samples RFC 9002 [RFC9002]. 279 4.3. Sender-Side Operation 281 According to Formula (4), the run-time ACK intensity in QUIC are 282 decided by bw, and RTTmin. Generally, the RTTmin and bw are 283 calculated at the sender. 285 Before estimating the RTTmin, the RTT samples should be computed 286 based on the ACK frames collected during a period of time. Assume 287 that a packet is sent by the sender at time t_1 and arrives at time 288 t_3, and the ACK frame is sent at time t_4. The ACK delay can be 289 computed at the receiver. For example, the receiver computes the ACK 290 delay delta_t = t_4 - t_3, and syncs the ACK delay to the sender via 291 an ACK frame. The ACK delay can also be computed at the sender. For 292 example, the receiver directly syncs an ACK frame carrying t_4 and 293 t_3 to the sender, the sender then computes the ACK delay delta_t = 294 t_4 - t_3. 296 The sender therefore computes an RTT sample according to delta_t, 297 t_1, and the arrival time (t_2) of the ACK frame, i.e., RTT_sample = 298 t_2 - t_1 - delta_t. Measuring delta_t at the receiver assures an 299 explicit correction for a more accurate RTT estimate. RTT samples 300 SHOULD be smoothed using exponentially weighted moving average (EWMA) 301 as specified in [RFC6298]. The sender then computes the RTTmin 302 according to these RTT samples during a period of time. 304 The bw estimation can be acquired in a similar manner to BBR [Neal]. 305 Since minimizing the ACK intensity induces excessive ACK delay, the 306 value of bw may be the average value over a long period of time. 307 However, the biases introduced in ACK intensity computation is 308 limited. 310 After computing the f_quic, the sender periodically syncs it to the 311 receiver to update the intensity of ACK Frame by sending a new ACK- 312 INTENSITY frame. 314 The sender SHOULD generate an ACK-INTENSITY frame on a regular basis. 315 For example, when the change of f_quic exceeds a threshold, the ACK- 316 INTENSITY frame should be sent to update the ACK intensity in time. 317 The interval of ACK-INTENSITY frame can also be set according to the 318 update window of RTTmin and bw. 320 4.4. Receiver-side Operation 322 Currently, the QUIC receiver reports ACK delays for only the largest 323 acknowledged packet in an ACK frame, hence an RTT sample is generated 324 using only the largest acknowledged packet in the received ACK frame. 325 For a more accurate RTTmin estimate when sending fewer ACK frames, 326 QUIC SHOULD adopt the OWD-based RTTmin estimation. The OWD-based 327 RTTmin estimation requires the QUIC receiver to filter the departure 328 timestamp for the packet that achieves the minimum OWD during the 329 interval between two ACK frames and report the ACK delay of this 330 packet. Whether redefining the meaning of ACK delay or not, it 331 depends on the negotiation between endpoints of the QUIC connection. 333 Upon packet arrivals, the receiver is capable to generate per-packet 334 OWD samples according to the difference between packet departure 335 timestamp and packet arrival timestamp. The receiver then computes 336 the minimum OWD by comparing the per-packet OWD samples. The OWD 337 estimation does not require clock synchronization here because the 338 relative values are adopted. 340 Afterwards, based on the ACK delay and the departure timestamp 341 corresponding to the packet that achieves the minimum OWD, the sender 342 calculates the RTT of this packet as a minimum RTT sample. 343 Ultimately, the minimum RTT is computed according to these minimum 344 RTT samples. 346 The ACK Delay field SHOULD be carried in the ACK Frame. Other fields 347 carried in the ACK frame have the same meaning as defined in RFC 9002 348 [RFC9002]. 350 The receiver adopts the newly updated ACK intensity once it receives 351 the ACK-INTENSITY frame from the sender. 353 4.5. Generating ACK 355 The newly proposed ACK mechanism SHOULD be applied when there is no 356 out-of-order delivery. When reordering happens, the ACK Frame SHOULD 357 be generated immediately. 359 4.6. Modification to QUIC Protocol 361 4.6.1. Transport Parameter: ack-intensity-support 363 A new field named ack-intensity-support should be added for 364 negotiation between both parties whether starting the dynamic ACK 365 intensity function in QUIC connection. The endpoints sends this 366 parameter during handshakes. Only when both parties agree, ACK 367 intensity refreshment can be adopted. 369 ack-intensity-support (0x XX):This parameter has two values (0 or 1) 370 specifying whether the sending endpoint is willing to adopt ACK 371 intensity refreshment. When the value is set as 1, it means that the 372 sending endpoint want to start ACK intensity refreshment during 373 connection. When the value is set as 0, it means that the sending 374 endpoint does not support this function. 376 4.6.2. ACK-INTENSITY Frame 378 An ACK-INTENSITY frame is shown in Figure 1. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | 0x b0(i) ... 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Sequence Number(i) ... 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | ACK Intensity (i) ... 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 1: ACK-INTENSITY Frame 392 An ACK-INTENSITY frame contains the following fields: 394 Sequence Number: A variable-length integer indicating the sequence 395 number assigned to the ACK-INTENSITY frame by the sender. 397 ACK Intensity: A variable-length integer indicating the updated 398 f_quic calculated by the sender. 400 ACK-INTENSITY frames are ack-eliciting. However, their loss does not 401 require retransmission. 403 Multiple ACK-INTENSITY frames SHOULD be generated by the sender 404 during a connection to notify the receiver the variation of ACK 405 intensity requirement under network dynamics. 407 4.6.3. TIMESTAMP Frame 409 Instead of the invasive way of adding a new field in the QUIC public 410 packet header, it is RECOMMENDED that a new frame be added for 411 exchanging the departure timestamp of each packet. 413 A TIMESTAMP frame is shown in Figure 2. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | 0x b1(i) ... 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Departure Timestamp (i) ... 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 2: TIMESTAMP Frame 425 A TIMESTAMP frame contains the following fields: 427 Departure Timestamp: An integer indicating the departure time of a 428 packet. 430 QUIC SHOULD carry the TIMESTAMP Frame in each packet. 432 4.6.4. ACK Delay Redefinition 434 The ACK Delay field is carried in the ACK Frame. Currently, the QUIC 435 receiver reports ACK delays for only the largest acknowledged packet 436 in an ACK frame, hence an RTT sample is generated using only the 437 largest acknowledged packet in the received ACK frame. For a more 438 accurate RTTmin estimate when sending fewer ACK frames, QUIC SHOULD 439 adopt the OWD-based RTTmin estimation. The OWD-based RTTmin 440 estimation requires the QUIC receiver to filter the departure 441 timestamp for the packet that achieves the minimum OWD during the 442 interval between two ACK frames and report the ACK delay of this 443 packet. Whether redefining the meaning of ACK delay or not, it 444 depends on the negotiation between endpoints of the QUIC connection. 446 In other words, QUIC SHOULD change the way of computing ACK Delay 447 according to the arrival timestamp of the packet with minimum OWD 448 instead of the arrival timestamp of the largest acknowledged packet. 450 5. Security Considerations 452 TBD 454 6. IANA Considerations 456 The value for ack-intensity-support transport parameter and ACK- 457 INTENSITY frame should be allocated. 459 7. References 461 7.1. Normative References 463 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 464 Communication Layers", STD 3, RFC 1122, 465 DOI 10.17487/RFC1122, October 1989, 466 . 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 474 Sooriyabandara, "TCP Performance Implications of Network 475 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 476 December 2002, . 478 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 479 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 480 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 481 2006, . 483 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 484 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 485 . 487 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 488 Acknowledgement Congestion Control to TCP", RFC 5690, 489 DOI 10.17487/RFC5690, February 2010, 490 . 492 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 493 "Computing TCP's Retransmission Timer", RFC 6298, 494 DOI 10.17487/RFC6298, June 2011, 495 . 497 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 498 Multiplexed and Secure Transport", RFC 9000, 499 DOI 10.17487/RFC9000, May 2021, 500 . 502 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 503 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 504 May 2021, . 506 7.2. Informative References 508 [ACK-PULL] Gomez, C., Ed. and J. Crowcroft, Ed., "TCP ACK Pull", Work 509 in Progress, Internet-Draft, draft-gomez-tcpm-ack-pull-01, 510 4 November 2019, . 513 [AOD] Li, T., Zheng, K., and K. Xu, "Acknowledgment On Demand 514 for Transport Control", IEEE Internet 515 Computing 25(2):109-115, 2021. 517 [IYENGAR-ACK] 518 Iyengar, J., Ed. and I. Swett, Ed., "Sender Control of 519 acknowledgment Delays in QUIC", Work in Progress, 520 Internet-Draft, draft-iyengar-quic-delayed-ack-02, 2 521 November 2020, . 524 [Neal] Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., and 525 V. Jacobson, "BBR: Congestion-based congestion control", 526 ACM QUEUE 14(5):20-53, 2016. 528 [QUIC-SATCOM] 529 Kuhn, N., Ed., Fairhurst, G., Ed., Border, J., Ed., and E. 530 Stephan, Ed., "QUIC for SATCOM", Work in Progress, 531 Internet-Draft, draft-kuhn-quic-4-sat-06, 30 October 2020, 532 . 535 [QUIC-SCALING] 536 Fairhurst, G., Ed., Custura, A., Ed., and T. Jones, Ed., 537 "Changing the Default QUIC ACK Policy", Work in Progress, 538 Internet-Draft, draft-fairhurst-quic-ack-scaling-03, 14 539 September 2020, . 542 [Sara] Landstrom, S. and L. Larzon, "Reducing the tcp 543 acknowledgment frequency", ACM SIGCOMM CCR 37(3):5-16, 544 2007. 546 [Tong] Li, T., Zheng, K., Xu, K., Jadhav, R. A., Xiong, T., 547 Winstein, K., and K. Tan, "TACK: Improving Wireless 548 Transport Performance by Taming Acknowledgments", ACM 549 SIGCOMM 2020:15-30, 2020. 551 Authors' Addresses 553 Tong Li 554 Renmin University of China 555 Room 421, Information Building, Renmin University of China 556 Haidian District 557 Beijing 558 China 559 Email: tong.li@ruc.edu.cn 560 Kai Zheng 561 Huawei 562 Information Road, Haidian District 563 Beijing 564 China 565 Email: kai.zheng@huawei.com 567 Rahul Arvind Jadhav 568 Huawei 569 D2-03,Huawei Industrial Base 570 Longgang District 571 Shenzhen 572 China 573 Email: rahul.jadhav@huawei.com 575 Jiao Kang 576 Huawei 577 D2-03,Huawei Industrial Base 578 Longgang District 579 Shenzhen 580 China 581 Email: kangjiao@huawei.com