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: 根據包到達信息，發(fā)送端報告估算最大帶寬

  • Arrival-time model

    • d(i) = t(i) - t(i-1) - (T(i) - T(i-1))
    • d(i): 數據組間延遲
    • t(i): 數據組發(fā)送時間戳
    • T(i): 數據組到達時間戳

    d 表達了兩個數據組間收發(fā)時長的差值。
    d 平均值增大表明數據擁堵，下降表明網絡趨于暢通。

  • Pre-filtering

    為了應對網絡中斷恢復導致的瞬間數據爆增的情況，加入預處理：

    1. burst_time 時間內發(fā)送的所有數據，合并為一個數據組
    2. 到達時間少于 burst_time 并且 數據組間延遲少于0 合并到當前數據組

  • Arrival-time filter

    通過卡夫曼濾波去掉網絡抖動噪聲，估算出實際的數據組間延遲

    • 關于卡夫曼濾波的解釋 https://www.zhihu.com/question/23971601/answer/137325095
      • 根據多個測量值估算
      • 加權平均
      • 根據下一次的測量值修正權重
    • 關于協方差的解釋 https://www.zhihu.com/question/20852004

  • Over-use detector

    根據動態(tài)閥值來得到擁塞狀態(tài)。超出閥值范圍一定時間(建議10ms)，則置為非正常狀態(tài)。

    • 大于閥值范圍，over-use： 擁堵
    • 閥值范圍內，normal：正常
    • 少于閥值范圍，under-use：空閑

  • Rate control

    根據擁塞狀態(tài)來調整估算碼率。
    空閑則回升碼率，擁堵則下調碼率
    估算碼率 A_hat(i)

• 發(fā)送端帶寬估算 SendSide-BWE (chrome m55 及以上版本)

  原理與 gcc 一致，濾波方法改用了 trendline filter

• 發(fā)送端碼率控制 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 三個估算值的最小值。

• 發(fā)送端編碼性能控制

  • 機制說明 bugs.webrtc.org/8504

  通過編碼耗時來估算性能

相關資料

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