Facebook的測試結果顯示，COPA較于常用算法CUBIC及BBR v1存在一定優勢，來看看具體表現。

文 / Nitin Garg

譯 / Adrian Ng

原文 https://engineering.fb.com/video-engineering/copa/

在對互聯網應用進行性能優化時，可能會涉及一些復雜的權衡。在傳輸大量數據的時候，如果傳輸速度過快，可能會因為丟包而產生重傳，從而隨著時間流逝導致性能損失。同時，如果發送數據的速度太慢則可能會導致延遲和卡頓，對性能也有很大的損害。此外，不同的視頻體驗需要針對質量與延遲進行不同的權衡。對于交互式體驗，其應用程序可通過降低視頻質量，避免卡頓。但當視頻的高質量是最重要的因素時，應用程序可以在合理的范圍內的保持一定延遲。此時，應用通常會在幾種不同的擁塞控制算法中進行選擇，找到最適合當前目標的優化算法進行優化。

盡管在擁塞控制領域上我們已進行了廣泛的研究，但若要將研究付諸實踐一直以來都會涉及到修改Linux內核。使用QUIC可以在無需修改內核的情況下，在用戶空間中實現整個傳輸堆棧，簡化整個部署和實驗的流程。而COPA 與 QUIC 的耦合可以為我們提供一種算法，該算法可適用于各種視頻體驗，并且可以合理地遵循一種部署策略。在實際測試中，測試結果顯示COPA較于常用算法CUBIC及BBR v1存在一定優勢。本文將詳細介紹為此所做的實驗工作以及從大規模評估COPA中獲得的經驗。

COPA測試：基于延遲的擁塞控制

經過對COPA的實施和評估， COPA(美國MIT理工學院所設計的基于延遲的可調擁塞控制算法) 基于一個客觀函數，所以吞吐量和延遲的權衡可以通過用戶指定的參數parameter，delta進行配置。如果增量值較高，COPA對延遲就越敏感，使得輸出降低。反應效果的增量值減少將提供高質量的輸出并降低延遲。

在此實驗中，我們選擇了Android平臺上的Facebook Live。通過Facebook Live, 用戶可以做線上直播streaming，推廣給朋友并且獲取更多粉絲. 根據我們的設置，首先需要一個手機攝像頭生成視頻，再用自適應bitrate算法測量輸出, 并調整編碼bitrate。接著，我們將使用QUIC把視頻傳送到FB服務器，重新在服務器內發出新的碼流播放給觀眾。

在第一個測試里，我們實現了無競爭模式（采用固定delta）的COPA。采用0.04的增量值才得以以達到以下結果，并在其中發現這些結構作為應用程序可以提供更合理的質量與延遲權衡，所以將CUBIC和BBR v1擁塞控制算法放在一起進行比較。CUBIC比較常見，也是LINUX的默認擁塞控制算法。此應用模式是增加CWND一直到數據包丟失，再通過乘法式減少CWND。但這種模式也會帶來一些問題，例如緩沖膨脹buffer bloat及jagged鋸齒狀的傳輸模式會導致延遲。最近Google開發的新算法BBR，利用的則是bottleneck帶寬和RTT構建網絡路徑模型，調整發送速率，以實現帶寬和延遲之間的最佳平衡點。COPA、CUBIC 和 BBR的實作方案都可以在我們的 QUIC 方法中找到。

測試結果

我們通過A/B 測試來衡量全球 Facebook 實時視頻的性能，其中大多數在線會話來自美國、墨西哥、印度、印度尼西亞、越南和泰國。在此次實驗中，我們聚焦于每個視頻的應用指標：

平均高質量的輸出: 在廣播期間，發送的應用程序字節總數除以持續時間。請注意，Facebook Live 會話時間通常比較長（從幾十秒到幾分鐘），所以應用程序會根據高質量輸出和隊列大小更改比特率。如果有更好高質量輸出，反應出來的傳送質量也會提升。重傳發生期間，數據字節不會提高輸出質量，原因是因為它們不代表任何新的應用程序字節-自然而然地也減少了goodput.

平均應用程序RTT測試: 這是Live攝入延遲的prox服務器。每一秒，應用程序會向服務器發送一個小的虛擬負載并等待確認。我們測量了此往返時間（RTT），并采用會話時間的平均值來計算平均應用 RTT。如果bitrate相同或比例更高，那表示較低的應用 RTT 會顯示較低的視頻引入延遲。

依據測試結果，我們使用RTT 測量發現 COPA 的視頻延遲平均率比 CUBIC 低。對于網絡良好且低延遲率的session，BBR可以減少更多幅度。P50 應用 RTT 從 499 ms 的 CUBIC 下降到 479 ms 的 COPA 和 462 ms 的 BBR，COPA 減少了 4%， BBR 減少了 8%。

因此，對于網絡較差且延遲率較高的直播，COPA可以克服減少更多的幅度。 P90 App RTT 從 CUBIC 的 5.4 秒降至 COPA 的 3.9 秒，COPA 減少了 27%，而 BBR 的縮減開始減少。

在實際場景中，我們可以通過調整視頻質量來降低延遲。舉個例子，如果降低視頻bitrate，降低視頻質量，每當發生網絡擁塞時，視頻延遲也會相應降低。如果分別把三組數據都拿來做比較，我們會發現COPA和BBR提供的質量輸出要比CUBIC好。這樣的結果反而顯得COPA 和 BBR不僅減少了延遲，還可以提供更高質量的視頻。如果我們遵循延遲改進的模式，可以發現COPA 相比 BBR 有明顯的優勢。BBR 將 P10 改進了 4.8%，而 COPA 提高了 6.2%。BBR 將 P50 良件提高了 5.5%，而 COPA 提高了 16.3%。

我們必須留意的是，在P90 以上的增益似乎會減少，這是由于這個實驗的編碼器bitrate設限為 3 Mbps。在具體實驗中，我們專注于測量 QUIC 運輸的 RTT 和轉播overhead。傳輸 RTT 和應用 RTT 有很大的差異，前者是通過網絡發送數據包后測量往返時間，后者是在數據包離開應用層后測量數據包。應用程序 RTT 存在隱藏的重傳，即使在packet loss的情況下，它也會在傳輸層產生多次的往返運輸。

?

RTT平均傳輸數據

隨著RTT應用模式，BBR為我們提供了最低的傳輸 RTT能量，以獲得最佳連接（P25 及以下）。但是結果顯而易見，平均率幅度的減少并不大，因為對于這些用戶來說RTT已經處在一個很低的平均率了。

當你留意P75 及更高時， COPA在此很明顯提供了最低值。BBR 將 P75 RTT 降低了 10%，而 COPA 將其降低了 35%。與之相比，P95 的降低幅度更大，BBR 將其降低了 16%，而 COPA 將其降低的幅度高達 45%。

如果存在較低的傳輸 RTT，也許可以判定視頻延遲下降的原因。值得注意的是，視頻延遲（RTT應用程序）還取決于應用程序基于 ABR 發送的數據量，這會影響傳輸發送緩沖區中的數據量。因此，這使 ABR 能夠產生更好質量，從而抵消了較低傳輸 RTT 減少的延遲。另一方面，傳輸 RTT 的變化僅取決于數據包離開傳輸后基礎網絡中排隊的數據量

?

RTX Overhead開銷

為進一步了解傳輸行為，我們查看了丟失和傳輸的數據量。該指標的確切定義是：

RTX Overhead = Total bytes retransmitted bytransport / Total bytes ACKed

?

我們發現，與CUBIC相比BBR 對于所有用戶的總體開銷較低，對于90%的用戶來講約為CUBIC的一半左右。COPA和CUBIC相比， COPA 負擔了大約 75% 用戶四分之一的開銷，到最后開始攀升并最終達到CUBIC 的4-5倍左右。

COPA 不將packet loss視為擁塞信號; 當它發現隊列延遲增加時，會主動降低CWND。隨著bottleneck隊列的填滿，COPA 所進行的延遲測量將會增加，我們就可以在流量損失產生前發現存在擁塞。因此在理想情況下，我們應該始終可以看到COPA有較低的數據包流失。實際上，這是大約90%的用戶所看到的，而最后 10% 的用戶則看到更多的損失。這表示丟失率和排隊延遲與這部分用戶沒有關聯性。

網絡流量監管

網絡流量監管表示某一來源的流量被隔離并限制以特定速率節流。。通常情況下，提供者將會丟棄超過該速率的所有額外數據包。并且會產生一些明顯特征，使其與擁塞造成的損失區分開來：

• 一致的吞吐量

• 高損失

• 更低的RTT 和隊列延遲

盡管與CUBIC和BBR相比，COPA的尾端重傳開銷很大，但尾端RTT開銷比較少，這與流量監管的一些特點相符。為了正視這一點，第一步，我們按照ASN 對結果進行分解，因為通常情況下，流量監管會因為ASN 的提供對象不同存在很大差異。經過測試，我們發現某些 ASN（在某一項獨立分析中發現了流量監管的跡象）對于 COPA 的 RTX 開銷也高得多。為了證實此理論，我們繪制了圖表展示 RTT、隊列延遲和 RTX 開銷之間的關聯性。

在圖中的前半部分，我們看到對于 COPA，RTT 和隊列延遲會隨著 RTX 開銷的增加而提升。這表示在當前區域，損失確實是由于擁塞造成的，同時伴隨著排隊延遲的增加。但在達到最大值后，RTT 和隊列延遲在圖表的后半部分開始下降。RTX開銷最高的區域中的用戶實際上看到的延遲非常低。這就證實了我們的結論，即高損失可能是因為網絡限制的原因。不過，短緩沖區也有可能是其中一部分原因，但網絡特征和解決方案非常相似。對于CUBIC來說，RTT 和隊列延遲隨著 RTX 開銷的增加而增加。這表明所有用戶的損失都是由于擁塞造成的，因為 CUBIC 將損失視為擁塞信號，并相應地減少了 CWND。

?

未來計劃

?

COPA的潛力是毋庸置疑的。目標函數運行良好，控制排隊延遲與吞吐量權衡的撥號非常有吸引力。我們的測試是基于極端條件情況進行的，即在非常低的delta值下優化吞吐量。雖然它僅僅是針對吞吐量進行優化，但與 BBR 和 CUBIC 相比，仍然大大減少了排隊延遲。值得注意的是，在我們的 QUIC 實現和傳輸控制協議（TCP） 版本中，BBR 正在進行一些變化和改進，因此這種比較在將來可能會顯示出不同的結果。后續，我們將開始測試另一個極端情況， 即產品對極低延遲有要求時。這項實驗會使我們更接近于擁有一個能夠滿足不同應用需求的單一可調擁塞控制算法。廣泛的部署還需要更好地了解COPA對競爭流程的影響及其對于TCP的友好性。在測試中，我們無法捕捉到這方面的重要信號。因此，這仍然是未來工作很重要的一部分，高RTX cases還存在許多改進的余地。目前有幾種方法來更好的解決這些問題：COPA文件建議實施一種競爭模式，在這種模式中，增量值根據競爭的流動和損失動態變化。另外一種選擇是實施啟發式方法，即根據損失來減少CWDN。但此方法存在一定風險，有可能會使COPA對于擁塞無關的隨機損失做出反應，并侵蝕一些吞吐量。此外，與 BBR v1類似，還有一種方法就是可以為網絡策略實施顯示檢測。

LiveVideoStack?秋季招聘

LiveVideoStack正在招募編輯/記者/運營，與全球頂尖多媒體技術專家和LiveVideoStack年輕的伙伴一起，推動多媒體技術生態發展。同時，也歡迎你利用業余時間、遠程參與內容生產。了解崗位信息請在BOSS直聘上搜索“LiveVideoStack”，或通過微信“Tony_Bao_”與主編包研交流。

總結

以上是生活随笔為你收集整理的Facebook：对比COPA 与CUBIC，BBR v1在拥塞控制及视频质量的表现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。