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

[Gorry Fairhurst <[e-mail]>]

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

2020年4月28日(火) 20:37 Gorry Fairhurst <[e-mail]>:
>
> 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, 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!
>
> 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/



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