擁塞控制算法分類

• 基于丟包(loss rate)的擁塞控制算法
  例如TCP中早期的擁塞控制算法Reno， 會帶來較高的時延

• 基于雙向時延(rtt)的擁塞控制算法
  TCP中較新的cubic, 還有BBR算法基于瓶頸帶寬和rtt, 考量的是雙向時延， 帶寬利用率不夠高，且對時延的控制不夠精確。

• 基于單向時延(one way delay)的擁塞控制算法
  典型的是webrtc中的GCC算法， 是目前實時通訊場景的一個較優選擇。

實時通訊領域的擁塞控制

實時通訊的需求不斷增長， 低延時的擁塞控制就顯得由為重要。這樣就有一個組織叫RMCAT專門來負責制定用于實時通訊的擁塞控制的標準。
目前RMCAT下共有三個大的擁塞算法：GCC, SCReAM, NADA。這三個算法由三個不同公司開發，各有優劣。
GCC有兩個版本的算法：REMB-GCC , TFB-GCC， 原理幾乎是一樣的。

三大標準算法對比

從學術界給出評測數據表明： GCC的公平性更好，能較好的對抗丟包鏈路，但收斂的較慢，較長時間達到穩定帶寬； SCReAM時延更小，但帶寬利用較低，吞吐量小一些； NADA的公平性差一些，收斂較快。

GCC: 基于單向時延（one way delay)的變化來預測數據包在網絡隊列中的排隊情況, 進而調節發送帶寬。 原理見下一節。
SCReAM: 基于單向隊列時延(one way queue delay)的變化在預測數據包在網絡隊列中的排隊情況， 進而調節擁塞窗口。算法如下：

scream.png

NADA: 基于單向時延(one way delay）的變化和丟包時延補償來預測數據包在網絡隊列中的排隊情況， 進而調節發送帶寬。原理如下：

nada.png

REMB-GCC vs TFB-GCC

REMB-GCC : 擁塞判斷基于數據包的時延變化， 收端做擁塞估計，通過REMB報文反饋給發端做擁塞調節。 在webrtc的M55版本之前的版本支持。
TFB-GCC : 擁塞判斷基于數據包的時延變化， 收端通過Transport Feedback反饋收包時間給發端，發端做擁塞估計和擁塞調節。在webrtc的M55版本之后支持。
TFB-GCC 在工程調試上較REMB-GCC方便，因為所有算法計算都在一端。在效果上，差別不太大。

TFB-GCC算法的原理

1. 擁塞控制的流程如下：

   
   
   tcc-flow.png

同REMB-GCC的兩個主要區別：

• 反饋包文件不一樣， 這里是Transport feedback,攜帶的收包時間等信息， 而REMB-GCC是REMB攜帶估算帶寬等信息。
• TrendlineFilter取代了卡爾曼濾波。

2. 同REMB-GCC一樣， 基于數據包的單向時延變化

   
   
   one_way_delay.png

delay(i) = (G(i).recvTime - G(i-1).recvTime) - (G(i).sendTiem - G(i-1).sendTime)

略有不同的是， 不是計算每個包P(i)的時延，而對包進行分組，每5s間隔內的包為一組， G(i).sendTime即第i組包的第一個包的發送時間， G(i-1).recvTime即這一組時間內最后收到的那個包的時間， 以sendTime分組。這樣做主要為了減少發端的時延來來的干擾，發端pacer時間分片5ms，可近似認為5ms的數據是均勻。

可以簡單這么理解：
delay(i) > 0 -- > overuse 網絡擁塞了 ；
delay(i) < 0 --> underuse 網絡變好了；
delay(i) == 0 -- > normal 網絡較平穩；

Trendline Filter計算

1. 將delay做累加和平滑：

   
   
   smoothDelay.png

smoothingCoef是個經驗值， 在webrtc trendline_estimator.cc中取0.9。

另外還有一個相對接收時間recvTime = recvTime(i) - firstRecvTime;
接著將recvTime, accumulatedDelay和smoothedDelay保存到一個固定窗口大小的隊列HistoryQueue中，

2. 然后按以下公式計算線性斜率：

   
   
   slope.png
   
   

   為了限制slope不讓它跑偏了，
   在HistoryQueue中取前80%的包中最小的accumlatedDelay(k), 以及這個包對應的recvTime(k),
   在HistoryQueue中取后80%的包中最大的accumlatedDelay(m), 以及這個包對應的recvTime(k)

   
   
   slopemax.png

slope不能大于slope(max)。

當鏈路排列列隊減少時，slope的值也會減少， 因此slope值反映了網絡帶寬變化趨勢。

trendline.png

slope值即GCC論文中的藍色線m。
動態門限值threshold（線色線）的計算，同REMB-GCC：

threshold.png

當slope > threshold時， overuse
當slope < -threshold時， underuse
其他情況時， normal.

有了以上三種網絡狀態后，就可以對帶寬進行調節：

stat_machine_gcc.png

簡單來說就是： 如果是Decrease, 在接收帶寬基礎上倍數下降， 如果是Increase, 在上一時刻估計的帶寬基礎上遞增， 其他情況則保持不變。 即AIMD算法。

AIMD.png

有了時延估算的帶寬，收端帶寬， 再加上丟包率，就可以綜合評估出當前帶寬了：

loss_bitrate.png

1. TrendlineFilter: goog_cc/trendline_estimator.cc slope計算 -- UpdateTrendline方法， threshold計算： UpdateThreshold
2. OveruseDetector: goog_cc/trendline_estimator.cc Detect方法
3. AIMD : remote_bitrate_estimator/aimd_rate_control.cc
4. Delay base estimator: goog_cc/delay_based_bwe.cc