Subject: [quicwg/base-drafts] Update ACK generation policy (#3501)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 05 Mar 2020 02:52:53 -0800

This will update the default recommendation to ACK at least every 10th eliciting packet. This reduces ACK traffic. It also improves QUIC performance on asymmetric paths.

Related issue #3304.

QUIC ACKs are significantly larger in size than TCP ACKS (e.g. 1.5-2 times), which means additional processing overhead and link usage for all Internet paths, with a significant impact on asymmetric links, where this can also limit throughput.

Additional methods, such as the one described in https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack/, can be
used to modify the ACK Ratio in use-cases where further tuning is required, such as high-speed networks, or when a different congestion controller is used. Using an appropriate value for max_ack_delay, or ensuring a minimum number of ACKs per RTT (e.g 8) would mitigate the effect of ACK loss on RTT estimation and aids performance for low-rate interactive applications.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3501

-- Commit Summary --

  * Update ACK generation policy

-- File Changes --

    M draft-ietf-quic-transport.md (16)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3501.patch
https://github.com/quicwg/base-drafts/pull/3501.diff

-- 
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/pull/3501

---

From: ianswett <[email-masked]>
Date: Tue, 10 Mar 2020 15:27:23 -0700

This is design, but I would prefer a slightly different direction, so I'll write a PR for that.

-- 
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/pull/3501#issuecomment-597351287

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Mar 2020 15:39:13 -0700

This speaks to a design issue, so we should start by first filing an issue. Specifically,  since we did a consensus call on #3304 and closed it, I'd like to know if there is any information beyond what we agreed to do there that warrants further discussion.

-- 
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/pull/3501#issuecomment-597354857

---

From: MikkelFJ <[email-masked]>
Date: Wed, 11 Mar 2020 17:23:44 +0000 (UTC)

mikkelfj commented on this pull request.

-An ACK frame SHOULD be generated for at least every second ack-eliciting packet.
-This recommendation is in keeping with standard practice for TCP {{?RFC5681}}.
+A QUIC receiver can generate one ACK frame for every received
+ack-eliciting packet.  TCP recommends
+that a receiver generates an ACK corresponding to every second MSS of
+received data, Section 4.2 of {{?RFC5681}}, however {{?RFC3449}} also
+notes the need for, and deployment of, methods to further
+reduce the number of TCP ACKs in networks with asymmetric paths.

I find this TCP discussion a bit confusing when trying to state a clear algorithm recommendation for QUIC. Can it be moved to a "compared to TCP" section?

-- 
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/pull/3501#pullrequestreview-372970067

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 17 Mar 2020 15:28:53 -0700

There seems to be some difference of opinion on the suggested text, which speaks to different opinion on the topic at hand. Can we please get an issue to discuss?

-- 
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/pull/3501#issuecomment-600330801

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 18 Mar 2020 00:37:21 -0700

I will frame an issue around draft-fairhurst-quic-ack-scaling - about a 
request to change the Default QUIC ACK Policy.

We do have data, and some experience working with Chromium and Quicly 
that we can share if there is interest.

Gorry

On 17/03/2020 22:28, Lucas Pardue wrote:
>
> There seems to be some difference of opinion on the suggested text, 
> which speaks to different opinion on the topic at hand. Can we please 
> get an issue to discuss?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/quicwg/base-drafts/pull/3501#issuecomment-600330801>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLEQGKTQQQ4MNYHO7KLDRH72RZANCNFSM4LCHDKLA>.
>

-- 
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/pull/3501#issuecomment-600469114

---

From: ianswett <[email-masked]>
Date: Sun, 22 Mar 2020 09:17:49 -0700

ianswett commented on this pull request.

I don't want to land this for reasons posted in the issue.

> @@ -3170,11 +3170,21 @@ delayed retransmissions from the peer. For Initial and Handshake packets,
 a max_ack_delay of 0 is used. The sender uses the receiver's `max_ack_delay`
 value in determining timeouts for timer-based retransmission, as detailed in
 Section 5.2.1 of {{QUIC-RECOVERY}}.
+The max_ack_delay needs to be set so that at least several samples can

When max_ack_delay is first sent, the path RTT is not known.

-In order to assist loss detection at the sender, an endpoint SHOULD send an ACK
+An ACK frame SHOULD be generated for at least every tenth ack-eliciting

There's no mention here of ACKing more frequently for N initial packets to avoid reducing the increase in slow-start.

-- 
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/pull/3501#pullrequestreview-379020995

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 22 Mar 2020 12:25:43 -0700

gorryfair commented on this pull request.

Does that matter for there first RTT?  The sender still receives an ACK after IW packets (assuming IW packets are sent)? If it matters, let's figure out how to solve that.

If the RTT turns out to be smaller than max_ack_delay*n (n updates/sec), then you can reduce max_ack_delay. I think this replicates  the ACK policy in Chromium? - but would be happy to see a different formulation that generates sufficient ACKs.

-- 
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/pull/3501#discussion_r396131247

---

From: ianswett <[email-masked]>
Date: Sun, 22 Mar 2020 12:27:51 -0700

max_ack_delay is unilateral, chosen prior to an RTT sample, and never changed over the course of the connection(unless one implements the ack-frequency extension, of course).

-- 
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/pull/3501#discussion_r396131448

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 22 Mar 2020 12:48:21 -0700

Bah, OK. Not sure why its designed that way - but let's live with that. A different way, is for a receiver with an RTT sample to use that to achieve the same outcome at the 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/pull/3501#discussion_r396133450

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 22 Mar 2020 12:53:14 -0700

Sure you could add that rule also. When do you think this helps... for RTT << 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/pull/3501#discussion_r396133944

---

From: ianswett <[email-masked]>
Date: Sun, 22 Mar 2020 12:53:22 -0700

max_ack_delay is used in the PTO timeout, and there's no guarantee the two peers have a similar view of RTT(in fact, it's pretty much guaranteed they're not quite identical), so an explicit signal is necessary.

-- 
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/pull/3501#discussion_r396133956