Dear Marco, Thank you for your feedback and suggestions regarding the draft “draft-li-quic-minimum-rtt-estimation-00”. I have revised the draft accordingly and submitted an updated version as “draft-li-quic-minimum-rtt-estimation-01” (available at: https://datatracker.ietf.org/doc/html/draft-li-quic-minimum-rtt-estimation). Below are my responses. Q1: This requires redefining the ack delay field depending on the negotiated transport, which seems tricky at best. Why not simply send an ack immediately when the receiver observes a new one way delay minimum? You can limit this to at most once an RTT which should be a negligible cost.
A1: Initially, we aimed to minimize modifications to the existing QUIC protocol, which led to the approach described in the initial draft. However, based on your feedback, we agree that triggering an ACK when a new one-way delay minimum is observed is a promising direction. We have revised the mechanism to send MINOWD-ACK frames periodically—rather than immediately—as the receiver continuously monitors the minimum one-way delay (minOWD). This adjustment balances responsiveness with protocol overhead and is now reflected in Section 4.2 and 5.3 of the updated draft. Q2: Do you know of any research and data that shows how accurately something like your draft can lead to discovering the minRTT? And, relatedly, do you know of research and data showing how incorrect a minRTT estimate is with a reduced ack frequency of around ~4 acks per RTT? A2: Thank you for raising this point. In the SIGCOMM 2020 paper "TACK: Improving Wireless Transport Performance by Taming Acknowledgments" (Li et al.), experimental results (Figure 6) demonstrated that conventional RTT sampling leads to minRTT overestimates by 8%–18%. By employing more accurate minRTT estimation—via mechanisms such as TACK—the 95th percentile one-way delay was reduced by 20%, and packet loss by 54%, without throughput degradation. These results suggest that precise minRTT estimation helps avoid overloading the network path. That said, we acknowledge the need for further testing and data in diverse environments, and we welcome additional discussion on this topic. Q3: You may also find Christian Huitema's draft "Quic Timestamps For Measuring One-Way Delays" [0] helpful. A3: We sincerely appreciate your recommendation of Christian Huitema’s draft, "QUIC Timestamps for Measuring One-Way Delays." It is highly relevant to our work, and we have included a reference to it in Section 5.2 of the updated draft, where we acknowledge the reuse of the TIMESTAMP frame for minRTT estimation. Please feel free to share any further thoughts or suggestions. Best regards, Tong Li ---- Replied Message ---- From Marco Munizaga<[email protected]> Date 11/14/2025 12:09 To tong.li<[email protected]>, [email protected]<[email protected]> Subject Re: Fw: New Version Notification for draft-li-quic-minimum-rtt-estimation-00.txt Hi Tong Li, Thanks for sharing. I think this is an interesting idea. If I understand your draft correctly, this introduces a TIMESTAMP frame that the sender sends to allow the receiver to calculate a one way delay. When the receiver observes a new minimum, it will use the instigating packet's arrival time for the ack delay field in the next ack. This requires redefining the ack delay field depending on the negotiated transport, which seems tricky at best. Why not simply send an ack immediately when the receiver observes a new one way delay minimum? You can limit this to at most once an RTT which should be a negligible cost. Do you know of any research and data that shows how accurately something like your draft can lead to discovering the minRTT? And, relatedly, do you know of research and data showing how incorrect a minRTT estimate is with a reduced ack frequency of around ~4 acks per RTT? You may also find Christian Huitema's draft "Quic Timestamps For Measuring One-Way Delays" [0] helpful. -Marco [0]: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/ On Thu Nov 13, 2025 at 6:31 PM PST, tong.li wrote: Hi everyone, As we know, networks like WLAN, cellular, and satellite often perform better with fewer ACKs to reduce overhead. Inspired by drafts such as "draft-ietf-quic-ack-frequency" (Iyengar et al.), I've been working on a draft that improves min RTT estimation for QUIC when ACK frequency is low. I'm keen to hear your perspectives if this is an area of interest. -Tong Li Renmin University of China [email protected] Room 421, Information Building 100872 http://iir.ruc.edu.cn/~litong/index.html ---- Forwarded Message ---- From <[email protected]> Date 11/8/2025 22:11 To Bo Wu<[email protected]>, Ke Xu<[email protected]>, Tong Li<[email protected]>, Youjian Zhao<[email protected]> Subject New Version Notification for draft-li-quic-minimum-rtt-estimation-00.txt A new version of Internet-Draft draft-li-quic-minimum-rtt-estimation-00.txt has been successfully submitted by Tong Li and posted to the IETF repository. Name: draft-li-quic-minimum-rtt-estimation Revision: 00 Title: Minimum RTT Estimation Under Low ACK Frequency Date: 2025-11-08 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-li-quic-minimum-rtt-estimation-00.txt Status: https://datatracker.ietf.org/doc/draft-li-quic-minimum-rtt-estimation/ HTMLized: https://datatracker.ietf.org/doc/html/draft-li-quic-minimum-rtt-estimation Abstract: In traditional acknowledgment mechanisms, the sender frequently "pulls" ACK packets, resulting in significant protocol control overhead. This leads to wasted CPU and I/O resources, contention for packet spectrum on half-duplex links (e.g., WLAN), and reverse-path congestion in asymmetric links (e.g., satellite network). Reducing the number of ACKs is essential in scenarios where ACK overhead is non-negligible. However, a lower ACK frequency can introduce biases in delay estimation, such as overestimating the minimum round-trip time (minRTT). This document proposes how to calibrate the estimation of the minRTT under low ACK frequency conditions. The IETF Secretariat
