,,

(中南大學(xué) 信息科學(xué)與工程學(xué)院,長沙 410083)

0 概述

近年來,Web搜索、Google文件系統(tǒng)(Google File System,GFS)[1]、Hadoop文件系統(tǒng)(Hadoop File System,HDFS)[2]等網(wǎng)絡(luò)應(yīng)用在數(shù)據(jù)中心廣泛部署。而傳統(tǒng)的TCP不能很好地適應(yīng)數(shù)據(jù)中心網(wǎng)絡(luò)高帶寬、低延時(shí)的環(huán)境[3]。在數(shù)據(jù)中心分散聚合的通信模式[4]中,高并發(fā)TCP流到達(dá)瓶頸鏈路時(shí),由于交換機(jī)緩沖區(qū)溢出會(huì)造成丟包。而如果此時(shí)TCP快速重傳機(jī)制不能成功重傳丟失的數(shù)據(jù)包,則需要等待200 ms的超時(shí)時(shí)間(Retransmission Time Out,RTO),遠(yuǎn)大于數(shù)據(jù)中心網(wǎng)絡(luò)微秒級的往返時(shí)延(Round-Trip Time,RTT),造成長時(shí)間的鏈路空閑。同時(shí)在分散聚合中,新的數(shù)據(jù)請求必須等待上一輪數(shù)據(jù)請求處理完成,即僅當(dāng)客戶端接收到所有并發(fā)服務(wù)器的服務(wù)器請求單元(Server Request Unit,SRU)[5]時(shí),才可發(fā)送下一請求。因此,個(gè)別流超時(shí)拖尾會(huì)導(dǎo)致之后所有請求的等待,引起TCP Incast吞吐率崩潰[6]。

目前,Incast問題的主要解決思路是通過顯式擁塞反饋(Explicit Congestion Notification,ECN)[7]、RTT測量等推測網(wǎng)絡(luò)擁塞狀態(tài),以減小服務(wù)器端擁塞窗口來降低并發(fā)TCP流的發(fā)送速率和Incast事件發(fā)生的概率。例如DCTCP[8]、D2TCP[9]和L2TCP[10]協(xié)議利用ECN反饋擁塞狀況,并調(diào)節(jié)服務(wù)器端發(fā)送速率。TIMELY[11]、ICTCP[12]等探索RTT的測量方式進(jìn)行擁塞窗口的調(diào)節(jié)。但這些方法存在一個(gè)共同問題:調(diào)節(jié)TCP流的傳輸速率并不能有效緩解瞬時(shí)高并發(fā)傳輸突發(fā)造成的網(wǎng)絡(luò)擁塞。當(dāng)高并發(fā)TCP流同時(shí)開始發(fā)送數(shù)據(jù)時(shí),即使每條流的擁塞窗口已經(jīng)降低到最小值,大量并發(fā)流瞬時(shí)突發(fā)的數(shù)據(jù)流量仍然容易造成大量丟包[13]。如果并發(fā)傳輸流隨機(jī)退避發(fā)送就能有效降低瞬時(shí)突發(fā)流量,相對于降低擁塞窗口方法能大幅降低超時(shí)事件的發(fā)生概率。

本文提出高并發(fā)TCP的隨機(jī)退避方法(Random Backoff TCP,RBTCP)。各服務(wù)器在隨機(jī)等待一定的時(shí)間后開始進(jìn)行數(shù)據(jù)傳輸,控制進(jìn)入瓶頸鏈路的瞬時(shí)數(shù)據(jù)量,避免Incast吞吐率崩塌。

1 協(xié)議設(shè)計(jì)

設(shè)計(jì)目的是緩解高并發(fā)TCP的吞吐量崩塌。設(shè)計(jì)要點(diǎn)是計(jì)算最優(yōu)的隨機(jī)退避時(shí)間區(qū)間,保證各并發(fā)服務(wù)器的發(fā)送時(shí)間在時(shí)間區(qū)間內(nèi)隨機(jī)退避,既避免TCP Incast事件的發(fā)生,又能獲得較高的網(wǎng)絡(luò)吞吐率。

1.1 設(shè)計(jì)思想

本文的設(shè)計(jì)思路是通過隨機(jī)退避避免高并發(fā)TCP流的突發(fā)擁塞,圖1對比了采用RBTCP隨機(jī)退避方法前后的效果。圖1(a)顯示n臺服務(wù)器同時(shí)發(fā)送時(shí),交換機(jī)緩存被占滿并使得數(shù)據(jù)包大量溢出,有可能發(fā)生全窗丟包,導(dǎo)致超時(shí)。而圖1(b)顯示采用隨機(jī)退避后,各服務(wù)器隨機(jī)推遲數(shù)據(jù)包的開始傳輸時(shí)間,各流在[0,t]內(nèi)隨機(jī)選取開始時(shí)間,降低了并發(fā)程度,減緩了數(shù)據(jù)包同時(shí)涌向瓶頸鏈路引發(fā)的突發(fā)交換機(jī)緩存擁塞。

圖1 傳輸過程示意圖

1.2 超時(shí)概率分析

本節(jié)從理論上分析具體的TCP Incast發(fā)生概率P與隨機(jī)時(shí)間區(qū)間t取值的關(guān)系。其中,TCP擁塞窗口全窗丟包是造成Incast發(fā)生的主要原因[14],因此從全窗丟包的概率來分析t取值的影響。

在典型的數(shù)據(jù)中心多對一場景中[15],當(dāng)服務(wù)器并發(fā)傳輸時(shí),瓶頸鏈路可以容納的數(shù)據(jù)包數(shù)為交換機(jī)緩沖區(qū)大小B與在RTT時(shí)間內(nèi)可處理的數(shù)據(jù)包數(shù)C×RTT的和(單位為包數(shù)量)。而若每臺服務(wù)器的傳輸開始時(shí)間在[0,t]內(nèi)隨機(jī)取值,則鏈路可容納的數(shù)據(jù)包數(shù)為B+C×t。因此在隨機(jī)退避方法中,單臺服務(wù)器出現(xiàn)丟包的概率為1-(C×t+B)/nw。

由于超時(shí)產(chǎn)生的原因是服務(wù)器端窗口整窗丟失,因此超時(shí)概率p為:

(1)

其中,w是擁塞窗口的大小。當(dāng)至少有1臺服務(wù)器出現(xiàn)超時(shí)時(shí),就會(huì)發(fā)生TCP Incast現(xiàn)象。因此可得到n臺服務(wù)器發(fā)生Incast的概率P為:

(2)

式(2)表明:P的大小受t值的影響,隨著t取值的增大,發(fā)生TCP Incast的概率會(huì)減小。為了避免最大擁塞窗口下發(fā)生超時(shí),依據(jù)各流數(shù)據(jù)量大小Y來計(jì)算w的最大值。據(jù)統(tǒng)計(jì),目前數(shù)據(jù)中心絕大部分流是小數(shù)據(jù)流,能在慢啟動(dòng)階段內(nèi)完成傳輸[16]。因此,假設(shè)每臺并發(fā)服務(wù)器都以慢啟動(dòng)的指數(shù)方式從初始窗口2開始增長窗口。當(dāng)傳輸數(shù)據(jù)大小為Y時(shí),需要經(jīng)過的RTT輪數(shù)k是:

k=?lb(Y+1)」

(3)

那么在最后一輪RTT內(nèi),每一臺服務(wù)器發(fā)送的最大擁塞窗口數(shù)為:

w=2k=2?lb(Y+1)」-1

(4)

依據(jù)式(2)和式(4),得到如圖2所示的變化趨勢:隨著t的增大,發(fā)生Incast現(xiàn)象的概率P逐漸降低。當(dāng)t增大到一定程度時(shí),P會(huì)接近到0。所以,如果僅從不發(fā)生吞吐量崩塌的角度來看,t的取值越大越好。

圖2 P值變化曲線

1.3 隨機(jī)退避時(shí)間區(qū)間

首先,用仿真實(shí)驗(yàn)測試不同t下的吞吐率。其中吞吐率是所有流的總吞吐率。仿真使用NS2測試,將DCTCP作為傳輸層協(xié)議,包大小為1.5 KB,鏈路帶寬為1 Gb/s,RTT為200 μs,交換機(jī)緩存大小和標(biāo)記門限值分別為80和20。

如圖3(a)所示,固定SRU大小為128 KB,當(dāng)并發(fā)服務(wù)器數(shù)量分別為40、60、80時(shí),可以看出:隨著t的增大,吞吐率逐漸升高,并達(dá)到一個(gè)最大值,此時(shí)若t值在小范圍內(nèi)增加,則吞吐率會(huì)維持在一個(gè)較高水平,近似等于最大值。而若t繼續(xù)增大,那么吞吐率呈現(xiàn)近似直線下降的趨勢。

如圖3(b)所示,固定服務(wù)器數(shù)量為60,當(dāng)SRU取32 KB、64 KB、128 KB時(shí),同樣得到最優(yōu)的t。且SRU為128 KB所需的隨機(jī)退避時(shí)間區(qū)間大于SRU為64 KB、32 KB時(shí),這是因?yàn)?28 KB數(shù)據(jù)所能達(dá)到的最大窗口數(shù)較大。而隨著窗口的增加,擁塞程度會(huì)不斷增加,較大的t值才能避免超時(shí)事件的發(fā)生。

總體上,圖3說明不同的網(wǎng)絡(luò)參數(shù)設(shè)置下,均存在最優(yōu)t值使得吞吐率最高。

圖3 不同時(shí)間區(qū)間的吞吐量變化

接下來,計(jì)算最優(yōu)的隨機(jī)退避時(shí)間區(qū)間t。當(dāng)發(fā)送的數(shù)據(jù)量小于瓶頸鏈路可容納數(shù)據(jù)量時(shí),將網(wǎng)絡(luò)吞吐率G表示為nw/(B+C×t),反之,則n條流的平均發(fā)送起始時(shí)間間隔為t/2。網(wǎng)絡(luò)的有效吞吐率G可以歸一化為:

(5)

將在不同的并發(fā)度場景下計(jì)算關(guān)于G的變化曲線,G值最高時(shí)對應(yīng)的t值就是最優(yōu)的隨機(jī)退避時(shí)間區(qū)間取值。以下分2種情況分析G的變化趨勢:

(6)

首先分析P隨t增加的變化趨勢,對P求導(dǎo)為:

(7)

而式(6)中,1-(RTT+t/2)/RTO同樣是關(guān)于t的減函數(shù),可得出:G隨著t的增大而增大。

依據(jù)式(5),得到如圖4中G隨著t的變化趨勢。與上述分析相同,圖4中G是關(guān)于t的先增后減函數(shù)。此時(shí),頂點(diǎn)處的隨機(jī)退避時(shí)間區(qū)間取值為(n×w-B)/C。

圖4 G值變化曲線

最后,將式(4)中的w值代入到頂點(diǎn)t中可得到最優(yōu)的時(shí)間區(qū)間取值為:

(8)

由式(8)可得出,隨機(jī)退避時(shí)間t*隨著n的增加而不斷增大,在重負(fù)載情況下,由式(8)計(jì)算最優(yōu)的t*,各流在t*內(nèi)隨機(jī)退避。當(dāng)n值很大時(shí),TCP流的并行傳輸將變?yōu)榻咏诖袀鬏斠员苊獬瑫r(shí)事件的發(fā)生。

1.4 協(xié)議實(shí)現(xiàn)

在RBTCP協(xié)議實(shí)現(xiàn)中主要包括以下2個(gè)要點(diǎn):

1)并發(fā)服務(wù)器數(shù)量n的評估:依據(jù)TCP的SYN和FIN信息,在交換機(jī)上統(tǒng)計(jì)n。因?yàn)楫?dāng)交換機(jī)收到一個(gè)SYN或FIN時(shí),就表明n的值加1或減1[17]。同時(shí),交換機(jī)可通過ACK攜帶方式將n傳輸給服務(wù)器端。

2)隨機(jī)退避的實(shí)現(xiàn):在每個(gè)并發(fā)服務(wù)器端加入一個(gè)定時(shí)器,TCP三次握手收到連接成功后,開啟該定時(shí)器。根據(jù)式(8)計(jì)算退避時(shí)間區(qū)間t,并在[0,t]區(qū)間內(nèi)取一個(gè)隨機(jī)值作為定時(shí)器超時(shí)時(shí)間。當(dāng)定時(shí)器超時(shí)后,服務(wù)器開始數(shù)據(jù)傳輸。

2 性能分析

本節(jié)基于DCTCP協(xié)議,測試網(wǎng)絡(luò)吞吐率。測試中,采用典型的數(shù)據(jù)中心多對一的拓?fù)?多臺服務(wù)器通過一個(gè)交換機(jī)瓶頸傳輸SRU給客戶端。同時(shí)SRU大小設(shè)置為10 KB～128 KB,將交換機(jī)緩存大小設(shè)置為64 packet/s。

2.1 基礎(chǔ)性能結(jié)果

通過吞吐率和交換機(jī)緩存隊(duì)列的變化,分析對比網(wǎng)絡(luò)的整體性能。

圖5說明當(dāng)服務(wù)器數(shù)量大于30時(shí),DCTCP協(xié)議發(fā)生了吞吐量崩塌現(xiàn)象。而RBTCP的吞吐率即使是在n增至70時(shí),仍然保持了很高的網(wǎng)絡(luò)吞吐率。這說明RBTCP的隨機(jī)退避方法在整個(gè)傳輸過程中避免了超時(shí)現(xiàn)象,保證了瓶頸鏈路滿帶寬的利用。并且,RBTCP將并發(fā)度提升了2倍,其原因在于超時(shí)引發(fā)的Incast發(fā)生之后,吞吐率會(huì)降低數(shù)倍,而RBTCP在2倍的并發(fā)度下仍能避免Incast事件的發(fā)生以致吞吐率下降。但這并不意味著每條流的吞吐率均增加,而是總體吞吐率由于避免Incast問題,可維持在較高水平。

圖5 吞吐率情況對比

如圖6所示,40臺服務(wù)器發(fā)送數(shù)據(jù)到緩存區(qū)大小為64個(gè)數(shù)據(jù)包,數(shù)據(jù)包迅速地占滿交換機(jī)緩存,隨后出現(xiàn)超時(shí)現(xiàn)象等待了200 ms才進(jìn)行剩余數(shù)據(jù)的傳輸。而RBTCP協(xié)議則以較為平緩的方式填充交換機(jī)緩沖區(qū),并且整個(gè)傳輸過程中隊(duì)列長度總是小于緩沖區(qū)大小,說明隨機(jī)退避方法可避免超時(shí),并達(dá)到接近于滿帶寬的傳輸效果。

圖6 隊(duì)列情況對比

2.2 改變流大小性能對比

本節(jié)測試SRU大小下使用DCTCP和RBTCP協(xié)議的吞吐率變化情況。

圖7(a)中n臺并發(fā)服務(wù)器分別發(fā)送32 KB、64 KB、100 KB。從圖7(a)可看出,隨著n的增大,RBTCP協(xié)議發(fā)送不同大小的SRU,吞吐率均可維持接近于滿帶寬的傳輸;而使用DCTCP協(xié)議會(huì)在n為30左右時(shí)即出現(xiàn)吞吐量崩塌現(xiàn)象。說明RBTCP可適應(yīng)不同大小的SRU場景,保持較高的網(wǎng)絡(luò)吞吐率。

在圖7(b)中,分別測試SRU大小不同(在10 KB～128 KB之間隨機(jī)選取)時(shí),DCTCP和RBTCP的吞吐率。從圖7(b)可看出,RBTCP隨著n的增加可維持較高的吞吐率。但是,由于每臺服務(wù)器根據(jù)其自身SRU計(jì)算一個(gè)時(shí)間區(qū)間,很大概率會(huì)出現(xiàn):SRU較小的服務(wù)器集中先發(fā)送,SRU較大的服務(wù)器會(huì)等待較長的時(shí)間才發(fā)送,因此,不能達(dá)到滿帶寬的傳輸效果,但亦可確保不發(fā)生吞吐量崩塌,將吞吐率維持在一個(gè)較穩(wěn)定的狀態(tài)。

圖7 吞吐率情況

2.3 不同場景性能對比

為了評估在數(shù)據(jù)中心典型應(yīng)用場景下,隨機(jī)退避方法的性能,選擇Web Search和Map Reduce場景進(jìn)行測試。

Web Search應(yīng)用場景固定傳輸數(shù)據(jù)總量為500 KB,各服務(wù)器發(fā)送數(shù)據(jù)量相等。從圖8可看出,在Web Search場景中,DCTCP協(xié)議傳輸下,在小并發(fā)(n=30)的情況下就出現(xiàn)了Incast事件,吞吐量崩塌,降低到100 Mb/s以下。而當(dāng)n大于30時(shí),RBTCP的吞吐率波動(dòng)不是很大,基本可維持在滿帶寬水平,比DCTCP提升86倍左右。RBTCP相對于DCTCP吞吐率的增加是由于各流隨機(jī)退避發(fā)送時(shí),避免了超時(shí)引發(fā)的各流本身鏈路帶寬的空閑。所以,當(dāng)與其他流有競爭時(shí),RBTCP仍會(huì)退避本身流的發(fā)送而非搶占其他流的帶寬。

圖8 Web Search流量模型

圖9表明在Map Reduce應(yīng)用場景下,固定并發(fā)服務(wù)器傳輸數(shù)據(jù)量SRU大小為64 KB,增加服務(wù)器并發(fā)數(shù)量,使用RBTCP協(xié)議相比DCTCP在吞吐率方面仍有大幅度的提升。同樣,這種優(yōu)勢在當(dāng)并發(fā)服務(wù)器數(shù)量增加時(shí),將更加明顯。

圖9 Map Reduce流量模型

3 結(jié)束語

針對數(shù)據(jù)中心高帶寬、低延時(shí)的特點(diǎn),本文分析大并發(fā)量數(shù)據(jù)同時(shí)到達(dá)瓶頸鏈路造成超時(shí),并引發(fā)吞吐量崩塌的關(guān)鍵原因。為緩解高并發(fā)TCP的吞吐量崩塌,提出隨機(jī)退避方法,通過在最優(yōu)的時(shí)間區(qū)間內(nèi)隨機(jī)取值來確定每個(gè)并發(fā)服務(wù)器的開始傳輸時(shí)間,減少同一時(shí)刻到達(dá)瓶頸鏈路的數(shù)據(jù)包數(shù)量,降低交換機(jī)緩沖區(qū)溢出的概率。實(shí)驗(yàn)結(jié)果表明,該方法有效地避免了吞吐量崩潰現(xiàn)象,并使得DCTCP的并發(fā)度和吞吐率分別提升2倍和86倍。下一步將繼續(xù)研究隨機(jī)退避方法在不同網(wǎng)絡(luò)拓?fù)浜途W(wǎng)絡(luò)環(huán)境中具備普適性的協(xié)議。

[1] GHEMAWAT S,GOBIOFF H,LEUNG S T.The Google file system[C]//Proceedings of the 19th ACM Symposium on Operating Systems Principles.New York,USA:ACM Press,2003:29-43.

[2] BORTHAKUR D.The Hadoop distributed file system:architecture and design[J].Hadoop Project Website,2007,11(11):1-10.

[3] LIU Fangming,GUO Jian,HUANG Xiaomeng,et al.eBA:efficient bandwidth guarantee under traffic variability in datacenters[J].IEEE/ACM Transactions on Networking,2017,25(1):506-519.

[4] HUANG Jiawei,HE Tian,HUANG Yi,et al.ARS:cross-layer adaptive request scheduling to mitigate TCP incast in data center networks[C]//Proceedings of the 35th Annual IEEE International Conference on Computer Communications.Washington D.C.,USA:IEEE Press,2016:1-9.

[5] LUO Jintang,YANG Xiaolong,XU Jie,et al.AAIC:adaptive-sliding-connection-window solution to TCP incast from application layer[J].IEEE Communications Letters,2016,20(10):1967-1970.

[6] REN Yongmao,ZHAO Yu,LIU Pei,et al.A survey on TCP incast in cata center networks[J].International Journal of Communication Systems,2014,27(8):1160-1172.

[7] BAI Wei,CHEN Li,CHEN Kai,et al.Enabling ECN in multi-service multi-queue data centers[C]//Proceedings of the 13th USENIX Symposium on Networked Systems Design and Implementation.New York,USA:ACM Press,2016:537-549.

[8] ALIZADEH M,GREENBERG A,MALTZ D A,et al.Data center TCP(DCTCP)[J].ACM SIGCOMM Computer Communication Review,2010,40(4):63-74.

[9] VAMANAN B,HASAN J,VIJAYKUMAR T N.Deadline-aware datacenter TCP (D2TCP)[J].ACM SIGCOMM Computer Communication Review,2012,42(4):115-126.

[10] MUNIR A,QAZI I A,UZMI Z A,et al.Minimizing flow completion times in data centers[C]//Proceedings of INFOCOM’2013.Washington D.C.,USA:IEEE Press,2013:2157-2165.

[11] MITTAL R,DUKKIPATI N,BLEM E,et al.TIMELY:RTT-based congestion control for the datacenter[J].ACM SIGCOMM Computer Communication Review,2015,45(4):537-550.

[12] WU Haitao,FENG Zhenqian,GUO Chuanxiong,et al.ICTCP:incast congestion control for TCP in data-center networks[J].IEEE/ACM Transactions on Networking,2013,21(2):345-358.

[13] ALIZADEH M,ATIKOGLU B,KABBANI A,et al.Data center transport mechanisms:congestion control theory and IEEE standardization[C]//Proceedings of the 46th Annual Allerton Conference on Communica-tion,Control,and Computing.Washington D.C.,USA:IEEE Press,2008:1270-1277.

[14] ZHANG Shuli,ZHANG Yan,QIN Yifang,et al.OSDT:a scalable application-level scheduling scheme for TCP incast problem[C]//Proceedings of IEEE International Con-ference on Communications.Washington D.C.,USA:IEEE Press,2015:325-331.

[15] 李 丹,陳貴海,任豐原,等.數(shù)據(jù)中心網(wǎng)絡(luò)的研究進(jìn)展與趨勢[J].計(jì)算機(jī)學(xué)報(bào),2014,37(2):259-274.

[16] CHEN Yanpei,GRIFFITH R,LIU Junda,et al.Under-standing TCP incast throughput collapse in datacenter networks[C]//Proceedings of the 1st ACM Workshop on Research on Enterprise Networking.New York,USA:ACM Press,2009:73-82.

[17] HUANG Jiawei,HUANG Yi,WANG Jianxin,et al.Packet slicing for highly concurrent TCPs in data center networks with COTS switches[C]//Proceedings of the 23rd International Conference on Network Protocols.Washington D.C.,USA:IEEE Press,2015:22-31.