Re: [quicwg/base-drafts] ACK generation recommendation (#3304)

[ianswett <[e-mail]>]

@kazuho I was hoping to have the Chrome default be ACK every two packets and then use a frame or TP to change the behavior everywhere we're running BBR.  But I haven't done that yet.

@janaiyengar Your points are very strong.  We have a loads of evidence from QUIC and TCP that acking every 2 packets is not the right choice in many circumstances, so saying SHOULD seems quite odd.  On the other hand, I feel like we punted this issue when it was raised before(#1978 ), and I feel like this is a bit late to make large changes.

@junhochoi I would prefer to avoid sending a congestion controller, since that limits innovation going forward(ie: what if someone uses a new CC?).

Here are some possible options(feel free to suggest others):
1) We make the existing text a default, but not really a recommendation: ie: You should ACK every two packets, unless you know better.
2) We add a 'fraction of RTT' ack aggregation transport param that a peer can specify, which kicks in at 'some point' when the receiver thinks the sender is out of slow start or the receiver sending too many ACKs per RTT.  Also limit the number of packets in a single ACK to IW, in order to limit bursts to IW.
3) We add a frame for "Number of packets before sending an ACK", as discussed in #1978 
4) We say something about not ACKing more frequently than the timer granularity, unless IW has arrived.
5) We say you have to ACK every IW and within max_ack_delay, and that's it.  If you want an immediate ACK, skip a packet number.  This has costs in terms of ack frame size and datastructure size, and means we have to be more conservative about how many times to send an immediate ACK after receiving a gap(ie: probably only once).

There are(at least) three resources being conserved here: Sender CPU, Receiver CPU, and path bandwidth(or transmission opportunities, packet counts, etc), so no one has perfect information.

-- 
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/3304#issuecomment-567537204