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

From: Jana Iyengar <[email-masked]>
Date: Sat, 30 Mar 2019 13:40:58 -0700

The RTT estimator currently does not use RTT samples if the largest_acked is not ack-eliciting. This can lead to the endpoint missing RTT samples unnecessarily, in two ways.

First, checking only for the largest_acked to be ack-eliciting means that we ignore other newly acked packets that were ack-eliciting. The peer is expected to send an ack within max_ack_delay if it has received any ack-eliciting packets, not just the largest acked one. This is probematic if the connection has a pattern that results in more non-ack-eliciting packets being the largest_acked. I propose that we change the condition for a valid RTT sample to be if _any_ newly acked is ack-eliciting (in addition to the ACK frame carrying a new largest_acked).

Second, non-ack-eliciting packets are a perfectly fine source of RTT samples, with the caveat that ack_delay might be larger than max_ack_delay; a receiver that has only received non-ack-eliciting packets might delay acknowledging these packets much longer than otherwise. I propose that we don't drop all RTT samples associated with non-ack-eliciting packets, but only those with unusable ack_delay. Basically, I propose that we use the RTT sample if ack_delay < max_ack_delay.

-- 
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

---

From: Nick Banks <[email-masked]>
Date: Sat, 30 Mar 2019 15:47:35 -0700

Why only accept the RTT measurement if ack_delay is less than (or equal I assume) max_ack_delay? So the peer held on to the packet a little longer than normal? What's the big deal? If they report to you exactly how long they held on to it, you should still get an accurate RTT measurement, right?

-- 
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-478296059

---

From: ianswett <[email-masked]>
Date: Sat, 30 Mar 2019 16:41:18 -0700

@janaiyengar you make some good points, but the sender needs to know which packet to use to create an RTT sample.  The obvious answer is the largest ack-eliciting packet number.  I can think of some cases involving ACK loss and/or reordering that would be slightly incorrect, but I can't think of any cases that would be disastrous.  However, it seems important that ack_delay is from the largest_acked ack-eliciting packet in that case, otherwise the RTT sample will be incorrect.  I'm not feeling great about the fact we're not explicitly specifying the largest ack eliciting packet an instead letting the sender figure it out, but besides that this seems ok.  I will note that we could also advise not including non-ack-eliciting packets as the largest acked and only ACK them when they're less than an ack-eliciting packet.   I wonder if that might be simpler, given this is somewhat of an edge case?

@nibanks The reason for limiting ack_delay to max_ack_delay is to incentivize correct reporting of max_ack_delay.  Otherwise, one could report a max_ack_delay of 0ms and consistently report a larger ack_delay value, allowing the receiver to decrease the sender's SRTT.  I'm not sure how large a problem this is in practice, but it's nice if the mechanisms incentivize accurate reporting.

The algorithms should devolve into something very similar to TCP if max_ack_delay is 0ms, so the worst case doesn't seem that bad.

-- 
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-478298803

---

From: Nick Banks <[email-masked]>
Date: Sat, 30 Mar 2019 16:52:14 -0700

It just seems like a bad idea to always ignore RTT measurements if ack_delay is larger than max_ack_delay. For instance, what about one of the following scenarios:

1. Sheer CPU load on the peer prevents it from ACK'ing a packet within max_ack_delay.
2. An implementation that literally sets a max_ack_delay timer on receipt of a packet, then when the timer fires, queues a send packet work item. When that work item is processed, the ack_delay is calculated and it ends up being just over max_ack_delay.

-- 
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-478299319