https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-remb-03 - REMB
https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02 - A Google Congestion Control Algorithm for Real-Time Communication on the
World Wide Web

REMB GCC 拥塞控制的关键说明

• 接收端带宽估算 REMB

  Delay-based controller: 根据包到达信息，发送端报告估算最大带宽

  • Arrival-time model

    • d(i) = t(i) - t(i-1) - (T(i) - T(i-1))
    • d(i): 数据组间延迟
    • t(i): 数据组发送时间戳
    • T(i): 数据组到达时间戳

    d 表达了两个数据组间收发时长的差值。
    d 平均值增大表明数据拥堵，下降表明网络趋于畅通。

  • Pre-filtering

    为了应对网络中断恢复导致的瞬间数据爆增的情况，加入预处理：

    1. burst_time 时间内发送的所有数据，合并为一个数据组
    2. 到达时间少于 burst_time 并且 数据组间延迟少于0 合并到当前数据组

  • Arrival-time filter

    通过卡夫曼滤波去掉网络抖动噪声，估算出实际的数据组间延迟

    • 关于卡夫曼滤波的解释 https://www.zhihu.com/question/23971601/answer/137325095
      • 根据多个测量值估算
      • 加权平均
      • 根据下一次的测量值修正权重
    • 关于协方差的解释 https://www.zhihu.com/question/20852004

  • Over-use detector

    根据动态阀值来得到拥塞状态。超出阀值范围一定时间(建议10ms)，则置为非正常状态。

    • 大于阀值范围，over-use： 拥堵
    • 阀值范围内，normal：正常
    • 少于阀值范围，under-use：空闲

  • Rate control

    根据拥塞状态来调整估算码率。
    空闲则回升码率，拥堵则下调码率
    估算码率 A_hat(i)

• 发送端带宽估算 SendSide-BWE (chrome m55 及以上版本)

  原理与 gcc 一致，滤波方法改用了 trendline filter

• 发送端码率控制 GCC

  Loss-based controller: 根据丢包率，编码性能，RTT时间估算码率
  每次收到 REMB 需要计算一次丢包率，估算码率 As_hat(i)

  • 2%-10%丢包率：保持不变
  • <2%：As_hat *= 1.05
  • >10%：As_hat = 1 - 0.5丢包率

  2-10%制定的理由：如果丢包率保持在10%以下，一般不是因为自身码率原因导致的，所以不作码率调整。如果是自身码率原因导致丢包，丢包率会不断递增，直到突破10%。

  • 据说，码率还会根据 TFRC 估算。最后取 Delay-based Loss-based TFRC 三个估算值的最小值。

• 发送端编码性能控制

  • 机制说明 bugs.webrtc.org/8504

  通过编码耗时来估算性能

相关资料

https://blog.csdn.net/fishmai/article/details/78793512
https://blog.csdn.net/crystalshaw/category_9281395.html