Subject: [quicwg/base-drafts] Ack delay in SRTT computation (#961)

From: janaiyengar <[email-masked]>
Date: Tue, 28 Nov 2017 09:08:50 +0000 (UTC)

The recovery draft (and GQUIC) use ack delay in SRTT computations, but with the caveat that "the ack delay field from the ACK frame SHOULD be subtracted from the RTT as long as the result is positive." 

The ack delay may be too large if the peer's clock was adjusted, but it can also happen if the peer uses a very granular clock, which can lead to arbitrarily large ack delays.

There are a few ways to deal with this, including:
1. current text, which simply drops the problematic ack delays,
2. ignore ack delays from a peer that screws up once (ack delay > measured RTT),
3. ignore RTT sample that contains problematic ack delay.

(1) is a bit aggressive. (2) is conservative: If ack delay is screwed up then you won't always be able to detect it, but once can be treated as a signal to not trust this peer's ack delays. (3) has been proposed but I'm not sure it addresses the right thing -- the RTT sample isn't bad, the ack delay is.

I'm leaning towards (2).

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

---

From: ianswett <[email-masked]>
Date: Tue, 28 Nov 2017 13:34:29 +0000 (UTC)

If your first theory is correct, this is due to clock jump, then 2 seems like the wrong approach, since it means one bad ack delay is likely to be isolated.

4. An improvement to #1 might be to ignore the ack delay any time the resulting RTT is less than min_rtt.  We'd have to define min_rtt, which we currently don't, but that puts a tighter bound on reasonable use of ack delay than just 'must result in a positive RTT signal'.  This makes it much harder to intentionally use the ack delay to manipulate the peer's SRTT, which seems nice.

So I lean towards 4 and I think my least favorite is 4, the more I think about it, because I fear going a long time without an RTT sample, and the goal should be to never be worse than TCP's RTT signaling.

-- 
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/961#issuecomment-347524701

---

From: ianswett <[email-masked]>
Date: Tue, 28 Nov 2017 14:15:55 +0000 (UTC)

One more improvement could be to limit the ack delay to the max_ack_delay, once it's communicated via transport params.  #912 

-- 
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/961#issuecomment-347536072

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 00:23:03 +0000 (UTC)

I actually like the fourth option here.  min_rtt is a value worth tracking, and it could still be calculated based on actual flight times (i.e., the value before subtracting the ack delay).  Then you only train min_rtt on a value that is harder to fake.  It only leaves you open to the peer sending opportunistic acks, essentially, which is pretty risky for an implementation that does that.  Then your RTT calculations can't drive RTT below that floor.  You still have to guard against negative values, which might still happen, but that guard might be coincident with the min_rtt guard.

Why we insist on using wall clocks for this sort of thing is beyond me, but that's the state of the world today.

-- 
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/961#issuecomment-347710212

---

From: Marten Seemann <[email-masked]>
Date: Wed, 29 Nov 2017 17:49:52 -0800

Why is min_rtt the value based on actual flight times (before subtracting the ack delay)? Subtracting the ack delay will decrease this value, so the real rtt will be larger than min_rtt.

We should consider the attack where a peer sends ack delays such that the rtt will end up very close to 0. That way, the other side would increase the congestion window, and also allocate more receive buffer space (assuming it does flow-control tuning). One variant of this attack could also be sending ack delay times that are *always* bigger than the actual RTT, so that the other side doesn't have any useful RTT measurement at all.

-- 
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/961#issuecomment-348056917

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Nov 2017 02:59:59 +0000 (UTC)

The idea here (I think) is to remove the exposure to the ack delay being inflated (either by malice or by accident) when calculating min_rtt.  You can still measure RTT based on packet arrival times if you assume that the peer can't opportunistically send ACKs.

The observed RTT would then have a lower bound.  That lower bound might be higher than the actual minimum RTT, but it will be less exposed to manipulation through tweaking the ack delay field.

-- 
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/961#issuecomment-348068143

---

From: ianswett <[email-masked]>
Date: Thu, 30 Nov 2017 08:58:55 -0800

Because min_rtt never increases, and at least some of your RTT samples are likely to have essentially 0 ack delay, it's much safer to not consider ack delay.

And as you mention Marten, it'd be pretty easy to set the peer's min_rtt to 0 otherwise.

In practice, GQUIC used to allow ack delay to be included in min_rtt, and every once in a while this resulted in an RTT very close to 0 and some weird issues for the bits of code that actually the min_rtt.  Not allowing ack delay to be considered has been much safer and seems to result in much more realistic min_rtt values, based on looking at traces.

Take a look at #975 for a writeup of this.

-- 
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/961#issuecomment-348252008

---

From: janaiyengar <[email-masked]>
Date: Thu, 30 Nov 2017 21:01:13 +0000 (UTC)

Closed #961 via #975.

-- 
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/961#event-1366508380