Changing the Default QUIC ACK Policy
draft-fairhurst-quic-ack-scaling-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Gorry Fairhurst , Ana Custura , Tom Jones | ||
| Last updated | 2020-03-05 (Latest revision 2020-01-29) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fairhurst-quic-ack-scaling-01
Internet Engineering Task Force G. Fairhurst
Internet-Draft A. Custura
Intended status: Informational T. Jones
Expires: September 6, 2020 University of Aberdeen
March 05, 2020
Changing the Default QUIC ACK Policy
draft-fairhurst-quic-ack-scaling-01
Abstract
ACKs are used by transport protocols to confirm delivery of packets.
The transmission of ACKs consumes resources at the receiver, in the
network and at the sender. On network paths where there is
significant path asymmetry, acknowledgments of data receipt can
reduce the efficient use of network capacity. This effect occurs
when the return capacity is significantly more constrained than the
forward capacity, or the cost of transmission per packet is a
significant component of the total transmission cost. In these
cases, reducing the ratio of acknowledgements to data can improve
link utilization and reduce link transmission costs. It can also
reduce processing overhead at the sender and receiver.
This document proposes a change to the default acknowledgement policy
of the QUIC transport protocol to improve performance over paths with
appreciable asymmetry.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2020.
Fairhurst, et al. Expires September 6, 2020 [Page 1]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. ACK Ratio Impact on Asymmetric Paths . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Adapting the ACK Ratio in Current Transport
Specifications . . . . . . . . . . . . . . . . . . . . . 3
2.4. Adapting the ACK Ratio in the Network . . . . . . . . . . 4
3. Updating the Default ACK Ratio for QUIC . . . . . . . . . . . 4
3.1. Considerations Updating the Default QUIC ACK Policy . . . 5
3.2. During Slow Start . . . . . . . . . . . . . . . . . . . . 6
3.3. After Slow Start . . . . . . . . . . . . . . . . . . . . 6
3.4. When Encountering Loss/Congestion . . . . . . . . . . . . 6
4. Recommended ACK Policy . . . . . . . . . . . . . . . . . . . 6
4.1. Further Tuning of the ACK Policy . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Summary of Recommended ACK Policy for TCP . . . . . 9
Appendix B. Experiments Exploring an ACK Ratio of 1:10 . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The current design of QUIC [I-D.ietf-quic-transport] currently
proposes a default acknowledgement (ACK) ratio of 1:2 (at least one
ACK for every 2 ack-eliciting packets) inspired by current
recommendations for TCP, Appendix A, see. This document proposes an
increase in the ratio of ACK packets to data packets from 1:2 to 1:10
for QUIC flows.
Fairhurst, et al. Expires September 6, 2020 [Page 2]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
2. Motivation
When the characteristics of the forward and return paths are not
symmetric, the transmission of ACKs can adversely impact either
transport performance or the cost of sending data across a link.
2.1. ACK Ratio Impact on Asymmetric Paths
TCP Performance Implications of Network Path Asymmetry [RFC3449]
describes a series of problems and mitigations when transports use an
asymmetric path. Performance problems arise in several access
networks, including bandwidth-asymmetric networks (such as broadband
satellite access, DOCSIS cable networks, cellular mobile, WiFi, etc).
Where the ACK rate is limited by the capacity of the return path,
this constrains the maxium throughput for the forward path. The ACK
traffic also competes for capacity and/or transmission opportunities
with other traffic that shares a constrained return path. This
motivates the need to reduce the volume of ACK traffic (increase the
number of segments/packets that are acknowledged by each ACK).
Capacity is not the only asymmetric path constraint. Sending ACKs
can consume significant transmission resources and the cost of
transmitting ACKs can become a significant part of the cost of
transmission when using a network segment. In many wireless
technologies, there is appreciable overhead for the transmission of
each packet burst (data and ACK). There can also be associated costs
(e.g. in radio resource management and transmission scheduling) that
are often different for the forward and return paths because they use
different technologies or configurations. This provides an incentive
to reduce the rate of ACK traffic.
2.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.3. Adapting the ACK Ratio in Current Transport Specifications
Various methods have been proposed to modify the ACK Ratio used by
transport protocols. Two examples follow:
ACK-CC [RFC5690] proposed a method to control the rate of ACKs to
avoid the return path from becoming congested, but this did not
achieve wide-scale deployment.
Fairhurst, et al. Expires September 6, 2020 [Page 3]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
The Datagram Congestion Control Protocol (DCCP) [RFC4340] has methods
to control the ACK ratio at the receiver. DCCP specifies a TCP-
friendly congestion control [RFC4341], which includes the ability to
use signaling to allow this sender to adjust the receiver ACK ratio
within certain parameters. This also was not widely used.
End-to-end transport methods do not have a way to detect and account
for the cost of ACK transmission, and are difficult to tune to adapt
to delays introduced by the path (especially when fair-queueing and
other link scheduling methods hide the effects of increased ACK
traffic). They therefore only provide a partial mitigation to the
impacts when sending ACKs over asymmetric paths.
2.4. Adapting the ACK Ratio in the Network
An alternative approach has been deployed for TCP that uses a
middlebox in the network to thin the rate of ACKs. This method is
used with paths that exhibit significant ACK symmetry to improve
performance of TCP when it uses an ACK Ratio of 1:2 [RFC3449].
Performance Enhancing Proxies (PEPs) can implement these functions
when they detect/know an upstream link is filled with TCP ACKs.
Removing redundant ACKs (also known as "ACK Thinning") leads to TCP
stretch ACKs (where a single ACK acknowledges more than two TCP
segments). The introduction of TCP Appropriate Byte Counting (ABC)
i[RFC3465] partly mitigates the impact of stretch ACKs, and also
recommends burst mitigation techniques at a TCP sender.
These methods only work when ACKs can be observed by a device in the
network. QUIC uses an encrypted feedback packet to communicate an
ACK. The use of encryption intentionally prevents such in-network
optimisations. Compared to TCP, performance of QUIC is therefore
disadvantaged when QUIC uses an ACK Ratio of 1:2.
QUIC ACKs are also significantly larger in size than TCP ACKS (e.g.,
1.5-2 times), which means additional processing overhead and link
usage for all Internet paths, with a significant impact on asymmetric
links, where this can also limit throughput.
3. Updating the Default ACK Ratio for QUIC
Any ACK policy that changes the ACK ratio from 1:2 needs to
compensate for three issues:
o A reduced frequency of feedback can increase the time to detect
congestion, impacting the congestion control algorithm. QUIC
mitigates this by using PTO-based retransmission.
Fairhurst, et al. Expires September 6, 2020 [Page 4]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
o A reduced frequency of feedback can increase the time to detect
loss, impacting the loss recovery algorithm, and potentially
leading to cases of spurious retransmission;
o A reduced ACK rate can lead to bursts of acknowledged packets, and
introduces a need for burst mitigation at the sender;
3.1. Considerations Updating the Default QUIC ACK Policy
The QUIC transport protocol currently specifies a maximum ACK Delay,
which is communicated by the sender to indicate the maximum time an
endpoint will delay sending acknowledgments. A default of 25
milliseconds is recommended and QUIC currently recommends a default
ACK Ratio of 1:2 [I-D.ietf-quic-transport].
This document proposes changing the default QUIC behaviour to send an
ACK for at least every 10 received packets. Further background to
the proposed method is detailed in the Annexe (Appendix B).
The ACK Delay timer ensures ACKs are not unduly delayed. The effect
of a large delay could be significant when a stretched ACK
acknowledges more packets, and therefore the proposed method also
ensures feedback at least four times per RTT (less important when the
RTT is greater than 100ms and the ACK Delay forms a small part of the
total RTT).
Loss detection can be impacted by delayed acknowledgments. Although
timer-based methods (e.g., using the QUIC Probe Timeout (PTO), see
section 5.1 of [I-D.ietf-quic-recovery]) can reduce the reliance on
ACKs to detect loss, prompt communication of ACK ranges after loss is
still important to efficient loss recovery.
Since the introduction of the specification to allow a larger TCP
Initial Window (IW) [RFC6928], there has been deployment experience
using TCP with an IW of 10 segments at startup. QUIC continues this
practice, which in part motivates the need for a QUIC transport
protocol to operate when a burst of acknowledgements for up to ten
packets is received. QUIC therefore transport recommends the use of
pacing to mitigate packet bursts being generated by a sender (see
section 6.8 of [I-D.ietf-quic-recovery]).
The proposed method seeks to allow QUIC to effectively operate over
asymmetric paths.
Fairhurst, et al. Expires September 6, 2020 [Page 5]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
3.2. During Slow Start
Some congestion controllers can benefit from frequent feedback during
an initial slow start period, where the sender is probing for
available path capacity. This update therefore does not change the
recommended ACK Ratio during the initial part of slow start. This
ensures stretch ACKs do not impact the initial rate of growth for the
congestion window.
A suitable method might send an ACK frame for every received ack-
eliciting packets for the first 100 received packets if max_ack_delay
time has passed since the oldest unacknowledged data was received.
A receiver typically has no understanding of the senders congestion
control state. The number 100 reflects a trade-off, corresponding to
an appreciable opening of the sender's congestion window.
A congestion controller typically re-enters slow start after
congestion is detected. The need to probe to re-establish a working
congestion window is helped by the ACK policy after loss.
3.3. After Slow Start
A receiver sends an ACK if a period more than
MIN(max_ack_delay,min_rtt/4) has passed since receiving the oldest
unacknowledged data OR it has accumulated 10 unacknowledged packets.
3.4. When Encountering Loss/Congestion
Following detected loss or congestion, a receiver sends ACKs
according to section 13.2.1 of QUIC transport
[I-D.ietf-quic-transport].
4. Recommended ACK Policy
The max_ack_delay needs to be set so that at least several samples
can be generated per RTT to estimate the path RTT.
A QUIC receiver can generate one ACK frame for every received ack-
eliciting packet. TCP recommends that a receiver generates an ACK
corresponding to every second MSS of received data, Section 4.2 of
RFC 5681 [RFC5681], however RFC 3449 [RFC3449] also notes the need
for, and deployment of, methods to further reduce the number of TCP
ACKs in networks with asymmetric paths.
An ACK frame SHOULD be generated for at least every tenth ack-
eliciting packet. The maximum of receiving not more than 10 ack-
Fairhurst, et al. Expires September 6, 2020 [Page 6]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
eliciting packets is derived from the recommended TCP Initial Window
[RFC6928].
Using an appropriate value for max_ack_delay, or ensuring a minimum
number of ACKs per RTT (e.g 8) would mitigate the effect of ACK loss
on RTT estimation and aids performance for low-rate interactive
applications.
4.1. Further Tuning of the ACK Policy
In situations where the default method is not sufficient, the ACK
Ratio might be further tuned by server, as described in
[I-D.iyengar-quic-delayed-ack]. This could also permit the ACK
method to be adapted to match the behaviour of new congestion control
algorithms. Reducing the rate of ACKs can also lower the
computational effort required to process ACKs at the sender and
receiver. For instance, this could reduce the workload for high
speed network interfaces by reducing the rate of cache ejection for
Generic Receiver Offload (GRO).
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
The security considerations for the QUIC transport protocol are
described in [I-D.ietf-quic-transport].
7. References
7.1. Normative References
[I-D.ietf-quic-recovery]
Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", draft-ietf-quic-recovery-26 (work in
progress), February 2020.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-27 (work
in progress), February 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Fairhurst, et al. Expires September 6, 2020 [Page 7]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[I-D.iyengar-quic-delayed-ack]
Iyengar, J. and I. Swett, "Sender Control of
Acknowledgement Delays in QUIC", draft-iyengar-quic-
delayed-ack-00 (work in progress), January 2020.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known
TCP Implementation Problems", RFC 2525,
DOI 10.17487/RFC2525, March 1999,
<https://www.rfc-editor.org/info/rfc2525>.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
Sooriyabandara, "TCP Performance Implications of Network
Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
December 2002, <https://www.rfc-editor.org/info/rfc3449>.
[RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February
2003, <https://www.rfc-editor.org/info/rfc3465>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March
2006, <https://www.rfc-editor.org/info/rfc4341>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
Fairhurst, et al. Expires September 6, 2020 [Page 8]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
Acknowledgement Congestion Control to TCP", RFC 5690,
DOI 10.17487/RFC5690, February 2010,
<https://www.rfc-editor.org/info/rfc5690>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>.
Appendix A. Summary of Recommended ACK Policy for TCP
RFC 5681 [RFC5681] clarifies the TCP ACK frequency described in
RFC 1122 [RFC1122] to recommend the ACK policy for a TCP receiver:
"an ACK SHOULD be generated for at least every second full-sized
segment, and MUST be generated within 500 ms of the arrival of the
first unacknowledged packet".
The TCP sender regards reception of an ACK as a positive indication
that data has been received across the path. The congestion control
algorithm uses this to increase the size of the congestion window,
cwnd RFC 5681 [RFC5681].
To reduce the ACK Rate, a receiver can delay sending an ACK for a
period of time called the ACK Delay. This can increase network
efficiency. When the receiver delays ACKs, this reduces the rate of
growth of the cwnd. TCP implementations often use heuristics such as
DAAS (Delayed ACK after Slow Start) to mitigate this. This allows
the receiver to estimate when the sender could be in the slow start
phase of cwnd growth, and for a period of time sends an ACK for each
received segment/packet (i.e., an ACK Ratio of 1:1).
ACKs can be lost on the return path (either through packet loss, or
by intentional thinning of the ACK stream). If a sender does not
receive an ACK for every second segment, a stretch ACK has occurred.
RFC2525 [RFC2525] describes the significance of stretch ACK
violations:
"this behavior will cause TCP senders to generate burstier traffic,
which can degrade performance in congested environments. In
addition, generating fewer ACKs increases the amount of time needed
by the slow start algorithm to open the congestion window to an
appropriate point, which diminishes performance in environments with
large bandwidth-delay products. Finally, generating fewer ACKs may
cause needless retransmission timeouts in lossy environments, as it
increases the possibility that an entire window of ACKs is lost,
forcing a retransmission timeout."
Fairhurst, et al. Expires September 6, 2020 [Page 9]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
RFC 3465 [RFC3465] further discusses the issue of bursts that may be
caused by the interaction between ACK processing and congestion
control. This motivates a need to deal with bursts within TCP. TCP
senders can mitigate bursts by using Appropriate Byte Counting (ABC),
which increases the congestion window in proportion to the amount of
data sent into the network, rather than upon the arrival of each ACK.
(This also defends against ACK Splitting, where multiple ACKs are
received for parts of the same segment/packet).
There are other scenarios where a change to the TCP ACK policy would
have improved performance. However, the design of TCP, and
ossification of the protocol has made it hard for new mechanisms to
be deployed. QUIC does not suffer from these design constraints.
Appendix B. Experiments Exploring an ACK Ratio of 1:10
The performance of QUIC is at a disadvantage compared to other
transport protocols if designs use a conservative ACK Ratio, because
QUIC can not modified by in-network middleboxes (such as used for TCP
ACK Thinning). We argue that a default ratio of 1:2 is too
conservative.
We used an experimental approach to examine a change to QUIC's ACK
Policy <http://erg.abdn.ac.uk/~downloads/ackscaling.pdf>. This
updated the default ACK Ratio from 1:2 to 1:10. Our tests show that
this did not negatively impact the protocol. This reduced the amount
of IP, UDP and ACK overhead by a factor of approximately 5. The
implemented congestion control, was also not negatively impacted.
These experiments were performed in January 2020 based on available
implementations at that time.
Unlike TCP, QUIC sends other types of data frames in addition to ACK
frames, increasing the total overhead on the return path. On
asymmetrical paths an ACK Ratio of 1:10 may still reduce the ACK
traffic, helping to avoid return path capacity limits impacting the
ability to use the forward path capacity.
Figure 1 presents a table with a set of asymmetric scenarios. The
columns present the rate of ACK traffic required (in kbps) to fill
each of the forward paths. The table shows the results for TCP
(without a PEP), both for lossless communication. It considers the
period after loss, when ACKs communicate the loss information. It
also shows the impact of using an ACK Ratio of 1:10 with QUIC.
An ACK Ratio of 1:10 reduces the utilisation of the return path.
Scenarios where the ACK traffic exceeds the return link capacity
(i.e. where this limits the forward path capacity that can be used)
are marked with a star. Note that the QUIC figure does not include
Fairhurst, et al. Expires September 6, 2020 [Page 10]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
the encryption overhead, which would be dependent on the ciphers
chosen. This would add several additional bytes for every QUIC
packet.
+-------------------+-------------+---------------+-----------------+
| | 10/2 Mbps | 50/10 Mbps | 250/3 Mbps |
+-------------------+-------------+---------------+-----------------+
| TCP no loss | 133 - 346 | 650 -1,730 | 3250 - 8,650* |
| TCP loss | 346 - 560 | 1,730 - 2,800 | 8,650 - 14,000* |
| QUIC 1:2 no loss | 144 - 438 | 720 - 2,190 | 3,600 - 10,950* |
| QUIC 1:2 loss | 290 - * | 1450 - * | 7,250 - * |
| QUIC 1:10 no loss | 28.8 - 87.6 | 144 - 438 | 720 - 2,190 |
+-------------------+-------------+---------------+-----------------+
Figure 1: ACK traffic required to fill the forward path in different
loss and asymmetry scenarios. The QUIC figures do not include
encryption overhead.
Figure 2 presents a table with the numbers of packets sent by two
QUIC implementations using a 1:2 and a 1:10 ACK Ratio. This shows
between a four and five time reduction in the number of packets sent.
+-------------------------------+----------------+----------------+
| | Chromium | Quicly |
| | Draft 23 | Draft 23 |
+-------------------------------+----------------+----------------+
| Packets sent | 77,419 | 83,238 |
| Packets on return path (1:2) | 39,089 (50.4%) | 41,108 (49.3%) |
| Packets on return path (1:10) | 10,409 (13.4%) | 9650 (11.5%) |
+-------------------------------+----------------+----------------+
Figure 2: Number of packets sent and received during a 100MB QUIC
transfer using different ACK ratios, for two implementations
Figure 3 presents a table with the number of bytes sent by one of the
QUIC implementations using a 1:2 and a 1:10 ACK Ratio. This shows a
reduction in the number of bytes on the return path from 2.7 to 0.7%
of the total bytes sent. In these scenarios, this is sufficient to
take full advantage of the forward path capacity.
Fairhurst, et al. Expires September 6, 2020 [Page 11]
Internet-Draft Changing the Default QUIC ACK Policy March 2020
+---------------------------------+----------------+
| | Chromium |
| | Draft 23 |
+---------------------------------+----------------+
| Bytes sent | 110M |
| Bytes on return path (1:2 AR) | 3,056KB (2.7%) |
| Bytes on return path (1:10 AR) | 810KB (0.7%) |
+---------------------------------+----------------+
Figure 3: Number of bytes sent and received during a 100MB Chromium
QUIC transfer using different ACK ratios
The number of bytes and packets reduces as expected when using an ACK
Ratio of 1:10, without any increase in loss, on a high-latency path
with an asymmetry of 5:1. This offers a clear benefit for paths that
are capacity-constrained, as well as paths which would benefit from a
reduction in the ACK Rate.
Authors' Addresses
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Ana Custura
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
UK
Email: ana@erg.abdn.ac.uk
Tom Jones
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
UK
Email: tom@erg.abdn.ac.uk
Fairhurst, et al. Expires September 6, 2020 [Page 12]