Dear Christian: In the updated version of our draft draft-li-quic-minimum-rtt-estimation-01 (https://datatracker.ietf.org/doc/html/draft-li-quic-minimum-rtt-estimation), I have already added an acknowledgement and a reference to the timestamp draft (draft-huitema-quic-ts) in Section 5.2. I also realize that our current draft as providing a motivation and a specific application for timestamp mechanisms like the one you proposed, potentially renewing interest in this area by demonstrating a use-case for improving minRTT estimation I also greatly appreciate your suggestion to contribute to the ongoing WG effort, draft-ietf-quic-receive-ts. If I understand correctly, my approach addresses a slightly different aspect of the problem. While draft-ietf-quic-receive-ts enables reporting multiple receive timestamps, it does not guarantee that the timestamp of the packet with the minimum One-Way Delay (minOWD) is included in the feedback. As we discuss in our draft (Section 3), missing this specific sample can still lead to a biased minRTT estimate, especially under high throughput (I have some preliminary data in a prior paper "TACK: Improving Wireless Transport Performance by Taming Acknowledgments" (Li et al.), indeed we need more evaluations to show how the biases change under different networks). draft-li-quic-minimum-rtt-estimation-01 now proposes MINOWD-ACK frame (thanks to the help from Marco Munizaga), which is specifically designed to ensure this critical sample is reported. Our work can complement draft-ietf-quic-receive-ts by highlighting a key scenario (precise minRTT estimation under low ACK frequency) and offering a specialized solution. We would be very interested in contributing to the WG discussion and exploring how these ideas could be integrated or how our findings could help improve the ongoing work. Thank you again for your guidance. Best regards, Tong Li
---- Replied Message ---- From Christian Huitema<[email protected]> Date 11/15/2025 02:29 To Marten Seemann<[email protected]>, tong.li<[email protected]> Cc [email protected]<[email protected]> Subject Re: Fw: New Version Notification for draft-li-quic-minimum-rtt-estimation-00.txt As other have observed, the definition of timestamps in this draft is identical to the definition in the expired timestamp draft https://datatracker.ietf.org/doc/draft-huitema-quic-ts/. That timestamp draft expired because of lack of interest, but another effort is addressing the problem in "QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps", https://datatracker.ietf.org/doc/draft-ietf-quic-receive-ts/. At a minimum, draft-li-quic-minimum-rtt-estimation <https://www.ietf.org/archive/id/draft-li-quic-minimum-rtt-estimation-00.txt> should be updated and acknowledge the prior art. But it seems that this timestamp draft addresses exactly the same problem as draft-ietf-quic-receive-ts, which has been adopted by the WG. rather than developing a parallel draft, it might be better to contribute to the ongoing effort. If you think that the working group draft has issue, you may want to discuss that and propose improvements! -- Christian Huitema On 11/13/2025 8:14 PM, Marten Seemann wrote: 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 <http://tong.li> <tong.li <http://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]> <mailto:[email protected]> Date 11/8/2025 22:11 To Bo Wu<[email protected]>, <mailto:[email protected]>Ke Xu<[email protected]>, <mailto:[email protected]>Tong Li<[email protected]>, <mailto:[email protected]>Youjian Zhao<[email protected]> <mailto:[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
