Subject: [quicwg/base-drafts] Resending ACK frames increases max_ack_delay unnecessarily (#1438)

From: janaiyengar <[email-masked]>
Date: Mon, 11 Jun 2018 15:51:08 -0700

Subodh notes that when a receiver simply resends old ACK frames, the ack_delay field keeps on increasing, which unnecessarily inflates max_ack_delay. From email thread:

<quote>
My concern is this situation: a "receiver" had not seen the original ACK (the packet was lost), then the sender rtos and sends a large ack delay to compensate for the rto, the max filter for max ack delay would inflate the delay for future packet. 

if latest_rtt - min_rtt  > ack_delay:

   max_ack_delay = max(max_ack_delay, ack_delay)

latest_rtt in this case would be rto_timer + rtt because the sender sends an ack after an rto. 
</quote>

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

---

From: Christian Huitema <[email-masked]>
Date: Mon, 11 Jun 2018 16:35:44 -0700

Pick your poison. If you don't increase the ACK delay, you will overestimate the RTT sample. I think the increased ACK delay is a better reflection of reality.

-- 
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/1438#issuecomment-396419329

---

From: ianswett <[email-masked]>
Date: Mon, 11 Jun 2018 17:30:27 -0700

I agree with Christian that this seems like it's working as intended, but it's another reason I'm a bit concerned about not having explicit max ack delay in transport params.

-- 
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/1438#issuecomment-396428122

---

From: Baptiste Jonglez <[email-masked]>
Date: Thu, 28 Jun 2018 09:00:37 -0700

Resending old ACKs seems like a valid use-case.  We have ongoing work that estimates the one-way-delay on a path (within the current Multipath QUIC setting).  It relies on bundling a copy of the latest ACK for each path in the same return packet.  So, some of these ACKs may potentially be quite old.

With the current draft, this will cause `max_ack_delay` to increase a lot at the sender, making the RTO value too large to be useful.

I get the impression that `max_ack_delay` is there to compensate delayed ACKs at the sender.  We can expect the sender to have a bound on how long it delays ACKs (e.g. TCP on Linux has a max ACK delay of 200 ms), so why not explicitly communicate this bound from sender to receiver?

-- 
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/1438#issuecomment-401085671

---

From: ianswett <[email-masked]>
Date: Thu, 28 Jun 2018 10:02:03 -0700

You only increase max_ack_delay if there's a newly acknowledged largest acked packet.  So sending old acks by itself doesn't increase max_ack_delay.

Explicit communication is a way to bound this, and in theory it seems unnecessary, but I suspect adding it could mitigate some very weird edge cases.

-- 
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/1438#issuecomment-401104787