TCP拥塞控制算法内核实现剖析（三）
本文主要从算法层面分析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.
详细分析可看上一篇博客。
=============================================================================================================
