The transport draft currently says:

An ACK frame SHOULD be generated for at least every second ack-eliciting packet.
This recommendation is in keeping with standard practice for TCP {{?RFC5681}}.

Gorry raised the point that in experiments, this generates way too many ACK packets in high bandwidth networks, such as satellite networks. This has noticeable CPU costs for QUIC, for both sending as well as for receiving. Satellite networks use middleboxes that collapse TCP ACKs, but they can't for QUIC.

We have talked about doing a more general strategy separately as an extension, but we have experience with a fairly straightforward one. Chrome uses an ACK coalescing strategy that does the following: after the first 100 packets, ACK once every 10 packets or 1/4th of an RTT, whichever comes earlier. If we agree that this might be good general strategy, we should suggest it in the transport document.

@ianswett: my recollection is that the strategy had some throughput reduction when used with Cubic, is that correct? Do you think using 1/8th RTT might resolve this?