論文信息：

S. M. Irteza, A. Ahmed, S. Farrukh, B. N. Memon, and I. A. Qazi.On the coexistence of transport protocols in data?centers. In Proceedings of IEEE ICC, 2014.

數(shù)據(jù)中心傳輸協(xié)議的共存

摘要 ?云數(shù)據(jù)中心的出現(xiàn)直接導(dǎo)致了數(shù)據(jù)中心TCP（DCTCP）等自定義傳輸協(xié)議的出現(xiàn)。這些協(xié)議通過考慮數(shù)據(jù)中心的獨(dú)特網(wǎng)絡(luò)和流量特性來提高云應(yīng)用的性能。然而，這樣的協(xié)議只能在新建部署的情況下進(jìn)行評估，需要假定整個(gè)數(shù)據(jù)中心都使用相同的協(xié)議，這在實(shí)際中并不可行。在數(shù)據(jù)中心中，自定義傳輸協(xié)議與TCP共存，共享網(wǎng)1絡(luò)資源。本文對DCTCP和TCP并存進(jìn)行了全面的研究。我們評估了在不同的主動隊(duì)列管理方案（AQM）（包括RED，DCTCP AQM和CHOKe）下的帶寬共享屬性。研究結(jié)果表明，在DCTCP AQM下，DCTCP可能導(dǎo)致TCP分配的流量不足。這個(gè)問題通過使用RED來減輕，但是不公平現(xiàn)象仍然存在，而且CHOKe的存在加劇了這種不公平。在本文中，我們證明了CHOKe的修改版本能通過更精確地處理主導(dǎo)流量而大大提高了公平性。

Ⅰ. 介紹

大規(guī)模數(shù)據(jù)中心的出現(xiàn)已經(jīng)因?yàn)榫W(wǎng)絡(luò)搜索，社交網(wǎng)絡(luò)和廣告系統(tǒng)等大規(guī)模在線服務(wù)以及亞馬遜，谷歌和微軟等云計(jì)算服務(wù)提供商的崛起，轉(zhuǎn)變了計(jì)算格局[1]。這些數(shù)據(jù)中心具有獨(dú)特的網(wǎng)絡(luò)和流量特性，可以承載多種應(yīng)用。在應(yīng)用的多樣化要求下，為數(shù)據(jù)中心設(shè)計(jì)定制的傳輸協(xié)議[2][3] [4] [5] [6]應(yīng)運(yùn)而生。 例如，數(shù)據(jù)中心TCP（DCTCP）的設(shè)計(jì)是為了滿足軟實(shí)時(shí)應(yīng)用的需求，如網(wǎng)絡(luò)搜索，廣告和零售[2]等

這些協(xié)議在假定整個(gè)數(shù)據(jù)中心使用相同協(xié)議的新建部署場景下進(jìn)行了評估。但是，這種情況并不總是可行的。首先，典型的數(shù)據(jù)中心同時(shí)托管多個(gè)應(yīng)用程序，以實(shí)現(xiàn)資源使用的靈活性和高效性[1]，[3]。在某些應(yīng)用程序（例如，網(wǎng)頁搜索和社交網(wǎng)絡(luò)等軟實(shí)時(shí)應(yīng)用程序）需要使用截止期限感知（[3]）或延遲最小化（[5]，[6]）傳輸協(xié)議時(shí)，其他應(yīng)用程序 （例如，具有服務(wù)級別協(xié)議的多租戶環(huán)境中的云服務(wù)或與之相關(guān)的SLA）可能需要公平共享的傳輸協(xié)議[2]。其次，使用新的傳輸協(xié)議需要軟件和/或硬件的改變，并可能要求重寫應(yīng)用程序（[4]，[6]），但這有時(shí)候并不現(xiàn)實(shí)（例如，由于使用專有系統(tǒng)） （例如，由于對新建部署需要大量的數(shù)據(jù)中心停機(jī)時(shí)間，降低了數(shù)據(jù)中心的可用性）。

這導(dǎo)致定制的數(shù)據(jù)中心傳輸協(xié)議與現(xiàn)有的傳輸協(xié)議（如TCP）共存并共享網(wǎng)絡(luò)資源的情況。然而，這種共享可能會造成某種協(xié)議的低吞吐量或者饑餓的情況。本文對這些場景進(jìn)行了全面的研究，并研究了在幾種主動隊(duì)列管理（AQM）方案下DCTCP和TCP的共存性質(zhì)。

我們的結(jié)果表明，由于DCTCPAQM基于瞬時(shí)隊(duì)列長度的進(jìn)行標(biāo)記，以及和TCP相比使用了更小的補(bǔ)償因子，它可能導(dǎo)致TCP流量的匱乏。隨機(jī)早期檢測（RED）[7]可以提高協(xié)議之間的公平性，但仍然存在著吞吐量的顯著差異。考慮到CHOKe[8]，由于其標(biāo)記政策對TCP非流占主導(dǎo)地位產(chǎn)生了負(fù)面影響，它反而降低了公平性。因此我們建議對CHOKe進(jìn)行一個(gè)簡單的改變，這可以提高主流的檢測精度，并大大提高RED的公平性。

本文具有如下貢獻(xiàn)：

* 在不同的AQM方案下，我們對DCTCP和TCP共存行為進(jìn)行了嚴(yán)格的分析。 通過模型分析，我們研究了增加和減少參數(shù)以及AQM對協(xié)議性能的影響。

* 本文表明，雖然RED提高了公平性，但CHOKe實(shí)際上降低了它。我們建議對CHOKe進(jìn)行修改，通過更準(zhǔn)確地主導(dǎo)主流，提高性能。

* 本文提出根據(jù)平均流量完成時(shí)間（AFCT）和吞吐量評估典型數(shù)據(jù)中心特定流量模式下的DCTCP和TCP。

本文的其余部分安排如下。 本文第二部分描述了DCTCP，討論了AQM方案。 在第三部分討論協(xié)議共存問題，在第四部分和第五部分討論目前的評估問題。有關(guān)的工作在第六部分討論，第七部分是結(jié)束語。

Ⅱ DCTCP和AQM方案

?????? 本節(jié)描述DCTCP和評估DCTCP和TCP共存的AQM方案。

A.??? 數(shù)據(jù)中心TCP

DCTCP [2]旨在通過使用標(biāo)記數(shù)據(jù)包的一小部分對擁塞程度做出反應(yīng)的方法，達(dá)到數(shù)據(jù)中心環(huán)境中的低延遲和高吞吐量的目標(biāo)。當(dāng)擁塞率低時(shí)，它使用一個(gè)小的補(bǔ)償因子。當(dāng)擁塞增加時(shí)，它增加回退因子。DCTCP使用的最大退避因子是0.5。DCTCP用于確定退避因子的公式如下：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

F代表上一個(gè)RTT中被標(biāo)記包的比例，DCTCP使用α/2作為退避因子。

B.??? 主動隊(duì)列管理算法

DCTCP AQM：DCTCPAQM通過使用ECN設(shè)置Congestion Experienced（CE）位，在隊(duì)列長度超過某個(gè)閾值K時(shí)標(biāo)記所有的數(shù)據(jù)包。 與RED不同，DCTCPAQM使用瞬時(shí)隊(duì)列長度，這會導(dǎo)致更主動的標(biāo)記。

RED：REDAQM根據(jù)平均隊(duì)列長度qavg概率標(biāo)記數(shù)據(jù)包。當(dāng)qavg超過下限閾值時(shí)，它開始標(biāo)記數(shù)據(jù)包。標(biāo)記概率p線性增加，直到qavg超過最大值，達(dá)到：

? ? ? ? ? ? ? ? ? ? ? ? ? ??

? 代表最大標(biāo)記概率。當(dāng)大于時(shí)，RED百分百標(biāo)記達(dá)到的數(shù)據(jù)包。

CHOKe：CHOKeAQM建立在RED的基礎(chǔ)上，通過包含基于流分類的優(yōu)先標(biāo)記/丟棄數(shù)據(jù)包的機(jī)制實(shí)現(xiàn)功能。當(dāng)超過時(shí)，CHOKe從隊(duì)列中挑選一個(gè)隨機(jī)數(shù)據(jù)包，并檢查輸入數(shù)據(jù)包是否與隨機(jī)數(shù)據(jù)包具有相同的流。如果為true，則標(biāo)記兩個(gè)數(shù)據(jù)包。否則，它使用等式（2）計(jì)算的概率標(biāo)記傳入分組。如果超過，則標(biāo)記數(shù)據(jù)包

Ⅲ. 協(xié)議共存

許多數(shù)據(jù)中心傳輸協(xié)議基于網(wǎng)絡(luò)條件來調(diào)整TCP參數(shù)來實(shí)現(xiàn)高性能[2]，[3]，[5]，例如，DCTCP根據(jù)網(wǎng)絡(luò)擁塞程度在[0.5，1]范圍內(nèi)調(diào)整退避因子；D2TCP[3]根據(jù)流程截止時(shí)間調(diào)整回退因子；L2DCT [5]通過逼近最短剩余處理時(shí)間（SRPT）調(diào)度規(guī)則來調(diào)整增加因子和回退因子以最小化完成時(shí)間。因此，與TCP競爭時(shí)，這些協(xié)議基于參數(shù)設(shè)置的差異將實(shí)現(xiàn)不同的吞吐量性能。

現(xiàn)存在幾種模型，它們能在協(xié)議共存時(shí)，使用不同的加性增加乘法減少（AIMD）參數(shù)來表征協(xié)議的性能[9]，[10]。但是，它們假設(shè)協(xié)議都承擔(dān)相同的分組丟棄/標(biāo)記概率，這在實(shí)際中可能并不成立，因?yàn)榉纸M丟棄/標(biāo)記概率取決于在路由器上采用的AQM方案的選擇。 除了參數(shù)的差異之外，AQM方案還會顯著影響協(xié)議的性能。 事實(shí)上，在某些情況下，使用AQM可能會加劇不公平甚至導(dǎo)致其中一個(gè)協(xié)議饑餓。

我們在這項(xiàng)工作中的目標(biāo)是分析幾個(gè)常用的AQM對協(xié)議共存的影響。我們評估這些AQM如何能夠?qū)崿F(xiàn)公平的丟棄/標(biāo)記，使得協(xié)議性能的差異僅僅是由于它們的AIMD參數(shù)的差異，而不是交換機(jī)處的排隊(duì)動態(tài)。

A.??? 量化吞吐量差異

我們現(xiàn)在只分析由于DCTCP和TCP使用的不同AIMD參數(shù)而引起預(yù)期的吞吐量差異。

考慮有N個(gè)流的AIMD系統(tǒng)，其中每個(gè)流分別使用不同的AI和MD參數(shù)，即α1和β1，使用模型與[9]，[10]中的模型類似。所有流用i∈{1,2，...，n}標(biāo)記，共享一個(gè)瓶頸鏈接。假設(shè)所有流具有等于T的同質(zhì)RTT，并且在隊(duì)列變滿之后通知每個(gè)流需要一個(gè)RTT。假定流是同步的;，并處于數(shù)據(jù)中心環(huán)境中的典型場景中[1]。在上述假設(shè)的基礎(chǔ)上，文獻(xiàn)[9]中描述的AIMD源網(wǎng)絡(luò)收斂到一個(gè)唯一的穩(wěn)態(tài)點(diǎn)，其中θ是正常數(shù)，W_ss是窗口大小，x_p由下式給出：

? ? ? ? ? ? ? ? ? ? ? ? ? ?

由于所有流具有相同大小的RTT，因此使用不同的AIMD參數(shù)的兩個(gè)流（一個(gè)DCTCP和另一個(gè)TCP）的吞吐量T_r之比由下式給出：

? ? ? ? ? ? ? ? ? ? ??

圖1顯示了當(dāng)DCTCP的退避因子在[0,5,1]的范圍內(nèi)變化時(shí)的變化。當(dāng)增加時(shí)，也增加。發(fā)生這種情況的原因是，退避減小，與TCP相比，DCTCP能夠保持更大的窗口大小，從而實(shí)現(xiàn)更高的吞吐量。注意，當(dāng)= 0.5時(shí)，為1，流獲得相同的吞吐量。

Ⅳ. 具有不同AQMS的TCP和DCTCP

? 在本節(jié)中，我們評估DCTCP和TCP在共享瓶頸鏈接時(shí)的共存屬性。我們考慮包括RED，DCTCPAQM和CHOKe在內(nèi)的幾個(gè)AQM，并將其與Drop-Tail隊(duì)列進(jìn)行比較。

仿真設(shè)置：我們選擇NS2作為仿真平臺，使用單根樹型拓?fù)鋪磉M(jìn)行評估。單根樹型拓?fù)涫菙?shù)據(jù)中心常用的拓?fù)淠Ｐ蚚2]，[11]，[12]。瓶頸鏈路容量設(shè)置為1Gbps，而其他所有鏈路的容量均為10 Gbps。一個(gè)源生成TCP流，而另一個(gè)生成DCTCP流。我們使用具有ECN能力的TCPNewReno，數(shù)據(jù)包大小設(shè)置為1500字節(jié)。往返傳播延遲（RTT）設(shè)置為250μs，如之前的論文[2]所報(bào)告，導(dǎo)致帶寬延遲乘積（BDP）為約22個(gè)分組。緩沖區(qū)大小設(shè)置為250個(gè)數(shù)據(jù)包[2]。為了消除RTT異質(zhì)性的影響，DCTCP和TCP流都使用相同的RTT。流的開始時(shí)間是隨機(jī)的，用來防止任何相位效應(yīng)的影響。除非另有說明，每個(gè)實(shí)驗(yàn)重復(fù)十次，本文報(bào)告了這些結(jié)果的平均值。

指標(biāo)：我們使用以下兩個(gè)指標(biāo)比較DCTCP和TCP的性能：

?公平性：設(shè)吞吐量比，其中和分別是DCTCP和TCP流實(shí)現(xiàn)的平均吞吐量。 注意= 1意味著兩個(gè)協(xié)議達(dá)到相同的吞吐量。

?系統(tǒng)效率：設(shè)總吞吐量，它是所有流吞吐量的總和。

A.??? 使用Drop-Tail的TCP和DCTCP

當(dāng)瓶頸路由器使用Drop-Tail隊(duì)列時(shí)，我們首先考慮TCP和DCTCP的共存屬性。在這種情況下，當(dāng)?shù)竭_(dá)的數(shù)據(jù)包發(fā)現(xiàn)隊(duì)列已滿時(shí)，數(shù)據(jù)包（TCP和/或DCTCP）將從隊(duì)列尾部丟棄。因此，兩種協(xié)議的退避機(jī)制都由分組丟棄來驅(qū)動，這導(dǎo)致DCTCP以與TCP相同的量退避，即0.5。在圖2中可看出，兩個(gè)流都收斂到相同的吞吐量值。但是，使用Drop-Tail隊(duì)列有兩個(gè)挑戰(zhàn)：（a）會導(dǎo)致較大的排隊(duì)延遲（平均隊(duì)列占用率為71％），這會增加延遲敏感業(yè)務(wù)的完成時(shí)間；（b）相同的吞吐量降低了像DCTCP這樣的新協(xié)議部署的動力。

B.??? 使用DCTCP AQM的TCP和DCTCP

接下來驗(yàn)證DCTCP AQM。圖3（a）顯示了吞吐量隨著時(shí)間變化的情況（在RTT時(shí)間尺度上測量）。圖中顯示TCP流饑餓，且DCTCP流的吞吐量大約是TCP流的8倍。發(fā)生這種情況的原因是：（a）基于瞬時(shí)隊(duì)列長度的DCTCPAQM的積極標(biāo)記；（b）DCTCP使用了較溫和的退避因子。DCTCP使用比TCP更小的退避因子使得保持的平均隊(duì)列長度接近標(biāo)記閾值K。由于DCTCP的主動標(biāo)記，這使得來自TCP流的非常少的分組被容納在緩沖器中，并且導(dǎo)致頻繁的TCP流量回退，從而降低吞吐量。 請注意，保持在1Gbps（請參見圖3（b））。

標(biāo)記閾值K的影響：標(biāo)記閾值K決定了DCTCP流達(dá)到的時(shí)延和吞吐量。[2]表明為了避免鏈路吞吐量的任何損失，K應(yīng)至少為BDP/ 7。與需要BDP緩沖區(qū)來保持全鏈路吞吐量的TCP不同，由于使用較小的退避因子，DCTCP需求較少。圖3表現(xiàn)了隨著K值變化的情況。圖中顯示，隨著K增加，從K= 20時(shí)的6增加到K= 150時(shí)的12，表明DCTCP正在獲得更大的瓶頸環(huán)節(jié)容量份額。發(fā)生這種情況的原因是：隨著K值，流量競爭更大的緩沖空間，平均隊(duì)列占用率也隨之增大。在較大的緩沖空間中，DCTCP占據(jù)較大優(yōu)勢，增加。具體說來，K的值決定了兩個(gè)流可用的平均緩沖空間。當(dāng)K增加時(shí)，DCTCP保持更大的擁塞窗口，從而維持隊(duì)列中更大數(shù)量的分組。由于DCTCP采用小于TCP的回退因子，因此對于緩沖區(qū)中的TCP數(shù)據(jù)包幾乎沒有凈空。另一方面，TCP的積極回退允許DCTCP流支配緩沖區(qū)空間增大。這轉(zhuǎn)化為DCTCP流量的吞吐量的增加和TCP流量的吞吐量的減少。

圖3 該圖顯示了當(dāng)瓶頸鏈路使用DCTCPAQM時(shí)長DCTCP和TCP流的性能。 （a）顯示隨時(shí)間變化的流吞吐量，（b）顯示流的總吞吐量，（c）顯示吞吐率與K的函數(shù)關(guān)系。

總之，當(dāng)DCTCP與DCTCP共存時(shí)，因?yàn)镈CTCP的激進(jìn)AQM和較小的回退因子，DCTCPAQM會導(dǎo)致TCP流非常低的吞吐量。而且，取決于標(biāo)記閾值K。隨著K增加，和排隊(duì)延遲也增加。

C.??? 使用RED的TCP和DCTCP

DCTCP具有比TCP更高吞吐量的主要原因是其較小的退避因子和交換機(jī)上的積極標(biāo)記，這造成了DCTCP對緩沖區(qū)的壟斷。這反過來又導(dǎo)致了TCP的經(jīng)常回退。因此，一個(gè)比DCTCPAQM更加公平的數(shù)據(jù)包標(biāo)記可以提高協(xié)議流的公平性。RED提供了這樣的選擇。我們現(xiàn)在評估RED下的共存屬性。我們使用RED和ECN標(biāo)記，并研究了最小和最大隊(duì)列閾值對DCTCP和TCP流的性能的影響。

圖4（a）顯示了當(dāng)50，= 100時(shí)，DCTCP和TCP流的吞吐量隨著時(shí)間的變化。圖中顯示TCP比在使用DCTCPAQM時(shí)的吞吐量更好。但是，由于分組的概率標(biāo)記和隨之而來的排隊(duì)行為，兩個(gè)流都表現(xiàn)出吞吐量的巨大波動。

的影響： 當(dāng)我們在保持固定為100的情況下增加時(shí)，觀察到也增加。發(fā)生這種情況是因?yàn)槭盏綐?biāo)記數(shù)據(jù)包時(shí)，TCP比DCTCP更積極地回退。因此，平均而言，DCTCP將會獲得更高的緩存份額。請注意，當(dāng)設(shè)置為30時(shí)，吞吐率為~2。隨著我們將增加到90，吞吐率會增加到3.5。因此，就像DCTCPAQM一樣，DCTCP實(shí)現(xiàn)比TCP更高的擁塞窗口大小。另一個(gè)要考慮的因素是標(biāo)記概率的變化，這取決于兩個(gè)閾值之間的差異。隨著我們增加，差異（?-）也減少，從而使RED在標(biāo)記方面更加積極，類似于DCTCPAQM。

的影響：當(dāng)maxth增加時(shí)，標(biāo)記概率的斜率減小（參見公式（2））。這導(dǎo)致的增加，流量之間正在爭奪更大的緩沖空間。但是，反饋效果仍然存在。占主導(dǎo)地位的流量將平均得到更多標(biāo)記的數(shù)據(jù)包，流量之間的吞吐量會因此分配得更公平。從圖4（c）可以明顯看出，當(dāng)最大值從65變化到200時(shí)，流量吞吐量之比從2.7下降到2.25。

總之，RED顯著提高了DCTCP和TCP流量之間的公平性。增加會降低公平性，增加可以提高公平性，但這是以增加為代價(jià)的，這不利于延遲敏感型業(yè)務(wù)。

圖4該圖顯示了當(dāng)瓶頸鏈路使用RED時(shí)長壽命DCTCP和TCP流的性能。（a）顯示=50和=100時(shí)的流量隨時(shí)間的吞吐量，（b）時(shí)，是的函數(shù)（c）顯示為的函數(shù)。

D.??? 使用CHOKe得TCP和DCTCP

我們現(xiàn)在評估CHOKeAQM下的DCTCP和TCP的性能。與RED相比，CHOKe的標(biāo)記政策更為公平。它通過將隊(duì)列中的隨機(jī)數(shù)據(jù)包與到達(dá)的數(shù)據(jù)包進(jìn)行比較來實(shí)現(xiàn)此目的。 如果它們都屬于同一個(gè)流，則兩個(gè)數(shù)據(jù)包都被標(biāo)記。 圖5（a）顯示了帶有ECN的CHOKe下的吞吐率。CHOKe賦予非主導(dǎo)流量的更高的懲罰，在CHOKe下，獲得了比RED下更高的吞吐量。雖然兩個(gè)數(shù)據(jù)包的標(biāo)記由于其較大的窗口大小而不會對DCTCP造成太大的影響，但是會導(dǎo)致TCP流的吞吐量大大降低，從而增加了。

圖5該圖顯示了在具有ECN的CHOKe下單個(gè)長壽命的DCTCP和TCP流的性能。 （a），（b）和（c）分別顯示了，平均隊(duì)列長度和α隨著變化的過程。

E.??? 使用改版CHOKe的TCP和DCTCP

我們現(xiàn)在考慮一個(gè)CHOKe的修改版本。使用這個(gè)版本，當(dāng)超過時(shí)，我們從隊(duì)列中隨機(jī)選擇“m”個(gè)數(shù)據(jù)包，看它們是否屬于與傳入數(shù)據(jù)包相同的數(shù)據(jù)流。這樣做是為了即使在CHOKe中，非主導(dǎo)協(xié)議流的數(shù)據(jù)包也有可能被頻繁地標(biāo)記出來。當(dāng)以這個(gè)標(biāo)準(zhǔn)檢查'm'包時(shí)，非支配流被標(biāo)記的可能性被降低。

圖6（a）顯示了修改后的CHOKe的。我們可以發(fā)現(xiàn)圖中顯示的公平性大大提高。當(dāng)為30時(shí)，為?1.5，當(dāng)增加到90時(shí)，增加到?2。發(fā)生這種情況的原因是在小的值處，DCTCP流的數(shù)據(jù)包受到更嚴(yán)重抵制的可能性相對于TCP增加，如圖6（b）所示，這相對于其他AQM方案改善了公平性。

由于DCTCP和TCP在RTT中只減少一次窗口，TCP在兩個(gè)不同的擁塞窗口實(shí)例中標(biāo)記數(shù)據(jù)包的概率甚至更低，所以TCP主要受到RED標(biāo)記的影響。 另一方面，DCTCP遭受的回退的頻率以及強(qiáng)度都有所增加。

根據(jù)等式4，當(dāng)退避因子是0.215（對應(yīng)于?= 40）時(shí)，應(yīng)該等于4.6。 但是，根據(jù)圖6（a）所示的評估結(jié)果，低于模型預(yù)測的結(jié)果。產(chǎn)生這種情況的關(guān)鍵原因是該模型假定協(xié)議流接收同步反饋（即具有相同的退避頻率）。一個(gè)回退小的流，使用相同的增加因子，卻觀察到更高的回退頻率。例如，在這些設(shè)置下，通過一次模擬運(yùn)行，我們發(fā)現(xiàn)DCTCP回退約1600次，平均回退系數(shù)為?0.215。 另一方面，即使采用0.5的更積極的退避因子，TCP也只退縮了大約400次。 這導(dǎo)致流量之間更公平的帶寬分配。

圖6 該圖顯示了在m= 7并啟用了ECN的CHOKe下的單個(gè)長壽命DCTCP和TCP流的性能。（a）和（b）分別表示Tr和DCTCPα隨著變化的過程。

總之，改進(jìn)的CHOKe通過更公平地標(biāo)記了控制主流的數(shù)據(jù)包，降低處理低吞吐量的流量的概率，改進(jìn)了RED。

Ⅴ. 數(shù)據(jù)中心特定的缺陷

我們現(xiàn)在用RED和CHOKe評估數(shù)據(jù)中心特定場景下DCTCP和TCP的性能。我們首先考慮TCPincast的情況。然后，我們考慮基準(zhǔn)設(shè)置，在這個(gè)基準(zhǔn)設(shè)置中，對延遲敏感的短流與長流流競爭[2]

A．TCP incast

設(shè)置包括幾臺連接到1 Gbps鏈路交換機(jī)的機(jī)器。一臺機(jī)器充當(dāng)客戶端，其余機(jī)器充當(dāng)服務(wù)器。客戶端向每個(gè)服務(wù)器請求1MB/ n的數(shù)據(jù)量，其中n是客戶端請求的服務(wù)器總數(shù)，服務(wù)器響應(yīng)。這導(dǎo)致了同步的反應(yīng)，并導(dǎo)致了眾所周知的incast現(xiàn)象[1]。在數(shù)據(jù)中心網(wǎng)絡(luò)中，我們始終保持一個(gè)長期的DCTCP流量和一個(gè)長期的TCP流量，這是數(shù)據(jù)中心網(wǎng)絡(luò)中常見的情況[2]。圖7顯示了平均流量完成時(shí)間（AFCT），作為incast發(fā)生情況下RED和CHOKe發(fā)送者數(shù)量的函數(shù)（注意，設(shè)置為70）。我們可以發(fā)現(xiàn)在RED和CHOKe下，DCTCP流量與的TCP流量相比，擁有較短的AFCT。 當(dāng)發(fā)送者數(shù)量很大時(shí)，AFCT的差別更大， 例如，當(dāng)有90個(gè)發(fā)送者時(shí)，TCP流的AFCT比DCTCP的大2倍以上。

圖7 該圖顯示了在RED和改進(jìn)的CHOKe的情況下DCTCP和TCP流的AFCT。 被設(shè)定為70。

B.??? 非incast情景

在這種情況下，我們生成兩個(gè)長期的背景流（一個(gè)TCP和一個(gè)DCTCP流）。此外，短流量以瓶頸容量的20％提供負(fù)載進(jìn)入網(wǎng)絡(luò);數(shù)據(jù)中心的現(xiàn)實(shí)負(fù)載。這個(gè)負(fù)載在TCP和DCTCP流之間平均分配（即每個(gè)10％）。短流的到達(dá)時(shí)間呈指數(shù)分布。 流量大小均勻分布在[10KB，50KB]，平均大小為30KB。圖8（a）和圖8（b）顯示，當(dāng)RED和CHOKe下降時(shí)，AFCT均下降。發(fā)生這種情況是因?yàn)槠骄?duì)列長度在減少時(shí)減少，這反過來又改善了流完成時(shí)間。與RED相比，經(jīng)修改的CHOKe在更高的下導(dǎo)致更公平的AFCT。

Ⅵ. 相關(guān)工作

學(xué)者們已經(jīng)提出了幾種協(xié)議和機(jī)制來允許異構(gòu)傳輸協(xié)議的共存。[14]，[15]建議將每個(gè)協(xié)議映射到一個(gè)單獨(dú)的隊(duì)列，并使用共享的加權(quán)處理器調(diào)度來自隊(duì)列的數(shù)據(jù)包。但是，這提出了復(fù)雜的管理問題，并且增加了不必要的成本。[16]使用一個(gè)單一的隊(duì)列，但建議對不同的協(xié)議使用不同的AQM。[17]提出在僅使用其中一個(gè)協(xié)議的孤島中使用協(xié)議。

Ⅶ. 結(jié)論

在本文中，我們研究了DCTCP和TCP的共存性質(zhì)。我們發(fā)現(xiàn)DCTCPAQM可能會導(dǎo)致TCP流量不足。我們的研究結(jié)果表明，在RED下，DCTCP明顯優(yōu)于TCP（至少2倍），適應(yīng)參數(shù)并不能提高公平性。我們發(fā)現(xiàn)CHOKe降低了公平性。 我們提出了CHOKe的修改版本，通過精確檢測主流，大大提高了公平性。 今后，我們計(jì)劃研究使用異構(gòu)應(yīng)用程序的實(shí)際測試平臺上的協(xié)議互操作性。在未來，我們計(jì)劃在一個(gè)使用異構(gòu)應(yīng)用程序的真正測試平臺上研究協(xié)議的互操作性。

?

文獻(xiàn)引用

[1] D.Abts and B. Felderman, “A guided tour of data-center networking,”Communications of the ACM, vol. 55, no. 6, pp. 44–51, Jun. 2012.
[2] M. Alizadeh,A. Greenberg, D. Maltz, J. Padhye, P. Patel, B. Prabhakar,S. Sengupta, and M. Sridharan, “Datacenter tcp (dctcp),” in ACMSIGCOMM’10.
[3] B.Vamanan, J. Hasan, and T. N. Vijaykumar, “Deadline-aware datacenter tcp(d2tcp),” in ACMSIGCOMM’12.
[4] C.-Y.Hong, M. Caesar, and P. B. Godfrey, “Finishing flows quickly withpreemptive scheduling,” in ACM SIGCOMM’12.
[5] A. Munir,I. A. Qazi, Z. A. Uzmi, A. Mushtaq, S. N. Ismail, M. S. Iqbal,and B. Khan, “Minimizing FlowCompletion Times in Data Centers,”in IEEEINFOCOM’13.
[6] M.Alizadeh, S. Yang, M. Sharif, S. Katti, N. McKeown, B. Prabhakar,and S. Shenker, “pfabric: Minimalnear-optimal datacenter transport,” inACM SIGCOMM’13.
[7] S. Floydand V. Jacobson, “Random early detection gateways for congestion avoidance,” inIEEE/ACMTransactions on Networking, 1(4):397-413,Aug 1993.
[8] R. Pan,B. Prabhakar, and K. Psounis, “Choke, a stateless active queuemanagement scheme for approximatingfair bandwidth allocation,” inIEEEINFOCOM’00.
[9] R.Shorten, F. Wirth, and D. Leith, “A positive systems model of TCPlikecongestion control: Asymptotic results,” IEEE/ACM Transactionson Networking, vol. 14, pp. 616–629, 2006.
[10] M.Corless and R. Shorten, “Deterministic and stochastic convergenceproperties of aimd algorithms withnonlinear back-off functions,” inAutomatica 2011.
[11] V.Vasudevan, A. Phanishayee, H. Shah, E. Krevat, D. Andersen,G. Ganger, G. Gibson, and B. Mueller,“Safe and effective finegrained tcp retransmissions for datacenter communication,”in ACMSIGCOMM’09.
[12] H. Wu,Z. Feng, C. Guo, and Y. Zhang, “Ictcp: Incast congestion controlfor tcp in data center networks,” in ACM CoNEXT’10.
[13] G.Appenzeller, I. Keslassy, and N. McKeown, “Sizing router buffers,”in ACM SIGCOMM’04.
[14] C. H.Tai, J. Zhu, and N. Dukkipati, “Making large scale deployment ofRCP practical for real networks,” in IEEE INFOCOM Mini-Conference,2008.
[15] N.Dukkipati, M. Kobayashi, R. Zhang-Shen, and N. McKeown, “Processor sharingflows in the internet,” in IWQoS,2005.
[16] I. A.Qazi, L. L. H. Andrew, and T. Znati, “Incremental deployment ofnew ECN-compatible congestion control,”in PFLDNeT, Tokyo, Japan,May 2009.
[17] D.Katabi, M. Handley, and C. Rohrs, “Internet congestion control forhigh bandwidth-delay product networks,”in ACMSIGCOMM’01.

總結(jié)

以上是生活随笔為你收集整理的On the coexistence of transport protocols in data centers的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。