Re: Proposed extension for delayed acknowledgments

[Ian Swett <[e-mail]>]

Thanks Jana!

This draft was motivated both by the fact Chrome(and Cronet) clients
already have a variation on this enabled(ack every 10 packets or 1/4
min_rtt), and it has shown huge(ie: 2x+) improvements in client CPU,
particularly on mobile clients.  Other clients have had similar experiences.

Additionally, testing on satellite networks has shown this is a critical
performance improvement, because these networks are commonly highly
asymmetric and they can't add proxies which terminate transport(ie: TCP)
separately from crypto for QUIC.

Additionally, by specifying the update_max_ack_delay field in microseconds,
this is a potential fix for Issue #3363
<https://github.com/quicwg/base-drafts/issues/3363>(max_ack_delay should be
in us, not ms).

I'm very excited about this extension and our team intends to implement it
relatively soon in Chrome and Google servers when an IETF QUIC draft is
enabled.

Ian

On Thu, Jan 23, 2020 at 4:51 PM Jana Iyengar <[e-mail]> wrote:

> Hi all,
>
> Ian and I have proposed an extension to enable sender-side control of
> acknowledgement frequency: draft-iyengar-quic-delayed-ack-00
> <https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack/>.
>
> The problem this extension solves was originally discussed in #1978
> <https://github.com/quicwg/base-drafts/issues/1978>, where we agreed that
> this might be best done in an extension. The desire to reduce the frequency
> of acknowledgements was more recently brought up and discussed in #3304
> <https://github.com/quicwg/base-drafts/issues/3304>, where it seemed
> clear that there was interest in working on this now. This proposed
> extension is a result.
>
> This is an individual draft. Please feel free to use the following github
> repo, which is NOT the working group's repo, for filing issues and
> discussion pertaining to the draft:
> https://github.com/janaiyengar/ack-frequency
>
> - jana
>