实时通讯中拥塞控制算法
fire fox
拥塞控制算法分类
基于丢包(loss rate)的拥塞控制算法
例如TCP中早期的拥塞控制算法Reno， 会带来较⾼的时延
基于双向时延(rtt)的拥塞控制算法
TCP中较新的cubic, 还有BBR算法基于瓶颈带宽和rtt, 考量的是双向时延， 带宽利⽤率不够⾼，且对时延的控制不够精确。
基于单向时延(one way delay)的拥塞控制算法
典型的是webrtc中的GCC算法， 是⽬前实时通讯场景的⼀个较优选择。
organize实时通讯领域的拥塞控制
实时通讯的需求不断增长， 低延时的拥塞控制就显得由为重要。这样就有⼀个组织叫RMCAT专门来负责制定⽤于实时通讯的拥塞控制的标准。⽬前RMCAT下共有三个⼤的拥塞算法：GCC, SCReAM, NAD
A。这三个算法由三个不同公司开发，各有优劣。
火锅 英语
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
xn(ti) = ˜d(ti) （即one way delay) + Dloss (丢包预计时延） · ploss(ti) （丢包率）电脑维修工具
REMB-GCC vs TFB-GCC
REMB-GCC : 拥塞判断基于数据包的时延变化， 收端做拥塞估计，通过REMB报⽂反馈给发端做拥塞调节。 在webrtc的M55版本之前的版本⽀持。
TFB-GCC : 拥塞判断基于数据包的时延变化， 收端通过Transport Feedback反馈收包时间给发端，发端做拥塞估计和拥塞调节。在webrtc的M55版本之后⽀持。
TFB-GCC 在⼯程调试上较REMB-GCC⽅便，因为所有算法计算都在⼀端。在效果上，差别不太⼤。
TFB-GCC算法的原理天文潮
1. 拥塞控制的流程如下：
one_way_delay.png delay(i) = (G(i).recvTime - G(i-1).recvTime) - (G(i).ndTiem - G(i-1).ndTime)
道喜smoothDelay.png
smoothingCoef是个经验值， 在webrtc trendline_estimator中取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
emperorslope值即GCC论⽂中的蓝⾊线m。
笔译价格
动态门限值threshold（线⾊线）的计算，同REMB-GCC：
threshold.png
yipin当slope > threshold时， overu
当slope < -threshold时， underu
其他情况时， normal.
有了以上三种⽹络状态后，就可以对带宽进⾏调节：
stat_machine_gcc.png
简单来说就是： 如果是Decrea, 在接收带宽基础上倍数下降， 如果是Increa, 在上⼀时刻估计的带宽基础上递增， 其他情况则保持不变。即AIMD算法。
