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
