本文主要從算法層面分析Cubic，以及其它TCP擁塞控制算法
======================================================================================================
1. Cubic
Cubic，立方的。顧名思義，此算法一特徵爲它的窗口增長函數爲一立方函數。
The protocol modifies the linear window growth function of existing TCP standards to be a cubic function
in order to improve the scalability of TCP over fast and long distance networks. It also achieves more
equitable bandwith allocations among flows with different RTTs by making the window growth to be
independent of RTT——thus those flows grow their congestion window at the same rate. During steady
state, Cubic increases the window size aggresively when the window is far from the saturation point,
and the slowly when it is close to the saturation point.
Cubic不僅在BDP網絡中能達到較高的吞吐量，而且它還具有很好的RTT公平性。因此，它是一個TCP-Friendly
和 High-Speed的算法。
Cubic有很好的穩定性。但是如果在易變的網絡環境下，這將是一把雙刃劍。
Because it stays longer near the previous saturation point than other variants, it can be sluggish to find
the new saturation point if the saturation point has increased far beyond the last one.
Cubic有很好的公平性。但是當RTT較小時，這種公平性會降低算法的帶寬競爭力。
The key feature of Cubic is that its window growth depends only on the real tiime between two consecutive
congestion events. When RTTs are short, since the window growth rate is fixed, its growth rate could be
slower than TCP standards.
Cubic取消了max increment。This feature is not needed after entensive testing due to the increased
stability of Cubic. Cubic replaced BIC-TCP as the default algorithm in 2006 after version 2.6.18.
=========================================================================================================
2. scalable tcp
The design objective of STCP is to make the recovery time from loss events be constant regardless of
the window size. This is why it is called "Scalable". Note that the recovery time of TCP-NewReno largely
depends on the current window size.
主要改進方面：快速恢復。使快速恢復時間與當前窗口大小無關，爲一常數。
STCP suggests alternative algorithms for cwnd increase and decrease(in congestion avoidance)
主要算法：
cwnd = cwnd + 0.01 (per ACK received in an RTT)
Upon the first detection of congestion, the cwnd is decreased accordingly:
cwnd = cwnd - (0.125*cwnd)
=========================================================================================================
3. highspeed tcp
HighSpeed TCP(HSTCP) uses a generalized AIMD where the linear increase factor and multiplicative
decrease factor are adjusted by a convex function of the current congestion window size. When the
congestion window is less than some cutoff value, HSTCP uses the same factors as TCP. Most of
high-speed TCP variants support this form of TCP compatibility, which is based on the window size.
When the window grows beyond the cutoff point, the convex function increase the increase factor and
reduces the decrease factor proportionally to the window size.
主要改進方面：AIMD，增加加性因子，減少乘性因子。增得快，降得慢。
=========================================================================================================
4. HTCP
HTCP, like Cubic, uses the elapsed time(t) since the last congestion event for calculating the current
congestion window size. The window growth function of HTCP is a quadratic function of t. HTCP is
unique in that it adjusts the decrease factor by a function of RTTs which is engineered to estimate the
queue size in the network path of the current flow. Thus, the decrease factor is adjusted to be
proportional to the queue size.
主要改進方面：窗口增加函數爲二次函數，與上次擁塞的時間差爲自變量。乘性減少因子，由估計網絡中
的包隊列決定。
==========================================================================================================
5. Vegas
TCP-Vegas measures the difference(O) between expected throughput and actual throughput based
on round-trip delays. When O is less than a low threshold a, TCP-Vegas believes the path is not
congested and thus increases the sending rate. When O is larger than a upper threshold B, which
is strong indication of congestion, TCP-Vegas reduces the sending rate.Otherwise, TCP-Vegas
maintains the current sending rate. The expected throughput is calculated by dividing the current
congestion window by the minimum RTT which typically contains the delay when the path is not
congested. For each round trip time, TCP-Vegas computes the actual throughput by dividing the
number of packets sent by the sampled RTT.
Vegas不是基於丟包檢測，而是利用RTT的變化來判斷帶寬的，這是一種全新的思路，和其它大多數算
法都不一樣。
根據RTT的變化來判斷帶寬，這樣就能時刻洞察網絡的變化，非常敏感。Vegas對慢啓動階段、擁塞避免階段、
快速重傳階段都做了改動，讓人耳目一新。如果大家都採用Vegas，網絡確實可以達到更好的性能。
遺憾的是，它的帶寬競爭力很弱。試想，很多因素都能導致它主動降低發送速率，而採用其它算法的發送速率
則不變或者還在增加，那他能爭的過別人嗎？
==========================================================================================================
6. FAST
FAST determines the current congestion window size based on both round-trip delays and
packet losses over a path. FAST updates the sending rate at every other RTT with rate-pacing.
The algorithm estimates the queuing delay of the path using RTTs and if the delay is well below
a threshold, it increases the window aggressively and if it gets closer to the threshold, the algorithm
slowly reduces the increasing rate. The opposite happens when the delay increases beyond the
threshold: slowly decreases the window first and then aggressively decreases the window.
For packet losses, FAST halves the congestion window and enters loss recovery just like TCP.
FAST沒有被加入到Linux的可選算法中，它算是一種實驗型算法。它嘗試着把基於RTT、基於丟包檢測
這兩種思路結合起來。從這裏可以看出Cubic和Vegas的影子。
==========================================================================================================
7. Westwood
TCP-Westwood estimates an end-to-end available bandwidth by accounting the rate of returning
ACKs. For packet losses, unlike TCP which "blindly" reduces the congestion window to the half,
TCP-Westwood sets the slow start threshold to this estimate. This mechanism is effective
especially over wireless links where frequent channel losses are misinterpreted as congestion
losses and thus TCP reduces the congestion window unnecessarily.
Westwood比較適用於無線網絡，因爲它在丟包後能重設合適的閾值。不過由於不能區分隨機丟包
和擁塞丟包，導致擁塞控制算法不必要的頻繁調用。
==========================================================================================================
8. Illinois
TCP-Illinois uses a queueing delay to determine an increase factor a and multiplicative
decrease factor B instantaneously during the window increment phase. Precisely, TCP-Illinois
sets a large a and small B when the average delay d is small, which is the indication that
congestion is not imminent, and sets a small a and large B when d is large because of imminent congestion.
基於RTT估計，來動態調整AI因子、MD因子。
==========================================================================================================
9. Hybla
TCP-Hybla scales the window increment rule to ensure fairness among the flows with
different RTTs. TCP-Hybla behaves as TCP-NewReno when the RTT of a flow is less than
a certain reference RTT(e.g. 25ms). Otherwise, TCP-Hybla increases the congestion window size
more aggressively to compensate throughput drop due to RTT increase.
Hybla主要解決不同RTT的公平性問題。它採用基於時延補償的方法。對於大時延網絡來說，採用這種算法可以提高傳輸效率。
主要算法：
Equalize performance for connections with different RTTs.
Cwnd increase:
cwnd + 2^p - 1 (slow start)
cwnd =
cwnd + p^2 / cwnd (congestion avoidance)
p is a normalized RTT: p = RTT/RTT0. RTT0 is in Linux set to 25ms
Designed for connections with long RTTs
============================================================================================================
10. Veno
TCP-Veno determines the congestion window size very similar to TCP-NewReno, but it uses
the delay information of TCP-Vegas to differentiate non-congestion losses. When packet loss
happens, if the queue size inferred by the delay increase is within a certain threshold, which is
the strong indication of random loss, TCP-Veno reduces the congestion window by 20%, not by 50%.
Veno主要用於無線網絡。根據Vegas的RTT估計帶寬，它能區別隨機丟包和擁塞丟包。
============================================================================================================
11. BIC
Reduces the cwnd with a multiplicative factor(minimum) in case of packet loss.
Performs a binary search between(minimum) and the cwnd at the time of loss(maximum).
Additionally performs 'max probing' , if the cwnd grows past the current maximum.
However, BIC-TCP's growth function can still be too aggressive for TCP, especially under short RTT or low speed net works.
=============================================================================================================