Comparison of TCP BBR algorithm with Reno/cubic _tcp

I have repeatedly stressed that the BBR algorithm is a demarcation point, all TCP congestion control algorithm, is divided into bbr before and after BBR (in fact, this is not my personal point of view, many people think so, all want to write this article to find out). Of course, "all" here does not include those algorithms that are closed, such as the Spam company Appex algorithm, or the great spam Microsoft algorithm. Any algorithm contains an evolutionary process, cubic and Reno look very different, but they belong to the same idea, so it can be said that cubic is the advanced version of Reno (to replace one sawtooth with another), in fact, the TCP congestion control algorithm has been constantly improved, At first, the Reno algorithm, then is Newreno, then is all sorts of melee, until finally implemented to cubic, at least in the Linux platform is such a process, the other platform, is similar.
As for the details of the evolution from Reno to Cubic, it is not discussed here that 80% of the people may not care, and 20% of those who care may know more than I do, so don't talk about it here.
... [But I still have to keep the space]
This is about the consistency of BBR and reno/cubic, which may sound surprising, but isn't there an essential difference? Why do you say they are consistent?
I am particularly grateful to Van Jacobson, the master. Although he did not know me, I have not seen him, but his question led to Reno,cubic until the birth of BBR, I estimate Appex and Microsoft This only eat not to poop Pixiu is also borrowed his ideas.
First of all, I am not a fan of Google, so I can take a fair look at the BBR algorithm, although I have repeatedly stressed how much innovation it, but this does not mean that BBR is the best, if the BBR as a starting point, similar to the beginning of Reno, BBR itself will also have an evolutionary process, I hope that everyone is involved in the process, I can do is to stimulate. I'm just a propagandist, a drummer. By the way, I adore Eric S., who writes "The Cathedral and the market" and can play the flute. Raymond, he calls himself a drummer (why not a flute player). )。
Let's take a look at some of the questions that Van Jacobson raised.
To achieve network stability, TCP entity should obey a ' packet conservation ' principle, which was borrowed from physics.

What is packet conservation principle?
--a New packet is isn't put into the network until a packet leaves (i.e. ' conservation ') while maintaining ' equilibrium ' in which a connection runs stably
By effectively using the bandwidth available on the path.

OK, understanding this is simple and intuitive, and then. VJ went on to say:
Three Failures of packet conservation
1. The connection does not get to equilibrium
2. A sender injects a new packet before a old packet
Has exited
3. The equilibrium can ' t be reached because of
Resource limits along the path

1, 3:equilibrium problem 2:conservation problem

To fix those failures, three algorithm are introduced
* Slow-start algorithm for 1.
* retransmit timeout estimation algorithm for 2.
* Congestion avoidance algorithm for 3.
OK, the question has been mentioned, the solution has, then is how to solve the problem, that is, how to turn the scheme into code.

Let's look at a picture, a diagram of the TCP congestion control algorithm before the BBR algorithm so far, assuming you know something about the TCP congestion algorithm, the diagram is intuitive:

Of course, the fast retransmission/fast recovery algorithm is not included here. Why. Isn't it important to recover quickly? It is not unimportant, but a quick recovery is an optimization that belongs to the above classical illustrations. Didn't I say that the algorithm is an evolutionary process, and no matter how complex it eventually becomes, it won't change at all.        Before BBR, it is simply the image shown above. According to VJ's idea, TCP congestion control is basically the implementation of the red box in the above frame of the processing logic of those stages. Let's take a look at how the BBR was handled before, which is not important, but look at the few after all:

CWnd = 1;                 while (1) {Send packets of min (CWnd, Rwnd); Burst wait until receiving all ACKs for the previous sent packets Slow-start if (timeout occurs) b      Reak;
else CWnd = 2*cwnd;    } threshold = CWND/2;
CWnd = 1;              while (1) {if (CWnd < threshold) {Send packets of min (CWnd, Rwnd);  Burst wait until receiving all ACKs for the previous sent packets if (Slow-start timeout) {    threshold = CWND/2;
        CWnd = 1;}
        else CWnd = 2*cwnd;}     if (CWnd = = Threshold | | CWnd > Threshold) Send packets of min (threshold, rwnd);
        Burst} else if (CWnd > Threshold) {Send a new packet whenever an ACK is received//self-clocking   If (Sender receives all ACKs for the previous sent packets) {CWnd = CWnd + 1; send a new packet;}    To probe more bandwidth if (timeout occurs) {threshold = CWND/2; CWnd= 1;} To avoid congestion}}

However, it is still the words of VJ:
"The way we ' ve always done it" isn't necessarily the same as "the right way to do it"
It's a damn classic.
Then, let's see how BBR is doing.

What can you see by studying the two graphs above?
Reno/cubic:
They are event-driven. Whether the packet is lost or the RTT is increased, it is considered a serious event that causes the TCP congestion control system to be in the "to find current bandwidth" and "to avoid congestion" and
"To probe more bandwidth" switch between, the final implementation is to promote congestion algorithm (whether reno,vegas or cubic) to adjust the size of the window.
So who's going to find out if these events happen? The answer is TCP congestion control state machine. The congestion control state machine directly dominates the switching of these states, so long as it finds that the packet is lost, whether it is true or not, it will pull down the window value.
So, Reno/cubic's window adjustment is passive.
BBR:
The BBR is feedback driven. BBR built-in independent speed regulation mechanism, not under the control of TCP congestion control state machine, BBR algorithm is autistic, it can complete the VJ of all state detection and switching, without outside interference, and the outside interference blind.
BBR periodically tries to detect if there is more bandwidth, and if so, take advantage of it, and if not, return to the previous state.
So, BBR's window adjustment is active.

When you see the difference between Reno/cubic and BBR, you may think of the difference between interruptions and polling, and the difference between BBR and polling is that bbr have factual feedback.
Well, that's the difference between Reno/cubic and BBR, which also completes the logic of "to find the bandwidth", "to avoid congestion" and "to probe more bandwidth". Just one is the passive implementation of event-driven, one is the active implementation of feedback drive. Chatting with colleagues, when talking about high blood pressure, there is a very similar fact: some people only feel dizzy when they will take blood pressure measures, others are constantly drinking water and less alcohol to keep their blood pressure at the normal level ...

At the end of this article, let's take a look at some topics of the BBR algorithm itself.
In fact, as early as 1981, Gail & Kleinrock discovered the model used by BBR:
Rather than using events such as loss or buffer occupancy, which are only weakly correlated with congestion, BBR starts FR Om Kleinrock ' s formal model of
Congestion and its associated optimal operating point.
However, at the time and for the next 30 years, it was thought to be a difficult thing, how do you know that the current bandwidth is not the largest and the RTT is the smallest, and that bandwidth and RTT are related and their product is the BDP. Until recently, Google's BBR was aware of a very simple approach:
While it's impossible to disambiguate any single bandwidth or RTT measurement, a connection ' s behavior over time tells a Clearer story.
How clearer it is.
BBR uses a time window of bandwidth measurement and RTT measurement, the key is this sentence in the "Over time". The key to the BBR algorithm for maximum bandwidth and minimum RTT measurement is the following points:

When the maximum bandwidth is reached, the RTT begins to grow (all caches that do not target the increase rate are bullying.) Caching does not directly increase the rate, and caching improves network utilization by reducing packet loss. ), two operating points are consistent, both from the RTT view and from the bandwidth view, which is fundamental. So how did the BBR measure it?
        stabilize bandwidth first, when bandwidth no longer increases, BBR think has reached the maximum bandwidth can, and then on this basis to measure RTT, bandwidth of the RTT operation Point is coincident. It's so simple and straightforward.

        Now you know that whatever TCP congestion control algorithm solves is a problem (the conclusion is too simple to be nonsense). This is a different method.

        Finally, attach some words.
        In addition to algorithm-level optimization, there are implementation-level optimization, such as how to take advantage of today's multi-core processors, how to optimize the interrupt, how to optimize the lock ... VJ once said that today's TCP implementation is basically inherited from BSD, and BSD and directly follow from Multics, however, Multics is an antique. So VJ says it's not always the right thing to do. Back to BBR, as one of the first drafters of the TCP/IP protocol, although VJ is not a direct implementation of the BBR algorithm, VJ contributes more than any other person can do.

        PS: Last night at the company an all-night, not because of work overtime, is a personal life problems caused. Half asleep and half awake to finish writing this article, also be to oneself guilty heart dozen a dose of injection.