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

[Kangjiao <[e-mail]>]

Hi Christian,

Question 1:
We have a udp-based simulation tool in github ( https://github.com/fillthepipe/ackemu ). You can also directly refer to Figure 9(b) in the paper [2] for the simulation results. An acknowledgement policy that sends less ACKs achieves higher thoughput. Also the policy proposed in draft-li-quic-optimizing-ack-in-wlan-00 approaches the transport upper bound with a minimized ACK frequency (802.11n).

Question 2:
Comparing to draft-iyengar-quic-delayed-ack-00, if the delay is set to a fraction of the RTT, we think the difference might be that:
For draft-iyengar-quic-delayed-ack-00, ACK frequency is computed as: MAX{bw/( packet_tolerance *max_packet_size), 1/ max_ack_delay}.
For draft-li-quic-optimizing-ack-in-wlan-00, ACK frequency is computed as: MIN{bw/(packet_tolerance *max_packet_size), beta/RTTmin} (beta indicates the number of ACKs per RTT, RTT/4 is recommended in our solution).
In practice, we have proved that using a MIN instead of a MAX can also achieve equally good performance.

Question 3:

In delayed ACK, traditional RTT calculation meets the challenge of biases for the sender can hardly generate per-packet RTT samples:

The algorithm in draft-huitema-quic-ts-00 is interesting. If my understanding is right, the OWD is computed all on sender side and the formulas include:

latest_OWD = t3 (largest acked packet arrival) – t1 (largest acked packet departure) - phase_shift.
phase_shift = t3 (largest acked packet arrival) – t1 (largest acked packet departure) - latest_rtt/2

For draft-li-quic-optimizing-ack-in-wlan-00, RTTmin is a factor used to update ACK intensity. In order to improve accuracy, we adopt OWD-based RTTmin estimation instead of reporting ACK delays for the largest acknowledged packet in ACK frame in QUIC protocol. The formulas include:

RTTmin_sample = t2 (ACK arrival) – t1 (packet with OWDmin departure) - delta_t (ACK Delay)   ---- on sender side
delta_t = t3 (packet with OWDmin arrival) – t4 (ACK departure)   --- on receiver side ( If the receiver can send t3 and t4 to the sender, delta_t can also be calculated on sender side.)

For more details, please refer to our paper and draft. Thanks

Sincerely,
Jiao
From: Christian Huitema [mailto:[e-mail]]
Sent: Tuesday, July 7, 2020 5:07 AM
To: Kangjiao <[e-mail]>; Martin Thomson <[e-mail]>
Cc: [e-mail]
Subject: Re: Hope a discussion for draft-li-quic-optimizing-ack-in-wlan-00


Hello Jiao,

Your draft is motivated by specific data about running high bandwidth applications over wireless local area network. It would be interesting to compare behavior of these applications using different acknowledgement policies, probably using simulations. Do you have definitions of the application and of the WLAN that we could enter in simulations?

The draft draft-iyengar-quic-delayed-ack-00 provides a way for senders to specify both the maximum delay between acknowledgements and the maximum number of packets between acknowledgement, with receivers sending acknowledgements when one of the conditions is true. Several servers set the delay to a fraction of the RTT, and the number of packets to a corresponding fraction of the number of packets per congestion window -- RTT/8 is often suggested. How is that different from setting the "ACK intensity" suggested in draft-li-quic-optimizing-ack-in-wlan-00?

The draft draft-li-quic-optimizing-ack-in-wlan-00 mentions using one way delay measurements. Is that a reference to draft-huitema-quic-ts-00 ?

-- Christian Huitema
On 7/6/2020 7:35 AM, Kangjiao wrote:

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]<mailto:[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

>