Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

From: Lars Eggert <[email-masked]>
Date: Thu, 16 Apr 2020 08:59:04 -0700

This is a small enough change. However, there is still a bar for those, and the current level of discussion makes me believe we should close this with no action?

-- 
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/3529#issuecomment-614741080

---

From: Lars Eggert <[email-masked]>
Date: Wed, 22 Apr 2020 04:30:33 -0700

Just so that it's easy to find, there is data and a continued discussion at https://mailarchive.ietf.org/arch/msg/quic/NZBbuY88v0lrVspQE2A5br83asA

-- 
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/3529#issuecomment-617720476

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Apr 2020 09:19:44 -0700

Folks who care about a change here need to prioritize progressing this issue. We're close to being able to last-call the specs, and would like this resolved in time.

-- 
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/3529#issuecomment-620088318

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 28 Apr 2020 04:37:54 -0700

On 27/04/2020 17:19, Lars Eggert wrote:

> Folks who care about a change here need to prioritize progressing this 
> issue. We're close to being able to last-call the specs, and would 
> like this resolved in time.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620088318>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA>.
>
We’ve completed a round of updated analysis of the proposed change to 
the QUIC spec, using quicly (changing to a 1:10 policy), and chromium 
(which currently does 1:10 by default). Our hope is that this change to 
the spec,  to actually make standard end-to-end QUIC work better than 
TCP over asymmetric paths!

This is a short slide deck about the performance of the proposed change:
https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/QUIC-ack10-24-april-00.pdf

There have been a number of other change made by the QUIC ID editors 
relating to ACK processing, so we wanted to be sure these results were 
up to date. (These results do not consider additional ACKs after 
re-ordering - reflecting the latest text removing that.)

We also really hope this will motivate a change the practice of forcing 
of QUIC fallback to TCP (with PEP/Thining) over highly asymmetric paths. 
People may also be interested in work for L4S to evaluate the impact of 
ACK Thining for TCP-Prague.

Please do provide feedback, or any questions on this - as Lars notes, we 
think the time is running out for considering new changes, even 
relatively simple ones like this.

Gorry

P.S. First email: 
https://mailarchive.ietf.org/arch/msg/quic/NZBbuY88v0lrVspQE2A5br83asA/

-- 
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/3529#issuecomment-620551738

---

From: IngJohEricsson <[email-masked]>
Date: Tue, 28 Apr 2020 05:34:18 -0700

Hi

I believe that it is beneficial to use a 1:10 policy, I understand that this means that a 1:2 policy that still be used in the initial phase (flow start) or does the timer mechanisms kick in to avoid that ACKs are transmitted too sparsely in this case ?.

/Ingemar

From: Gorry Fairhurst <[email-masked]> 
Sent: den 28 april 2020 13:38
To: quicwg/base-drafts <[email-masked]>
Cc: Ingemar Johansson S <[email-masked]>; Comment <[email-masked]>
Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

On 27/04/2020 17:19, Lars Eggert wrote:

> <https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620088318 <https://protect2.fireeye.com/v1/url?k=b82acfbc-e4a36075-b82a8f27-0cc47ad93e1c-7966577c56c12be6&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620088318> >, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA <https://protect2.fireeye.com/v1/url?k=d1f11561-8d78baa8-d1f155fa-0cc47ad93e1c-a2e73379d4d76bf3&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA> >.
>

Gorry

P.S. First email: 

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/v1/url?k=9d433096-c1ca9f5f-9d43700d-0cc47ad93e1c-30eb55b8449f0bee&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620551738> , or unsubscribe <https://protect2.fireeye.com/v1/url?k=fbb00142-a739ae8b-fbb041d9-0cc47ad93e1c-d874a6a9da42014c&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GD2F3JDT6LI5Q4A2NTRO25YTANCNFSM4LOJ4RQA> .  <https://github.com/notifications/beacon/ACRZ2GETA2BOY6L5IISTQD3RO25YTA5CNFSM4LOJ4RQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOET6N4OQ.gif> 

-- 
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/3529#issuecomment-620577062

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 28 Apr 2020 06:03:31 -0700

Yes, our proposal counted ACK-eliciting packets at the receiver (because 
the receiver does not in general know the congestion state, so you need 
a heuristic), and we finally chose the same method in currect QUIC 
Chromium - i.e. for the first 100 packets we do not use ACK 1:10, 
changing only after 100 packets.

Gorry

On 28/04/2020 13:34, IngJohEricsson wrote:
> Hi
>
>
>
> I believe that it is beneficial to use a 1:10 policy, I understand 
> that this means that a 1:2 policy that still be used in the initial 
> phase (flow start) or does the timer mechanisms kick in to avoid that 
> ACKs are transmitted too sparsely in this case ?.
>
>
>
> /Ingemar
>
>
>
> <https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620088318 
> <https://protect2.fireeye.com/v1/url?k=b82acfbc-e4a36075-b82a8f27-0cc47ad93e1c-7966577c56c12be6&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620088318> 
> >,
> > or unsubscribe
> > 
> <https://github.com/notifications/unsubscribe-auth/ABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA 
> <https://protect2.fireeye.com/v1/url?k=d1f11561-8d78baa8-d1f155fa-0cc47ad93e1c-a2e73379d4d76bf3&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA> 
> >.
> >
> <https://protect2.fireeye.com/v1/url?k=9d433096-c1ca9f5f-9d43700d-0cc47ad93e1c-30eb55b8449f0bee&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620551738> 
> , or unsubscribe 
> <https://protect2.fireeye.com/v1/url?k=fbb00142-a739ae8b-fbb041d9-0cc47ad93e1c-d874a6a9da42014c&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GD2F3JDT6LI5Q4A2NTRO25YTANCNFSM4LOJ4RQA> 
> . 
> <https://github.com/notifications/beacon/ACRZ2GETA2BOY6L5IISTQD3RO25YTA5CNFSM4LOJ4RQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOET6N4OQ.gif> 
>
>
> —
> <https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620577062>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLEQBOCAEWPFNFDLHIRLRO3EMFANCNFSM4LOJ4RQA>.
>
-- 
G. Fairhurst, School of Engineering

-- 
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/3529#issuecomment-620592559

---

From: IngJohEricsson <[email-masked]>
Date: Tue, 28 Apr 2020 06:41:01 -0700

OK, it sounds like a good idea to use 1:10 after 100 packets or so. 

Just one potentially stupid question, Is there any special treatment necessary after an RTO ?

/Ingemar

Sent: den 28 april 2020 15:03

Gorry

On 28/04/2020 13:34, IngJohEricsson wrote:
> From: Gorry Fairhurst <[email-masked] <mailto:[email-masked]> >
> To: quicwg/base-drafts <[email-masked] <mailto:[email-masked]> >
> Cc: Ingemar Johansson S <[email-masked] <mailto:[email-masked]> >; Comment 
> <[email-masked] <mailto:[email-masked]> >
> <https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620088318  <https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620088318 > 
> <https://protect2.fireeye.com/v1/url?k=b82acfbc-e4a36075-b82a8f27-0cc47ad93e1c-7966577c56c12be6 <https://protect2.fireeye.com/v1/url?k=b82acfbc-e4a36075-b82a8f27-0cc47ad93e1c-7966577c56c12be6&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620088318> &q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620088318> 
> >,
> > or unsubscribe
> > 
> <https://github.com/notifications/unsubscribe-auth/ABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA  <https://github.com/notifications/unsubscribe-auth/ABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA%20%0b> 
> <https://protect2.fireeye.com/v1/url?k=d1f11561-8d78baa8-d1f155fa-0cc47ad93e1c-a2e73379d4d76bf3 <https://protect2.fireeye.com/v1/url?k=d1f11561-8d78baa8-d1f155fa-0cc47ad93e1c-a2e73379d4d76bf3&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA> &q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABYLLETADUCHE7WAN5IFIWDROWWBNANCNFSM4LOJ4RQA> 
> >.
> >
> <https://protect2.fireeye.com/v1/url?k=9d433096-c1ca9f5f-9d43700d-0cc47ad93e1c-30eb55b8449f0bee <https://protect2.fireeye.com/v1/url?k=9d433096-c1ca9f5f-9d43700d-0cc47ad93e1c-30eb55b8449f0bee&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620551738> &q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620551738> 
> , or unsubscribe 
> <https://protect2.fireeye.com/v1/url?k=fbb00142-a739ae8b-fbb041d9-0cc47ad93e1c-d874a6a9da42014c <https://protect2.fireeye.com/v1/url?k=fbb00142-a739ae8b-fbb041d9-0cc47ad93e1c-d874a6a9da42014c&q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GD2F3JDT6LI5Q4A2NTRO25YTANCNFSM4LOJ4RQA> &q=1&e=3996eab0-a615-40ad-8b7d-b572a1fd4189&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GD2F3JDT6LI5Q4A2NTRO25YTANCNFSM4LOJ4RQA> 
> . 
> <https://github.com/notifications/beacon/ACRZ2GETA2BOY6L5IISTQD3RO25YTA5CNFSM4LOJ4RQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOET6N4OQ.gif <https://protect2.fireeye.com/v1/url?k=5161f97a-0fc2dd89-5161b9e1-0cc47a696e38-a39dc657fd9acc80&q=1&e=cb617aa2-a952-4ce5-b68f-a420cb5683d3&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Fbeacon%2FACRZ2GETA2BOY6L5IISTQD3RO25YTA5CNFSM4LOJ4RQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOET6N4OQ.gif> > 
>
>
> —
> <https://github.com/quicwg/base-drafts/issues/3529#issuecomment-620577062 <https://protect2.fireeye.com/v1/url?k=b6170f3e-e8b42bcd-b6174fa5-0cc47a696e38-8f37a865b0e1011b&q=1&e=cb617aa2-a952-4ce5-b68f-a420cb5683d3&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620577062> >, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLEQBOCAEWPFNFDLHIRLRO3EMFANCNFSM4LOJ4RQA <https://protect2.fireeye.com/v1/url?k=5532145a-0b9130a9-553254c1-0cc47a696e38-eb496219e9f8d14b&q=1&e=cb617aa2-a952-4ce5-b68f-a420cb5683d3&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABYLLEQBOCAEWPFNFDLHIRLRO3EMFANCNFSM4LOJ4RQA> >.
>

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <https://protect2.fireeye.com/v1/url?k=077a043e-59d920cd-077a44a5-0cc47a696e38-805ecde7097ea8aa&q=1&e=cb617aa2-a952-4ce5-b68f-a420cb5683d3&u=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3529%23issuecomment-620592559> , or unsubscribe <https://protect2.fireeye.com/v1/url?k=130f3f99-4dac1b6a-130f7f02-0cc47a696e38-30f82de726554d52&q=1&e=cb617aa2-a952-4ce5-b68f-a420cb5683d3&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACRZ2GAPBJIBIQTIMIVZ2ULRO3HZRANCNFSM4LOJ4RQA> .  <https://github.com/notifications/beacon/ACRZ2GCEHJ36MZSD3LU5MGDRO3HZRA5CNFSM4LOJ4RQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOET6X3LY.gif> 

-- 
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/3529#issuecomment-620615122

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 30 Apr 2020 21:41:28 -0700

Hi, Gorry

Thank you for sharing your experiments. I'm delighted to see results
showing that use of ack10 gives us comparable throughput to ack2.

Recently, I have been looking into how ack-frequency affects the
computational efficiency of the server [1]. Using the (almost) same setup,
I have today run a benchmark comparing three ACK strategies: ack2, ack10,
ack 1/8cwnd.

ack2: 334Mbps
ack10: 414Mbps
ack 1/8cwnd: 487Mbps

As can be seen, ack10 is better than ack2, but lags behind ack1/8cwnd.
That's because there are still frequent ACKs. They take considerable amount
of CPU cycles.

If we want to see QUIC being as lightweight as TLS over TCP, it is
critically important to reduce ACK frequency as much as possible. This is
because the cost of processing ACK in QUIC is much more expensive than TCP,
due QUIC being a userspace transport.

Based on this, if we are to change what we have in the base drafts, I'd
much prefer adopting what we have in the proposed delayed ack extension
[2], rather than just changing the default ack policy from ack2 to ack10.
By adopting what we have in the delayed ack extension, we can expect better
performance, and the endpoints would have the freedom to change the
behavior when the default ack policy is deemed insufficient (regardless of
the default being ack2 or ack10).

[1]
https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency
[2] https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00

> Folks who care about a change here need to prioritize progressing this
issue. We're close to being able to last-call the specs, and would like
this resolved in time.
> Reply to this email directly, view it on GitHub, or unsubscribe.
>
> We’ve completed a round of updated analysis of the proposed change to the
QUIC spec, using quicly (changing to a 1:10 policy), and chromium (which
currently does 1:10 by default). Our hope is that this change to the spec,
 to actually make standard end-to-end QUIC work better than TCP over
asymmetric paths!
> There have been a number of other change made by the QUIC ID editors
relating to ACK processing, so we wanted to be sure these results were up
to date. (These results do not consider additional ACKs after re-ordering -
reflecting the latest text removing that.)
of QUIC fallback to TCP (with PEP/Thining) over highly asymmetric paths.
People may also be interested in work for L4S to evaluate the impact of ACK
Thining for TCP-Prague.
> Please do provide feedback, or any questions on this - as Lars notes, we
think the time is running out for considering new changes, even relatively
simple ones like this.

--
Kazuho Oku

-- 
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/3529#issuecomment-622245014