瓶頸帶寬和往返傳播時間(BBR)是一種TCP擁塞控制算法，由於它能夠提供更高的吞吐量(許多內容提供商都報告了這一點)，因此引起了市場的極大關注。 在本篇文章中，我們將在Verizon Media (現在是Edgio的)內容交付網路(CDN)工作負載的環境中評估BBR (版本1)，該工作負載可提供大量(多Tbps)的軟體更新和流影片，並量化收益和對流量的影響。 我們希望在大型CDN中進行此類評估將有助於其他內容提供商為其流量選擇正確的擁塞控制協議。
背景
許多內容提供商和學術研究人員發現BBR比TCP-Cubic等其他協議提供更高的吞吐量。 與基於損失的擁塞控制算法(如無處不在的TCP-Cubic)不同，BBR具有不同的操作模式：它根據會話到目前為止所見的最小RTT持續更新傳輸中的數據量，以避免緩衝膨脹。 有關BBR操作的更多信息，請在這裏查看Google的原始出版物。
測量和分析
為了了解CDN的BBR潛力，我們在多個階段評估了BBR，測量了幾個存在點(POP)對TCP流量的影響。 POP代表位於大城域的暫存伺服器集中。 最初，我們在POP上執行了小規模BBR測試，同時還執行了完全POP測試，所有流向執行BBR的客戶端。 為了確定客戶端可以體驗到的優勢，我們在測試期間測量了內部代理Web伺服器日誌的吞吐量，以及套接字級別分析。
要評估的指標
我們的多租戶CDN可以看到大量的客戶端流量。 許多客戶擁有許多小對象，而其他客戶擁有更大的數千兆位元組對象。 因此，確定成功指標至關重要，這些指標可捕獲不同流量模式的實際性能增益。 特別是，在本次評估中，我們將吞吐量和TCP流完成時間確定爲成功參數。 在圖1中，我們顯示了從CDN請求的常見對象大小與提供這些對象所需時間的熱圖。 顏色漸變表示每個類別中的請求數。 這些是一小組伺服器的代表性編號，足以僅捕獲常見行為。
圖1. 熱圖顯示常見對象大小。
熱圖讓我們了解不同的請求模式。 一般來說，獲得更高的吞吐量是性能增益的最佳指標。 但是，吞吐量作為測量值可能非常嘈雜，尤其是在對象大小較小(少於幾MB)的情況下。 因此，根據對哪些大小提供最可靠的吞吐量評估的單獨評估，我們僅使用大於3MB的對象大小進行吞吐量評估。 對於小於3MB的對象，跟蹤流完成時間是更好的度量。
作爲評估的第一步，我們在洛杉磯的幾臺服務器上啓用了BBR，並監控了所有TCP流量的吞吐量和流量完成時間。 以下結果將檢查一些Internet服務提供商特定的案例研究。
大型無線提供商
圖2顯示了打開BBR後的差異。
圖2。 與立方流量(控制)相比，打開BBR (測試)時對大型無線提供商客戶端的吞吐量影響。 左側：兩天內的吞吐量測量。 藍色垂直線指示BBR何時啟動。 在這裡，我們看到BBR的整體改善約為6至8 %。 右：吞吐量為第五百分位的CDF。 BBR流量顯示顯著改善。
對於這家無線提供商，我們在啟用BBR後，平均而言，吞吐量提高了6到8％。 總體來說，TCP流量完成時間也降低了。 這一結論與Spotify，Dropbox和YouTube的其他報告一致，在無線網路中，吞吐量明顯提高，數據包丟失很常見，但這不一定是擁塞的指標。
大型有線提供商
接下來，我們檢查了一家大型有線提供商的性能。 在這裡，我們還看到了使用BBR的吞吐量(對於大型對象)和流量完成時間(如圖3所示)的改進。
圖3。 大型有線提供商完成流量所需的平均時間。 BBR (測試)流顯示的抖動較少，完成數據傳輸所需的時間也較短。 對於較大的物體而言，其優勢更具影響力。 但是，對於Cubic和BBR的較大文件大小，我們確實看到類似的抖動。
這些測試報告的收益顯示客戶端通信的結果非常有希望。
由於這些收益都是在匯總視圖上實現的，我們決定深入一點，檢查是否所有TCP流量在Pop中都看到了使用BBR的好處；或者是否有些TCP流量受到影響，以及哪些流量受到影響？
在CDN邊緣，我們執行四種不同類型的TCP會話：
- 彈出到客戶端(如上所示)
- 彈出到彈出(數據中心之間)
- Pop內通信(同一Pop的高速暫存之間)
- 彈出到源站(彈出到客戶源站數據中心)
在本研究中，我們考慮了Pop-to-Client，Pop-Pop和Pop內流量，因為邊緣到源的流量不如其他三種流量高。
Pop-to-Pop和Pop內流量
評估對這些TCP流的影響也很重要，因為在許多情況下，這些流會阻止客戶端交付，如動態內容。
對於Pop到Pop和Pop內流量吞吐量，我們發現性能出現了很大的倒退。 圖4顯示了同一時間段內對Pop內和Pop到Pop通信的影響：
圖4。 與立方流量(控制)相比，打開BBR時(測試)對Pop內和Pop到Pop通信的吞吐量影響。 兩天內的通量測量。 藍色垂直線指示BBR何時啟動。 使用BBR時，吞吐量減少了約一半。
在以前的調查結果中，尚未報告流向最終用戶和數據中心之間的這種明顯的性能差異。 我們需要評估這些特定TCP流量遭受影響的原因；如果這是我們CDN上的硬體或配置的成品；如果是，需要更改哪些調整。
從使用Web伺服器訪問日誌進行的進一步調查以及從伺服器端套接字數據進行的評估來看，在高RTT流量和低RTT流量的情況下，使用BBR會影響RTT非常低的TCP流量。 我們進一步評估了傳輸的數據少於0.5KB的案例，發現在大多數案例中，BBR的表現與CUBR類似。
根據這些調查結果，我們得出結論認為，對於我們的流量模式，在RTT和損耗較低的情況下，最好使用立方通信進行Pop內通信和Pop到Pop通信。 對於客戶端通信，使用BBR是值得的。
完整彈出測試
為了大規模評估BBR的性能優勢，我們在裡約熱內盧的一家POP對該POP的所有面向客戶端的流量進行了全面POP測試。 這一流行案例研究非常有趣，因爲該地區的位置和對等限制導致客戶所經歷的RTT中位數高於其他地區。
圖5。 使用BBR改善客戶端的吞吐量，因為這顯示高重傳輸(ASN1)。
我們部署了擁塞控制算法的更改並監控了性能。 顯示Rio前兩個ASE (自治系統)使用BBR與立方觀察到的吞吐量CDF。 如圖5所示，一個整體上看到了BBR的好處，另一個則沒有。
為了調查其背後的原因，我們查找了在測試過程中使用ss實用程序收集的其他TCP指標。 這兩個ASE之間的重新傳輸速率有明顯的區別。 即使對於RTT較高的ASS，BBR也只能在重傳次數較高的情況下表現良好，換句話說，對於損失較少的ASS立方沒有理由回退，性能比BBR好。 但是，請務必注意，TCP Cubic的許多參數都已在CDN上仔細調整。
接下來，我們調查了圖5中所示的ASN1的所有連接是否顯示吞吐量有所提高。 圖6是不同對象大小的BBR和立方連接所花費的時間圖(越低意味著吞吐量越高)。 在這裡，我們可以看到BBR只是開始在MBs的順序上顯示較大對象的顯著優勢。 我們確實看到一個使用BBR的異常實例，但無法將其歸咎於任何特定的擁塞控制協議相關問題。
圖6。 對於顯示改進的ASE，BBR的優點在長時間運行的大型文件流中可見。
為什麼會發生這種情況？
這些結果有兩個維度–立方與BBR，BBR與BBR。
立方與BBR
BBR在估算瓶頸帶寬時對緩衝區大小和RTT的反應性很強。 如果緩衝區較大，中間框可能會形成隊列，則BBR的估計RTT會增加。 由於沒有數據包丟失，因此Cubic不會在這種情況下恢復，也就是說，Pop-to-pop類型的通信，因此Cubic可以實現更高的吞吐量。 在小型緩衝區(如無線客戶端)中，緩衝區會快速填充並導致損失–因此立方流量回流，BBR流量性能更好。
BBR與BBR
在這種情況下，當出現損失時，不會出現流回。 但是，當兩個具有不同RTT的流量爭奪一部分帶寬時，具有較高RTT的流量也具有較大的最小RTT，因此具有較高的帶寬延遲產品。 因此，該流以比RTT較低的流更快的速度增加其飛行中的數據。 這會導致以RTT降序重新分配給流量的帶寬，而RTT較高的流量會比RTT較小的流量更快填滿緩衝區。
在實驗室環境中重現結果
為了進一步了解流程之間的交互，我們在虛擬機中創建了一個測試環境，以捕獲我們在生產中看到的行為。 我們確定了在邊緣伺服器上類比不同流量類別的方法，如下所示：
客戶端流量延遲設定為~50ms，損耗範圍為0.001到0.1，瓶頸帶寬為50Mbps。 同樣，對於Pop-to-Pop，僅損耗和延遲設定為~15ms，0.0001至0.01。 對於Pop內流量，我們允許虛擬機最大化可用容量。 最後，我們使用各種大小的對象執行類比，以捕獲流量的多租戶性質。 我們同時執行所有三種流量模式和指數級流量到達，以捕獲Poisson式流量到達分布。 圖7所示為測試臺設定。
此測試的目標是重現我們在生產測試中看到的問題，特別是對於Pop內流量和Pop到Pop的小型RTT流量，吞吐量下降。
圖7。 使用KVM，iperf，netem和tc實用程序進行實驗室設定。
使用此設定，我們使用類比後臺流量(包括立方流量和BBR流量)以及完成流程所需的測量時間執行了數百次類比。 後臺通信的目標是類比生產環境。 許多現有研究都著重於執行幾個立方和BBR流，並評估其行為。 雖然在這些情況下，了解每流行為非常有用，但它很難代表大容量CDN的復雜性。 我們使用客戶端流量完成時間作為可靠的指標，因為對於較小的文件大小，吞吐量可能會產生噪音。
圖8。 iperf流程所需的時間。 左：客戶端流。 右：彈出到彈出流量。 對象大小：3MB。 BBR在類比客戶端流程方面的表現優於Cubic。
我們也看到這個圖案再次出現在我們的測試臺上。 在圖8中，我們顯示了BBR和立方iperf流在兩種情況下所花費的時間的CDF：客戶端流量和3MB (中型)文件的彈出到彈出流量。 在低損耗高帶寬設定中，BBR流量無法達到立方。 客戶端流量(低帶寬)有所改善，即BBR流所花費的時間較短。 但是，小文件的改進很少。 在測試環境中重現這些行為使我們確信它們是不同流類型之間相互作用的結果。 因此，在CDN上部署BBR時，必須了解它可能對混合流類型產生的更廣泛影響。
結論
根據我們的評估，我們發現BBR流量並非在所有情況下都能表現良好。 具體而言，使用BBR時，數據中心/入網點(POP)內的流量和數據中心之間的流量(Pop-to-Pop)流量會受到影響。 在某些極端情況下，吞吐量會減少一半。 但是，我們發現Pop-to-Client流量吞吐量提高了6到8％。
在這篇文章中，我們概述了在CDN上下文中對BBR (版本1)的評估。 我們首先在一個彈出窗口中對幾臺伺服器進行了小測試，並評估了我們作為大型內容提供商感興趣的不同變量。 在大規模的全面POP測試中，我們注意到在重傳率高的ASE中，BBR會有很大的幫助，並建議對於大文件使用BBR是值得的。
我們要從這裏做什麼？
如果我們在系統級別(所有流)啟用BBR，則會面臨Pop內和Pop到Pop通信量降低的風險。
但是，BBR已顯示出潛在的客戶端流量，並且性能良好。 這確實促使我們有選擇地為客戶端啟用BBR，可能從無線提供商開始。 此外，這些路徑的緩衝區較淺，無線損耗也較低，這是BBR比其他立方流量更好的理想情況。
我們希望這一大綱能使我們對大型內容提供商使用BBR及其對可能存在瓶頸的不同類型流量的影響有一些明確的說明。 BBRv2的alpha版本現已推出，該版本應可解決其中一些問題。 我們計劃繼續評估新版本的BBR，並使用智能傳輸控制器，為正確的流量類型選擇合適的擁塞控制。 我們將在未來分享更多有關這方面的詳細資訊。
感謝組織內各團隊的貢獻，使這項分析成為可能！
