Facebook：對比COPA 與CUBIC，BBR v1在擁塞控制及視頻質量的表現

 

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 實時視頻的性能，其中大多數在線會話來自美國、墨西哥、印度、印度尼西亞、越南和泰國。在這次實驗中，咱們聚焦於每一個視頻的應用指標：

1. 平均高質量的輸出: 在廣播期間，發送的應用程序字節總數除以持續時間。請注意，Facebook Live 會話時間一般比較長（從幾十秒到幾分鐘），因此應用程序會根據高質量輸出和隊列大小更改比特率。若是有更好高質量輸出，反應出來的傳送質量也會提高。重傳發生期間，數據字節不會提升輸出質量，緣由是由於它們不表明任何新的應用程序字節-天然而然地也減小了goodput.
2. 平均應用程序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相似，還有一種方法就是能夠爲網絡策略實施顯示檢測。