Facebook 新擁塞控制演算法的實驗結果 - ，針對視訊內容傳輸進行了最佳化。 該演算法是由麻省理工學院的研究人員提出的。 提議用於測試的 COPA 原型是用 C++ 編寫的， 獲得麻省理工學院許可並包含在 — Facebook 正在開發的 QUIC 協議的實作。
COPA 演算法專注於解決透過網路傳輸視訊時出現的問題。 根據視頻類型的不同，對擁塞控制演算法提出了幾乎相反的要求——對於交互式視頻，需要確保最小的延遲，甚至以犧牲質量為代價，而在播放預先準備好的高質量視頻時，會優先考慮以保持品質。 以前，應用程式開發人員只能根據品質或延遲要求應用不同的演算法。 開發 COPA 的研究人員試圖創建一種用於管理 TCP 視訊擁塞的通用演算法，該演算法可以根據視訊要求進行客製化。
擁塞控制演算法的工作是確定發送資料包時的最佳平衡- 發送太多資料包可能會導致資料包遺失，並且由於需要重新發送而導致效能下降，而發送太慢會導致延遲，這也會對性能產生負面影響。 選擇 QUIC 協定進行實驗，因為它允許在用戶空間中實現擁塞控制演算法而不干擾核心。
為了防止通訊通道擁塞，COPA 是基於對資料包傳輸過程中延遲變化的分析來對通道特徵進行建模（COPA 隨著延遲的增加而減少擁塞視窗的大小，從而即使在丟包發生之前的階段，延遲也開始增加） 。 使用特殊的增量參數來調整延遲和吞吐量之間的平衡。 增加增量會增加對延遲的敏感度，但會降低吞吐量，而減少增量則可以提高吞吐量，但會增加延遲。 Delta=0.04 被定義為質量和延遲之間的最佳平衡。
基於 Facebook Live 串流服務，對 COPA 進行了測試，與流行的 CUBIC 和 BBR 演算法進行了比較。 Linux上預設的CUBIC演算法是逐漸增加擁塞視窗的大小，直到發生丟包，之後視窗大小回滾到丟包開始之前的值。
CUBIC 在現代網路設備上的資料包緩衝方面還有很多不足之處，這會減慢資料包遺失的速度。 擁塞控制演算法不知道緩衝，即使頻道已經發生實體擁塞，也會繼續提高速度。 未發送的資料包會被緩衝而不是被丟棄，並且 TCP 的擁塞控制演算法僅在緩衝區已滿時才會啟動，並且無法平衡流量與實體鏈路的速度。 為了解決這個問題，Google 提出了一種改進的 BBR 演算法，透過順序檢查和往返時間（RTT）估計來預測可用頻寬。
當 delta=0.04 時，COPA 指標接近 CUBIC 和 BBR。 在透過低資料包傳輸延遲的高速網路連線進行的測試中，COPA 實現了比 CUBIC（479 毫秒）更低的延遲（499 毫秒），但略落後於 BBR（462 毫秒）。 當連接品質下降時，COPA 顯示最佳結果 - 延遲比使用 CUBIC 和 BBR 時低 27%。
同時，在通訊頻道較差的情況下，與 CUBIC 相比，COPA 和 BBR 可實現顯著更高的吞吐量。 與 CUBIC 相比，BBR 的增益為 4.8% 和 5.5%，COPA 的增益為 6.2% 和 16.3%。
來源： opennet.ru