Self-clock TCP ACK congestion control required to cause formation continue sending data packets, but this is only 1988 Van Jacobson view, i.e., holding over the full VJ but not overflow pipe .
Obviously, this ideal has not been realized until today. Later, BBR transformed the VJ pipeline and used pacing rate instead of cwnd for congestion control. However, pacing rate relies on ACK anyway, but it is not as heavily dependent on AIMD. Self-clock can be weakened or even cancelled.
This means that there is no need for continuous ACKs. As long as a max bandwidth can be collected and maintained in a predetermined max-filter function, data can be sent continuously at the calculated pacing rate.
In the past, under the combined effect of data packet conservation and AIMD principles, ACK must continue to arrive. Now ACK only needs to ensure that the speed can be measured within the max-filter range. what does this mean?
This means that midbox can randomly or deliberately discard some pure ACK packets. Let's see what benefits can be brought by losing these pure ACK packets.
- A box in a weak network environment/half-duplex environment no longer requires arbitration of shared resources in order to process pure ACK.
- The encryption and decryption box no longer needs to consume CPU in order to process pure ACK that only provides self-clock, which saves energy and reduces emissions.
- Midboxes no longer need to design complex AQM systems in order to take into account pure ACK, which reduces the complexity of the control plane.
- …
So, if you have a calculation method for pacing rate, then abandon continuous ACK. You may have been indoctrinated, and then feel that continuous ACK is indispensable, how can there be no ACK? …Refer to how BBRv2 estimates the pacing rate without continuous ACK.
What is interesting is that the self-clock formed by ACK was originally used for sliding window control, not for congestion window control.
…
max-filter is not perfect, but it is the beginning. Does this filter based on time window mean nothing? It is getting rid of the continuous dependence on the ACK stream.
My suggestion is that if you want to improve the transmission performance of a single machine, if you use BBR or self-developed algorithms, then drop more pure ACK packets at a lower level! In fact, there is another meaning behind the self-developed algorithm. If it is a self-developed algorithm, do you still rely on ACK for TMD? Shet it. Of course, this short article is written in Chinese, and it is aimed at TCP acceleration vendors in the Chinese circle. Oh, that's an area I hate.
What is a good way? Fortunately, I no longer do anything in this field, so when I am fine, I can think about it.
Zhejiang Wenzhou skinshoe wet, down rain enter water not can fat. Zhejiang Wenzhou skinshoe wet, down rain enter water not can fat
.