趙正偉 任禎琴 趙旭鴿
摘 ?要:延遲是數(shù)據(jù)中心網(wǎng)絡(luò)及其承載應(yīng)用的一個關(guān)鍵性能度量指標(biāo),越來越受到學(xué)術(shù)界和工業(yè)界的關(guān)注。文章提出一種綜合的協(xié)調(diào)機制,把負(fù)載均衡和擁塞控制統(tǒng)一起來,在多條等價路徑上均勻分布流量,利用ECN并結(jié)合流的優(yōu)先級自適應(yīng)地對擁塞做出反應(yīng)。實驗結(jié)果顯示,該機制與目前采用的TCP和基于哈希的多路徑傳輸機制相比,對延遲敏感的流,應(yīng)用吞吐率提高了30%,流完成時間的99th分位數(shù)降低了90%;對背景流量,流的平均完成時間降低50%~80%。
關(guān)鍵詞:擁塞控制;負(fù)載均衡;多路徑傳輸;數(shù)據(jù)中心網(wǎng)絡(luò);顯式擁塞通告;時限
中圖分類號:TP393 ? ? 文獻標(biāo)識碼:A 文章編號:2096-4706(2020)23-0044-07
Study on a Kind of Network Flow Latency Framework of Minimizing Data Center
ZHAO Zhengwei,REN Zhenqin,ZHAO Xuge
(School of Information Technology,Luoyang Normal University,Luoyang ?471934,China)
Abstract:Latency is a key performance measurement index of data center network and its load bearing application,which is getting more and more attention from academic circles and industrial circles. This pager proposes an integrated coordinated mechanism to unite load balancing and congestion control,and evenly distribute flow in several equivalent paths,uses ECN and combining priority level of flow to adaptively respond to congestion. Experimental results show,comparing to existing multi-path transmission mechanism based on TCP and Hash,the mechanism achieves an improvement of 30% in application throughput rate and an reduction of 90% in 99th percentile of flow completion time for latency-sensitive flow,and achieve a reduction of 50%~80% in average completion time of flow for background flow.
Keywords:congestion control;load balance;multi-path transmission;data center network;explicit congestion notification;time limit
0 ?引 ?言
近年來,隨著互聯(lián)網(wǎng)和云計算的快速發(fā)展,數(shù)據(jù)中心已經(jīng)成為許多商業(yè)服務(wù)的關(guān)鍵基礎(chǔ)設(shè)施,如Web搜索、在線零售、社交網(wǎng)絡(luò)和廣告推薦系統(tǒng)等。這些服務(wù)通常是面向用戶的在線服務(wù),延遲對用戶體驗有重要影響,并最終影響服務(wù)提供商的運營收入。例如,平均訪問延遲增加100 ms將使Amazon的收入減少約1%[1,2];增加100 ms的延遲會使Google的搜索請求減少0.2%~0.4%,并最終導(dǎo)致其收入減少[3]。此外,數(shù)據(jù)中心主存、外存和計算的分離也加劇了對低延遲網(wǎng)絡(luò)通信的要求[4-6]。
然而,在目前的數(shù)據(jù)中心網(wǎng)絡(luò)中,滿足流的時限約束非常困難,具體原因有:
(1)劃分-聚合負(fù)載模式:劃分-聚合設(shè)計模式(partition- aggregate workloa d)是目前許多大規(guī)模互聯(lián)網(wǎng)應(yīng)用的基礎(chǔ),如搜索引擎等。在該負(fù)載模式下,大量的小流在短時間內(nèi)匯聚到交換機的一個端口上,導(dǎo)致端口緩沖溢出,繼而發(fā)生丟包和重傳[7-10]。
(2)順序依賴性的負(fù)載模式:順序依賴性的負(fù)載模式(dependent-sequential workload)是數(shù)據(jù)中心中另一種常見的通信模式,例如,為了構(gòu)建一個用戶頁面,F(xiàn)acebook需要進行100~200次數(shù)據(jù)請求,其中很大一部分請求之間存在時序依賴關(guān)系[12]。文獻[12]指出,同一機柜內(nèi),約有10%的通信往返時間大于1 ms,也就是說,在最壞情況下,2~3個RTT就會導(dǎo)致一條流錯過時限。
(3)公平共享的傳輸層協(xié)議:TCP公平對待所有的流,擁塞發(fā)生時,在最小化流的完成時間以及錯過時限流的比例方面,遠(yuǎn)不是最優(yōu)的,不僅不能滿足應(yīng)用的延遲要求,還會造成網(wǎng)絡(luò)帶寬浪費。
(4)基于隨機的負(fù)載均衡策略:目前數(shù)據(jù)中心大都采用ECMP在多條路徑之間均攤流量,通常會導(dǎo)致熱點的出現(xiàn),多條流可能被調(diào)度到一條擁擠的路徑上,其他的路徑幾乎沒有流量。這會大量增加流的平均完成時間以及高分位數(shù)完成時間。
為此,本文提出一種綜合的協(xié)調(diào)機制,把數(shù)據(jù)中心網(wǎng)絡(luò)多路徑傳輸和擁塞控制有機地結(jié)合起來,減小數(shù)據(jù)中心網(wǎng)絡(luò)流延遲。該機制既能充分利用現(xiàn)代數(shù)據(jù)中心的多根樹拓?fù)?,又能保證隨著擁塞的加劇,系統(tǒng)仍然能夠像TCP一樣收斂。同時在小規(guī)模的真實環(huán)境和大規(guī)模的仿真環(huán)境進行實驗,結(jié)果顯示該機制能夠大幅降低流延遲。
1 ?背景和相關(guān)工作
1.1 ?數(shù)據(jù)中心的網(wǎng)絡(luò)拓?fù)浜拓?fù)載均衡
為了提高性能和可靠性,現(xiàn)代數(shù)據(jù)中心大都采用多路徑的拓?fù)浣Y(jié)構(gòu)[13-16],任意兩個節(jié)點之間有多條等價路徑,但是路由和轉(zhuǎn)發(fā)層面沒有有效利用這些等價路徑。數(shù)據(jù)中心的多路徑傳輸機制,根據(jù)粒度的不同,大致可以分為以下3類:
(1)以流為粒度的多路徑傳輸機制。目前,ECMP[17]是數(shù)據(jù)中心中多路徑傳輸?shù)氖聦嵣系臉?biāo)準(zhǔn),但是經(jīng)常發(fā)生負(fù)載分布不均[12,18,19]的情況。Hedera[18]、MicroTE[20]、Mahout[21]和BCube[13]根據(jù)當(dāng)前的網(wǎng)絡(luò)狀況來選擇路徑,當(dāng)網(wǎng)絡(luò)狀況隨時間變化時,被選擇的路徑可能已不是最優(yōu)。VL2[15]和Monsoon[22]采用per-flow的Valiant Load Balancing(VLB),但是,這兩個工作都不在多條路徑上對單條流進行分割。
(2)以子流(sub-flow)為粒度的多路徑傳輸機制。MPTCP在主機端把一條TCP流分割成多條sub-flow,對于長度大于70 kB的流來說,MPTCP非常有效,然而對于長度小于10個分組的流來說,MPTCP的性能不如TCP[19]。FLARE[23]把一條流分解為一系列的突發(fā)(Flowlet),并把Flowlet路由到不同的路徑上。但是不能有效解決數(shù)據(jù)中心的同步突發(fā)問題,F(xiàn)lowlet會導(dǎo)致更大幅度隊列長度變化[22]。
(3)以分組為粒度的多路徑傳輸機制。Cisco的一些商用交換機[24]已經(jīng)采用了比較成熟的分組噴射技術(shù)(packet spray),以分組的目的地址為單位進行輪循調(diào)度(round-robin)。文獻[25]提出在主機端以分組為單位在多條路徑之間進行分發(fā),擴展性不是很好。DeTail[25]以分組為單位進行自適應(yīng)的多路徑傳輸,但是,它幾乎全部廢棄了TCP層的功能,并且受到優(yōu)先級數(shù)目有限的限制[10,26]。RPS[27]把一條流的分組隨機指派給多條等價路徑中的一條,盡管這可以降低復(fù)雜性,但RPS仍然會造成熱點問題。
1.2 ?數(shù)據(jù)中心的擁塞控制
同步突發(fā)是數(shù)據(jù)中心流量的一個基本特性,但是目前的數(shù)據(jù)中心網(wǎng)絡(luò)不能很好地處理這種情況,導(dǎo)致應(yīng)用錯過時限,具體為:
(1)TCP/IP協(xié)議棧在網(wǎng)絡(luò)發(fā)生擁塞時,使用丟包作為對發(fā)送端的反饋,超時重傳機制經(jīng)常導(dǎo)致丟包的流錯過時限。
(2)TCP平等對待所有的擁塞流,擁塞發(fā)生時,不能優(yōu)先處理某些特殊的流,這對時延敏感流極其不利。RCP[28]、XCP[29]和DCTCP[7]在高速網(wǎng)絡(luò)中性能都獲得顯著的提升,然而,這些都是公平共享的,在減小流完成時間上遠(yuǎn)不是最優(yōu)的[8,9,20]。
更嚴(yán)重的是,由于TCP不能很好地滿足應(yīng)用的時限要求,開發(fā)人員轉(zhuǎn)而尋求其他解決途徑。例如,據(jù)報道,F(xiàn)acebook正在開發(fā)基于UDP的擁塞控制協(xié)議,來滿足應(yīng)用的延遲要求[7,14,15]。
2 ?系統(tǒng)設(shè)計與分析
2.1 ?系統(tǒng)概述
圖1展示了系統(tǒng)的設(shè)計方案及其信息交換過程。該系統(tǒng)的主要設(shè)計思想是,通過基于交換機隊列長度閾值的信號機制和ECN標(biāo)記機制,把數(shù)據(jù)中心網(wǎng)絡(luò)多路徑傳輸和擁塞控制協(xié)調(diào)起來,主要目標(biāo)是利用多路徑和提高小流的優(yōu)先級來滿足小流的延遲需求。該機制由兩部分組成:
(1)在網(wǎng)絡(luò)側(cè),我們在交換機上監(jiān)控其端口隊列的瞬時長度,當(dāng)超過閾值時,觸發(fā)一個擁塞信號并通告給網(wǎng)絡(luò)層,作為其多路徑路由選擇的依據(jù),同時對隊列中的分組進行ECN標(biāo)記。
(2)在主機側(cè),接收端僅把ECN標(biāo)記完整地寫入ACK,并反饋給發(fā)送端。發(fā)送端根據(jù)在每個RTT內(nèi)接收到的ACK分組中的ECN標(biāo)記信息,計算網(wǎng)絡(luò)的擁塞程度,根據(jù)這個擁塞程度和流的優(yōu)先級動態(tài)調(diào)整其發(fā)送速率。
2.2 ?自適應(yīng)的負(fù)載均衡
為了把分組轉(zhuǎn)發(fā)到隊列長度最短的等價路徑上,并且不帶來額外的計算開銷,本文提出一種自適應(yīng)的多路徑傳輸機制。我們?yōu)榻粨Q機的每個緩沖隊列關(guān)聯(lián)一個信號,一旦隊列占用小于某個預(yù)先設(shè)置的閾值,就把信號置為有效,一旦隊列占用長度超過這個閾值,就把信號置為無效。這個信號反映的是網(wǎng)絡(luò)的擁塞狀況,所有端口的信號構(gòu)成一個信號位圖,稱為信號位圖,如圖2所示。
當(dāng)分組到達交換機時,交換機從多路徑路由表中取出所有可能的轉(zhuǎn)發(fā)端口Es同時獲取信號位圖S。接著把Es和S做按位與操作,得到所有可能的負(fù)載較輕的路徑Eg,并對分組頭做哈希操作,得到默認(rèn)的ECMP的轉(zhuǎn)發(fā)端口Eh。如果Eh的負(fù)載也較輕(即Eh∈Eg),就把Eh作為轉(zhuǎn)發(fā)端口。否則,交換機就從Eg中隨機選擇一個端口轉(zhuǎn)發(fā)該分組。當(dāng)沒有負(fù)載較輕的路徑時(即Eg=?),交換機還要對分組設(shè)置ECN標(biāo)記。這里優(yōu)先選擇ECMP計算出來的路徑,其主要目的是為了和傳統(tǒng)的ECMP保持一致,在一定程度上減小分組亂序的發(fā)生。
2.3 ?基于優(yōu)先級的自適應(yīng)的擁塞控制
2.3.1 ?網(wǎng)絡(luò)的擁塞程度
和DCTCP[7]一樣,我們采用ECN機制來獲取網(wǎng)絡(luò)的擁塞程度。發(fā)送端維護一個變量α,用來估計已標(biāo)記分組的比例,每發(fā)送完一個窗口的數(shù)據(jù)(大概是一個RTT時間)更新一次:
α=(1-g)·α+g·F ? ? ? ? ? ? ? ? ? ? ? ? (1)
其中,F(xiàn)為最后一個窗口中被標(biāo)記的分組的比例。0
2.3.2 ?基于時限的優(yōu)先級劃分
為了優(yōu)先處理時延敏感的流,我們引入了優(yōu)先級的概念。優(yōu)先級越高,擁塞時其擁塞窗口退避幅度越小。流的優(yōu)先級定義為:
(2)
其中RD為在時限截止前發(fā)送完一條流剩余數(shù)據(jù)的期望速率,RA為從流開始到當(dāng)前時刻的平均速率。
2.3.3 ?擁塞窗口的調(diào)節(jié)
為了根據(jù)網(wǎng)絡(luò)的擁塞程度和流的優(yōu)先級來調(diào)節(jié)擁塞窗口,我們定義懲罰函數(shù):
P=αp ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(3)
這個函數(shù)被稱為Gamma校正函數(shù)。這個函數(shù)的一個優(yōu)良特性是當(dāng)自變量α在[0,1]之間變化時,其函數(shù)值也在這個區(qū)間變化,這就可以保證,當(dāng)擁塞加劇時或者時限即將結(jié)束時,PDTCP可以像TCP一樣收斂。
接下來,根據(jù)懲罰函數(shù)P調(diào)節(jié)擁塞窗口:
(4)
可以看出,在網(wǎng)絡(luò)擁塞程度相同的情況下,優(yōu)先級越高,懲罰函數(shù)P越小,窗口W退避得越少,從而保證能夠以較快的速度發(fā)送完畢。在所有的流中,擁塞程度相同時,延遲不敏感的流窗口退避程度最大,從而為延遲敏感的流騰出帶寬,滿足后者的時限約束。
2.3.4 ?提前優(yōu)先級翻轉(zhuǎn)
當(dāng)可以確定流不能滿足其時限約束時,提前將其優(yōu)先級降為最低,為其他延遲敏感流騰出帶寬。
2.4 ?理論分析
假定N條無限長的流共享M個鏈路,N?M所以M條鏈路就是瓶頸鏈路。因為采用按分組的多路徑傳輸,所以在任何時刻,M條鏈路的隊列長度都是相同的。進一步假設(shè)N條流完全同步,鋸齒窗口完全一致,并且都有相同的RTT。這種通信模式是由數(shù)據(jù)中心中常見的劃分-聚合設(shè)計模式產(chǎn)生的。
根據(jù)文獻[30],在t時刻,隊列長度由式(5)決定:
Q(t)= ? ? ? ? ? ? ? (5)
這里N條流共享一條瓶頸鏈路。RTT是往返時間,沒有排隊延遲。假設(shè)TCP進入到AIMD的擁塞避免階段。Wi(t)為第i條流在時間t時的窗口大小,C為鏈路帶寬,ε為被丟棄的分組數(shù)目。
這里N條流完全同步,其鋸齒窗口完全相同。我們忽略ε,因為PDTCP的設(shè)計初衷之一就是避免分組丟棄。所以,可以把式(5)變?yōu)椋?/p>
M·Q(t)=N·W(t)-(RTT·C·M) ? ? (6)
式(6)的物理意義是這樣的:所有發(fā)出的分組,要么是在M條鏈路的隊列里,要么在M條鏈路上。
為了刻畫鋸齒窗口的特性,我們重點關(guān)注以下幾個變量:交換機隊列的最大長度Qmax、隊列的震蕩幅度A、震蕩的周期TC。其中最關(guān)鍵的是震蕩幅度A,因為算法的目標(biāo)之一就是盡量維持隊列長度在其閾值K附近,震蕩幅度越小越好。因為N條流是完全同步的,所以交換機隊列也是鋸齒狀,只是震蕩幅度和發(fā)送端擁塞窗口不同,如圖3所示。
因為所有的發(fā)送者是完全同步的,考慮其中的一個。令PS(W1,W2)為發(fā)送者的窗口從W1增加到W2期間,一共發(fā)送的分組數(shù)目。這個過程需要W2-W1個RTT,并且期間的平均窗口大小為(W2-W1)/2,因而可以得到:
PS(W1,W2)=(W2-W1)·(W1+W2)/2=(W22-W12)/2 ?(7)
令W*=M·(C·RTT+K)/N,其為隊列長度接近K時的臨界窗口大小,超過這個之后,交換機開始設(shè)置CE代碼點。在下一個RTT,發(fā)送窗口增加到W*+1,發(fā)送端接收到CE標(biāo)記。因此:
(8)
將式(7)帶入式(8),得:
α(P-P2/4)=(2W*+1)/(W*+1)2 ? ? ? ? ? ?(9)
假設(shè)懲罰函數(shù)P的值很小,忽略高次項,得:
αP=(2W*+1)/(W*+1)2 ? ? ? ? ? ? ? ? ? (10)
假定W*?1,式(10)右邊近似等于2/W*,將窗口退避懲罰函數(shù)的定義式P=α p帶入式(10),得:
αp+1≈2/W* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(11)
由此得到α的近似值:
α=(2/W*)1/(p+1) ? ? ? ? ? ? ? ? ? ? ? ?(12)
下文計算隊列的震蕩幅度QA。定義WA為一條流的窗口震蕩幅度,如圖3所示。因為N條流是完全同步的,QA只是WA的簡單放大,即:
(13)
因為N條流共享M條鏈路,故:
M·QA=N·WA ? ? ? ? ? ? ? ? ? ? ? ? ? ?(14)
(15)
式(15)展示了PDTCP在多路徑下的一個重要特性:當(dāng)N比較小時,隊列的震蕩幅度為O((M·C·RTT)1/(p+1))。
當(dāng)p=1,N較小時,振幅為,這就是DCTCP
在自適應(yīng)多路徑傳輸下的情形。當(dāng)p=0時,就是TCP在多路徑下的情形。
到此,我們得到:
TC=WA(inRTTs) ? ? ? ? ? ? ? ? ? ? ? (16)
最后,根據(jù)式(5),可以計算Qmax:
(17)
門限值K。交換機隊列長度的最小值計算為:
(18)
Qmin對N求導(dǎo),并讓導(dǎo)數(shù)取0,求解N,得:
N=(1/2)(p/(1+p))1+p[M(C·RTT+K)] ?(19)
帶入式(18),并令Qmin>0,得到K的下界:
(20)
3 ?實驗結(jié)果
3.1 ?關(guān)鍵參數(shù)設(shè)置
我們根據(jù)文獻[5]來設(shè)置DCTCP,D2TCP和PDTCP的關(guān)鍵參數(shù)。對1 Gbps的鏈路,設(shè)置g=1/16。對PDTCP,和文獻[6]一樣,我們限制了流的優(yōu)先級P的取值范圍在[0.5,2.0]之間。對所有的協(xié)議,我們把RTOmin設(shè)置為20 ms。
流的時限服從指數(shù)分布,均值分別為20 ms(tight)、30 ms(median)和40 ms(lax)[8]。我們用應(yīng)用吞吐率即滿足時限的流的比例,作為這些時限約束流的性能度量指標(biāo)。
3.2 ?真實環(huán)境結(jié)果和模擬器驗證
為了驗證模擬器的參數(shù)設(shè)置,我們同時在真實環(huán)境和ns-2中構(gòu)建了一個36節(jié)點的Fat-tree拓?fù)洌⑹褂孟嗤呢?fù)載流量。結(jié)果顯示,真實實現(xiàn)和仿真實驗下各個指標(biāo)的絕對值和相對差值都非常小,并且變化趨勢一致,這些關(guān)鍵的相似性說明模擬器的參數(shù)設(shè)置是可信的,能夠反映系統(tǒng)在真實實現(xiàn)下的性能。
3.3 ?仿真實驗結(jié)果
劃分-聚合負(fù)載模式。圖4(a)展示了當(dāng)同步突發(fā)流數(shù)目從5增加到40時,應(yīng)用吞吐率的變化情況??梢钥闯?,與TCP+FH相比,PDTCP+AM有明顯的性能提升,例如,當(dāng)并發(fā)的同步流數(shù)目是40時,PD2TCP+AM下95%的流滿足時限,而TCP+FH只能滿足65%流的時限。圖4(b)展示了流完成時間的99th分位數(shù),我們把流完成時間歸一化到最優(yōu)值上。PD2TCP+AM能夠獲得接近最優(yōu)的性能,因為歸一化的流完成時間的99th分位數(shù)在1.0~1.2之間。TCP+AM與PD2TCP+FH比TCP+FH稍好,其值分別在1.4~2.5和1.1~1.6之間。TCP+FH表現(xiàn)最差,當(dāng)并發(fā)流數(shù)目是40時,其歸一化的完成時間超過6,亦即最優(yōu)值的6倍。同樣,對背景流量,PD2TCP+AM也能獲得接近最優(yōu)的表現(xiàn),如圖4(c)所示。
順序依賴負(fù)載模式。在該流量模式下,PD2TCP+AM的性能提高比在劃分-聚合流量下更明顯。如圖5所示,當(dāng)工作流的達到速率在1 600個/秒時,PD2TCP+AM和TCP+ FH的應(yīng)用吞吐率分別是96%和70%,歸一化流完成時間的99th分位數(shù)分別是1.5和45。對背景流,在1 600工作流/秒時,歸一化的流完成時間分別是1.6和9.5。
這些結(jié)果說明,與TCP+FH相比,PDTCP+AM在性能上有明顯的提升,其原因是自適應(yīng)的多路徑機制充分利用了拓?fù)浣Y(jié)構(gòu)中的多條等價的最短路徑,并且以分組為粒度選擇最不擁堵的路徑。這種機制能同時降低流的排隊延遲,并提高流的吞吐率。此外,在擁塞時,PDTCP優(yōu)先處理延遲敏感的流,進一步降低了這類流的排隊延遲。
4 ?結(jié) ?論
延遲是數(shù)據(jù)中心網(wǎng)絡(luò)主要的性能指標(biāo)之一,降低數(shù)據(jù)中心網(wǎng)絡(luò)流延遲面臨許多挑戰(zhàn)。本文提出一種協(xié)調(diào)一致的數(shù)據(jù)中心網(wǎng)絡(luò)擁塞控制和多路徑傳輸機制,同時解決數(shù)據(jù)中心網(wǎng)絡(luò)對高帶寬和低延遲的要求。同時在真實和仿真環(huán)境中,采用真實的數(shù)據(jù)中心流量模型對該機制進行評價。實驗結(jié)果顯示,該機制與目前數(shù)據(jù)中心采用的TCP和基于哈希的多路徑傳輸機制相比,能夠有效提高延遲敏感流的應(yīng)用吞吐率和99th分位數(shù)完成時間,并能同時提高背景流的吞吐率。
參考文獻:
[1] HOFF T. Latency is Everywhere and it Costs You Sales-How to Crush it [EB/OL].(2009-07-25).http://highscalability.com/blog/2009/7/25/latency-is-everywhere-and-it-costs-you-sales-how-to-crush-it.html.
[2] KOHAVIR R,LONGOTHAM R. Online experiments:Lessons learned [J] Computer ,2007,40(9):103-105.
[3] BRUTLAG J. Speed matters for Google web search [EB/OL].[2020-10-15].https://services.google.com/fh/files/blogs/google_delayexp.pdf.
[4] GAO P X,NARAYAN A,KARANDIKAR S. Network requirements for resource disaggregation [C]//Proceedings of the 12th USENIX conference on Operating Systems Design and Implementation.Berkeley:USENIX Association,2016:249-264.
[5] SHAN Y Z,ZHANG Y Y,CHEN Y L,et al. LegoOS:a disseminated,distributed OS for hardware resource disaggregation [C]//13th USENIX Symposium on Operating Systems Design and Implementation.Berkeley:USENIX Association,2018:69-87.
[6] KUMAR G,DUKKIPATI N,JANG K,et al. Swift:Delay is Simple and Effective for Congestion Control in the Datacenter [C]//Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications,technologies,architectures,and protocols for computer communication.New York:Association for Computing Machinery,2020:514-528.
[7] VASUDEVAN V,PHANISHAYEE A,SHAH H,et al. Safe and Effective Fine-grained TCP Retransmissions for Datacenter Communication [J].ACM SIGCOMM Computer Communication Review,2011,39(4):303-314.
[8] CHEN Y P,GRIFFITH R,LIU J D. Understanding TCP incast throughput collapse in datacenter networks [C]//Proceedings of the 1st ACM SIGCOMM 2009 Workshop on Research on Enterprise Networking.Barcelona:Association for Computing Machinery,2009:73-82.
[9] ALIZADEH M,GREENBERG A G,MALTZ D A,et al. Data center TCP (DCTCP)[J].ACM SIGCOMM Computer Communication Review,2010,40(4):63-74.
[10] WILSON C,BALLANI H,KARAGIANNIS T,et al. Better Never than Late:Meeting Deadlines in Datacenter Networks [J].ACM SIGCOMM Computer Communication Review,2012,41(4):50-61.
[11] OUSTERHOUT J K,AGRAWAL P,ERICKSON D,et al. The case for RAMClouds:Scalable high-performance storage entirely in DRAM [J].ACM SIGOPS Operating Systems Review,2009,43(4):92-105.
[12] ZATS D,DAS T,MOHAN P,et al. DeTail:reducing the flow completion time tail in datacenter networks [J].ACM SIGCOMM Computer Communication Review,2012,42(4):139-150.
[13] GUO C X,LU G H,LI D,et al. BCube:A High Performance,Server-centric Network Architecture for Modular Data Centers [J].ACM SIGCOMM Computer Communication Review,2009,39(4):63-74.
[14] GUO C X,WU H T,TAN K,et al. DCell:A scalable and fault-tolerant network structure for data centers [J].ACM SIGCOMM Computer Communication Review,2008,38(4):75.
[15] GREENBERG A G,HAMILTON J R,JAIN N,et al. VL2:A Scalable and Flexible Data Center Network [J].Communications of the ACM,2009,54(3):95-104.
[16] MYSORE R N,PAMBORIS A,F(xiàn)ARRINGTON N,et al. PortLand:A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric [J].ACM SIGCOMM Computer Communication Review,2009,39(4):39-50.
[17] Cisco.Cisco Data Center Infrastructure 2.5 Design Guide [EB/OL].[2020-10-15].http://www.cisco.com/univercd/cc/td/doc/solution/dcidg21.pdf.
[18] AL-FARES M,RADHAKRISHNAN S,RAGHAVAN B,et al. Hedera:dynamic flow scheduling for data center networks [C]//Proceedings of the 7th USENIX Symposium on Networked Systems Design and Implementation.San Jose:USENIX Association,2010:19.
[19] RAICIU C,BARR? S,PLUNTKE C,et al. Improving Datacenter Performance and Robustness with Multipath TCP [J].ACM SIGCOMM Computer Communication Review,2011,41(4):266-277.
[20] BENSON T,ANAND A,AKELLA A,et al. MicroTE:Fine Grained Traffic Engineering for Data Centers [C]//Conference on emerging Networking Experiments and Technologies.New York:Association for Computing Machinery,2011:1-12.
[21] CURTIS A R,MOGUL J,TOURRILHES J. DevoFlow:Scaling Flow Management for High-Performance Networks [J].ACM SIGCOMM Computer Communication Review,2011,41(4):254-265.
[22] GREENBERG A G,LAHIRI P,MALTZ D A,et al. Towards a next generation data center architecture [C]//Proceedings of the ACM SIGCOMM 2008 Workshop on Programmable Routers for Extensible Services of Tomorrow.New York:Association for Computing Machinery,2008:57-62.
[23] SINHA S,KANDULA S,KATABI D. Harnessing TCPs Burstiness using Flowlet Switching [C]//Hot Topics in Networks HotNets-Ⅲ.San Diego:2004.
[24] Cisco. Per-packet load balancing [EB/OL].[2020-10-15].https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipswitch_cef/configuration/15-s/isw-cef-15-s-book/isw-cef-load-balancing.html#GUID-C725A4B8-9263-4D2C-95FB-F31D14E477C4.
[25] GEOFFRAY P,HOEFLER T. Adaptive Routing Strategies for Modern High Performance Networks [C]//2008 16th IEEE Symposium on High Performance Interconnects.Stanford:IEEE,2008:165-172.
[26] HONG C Y,CAESAR M,GODFREY P B. Finishing Flows Quickly with Preemptive Scheduling [J].ACM SIGCOMM Computer Communication Review,2012,42(4):127-138.
[27] DIXIT A,PRAKASH P,HU Y C,et al. On the impact of packet spraying in data center networks [C]//2013 Proceedings IEEE INFOCOM.Turin:IEEE,2013:2130-2138.
[28] DUKKIPATI N. Rate control protocol (rcp):congestion control to make flows complete quickly [D].Stanford:Stanford University,2007.
[29] KOHAVI R,LONGBOTHAM R,SOMMERFIELD D,et al. Controlled experiments on the Web:survey and practical guide [J].Data Mining and Knowledge Discovery,2009,18:140-181.
[30] APPENZELLER G,KESLASSY I,MCKEOWN N. Sizing Router Buffers [J].ACM SIGCOMM Computer Communication Review,2004,34(4):281-292.
作者簡介:趙正偉(1982—),男,漢族,河南澠池人,講師,博士,主要研究方向:數(shù)據(jù)中心網(wǎng)絡(luò);任禎琴(1983—),女,漢族,河南焦作人,講師,博士,主要研究方向:非線性系統(tǒng);趙旭鴿(1992—),女,漢族,河南汝州人,助教,碩士,主要研究方向:大數(shù)據(jù)。