數(shù)據(jù)中心網(wǎng)絡中多種TCP擁塞控制算法的性能研究

陳雷明，顏金堯,安站東

(1.中國傳媒大學 信息工程學院，北京 100024；2.陽泉煤業(yè)集團機電動力部，山西陽泉 045000)

數(shù)據(jù)中心網(wǎng)絡中多種TCP擁塞控制算法的性能研究

陳雷明1，顏金堯1,安站東2

(1.中國傳媒大學 信息工程學院，北京 100024；2.陽泉煤業(yè)集團機電動力部，山西陽泉 045000)

數(shù)據(jù)中心網(wǎng)絡中的TCP擁塞控制算法的研究一直是學術界的熱點，大多數(shù)論文是在啞鈴型拓撲中進行分析的，而數(shù)據(jù)中心中常用網(wǎng)絡架構有：three-tier，F(xiàn)at-tree、BCube、DCel和VL2。本文研究分析在Fat-tree拓撲中三種類型的TCP(基于ECN的DCTCP，基于丟包的Reno、NewReno、Cubic、Sclable和基于RTT的Vegas)的性能，從隊列長度、丟棄的數(shù)據(jù)包數(shù)量、吞吐量和數(shù)據(jù)包的平均端到端時延等方面進行綜合評估。本文結合ECN控制方法，來改善多種TCP在數(shù)據(jù)中心網(wǎng)絡中出現(xiàn)的問題。經(jīng)過大量實驗分析得出ECN控制方法可以減少TCP的時延和丟包、減輕交換機隊列擁擠，并且發(fā)現(xiàn)結合ECN的Cubic可以獲得比DCTCP更好的綜合性能。

數(shù)據(jù)中心網(wǎng)絡；TCP擁塞控制算法；Fat-tree拓撲；顯示擁塞通知

1 引言

傳輸控制協(xié)議(TCP)的可擴展性和魯棒性通過其在網(wǎng)絡中的主導作用已經(jīng)得到證明，其擁塞控制算法有助于網(wǎng)絡環(huán)境的穩(wěn)定。然而，隨著現(xiàn)代網(wǎng)絡環(huán)境(諸如衛(wèi)星網(wǎng)絡和數(shù)據(jù)中心網(wǎng)絡)的出現(xiàn)，每個具有不同特征的網(wǎng)絡技術的發(fā)展已經(jīng)對完善的TCP提出了挑戰(zhàn)。

經(jīng)過大量的測量顯示，數(shù)據(jù)中心網(wǎng)絡(DCN)內的絕大部分流量可以分成三種不同的類型。查詢流的流量很小，通常小于100Kbytes，主要來自需要快速響應的應用程序，例如百度搜索和移動終端APP或電腦軟件更新的提交。這種流容易在多條流同時經(jīng)過某個交換機時因交換機緩存空間不足而導致分組部分或者完全丟棄，影響用戶體驗。第二種類型的TCP流是延遲敏感的短流量，其大小在100Kbytes到5Mbytes之間，例如由微博、微信等應用生成。第三種TCP流是由軟件更新等應用程序生成的大小超過5Mbytes的吞吐量敏感的長流。數(shù)據(jù)中心還需要處理來自內部或者另一個數(shù)據(jù)中心的數(shù)據(jù)流，例如用戶使用數(shù)據(jù)云業(yè)務時。

DCN中的一直存在丟包，隊列擁擠和緩沖壓力問題[1]。當很多業(yè)務流到達相同的輸出端口時因隊列溢出而出現(xiàn)數(shù)據(jù)包丟棄，而當貪婪的長流占據(jù)大部分瓶頸隊列緩沖空間時，出現(xiàn)緩沖壓力問題，對于查詢流量幾乎沒有留下空間，導致分組被丟棄。 DCN中的TCP的眾多缺點促使開發(fā)了多種TCP變體以解決TCP問題，包括DCTCP，ICTCP和D2TCP。然而，這些TCP變體是以一般廣域網(wǎng)絡中的缺點為對比來展示他們的優(yōu)點。對于DCN的理想擁塞控制應該能夠有效地利用可用的網(wǎng)絡帶寬，并且讓數(shù)據(jù)包經(jīng)過小緩存的交換機時具有較小的等待時間。還需要考慮其他設計約束，如可擴展性，魯棒性和部署復雜性。此外，作為端到端算法，協(xié)議應能夠在商品交換機的全部潛力下與商品交換機協(xié)作，而不需要修改網(wǎng)絡設備。本文認為，需要在對現(xiàn)有TCP的全面理解的基礎上對每個新的TCP變式進行研究，以便在不重復改進的情況下獲得更好的解決方案。不幸的是，研究界仍然缺乏在現(xiàn)代網(wǎng)絡環(huán)境中對常規(guī)TCP擁塞控制算法的這種全面的比較研究。

2 數(shù)據(jù)中心的擁塞控制算法

對于數(shù)據(jù)中心網(wǎng)絡，之前被部署在其他網(wǎng)絡環(huán)境中的成熟的TCP擁塞控制算法都表現(xiàn)平平，主要是數(shù)據(jù)中心網(wǎng)絡使用具有非常小的緩存的商品交換機，高速鏈路和低往返時延。這種特殊的要求和數(shù)據(jù)中心應用程序的要求與廣域網(wǎng)的差異很大；數(shù)據(jù)中心應用程序會產生突發(fā)查詢流量，延遲的敏感短流量和吞吐密集型長流量，并且通常具有嚴格的流量完成時間的要求。

2.1 傳統(tǒng)擁塞控制算法

本文研究的傳統(tǒng)TCP主要分為兩類：基于丟包反饋的Reno，NewReno，Cubic和Scalable，基于RTT反饋的Vegas。每種TCP都有不同的設計思想和適合它們的網(wǎng)絡環(huán)境。

Reno是在Tahoe算法的基礎之上加入了快速恢復階段，但Reno只考慮了每次網(wǎng)絡擁塞發(fā)生時只丟棄一個數(shù)據(jù)包的情況。NewReno是在Reno的基礎之上對快速恢復算法進行了改進，增加了對恢復應答執(zhí)行預先判斷的功能，以增強發(fā)送端通過ACK分析數(shù)據(jù)包傳輸情況的能力。Cubic設計時使用了一個三次函數(shù)來調整擁塞窗口[2]，Cubic的窗口增長函數(shù)僅僅取決于連續(xù)的兩次擁塞丟包事件的時間間隔之差，這樣Cubic窗口增長與網(wǎng)絡中的時延RTT大小無關。Scalable TCP(STCP)是面向高帶寬時延乘積的TCP新算法，以穩(wěn)定性著稱，其基本思想是網(wǎng)絡中擁塞情況發(fā)生后快速恢復階段所需要的時間與擁塞窗口值是相互獨立的。Vegas是一種基于RTT的擁塞控制算法，基本思想是：首先設置一個閾值，計算當前網(wǎng)絡中實際吞吐量的大小和網(wǎng)絡所期望的吞吐量的大小，如果兩者之差大于所設置的閾值就認為網(wǎng)絡中出現(xiàn)擁塞，馬上主動減小發(fā)送端的發(fā)送速率；如果兩者之差小于這個閾值，就認為網(wǎng)絡環(huán)境沒有出現(xiàn)擁塞，擁塞窗口還可以繼續(xù)增長。

2.2 DCTCP擁塞控制算法

DCTCP是為數(shù)據(jù)中心網(wǎng)絡環(huán)境設計的新算法，是基于顯示擁塞反饋和主動隊列管理算法RED相結合的一種擁塞控制機制[3-4]。該算法的部署需要三方面的共同實現(xiàn)。

2.2.1 交換機標記。

在RED中設置一個閾值K，如果瞬時隊列的長度超過K，則超過的數(shù)據(jù)包的IP頭部的CE位都會被標記為1，否則不標記。發(fā)送端通過接收端反饋回來的ACK就可以知道交換機隊列的占有率情況?，F(xiàn)如今大部分商用交換機已經(jīng)實現(xiàn)了RED算法，DCTCP正好利用了這一點，只需要在RED中同時設置高門限值和低門限值同時為K。

2.2.2 接收端ECN-Echo(ECE)

在接收端收到來自發(fā)送端的窗口減小確認信息(TCP頭部的CWR位被置1)之前，接收端如果發(fā)現(xiàn)數(shù)據(jù)包的IP頭部CE位為1，就繼續(xù)將ACK數(shù)據(jù)包的ECE位標記為1，以此繼續(xù)告訴發(fā)送端網(wǎng)絡中出現(xiàn)了擁塞。

2.2.3 發(fā)送端的控制器

發(fā)送端不斷更新一個用來評估被標記數(shù)據(jù)包比重的參數(shù)，每個RTT內更新一次，公式如下所示：

α=(1-g)*α+g*F

(1)

式中，F(xiàn)是最后一個數(shù)據(jù)窗口中被標記的數(shù)據(jù)包的比重，g(0

(2)

Alizade等人的論文中表明，當K值大于時延帶寬乘積的17%就能實現(xiàn)95%以上的吞吐量。

2.3 顯示擁塞控制通知

顯示擁塞控制通知(ECN)機制[5]的實現(xiàn)是需要和RED算法配合使用的，其控制的基本思想是：當路由器和交換機等網(wǎng)絡設備出現(xiàn)早期擁塞情況時，不是按照RED的算法計算出丟包概率來丟棄數(shù)據(jù)包，而是盡量對數(shù)據(jù)包進行標記。

(1)IP對ECN的支持。IP頭部一般有20個字節(jié)的空間，從IP頭部的第8位開始到第15位為服務類型區(qū)域，共有8位，其中6-7位預留未使用。在RFC2481文檔中建議使用這預留未用的兩bit作為ECN區(qū)域。第一個bit為ECN-Capable Transport(ECT)位，表示該TCP協(xié)議支持ECN擁塞通知，第二個bit為Congestion Experience(CE)位，表示數(shù)據(jù)包正經(jīng)歷擁塞。RFC3168文檔中提出，用組合形式“00”表示不支持ECN，用組合“01”和“10”表示支持ECN，使用“11”組合表示數(shù)據(jù)包正在經(jīng)歷擁塞。

(2)TCP對ECN的支持。ECN使用TCP頭部的CWR(Congestion Window Reduced)和ECE(ECE-Echo)兩位。根據(jù)RFC3168建議，如果發(fā)送端和接收端都需要使用ECN機制，則在TCP初始化時，發(fā)送端在發(fā)送的TCP頭部設置ECE位和CWR位均為1，以表示TCP協(xié)議支持ECN機制。接收端收到這個TCP包后返回ECE=1、CWR=0的ACK確認信息。最后發(fā)送端再一次向接收端發(fā)送一個應答包，完成TCP鏈接的三次握手，支持ECN的TCP鏈接建立完成。

3 TCP擁塞控制算法的分析與改進

本章選用數(shù)據(jù)中心網(wǎng)絡中的DCTCP和其他網(wǎng)絡環(huán)境中的TCP(reno、newreno、cubic、scalable、vegas)，通過多次實驗詳細分析它們各自在Fat-tree拓撲中的性能表現(xiàn)，根據(jù)實驗獲得的數(shù)據(jù)從四個方面進行比較評估它們的性能：丟包數(shù)量、數(shù)據(jù)包的平均端到端時延、網(wǎng)絡中瓶頸鏈路總的吞吐量和處于網(wǎng)絡鏈路瓶頸的核心交換機的瞬時隊列長度。

然后，本章應用ECN控制方法來改善各類TCP在數(shù)據(jù)中心網(wǎng)絡中的性能，并從隊列長度、丟棄的數(shù)據(jù)包數(shù)量、吞吐量和數(shù)據(jù)包的平均端到端時延等方面對ECN-TCP進行綜合評估。

3.1 實驗拓撲和參數(shù)設置

本實驗使用k=4的Fat-tree拓撲，使用網(wǎng)絡模擬軟件NS-2在Ubuntu14.04系統(tǒng)環(huán)境中進行模擬實驗仿真，搭建的拓撲如圖1所示，拓撲中編號為4-15的12個主機作為數(shù)據(jù)發(fā)送端，編號為0的主機作為數(shù)據(jù)接收端。圖1為12條TCP流同時發(fā)送數(shù)據(jù)。

圖1 12條TCP流的模擬仿真圖

實驗過程中沒有設置固定的網(wǎng)絡鏈路丟包率。由于試驗中往返時延很短，所有的TCP流在很短的時間內即可達到穩(wěn)定狀態(tài)，設置的仿真時間為10秒。表1中展示了試驗中的一些關鍵參數(shù)的設置。

表1 實驗仿真參數(shù)

3.2 TCP性能分析

本次實驗仿真六種不同的TCP，設置了六組實驗，每一組都使用相同的TCP。為了了解不同數(shù)量的TCP流對TCP 性能的影響情況，每組實驗等間隔設置四種不同數(shù)量的TCP流：3條TCP流、6條TCP流、9條TCP流和12條TCP流。每組試驗我們都采取多次測量求組平均值作為最終的結果，以防止個別實驗特殊情況的發(fā)生，減小實驗誤差。

1.端到端時延。六種TCP的數(shù)據(jù)包的平均端到端時延如圖2所示，DCTCP的數(shù)據(jù)包的平均端到端時延一直很低，基本維持在0.5 ms左右；Vegas的數(shù)據(jù)包的平均端到端時延從3條TCP流時的0.5 ms逐漸增加到12條TCP流時的約1 ms，增長近一倍，而且在3條TCP流時還低于DCTCP；Reno和NewReno的數(shù)據(jù)包的平均端到端時延很接近，基本維持在4 ms，幾乎是DCTCP的7倍、Vegas的4倍；Scalable的數(shù)據(jù)包的平均端到端時延基本在4.5—4.7 ms之間；Cubic是最高的，是DCTCP的近10倍。所有TCP的平均端到端時延隨著TCP流的增加都有不同程度的增加。由于TCP流增多，但是鏈路資源有限，不同流之間的競爭就增加，各自爭搶網(wǎng)絡資源，網(wǎng)絡出現(xiàn)丟包的概率就增加，TCP擁塞控制算法進入擁塞避免階段、快速恢復階段和快速重傳階段的次數(shù)就增多，每條流的平均吞吐量就會降低。從平均端到端時延可以看出，DCTCP擁塞控制算法的優(yōu)勢是很明顯的。

圖2 TCP數(shù)據(jù)包的平均端到端時延變化

2.吞吐量。不同數(shù)量TCP流的核心交換機的吞吐量變化，如圖3所示。其中DCTCP、Cubic、Scalable、Vegas的吞吐量很接近，Reno的吞吐量稍微低一些，NewReno的吞吐量最低，但是值得稱贊的是六種TCP的瓶頸處的吞吐量都能達到鏈路的95%以上。隨著TCP流的增加，每種TCP的吞吐量都有少許的增加，但是每條流的平均吞吐量肯定是逐漸減小的。

圖3 六種TCP的吞吐量變化

3.丟包數(shù)量。六種TCP的不同鏈接數(shù)量的丟包數(shù)量的變化，如圖4所示。DCTCP和Vegas的丟包數(shù)量都為0。其他四種TCP都是基于丟包的擁塞控制算法，Scalable和Cubic的丟包最為嚴重，Reno和NewReno相對最少。隨著TCP流的增加，瓶頸處交換機的隊列更加擁擠，丟包數(shù)量也是逐漸增加的，這一點和端到端時延、吞吐量一樣。

圖4 六種TCP的丟包情況

4.核心交換機隊列瞬時長度。圖5-7分別展示了DCTCP、Vegas、Cubic在12條TCP流時的核心交換機瞬時隊列的長度。其中DCTCP設置的K=20，從圖5可以看出，其隊列長度維持在20上下；Vegas的隊列長度維持在50以下。DCTCP和Vegas在緩存空間為400個數(shù)據(jù)包的情況下都能保持較低的隊列，零丟包，時延也很低，但是在TCP流數(shù)量增加到一定程度后隊列長度就會很高，接近交換機緩存的空間大小，這時隊列排隊時延和丟包率都會很大。而Reno、NewReno、Cubic、Scalable的隊列長度一直很高，因緩存空間溢出而出現(xiàn)大量丟包，圖7給出了Cubic的隊列長度。

圖5 DCTCP在12條數(shù)據(jù)流時的隊列長度

圖6 Vegas在12條數(shù)據(jù)流時的隊列長度

圖7 Cubic在12條數(shù)據(jù)流時的隊列長度

3.3 基于ECN的TCP性能改進

鑒于DCTCP在數(shù)據(jù)中心網(wǎng)絡中的優(yōu)點，本節(jié)把顯示擁塞通知(ECN)機制應用在Reno、NewReno、Cubic、Scalable和Vegas上(分別稱為ECN-Reno、ECN-NewReno、ECN-Cubic、ECN-Scalable和ECN-Vegas)，以緩解瓶頸處核心交換機的隊列擁擠和丟包問題。

本次實驗的拓撲結構如圖1所示。實驗中12個主機連續(xù)的發(fā)送12條長TCP流到同一個接收端。實驗中的TCP擁塞控制算法使用DCTCP、Reno、NewReno、Cubic、Scalable和Vegas，ECN閾值K選取1和10-100共11個不同值。

實驗結果中六種TCP的丟包數(shù)量均為0，解決了網(wǎng)絡中丟包的問題，下面從數(shù)據(jù)包的平均端到端時延、總的吞吐量和交換機瞬時隊列長度三個角度進行性能分析。

1.數(shù)據(jù)包的平均端到端時延：如圖8所示，K=1時除了ECN-Scalable高于0.4ms之外，其他五種ECN-TCP都低于0.4ms，而且大小很接近。隨著閾值K的增加，各ECN-TCP的端到端時延逐漸增加。DCTCP幾乎呈線性增加，且在K大于30以后，DCTCP的時延一直是最大的，主要是因為其隊列維持在K±10左右，而其他TCP隊列從接近于0到K+10幅度變化范圍比較大，隊列空閑比DCTCP多一些，時延也就小了一些。ECN-Vegas在閾值K大于30以后，時延增長幅度變緩，尤其在K大于50之后，時延是最低的，主要是ECN-Vegas隊列在K大于30后，隊列一直維持在30-40附近，這和Vegas基于RTT的擁塞控制機制是密不可分的[6]。和圖2相比，ECN機制在降低時延方面的優(yōu)勢非常明顯。

圖8 DCTCP和ECN-TCP在不同K值時的時延

2.總的吞吐量：如圖9所示，ECN-Scalable的吞吐量一直是最高的，吞吐率都在95%以上，這主要是因為Scalable在處理丟包時快速恢復階段所需要的時間與擁塞窗口值是相互獨立的[7]，擁塞窗口很快就能恢復到丟包前的大小，實現(xiàn)高吞吐率。DCTCP在K為1時也能實現(xiàn)93%的鏈路利用率，K大于10以后就能實現(xiàn)95%的鏈路利用率。另外四種ECN-TCP在K=1時鏈路利用率都很低，直到K大于70時鏈路利用率才能達到95%。和非ECN相比，合適的閾值使得各TCP的最高吞吐量相差不多，所以，當選擇合適的閾值K時，是否使用ECN機制對它們的吞吐量影響很小。

圖9 DCTCP和ECN-TCP在不同K值時的吞吐量

3.交換機瞬時隊列長度：圖10-14展示了五種ECN-TCP在K=20時的交換機瞬時隊列長度的變化情況，DCTCP見圖5所示。ECN-Cubic的瞬時隊列維持在K+30以內，且變化幅度較大，其他ECN-TCP的瞬時隊列基本在K+10以下。在緩存空間在400個最大數(shù)據(jù)包情況下，各ECN-TCP都能保持較低的瞬時隊列長度，緩解了隊列擁擠，實現(xiàn)了零丟包，增加了應對突發(fā)TCP流的能力。

從以上三方面的綜合分析可以看出，傳統(tǒng)TCP結合ECN機制后，使用合適的閾值K(大約20)，在丟包、時延、交換機隊列擁擠等方面都具有很明顯的改進，實現(xiàn)了零丟包、低時延、低隊列，同時又能達到95%以上的鏈路利用率。綜合時延和吞吐量特性，ECN-Cuibic時延相對DCTCP較低而吞吐量相近，因此本文認為結合ECN的Cubic可以獲得比DCTCP更好的綜合性能。

4 結論

本文以應用于數(shù)據(jù)中心網(wǎng)絡中的Fat-tree拓撲為架構，從丟包數(shù)量、數(shù)據(jù)包的平均端到端時延、總的吞吐量和核心交換機瞬時隊列長度四個方面對DCTCP、Reno、NewReno、Cubic、Scalable、Vegas等六種TCP擁塞控制算法進行了綜合性能評估?？梢缘贸觯贓CN的DCTCP和基于RTT的Vegas在各方面的變現(xiàn)均很出色，而基于丟包的Reno、NewReno、Cubic和Scalable各自爭奪網(wǎng)絡資源而出現(xiàn)比較嚴重的丟包、隊列擁擠和較高的端到端時延，不滿足數(shù)據(jù)中心網(wǎng)絡環(huán)境的特點和需求。

圖10-14 ECN-TCP的核心交換機隊列

為了改善傳統(tǒng)TCP在數(shù)據(jù)中心網(wǎng)絡中的性能，本文將DCTCP中的ECN機制應用到其他五種TCP來嘗試解決傳統(tǒng)TCP出現(xiàn)的問題，通過大量實驗驗證ECN-Reno、ECN-NewReno、ECN-Cubic和ECN-Scalable在處理丟包和時延方面都有很明顯的改善，丟包問題解決，而且合適的閾值K也能使得端到端時延控制在1ms左右，同時還能達到95%左右的吞吐量，基本滿足數(shù)據(jù)中心網(wǎng)絡對TCP的各方面的要求，甚至綜合性能可以超過DCTCP。

[1]Truck Anh N Nguyen，Siddharth Gangadhar. Performance Evaluation of TCP Congestion Control Algorithms in Data Center Networks [J]. CFI’16，June，15-17，ACM，2016.

[2]S Ha，I Rhee，L Xu. CUBIC：A New TCP-friendly High-speed TCP Variant[J]. SIGOPS Oper Syst Rev，42(5)：64-74，July，2008.

[3]M Alizadeh，A Greenberg，D A Maltz，J Padhye，P Patel，B Prabhakar，S Sengupta，M Sridharan. Data center TCP(DCTCP)[J]. In Proceedings of SIGCOMM’10，63-74，New York，NY，USA，2010 ACM.

[4]M Alizadeh，A Javanmard，B Prabhakar.Analysis of DCTCP：Stability，Convergence and Fairness [J].Proceedings of the ACM SIGMETRICS，Joint International Conference on Measurement and Modeling of Computer Systems，ser SIGMETRICS’11，New York，USA：ACM，2011，73-84.

[5]K Ramakrishnan，S Floyd，D Black. RFC 3168：the addition of explicit congestion notification(ECN)to IP [S].

[6]L Brakmo，S O’Malley，L Peterson. TCP Vegas：New techniques for congestion detection and avoidance [J]. In SIGCOMM，1994.

[7]T Kelly. Scalable TCP：Improving performance in highspeed wide area networks [J]. ACM SIGCOMM Computer Communication Review(CCR)，33(2)：83，2003.

(責任編輯：宋金寶)

ResearchonPerformanceofManyTCPCongestionControlAlgorithmsinDataCenterNetwork

CHEN Lei-ming1，YAN Jin-yao1，AN Zhan-dong2

(1.School of Information Engineering，Communication University of China，Beijing 100024，China；2.Department of Electronic Mechanical and Power，Yangquan coal Industry Group，Shanxi Yangquan 045000，China)

The study of TCP congestion control algorithm in data center network has always been a hot topic in academia. Most of the papers are analyzed in dumbbell topology. The common network architectures in the data center are：three-tier，F(xiàn)at-tree，BCube，DCel and VL2. This paper investigates the performance of three types of TCP(ECN-based DCTCP，loss-based Reno，NewReno，Cubic，Sclable，and delay-based Vegas)in the Fat-tree topology，and evaluated in terms of queue length，number of dropped packet，throughput and average packet end-to-end delay. This paper combines ECN control methods to improve the various TCP in the data center network problems. After a large number of experimental analysis，ECN control method can reduce TCP delay and packet loss，reduce the switch queue congestion，and the combination of ECN Cubic can get better than DCTCP comprehensive performance.

DCN；TCP congestion control algorithms；Fat-tree；ECN

TP393.05

A

1673-4793(2017)05-0037-08

2017-06-20

陳雷明(1987 -)，男(漢族)，山東人，中國傳媒大學碩士研究生.E-mail：chenlm28@163.com