Subject: [quicwg/base-drafts] Only send one immediate ACK after reordering (#3357)

From: ianswett <[email-masked]>
Date: Fri, 17 Jan 2020 11:09:57 -0800

Currently the transport draft says:

> "In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet that is out of order. The endpoint MAY continue sending ACK frames immediately on each subsequently received packet, but the endpoint SHOULD return to acknowledging every other packet within a period of 1/8 x RTT, unless more ack-eliciting packets are received out of order. If every subsequent ack-eliciting packet arrives out of order, then an ACK frame SHOULD be sent immediately for every received ack-eliciting packet."

However, since this text was written, recovery was changed to require packet AND time threshold loss detection, so the only time sending multiple immediate ACKs for a single missing packet would be beneficial is if the first ACK is lost.

Also, only sending 1 immediate ACK is a lot easier to implement and reason about in my opinion than "up to 1/8 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/3357

---

From: ianswett <[email-masked]>
Date: Fri, 17 Jan 2020 13:25:27 -0800

@LPardue @larseggert @mnot Can you please mark this as design since the PR will change normative text.

-- 
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/3357#issuecomment-575800669

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 29 Jan 2020 08:54:49 -0800

I think it could have other effects - it will impact the robustness to loss/congestion on the return path compared to the way TCP operates. Sending one isolated ACK here isn't the same, although you could argue that the ACK information is indeed repeated "ACK Delay" or "N packets" later. If we relax the number of packets per ACK this may need a little more thought to avoid delaying congestion detection when there is loss?

-- 
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/3357#issuecomment-579853801

---

From: ianswett <[email-masked]>
Date: Fri, 31 Jan 2020 08:24:03 -0800

Currently in the drafts, N is 2, so there are very few cases where sending more ACKs would be beneficial.

The worst case I can construct is If the first ACK is lost, then the loss detection could be delayed by the max_ack_delay IF exactly one more packet was received.  That seems quite acceptable and loss of ack-only packets is rare in my experience.

Drafts like the ack-frequency extension do change the dynamics some, but they also increase the relative cost of sending immediate ACKs more than once.  For example, instead of sending an ACK-only packet every 10 or 20 packets, a receiver could switch to sending an ACK for every packet, which could massively slow down the connection and increase load on the network.

I'm going to run a production experiment with this change as well to confirm that it performs as well or better, but that may take a few months.

-- 
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/3357#issuecomment-580803023