idnits 2.17.1 draft-fairhurst-quic-ack-scaling-01.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 (March 05, 2020) is 1513 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-26 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 == Outdated reference: A later version (-02) exists of draft-iyengar-quic-delayed-ack-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Fairhurst 3 Internet-Draft A. Custura 4 Intended status: Informational T. Jones 5 Expires: September 6, 2020 University of Aberdeen 6 March 05, 2020 8 Changing the Default QUIC ACK Policy 9 draft-fairhurst-quic-ack-scaling-01 11 Abstract 13 ACKs are used by transport protocols to confirm delivery of packets. 14 The transmission of ACKs consumes resources at the receiver, in the 15 network and at the sender. On network paths where there is 16 significant path asymmetry, acknowledgments of data receipt can 17 reduce the efficient use of network capacity. This effect occurs 18 when the return capacity is significantly more constrained than the 19 forward capacity, or the cost of transmission per packet is a 20 significant component of the total transmission cost. In these 21 cases, reducing the ratio of acknowledgements to data can improve 22 link utilization and reduce link transmission costs. It can also 23 reduce processing overhead at the sender and receiver. 25 This document proposes a change to the default acknowledgement policy 26 of the QUIC transport protocol to improve performance over paths with 27 appreciable asymmetry. 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 September 6, 2020. 46 Copyright Notice 48 Copyright (c) 2020 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 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. ACK Ratio Impact on Asymmetric Paths . . . . . . . . . . 3 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.3. Adapting the ACK Ratio in Current Transport 68 Specifications . . . . . . . . . . . . . . . . . . . . . 3 69 2.4. Adapting the ACK Ratio in the Network . . . . . . . . . . 4 70 3. Updating the Default ACK Ratio for QUIC . . . . . . . . . . . 4 71 3.1. Considerations Updating the Default QUIC ACK Policy . . . 5 72 3.2. During Slow Start . . . . . . . . . . . . . . . . . . . . 6 73 3.3. After Slow Start . . . . . . . . . . . . . . . . . . . . 6 74 3.4. When Encountering Loss/Congestion . . . . . . . . . . . . 6 75 4. Recommended ACK Policy . . . . . . . . . . . . . . . . . . . 6 76 4.1. Further Tuning of the ACK Policy . . . . . . . . . . . . 7 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 7.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Appendix A. Summary of Recommended ACK Policy for TCP . . . . . 9 83 Appendix B. Experiments Exploring an ACK Ratio of 1:10 . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 The current design of QUIC [I-D.ietf-quic-transport] currently 89 proposes a default acknowledgement (ACK) ratio of 1:2 (at least one 90 ACK for every 2 ack-eliciting packets) inspired by current 91 recommendations for TCP, Appendix A, see. This document proposes an 92 increase in the ratio of ACK packets to data packets from 1:2 to 1:10 93 for QUIC flows. 95 2. Motivation 97 When the characteristics of the forward and return paths are not 98 symmetric, the transmission of ACKs can adversely impact either 99 transport performance or the cost of sending data across a link. 101 2.1. ACK Ratio Impact on Asymmetric Paths 103 TCP Performance Implications of Network Path Asymmetry [RFC3449] 104 describes a series of problems and mitigations when transports use an 105 asymmetric path. Performance problems arise in several access 106 networks, including bandwidth-asymmetric networks (such as broadband 107 satellite access, DOCSIS cable networks, cellular mobile, WiFi, etc). 109 Where the ACK rate is limited by the capacity of the return path, 110 this constrains the maxium throughput for the forward path. The ACK 111 traffic also competes for capacity and/or transmission opportunities 112 with other traffic that shares a constrained return path. This 113 motivates the need to reduce the volume of ACK traffic (increase the 114 number of segments/packets that are acknowledged by each ACK). 116 Capacity is not the only asymmetric path constraint. Sending ACKs 117 can consume significant transmission resources and the cost of 118 transmitting ACKs can become a significant part of the cost of 119 transmission when using a network segment. In many wireless 120 technologies, there is appreciable overhead for the transmission of 121 each packet burst (data and ACK). There can also be associated costs 122 (e.g. in radio resource management and transmission scheduling) that 123 are often different for the forward and return paths because they use 124 different technologies or configurations. This provides an incentive 125 to reduce the rate of ACK traffic. 127 2.2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2.3. Adapting the ACK Ratio in Current Transport Specifications 137 Various methods have been proposed to modify the ACK Ratio used by 138 transport protocols. Two examples follow: 140 ACK-CC [RFC5690] proposed a method to control the rate of ACKs to 141 avoid the return path from becoming congested, but this did not 142 achieve wide-scale deployment. 144 The Datagram Congestion Control Protocol (DCCP) [RFC4340] has methods 145 to control the ACK ratio at the receiver. DCCP specifies a TCP- 146 friendly congestion control [RFC4341], which includes the ability to 147 use signaling to allow this sender to adjust the receiver ACK ratio 148 within certain parameters. This also was not widely used. 150 End-to-end transport methods do not have a way to detect and account 151 for the cost of ACK transmission, and are difficult to tune to adapt 152 to delays introduced by the path (especially when fair-queueing and 153 other link scheduling methods hide the effects of increased ACK 154 traffic). They therefore only provide a partial mitigation to the 155 impacts when sending ACKs over asymmetric paths. 157 2.4. Adapting the ACK Ratio in the Network 159 An alternative approach has been deployed for TCP that uses a 160 middlebox in the network to thin the rate of ACKs. This method is 161 used with paths that exhibit significant ACK symmetry to improve 162 performance of TCP when it uses an ACK Ratio of 1:2 [RFC3449]. 163 Performance Enhancing Proxies (PEPs) can implement these functions 164 when they detect/know an upstream link is filled with TCP ACKs. 166 Removing redundant ACKs (also known as "ACK Thinning") leads to TCP 167 stretch ACKs (where a single ACK acknowledges more than two TCP 168 segments). The introduction of TCP Appropriate Byte Counting (ABC) 169 i[RFC3465] partly mitigates the impact of stretch ACKs, and also 170 recommends burst mitigation techniques at a TCP sender. 172 These methods only work when ACKs can be observed by a device in the 173 network. QUIC uses an encrypted feedback packet to communicate an 174 ACK. The use of encryption intentionally prevents such in-network 175 optimisations. Compared to TCP, performance of QUIC is therefore 176 disadvantaged when QUIC uses an ACK Ratio of 1:2. 178 QUIC ACKs are also significantly larger in size than TCP ACKS (e.g., 179 1.5-2 times), which means additional processing overhead and link 180 usage for all Internet paths, with a significant impact on asymmetric 181 links, where this can also limit throughput. 183 3. Updating the Default ACK Ratio for QUIC 185 Any ACK policy that changes the ACK ratio from 1:2 needs to 186 compensate for three issues: 188 o A reduced frequency of feedback can increase the time to detect 189 congestion, impacting the congestion control algorithm. QUIC 190 mitigates this by using PTO-based retransmission. 192 o A reduced frequency of feedback can increase the time to detect 193 loss, impacting the loss recovery algorithm, and potentially 194 leading to cases of spurious retransmission; 196 o A reduced ACK rate can lead to bursts of acknowledged packets, and 197 introduces a need for burst mitigation at the sender; 199 3.1. Considerations Updating the Default QUIC ACK Policy 201 The QUIC transport protocol currently specifies a maximum ACK Delay, 202 which is communicated by the sender to indicate the maximum time an 203 endpoint will delay sending acknowledgments. A default of 25 204 milliseconds is recommended and QUIC currently recommends a default 205 ACK Ratio of 1:2 [I-D.ietf-quic-transport]. 207 This document proposes changing the default QUIC behaviour to send an 208 ACK for at least every 10 received packets. Further background to 209 the proposed method is detailed in the Annexe (Appendix B). 211 The ACK Delay timer ensures ACKs are not unduly delayed. The effect 212 of a large delay could be significant when a stretched ACK 213 acknowledges more packets, and therefore the proposed method also 214 ensures feedback at least four times per RTT (less important when the 215 RTT is greater than 100ms and the ACK Delay forms a small part of the 216 total RTT). 218 Loss detection can be impacted by delayed acknowledgments. Although 219 timer-based methods (e.g., using the QUIC Probe Timeout (PTO), see 220 section 5.1 of [I-D.ietf-quic-recovery]) can reduce the reliance on 221 ACKs to detect loss, prompt communication of ACK ranges after loss is 222 still important to efficient loss recovery. 224 Since the introduction of the specification to allow a larger TCP 225 Initial Window (IW) [RFC6928], there has been deployment experience 226 using TCP with an IW of 10 segments at startup. QUIC continues this 227 practice, which in part motivates the need for a QUIC transport 228 protocol to operate when a burst of acknowledgements for up to ten 229 packets is received. QUIC therefore transport recommends the use of 230 pacing to mitigate packet bursts being generated by a sender (see 231 section 6.8 of [I-D.ietf-quic-recovery]). 233 The proposed method seeks to allow QUIC to effectively operate over 234 asymmetric paths. 236 3.2. During Slow Start 238 Some congestion controllers can benefit from frequent feedback during 239 an initial slow start period, where the sender is probing for 240 available path capacity. This update therefore does not change the 241 recommended ACK Ratio during the initial part of slow start. This 242 ensures stretch ACKs do not impact the initial rate of growth for the 243 congestion window. 245 A suitable method might send an ACK frame for every received ack- 246 eliciting packets for the first 100 received packets if max_ack_delay 247 time has passed since the oldest unacknowledged data was received. 249 A receiver typically has no understanding of the senders congestion 250 control state. The number 100 reflects a trade-off, corresponding to 251 an appreciable opening of the sender's congestion window. 253 A congestion controller typically re-enters slow start after 254 congestion is detected. The need to probe to re-establish a working 255 congestion window is helped by the ACK policy after loss. 257 3.3. After Slow Start 259 A receiver sends an ACK if a period more than 260 MIN(max_ack_delay,min_rtt/4) has passed since receiving the oldest 261 unacknowledged data OR it has accumulated 10 unacknowledged packets. 263 3.4. When Encountering Loss/Congestion 265 Following detected loss or congestion, a receiver sends ACKs 266 according to section 13.2.1 of QUIC transport 267 [I-D.ietf-quic-transport]. 269 4. Recommended ACK Policy 271 The max_ack_delay needs to be set so that at least several samples 272 can be generated per RTT to estimate the path RTT. 274 A QUIC receiver can generate one ACK frame for every received ack- 275 eliciting packet. TCP recommends that a receiver generates an ACK 276 corresponding to every second MSS of received data, Section 4.2 of 277 RFC 5681 [RFC5681], however RFC 3449 [RFC3449] also notes the need 278 for, and deployment of, methods to further reduce the number of TCP 279 ACKs in networks with asymmetric paths. 281 An ACK frame SHOULD be generated for at least every tenth ack- 282 eliciting packet. The maximum of receiving not more than 10 ack- 283 eliciting packets is derived from the recommended TCP Initial Window 284 [RFC6928]. 286 Using an appropriate value for max_ack_delay, or ensuring a minimum 287 number of ACKs per RTT (e.g 8) would mitigate the effect of ACK loss 288 on RTT estimation and aids performance for low-rate interactive 289 applications. 291 4.1. Further Tuning of the ACK Policy 293 In situations where the default method is not sufficient, the ACK 294 Ratio might be further tuned by server, as described in 295 [I-D.iyengar-quic-delayed-ack]. This could also permit the ACK 296 method to be adapted to match the behaviour of new congestion control 297 algorithms. Reducing the rate of ACKs can also lower the 298 computational effort required to process ACKs at the sender and 299 receiver. For instance, this could reduce the workload for high 300 speed network interfaces by reducing the rate of cache ejection for 301 Generic Receiver Offload (GRO). 303 5. IANA Considerations 305 This memo includes no request to IANA. 307 6. Security Considerations 309 The security considerations for the QUIC transport protocol are 310 described in [I-D.ietf-quic-transport]. 312 7. References 314 7.1. Normative References 316 [I-D.ietf-quic-recovery] 317 Iyengar, J. and I. Swett, "QUIC Loss Detection and 318 Congestion Control", draft-ietf-quic-recovery-26 (work in 319 progress), February 2020. 321 [I-D.ietf-quic-transport] 322 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 323 and Secure Transport", draft-ietf-quic-transport-27 (work 324 in progress), February 2020. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 333 May 2017, . 335 7.2. Informative References 337 [I-D.iyengar-quic-delayed-ack] 338 Iyengar, J. and I. Swett, "Sender Control of 339 Acknowledgement Delays in QUIC", draft-iyengar-quic- 340 delayed-ack-00 (work in progress), January 2020. 342 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 343 Communication Layers", STD 3, RFC 1122, 344 DOI 10.17487/RFC1122, October 1989, 345 . 347 [RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, 348 J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known 349 TCP Implementation Problems", RFC 2525, 350 DOI 10.17487/RFC2525, March 1999, 351 . 353 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 354 Sooriyabandara, "TCP Performance Implications of Network 355 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 356 December 2002, . 358 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 359 Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 360 2003, . 362 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 363 Congestion Control Protocol (DCCP)", RFC 4340, 364 DOI 10.17487/RFC4340, March 2006, 365 . 367 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 368 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 369 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 370 2006, . 372 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 373 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 374 . 376 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 377 Acknowledgement Congestion Control to TCP", RFC 5690, 378 DOI 10.17487/RFC5690, February 2010, 379 . 381 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 382 "Increasing TCP's Initial Window", RFC 6928, 383 DOI 10.17487/RFC6928, April 2013, 384 . 386 Appendix A. Summary of Recommended ACK Policy for TCP 388 RFC 5681 [RFC5681] clarifies the TCP ACK frequency described in 389 RFC 1122 [RFC1122] to recommend the ACK policy for a TCP receiver: 390 "an ACK SHOULD be generated for at least every second full-sized 391 segment, and MUST be generated within 500 ms of the arrival of the 392 first unacknowledged packet". 394 The TCP sender regards reception of an ACK as a positive indication 395 that data has been received across the path. The congestion control 396 algorithm uses this to increase the size of the congestion window, 397 cwnd RFC 5681 [RFC5681]. 399 To reduce the ACK Rate, a receiver can delay sending an ACK for a 400 period of time called the ACK Delay. This can increase network 401 efficiency. When the receiver delays ACKs, this reduces the rate of 402 growth of the cwnd. TCP implementations often use heuristics such as 403 DAAS (Delayed ACK after Slow Start) to mitigate this. This allows 404 the receiver to estimate when the sender could be in the slow start 405 phase of cwnd growth, and for a period of time sends an ACK for each 406 received segment/packet (i.e., an ACK Ratio of 1:1). 408 ACKs can be lost on the return path (either through packet loss, or 409 by intentional thinning of the ACK stream). If a sender does not 410 receive an ACK for every second segment, a stretch ACK has occurred. 411 RFC2525 [RFC2525] describes the significance of stretch ACK 412 violations: 414 "this behavior will cause TCP senders to generate burstier traffic, 415 which can degrade performance in congested environments. In 416 addition, generating fewer ACKs increases the amount of time needed 417 by the slow start algorithm to open the congestion window to an 418 appropriate point, which diminishes performance in environments with 419 large bandwidth-delay products. Finally, generating fewer ACKs may 420 cause needless retransmission timeouts in lossy environments, as it 421 increases the possibility that an entire window of ACKs is lost, 422 forcing a retransmission timeout." 423 RFC 3465 [RFC3465] further discusses the issue of bursts that may be 424 caused by the interaction between ACK processing and congestion 425 control. This motivates a need to deal with bursts within TCP. TCP 426 senders can mitigate bursts by using Appropriate Byte Counting (ABC), 427 which increases the congestion window in proportion to the amount of 428 data sent into the network, rather than upon the arrival of each ACK. 429 (This also defends against ACK Splitting, where multiple ACKs are 430 received for parts of the same segment/packet). 432 There are other scenarios where a change to the TCP ACK policy would 433 have improved performance. However, the design of TCP, and 434 ossification of the protocol has made it hard for new mechanisms to 435 be deployed. QUIC does not suffer from these design constraints. 437 Appendix B. Experiments Exploring an ACK Ratio of 1:10 439 The performance of QUIC is at a disadvantage compared to other 440 transport protocols if designs use a conservative ACK Ratio, because 441 QUIC can not modified by in-network middleboxes (such as used for TCP 442 ACK Thinning). We argue that a default ratio of 1:2 is too 443 conservative. 445 We used an experimental approach to examine a change to QUIC's ACK 446 Policy . This 447 updated the default ACK Ratio from 1:2 to 1:10. Our tests show that 448 this did not negatively impact the protocol. This reduced the amount 449 of IP, UDP and ACK overhead by a factor of approximately 5. The 450 implemented congestion control, was also not negatively impacted. 451 These experiments were performed in January 2020 based on available 452 implementations at that time. 454 Unlike TCP, QUIC sends other types of data frames in addition to ACK 455 frames, increasing the total overhead on the return path. On 456 asymmetrical paths an ACK Ratio of 1:10 may still reduce the ACK 457 traffic, helping to avoid return path capacity limits impacting the 458 ability to use the forward path capacity. 460 Figure 1 presents a table with a set of asymmetric scenarios. The 461 columns present the rate of ACK traffic required (in kbps) to fill 462 each of the forward paths. The table shows the results for TCP 463 (without a PEP), both for lossless communication. It considers the 464 period after loss, when ACKs communicate the loss information. It 465 also shows the impact of using an ACK Ratio of 1:10 with QUIC. 467 An ACK Ratio of 1:10 reduces the utilisation of the return path. 468 Scenarios where the ACK traffic exceeds the return link capacity 469 (i.e. where this limits the forward path capacity that can be used) 470 are marked with a star. Note that the QUIC figure does not include 471 the encryption overhead, which would be dependent on the ciphers 472 chosen. This would add several additional bytes for every QUIC 473 packet. 475 +-------------------+-------------+---------------+-----------------+ 476 | | 10/2 Mbps | 50/10 Mbps | 250/3 Mbps | 477 +-------------------+-------------+---------------+-----------------+ 478 | TCP no loss | 133 - 346 | 650 -1,730 | 3250 - 8,650* | 479 | TCP loss | 346 - 560 | 1,730 - 2,800 | 8,650 - 14,000* | 480 | QUIC 1:2 no loss | 144 - 438 | 720 - 2,190 | 3,600 - 10,950* | 481 | QUIC 1:2 loss | 290 - * | 1450 - * | 7,250 - * | 482 | QUIC 1:10 no loss | 28.8 - 87.6 | 144 - 438 | 720 - 2,190 | 483 +-------------------+-------------+---------------+-----------------+ 485 Figure 1: ACK traffic required to fill the forward path in different 486 loss and asymmetry scenarios. The QUIC figures do not include 487 encryption overhead. 489 Figure 2 presents a table with the numbers of packets sent by two 490 QUIC implementations using a 1:2 and a 1:10 ACK Ratio. This shows 491 between a four and five time reduction in the number of packets sent. 493 +-------------------------------+----------------+----------------+ 494 | | Chromium | Quicly | 495 | | Draft 23 | Draft 23 | 496 +-------------------------------+----------------+----------------+ 497 | Packets sent | 77,419 | 83,238 | 498 | Packets on return path (1:2) | 39,089 (50.4%) | 41,108 (49.3%) | 499 | Packets on return path (1:10) | 10,409 (13.4%) | 9650 (11.5%) | 500 +-------------------------------+----------------+----------------+ 502 Figure 2: Number of packets sent and received during a 100MB QUIC 503 transfer using different ACK ratios, for two implementations 505 Figure 3 presents a table with the number of bytes sent by one of the 506 QUIC implementations using a 1:2 and a 1:10 ACK Ratio. This shows a 507 reduction in the number of bytes on the return path from 2.7 to 0.7% 508 of the total bytes sent. In these scenarios, this is sufficient to 509 take full advantage of the forward path capacity. 511 +---------------------------------+----------------+ 512 | | Chromium | 513 | | Draft 23 | 514 +---------------------------------+----------------+ 515 | Bytes sent | 110M | 516 | Bytes on return path (1:2 AR) | 3,056KB (2.7%) | 517 | Bytes on return path (1:10 AR) | 810KB (0.7%) | 518 +---------------------------------+----------------+ 520 Figure 3: Number of bytes sent and received during a 100MB Chromium 521 QUIC transfer using different ACK ratios 523 The number of bytes and packets reduces as expected when using an ACK 524 Ratio of 1:10, without any increase in loss, on a high-latency path 525 with an asymmetry of 5:1. This offers a clear benefit for paths that 526 are capacity-constrained, as well as paths which would benefit from a 527 reduction in the ACK Rate. 529 Authors' Addresses 531 Godred Fairhurst 532 University of Aberdeen 533 School of Engineering 534 Fraser Noble Building 535 Aberdeen AB24 3UE 536 UK 538 Email: gorry@erg.abdn.ac.uk 540 Ana Custura 541 University of Aberdeen 542 School of Engineering 543 Fraser Noble Building 544 Aberdeen AB24 3UE 545 UK 547 Email: ana@erg.abdn.ac.uk 549 Tom Jones 550 University of Aberdeen 551 School of Engineering 552 Fraser Noble Building 553 Aberdeen AB24 3UE 554 UK 556 Email: tom@erg.abdn.ac.uk