Dear Marten, Thank you for your review and questions regarding our draft "draft-li-quic-minimum-rtt-estimation-00". Your feedback is highly appreciated. Below are my responses: Q1: According to RFC 9002, min_rtt is the minimum RTT observed on a path. While reducing the ACK frequency means that you'll get fewer RTT measurements over a given time frame, this seems probably the least relevant for min_rtt (as it's just the minimum of all measurements), and more relevant for smoothed_rtt (as it averages over the last couple of measurements). Even with the ACK frequency extension (and reasonable tuning of the parameters), you'll still get a couple of ACKs per RTT, so you'd still pick up on changes to min_rtt fairly quickly. In which situations is it relevant to pick up on min_rtt changes fractions of an RTT earlier? A1: We agree that smoothed RTT is more sensitive to the frequency of RTT samples, as it relies on averaging recent measurements. In contrast, minRTT is defined as the minimum of all observed RTT samples over a period. However, the key issue is not merely the number of samples, but the representativeness of the samples obtained under low ACK frequency. When the receiver sends only a few ACKs per RTT, the sender can only generate RTT samples for the specific packets that happen to be acknowledged. There is no guarantee that these samples include the packet with the actual minimum RTT on the path. As a result, the sender's minRTT estimate can become significantly biased—specifically, overestimated—because the sampling process may systematically miss the lowest-RTT packets. As reported in the SIGCOMM 2020 paper "TACK: Improving Wireless Transport Performance by Taming Acknowledgments" (Li et al.), conventional RTT sampling under reduced ACK frequency leads to minRTT overestimates of 8%–18%. Moreover, the bias tends to increase with throughput, as more packets are delivered between ACKs, further reducing the probability of capturing the true minimum RTT. Q2: Regarding the proposed mechanism, it is unclear to me how measuring one-way delays would help in generating a better min_rtt estimate. A receiver already generates an immediate ACK for a packet that raced ahead (beyond the reordering threshold), thereby enabling the sender to accurately measure min_rtt. It is true that this doesn't capture RTT samples that could've been generated from reordered packets below the reordering threshold, but I'd like to see some data that this is a problem in practice, and if it is, why it can't be solved by lowering the reordering threshold. A2: You raise an excellent question about why measuring one-way delays helps generate better minRTT estimates. The key insight is that the minimum one-way delay (minOWD) directly corresponds to the minimum RTT (minRTT) in symmetric paths, and provides a robust lower bound even in asymmetric scenarios. Unlike conventional RTT sampling, which randomly acknowledges packets and may miss the true minimum, our OWD-based approach ensures the sender receives RTT samples specifically for packets that reflect the minimal path delay. This method is independent of reordering thresholds. We welcome further discussion and suggestions to help guide our future work. Best regards, Tong Li
---- Replied Message ---- From Marten Seemann<[email protected]> Date 11/14/2025 12:14 To tong.li<[email protected]> Cc [email protected]<[email protected]> Subject Re: Fw: New Version Notification for draft-li-quic-minimum-rtt-estimation-00.txt I read the draft, and I neither understand the problem it's trying to solve, nor do I understand the way that it solves it. According to RFC 9002, min_rtt is the minimum RTT observed on a path. While reducing the ACK frequency means that you'll get fewer RTT measurements over a given time frame, this seems probably the least relevant for min_rtt (as it's just the minimum of all measurements), and more relevant for smoothed_rtt (as it averages over the last couple of measurements). Even with the ACK frequency extension (and reasonable tuning of the parameters), you'll still get a couple of ACKs per RTT, so you'd still pick up on changes to min_rtt fairly quickly. In which situations is it relevant to pick up on min_rtt changes fractions of an RTT earlier? Regarding the proposed mechanism, it is unclear to me how measuring one-way delays would help in generating a better min_rtt estimate. A receiver already generates an immediate ACK for a packet that raced ahead (beyond the reordering threshold), thereby enabling the sender to accurately measure min_rtt. It is true that this doesn't capture RTT samples that could've been generated from reordered packets below the reordering threshold, but I'd like to see some data that this is a problem in practice, and if it is, why it can't be solved by lowering the reordering threshold. On Fri, 14 Nov 2025 at 10:32, tong.li <[email protected]> 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
