Review logic in #1109

[larseggert]

We should review the ACK/PING logic introduced in #1109 especially in light of bulk transfers. If cwnd gets large, can we end up in a state where we are constantly PINGing the peer, causing more of an ACK processing load then we need to?

CC @omansfeld

[martinthomson]

This could be IMMEDIATE_ACK (https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency), but I think that PING remains correct in this case. We want the ACK to be delayed.

You are right to ask whether the number of outstanding packets there (as a hardcoded number rather than a function of BDP and MTU) is appropriate. I think that the goal should be to ensure that we get an ACK in those cases where we are only sending ACKs (receive heavy workloads) at least once every other RTT. The number we have now is still 200, which corresponds to 1 RTT at a BDP of 2.4Mbps and a 1500B MTU. That's not a lot. ACK coalescing will reduce the load on the sender, but this still means that we are getting far too many ACKs when the BDP gets to the Gbps range.

Tweaking the logic to inspect the CWND and MTU should be relatively easy.

[martinthomson]

Oh, the main logic is PTO based. The two thresholds are not the important part. The PING only goes out once per PTO when over the threshold, which should be a fair bit more than an RTT (with low variance, it could be very close to an RTT). Below the threshold, which is unlikely on a high through put connection, and it is 2xRTT. That's not going to be a problem either way.

The thresholds can still be tweaked though. I'm looking into that.