On 9/17/2024 8:18 AM, Mirja Kuehlewind wrote:
Also an ACK really gives you only one RTT sample for the largest PN (which was
either ACK-eliciting or gives you the ACK delay).
On 17.09.24, 16:37, "Martin Thomson" <[email protected]
<mailto:[email protected]>> wrote:
On Tue, Sep 17, 2024, at 09:49, Lars Eggert wrote:
maybe I'm missing something, but isn't the ACK delay encoded in an ACK
frame (only) the delay of the largest ACK'ed packet number? How would
you disambiguate between ack-eliciting and non-ack-eliciting packet
numbers when you parse an ACK?
The sender tracks whether the packet they sent was ack-eliciting.
I think that's the key. The sender behavior should vary depending
whether the packet with the highest acknowledged PN was ACK-eliciting or
not. If it was not, the ACK delay is pretty much unbounded. The RTT
sample will have a value anywhere between min RTT and "a long time". The
ACK does provide some information, e.g., checking continuity, but the
sample value should not be used to compute variables like smoothed RTT
or RTT variant. And it should certainly not be used as an indication of
congestion for delay-based congestion algorithms.
-- Christian Huitema
