Subject: Review of draft-ietf-quic-ack-frequency-01

From: Martin Duke <[email-masked]>
Date: Tue, 9 Nov 2021 15:42:44 -0800

I believe this work is valuable.

*Possibly unactionable discussion*:
The most obvious use case, to me, is a mobile client trying to conserve
power by limiting the number of acks it sends on a download. It therefore
seemed counter-intuitive to have this be a data-sender-driven process.
However, as the real limiting factor is the flexibility of the sender's
congestion control and loss recovery, I eventually saw that your chosen
design is more or less inevitable.

I wonder how to implement a server when this extension is ubiquitous. Is
the correct strategy to send ACK_FREQUENCY with quite large thresholds and
Requested max_ack_delay (and, presumably, also a quite high value of L for
Appropriate Byte Counting), so that a client sensitive to these can go as
high as it needs to?

*Nits*:
Please specify the acceptable packet types for each frame.

Please define what it means to "bundle" an acknowledgment.