idnits 2.17.1 draft-li-quic-optimizing-ack-in-wlan-02.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 (May 25, 2021) is 1068 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-27 == Outdated reference: A later version (-04) exists of draft-fairhurst-quic-ack-scaling-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC T. Li 3 Internet-Draft K. Zheng 4 Intended status: Experimental R. Jadhav 5 Expires: November 26, 2021 J. Kang 6 Huawei 7 May 25, 2021 9 Optimizing ACK mechanism for QUIC 10 draft-li-quic-optimizing-ack-in-wlan-02 12 Abstract 14 The dependence on frequent acknowledgments (ACKs) is an artifact of 15 current transport protocol designs rather than a fundamental 16 requirement. This document analyzes the problems caused by 17 contentions and collisions on wireless medium between data packets 18 and ACKs in WLAN and it proposes an ACK mechanism that minimizes the 19 intensity of ACK Frame in QUIC, improving the performance of 20 transport layer connection. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 26, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified 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 . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 9 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, and more. However, the 88 shared nature of the wireless medium induces contention between data 89 transport and backward signaling, such as acknowledgement. ACKs 90 share the same medium route with data packets, causing similar medium 91 access overhead despite the much smaller size of the ACKs. 92 Contentions and collisions, as well as the wasted wireless resources 93 by ACKs, lead to significant throughput decline on the data path. 95 3. Overview of Standards on ACK Mechanism 97 [QUIC-TRANSPORT] specifies a simple delayed ACK mechanism that a 98 receiver can send an ACK for every other packet, and for every packet 99 when reordering is observed, or when the max_ack_delay timer expires. 100 However, this ACK mechanism may not match the number of ACKs to the 101 transport's required intensity under different network conditions. 102 For example, when the data throughput of a WLAN transport is 103 extremely high, QUIC will generate a large number of ACKs. In this 104 case, minimizing the ACK intensity of QUIC is not only a win for data 105 throughput improvement but also a win for energy and CPU efficiency. 107 RFC 1122 [RFC1122] and RFC 5681 [RFC5681] were two core functionality 108 standards that introduced delayed ACK, which was the default 109 acknowledgment mechanism in most Linux distributions. RFC 4341 110 [RFC4341] and RFC 5690 [RFC5690] described an acknowledgment 111 congestion control mechanism in which the minimum ACK frequency 112 allowed is twice per send window. RFC 3449 [RFC3449] discussed the 113 imperfection and variability of TCP's acknowledgment mechanism 114 because of asymmetric effects and recommended scaling ACK frequency 115 as a mitigation to these effects. These RFCs reveal that the 116 dependence on frequent ACKs is an artifact of current transport 117 protocol designs rather than a fundamental requirement. Based on 118 this insight, some work-in-progress IETF drafts have paid great 119 attention to ACK scaling technologies in both TCP and QUIC working 120 groups. 122 First of all, [ACK-PULL] proposed the TCP ACK pull mechanism, which 123 allows a sender to request the ACK for a data segment to be sent 124 without additional delay by the receiver. This helps in some cases 125 when the delayed ACKs degrade transport performance. 127 Instead of pulling more ACKs, [QUIC-SCALING] recommended that 128 reducing the ACK frequency by sending an ACK for at least every 10 129 received packets and [QUIC-SATCOM] recommended an ACK frequency of 130 four ACKs every round-trip time (RTT), aiming to reduce link 131 transmission costs for asymmetric paths. 133 Different from using an empirical value of ACK frequency, instead, 134 this draft aims to improve the scalability by proposing the Tame ACK 135 (TACK), whose frequency is a function of bandwidth-delay product of 136 network connections. [IYENGAR-ACK] has proposed an extension of 137 sender controlled ACK-FREQUENCY frame for QUIC, which is possible to 138 be reused to help the sender sync the dynamically adjusted TACK 139 frequency with the receiver in this case. 141 4. Optimized ACK Mechanism for QUIC 143 4.1. Reducing ACK intensity 145 ACK intensity can be quantified by the unit of Hz, i.e., number of 146 ACKs per second. Byte-counting ACK and periodic ACK are two 147 fundamental ways to reduce ACK intensity on the transport layer. 149 1. Byte-counting ACK: ACK intensity is controlled by sending an ACK 150 for every L (L >= 2) incoming full-sized packets, in which the packet 151 size equals to the Max Packet Size (set in the max_packet_size 152 parameter in QUIC). The intensity of byte-counting ACK (f_b) is 153 proportional to data throughput (bw): 155 f_b = bw/L*max_packet_size (1) 157 In general, f_b can be reduced by setting a large value of L. 158 However, for a given L, f_b increases with bw. This means when data 159 throughput is extremely high, the ACK intensity still might be 160 comparatively large. In other words, the intensity of byte-counting 161 ACK changes proportionately with bandwidth. 163 2. Periodic ACK: Byte-counting ACK's unbounded intensity can be 164 attributed to the coupling between ACK sending and packet arrivals. 165 Periodic ACK can decouple ACK intensity from packet arrivals, 166 achieving a bounded ACK intensity when bw is high. The intensity of 167 periodic ACK (f_pack) is: 169 f_pack = 1/alpha (2) 171 Where alpha is the time interval between two ACKs and is a function 172 of RTT. However, when bw is extremely low, the ACK intensity is 173 always as high as that in the case of a high throughput. In other 174 words, the intensity of periodic ACK is unadaptable to bandwidth 175 change, which wastes resources. 177 Combining these two ways, the minimum ACK intensity in a QUIC 178 connection can be set as f_quic = min{f_b,f_pack}. Through Equations 179 (1) and (2), we have 181 f_quic = min{bw/(L*max_packet_size), 1/alpha} (3) 183 We set alpha = RTTmin/beta, which means sending beta ACKs per RTTmin. 184 RTTmin is the minimum RTT observed for a given network path. As a 185 consequence, the minimum ACK intensity in a QUIC connection can be 186 given as follow: 188 f_quic = min{bw/(L*max_packet_size), beta/RTTmin} (4) 189 where beta indicates the number of ACKs per RTT, and L indicates the 190 number of full-sized data packets counted before sending an ACK. To 191 minimize the ACK intensity, a smaller beta or a larger L is expected. 192 Sara Landstrom et al. has given a lower bound of beta in [Sara], 193 i.e., beta >= 2. An upper bound of L can also be derived according 194 to the loss rate on the data path (plr_data) and the ack path 195 (plr_ack), i.e., L <= feedback_info/(plr_data*plr_ack), where 196 feedback_info denotes the amount of information carried by an ACK 198 Qualitatively, periodic ACK is applied when bandwidth-delay product 199 (bdp) is large (i.e., bdp >= beta*L* max_packet_size), and byte- 200 counting ACK is applied when bdp is small (i.e., bdp < beta*L* 201 max_packet_size). 203 In terms of a transport with a large bdp, beta = 2 should be 204 sufficient to ensure utilization, but the large bottleneck buffer 205 (i.e., one bdp) makes it necessary to acknowledge data more often. 206 In general, the minimum send window (SWNDmin) can be roughly 207 estimated as follow: 209 SWNDmin = beta*bdp/(beta-1) (5) 211 Ideally, the bottleneck buffer requirement is decided by the minimum 212 send window, i.e., SWNDmin - bdp. Since doubling the ACK frequency 213 reduces the bottleneck buffer requirement substantially from 1 bdp to 214 0.33 bdp, beta = 4 is RECOMMENDED to provide redundancy [Sara], being 215 more robust in practice. 217 4.2. OWD-based RTTmin estimation 219 In this document, the RTTmin is the minimum RTT samples observed at 220 the sender for a given network path during a period of time, and 221 OWDmin is the minimum OWD samples observed on the same network path 222 during a period of time. 224 When multiple packets carrying departure timestamps are transported 225 between endpoints via the same path, an RTT of this path can be 226 sampled at the sender upon receiving an ACK frame. However, when 227 sending fewer ACK frames, more data packets might be received during 228 the ACK interval, generating only one RTT sample among multiple 229 packets is likely to result in biases. For example, a larger minimum 230 RTT estimate. In general, the higher the throughput, the larger the 231 biases. One alternative way to reduce biases can be that, each ACK 232 frame carries multiple timestamps (as well as ACK delays in 233 [QUIC-RECOVERY] for the sender to generate more RTT samples. 234 However, (1) the overhead is high, which is unacceptable especially 235 under high-bandwidth transport. Also, (2) the number of data packets 236 might be far more than the maximum number of timestamps that an ACK 237 frame is capable to carry. 239 An RTT estimation system contains a sender and a receiver. The 240 sender can hardly generate per-packet RTT samples, which is the root 241 cause of the minimum RTT estimation biases in the case of sending 242 fewer ACKs. When multiple packets carrying departure timestamps are 243 transported between endpoints via the same path , an RTT of this path 244 can be sampled at the sender upon receiving an ACK frame. However, 245 when sending fewer ACK frames, more data packets might be received 246 during the ACK interval, generating only one RTT sample among 247 multiple packets is likely to result in biases. For example, a 248 larger minimum RTT estimate. In general, the higher the throughput, 249 the larger the biases. One alternative way to reduce biases can be 250 that, each ACK frame carries multiple timestamps (as well as ACK 251 delays in [QUIC-RECOVERY]) for the sender to generate more RTT 252 samples. However, (1) the overhead is high, which is unacceptable 253 especially for high-bandwidth transport. Also, (2) the number of 254 data packets might be far more than the maximum number of timestamps 255 that an ACK frame is capable of carrying. Since the receiver is 256 capable to monitor per-packet state, the one-way delay (OWD) of each 257 packet can be easily computed according to the departure timestamps 258 (carried in the packet) and the arrival timestamps of each packet. 259 In this case, QUIC SHOULD adopt the OWD-based RTTmin estimation. The 260 rationale is that the variation of OWD reflects the variation of RTT 261 over near-symmetric links. The OWD-based RTTmin estimation requires 262 the sender to record the departure timestamp in each ack-eliciting 263 packet. Meanwhile, at the receiver, the per-packet OWD samples 264 SHOULD be computed upon packet arrivals and a function of computing 265 the minimum OWD SHOULD be newly added. The receiver then generates 266 an ACK frame to the sender, in which the ACK delay and departure 267 timestamp for the packet that achieves the minimum OWD is reported. 268 The ACK delay is defined as the delay incurred between when the 269 packet is received and when the ACK frame is sent. Based on the 270 information reported by the incoming ACK frames and the ACK arrival 271 timestamps, the sender can generate RTT samples and then compute 272 RTTmin accordingly. 274 In this document, RTTmin is used to update the ACK intensity. In 275 general, RTTmin can also be used by other modules. For example, some 276 congestion controllers depends on RTTmin to estimate the congestion 277 window [Neal]. RTTmin is also used by QUIC loss detection to reject 278 implausibly small rtt samples [QUIC-RECOVERY]. 280 4.3. Sender-Side Operation 282 According to Formula (4), the run-time ACK intensity in QUIC are 283 decided by bw, and RTTmin. Generally, the RTTmin and bw are 284 calculated at the sender. 286 Before estimating the RTTmin, the RTT samples should be computed 287 based on the ACK frames collected during a period of time. Assume 288 that a packet is sent by the sender at time t_1 and arrives at time 289 t_3, and the ACK frame is sent at time t_4. The ACK delay can be 290 computed at the receiver. For example, the receiver computes the ACK 291 delay delta_t = t_4 - t_3, and syncs the ACK delay to the sender via 292 an ACK frame. The ACK delay can also be computed at the sender. For 293 example, the receiver directly syncs an ACK frame carrying t_4 and 294 t_3 to the sender, the sender then computes the ACK delay delta_t = 295 t_4 - t_3. 297 The sender therefore computes an RTT sample according to delta_t, 298 t_1, and the arrival time (t_2) of the ACK frame, i.e., RTT_sample = 299 t_2 - t_1 - delta_t. Measuring delta_t at the receiver assures an 300 explicit correction for a more accurate RTT estimate. RTT samples 301 SHOULD be smoothed using exponentially weighted moving average (EWMA) 302 as specified in [RFC6298]. The sender then computes the RTTmin 303 according to these RTT samples during a period of time. 305 The bw estimation can be acquired in a similar manner to BBR [Neal]. 306 Since minimizing the ACK intensity induces excessive ACK delay, the 307 value of bw may be the average value over a long period of time. 308 However, the biases introduced in ACK intensity computation is 309 limited. 311 After computing the f_quic, the sender periodically syncs it to the 312 receiver to update the intensity of ACK Frame by sending a new ACK- 313 INTENSITY frame. 315 The sender SHOULD generate an ACK-INTENSITY frame on a regular basis. 316 For example, when the change of f_quic exceeds a threshold, the ACK- 317 INTENSITY frame should be sent to update the ACK intensity in time. 318 The interval of ACK-INTENSITY frame can also be set according to the 319 update window of RTTmin and bw. 321 4.4. Receiver-side Operation 323 Currently, the QUIC receiver reports ACK delays for only the largest 324 acknowledged packet in an ACK frame, hence an RTT sample is generated 325 using only the largest acknowledged packet in the received ACK frame. 326 For a more accurate RTTmin estimate when sending fewer ACK frames, 327 QUIC SHOULD adopt the OWD-based RTTmin estimation. The OWD-based 328 RTTmin estimation requires the QUIC receiver to filter the departure 329 timestamp for the packet that achieves the minimum OWD during the 330 interval between two ACK frames and report the ACK delay of this 331 packet. Whether redefining the meaning of ACK delay or not, it 332 depends on the negotiation between endpoints of the QUIC connection. 334 Upon packet arrivals, the receiver is capable to generate per-packet 335 OWD samples according to the difference between packet departure 336 timestamp and packet arrival timestamp. The receiver then computes 337 the minimum OWD by comparing the per-packet OWD samples. The OWD 338 estimation does not require clock synchronization here because the 339 relative values are adopted. 341 Afterwards, based on the ACK delay and the departure timestamp 342 corresponding to the packet that achieves the minimum OWD, the sender 343 calculates the RTT of this packet as a minimum RTT sample. 344 Ultimately, the minimum RTT is computed according to these minimum 345 RTT samples. 347 The ACK Delay field SHOULD be carried in the ACK Frame. Other fields 348 carried in the ACK frame have the same meaning as defined in 349 [QUIC-RECOVERY]. 351 The receiver adopts the newly updated ACK intensity once it receives 352 the ACK-INTENSITY frame from the sender. 354 4.5. Generating ACK 356 The newly proposed ACK mechanism SHOULD be applied when there is no 357 out-of-order delivery. When reordering happens, the ACK Frame SHOULD 358 be generated immediately. 360 4.6. Modification to QUIC Protocol 362 4.6.1. Transport Parameter: ack-intensity-support 364 A new field named ack-intensity-support should be added for 365 negotiation between both parties whether starting the dynamic ACK 366 intensity function in QUIC connection. The endpoints sends this 367 parameter during handshakes. Only when both parties agree, ACK 368 intensity refreshment can be adopted. 370 ack-intensity-support (0x XX):This parameter has two values (0 or 1) 371 specifying whether the sending endpoint is willing to adopt ACK 372 intensity refreshment. When the value is set as 1, it means that the 373 sending endpoint want to start ACK intensity refreshment during 374 connection. When the value is set as 0, it means that the sending 375 endpoint does not support this function. 377 4.6.2. ACK-INTENSITY Frame 379 An ACK-INTENSITY frame is shown in Figure 1. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | 0x b0(i) ... 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Sequence Number(i) ... 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | ACK Intensity (i) ... 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 1: ACK-INTENSITY Frame 393 An ACK-INTENSITY frame contains the following fields: 395 Sequence Number: A variable-length integer indicating the sequence 396 number assigned to the ACK-INTENSITY frame by the sender. 398 ACK Intensity: A variable-length integer indicating the updated 399 f_quic calculated by the sender. 401 ACK-INTENSITY frames are ack-eliciting. However, their loss does not 402 require retransmission. 404 Multiple ACK-INTENSITY frames SHOULD be generated by the sender 405 during a connection to notify the receiver the variation of ACK 406 intensity requirement under network dynamics. 408 4.6.3. TIMESTAMP Frame 410 Instead of the invasive way of adding a new field in the QUIC public 411 packet header, it is RECOMMENDED that a new frame be added for 412 exchanging the departure timestamp of each packet. 414 A TIMESTAMP frame is shown in Figure 2. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | 0x b1(i) ... 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Departure Timestamp (i) ... 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Figure 2: TIMESTAMP Frame 426 A TIMESTAMP frame contains the following fields: 428 Departure Timestamp: An integer indicating the departure time of a 429 packet. 431 QUIC SHOULD carry the TIMESTAMP Frame in each packet. 433 4.6.4. ACK Delay Redefinition 435 The ACK Delay field is carried in the ACK Frame. Currently, the QUIC 436 receiver reports ACK delays for only the largest acknowledged packet 437 in an ACK frame, hence an RTT sample is generated using only the 438 largest acknowledged packet in the received ACK frame. For a more 439 accurate RTTmin estimate when sending fewer ACK frames, QUIC SHOULD 440 adopt the OWD-based RTTmin estimation. The OWD-based RTTmin 441 estimation requires the QUIC receiver to filter the departure 442 timestamp for the packet that achieves the minimum OWD during the 443 interval between two ACK frames and report the ACK delay of this 444 packet. Whether redefining the meaning of ACK delay or not, it 445 depends on the negotiation between endpoints of the QUIC connection. 447 In other words, QUIC SHOULD change the way of computing ACK Delay 448 according to the arrival timestamp of the packet with minimum OWD 449 instead of the arrival timestamp of the largest acknowledged packet. 451 5. Security Considerations 453 TBD 455 6. IANA Considerations 457 The value for ack-intensity-support transport parameter and ACK- 458 INTENSITY frame should be allocated. 460 7. References 462 7.1. Normative References 464 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 465 Communication Layers", STD 3, RFC 1122, 466 DOI 10.17487/RFC1122, October 1989, 467 . 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, 471 DOI 10.17487/RFC2119, March 1997, 472 . 474 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 475 Sooriyabandara, "TCP Performance Implications of Network 476 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 477 December 2002, . 479 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 480 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 481 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 482 2006, . 484 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 485 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 486 . 488 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 489 Acknowledgement Congestion Control to TCP", RFC 5690, 490 DOI 10.17487/RFC5690, February 2010, 491 . 493 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 494 "Computing TCP's Retransmission Timer", RFC 6298, 495 DOI 10.17487/RFC6298, June 2011, 496 . 498 7.2. Informative References 500 [ACK-PULL] 501 Gomez, C., Ed. and J. Crowcroft, Ed., "TCP ACK Pull", 502 draft-gomez-tcpm-ack-pull-01 (work in progress), November 503 2019. 505 [IYENGAR-ACK] 506 Iyengar, J., Ed. and I. Swett, Ed., "Sender Control of 507 Acknowledgement Delays in QUIC", draft-iyengar-quic- 508 delayed-ack-02 (work in progress), November 2020. 510 [Neal] Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., and 511 V. Jacobson, "BBR: Congestion-based congestion control", 512 ACM QUEUE 14(5):20-53, 2016. 514 [QUIC-RECOVERY] 515 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 516 and Congestion Control", draft-ietf-quic-recovery-27 (work 517 in progress), February 2020. 519 [QUIC-SATCOM] 520 Kuhn, N., Ed., Fairhurst, G., Ed., Border, J., Ed., and E. 521 Stephan, Ed., "QUIC for SATCOM", draft-kuhn-quic-4-sat-06 522 (work in progress), October 2020. 524 [QUIC-SCALING] 525 Fairhurst, G., Ed., Custura, A., Ed., and T. Jones, Ed., 526 "Changing the Default QUIC ACK Policy", draft-fairhurst- 527 quic-ack-scaling-03 (work in progress), September 2020. 529 [QUIC-TRANSPORT] 530 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 531 Multiplexed and Secure Transport", draft-ietf-quic- 532 transport-27 (work in progress), March 2020. 534 [Sara] Landstrom, S. and L. Larzon, "Reducing the tcp 535 acknowledgment frequency", ACM SIGCOMM CCR 37(3):5-16, 536 2007. 538 Authors' Addresses 540 Tong Li 541 Huawei 542 D2-03,Huawei Industrial Base 543 Longgang District 544 Shenzhen 545 China 547 Email: li.tong@huawei.com 549 Kai Zheng 550 Huawei 551 Information Road, Haidian District 552 Beijing 553 China 555 Email: kai.zheng@huawei.com 557 Rahul Arvind Jadhav 558 Huawei 559 D2-03,Huawei Industrial Base 560 Longgang District 561 Shenzhen 562 China 564 Email: rahul.jadhav@huawei.com 565 Jiao Kang 566 Huawei 567 D2-03,Huawei Industrial Base 568 Longgang District 569 Shenzhen 570 China 572 Email: kangjiao@huawei.com