Dear Christian, Q1: 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. A1: Thank you for sharing the story behind the timestamp approach. The mechanism proposed in draft-li-quic-minimum-rtt-estimation also does not require the calculation of the absolute OWD value, nor does it rely on clock synchronization between endpoints. Much like the "ack delay" method in RFC 9000, draft-li-quic-minimum-rtt-estimation uses the relative comparison of OWDs computed at the receiver. Specifically, the receiver continuously calculates the OWD for each packet using the departure timestamp (from the TIMESTAMP frame) and its own arrival time. Since all calculations use the same local clock, the relative ordering of OWDs is accurate. The receiver only needs to identify which packet achieved the minimum OWD and then report that specific packet's timestamps (i.e., ack delay and packet number) back to the sender in the MINOWD-ACK frame. The sender then uses this timestamp, just as it would in the standard QUIC RTT calculation, to compute an RTT sample. Therefore, draft-li-quic-minimum-rtt-estimation shares the same advantage you highlighted: it does not require synchronized clocks. Q2: 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. A2: We would be very interested in exploring this synergy further with the people working on draft-ietf-quic-receive-ts. Q3: 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? A3: Thank you for your question. Here are some scenarios where an accurate minRTT might be essential (see section 3 in draft-li-quic-minimum-rtt-estimation): (1) Congestion Control: As you suspected, several congestion controllers, most notably BBR and its variants, fundamentally depend on an accurate minRTT to estimate the bandwidth-delay product (BDP) and size their congestion window effectively. (2) Loss Detection Validation: QUIC loss detection (RFC 9002) uses minRTT to reject implausibly small RTT samples, which helps maintain the robustness of the loss detection algorithm. (3) ACK Frequency Optimization: In mechanisms like the one described in "TACK: Improving Wireless Transport Performance by Taming Acknowledgments," the minRTT is used to dynamically adapt the ACK frequency to the network connection's bandwidth-delay product, improving scalability and efficiency. Best regards, Tong Li
---- Replied Message ---- From Christian Huitema<[email protected]> Date 11/17/2025 15:06 To tong.li<[email protected]> Cc Marten Seemann<[email protected]> , [email protected]<[email protected]> Subject Re: Fw: New Version Notification for draft-li-quic-minimum-rtt-estimation-00.txt 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
