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

本文对比了WebRTC中的三种拥塞控制算法:GCC、BBR和PCC。GCC算法具有高灵敏度,但带宽预估的稳定性和准确性较差;BBR算法在带宽准确性和稳定性上有优势,但收敛速度慢,抗丢包能力不足;PCC通过网络学习提供更好的适应性,但目前仍处于理论实现阶段,存在诸多问题。测试结果显示,各算法在不同网络条件下的表现各有优劣。
摘要由CSDN通过智能技术生成

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

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值