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

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. 这个问题现无法在算法层面去解决,