許美娟,黃 曄
(1.中國科學院微小衛(wèi)星創(chuàng)新研究院,上海 201203; 2.上海格思信息技術有限公司, 上海 201203)
自從1986年觀察到Internet的擁塞崩潰以來,關于擁塞控制的研究工作一直持續(xù)。TCP擁塞控制具有重要的意義,它可以確保Internet在正常狀態(tài)下工作,并避免再次發(fā)生擁塞崩潰。研究人員提出通過加性增加和乘性減小(AIMD)來調(diào)節(jié)TCP流量的擁塞窗口實現(xiàn)TCP擁塞控制。為了適應某些特定的網(wǎng)絡環(huán)境,通過對基本AIMD控制律進行細微改動,提出了幾種改進算法[1]。隨著互聯(lián)網(wǎng)基礎設施的發(fā)展,這些基于AIMD的速率控制算法的性能不佳。類似于AIMD的算法將數(shù)據(jù)包丟失作為鏈路擁塞的指示,這往往會浪費帶寬。在AIMD算法的啟發(fā)下,又陸續(xù)出現(xiàn)了多種TCP擁塞控制算法,以實現(xiàn)高吞吐量,同時最大限度地減少傳輸延遲。
BBR是Google在2016年發(fā)布的新一代TCP擁塞控制算法,該算法適用于高帶寬離延時的通信鏈路。與其他算法不同的是,BBR算法并不是把丟包作為鏈路擁塞的信號,而是周期性地探測當前通信鏈路的通信延時和帶寬來作為發(fā)送端數(shù)據(jù)發(fā)送窗口的調(diào)整。依據(jù)文獻[2-3]分析其在模擬鏈接或?qū)嶋H網(wǎng)絡測試臺中的行為,這些來自不同來源的實驗說明BBR可以顯著提高TCP連接的吞吐量。BBR已被廣泛應用于構建VPN(虛擬專用網(wǎng)絡),但其應用范圍還不夠廣泛,公平性有局限。在2019年5月,Google以QUIC 3代碼庫發(fā)布了BBR v2[4],其在更為復雜和多樣的網(wǎng)絡環(huán)境中的性能還有待驗證。本文通過模擬網(wǎng)絡環(huán)境實驗,評估了BBR算法及其變體BBR v2的性能。
對 TCP 協(xié)議的擁塞控制機制的改進大致可以分為基于丟包的擁塞控制和基于時延的擁塞控制機制?;趤G包的擁塞控制機制相對較多,典型的有Reno、BIC、Cubic[5-6]等;基于時延的擁塞控制機制,典型的有 Vegas、FAST[7-8]等。
Reno協(xié)議把丟包事件作為網(wǎng)絡擁塞信號。在每個RTT上,Reno發(fā)送方可以向網(wǎng)絡中再注入一個數(shù)據(jù)包,以探測更多可用帶寬。在數(shù)據(jù)包丟失到網(wǎng)絡恢復到正常狀態(tài)時,將擁塞窗口大小減小一半。其對擁塞窗口w()的調(diào)整可總結為式(1),其中α=1和β=0.5。
(1)
Reno 協(xié)議基于丟包反饋機制和AIMD速率調(diào)整算法,但是該算法無法識別錯誤丟包和擁塞丟包。在高速網(wǎng)絡中,一旦發(fā)生丟包,傳統(tǒng)的AIMD算法將需要相當長的時間才能恢復到擁塞窗口,然后再采取乘數(shù)減少操作,這樣造成Reno算法帶寬資源利用率低。
在BIC中,通過二進制搜索的方法進行積極的帶寬窗口探測。wmax是上一次快速恢復之前的擁塞窗口,BIC同Reno算法一樣,也采用乘法減小的方式減小窗口,減小后的窗口為wmin。對于鏈路當前最佳擁塞窗口的區(qū)間范圍為wmin Cubic是BIC的更新版本,引入了三次函數(shù)用于窗口調(diào)整。 由于其擁塞窗口的增加僅取決于2個連續(xù)擁塞事件之間的時間,因此可以解決RTT不公平問題。Cubic算法比AIMD具有更好的性能,并且到目前為止,它一直是Linux網(wǎng)絡堆棧中的默認配置。 基于延遲的算法可以防止隊列建立,充分利用信道資源并保持吞吐量穩(wěn)定性。一旦延遲超過某個閾值,將減少擁塞窗口以緩解擁塞。Vegas、FAST這類算法可以實現(xiàn)相當?shù)偷年犃姓加?,但當與基于丟包的算法共享鏈接時,它也會處于劣勢。由于這個原因,它沒有在實際網(wǎng)絡中廣泛應用。 BBR (Bottleneck Bandwidth and Round-trip propagation time)是TCP中一種新的擁塞控制機制[9],不再把丟包作為擁塞產(chǎn)生的信號。在BBR中,當發(fā)出新的數(shù)據(jù)包時,將記錄數(shù)據(jù)包狀態(tài)信息(接收的字節(jié)數(shù);數(shù)據(jù)包確認時間)。發(fā)送端維持一個長度為10×RTT時間窗口,通道帶寬BW是10個RTT內(nèi)的最大帶寬(BtlBW,Bottleneck Bandwidth),發(fā)送端維持一個長度為10 s 的時間窗口,將期間所觀察到的RTT測量值中的最小值作為傳播往返時間(RTTp)。通過上述方式,發(fā)送端用短時間內(nèi)傳輸?shù)臄?shù)據(jù)量Δdeliveded和傳輸時間來不斷地測量網(wǎng)絡的傳輸速率速率sending_Rate,可以按照公式(2)和(3)計算新的帶寬估計樣本。BBR協(xié)議根據(jù)測量到的BW和RTT調(diào)整發(fā)送端速率sending_Rate。 (2) sending_Rate=Pacing_gain*Bwbtl (3) BBR中有4個控制狀態(tài)StartUp、Drain、ProbeBW和ProbeRTT。BBR通過Pacing方式控制發(fā)送速率,增益系數(shù)G作用是調(diào)整Pacing。在每個控制狀態(tài)中,數(shù)據(jù)包發(fā)送速率是增益系數(shù)G和BW的乘積。StartUp狀態(tài)與TCP傳統(tǒng)擁塞控制中的緩慢啟動過程非常相似,Pacing_gain為2/ln2,以使每個RTT上的鏈路數(shù)據(jù)包加倍,讓發(fā)送方探測最大可用帶寬。當新估算的帶寬小于之前的帶寬1.25倍,并且這種情況持續(xù)3次時,狀態(tài)變?yōu)椤癉rain”狀態(tài)。Drain的Pacing_gain為ln2/2,以將發(fā)送速率降低到BW以下。 直到鏈路數(shù)據(jù)包與BDP匹配(BW*RTTmin),狀態(tài)從Drain更改為ProbeBW。在ProbeBW狀態(tài)期間,cwnd設置為2*BDP,Pacing增益為8個周期(kPacingGain[]=[1.25;0.75;1;1;1;1;1;1])。如果在10 s內(nèi)未再次采樣RTTmin,則認為鏈路陷入了擁塞狀態(tài),并進入ProbeRTT狀態(tài)。cwnd設置為4*MSS,ProbeRTT最多將持續(xù)200 ms。 在ProbeRTT中,運行中的數(shù)據(jù)包幾乎完全從鏈路中耗盡,開始對新的RTTmin值進行采樣。 BBR以估算的全部帶寬發(fā)送數(shù)據(jù)包,并且未用數(shù)據(jù)包丟失作為鏈路擁塞指示。如果瓶頸處的隊列長度小于1.5 BDP,多個BBR流將會導致高丟包率。而BBR v2[10]為了解決BBR中問題,將數(shù)據(jù)包丟失納入其控制邏輯中。添加了從StartUp到Drain的丟包條件:一輪丟包數(shù)超過8或丟包率(loss_threshold)超過0.02,施加這種條件避免了過多的分組丟失。在ProbeBW狀態(tài)下,BBR v2的工作機制與BBR 完全不同。探測階段周期(探測上升probe_up,探測下降probe_down,探測巡航probe_cruise)的切換不再取決于RTTmin的時間間隔。cwnd也未設置為2*BDP,而是增加了2個門限值inflight_lo和inflight_hi。如果有關丟包的條件成立,則將計算出的BDP分配給inflight_hi,當前網(wǎng)絡進入危險區(qū)域。并且inflight_lo值也會根據(jù)丟包的比例來動態(tài)調(diào)整。 在ns3[11-14]平臺上評估了Cubic、BBR、BBR v2算法的基本性能,構建的實驗拓撲圖如圖1所示。為了測試該算法是否可以保證帶寬的分配屬性,從發(fā)送端到接收端創(chuàng)建了3個流,在瓶頸帶寬為5 Mb/s、單向延遲100 ms、最大隊列長度300 ms的場景下,分別部署不同的TCP擁塞控制協(xié)議。在每種運行情況下,這些流都遵循相應的速率控制算法。 圖1 實驗拓撲Fig.1 Experimental topology 在發(fā)送方,當可以發(fā)送新數(shù)據(jù)包時,將跟蹤擁塞控制器的速率。數(shù)據(jù)包的發(fā)送時間被標記為數(shù)據(jù)包對象,便于計算接收方到計算機的單向傳輸延遲。除了單向延遲之外,在接收側(cè),還記錄接收到的分組的長度。 實時吞吐率變化如圖2所示,BBR傾向于對啟動狀態(tài)期間的帶寬進行過度估計,這樣的速率峰值將導致網(wǎng)絡擁塞并引入數(shù)據(jù)包丟失。BBR v2流可以保持良好的帶寬分配公平性。在BBR v2中,速率調(diào)整非常頻繁,探測更多帶寬與避免鏈路擁塞之間取得平衡。Cubic吞吐率在2 Mb/s上下波動,遠低于物理帶寬,因為發(fā)送端在探測到丟包時,速率會大幅度減速,傳輸速率受到鏈路丟包率的影響,Cubic的帶寬搶占性不如BBR和BBR v2。 圖2 實時吞吐率變化Fig.2 Real-time throughput rate change graph 在實驗中,計算每個實驗中所有數(shù)據(jù)流的傳輸延遲的結果如圖3所示。關于丟包率的結果如圖4所示。 圖3 數(shù)據(jù)流的傳輸延遲Fig.3 Transmission delay of data stream 圖4 不同協(xié)議的丟包率對比Fig.4 Comparison of packet loss rates of different protocols Cubic算法的平均傳輸延時比較高,BBR和BBR v2在起始階段傳輸延時基本一致,BBR的延時波動比較大,后期兩者延時波動基本同步。BBR在起始階段搶占帶寬,會導致丟包率相對較高,在后期進入穩(wěn)定階段,丟包率維持穩(wěn)定, BBR v2可以實現(xiàn)比較低平均丟包率。 RTT公平性是指不同協(xié)議間的公平性,本文主要對BBR、BBR v2、Cubic 三種協(xié)議之間的RRT公平性進行分析[15]。 評價實驗在RTT為不同的環(huán)境下,部署B(yǎng)BR、BBR v2、Cubic協(xié)議,2個流分別為flow 1 和flow 2,每次測試2個流的傳輸速率,模擬的運行時間持續(xù)200 s。整體的吞吐量的平均值由公式(4)計算。 bytes是所有接收到的數(shù)據(jù)包的長度。公平指數(shù)jainfis被用來表明當爭奪帶寬資源時帶寬共享的公平性[15]。jainfis公平指數(shù)的計算方法如公式(5)。J的公平性指數(shù)越接近1,就帶寬分配公平性而言就越好。 (4) (5) 根據(jù)表1可以得出BBR v2和Cubic的公平性要好于BBR,在第2種環(huán)境中, BBR flow2的吞吐量是flow1 的將近4倍。隨著RTT比率在不同情況下變小,2種流量的比率越來越近,jainfis的公平性也提高了。RTT不公平的原因與中間路由器中的鏈路占用有關。當瓶頸已經(jīng)很擁擠時,具有大RTT的流將發(fā)送更多的數(shù)據(jù)包,與具有較短RTT流的流相比,它將獲得更大的帶寬。 表1 RTT不公平模擬仿真的計算結果Tab.1 Simulation results of RTT unfairness 在實際網(wǎng)絡中,遵循不同的擁塞控制算法,多路流量會復用一個瓶頸鏈路。BBR v2的目標之一就是與Cubic和Reno 更好地共存。實驗測試當BBR,BBR v2和cubic流分別共存時,這些算法的性能。flow1在實驗中代表Cubic,flow2在不同的實驗中分別代表BBR,BBR v2。具體實驗結果見表2。在Cubic和BBR共存中,大多數(shù)帶寬被flow2占用。第一個測試案例中公平指數(shù)很低,吞吐率很高。隨著鏈接緩沖區(qū)的增加,Cubic流可以實現(xiàn)更高的吞吐量,但flow2所代表的BBR流吞吐量仍占主導地位。當BBR v2流與Cubic流共享瓶頸鏈路時,公平值非常接近1,BBR v2協(xié)議間公平性更好。 表2 不同協(xié)議之間的公平性Tab.2 Fairness between different agreements 通過建立數(shù)據(jù)傳輸實驗場景,對BBR和BBR v2擁塞控制算法運行效果進行仿真,與Cubic協(xié)議進行對比分析。在鏈路搶占性方面,BBR和BBR v2搶占性較強,吞吐量明顯高于Cubic,在延時和丟包率方面也均有較好的性能。BBR v2在BBR協(xié)議的基礎上有很大改進,BBR可通過調(diào)節(jié)帶寬探測方式提高RTT公平性,同時在高帶寬時進一步提高協(xié)議之間公平性。BBR v2協(xié)議可以引用ECN參數(shù)指標,以適應不同的網(wǎng)絡環(huán)境、保持不同流量間的平衡。1.2 BBR
1.3 BBR v2
2 實驗仿真與評估
2.1 協(xié)議內(nèi)部公平性
2.2 RTT公平性
2.3 協(xié)議間公平性
3 結語