On 11/16/2025 10:22 PM, tong.li wrote:
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.
Thanks!
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
It is very hard to compute one way delays without synchronized
clocks. That's one of the reasons why the timestamp approach failed to
gain much traction.
You can of course use the series of timestamps to construct a
synchronization mechanism. You will have to use construct a model of how
clocks may drift, and then implement a most likelihood estimator to
transform the peer's timestamps into time values synchronized with the
local scope. Most implementers who have seen that concluded that they
would rather not.
The "ack delay" approach used in RFC 9000 and extended in
draft-ietf-quic-receive-ts has the big advantage of not requiring
synchronized clocks, because the delay is the difference between two
local clocks. It does require that the clocks be reasonably precise, but
since the measured delays are usually very short that is not a big issue
in practice. You end up with a pretty good estimate of the min RTT, even
if the clocks are not synchronized.
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.
Maybe you could suggest a strategy for receivers to properly chose for
which packets they report the timestamp? That would be a very useful
complement to draft-ietf-quic-receive-ts.
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.
It would be interesting to discuss the purpose of the minRTT estimation.
Most implementations do not really use delay estimations for loss
detection and recovery -- like RFC 9002 they use RACK, which does not
require precise timeout estimates. Do you want to use the min RTT for
congestion control?
-- Christian Huitema
