实时通讯中拥塞控制算法

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了实时通讯中拥塞控制算法相关的知识,希望对你有一定的参考价值。

参考技术A 实时通讯的需求不断增长, 低延时的拥塞控制就显得由为重要。这样就有一个组织叫RMCAT专门来负责制定用于实时通讯的拥塞控制的标准。
目前RMCAT下共有三个大的拥塞算法:GCC, SCReAM, NADA。这三个算法由三个不同公司开发,各有优劣。
GCC有两个版本的算法:REMB-GCC , TFB-GCC, 原理几乎是一样的。

从学术界给出评测数据表明: GCC的公平性更好,能较好的对抗丢包链路,但收敛的较慢,较长时间达到稳定带宽; SCReAM时延更小,但带宽利用较低,吞吐量小一些; NADA的公平性差一些,收敛较快。

GCC: 基于单向时延(one way delay)的变化来预测数据包在网络队列中的排队情况, 进而调节发送带宽。 原理见下一节。
SCReAM: 基于单向队列时延(one way queue delay)的变化在预测数据包在网络队列中的排队情况, 进而调节拥塞窗口。算法如下:

NADA: 基于单向时延(one way delay)的变化和丢包时延补偿来预测数据包在网络队列中的排队情况, 进而调节发送带宽。原理如下:

REMB-GCC : 拥塞判断基于数据包的时延变化, 收端做拥塞估计,通过REMB报文反馈给发端做拥塞调节。 在webrtc的M55版本之前的版本支持。
TFB-GCC : 拥塞判断基于数据包的时延变化, 收端通过Transport Feedback反馈收包时间给发端,发端做拥塞估计和拥塞调节。在webrtc的M55版本之后支持。
TFB-GCC 在工程调试上较REMB-GCC方便,因为所有算法计算都在一端。在效果上,差别不太大。

同REMB-GCC的两个主要区别:

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 网络较平稳;

smoothingCoef是个经验值, 在webrtc trendline_estimator.cc中取0.9。

另外还有一个相对接收时间recvTime = recvTime(i) - firstRecvTime;
接着将recvTime, accumulatedDelay和smoothedDelay保存到一个固定窗口大小的队列HistoryQueue中,

slope不能大于slope(max)。

当链路排列列队减少时,slope的值也会减少, 因此slope值反映了网络带宽变化趋势。

slope值即GCC论文中的蓝色线m。
动态门限值threshold(线色线)的计算,同REMB-GCC:

当slope > threshold时, overuse
当slope < -threshold时, underuse
其他情况时, normal.

有了以上三种网络状态后,就可以对带宽进行调节:

简单来说就是: 如果是Decrease, 在接收带宽基础上倍数下降, 如果是Increase, 在上一时刻估计的带宽基础上递增, 其他情况则保持不变。 即AIMD算法。

有了时延估算的带宽,收端带宽, 再加上丢包率,就可以综合评估出当前带宽了:

互联网协议 — TCP — 拥塞控制(网络质量保障)

目录

拥塞控制

前面的流量控制是避免「发送方」的数据填满「接收方」的缓存,但是并不知道网络的中发生了什么。一般来说,计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。

如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度。为了在「发送方」调节所要发送数据的量,定义了一个叫做「拥塞窗口」的概念。

以上是关于实时通讯中拥塞控制算法的主要内容,如果未能解决你的问题,请参考以下文章

转载WebRTC基于GCC的拥塞控制(上) - 算法分析

TCP拥塞控制算法之NewReno和SACK

TCP拥塞控制算法

sdn默认路由算法与拥塞相关问题

浅谈TCP拥塞控制算法

在TCP的拥塞控制中,啥是慢开始、拥塞避免、快重传和快恢复算法