摘要：雲資料中心託管不同的應用程式，將需要小的可預測延遲的工作負載與需要大的持續吞吐量的工作負載混合在一起。在這種環境下，當今最先進的TCP協議達不到要求。

一、背景

為了給使用者提供高質量的雲服務，許多大型網際網路企業,如微軟、谷歌、亞馬遜和阿里巴巴等，在全球修建了許多資料中心。在資料中心內部，數以萬計的伺服器通過高頻寬(10-100Gbps)低時延(0-100us)的資料中心網路(DataCenterNetwork，DCN)相連。資料中心內執行著很多對延遲敏感的實時應用，比如電商零售、搜尋、社交網路等。這些實時應用的使用者請求需要儘快得到響應，而較高的響應延遲將嚴重影響使用者體驗，降低公司的運營收入。

資料中心網路流量以其突發性著稱，當流量瞬間爆發時，極易在流量接收端產生擁塞(端點擁塞)。不恰當的路由也會導致網路內部流量不均衡，從而產生內部擁塞(鏈路擁塞)。網路擁塞般可以通過負載均衡機制來解決。一旦發生擁塞，流量的網路延遲和吞吐量都會受到影響，從而造成較長的應用響應時延和更差的使用者體驗。傳統資料中心的內部網路是有損網路(lossynetwork)，網路發生嚴重擁塞時交換機可以直接丟棄資料包。由於資料中心交換機的緩衝區較小，加之資料中心流量的突發性特點，擁塞丟包在資料中心十分常見。丟包的後果會造成較高的重傳時延，從而影響實時應用的效能。學術界與工業界都十分關注傳統有損資料中心網路的擁塞問題，採取了一系列擁塞控制機制，以降低網路中的排隊和擁塞丟包問題。即便如此,這些機制也很難完全避免擁塞丟包。著名的DCTCP協議在網路擁塞並不嚴重時可以有效控制交換機佇列長度，但是當出現大量併發連線時，DCTCP仍難以避免交換機緩衝區的溢位。

資料中心設計的一貫主題是使用低成本的商用元件構建高可用性、高效能的計算和儲存基礎架構。資料中心網路也出現了相應的趨勢。特別是，低成本交換機常見於機架頂部，以1Gbps的速度提供多達48個埠，價格低於2000美元，大致相當於一臺資料中心伺服器的價格。最近的一些研究建議設想使用構建在這些商用交換機上的新型架構來建立經濟、易於管理的資料中心。

軟實時應用程式，支援推動了大量資料中心建設的網路搜尋、零售、廣告和推薦系統。這些應用程式產生長短流的不同組合，並要求資料中心網路具備三個條件:
短流的低延遲、
高突發容忍度、
長流的高利用率。

DCTCP的作者們在一個6000臺伺服器規模的DC中調查了一個月，取樣了超過150TB的壓縮資料，總結流量模式如下：

1. 99.91%的流量是TCP協議貢獻的。
2. DC中long-lived flow(large traffic)與short-lived flow (small traffic) 並存：從flow數量上看， small flow佔絕大多數比例，但從流量的位元組數上看，絕大多數又由large flow貢獻。
3. Flow的併發程度越高，flow的尺寸越小。例如，在考慮所有flow的情況下，併發flow的中數為36；但如果只考慮大於1MB的flow，中數只有1，而且75%的情況下為2。

我們對一個6000臺伺服器的生產叢集進行了測量，並揭示了導致應用程式高延遲的缺陷，其根源在於TCP對資料中心交換機中可用的有限緩衝空間的需求。

二、要解決的問題

影響效能的現象有哪些，大約總結為以下三類：

1. Incast。指的是這樣一種現象：1個client向N個server同時傳送請求，client必須等待N個server的應答全部到達時才能進行下一步動作。N個伺服器中的多個同時向client傳送應答，多個同時到達的”應答”導致交換機快取溢位，從而丟包。這樣只有等server發生TCP重傳超時才能讓client繼續。這個現象同時損害高吞吐量和低延遲。目前對於Incast的已有研究表明，降低TCP RTO的粒度是比較有效的方案，但這並沒有解決所有問題。

2. Queue buildup。由於TCP傳送流量的“貪婪性”，可以導致網路流量的大幅振盪，因而表現在交換機佇列長度的大幅振盪。在佇列長度增高時，會有導致兩個副作用：small flow丟包產生incast、small flow在佇列中延遲較長時間（在1Gb網路中是1ms vs 12ms的區別）。

3. Buffer pressure。因為許多交換機上的快取是在埠間共享的。因此，某埠上short flow很容易因為缺少快取受到其他埠上的large flow的影響。

三、DCTCP工作原理

DCTCP的一個設計約束就是必須充分現有的硬體資源，這意味著不能定製硬體，只修改軟體，它的工作原理是這樣的：

1. 交換機。在交換機發現佇列長度超過某個閥值時，使用ECN中的CE標記通過的TCP segment。但與標準的ECN（RFC3168）的不同，這裡交換機的判斷依據不是平均佇列長度，而是當前佇列長度（instantaneous queue size）。這個設計的動機在於快速響應交換機的佇列長度變化，因為現代交換機許多都是shallow buffer的，如果不及時動作，可能在傳送方進行有效擁塞控制之前交換機就已經發生緩衝溢位了。

2. 接收方。接收到CE標記後的行為，也與RFC3168中所要求的有所不同：RFC要求接收者在接收到CWR之前都在回覆的報文中設定ECE標誌。但DCTCP只在對有CE標誌的報文的ACK中設定ECE。如原作者們所說，一個最簡單的實現方案是立刻確認每個收到的報文。但這樣就與延遲確認的基本機制衝突，會帶來一些副作用，為此，DCTCP作者引入了一個簡單的狀態機解決這個問題：延遲確認仍然保留，但在出現CE標誌，或者CE標誌消失時立即傳送確認，這兩種情況下不再延遲。這麼做的動機在於可以確切告知傳送方有多少TCP流量（一個序號範圍）幾乎觸發了“擁塞”，這個序號範圍的大小標誌了擁塞的程度。

3. 傳送方。接收到的ECE的傳送方，當然也與RFC3168做的不同。RFC要求：TCP減半擁塞視窗，但DCTCP則是按照“擁塞程度”縮小擁塞視窗。這麼做的原因在於，我們在上面的分析已經看到，大多數流量由少數的large flow構成，並且它們的併發度很小。如果過度減小擁塞視窗，就意味著交換機的buffer可能很快就進入了下溢的狀態。

DCTCP演算法有三個主要元件:

交換機處的簡單標記：DCTCP採用了一種非常簡單的主動佇列管理方案。只有一個引數，即標記閾值K。如果到達的資料包到達時佇列佔用率大於K，則使用CE碼點標記該資料包。否則不作標記。該方案確保了佇列超調可以快速通知源。大多數現代交換機採用的紅色標記方案可用於DCTCP。我們只需將低閾值和高閾值都設定為K，並根據瞬時值而不是平均佇列長度進行標記。

接收器的回覆：DCTCP接收器和TCP接收器之間的唯一區別是CE碼點中的資訊被傳回傳送方的方式。rfc3168宣告接收機在一系列ACK分組中設定ECN Echo標誌，直到它從傳送方（通過CWR標誌）接收到擁塞通知已被接收的確認為止。然而，DCTCP接收器試圖準確地將標記包的確切序列傳回傳送者。最簡單的方法是確認每個包，當且僅當包具有標記的CE碼點時設定ECN Echo標誌。
但是，由於各種原因，使用延遲ack非常重要，包括減少資料傳送方的負載。為了使用延遲ACK（每m個連續接收的包有一個累積ACK），DCTCP接收器使用圖10所示的普通兩狀態機來確定是否設定ECNEcho位。這些狀態對應於最後接收的分組是否用CE碼點標記。由於傳送方知道每個ACK覆蓋多少個包，因此它可以準確地重建接收方看到的標記執行。

傳送方的控制器：傳送方保持對標記的分組部分的估計，稱為α，其對於每個資料視窗(大約一個RTT)更新一次，如下所示:

α ← (1 − g) × α + g × F

其中F是在上一個資料視窗中標記的資料包的比例，0<g<1是在α的估計中給予新樣本相對於過去的權重。假設傳送方在佇列長度大於K時接收每個包的標記，而在佇列長度小於K時不接收任何標記，上等式表示α估計佇列大小大於K的概率。本質上，α接近0表示低擁塞水平，α接近1表示高擁塞水平。

DCTCP傳送器和TCP傳送器之間的唯一區別在於，它們在接收設定了ECN Echo標誌的ACK時如何作出反應。TCP的其他特性，如慢啟動、擁塞避免的附加增加或從資料包丟失中恢復，都保持不變。雖然TCP總是根據標記的ACK將其視窗大小縮減2倍，但DCTCP使用α：

cwnd ← cwnd × (1 − α/2)

因此，當α接近0(低擁塞)時，視窗僅略微減小。換句話說，一旦佇列超過K，DCTCP傳送方就開始逐漸減少他們的視窗。這就是DCTCP如何保持低佇列長度，同時仍然確保高吞吐量。當擁塞較高(α = 1)時，DCTCP將視窗減半，就像TCP一樣。

這樣，整個DCTCP有兩個引數需要調整：

1. g，用於評估擁塞概率，它的上限是1.386 / (2(C*RTT+K))^0.5

2. K，交換機判斷是否處於擁塞狀態的閥值，它的下限是 (C x RTT)/7

注意：
1.DCTCP不適用於WAN環境的擁塞控制方案。
2.DCTCP沒有考慮RCP的解決方案。