WebRTC的带宽评估的新变化

带宽评估(BWE)也许是WebRTC的视频引擎中最关键的模块了, 它将决定视频通信中, 不引发网络拥塞时最多可以产生的视频数据量.

早期的带宽评估算法比较简陋, 大多是基于丢包来估计, 基本的策略是逐步增加发送的数据量, 直到检测到丢包为止. 为了让发送端获悉网络上的丢包信息, 可以使用标准的RTCP的RR来发送周期性的报告.

现代的带宽评估算法则可以在网络链路发生丢包以前就监测到网络拥塞, 它可以通过侦测数据包接收的时延来预测未来可能的拥塞. 它是基于链路上的路由器都有一定的缓存, 在数据包开始被丢弃之前, 先发生数据在缓存里堆积的事件, 所以时延相比于丢包, 对拥塞的反应更加灵敏. 现在几个典型的算法有: Google Congest Control(https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02), 爱立信的SCEAM(https://github.com/EricssonResearch/scream) 和 MIT的SPROUT(http://aim.nms.lcs.mit.edu/papers/nsdi13-sprout.pdf). Mozilla的这篇文章讲述了拥塞控制算法演变的历史(https://blog.mozilla.org/webrtc/what-is-rmcat-congestion-control/)

WebRTC刚开始的时候是用接受端的带宽评估来决定发送端的码率的, 如上文, 接受端根据接受到的数据量和数据包时延的变化, 得到当前网络带宽的评估, 使用REMB 将评估的带宽汇报给发送端. 另一个细节是, WebRTC的发送端除了使用REMB之外, 还会根据丢包情况来决定当前的视频码率, 伪代码如下:

Sender pseudocode (send_side_bandwidth_estimation.cc):
  onFeedbackFromReceiver(lossRate):
    if (lossRate < 2%) video_bitrate *= 1.08
    if (lossRate > 10%) video_bitrate *= (1 - 0.5*lossRate)
    if (video_bitrate > bwe) video_bitrate = bwe;

比较好的码率控制方法是, 检测到拥塞是,迅速下调码率, 当网络无拥塞是, 缓慢上调码率.

最近的WebRTC已把带宽评估整个搬到了发送端. 不过评估机制跟之前并没有显著的变化, 接受端需要把时延信息汇报给发送端, 这一机制引入了2个新的协议.

1. Transport wide sequence number header extension.
   a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
2. Transport Feedback
   a=rtcp-fb:100 transport-cc

详细可以参看: https://www.ietf.org/archive/id/draft-holmer-rmcat-transport-wide-cc-extensions-01.txt

The Original Post

http://www.rtcbits.com/2017/01/bandwidth-estimation-in-webrtc-and-new.html