I have repeatedly stressed that the BBR algorithm is a demarcation point, all TCP congestion control algorithm, is divided into bbr before and after the BBR (actually found that this is not my personal opinion, many people think so, all want to write this article to explore). Of course, the "all" here does not include closed algorithms, such as the garbage company Appex algorithm, or the great garbage Microsoft algorithm. Any algorithm contains an evolutionary process, cubic and Reno look very different, but belong to the same idea, so it can be said that Cubic is Reno advanced version (
change one type of sawtooth into anotherIn fact, the TCP congestion control algorithm has been in continuous improvement, at first, Reno algorithm, then Newreno, and then a variety of melee, until finally implemented to cubic, at least in the Linux platform is such a process, the other platform, but also similar.
About the details of the evolutionary process from Reno to Cubic, here, I believe that 80% of people may not care, and the other 20% people who care about may know more than I do, so here is not the talk.
... [But I still have to leave the space]
This is about the consistency of BBR and reno/cubic, which may sound surprising, isn't it an essential difference? Why do they have to say their consistency?
I am particularly grateful to Van Jacobson, the master. Although he does not know me, I have not seen him, but he raised the question led to Reno,cubic until the birth of BBR, I estimate Appex and Microsoft This only eat not to poop Pixiu also borrowed his ideas.
First of all, I am not a fan of Google, so I am more able to use a fair view of the BBR algorithm, although I have repeatedly emphasized how much innovation, 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 have a process of evolution, I hope that everyone involved in the process, all I can do is to stimulate. I'm just a flyer, a drummer. By the way, I worship Eric S., who writes the cathedral and the Bazaar and the flute. Raymond, he claims to be a drummer (why not a flute player?). )。
Let's take a look at some of the issues raised by Van Jacobson.
To achieve network stability, TCP entity should obey a ' packet conservation ' principle, which are borrowed from physics.
What is packet conservation principle?
--a New packet is isn't put into the network until a old 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 what? VJ went on to say:
Three failures of packet conservation
1. The connection does not get equilibrium
2. A sender injects a new packet before an 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 is introduced
* Slow-start algorithm for 1.
* retransmit timeout estimation algorithm for 2.
* Congestion avoidance algorithm for 3.
OK, the problem has been mentioned, the scheme has, the next is how to solve the problem, that is, how to turn the program into code.
Let's look at a graph, a diagram of the TCP congestion control algorithm that has been before the BBR algorithm, assuming you have an idea of the TCP congestion algorithm, then the graph is intuitive:
Of course, the fast retransmission/fast recovery algorithm is not included here. Why? Isn't it important to recover quickly? Not unimportant, but fast recovery belongs to an optimization of the above classic illustrations! Didn't I say that the algorithm is an evolutionary process, no matter how complex it eventually becomes, it will not change at all. Before BBR, it was simply shown.
According to VJ's idea, the root of TCP congestion control is to implement the processing logic of those stages in which the red box is framed. Let's take a look at what BBR did before, although it's not important, but look not much:
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) Bre Ak 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 Slow-start if (timeout occurs) {T Hreshold = 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;} ToAvoid congestion}} However, it is VJ's words:
"The-the-we ' ve always-done it" isn't necessarily the same as "the right-to-do it"
That's a hell of a classic!
Then, let's see how BBR is done.
What can you tell by studying the above two graphs?
reno/cubic:
They are event-driven! Both the loss of packets, or the increase in RTT, are considered a serious event that causes the TCP congestion control system to be in "to find current bandwidth", "to avoid congestion" and
"To probe more bandwidth" switch between, the final implementation is to promote the congestion algorithm (whether reno,vegas or cubic) resizing the window.
So who will find out if these events happen? The answer is a TCP congestion control state machine. The congestion control state machine directly dominates the switching of these states, as long as it finds that the packet drops, whether or not it is true, will pull down the window value.
So, Reno/cubic's window adjustment is passive.
BBR:
BBR is feedback-driven! BBR built-in self-regulating mechanism, independent of the TCP congestion control state machine control, the BBR algorithm is self-closed, it can complete all of VJ's state detection and switching, without external interference, and the external interference blind.
BBR periodically attempts to detect if there is more bandwidth, and if so, use it, if not, to 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 interruption and polling, and the difference between BBR and polling is that BBR has factual feedback.
Well, this is the difference between reno/cubic and BBR, and they also complete the logic of "to find current bandwidth", "to avoid congestion" and "to probe more bandwidth", Just one is the event-driven passive implementation, and the other is the active implementation of the feedback driver. 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 continue to drink water and less alcohol to keep their blood pressure at a normal level ...
At the end of this article, let's look at some of the topics in 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 is only weakly correlated with congestion, BBR s Tarts from Kleinrock ' s formal model of
Congestion and its associated optimal operating point.
However, at that time and in the next 30 years, people think this is a more difficult thing, how do you know the current bandwidth is not the largest and RTT is the smallest, you know, bandwidth and RTT are related, their product is 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 tell s a clearer story.
How clearer is it?
The BBR uses a time window for bandwidth measurement and RTT measurements, and the key is the phrase "over-time"! The key point for the BBR algorithm to measure maximum bandwidth and minimum RTT is the following:
When the maximum bandwidth is reached, the RTT starts to grow (all caches that do not aim at increasing the rate are bullying!). The cache does not directly increase the rate, and the cache improves network utilization by reducing packet loss! ), two operation points are consistent, both from the RTT view and from the bandwidth view, which is basic! So how did the BBR measure it?
first stabilize the bandwidth, when the bandwidth no longer increases, BBR think has reached the maximum bandwidth can, and then measure the RTT on this basis, the bandwidth of the RTT operation Point is coincident! It's so simple and straightforward.
Now, you understand that whatever TCP congestion control algorithm solves is a problem (the conclusion is too simple, it's nonsense). This is a different approach.
Finally, attach some words.
In addition to algorithmic-level optimizations, there are implementation-level optimizations, such as how to leverage today's multicore processors, how to optimize interrupts, how to optimize locks ... VJ once said that today's TCP implementation is basically inherited from BSD, and BSD is directly inherited from Multics, however, Multics is an antique at all. So VJ says it's not always the right thing to do. Back to BBR, one of the first drafters of the TCP/IP protocol, although VJ is not the direct implementation of the BBR algorithm, VJ can contribute more than any other person, stronger.
PS: Last night in the company an all-nighter, not because of work overtime, is the personal life problems caused. Half asleep and half awake in writing this article, but also to their own guilt heart hit a dose of injections.
Comparison of TCP BBR algorithm and Reno/cubic
