Four shifting engines for the Googles BBR TCP congestion control algorithm

        On the two almost overnight nights before the arrival of the typhoon hippocampus, I greeted the hippocampus with an article about the BBR algorithm! The company responded to the suspension of work in Shenzhen last night, suspended the call, issued a home office (please note, not a holiday...) notice... In fact, I think the power outage is king, what do you think? In the previous article on the bbr algorithm "Resolve TCP BBR Congestion Control Algorithm from Google" (this may be the first Chinese version of the bbr algorithm related article), I outlined the framework of the bbr algorithm, which is a general introduction. It is. In this article, I want to delve into the details of the bbr algorithm pipe state machine, but I will not continue to use the term "state machine", I chose to use the variable speed engine to demonstrate a modern high-speed TCP shifting engine. How to provide powerful power for data transmission. This set of engines is completely abstracted from the bbr algorithm. The idea comes from the process of running or driving. We suddenly discover that the essence of the bbr algorithm is almost exactly the same as when we are running on the runway and on the highway. Consistent! I can't help but sigh the unity of all things and curse nothingness. When the burning sensation in my stomach is finished, I completed this article! It’s about to start!

1. Linux TCP congestion control mechanism to date
I don't understand the TCP congestion control algorithm implementation of other platforms, but I understand Linux, so far, after bbr has just been introduced, Linux congestion control algorithm Divided into two categories:

Conservative mode
Bbr before Reno, including Reno, NewReno, ... principle almost unchanged, these algorithms have two characteristics: 1). Feedback difference with Reno as an example After the TCP sender receives the ACK in the congestion avoidance phase, it unconditionally increases cwnd by 1/cwnd. After receiving the ACK in the slow start phase, cwnd increases by 1. This is unfounded, but Reno has no better practice. Can only guess! Later Westwood, Vegas, BIC and other algorithms, a little smarter than Reno/NewReno, but still a fool! Later, CUBIC made a tall window-increasing mechanism based on the cubic equation of convexity and concave curve. It seems to be very "due", and it is very "manager", but still can not use the Internet freely. Bandwidth, on the contrary, when encountering anomalies, such as packet loss and congestion, the response is too conservative, and it tends to be fierce on a conservative route, that is, it is fiercely conservative to reduce the congestion window. What is more tragic is that this window is falling. Not subject to these algorithms. 2). The congestion algorithm is taken over when the TCP congestion control mechanism finds a packet loss (ie, RTO or N repeated ACKs, etc.), and TCP completely takes over the congestion control algorithm and controls the congestion window itself. However, the problem is that this so-called packet loss may not be a real packet loss. This is just a TCP packet loss. This is the packet loss judgment mechanism 30 years ago... Is it really lost? Not necessarily! However, as long as TCP considers packet loss, it will take over the congestion control algorithm (at least on Linux...). This makes me not happy! I have modified the PRR logic of Linux TCP, and only ask for the window reduction process is not so fierce... Linux TCP has been exhausted for this window reduction, and has experienced various programs, such as Halving Rate, PRR, etc. Isn't it directly handed over to the congestion control algorithm? ?

In general, the congestion control logic before bbr is divided into two phases, the normal phase and the abnormal phase. In the normal phase, the TCP modular congestion control algorithm dominates the window adjustment. In the abnormal phase, the TCP core congestion control state machine takes over the window calculation from the congestion control algorithm. In the Linux implementation, this is caused by the following logic. Represented:

static void tcp_cong_control(struct sock *sk, u32 ack, u32 acked_sacked, int flag){ if (tcp_in_cwnd_reduction(sk)) { //Exception mode /* Reduce cwnd if state mandates *///Before entering the window fall logic, tcp_fastretrans_alert is also needed to collect exception information and handle the exception process. Tcp_cwnd_reduction(sk, acked_sacked, flag); } else if (tcp_may_raise_cwnd(sk, flag)) { //Normal mode or safe exception mode! /* Advance cwnd if state allows */tcp_cong_avoid(sk, ack, acked_sacked); } tcp_update_pacing_rate(sk);} Whether to enter the exception mode of tcp_cwnd_reduction is determined by the following logic: 
if (tcp_ack_is_dubious(sk, Flag)) { is_dupack = !(flag & (FLAG_SND_UNA_ADVANCED