ACK frequencies should be configurable, solving both bottlenecks and making UDP less relevant at the same time:
Congestion control (the purpose of BBR) deals with the bottleneck problem. Delayed ACKs are an optimization to reduce protocol overhead. Indeed there are problems with delayed ACKs when combined with Nagle’s algorithm and an application that doesn’t send a steady stream of data, but it has nothing to do with the topic of this thread.
TCP_QUICKACK seems to be a boolean (basically 1 or 2 packets per ack)
DelayedAckFrequency goes from 10 to 600 but it's millisecs!?
You don't think acks. have an impact on congestion?
Right now it's hard coded to 2 which is just weird.
Ex:
4 -> 5 -> X -> 7 -> 8 -> 9
Until the client gets 6 then 7,8,9 will be held(and getting stale) until you roundtrip 6. At that point 9 may even be useless since it would be too stale and you've just added extra latency that you don't want or need.
Look up how dead-reckoning is done in realtime games, this is one of many other cases where having timely data works better over UDP than TCP.
For context I built this multiplayer platform, not that that prooves anything but I have 20 years of working with multiplayer: http://fuse.rupy.se/about.html
Really there's no up-side to doing it that way with UDP already existing and tons of downsides in changing an existing protocol in such a fundamental way.