RE: Hope a discussion for draft-li-quic-optimizing-ack-in-wlan-00

[Kangjiao <[e-mail]>]

Dear Martin,



Here are the two drafts:

draft-li-quic-optimizing-ack-in-wlan-00: https://tools.ietf.org/html/draft-li-quic-optimizing-ack-in-wlan-00

draft-iyengar-quic-delayed-ack-00: https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00



I have outlined some distinction and connection between these two drafts:



a)       Both draft-li-quic-optimizing-ack-in-wlan-00 and draft-iyengar-quic-delayed-ack-00 propose a solution to reduce the ACK frequency for QUIC. draft-iyengar-quic-delayed-ack-00 makes the two parameters in delayed ACK, i.e., "Packet Tolerance" and "Max Ack Delay", be tunable by the sender. These two tunable parameters do not include RTT as a factor. Sara Landstrom et al. [1] has demonstrated that, in theory, the endpoint should acknowledge data at least twice per send window (RTT) to ensure utilization. In this case, reducing ACK frequency without considering the RTT as a factor of Max Ack Delay, might cause performance issues. On the other hand, the purpose in draft-li-quic-optimizing-ack-in-wlan-00 is to minimize the ACK frequency required by the transport, thus the ACK frequency is computed as MIN{bw/(packet_tolerance *max_packet_size), beta/RTTmin} (beta indicates the number of ACKs per RTT). While draft-iyengar-quic-delayed-ack-00 adopts the extended delayed ACK as specified in the legacy TCP, whose ACK frequency is computed as MAX{bw/( packet_tolerance *max_packet_size), 1/ max_ack_delay}. A paper [2] (to be appeared in SIGCOMM2020) has demonstrated that using a MIN instead of a MAX can also achieve equally good performance.



b)       draft-iyengar-quic-delayed-ack-00 provides a way for the sender to customize the ACK frequency. This means the ACKs might be excessively delayed when the Max Ack Delay is large. When sending fewer ACK frames, many data packets might be received during the ACK interval, generating only one RTT sample among multiple packets is likely to result in biases. For example, a larger minimum RTT estimate. In draft-li-quic-optimizing-ack-in-wlan-00, we propose a one-way-delay-based method to compute the minimum RTT more accurately. Apart from the ACK scheme, this is another point that we would like to discuss and get feedback from QUIC WG.



c)       With some minor extensions such as adding one more field of ACK-INTENSITY, the proposed ACK scheme in draft-li-quic-optimizing-ack-in-wlan-00 may be able to reuse the ACK-FEQUENCY frame specified in draft-iyengar-quic-delayed-ack-00 to sync the ACK intensity between sender and receiver.



Some reference mentioned above:

[1] Sara Landstrom and Lars-Ake Larzon. 2007. Reducing the TCP acknowledgment frequency. ACM SIGCOMM CCR 37, 3 (2007), 5–16.

[2] Tong Li, Kai Zheng, Ke Xu, Rahul Arvind Jadhav, Tao Xiong, Keith Winstein, Kun Tan. "TACK: Improving Wireless Transport Performance by Taming Acknowledgments", ACM SIGCOMM, 2020. ( http://www.thucsnet.org/uploads/2/5/2/8/25289795/tong_sigcomm20.pdf )



Best Regards,

Jiao



-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
Sent: Monday, July 6, 2020 8:41 AM
To: [e-mail]
Subject: Re: Hope a discussion for draft-li-quic-optimizing-ack-in-wlan-00



Can you speak a little about the relationship with draft-iyengar-quic-delayed-ack ?



On Sat, Jul 4, 2020, at 16:05, Kangjiao wrote:

>

> Dear QUIC WG members,

>

>

> We uploaded a draft describing a mechanism for ACK optimization to

> QUIC group. The link is

> https://datatracker.ietf.org/doc/draft-li-quic-optimizing-ack-in-wlan/..

> This solution comes from our practice and the results show it is a

> good replacement of the traditional ACK mechanism to compensate for

> scenarios where the acknowledgement overhead is non-negligible (i.e.,

> wireless scenarios).

>

>

> The key points for this solution can be:

>

>

> 1. We conclude the formula of the minimum ACK intensity required for

> QUIC transport.

>

>

> 2. In order to alleviate the error in RTT estimation, we use protocol

> extensions and a one-way delay factor. We think this round-trip timing

> method can also be applicable for the ack thinning mechanisms (such as

> ”Changing the Default QUIC ACK Policy” #3529) that have been discussed

> in QUIC group..

>

>

> 3. For implementation and interoperability, we define a new

> ACK-INTENSITY Frame in which ACK Intensity is set. ACK Intensity is a

> variable-length integer indicating the updated intensity of QUIC ACK

> Frame calculated by our formula.

>

>

> We look forward to your valuable comments and suggestions. Thanks.

>

>

> Sincerely,

>

> Jiao

>