數據中心網絡中任務感知的傳輸控制協議

,,

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

0 概述

近年來,隨著網絡帶寬的飛速提升,在線搜索、社交網絡、電子商務等網絡應用得到了飛速發展和普及,越來越多的在線應用系統被遷移到數據中心網絡(Data Center Network,DCN)[1],利用大規模的計算和存儲資源來為用戶提供各種服務[2]。數據中心網絡中的應用任務包含一組相互獨立卻擁有共同目標的數據流,這些數據流中拖尾流的完成時間決定整個任務的完成時間。而數據中心網絡中數據傳輸的時延是影響DCN中應用性能至關重要的一部分[2]。Facebook的日志文件表明數據傳輸占據了整個應用處理時間的33%[3]。因此,能否提高DCN傳輸性能將極大影響用戶體驗。

為了提升DCN應用中的網絡傳輸性能,國內外學者做出了很多研究。最初的方案是基于數據流級別的延時敏感傳輸協議,這類協議以優化流級別平均完成時間作為目標。文獻[4-6]通過RTT的測量來檢測擁塞以調節擁塞窗口。這類協議需要準確探知鏈路的往返時間(Round Trip Time,RTT)或者鏈路RTT的變化情況?；陲@式擁塞反饋(Explicit Congestion Notification,ECN)的協議DCTCP[7]、D2TCP[8]和 L2DCT[9]等利用ECN標記來更準確地反饋鏈路擁塞狀態,從而調節發送速率[10]。然而,這些協議僅專注于流級別的數據傳輸控制,忽略了同一任務內的數據流具有共同目標的特性,降低了應用任務的性能。

針對以上問題,文獻[11]假設已有任務的先驗信息,利用中央調度器進行集中調度,提出最小瓶頸優先調度算法和MADD帶寬分配算法,實現了近乎完美的調度系統。但是需要實時的網絡全局信息,調度開銷很大。文獻[12]通過分布式系統進行任務調度,避免了額外的通信開銷,并且提出了FIFO-LM的調度算法,改變了傳統FIFO的調度模式,極大地避免了線頭阻塞。文獻[13]依據任務在集群中已發送的字節數更新coflow[14]在發送端的優先級隊列,在不知道數據流先驗知識的條件下實現了D-CLAS[13](Discretized Coflow-aware Least-attained Service)策略。而文獻[15]首次提出在應用透明的情況下,通過自動鑒別對任務進行調度。CODA利用數據流的一些特定屬性,計算某2條數據流的屬性距離。如果小于特定的值,就認為這2條屬于一個任務,通過綁定來減小鑒別任務大小不準確造成的影響。這些協議雖然通過任務感知進行優化,在一定程度上提升了任務級別的應用性能,但是難以實現且部署代價太大。

本文提出一種對任務大小及流拖尾程度感知的TCP擁塞控制協議TLDCT。在任務內部,減小所有數據流中拖尾流的完成時間,加速任務的完成時間。在任務之間感知任務大小,通過協議設計使得小任務優先,旨在減少平均任務完成時間。

1 問題分析

為了分析提升任務完成時間的關鍵因素,從DCN中應用任務的大小感知和任務內部流拖尾兩個方面進行分析,探究對任務平均完成時間的影響。

1.1 任務大小感知

在網絡中存在分屬于任務A和任務B的4條流,所有流同時到達,如圖1(a)所示。獨占帶寬時所需要的完成時間分別是3、3、3、1個單位。圖1(b)是基于流公平共享帶寬時,各數據流完成過程的時序圖。此時,網絡中所有未完成的流獲得同樣的帶寬,流[fA1,fA2,fB1,fB2]將在[6,4,6,2]時刻完成,因此任務A和任務B都在6時刻完成。采用至少達到服務(Least Attained Service,LAS)策略[16]的時序圖如圖1(c)所示。由于LAS為最少服務流最高的服務優先級,fA和fB也都在6時刻才完成。而采用任務大小感知策略則能有效減小平均任務完成時間。如圖1(d)所示,平均任務完成時間花費了5個單位時間。

圖1 已發送任務大小感知動機

任務感知策略相比于公平共享策略和LAS策略降低了20%的完成時間。因此,為了最小化平均任務完成時間,當小任務和大任務在同一個瓶頸時,優先小任務的傳輸有利于減少小任務等待的時間,從而也能減小平均任務完成時間。

1.2 任務內部流拖尾感知

由于任務由一組單獨的數據流組成,其完成時間由所有數據流中最后一條流的完成時間決定。

如圖2(a)所示,在同一個瓶頸交換機下的任務A包含2條流fA1和fA2,跟背景流fB競爭瓶頸傳輸數據。fA1、fA2和fB在獨占帶寬的情況下分別需要[1,2,3]個單位時間完成。fB和fA1在0時刻同時開始傳輸,fA2在1時刻開始傳輸。圖2(b)為采用公平共享帶寬策略時,fA1和fA2分別在2.5和5.5時刻完成,所以任務完成需要5.5個單位時間。采用LAS策略的時序圖如圖2(c)所示,fA和fB分別在3和5時刻完成。如圖2(d)所示,在任務內部流拖尾程度感知的情況下,任務內部發送速率快的流將一部分帶寬讓給發送速率慢的流,則2條流都在4.75時刻完成。這相比于公平共享策略和LAS策略將任務完成時間降低了15%和5.2%。

圖2 拖尾流感知動機

2 協議設計

DCN中應用執行的任務具有多樣性、復雜性和未知性。設計是針對DCN中未知先驗知識的任務,將從區分任務大小和感知任務內部拖尾流程度2個部分來降低任務的平均完成時間。綜合這2個部分提出降低平均任務完成時間的傳輸控制協議TLDCT。

2.1 任務大小因子和拖尾因子

為了控制任務的傳輸速率,定義了一個任務傳輸速率控制因子β,其計算如式(1)。其中,St表示任務已發送字節數,taskmin和taskmax是任務已發送字節數的最大最小門限值。任務傳輸速率控制因子β隨著任務已發送字節數變化。β初始值為0.5;當任務已發送字節數超過taskmin時,β呈線性上升;當任務已發送字節數超過最大門限taskmax時,β為1.5。文獻[17]分析了Web搜索應用的任務流量模型。其中約82%任務大小都分布在47 KB左右,而大約15%的任務遠大于100 KB。在這種流量模型下,將taskmin和taskmax分別設置為47 KB和100 KB。

(1)

另一方面,為了控制任務內部的流傳輸速率,定義了任務內部流傳輸速率控制因子γ,其計算公式如式(2)。其中,Sf表示流已發送字節數,St表示任務已發送字節數,n表示任務內部的流數目。任務內部流傳輸速率控制因子γ由該流已發送字節數和它所屬任務的平均每條流已發送字節數的差值除以該流已發送字節數決定,在數值小于0時歸一到0值。

(2)

2.2 詳細設計

本節詳細闡述TLDCT協議在發送端、接收端的設計部署。TLDCT協議基于DCTCP協議擴展,利用ECN標記動態反饋鏈路擁塞狀況。

接收方收到發送方的握手包,獲取握手包中所攜帶的任務id號,并查詢是否已經接收過同一id號的任務子流。若已接收過,就將該任務子流數目n加1。若初次收到該任務,初始化變量St和n,記錄已發送字節數和任務子流數目n,令St=0,n=1。接收方收到數據包時就更新對應任務的St值。在收到關閉連接的FIN包時就將對應的n減1,直到n等于0時釋放存儲空間St和n。接收方在向發送方發送ACK時,將St和n值寫入到ACK確認包TCP頭部32 bit的選項字段中返回給發送方。

發送方收到當前發送窗口內的全部確認包ACK之后,依據擁塞標志位被標記的ACK數量計算擁塞程度:

(3)

其中,cwnd是當前發送窗口大小,m是當前發送窗口中擁塞標志位被標記的ACK包數量,αn表示當前數據包往返周期的擁塞度(α0=0),αn-1表示上一個數據包往返周期的擁塞度,g表示滑動平均權值。接收方在收到本輪窗口最后一個數據包的ACK包后,獲得ACK中的任務已發送字節數St和任務中流條數n,利用式(1)計算得到任務大小因子。接收方在每次收到數據包的ACK時需要更新已確認發送字節數Sf,利用式(2)求出流的拖尾因子。

發送方通過之前計算出來的α、β、γ更新當前發送窗口cwnd:

(4)

3 性能評估

利用NS2模擬器對TLDCT協議以及DCTCP協議、L2DCT協議和Baraat進行基礎性能對比測試。然后針對大規模場景,評估TLDCT協議。根據數據中心網絡中的應用任務大小分布情況[17],約82%任務大小都分布在47 KB左右,而剩下約18%的任務都遠大于100 KB。因此,將式(1)中的taskmin和taskmax分別設置為47 KB和100 KB。

3.1 基礎性能測試

從區分任務大小和感知任務內部拖尾流程度2個部分來測試協議性能。實驗拓撲為多對一模型[9]。

3.1.1 區分任務大小性能對比

圖3比較了DCTCP、L2DCT、Baraat和TLDCT的大任務和小任務數據量在不同比值情況下的平均任務完成時間。實驗包含3組比值,從圖3可見,因為TLDCT加速了小任務的發送速率,減小了小任務等待傳輸的時間,最終降低了平均任務完成時間。其中,隨著大小任務的數據量差距增加,TLDCT的收益越明顯。例如,在大小任務數據量之比為2∶5的實驗中,TLDCT的平均任務完成時間相比于DCTCP和L2DCT分別減少了17.5%和16.8%,僅比Baraat增多了8.7%。Baraat雖然取得了最好的性能,但其也帶來極大的分布式部署開銷。

圖3 加速小任務完成時間對比

3.1.2 感知拖尾流性能對比

圖4顯示了DCTCP、L2DCT、Baraat和TLDCT任務內部出現拖尾流的平均任務完成時間。每個任務中的數據流開始發送數據的相差時間分別在20 ms、50 ms、100 ms服從均勻分布。圖4顯示,相比于DCTCP和L2DCT,TLDCT的平均任務完成時間有所降低。隨著時間間隔加大,TLDCT能提升拖尾流的發送速率,進一步加快任務完成速度,與Baraat的差距也越來越小。

圖4 加速任務內部拖尾流任務完成時間對比

3.2 協議性能測試

圖5顯示了TLDCT在真實DCN流量模型下的加速效果。其中,100臺主機通過同一交換機向一臺匯聚主機共發送2 038條流。這些流組成了4類任務,具體包括窄短任務、窄長任務、寬短任務和寬長任務。其中,52個窄短任務的寬度為3,流大小都是10 KB;16個窄長任務的寬度為7,流大小都是200 KB;15個寬短任務的寬度為50,流大小都是9 KB;17個寬長任務的寬度為60,流大小都是3 MB。任務的發送開始時間服從泊松到達分布,任務內部所有流的發送時間均勻分布在100 ms內。圖5實驗結果顯示,TLDCT前50%、75%、95%完成任務的平均任務完成時間相比于DCTCP分別減少了47.0%、34.3%、15.1%,相比于 L2DCT減少了45.3%、29.9%、12.4%,相比于Baraat增加了17.6%、29.8%、5.2%。

圖5 綜合大規模實驗任務完成時間對比

4 結束語

本文針對DCN中數據流具有的任務關聯性,提出了一種任務大小和流拖尾感知的擁塞控制協議——TLDCT。該協議從加速拖尾流和小任務出發,在考慮數據中心實際環境的情況和易于部署的情況下,減少了任務的平均完成時間,提升了應用性能。在此基礎上,下一步研究方向是在保證易于部署的前提下,實現閾值的自適應調節方法。

[1] 李 丹,陳貴海,任豐原,等.數據中心網絡的研究進展與趨勢[J].計算機學報,2014,37(2):259-274.

[2] MEISNER D,SADLER C M,BARROSO L A,et al.Power management of online data-intensive services[C]// Proceedings of the 38th Annual International Symposium on Computer Architecture.New York,USA:ACM Press,2011:319-330.

[3] CHOWDHURY M,ZAHARIA M,MA J,et al.Managing data transfers in computer clusters with orchestra[C]//Proceedings of ACM SIGCOMM Conference.New York,USA:ACM Press,2011:98-109.

[4] MITTAL R,LAM V T,DUKKIPATI N,et al.TIMELY:RTT-based congestion control for the datacenter[C]//Proceedings of ACM Conference on Special Interest Group on Data Communication.New York,USA:ACM Press,2015:537-550.

[5] LEE C,PARK C,JANG K,et al.Accurate latency-based congestion feedback for datacenters[C]//Proceedings of USENIX Technical Conference.Daejeon,Korea:[s.n.],2015:403-415.

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

[7] ALIZADEH M,GREENBERG A,MALTZ D A,et al.DCTCP:efficient packet transport for the commoditized data center[C]//Proceedings of ACM SIGCOMM’2010.New York,USA:ACM Press,2010:1-15.

[8] VAMANAN B,HASAN J,VIJAYKUMAR T N,et al.Deadline-aware datadcenter TCP(D2TCP)[EB/OL].[2017-02-01].http://www.raincent.com/content-84-162-1.html.

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

[10] 蘇凡軍,牛詠梅,邵 清.數據中心網絡快速反饋傳輸控制協議[J].計算機工程,2015,41(4):107-111.

[11] CHOWDHURY M,ZHONG Yuan,STOICA I.Efficient coflow scheduling with varys[C]//Proceedings of ACM Conference on SIGCOMM.New York,USA:ACM Press,2014:443-454.

[12] DOGAR F R,KARAGIANNIS T,BALLANI H,et al.Decentralized task-aware scheduling for data center networks[C]//Proceedings of ACM Conference on SIGCOMM.New York,USA:ACM Press,2014:431-442.

[13] CHOWDHURY M,STOICA I.Efficient coflow scheduling without prior knowledge[C]//Proceedings of ACM Conference on Special Interest Group on Data Communication.New York,USA:ACM Press,2015:393-406.

[14] CHOWDHURY M,STOICA I.Coflow:an application layer abstraction for cluster networking[EB/OL].[2017-03-10].http://www2.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-184.pdf.

[15] ZHANG Hong,CHEN Li,YI Bairen,et al.CODA:toward automatically identifying and scheduling coflows in the dark[C]//Proceedings of ACM Sigcomm Conference.New York,USA:ACM Press,2016:160-173.

[16] RAI I A,URVOY-KELLER G,BIERSACK E W.Analysis of LAS scheduling for job size distributions with high variance[J].ACM SIGMETRICS Perfor-mance Evaluation Review,2003,31(1):218-228.

[17] JALAPARTI V,BODIK P,KANDULA S,et al.Speeding up distributed request-response workflows[C]//Pro-ceedings of ACM SIGCOMM Conference.New York,USA:ACM Press,2013:219-230.