陳雷明，顏金堯,安站東

(1.中國傳媒大學(xué) 信息工程學(xué)院，北京 100024；2.陽泉煤業(yè)集團(tuán)機(jī)電動(dòng)力部，山西陽泉 045000)

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

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

(1.中國傳媒大學(xué) 信息工程學(xué)院，北京 100024；2.陽泉煤業(yè)集團(tuán)機(jī)電動(dòng)力部，山西陽泉 045000)

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

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

1 引言

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

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

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

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

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

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

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

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

2.2 DCTCP擁塞控制算法

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

2.2.1 交換機(jī)標(biāo)記。

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

2.2.2 接收端ECN-Echo(ECE)

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

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

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

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

(1)

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

(2)

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

2.3 顯示擁塞控制通知

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

(1)IP對ECN的支持。IP頭部一般有20個(gè)字節(jié)的空間，從IP頭部的第8位開始到第15位為服務(wù)類型區(qū)域，共有8位，其中6-7位預(yù)留未使用。在RFC2481文檔中建議使用這預(yù)留未用的兩bit作為ECN區(qū)域。第一個(gè)bit為ECN-Capable Transport(ECT)位，表示該TCP協(xié)議支持ECN擁塞通知，第二個(gè)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機(jī)制，則在TCP初始化時(shí)，發(fā)送端在發(fā)送的TCP頭部設(shè)置ECE位和CWR位均為1，以表示TCP協(xié)議支持ECN機(jī)制。接收端收到這個(gè)TCP包后返回ECE=1、CWR=0的ACK確認(rèn)信息。最后發(fā)送端再一次向接收端發(fā)送一個(gè)應(yīng)答包，完成TCP鏈接的三次握手，支持ECN的TCP鏈接建立完成。

3 TCP擁塞控制算法的分析與改進(jìn)

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

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

3.1 實(shí)驗(yàn)拓?fù)浜蛥?shù)設(shè)置

本實(shí)驗(yàn)使用k=4的Fat-tree拓?fù)?，使用網(wǎng)絡(luò)模擬軟件NS-2在Ubuntu14.04系統(tǒng)環(huán)境中進(jìn)行模擬實(shí)驗(yàn)仿真，搭建的拓?fù)淙鐖D1所示，拓?fù)渲芯幪?hào)為4-15的12個(gè)主機(jī)作為數(shù)據(jù)發(fā)送端，編號(hào)為0的主機(jī)作為數(shù)據(jù)接收端。圖1為12條TCP流同時(shí)發(fā)送數(shù)據(jù)。

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

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

表1 實(shí)驗(yàn)仿真參數(shù)

3.2 TCP性能分析

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

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

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

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

圖3 六種TCP的吞吐量變化

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

圖4 六種TCP的丟包情況

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

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

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

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

3.3 基于ECN的TCP性能改進(jìn)

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

本次實(shí)驗(yàn)的拓?fù)浣Y(jié)構(gòu)如圖1所示。實(shí)驗(yàn)中12個(gè)主機(jī)連續(xù)的發(fā)送12條長TCP流到同一個(gè)接收端。實(shí)驗(yàn)中的TCP擁塞控制算法使用DCTCP、Reno、NewReno、Cubic、Scalable和Vegas，ECN閾值K選取1和10-100共11個(gè)不同值。

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

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

圖8 DCTCP和ECN-TCP在不同K值時(shí)的時(shí)延

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

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

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

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

4 結(jié)論

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

圖10-14 ECN-TCP的核心交換機(jī)隊(duì)列

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

(責(zé)任編輯：宋金寶)

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 -)，男(漢族)，山東人，中國傳媒大學(xué)碩士研究生.E-mail：chenlm28@163.com