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

[Gorry Fairhurst <[e-mail]>]

These results/article on computational efficiency are really 
interesting. Please see below.

On 01/05/2020 05:40, Kazuho Oku wrote:
> 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.
>
This is useful, we see here there's a clear benefit here in using a 
larger ACK Ratio also in terms of server load.  We can see already the 
benefit at 1:10 and GSO helps as expected.
> 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.
>
We think that this is also really true. QUIC ACKs are also larger than 
TCP ACKs (see https://erg.abdn.ac.uk/users/gorry/ietf/QUIC/).
> 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
>
I don't think the two approaches conflict.

The difference between the two approaches is that the small change to 
the base specification to use an ACK Ratio 1:10 ensures the default 
return path is at least as good as TCP for common traffic (even with 
common TCP ACK Thinning). Without this change, the end user could 
experience significant differences in performance between TCP and 
between different QUIC versions over asymmetric paths.


Whereas to me, the transport parameter extension looks like an exciting 
way to enable many more things, but there are also many ways this could 
usefully evolve based on CC, offload, pacing etec and I think this will 
take much more to work-out what is needed, safe and best ... then to 
reach consensus. We still also need to specify a default ACK Ratio in 
this case as well.

Best wishes,

Gorry

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