數據中心網絡中高并發TCP傳輸的隨機退避方法

,,

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

0 概述

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

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

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

1 協議設計

設計目的是緩解高并發TCP的吞吐量崩塌。設計要點是計算最優的隨機退避時間區間,保證各并發服務器的發送時間在時間區間內隨機退避,既避免TCP Incast事件的發生,又能獲得較高的網絡吞吐率。

1.1 設計思想

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

圖1 傳輸過程示意圖

1.2 超時概率分析

本節從理論上分析具體的TCP Incast發生概率P與隨機時間區間t取值的關系。其中,TCP擁塞窗口全窗丟包是造成Incast發生的主要原因[14],因此從全窗丟包的概率來分析t取值的影響。

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

由于超時產生的原因是服務器端窗口整窗丟失,因此超時概率p為:

(1)

其中,w是擁塞窗口的大小。當至少有1臺服務器出現超時時,就會發生TCP Incast現象。因此可得到n臺服務器發生Incast的概率P為:

(2)

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

k=?lb(Y+1)」

(3)

那么在最后一輪RTT內,每一臺服務器發送的最大擁塞窗口數為:

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

(4)

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

圖2 P值變化曲線

1.3 隨機退避時間區間

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

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

如圖3(b)所示,固定服務器數量為60,當SRU取32 KB、64 KB、128 KB時,同樣得到最優的t。且SRU為128 KB所需的隨機退避時間區間大于SRU為64 KB、32 KB時,這是因為128 KB數據所能達到的最大窗口數較大。而隨著窗口的增加,擁塞程度會不斷增加,較大的t值才能避免超時事件的發生。

總體上,圖3說明不同的網絡參數設置下,均存在最優t值使得吞吐率最高。

圖3 不同時間區間的吞吐量變化

接下來,計算最優的隨機退避時間區間t。當發送的數據量小于瓶頸鏈路可容納數據量時,將網絡吞吐率G表示為nw/(B+C×t),反之,則n條流的平均發送起始時間間隔為t/2。網絡的有效吞吐率G可以歸一化為:

(5)

將在不同的并發度場景下計算關于G的變化曲線,G值最高時對應的t值就是最優的隨機退避時間區間取值。以下分2種情況分析G的變化趨勢:

(6)

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

(7)

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

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

圖4 G值變化曲線

最后,將式(4)中的w值代入到頂點t中可得到最優的時間區間取值為:

(8)

由式(8)可得出,隨機退避時間t*隨著n的增加而不斷增大,在重負載情況下,由式(8)計算最優的t*,各流在t*內隨機退避。當n值很大時,TCP流的并行傳輸將變為接近于串行傳輸以避免超時事件的發生。

1.4 協議實現

在RBTCP協議實現中主要包括以下2個要點:

1)并發服務器數量n的評估:依據TCP的SYN和FIN信息,在交換機上統計n。因為當交換機收到一個SYN或FIN時,就表明n的值加1或減1[17]。同時,交換機可通過ACK攜帶方式將n傳輸給服務器端。

2)隨機退避的實現:在每個并發服務器端加入一個定時器,TCP三次握手收到連接成功后,開啟該定時器。根據式(8)計算退避時間區間t,并在[0,t]區間內取一個隨機值作為定時器超時時間。當定時器超時后,服務器開始數據傳輸。

2 性能分析

本節基于DCTCP協議,測試網絡吞吐率。測試中,采用典型的數據中心多對一的拓撲,多臺服務器通過一個交換機瓶頸傳輸SRU給客戶端。同時SRU大小設置為10 KB～128 KB,將交換機緩存大小設置為64 packet/s。

2.1 基礎性能結果

通過吞吐率和交換機緩存隊列的變化,分析對比網絡的整體性能。

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

圖5 吞吐率情況對比

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

圖6 隊列情況對比

2.2 改變流大小性能對比

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

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

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

圖7 吞吐率情況

2.3 不同場景性能對比

為了評估在數據中心典型應用場景下,隨機退避方法的性能,選擇Web Search和Map Reduce場景進行測試。

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

圖8 Web Search流量模型

圖9表明在Map Reduce應用場景下,固定并發服務器傳輸數據量SRU大小為64 KB,增加服務器并發數量,使用RBTCP協議相比DCTCP在吞吐率方面仍有大幅度的提升。同樣,這種優勢在當并發服務器數量增加時,將更加明顯。

圖9 Map Reduce流量模型

3 結束語

針對數據中心高帶寬、低延時的特點,本文分析大并發量數據同時到達瓶頸鏈路造成超時,并引發吞吐量崩塌的關鍵原因。為緩解高并發TCP的吞吐量崩塌,提出隨機退避方法,通過在最優的時間區間內隨機取值來確定每個并發服務器的開始傳輸時間,減少同一時刻到達瓶頸鏈路的數據包數量,降低交換機緩沖區溢出的概率。實驗結果表明,該方法有效地避免了吞吐量崩潰現象,并使得DCTCP的并發度和吞吐率分別提升2倍和86倍。下一步將繼續研究隨機退避方法在不同網絡拓撲和網絡環境中具備普適性的協議。

[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] 李 丹,陳貴海,任豐原,等.數據中心網絡的研究進展與趨勢[J].計算機學報,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.