Re: [quicwg/base-drafts] Reduce restrictions on valid RTT samples (#2568)

[Jana Iyengar <[e-mail]>]

I've been doing more thinking, and here's where I've landed. (Thanks @kazuho and @ianswett for conversations.)

The higher order principle is this: max_ack_delay suggests a contract between this endpoint and its peer. The peer is supposed to send ACKs for ack-eliciting frames within max_ack_delay amount of time. Effectively, the peer _wants_ to wait for no more than max_ack_delay amount of time, but if the actual received ack_delay is larger (due to ack loss or scheduler latency), the RTT should be increased to compensate for this additional delay beyond max_ack_delay, because it's not within the peer's control and we might consider it part of "path" delay.

With this principle in place, I think it still makes sense to make the first change I proposed: that an ACK should be used for RTT measurement if any packet it newly acks is ack-eliciting. The RTT measurement is still on the largest_acked (since ack-delay is reported for the largest_acked).

It is difficult to reason about ACKs that only ack non-ack-eliciting packets, since the max_ack_delay contract does not hold. It is specifically difficult to reason about the reported ack_delays, since the peer can wait arbitrarily long and report arbitrarily long ack_delays. It's incorrect to add any additional delays (beyond max_ack_delay) into the RTT since the increased delay was not due to uncontrollable circumstances. Simply using the ack_delay, however large it may be, allows for the peer to simply game the RTT.  Using only the samples that have ack_delay < max_ack_delay might introduce a bias. It gets complicated quickly.

So, I conclude that we should not use ACKs of non-ack-eliciting packets for RTT measurement. This is what we do right now, so that's good. I'll add some text explaining why.

We should also recommend that an endpoint that is only sending non-ack-eliciting packets should piggyback a PING frame along with an ACK roughly once an RTT so that its RTT estimate is reasonably current.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2568#issuecomment-479629846