Subject: Re: [quicwg/base-drafts] compensation of ack_delay is fragile against errors (#2060)

From: janaiyengar <[email-masked]>
Date: Tue, 04 Dec 2018 19:07:01 -0800

@dtikhonov : The clock jumped up. It was monotonic.

-- 
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/2060#issuecomment-444342325

---

From: janaiyengar <[email-masked]>
Date: Tue, 04 Dec 2018 19:43:41 -0800

@ianswett: Responding to your comment ([here](https://github.com/quicwg/base-drafts/issues/2060#issuecomment-443213389)) and PR #2062. For (1), yes, that is true, but we have already put a stake in the ground: min_rtt is only driven by what a sender measures and not by reported ack_delay. Under that framework, no SRTT that is smaller than measured min_rtt will be valid. That is a consequence we know and hopefully we should be measuring true min_rtt often enough that this isn't a problem.

Basically, my core argument is this: SRTT is used for loss detection and potentially congestion control and pacing. 
- A too-small SRTT is more aggressive: it causes too-early loss detection and might cause a congestion controller that uses RTT samples to get a one-off min_rtt sample. It might also cause a pacer to go a bit too fast.
- A too-large SRTT is more conservative.

Given that this is a mis-reporting receiver, a natural consequence of mis-reporting should be poor performance, not more aggressive sending.

I still think the sender should ignore a computed latest_rtt sample which seems to be smaller than min_rtt.

-- 
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/2060#issuecomment-444348125

---

From: ianswett <[email-masked]>
Date: Wed, 05 Dec 2018 07:47:55 -0800

There are certainly cases where this does not require a mis-reporting receiver(ie: what I described above), but I think your argument is that you don't care about them?  If so, this does make it somewhat critical to send a reasonable number of non-delayed ACKs to ensure min_rtt is discovered relatively quickly.

I completely agree that I don't want to change the definition of min_rtt, FWIW.

-- 
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/2060#issuecomment-444533140

---

From: janaiyengar <[email-masked]>
Date: Thu, 06 Dec 2018 17:03:56 -0800

@ianswett : Sorry, I was referring to a mis-reporting receiver in the case that the min_rtt is known.

In the case you mention, yes, that is a potential condition where a sender might have poor performance too, but I imagine this is not something we would expect to happen for very long, especially given all the handshake packets should be acked immediately.  Using a 1ms timer means for immediate means that's just a part of the min_rtt... nothing a sender can do about that. 

Basically, I don't think optimistically compensating at the sender for receiver delays is the way to go.  If the RTT sample seems broken, I would argue it should be ignored.

-- 
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/2060#issuecomment-445086245

---

From: ianswett <[email-masked]>
Date: Thu, 06 Dec 2018 19:02:48 -0800

As commented on the PR, I'm increasingly thinking we should limit by max_ack_delay and then if it still seems invalid, ignore ack_delay, as in the current text, but not ignore the entire sample, since even without the ack_delay adjustment, we expect the RTT sample to be somewhat useful.

-- 
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/2060#issuecomment-445107128

---

From: janaiyengar <[email-masked]>
Date: Thu, 06 Dec 2018 19:23:50 -0800

Limiting to max_ack_delay sounds fine to me as I've said earlier.

If the RTT sample is used without ack_delay (current spec text) instead of ignoring, this causes the SRTT to increase which is safe. I'm fine with it.

@kazuho?

-- 
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/2060#issuecomment-445110491

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Dec 2018 19:39:17 -0800

Limiting to max_ack_delay sounds good to me, especially considering the fact that now we only sample ACK-eliciting packets.

-- 
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/2060#issuecomment-445112767

---

From: ianswett <[email-masked]>
Date: Fri, 07 Dec 2018 06:30:14 -0800

SGTM, closing the PR and this issue then.  We can always revisit it if we have some new data that indicates the current text is a problem.

-- 
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/2060#issuecomment-445249383

---

From: ianswett <[email-masked]>
Date: Fri, 07 Dec 2018 06:30:14 -0800

Closed #2060.

-- 
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/2060#event-2012569694