webrtc拥塞控制算法对比-GCC vs BBR vs PCC

news2024/9/28 7:20:02

1.前言

现有集成在webrtc中的拥塞控制算法有三种, 分别是: 谷歌自研发的gcc, 谷歌自研发的BBR算法, 斯坦福大学提出的基于机器学习凸优化的PCC算法. 本文将探讨一下三个算法的区别和优缺点。

2.背景

迈聆会议从17年到现在, 一直使用的是基于谷歌的gcc算法自研的Omcc算法(optimization of Mindlinker in network congestion controller), 经过这么多年的优化, 在现有表现上已经可以在大部分网络场景下准确预估带宽. Omcc算法已经可以做到抗50%丢包, 抗800ms抖动, 抗2s延时, 在300k-10mbps带宽范围下也可以准确预估带宽值, 在保障低延时的情况下, 能够尽可能提高带宽利用率。

本文将讨论webrtc自带的三种算法的优缺点, 并给出部分测试报告。

3.GCC算法

gcc算法是webrtc默认的算法. 其具体原理本文不再赘述, 已经有各种参考资料去详细讲解了gcc算法的原理.

3.1 gcc算法优点

灵敏度高, 能够及时响应, 提前避免拥塞. 基于抖动和基于丢包的预估值可以很好的预测网络拥塞.

3.2 现有GCC算法所面临的问题和难点

1.带宽对发送数据量的强相关

对于GCC算法, 其网络模型是依靠丢包和抖动去检测网络的拥塞, 从而及时响应网络的动态变化. 原版的GCC算法所能允许的丢包非常小, 丢包大于10%就断崖式下跌带宽. 所能允许的抖动和延时也不高. 通过我们现在的优化之后, 丢包上限达到了50%, 延时增长不是那么敏感, 抗抖动范围也会更高. 但这样带来的结果是, 在带宽预估的稳定性和准确性上面很难做好. GCC算法的逻辑是和数据发送量强相关的, 网络好时发送量多, 带宽预估才会上去. 发送100kbps的码率, 带宽预估很难超过200kbps. 此外, 现有有些发送逻辑是需要去降低发送量, 从而给用户节省带宽的, 比如桌面共享场景下静止画面和动态画面数据量可以从20kbps波动到4mbps.剧烈波动的发送量导致在某些场景下带宽预估的剧烈波动. 波动这么剧烈的场景下, 怎样在既保持带宽预估稳定的同时又不降低发送量呢, 此问题在现有webrtc的策略下很难去解决.

2.带宽恢复速度

GCC算法的核心是慢升快降, 在网络拥塞的时候指数下降带宽, 在网络恢复后, 龟速上涨带宽. 带宽缓慢恢复对于网络来说是一件好事, 但是, 低带宽恢复高带宽需要非常多的时间, 对用户体验不太好. 此外我们有全面放慢带宽上涨的速率, 用于维持在带宽限制场景下的带宽稳定性. 现在的带宽从300kbps上涨到3mbps需要1min, 上涨到6mbps需要90s. 这个问题现无法在算法层面去解决, 如果增加恢复速度后会更容易导致一些场景下带宽高估和带宽波动. 恢复速度和带宽稳定两者当前算法很难做到兼容.

3.带宽准确性

GCC算法在带宽准确性方面还是存在一个硬问题, 首先GCC算法中, 带宽稳定性要和发送码率准确性强相关, 和丢包率和延时又是强相关, GCC算法对网络拥塞很敏感, 稍微的拥塞就会导致带宽波动, 且波动范围挺大的. 如果要适应高抖动高延时等网络变化场景, GCC原生算法会很容易下降到不可接受的范围. 在一些固定丢包场景下GCC是带宽准确性会变得非常差.

4.带宽稳定性

稳定性方面是一个很难去优化的点, 本来带宽就是动态变化, 而且还是比较频繁的, 在限制带宽场景下, 带宽容忍一些上下波动. 但是这个波动范围不能偏离太多, 下图是我们在测试时原生GCC算法的波动情况, 如图波动范围会变化非常大

服务端限制1.5mbps带宽限制后的波动

客户端限制1.5mbps带宽限制后的波动

5.4G弱网环境

在4G弱网场景下, 延时会变得很大, 且和发送量相关, 没有丢包, 这种网络模型属于肥长管道形网络, GCC算法在此场景中会变得非常迟钝, 因为网络中没有丢包, 网络延时平滑增长, 且抖动很小. 导致基于抖动计算的带宽值会变得非常迟钝. 无法准确预估出低延时下的带宽值.

4G弱网场景下发送数据量太多后, 延时会变得非常非常大, 却不会出现网络丢包

4.BBR算法

BBR核心思路就是通过调整发送量去探测到网络的最大带宽和最小延时. 最大带宽通过发送超过网络容量的数据去获取, 当增加发送量后延时也开始增加时, 此时就是最大带宽. 最小延时通过发送低于网络容量的数据去计算, 当降低发送量后延时不降低时, 此时的RTT就是最小延时. 找到下图的理想点, 也就是BDP, 就是我们现在可以发送的最大带宽.

BBR算法网络模型

BBR设置了一个状态机用于不断获取当前变化网络的最小RTT和最大带宽, 但是探测BDP的过程只占整个周期的2%, 98%的场景是用于以正常速率去传输的. 毫无疑问, BBR天生就可以解决限制带宽场景下的带宽预估稳定性和准确性问题, 针对4G网络这种肥长网络模型也有对应的策略. 而且其带宽预估的准确性会很好. 但是发送数据的强相关性还是个问题, BBR在类似桌面共享这种场景下的发送码率变化剧烈的场景下估计适应性不会很好.

4.1 BBR算法的缺点

\1. 收敛速度慢\2. 抗丢包能力不足\3. ProbeRTT状态只发送四个包, 不适合低延时流媒体应用\4. 发送码率周期性波动\5. 上下行RTT和Loss相互影响(估计是有潜在bug)

4.2 BBR算法的优点

a. Probe_RTT 阶段的隐藏弱化b. 上行网络丢包带宽补偿c. 上行网络RTT突变以及高Jitter场景优化d. 下行链路抖动以及丢包的优化e. Padding流量的优化f. 快速上探机制的实现

测试webrtc中BBR的表现, 在带宽准确性和稳定性方面和上面描述的一致, 延时和抖动适应也都没问题, 抗持续丢包在25%左右.

5.PCC算法

PCC的目标是开发一种性能明显优于TCP传统算法的传输协议, 且保持一定的实际可部署性. 这种性能的改进是根据各种网络设置的吞吐量和各种公平的度量来衡量的. 其和以往传统的基于网络事件(丢包变化或者延时变化或者抖动变化之类)的hardwired-mapping硬连接映射不同, 是基于更广泛的网络条件来实时作出发送速率决策. 其具有网络学习的能力. 这一点是传统网络所不具备的;

PCC通过在执行期间不断以不同的速率发送数据进行A/B测试去测量网络. 最终的目的是通过目标函数去进行凸优化, 从而找到全局最优解, 并以此速率去运行. 对比PCC和BBR, 两者都是类似A/B测试去测量网络, BBR使用网络白盒建模的方式去转换表现测量, PCC使用黑盒机制, 在特定速率发送时去观察表现矩阵以及效用函数, 来调整发送策略.