論文信息：

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.

數據中心傳輸協議的共存

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

Ⅰ. 介紹

大規模數據中心的出現已經因為網絡搜索，社交網絡和廣告系統等大規模在線服務以及亞馬遜，谷歌和微軟等云計算服務提供商的崛起，轉變了計算格局[1]。這些數據中心具有獨特的網絡和流量特性，可以承載多種應用。在應用的多樣化要求下，為數據中心設計定制的傳輸協議[2][3] [4] [5] [6]應運而生。 例如，數據中心TCP（DCTCP）的設計是為了滿足軟實時應用的需求，如網絡搜索，廣告和零售[2]等

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

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

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

本文具有如下貢獻：

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

* 本文表明，雖然RED提高了公平性，但CHOKe實際上降低了它。我們建議對CHOKe進行修改，通過更準確地主導主流，提高性能。

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

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

Ⅱ DCTCP和AQM方案

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

A.??? 數據中心TCP

DCTCP [2]旨在通過使用標記數據包的一小部分對擁塞程度做出反應的方法，達到數據中心環境中的低延遲和高吞吐量的目標。當擁塞率低時，它使用一個小的補償因子。當擁塞增加時，它增加回退因子。DCTCP使用的最大退避因子是0.5。DCTCP用于確定退避因子的公式如下：

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

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

B.??? 主動隊列管理算法

DCTCP AQM：DCTCPAQM通過使用ECN設置Congestion Experienced（CE）位，在隊列長度超過某個閾值K時標記所有的數據包。 與RED不同，DCTCPAQM使用瞬時隊列長度，這會導致更主動的標記。

RED：REDAQM根據平均隊列長度qavg概率標記數據包。當qavg超過下限閾值時，它開始標記數據包。標記概率p線性增加，直到qavg超過最大值，達到：

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

? 代表最大標記概率。當大于時，RED百分百標記達到的數據包。

CHOKe：CHOKeAQM建立在RED的基礎上，通過包含基于流分類的優先標記/丟棄數據包的機制實現功能。當超過時，CHOKe從隊列中挑選一個隨機數據包，并檢查輸入數據包是否與隨機數據包具有相同的流。如果為true，則標記兩個數據包。否則，它使用等式（2）計算的概率標記傳入分組。如果超過，則標記數據包

Ⅲ. 協議共存

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

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

我們在這項工作中的目標是分析幾個常用的AQM對協議共存的影響。我們評估這些AQM如何能夠實現公平的丟棄/標記，使得協議性能的差異僅僅是由于它們的AIMD參數的差異，而不是交換機處的排隊動態。

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

我們現在只分析由于DCTCP和TCP使用的不同AIMD參數而引起預期的吞吐量差異。

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

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

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

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

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

Ⅳ. 具有不同AQMS的TCP和DCTCP

? 在本節中，我們評估DCTCP和TCP在共享瓶頸鏈接時的共存屬性。我們考慮包括RED，DCTCPAQM和CHOKe在內的幾個AQM，并將其與Drop-Tail隊列進行比較。

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

指標：我們使用以下兩個指標比較DCTCP和TCP的性能：

?公平性：設吞吐量比，其中和分別是DCTCP和TCP流實現的平均吞吐量。 注意= 1意味著兩個協議達到相同的吞吐量。

?系統效率：設總吞吐量，它是所有流吞吐量的總和。

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

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

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

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

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

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

總之，當DCTCP與DCTCP共存時，因為DCTCP的激進AQM和較小的回退因子，DCTCPAQM會導致TCP流非常低的吞吐量。而且，取決于標記閾值K。隨著K增加，和排隊延遲也增加。

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

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

圖4（a）顯示了當50，= 100時，DCTCP和TCP流的吞吐量隨著時間的變化。圖中顯示TCP比在使用DCTCPAQM時的吞吐量更好。但是，由于分組的概率標記和隨之而來的排隊行為，兩個流都表現出吞吐量的巨大波動。

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

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

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

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

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

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

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

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

我們現在考慮一個CHOKe的修改版本。使用這個版本，當超過時，我們從隊列中隨機選擇“m”個數據包，看它們是否屬于與傳入數據包相同的數據流。這樣做是為了即使在CHOKe中，非主導協議流的數據包也有可能被頻繁地標記出來。當以這個標準檢查'm'包時，非支配流被標記的可能性被降低。

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

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

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

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

總之，改進的CHOKe通過更公平地標記了控制主流的數據包，降低處理低吞吐量的流量的概率，改進了RED。

Ⅴ. 數據中心特定的缺陷

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

A．TCP incast

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

圖7 該圖顯示了在RED和改進的CHOKe的情況下DCTCP和TCP流的AFCT。 被設定為70。

B.??? 非incast情景

在這種情況下，我們生成兩個長期的背景流（一個TCP和一個DCTCP流）。此外，短流量以瓶頸容量的20％提供負載進入網絡;數據中心的現實負載。這個負載在TCP和DCTCP流之間平均分配（即每個10％）。短流的到達時間呈指數分布。 流量大小均勻分布在[10KB，50KB]，平均大小為30KB。圖8（a）和圖8（b）顯示，當RED和CHOKe下降時，AFCT均下降。發生這種情況是因為平均隊列長度在減少時減少，這反過來又改善了流完成時間。與RED相比，經修改的CHOKe在更高的下導致更公平的AFCT。

Ⅵ. 相關工作

學者們已經提出了幾種協議和機制來允許異構傳輸協議的共存。[14]，[15]建議將每個協議映射到一個單獨的隊列，并使用共享的加權處理器調度來自隊列的數據包。但是，這提出了復雜的管理問題，并且增加了不必要的成本。[16]使用一個單一的隊列，但建議對不同的協議使用不同的AQM。[17]提出在僅使用其中一個協議的孤島中使用協議。

Ⅶ. 結論

在本文中，我們研究了DCTCP和TCP的共存性質。我們發現DCTCPAQM可能會導致TCP流量不足。我們的研究結果表明，在RED下，DCTCP明顯優于TCP（至少2倍），適應參數并不能提高公平性。我們發現CHOKe降低了公平性。 我們提出了CHOKe的修改版本，通過精確檢測主流，大大提高了公平性。 今后，我們計劃研究使用異構應用程序的實際測試平臺上的協議互操作性。在未來，我們計劃在一個使用異構應用程序的真正測試平臺上研究協議的互操作性。

?

文獻引用

[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.

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。