數據中心網絡TCP Incast問題研究

余雅君，劉 崢，徐明偉

清華大學 計算機科學與技術系，北京 100084

數據中心網絡TCP Incast問題研究

余雅君+，劉 崢，徐明偉

清華大學 計算機科學與技術系，北京 100084

目前傳統TCP協議不適用于數據中心的工作模式，因此當數據中心中出現常見的多對一流量模式時會產生TCP Incast問題，造成應用層可見吞吐量崩潰。結合數據中心特點，提出全面的解決方案是解決TCP Incast問題的研究目標。圍繞TCP Incast問題，深層次剖析了該問題發生的根源，簡要概述了該問題面臨的挑戰，介紹了基于該問題所構建的數學模型；從鏈路層、傳輸層和應用層角度分析并總結了近十年具有代表性的解決方案，從有效性、可部署性等不同角度對所列舉方案進行了全面對比，發現當前方案大都基于某個具體方面緩解該問題，均存在缺陷；最后提出了可行的解決該問題的研究方向，將關注點聚焦于SDN結合機器學習以及傳輸新協議。

數據中心網絡；TCP Incast問題；吞吐量崩潰

1 引言

隨著互聯網的發展，云計算服務提供商大量涌現。Amazon、Microsoft、Google等云計算服務提供商使用數據中心向用戶提供網絡搜索、存儲、電子商務和大規模通用計算等服務。現代數據中心承載著成千上萬的服務和應用程序，為了適應業務和服務的需求，數據中心已由當初的計算中心轉變為數據集群中心[1]。基于集群的存儲系統具有低成本、高可靠性、高可用性、可擴展性等優勢，如今已被廣泛部署到數據中心網絡（data center networks，DCN）中。這些存儲系統由一組網絡化的小型存儲服務器組成，數據分布在這些服務器中，以提高性能和可靠性，并通常采用分布/匯總的通信模式，實現數據可靠高效的傳輸。

然而，目前數據中心采用的存儲和通信模式導致了被稱為TCP Incast的問題。TCP Incast指的是在高帶寬、低延時、有限緩沖區的數據中心環境中，當客戶端向多個存儲服務器同時請求數據，服務器響應并向客戶端同時發送數據時，導致數據包總大小超過以太網交換機緩沖能力，出現災難性TCP吞吐量崩潰的現象。由于在數據中心中，多對一通信的場景很普遍，例如Google提出的用于大規模數據集并行運算的軟件架構MapReduce，而當前絕大多數數據中心仍使用TCP/IP協議用于節點之間的通信，這就使得TCP Incast成為一個普遍存在的問題。TCP Incast現象危害巨大，它不僅會造成鏈路帶寬資源的浪費，還會影響網絡服務的完成效率。基于Memcached架構分布式key-value存儲的Facebook系統每秒要處理幾十億的請求，同時存儲幾萬億的數據項，給全世界超過十億的用戶提供服務，最小化易發生的TCP Incast問題帶來的影響至關重要。不管是服務提供商還是客戶端都希望盡力避免TCP Incast問題，TCP Incast問題已經受到了學術界和工業界的廣泛關注。

TCP Incast問題產生的原因，從根本上講是由于傳統的TCP/IP協議在設計之初針對的是帶寬較低、延遲較大、地理分布廣泛而連接較為稀疏的互聯網，而TCP協議不能很好地適應數據中心網絡高帶寬、低延時、地理分布集中而連接密集的特點。另一方面，由于TCP/IP技術在互聯網中取得了巨大的成功，采用其他傳輸協議作為替代方案的過渡期較長，這使得TCP Incast問題的解決變得富有挑戰性。目前國內外學者的研究重點在于：基于TCP傳輸協議和以太網，解決或緩解不同于傳統網絡的數據中心網絡中TCP Incast問題帶來的影響，盡可能地提高端到端通信以及大容量存儲數據傳輸的網絡性能。目前已有的方案從不同角度出發嘗試解決TCP Incast問題，需要總結和比較它們之間存在的聯系和差異。同時，已有解決方案尚未從根本上解決問題，在安全性、開銷和通用性的問題上也需要進一步探討。

本文對TCP Incast問題進行整理分析。首先，對TCP Incast問題發生的根源進行剖析，將其總結為同步請求、觸發超時重傳、參數設置不匹配等幾種。在此基礎上對TCP Incast問題存在的挑戰進行了概括，將核心挑戰總結為傳輸協議遷移、數據中心復雜性、部署開銷等問題。接著，介紹已有的關于TCP Incast問題所構建的模型，這些模型為探究問題細節提供了理論基礎。由于TCP Incast問題既屬于一種特殊的鏈路擁塞，也涉及到傳輸層和應用層的性能，本文分別從鏈路層、傳輸層、應用層這三方面對目前已提出的解決TCP Incast問題的方案進行了詳細分析，并總結了實現機制和優缺點。在此基礎上，對這些方案的有效性、可部署性等特性進行了對比分析，從總體上總結了各類方案的優缺點。最后提出了解決TCPIncast問題的新思路。相比近幾年綜述類文章[2-3]，本文有針對性地分析和對比了解決方案，對該問題的描述、挑戰以及相關模型進行了系統性研究，同時還增加了基于SDN（software defined networking）改進方案的研究，并為后續工作提出了較可行的方案。

本文組織結構如下：第2章分析了TCP Incast問題；第3章對該問題的挑戰性進行概括；第4章探究了針對該問題所構建的模型；第5章對當前方案進行了分類研究；第6章對各種方案進行全面對比；第7章進行總結與展望。

2 TCP Incast問題

2.1 問題描述

2004年，Nagle等人在研究存儲集群使用分布式存取和實現線性存儲帶寬可擴展性時，發現在存儲系統中隨著目標存儲設備數量的增加，數據聚合帶寬開始減小，并存在吞吐量下降等問題，首先在分布式存儲系統PanFS中發現并提出了網絡傳輸的Incast問題[4]。

同步請求工作負載在如今商業集群中越來越普遍，例如在集群存儲系統中，多個存儲節點同時響應數據請求時；在Web搜索中，當多個站點幾乎同時響應搜索查詢時；在批處理作業中，如在MapReduce中的“shuffle”階段，來自多個Mapper的鍵值對被傳送到Reducer時。因此在許多典型的數據中心應用中都可能出現TCP Incast問題。

一般來說，TCP Incast問題指的是存在TCP傳輸性能下降的多對一流量模式。圖1展示了典型的TCP Incast場景。在該模式下，客戶端通過交換機連接到數據中心，同時該交換機與多臺服務器相連。客戶端向一個或多個服務器請求數據，數據從服務器發出，通過交換機，經過瓶頸鏈路到達客戶端，形成多對一模型。該模式中，客戶端一般請求較大邏輯塊大小（比如1 MB）的數據，而實際上數據是以較小的數據塊大小（比如32 KB）即服務請求單元（server request unit，SRU）分布式地存儲在很多服務器上。客戶端向存儲請求數據塊的服務器發送請求包，通過TCP服務請求，直到當前請求的所有SRU均成功被客戶端接收，即完成當前請求，則開始下一請求。

由于數據塊存儲位置較為分散，并發發送者數量較多，數據傳輸負載可能在瓶頸交換機出現緩沖區溢出，導致包丟失，并伴隨著TCP超時重傳。同時由于直到所有發送方完成當前數據塊的傳輸，才允許客戶端請求下一數據塊的機制（被稱為barrier synchronized[5]，下文稱為同步阻礙模式），使網絡出現長時間空閑，該低鏈路利用率現象也被稱為吞吐量崩潰，即TCP Incast問題。

2.2 問題原因與影響

TCP Incast問題造成吞吐量下降的直接原因主要由以下幾方面相互影響。

（1）某些流的擁塞窗口較小。由于數據中心RTT（round-trip time）量級小，當很多流在同一鏈路競爭時，及時反饋，擁塞控制機制迅速減小擁塞窗口。

（2）觸發超時重傳。當交換機隊列溢出時，多條流會發生丟包，又由于擁塞窗口小，某條流可能出現整個窗口丟包，不能觸發TCP快速重傳，只能超時重傳，導致吞吐量下降。

（3）同步阻礙模式影響。當同步請求中涉及的某個服務器處于超時階段時，其他服務器可以完成其響應的發送，但客戶端必須等待至少TCP最小超時重傳RTOmin（默認為200 ms）才能接收重傳響應，在此期間客戶端鏈路可能處于完全空閑狀態，網絡利用率顯著下降。

TCP Incast問題導致的災難性吞吐量崩潰可能會使用戶可見吞吐量低至客戶端帶寬容量的1%～10%，且每個請求的延遲可能高于200 ms，這將極大程度地影響延時敏感的在線應用程序，使系統響應緩慢，從而錯過流完成期限，對用戶體驗造成負面影響。同時，Incast模式下造成網絡資源的浪費，在影響用戶的同時，會造成服務提供商的損失。

因此，在數據中心中避免TCP Incast問題的出現可以提高網絡的傳輸效率，并提升用戶的服務質量。目前針對TCP Incast問題的具體解決方案有很多，本文將對這些方案分層具體分析并進行對比。

3 問題挑戰

由于數據中心網絡的特點及其復雜性，解決TCP Incast問題具有較強的挑戰性。

（1）傳輸協議遷移問題。如前文所說，數據中心數據的傳輸是基于TCP/IP傳輸協議，而該協議是針對傳統網絡特點設計，傳統網絡對網絡拓撲、鏈路利用率、交換機緩存大小等特性都未知，而數據中心主要集中管理，能獲取較全面的網絡信息，同時數據中心網絡流量模式不同于傳統網絡，因此當傳統TCP應用于數據中心網絡時存在很多弊端。

（2）應用需求差異。在數據中心網絡中，各應用需求不同，有帶寬饑餓的大流量，同時存在有嚴格完成時間期限的小流量。因此需要權衡數據中心在低延時敏感的小流量和高吞吐量敏感的大流量間的調度，盡可能滿足不同應用的需求。

（3）突發流實時性要求。數據中心中存在突發流，且數據中心中80%的流持續時間小于10 s[6]，即使采取相應的擁塞控制算法，可能來不及反饋就已經完成對該流的傳輸，因此實時性較強。

同時，現有的解決TCP Incast問題的方案很多，但仍存在問題：其一，現有方案著重點各不同，且不能從根本解決該問題。其二，現有方案在實際部署中存在各種挑戰，主要表現為以下幾點。

（1）硬件開銷。如較大的交換機緩沖區可以延緩TCP Incast問題發生，加倍緩沖區大小可以使連接的服務器數量翻倍。但增加交換機緩沖區大小會帶來巨大的成本，同時會帶來更難預測的端到端延時并增加同步重傳的可能性，從經濟角度和擴展性方面，該方案在實際中不可取。

（2）一致性問題。如以太網流量控制可緩解隊列壓力，但存在隊頭阻塞（head-of-line blocking）問題，影響其他正常流。同時由于交換機供應商不同，交換機實現存在不一致問題。

（3）附加不確定影響。通過減少TCPRTOmin的方法可提高吞吐量。但系統時鐘實現微秒級的分辨率依舊存在挑戰，同時若RTO（retransmission timeout）設置過小，會導致超時誤判，同樣造成不利影響，因此閾值的選取也存在權衡問題。

（4）場景局限性。TCP需適用于不同網絡和流量特性的多樣網絡，因此也使得TCP在特定網絡，利用本地特性，針對某一目的提升性能具有局限性。而當前TCP Incast部分解決方案不僅存在未較全面利用網絡特性問題，而且在全面考慮網絡場景方面也需完善。

因此，在基于傳統TCP/IP協議的數據中心網絡中，兼顧不同應用的需求，結合數據中心特點，提出適合大多數網絡環境而非特定網絡環境的TCP Incast問題的解決方案依舊存在較大挑戰，需進一步對該問題深入研究。

4 建模與分析

對于TCP Incast問題產生的原因，國內外學者從不同角度進行了建模分析。目前已有的TCP Incast模型可總結為實驗數據擬合模型、理論建模分析模型和解釋模型。這些模型從實驗、理論等方面較全面地分析了TCP Incast問題，研究了造成吞吐量崩潰的原因，以及相應參數對該問題的量化影響。在模型基礎上，相繼提出了相應的解決方案。

4.1 實驗數據擬合模型

2009年，文獻[7]在不同環境下調節參數并用已有的兩種工作負載進行多次實驗的重現；通過分析實驗結果，建立了簡單的平均吞吐量預測模型，給定數學公式，其中比例因子是根據實驗和經驗設置的；最后通過分析歸納了影響TCP Incast問題的因素。

通過利用文獻[8]中固定段工作負載，即服務器每次響應數據大小固定（如數據遷移），以及文獻[5]中的可變段工作負載，即客戶端請求數據量固定（如分布式存儲應用），兩種類型工作負載重現了實驗，分析了RTO和Delayed ACK機制的影響，并提出了吞吐量的量化模型。模型具體核心如下：

其中，目標網絡吞吐量G為發送者數量S與每個發送者發送的數據量D的乘積（即發送總量）除以傳輸總時間；傳輸總時間為網絡中無RTO事件發生（即無丟包）時傳輸所需的理想時間L與超時大約持續的時間r乘以傳輸過程中出現RTO時間的個數R的和；B為鏈路帶寬；avgMSS（average maximum segment size）為平均包大小；I為發送兩數據包之間的等待時間。R和L均為S的函數，函數的系數是通過實驗結果擬合得出。通過將該模型計算的吞吐量與實驗中實際吞吐量對比發現，該模型一定程度上可以模擬出吞吐量的變化。

通過模型分析，RTOmin值和包發送間隔時間I極大地影響了吞吐量，因此RTOmin較大時，應減小該值；RTOmin較小時，需控制發送包的間隔時間I以解決TCP Incast問題。但是，該模型建立過程中的模型參數過于依賴實驗數據，不具有普適性，同時部分參數（如avgMSS）在發送數據前難以獲取，且該模型未進行嚴格的數學證明，只是直觀上的解釋，實驗只針對兩種特定的工作負載和網絡環境，對于不同的應用、網絡設備、網絡拓撲等的適用性有待深入分析。

4.2 理論建模分析模型

通過模擬TCP動態傳輸過程[9]，TCP Incast問題造成吞吐量崩潰的原因可分為兩種超時類型：塊尾部超時（block tail timeout，BTTO）和塊頭部超時（block head timeout，BHTO）。

BTTO描述的是，當同步發送者較少，數據塊最后3個包中出現丟包時，由于接收3個重復ACK才快速重傳的機制將不會觸發快速重傳，而是等待RTO時長觸發超時重傳，因此造成吞吐量下降。

而當同步發送者數量較大時，會出現BHTO。這是由于當某些流較早完成傳輸，使這些流具有較大的發送窗口。每個流根據其窗口大小將分組注入網絡。由于同步發送者過多，容易超出緩沖區容量，導致其中一些包被丟棄。更加不幸的是可能丟失某窗口中所有包，無ACK包反饋，進入超時重傳階段。這便是同步發送者數量增大時，超時重傳主要發生在塊傳輸的開始，導致吞吐量急劇下降的原因。

通過分別對兩種類型的超時建模仿真，證明了Incast問題在發送者數量不同時，主導該問題產生的原因不同。并通過模擬實驗分析了發送者數量N、緩沖區大小B和鏈路容量C的影響，認為增大鏈路容量并不能緩解TCP Incast問題，而增大緩沖區可以延遲吞吐量下降。

然而，基于ACK包不會丟失，窗口同步變化等假設，使該建模分析具有一定的局限性，但不能否認其工作為解決TCP Incast問題提供的參考價值。

4.3 解釋模型

不同于上述擬合模型依賴實驗數據，分析模型依賴TCP版本，在文獻[10]中并未直接計算特定場景的吞吐量，而是對流控系統參數和相關機制變量的影響進行量化分析，提出解釋模型，理論分析參數對TCP Incast問題的影響，從而總結該問題產生的原因。

吞吐量Th定義為：

其中，N代表發送者數目；S為數據塊大小；C為鏈路容量；PTO為發生超時的可能性；τTO為超時持續時長。

通過實驗觀察發現，流量較多時主要發生全損超時（full loss timeout，FLT），類似于BHTO，且窗口大小w服從正態分布。

通過理論證明，在一個輪詢（round）中發生超時的可能性與平均窗口大小、標準差σw、丟包率 p有關，關系見式（6）。

假設每次輪詢中發生超時可能性相等，設一次傳輸中輪詢次數為R，得出傳輸超時可能性PTO，即式（7）。

從上面理論公式可以看出，關于吞吐量的定義考慮了所有關鍵系統參數和機制變量，如系統參數鏈路容量C、數據塊大小S、緩沖區大小B、機制變量RTOmin、平均窗口大小和窗口大小的標準差σw，并討論分析了它們對吞吐量的量化影響。

該模型較客觀量化分析了各參數對TCP Incast問題的影響，為該問題的研究提供了理論基礎。

5 TCP Incast問題解決方案

解決TCP Incast問題的方案可從不同的層面進行設計。一方面，通過數據中心網絡運行機制采取一定措施可避免TCP Incast問題的發生。首先，明確限制終端請求建立連接的數目，即控制多對一模式中“多”的數量；其次，盡可能地在本地實現計算，減少瓶頸交換機出現Incast問題的可能性；最后，實現集群中應用運行時間的分散化，不至于出現數據中心吞吐量崩潰問題。另一方面，從產生吞吐量崩潰的本質，即數據包的丟失出發，主要從避免或減少丟包以及發生丟包后實現快速重傳減小丟包影響兩方面來緩解該問題。

以上不同層面的解決方案可更加細粒度地劃分為鏈路層、傳輸層和應用層3個角度。接下來將從這3個角度，對TCP Incast問題的解決方案進行闡述以及歸納總結。

5.1 鏈路層

在數據中心的鏈路層，擁塞通知和流控是緩解TCP Incast問題的兩個主要方法。

5.1.1 擁塞通知方案

互聯網工程任務組（IETF）和IEEE 802.1工作組的數據中心橋接任務組致力于研究DCN中的擁塞通知方案以減少超時包數量。其中較典型的反向擁塞通知（backward congestion notification，BCN）[11]和量化擁塞通知（quantized congestion notification，QCN）[12]方案都是基于隊列長度的反饋擁塞控制方案。

（1）BCN

BCN主要思想為檢測核心交換機處是否發生擁塞。這些交換機配置有用于檢測擁塞的硬件監視器，并且源和擁塞節點相互協作。當監視到核心交換機輸出隊列出現擁塞，通過BCN消息告知源，該消息包括擁塞程度。源節點利用集成的速率調節器（例如，令牌桶流量整形器）更新流傳輸速率響應接收的BCN消息。BCN系統模型如圖2所示。

Fig.2 BCN model圖2BCN系統模型

（2）QCN

QCN主要包含兩個算法：交換機擁塞點（congestion point，CP）算法和速率限制器反應點（reaction point，RP）算法。CP算法的目的是將交換機緩沖占用維持在期望的水平。在當前速率非常小時，RP算法通過使用定時器收斂到高發送速率，能主動增加其速率以恢復丟失的帶寬并探測額外的可用帶寬。

BCN和QCN均在擁塞的交換機處對到達的包進行采樣并且向發送方發送反饋，根據隊列長度標識擁塞程度。BCN旨在保持高吞吐量，最小化隊列延遲，并實現相對公平。而QCN的目標是在數據鏈路層提供穩定、有效的擁塞控制。QCN在反饋消息產生的流量方面比BCN更有效，但QCN的鏈路利用率和吞吐量較低。這主要是在TCP Incast場景下流之間不公平性造成的。因此在QCN的基礎上針對公平性提出了兩種QCN改進方案。

（3）AF-QCN

AF-QCN（approximately fair QCN）[13]對QCN進行了修改，以保證更快的公平收斂，它不同于QCN中所有流均具有相同的擁塞反饋信息，它是根據估算的發送速率區分每條流，然后根據反饋信息調節每條流的發送速率。

（4）F-QCN

F-QCN（fair QCN）[14]主要用于改善共享瓶頸鏈路中多個流的公平性。它將QCN消息反饋給所有流的源端，源端根據流所占共享瓶頸鏈路容量比例調節發送速率，從而實現共享瓶頸鏈路的公平性。

以上方法都是通過檢測擁塞交換機，向發送方發送反饋，調節發送速率緩解擁塞。這些基于兩層實現的擁塞通知方案一定程度上能緩解TCP Incast問題，但效果不顯著。

5.1.2 流控機制

基于交換機實現流控也有相應方案。諸如以太網流控[8]和優先級流控[15]提供的流控機制可以有效地管理發送到單個交換機的聚合數據量，從而緩解TCP Incast問題。

（1）EFC

支持EFC（Ethernet flow control）的過載交換機可以向發送數據接口的擁塞緩沖區發送“暫停”幀，通知連接到該接口的所有設備在給定的時間內停止或轉發數據。在此期間，過載交換機可以減輕其隊列壓力。EFC對于所有客戶端和服務器連接到單個交換機時是有效的，然而由于交換機的先進先出（first in first out，FIFO）機制和隊頭阻塞，當擁塞緩沖區的暫停幀意圖停止導致擁塞的流時，它會同時阻塞其他正常流。同時由于交換機供應商不同，會導致交換機實現存在不一致問題。

（2）PFC

針對阻礙其他流問題，PFC（priority-based flow control）方案被提出。該方案將基本的PAUSE語義擴展到多個服務等級，使需要流控的應用能夠在提供流控功能的線路上表現更好，能有效地緩解Incast問題。

表1總結了鏈路層解決方案的本質及優缺點，這些方案主要根據交換機反饋或直接控制交換機緩解擁塞，很多研究通過改進先前方案不足實現更好的功能，其中PFC方案依舊被廣泛應用。

5.2 傳輸層

傳輸層緩解或解決TCP Incast問題的解決方案主要分為三大類：

（1）參數調整。改善DCN中TCP重傳的機制，使得重傳盡快執行，提升吞吐量。

（2）傳輸機制優化。通過改進擁塞控制，盡量避免或減少瓶頸鏈路交換機緩存區占滿的情況，減少丟包，降低TCP Incast問題發生概率。

（3）協議替換。通過采用其他傳輸協議，從根本上解決該問題中TCP協議帶來的弊端。

Table 1 Solutions comparison of link layer表1 鏈路層解決方案對比

5.2.1 參數調整

（1）減小RTOmin

數據中心中的RTT相比于以太網小2到3個數量級，使用默認的RTO會大大降低網絡的吞吐量。早在2008年之前，就已經有人提出減小TCP的RTO設置來緩解Incast造成的不利影響。該方案對于緩解Incast問題有一定的作用，但是存在兩個主要的缺陷：一是系統時間精度不夠，DCN中RTT往往是100 μs的量級，Linux系統難以支持這樣的精度，方案實現難度很大；二是RTO設置時間太短，容易造成誤判，導致誤超時，同樣對網絡造成不利的影響。2009年，Vasudevan等人在文獻[16]中提出了毫秒級別的RTO和隨機RTO方案，在文獻[5]中，使用高精度的系統時鐘，研究了RTO對Incast場景下吞吐量的影響，證明了該方案的改進能夠有效提升吞吐量。因此，可深入研究時間精度和誤超時問題。

（2）關閉DelayedACK機制

修改Delayed ACK機制的出現一般都是伴隨著減小RTO而產生的。Delayed ACK本來是試圖通過一個ACK來確認多個數據包，以此來減少網絡中ACK包的數量。但如果接收者收到一個包而沒有收到其他包，就會等待一個超時時間，再最終決定反饋一個ACK，這個超時時間一般是40 ms。當RTO減小時，若小于Delayed ACK的默認超時時間，就會造成誤超時，從而發生重傳。在文獻[5，16]中都研究了Delayed ACK對于網絡吞吐量的影響，發現若關閉DelayedACK機制，可提升一定的吞吐量，因此建議數據中心應當盡量避免粗粒度的DelayedACK機制。

然而在文獻[7]中，通過重現Delayed ACK修改方式，發現是否關閉DelayedACK對于RTT的均值沒有太大影響。原因就是關閉DelayedACK機制后，會造成很大的RTT波動，不會對RTT均值產生太大影響。該方法對解決TCP Incast問題的有效性較差，因此對該方案的有效性有待進一步研究。

（3）基于SDN初始參數動態調整

隨著SDN技術思想的提出和部署，2012年，利用SDN控制器掌握網絡拓撲等全局信息的特點，Ghobadi等人提出了OpenTCP[17]，其架構見圖3。其主要思想即SDN控制器統計網絡特性，并向ToR交換機發送擁塞更新信號（congestion update epistles，CUE），交換機再向終端反饋，作為內核模塊安裝在終端的擁塞控制代理（congestion control agent，CCA）根據相應信息調整TCP初始擁塞窗口（initial window，IW）以及超時重傳RTO參數，降低網絡丟包可能性以及丟包影響，從而緩解TCP Incast問題。2013年Jouet在文獻[18]中也提出了相同的思想，并給出了明確的參數計算公式。通過完善前期工作，2016年Jouet提出了OTCP（omniscient TCP）[19]，不同于之前工作，其主要著重于具體實現，明確通過SDN如何進行數據統計和反饋。

通過SDN獲取全局信息，調節TCP中IW和RTO參數能一定程度緩解該問題，為解決TCP Incast問題提供了全局視角，但由于網絡流量具有突發性，更新周期的確定也具有一定挑戰。

Fig.3 Frame of OpenTCP圖3OpenTCP架構

5.2.2 傳輸機制優化

（1）DCTCP

DCTCP（data center TCP）由 Alizadeh等人 2010年在文獻[1]中提出，屬于TCP的變體，改善數據中心中TCP存在的缺陷。主要思想是交換機通過隊列長度識別擁塞狀況，間接通過顯式擁塞通知（explicit congestion notification，ECN）作為反饋來調節發送端的發送速率，避免擁塞。DCTCP算法實現了突發流處理、低時延和高吞吐量，具體工作過程如下。

交換機預先被設置好一個閾值，當隊列長度超過這個閾值時，就會通過CE標記告知接收端，該數據包經歷了擁塞；然后接收端在ACK上打上ECN標簽，告訴發送方調節發送窗口；發送方就會根據記錄包中ECN標記比例數，通過相應方式調節發送窗口，控制發送速率，從而實現擁塞避免。

在傳統的TCP中，出現擁塞時會將發送窗口減半，而在DCTCP中，使用式（8）調節擁塞窗口：

其中，α為估計隊列長度的參數，范圍在0到1之間，代表擁塞程度。這種發送窗口的好處是可以在隊列過長時減小發送速率避免擁塞，而且將調節的幅度與擁塞程度聯系，不是每次都減半，這樣可以提升窗口恢復速度，從而提升吞吐量。

α依據式（9）計算：

其中，F為當前窗口內的包被標記ECN的比例；g（0～1）是當前擁塞程度占總擁塞程度的權重，可以通過調節該參數控制所需考慮當前擁塞的比重。從上面兩式可見F越大，即被標記比例越大，說明隊列越長，從而α越大，計算出的擁塞窗口越小。

該方案不僅對于Incast情景有很積極的作用，同時也適用于普通場景。然而DCTCP存在公平性和擴展性問題。有些服務不支持DCTCP，比如部署在文件服務器的應用。而當TCP和DCTCP共存時，DCTCP會完全占有主導地位，使用傳統TCP的服務吞吐量基本為0。并且由于交換機緩沖能力有限，當發送端數量超過一定數目時，DCTCP性能急劇下降，從而和傳統TCP相當。在文獻[20]中，為了實現DCN中全面的DCTCP部署，通過利用IP DSCP字段區分應用是否支持DCTCP，并且令SYN和SYN-ACK支持ECT，使得DCTCP成功建立連接可能性提高，并稱此方式為DCTCP+。

（2）ICTCP

與通過使用細粒度超時值（RTO）和DCTCP協議不同，ICTCP（Incast congestion control for TCP）[21]是2013年提出的基于網絡剩余帶寬和吞吐量來調節接收方的接收窗口的TCP Incast擁塞控制方案，該方法在丟包之前主動調整TCP接收窗口。相對于DCTCP基于每條流進行擁塞調節，ICTCP可在接收端考慮所有流占用帶寬情況，實現不同流之間的耦合進行擁塞控制。該算法原理如下。

首先根據鏈路容量C和測量帶寬BWT計算網絡剩余帶寬BWA：

其中，rwndi是該鏈路的接收窗口；RTTi是該鏈路的往返時延。

最后定義測量吞吐量和期望吞吐量的差與期望吞吐量的比值為調節接收窗口指標：

在剩余帶寬BWA足夠的情況下，根據指標調節接收窗口的方法為：

其中，α0、β、γ1、γ2是可控的調節系數和閾值，在實驗中均直接取固定值。實驗證明，這種通過接收窗口實時控制吞吐量的方式能夠有效避免擁塞，提升吞吐量。

ICTCP被設計為NDIS（network driver interface specification）驅動器，在操作系統的TCP/IP協議棧和網卡驅動器之間實現，并且只需要在接收端部署，使ICTCP不改變TCP/IP內核實現，支持更多的操作系統版本，并且支持目前在數據中心中廣泛應用的虛擬機。

雖然ICTCP能實現高吞吐量和低超時率，以及支持虛擬機，但它也具有一定的局限性。該算法是針對特定的Incast場景，當在其他網絡環境中或Incast場景下發送端數量較少時，吞吐量低于傳統TCP。由于只部署在接收端，導致只能解決邊沿Incast問題，即瓶頸鏈路位于接收端，而不能緩解核心交換機出現的Incast問題。

（3）PAC

2014年提出的PAC（proactive ACK control）[22]方案的主要思想是在接收方根據交換機緩存大小、鏈路狀況等信息控制ACK反饋包的發送速率，從而控制瓶頸鏈路流量大小，解決TCP Incast問題。通過利用ACK觸發發送，它能解決基于窗口方案發送端數目可擴展問題。同時由于它不改變交換機和協議棧，也不存在基于恢復方案中存在的部署、開銷等問題。

PAC的主要算法思想較簡單，即主動控制ACK發送速率保證in-flight流量不超過一定閾值threshold，從而避免Incast擁塞并保持較高的鏈路利用率。因此主要包括三方面：（1）閾值的設置；（2）in-flight流量的估計；（3）ACK包的調度。由于數據中心的低帶寬延時積，初始化閾值為交換機緩存大小，其變化公式如下：其中，考慮到核心網絡雖然經歷擁塞可能性較小，但依舊會經歷持久擁塞，因此利用ECN設置了擁塞指示參數α來調節閾值大小。

in-flight流量的估計主要分為兩部分。

①發送ACK包時

這里是以TCP Reno為例，其中ACKq、ACKprev分別代表PAC需要釋放和上次釋放ACK包的包序號；Increment的值與慢啟動或擁塞避免階段有關，并根據擁塞窗口改變。

②接收包時

其中，L為收到包的長度。

由于數據中心網絡中流量的多樣性，在流量大小未知的情況下為實現自適應調度，巧妙地通過不同優先級隊列執行MLFQ（multi-level feedback queue）實現了不同流的ACK自適應調度。該方案的實現類似于ICTCP的實現，在Windows平臺將PAC設計為NDIS驅動，在Linux平臺將PAC實現為內核模塊。

通過實驗，得出PAC性能優于ICTCP、DCTCP大概40多倍的結論，但同式（17）所示，該算法與慢啟動、擁塞避免機制相關，因此會限制可支持的擁塞避免算法。同時由于利用ACK包觸發機制，該算法需考慮DelayedACK機制的影響。

（4）PS

2015年黃家瑋等人針對大量并行TCP流傳輸場景提出了PS（packet slicing）方案[23]。該方案結合擁塞窗口和包大小的相關性，根據實時網絡狀態，在交換機分析計算并通過發送ICMP（Internet control message protocol）消息告知發送方最佳包大小，以減小整個窗口包丟失的可能性。

TCP超時主要是因為整個窗口的包丟失，所以將整個窗口包丟失的概率近似為該流出現超時的概率p，有：

則發生TCP Incast的可能性P即n條流中至少一條流發生超時的概率，因此

其中，B為緩存大小；n為流數；s為包大小；w為每條流的擁塞窗口大小。

通過分析可知，減小包的大小比減小窗口能更有效地緩解TCP Incast問題。由于減小包大小會帶來包頭開銷，將實際吞吐量G進行如下量化：

其中，LD和LH分別代表包有效負載和包頭長度；k為調節的分片因子；C和RTTmin分別代表鏈路容量和傳播時延。

通過k?調節包大小減小了Incast發生的可能性，且只部署在ToR交換機上，兼容不同TCP版本，但該方案存在一些不可忽視的問題。首先包大小的計算是基于每條流在每個服務器的包個數為均勻分布，即窗口大小相等的假設，然而由于網絡的動態性，每個服務器的窗口大小都是動態變化的；其次在當前較廉價的商用交換機上實現包大小的計算并發送消息，會增加交換機開銷；同時減小包大小降低Incast可能性帶來的增益與增加的包頭開銷難以衡量。

（5）CP機制

CP（cutting payload）機制[24]是一種丟棄負載的方式，主要在以下三方面分別實現，工作原理如圖4所示。

交換機：當交換機緩沖區過載時，把包的有效負載丟棄，但保留包頭部分，如圖中包4和5；接收端：根據包頭中五元組等信息設置PACK（precise ACK）包，明確告知發送方哪些包經歷擁塞；發送端：根據PACK包選擇相應的調節策略和重發機制。

Fig.4 CP mechanism圖4 CP機制示意圖

由于平均包長為864 Byte，而包頭只占66 Byte，因而在一定程度上通過減小包大小增加交換機中包的數量，并明確告知發送方需重傳的包，能有效地改善吞吐量等問題。

（6）GIP

2013年，張嬌等人在2011年的理論建模分析模型（見4.2節）的基礎上提出了GIP（guaranteeing important packets）[25]，一種TCP增強協議。同樣認為Incast場景下造成吞吐量下降的主要原因為兩種超時：FLoss-TO（full window loss timeout）和LAck-TO（lack of ACK timeout），分別對應于4.2節中的BHTO和BTTO。

GIP針對兩種類型的超時提出了兩種緩解機制。根據造成兩種超時的根本原因，GIP機制首先在每個塊單元開始發送時，減小每個發送者的擁塞窗口初始值避免FLoss-TO；另外，通過冗余傳輸塊單元的最后一個包避免LAck-TO。

GIP在應用層和傳輸層間使用flags接口標識當前應用是否為Incast通信模式，在端主機上只需較小改動，且不影響其他基于TCP的應用，從而GIP具有較好的兼容性。然而當同步發送者較少時，第一個機制會導致瓶頸鏈路利用率不高，即GIP只適合發送者較多的Incast場景。

（7）TCP PLATO

為解決超時重傳導致吞吐量下降的影響，Shukla等人于2014年提出了包標記系統PLATO（packet labelling to alleviate time-out）[26]，它基于 NewReno 實現，不同之處主要為丟包檢測機制。

在不考慮ECN和選擇性確認（selective ACK，SACK）技術時，傳統TCP有兩種常用機制處理丟包重傳：第一種為超時重傳，第二種為快速重傳。當出現丟包時，后者不需要等待RTO時長，且后者鏈路帶寬平均利用率較高，因此PLATO的主要思想即保證系統丟包的快速重傳而非超時重傳。

在系統中存在3種主要的丟包不能觸發快速重傳：（1）阻塞丟包，窗口內所有包丟失；（2）尾部丟包，TCP流最后3個包中的某幾個包丟失；（3）再次丟包，重傳包丟失。PLATO主要針對以上情況提出了包標記機制，在發送端根據系統狀態機決定是否發送被標記的包（核心包），接收端接收到核心包時返回被標記的ACK包，其中假設交換機不會丟棄核心包，源端有無限包需轉發。該機制下可保證發生丟包時發送方會收到至少3個重復ACK包進入快速重傳。

PLATO通過改變IP包頭的DSCP字段實現包的標記，要求交換機支持加權隨機早期檢測（weighted random early detection，WRED）。該機制需要改動源端和目的端，且是出現丟包后的處理機制，網絡已出現較嚴重擁塞，并未從根本上解決TCP Incast問題。

5.2.3 基于編碼的UDP

2012年在文獻[27]中，作者另辟蹊徑，沒有追隨前人減小RTO或增強TCP協議來解決Incast問題的方案，而是想從根本上去除Incast場景中TCP方式的弊端，緩解Incast帶來的影響。UDP沒有超時和重傳機制，因此使用改造UDP的方式來代替TCP。

修改UDP協議代替TCP主要有兩個挑戰：第一個挑戰是UDP沒有可靠傳輸保障和避免亂序保障；第二個挑戰是無擁塞控制。

對于前者，使用LT（Luby transform）碼解決，利用數據冗余換取可靠傳輸，同時解決了UDP包亂序的問題；對于后者使用TFRC（TCP friendly rate control）進行擁塞控制。具體過程為：首先通過TCP建立連接，傳輸控制信息；然后客戶端向多個服務器同時請求數據（即Incast場景），服務器對數據進行LT編碼，再通過UDP發送編碼后的數據；同時TFRC部署在服務器和客戶端上進行擁塞控制，一旦客戶端成功解碼，則向服務器發送終止信息，完成數據傳輸。

這種方式雖能夠解決Incast問題，但存在很多缺點。首先是信息冗余，編碼過程會帶入一些信息的冗余開銷；再者是使用了新的傳輸層協議，而且使用新的擁塞控制算法，需要在客戶端和服務器端都做相應的更改，這在真實場景中不易部署。

表2對傳輸層解決方案的機制本質和優缺點進行了總結。這些方案分別從減小超時影響，避免超時以及替換TCP角度出發，能一定程度緩解TCP Incast問題，其中DCTCP受到廣泛認可，而其他方案暫時處于研究階段。

Table 2 Solutions comparison of transport layer表2 傳輸層解決方案對比

5.3 應用層

2007年Krevat等人在文獻[28]中針對Incast問題提出了限制并發流數、交錯數據傳輸、數據傳輸的全局調度等應用層解決角度的建議。近幾年基于以上角度，提出了很多應用層解決方案。

（1）XCo

XCo[29]是對數據中心中廣泛應用的虛擬機的網絡傳輸進行協調，實現避免擁塞以及吞吐量崩潰問題。XCo架構思想是一個或多個控制器與網絡相連，控制器掌握互聯拓撲，當前流量矩陣，虛擬機的優先級、帶寬、響應時間等策略需求，并周期性地給虛擬機協調器下達傳輸指令，協調網絡中多個虛擬機的傳輸速率，使得提高網絡利用率的同時，能保證發送的數據不會超過交換機的緩存。該方案與5.2節利用SDN技術類似，但存在本質區別。

文中利用循環掩碼提出了相應的時間調度算法，控制每個時間段激活主機的數目，從而實現擁塞避免。該架構也支持其他調度策略，如速率調度。

XCo架構不改變應用、協議或網絡交換機，支持任意拓撲，能從源頭解決TCP Incast問題，但數據中心網絡中時延特性不可忽視；同時，該架構的容錯性、協調開銷也是必須考慮的方面。

（2）交錯流

文獻[30]在應用層提出了一種可以避免Incast問題發生的可擴展方法。從網絡中所有流的微觀角度來看，每條流的數據包到達接收端的時間是不同的，但是由于相鄰時刻的間隔非常小，使得這些流看起來是并發的。如果能使得這些流交錯發生，并使得流的間隔周期足夠長，那么這些流就不會出現相互沖突，從而緩解交換機隊列的壓力。

文中提出的方法定義了round的概念（見圖5），即每個發送端完成一個SRU傳輸，接收端收到所請求的當前數據塊的時間周期。然后，在每一個round時間內，人為地在每個相鄰的數據流傳輸開始點之間插入一個交錯時間長度（見圖6），來實現流的交錯傳輸。直觀上即可推出，交錯時間長度越接近一個SRU的傳輸時間，性能越好。

Fig.5 Pattern of concurrent flow圖5 并發流傳輸模式示意圖

Fig.6 Pattern of asynchronous flow圖6 交錯流傳輸模式示意圖

通過阻止并發流的傳輸可有效緩解交換機壓力，然而由于網絡環境的復雜性，很難對網絡中的交錯時間長度進行估計，且接收方向發送方逐一請求數據會帶來不可忽視的請求時間開銷，一定程度上會增大流完成時間。

（3）并行連接限制

文獻[31]指出將網絡中最大并發連接數限制到預設值的方法不適用于SRU很小的情況，且最大連接數量無法優化，可能導致即使Incast沒有發生，仍出現網絡吞吐量很小的情況，文中提出了一種對任意SRU大小適用且最大連接數量可優化的方法。

由于客戶端利用帶寬延時積BaseBDP（瓶頸鏈路帶寬C與傳播時延BaseRTT的乘積）作為其接收窗口，因此每個服務器發送窗口sendwin為：

假設初始擁塞窗口設置為2，由于慢啟動機制，發送窗口的初始遞增階段時長T1和到達BaseBDP開始至連接結束時長T2可由以下公式分別計算：

其中，S為SRU大小。

分析式（28），可發現當SRU很小時，T2很小，因此導致帶寬利用率較小。于是在上述完全序列化方法（交錯時間=SRU傳輸時間）的基礎上盡可能避免未充分利用階段提出了近似完全序列化方法，即在當前連接已發送一定數據量時，便建立新的連接，同時設置交疊參數K限制并發流交疊數。但是當SRU小于某個閾值時，由于式（30）限制，并不能采用該方法，從而又提出了最優序列化方法，當SRU小于某閾值x時，將網絡中n個連接作為一個集合，視為一個連接，實現在不產生Incast問題下吞吐量的最大化。

因為近似序列化方法中限制條件為T2≥2×T1，即

因此當S不滿足式（30）時，采用最優序列化方法，通過式（31）求出耦合流數nmin：

該3種方法的結合使得控制連接間隔時間是對于任意的SRU大小定義的，同時建立連接的數量是可優化的，因此通過控制連接間隔時間與并行連接數實現高吞吐量。

（4）ARS

2016年黃家瑋教授等人在解釋模型（見4.3節）和2015年提出的PS方案（見5.2節）基礎上又提出了一種跨層（核心為應用層）的設計方案ARS[32]（adaptive request schedule），實現自適應的請求調度。ARS根據從傳輸層獲得的擁塞狀態來分批處理應用層請求，采用動態調節并發的TCP流數量來解決Incast問題。

造成TCP超時的主要原因是由于整個窗口的包丟失[8]，文中計算了整個窗口包丟失的可能性即超時可能性PTO：

因此n條流中至少一條流經歷超時，發生Incast的可能性P為：

其中，C為鏈路容量；RTTmin為往返傳播時延；B為交換機緩存大小；MSS為TCP段大小；n為流數；w為平均擁塞窗口大小。

相對于5.2節中的PS方案，ARS假設每個包的大小固定為1MSS。通過式（34）可知，發生Incast的可能性P與擁塞窗口w和流數n相關。通過理論分析和實驗證明，相比于減小擁塞窗口，控制流數能更有效地解決TCP Incast問題。文中將包亂序作為擁塞的一個指標。

從應用層角度來說，ARS不需要修改下層協議和硬件，且只部署在聚合層，具有較強的適用性和兼容性，但方案針對性太強。

表3對應用層解決方案的機制本質和優缺點進行了總結。

Table 3 Solutions comparison of application layer表3 應用層解決方案對比

6 方案對比

表4從不同角度整體分析了上文涉及的方案。其中L、M、H分別代表低、中、高程度；“—”代表不予以討論；“√”、“×”分別代表是與否。公平性代表采用不同方案的流相互競爭時帶寬分配的公平性，而部分方案如應用層方案涉及系統中所有流，因此公平性不予以討論。

從表4中可以發現，針對TCP Incast問題，鏈路層解決方案的有效性較低，這主要是因為鏈路層的主要手段是擁塞反饋。可以看出，目前較被看好的解決方案已從鏈路層轉向傳輸層和應用層，其中傳輸層研究占較大比例。傳輸層方案的主要問題在于需要改變TCP協議棧或交換機。例如DCTCP和ICTCP方案，兩者都能較高效地緩解TCP Incast問題，但都只適用于較小規模的同步發送者情況。DCTCP需要修改協議棧且要求終端和交換機支持ECN，而ICTCP需在接收端部署相應的驅動器。應用層方案對底層改動較小，使其可部署性整體優于傳輸層方案。應用層方案的問題主要在于需較全面的流信息、操作的復雜性以及開銷的控制。

7 總結與展望

TCP Incast問題本質是一種特殊的擁塞現象，而這種現象在數據中心中較為常見，因此在設計較全面的擁塞控制方案時必須評估常見場景下該解決方案的性能。由于數據中心環境的復雜性，會更多地考慮解決方案的開銷、適用性以及可部署性。

從全文可知，針對TCP Incast問題，在解決精度和誤判情況下，減小RTOmin能有效改善吞吐量，并且控制流并發數以及包大小比控制擁塞窗口更有效。當前數據中心中DCTCP及其優化方案被廣泛認可，早期提出的PFC作為路由控制方案也被廣泛應用，其他方案主要處于學術界研究階段，其部署還依賴于工業界的推進。但結合數據中心環境，有效解決TCP Incast問題更多的建議是采用應用層方案。

Table 4 Comparison of all solutions表4 解決方案對比表

當前解決方案或多或少都存在一些弊端：（1）可擴展性不強，如增大交換機緩存等只能一定程度緩解TCP Incast問題；（2）通用性不強，如實現細粒度RTOmin可能會造成虛假重傳，與其他屬性相互依賴；（3）適用場景局限性，如ICTCP等方案過于依賴系數的選取，靈活性不強，適用場景有限；（4）部署開銷問題，如UDP變體存在冗余開銷，預替換傳統TCP協議需要較長過渡期。

鑒于對方案的分析，結合當前學術界和工業界關注的熱點，總結了針對TCP Incast問題未來可能的研究方向。

（1）現有技術交叉融合

①機器學習

很多方案依賴系數的選取，人們可利用機器學習，建立參數間的相關性，在終端設計調節參數的控制模型。例如微軟實現的Pingmesh[33]每天會生成超過2 000億的探針，產生24 TB的數據，可復用這些數據，利用機器學習分析數據特征，如周期性等，更好地控制網絡狀態，避免TCP Incast問題。

②SDN技術+在線機器學習

5.2節中有相關方案運用SDN技術解決TCP Incast問題，使利用全局網絡狀態信息進行擁塞控制成為可能，可通過部署相應代理或設計接口調節TCP參數。前文方案主要是調節IW和RTO兩個參數，而部分流實時性較強，系數的選取也很關鍵，該方案仍有較大缺陷。而單獨的機器學習依賴于探針產生數據，如果結合兩者，可利用機器學習分析控制器統計的網絡特性進行實時反饋改善突發流性能，但處理相對更復雜。阿里巴巴基于Flink的系統Blink（https://data-artisans.com/blog/blink-flink-alibaba-search）中在線機器學習模型可將實時用戶行為數據反饋到系統，該平臺已經運行1年，并在去年雙11中為用戶提供了更好的服務，若將該技術與SDN相結合，有望有效改善TCP Incast問題。

（2）設計新的傳輸協議

另一種可行的思路是設計一種適合數據中心的傳輸層協議來替代TCP，避免TCP Incast問題。近幾年Google也提出了基于UDP的QUIC協議（quick UDP Internet connection）[34]，目前在Chrome瀏覽器和YouTube等Google服務器已支持，且正推進IETF標準化工作。重新設計傳輸協議能夠以較小的開銷有針對性地克服一些問題，例如QUIC協議采用多路復用來解決隊頭阻塞問題。考慮在下一步的工作中利用QUIC協議中較大范圍的NACK（negative ACK，類似于TCP中SACK）以及更詳細的延時反饋信息來解決TCP Incast問題。

（3）新型架構與硬件設備

從交換機硬件設施入手，通過合理的體系結構設計解決根本的阻塞等問題。例如，Samadi等人提出了在光纖網絡中結合分組交換與電路交換的混合網絡架構，其中采用的光交換機（optical space switches，OSS）[35]也是解決TCP Incast問題的有力補充。

[1]Alizadeh M,Greenberg A,Maltz D A,et al.Data center TCP(DCTCP)[J].ACM SIGCOMM Computer Communication Review,2010,40(4):63-74.

[2]Zhang Yan,Ansari N.On architecture design,congestion notification,TCP Incast and power consumption in data centers[J].IEEE Communications Surveys&Tutorials,2013,15(1):39-64.

[3]Rojas-Cessa R,Kaymak Y,Dong Ziqian.Schemes for fast transmission of flows in data center networks[J].IEEE Communications Surveys&Tutorials,2015,17(3):1391-1422.

[4]Nagle D,Serenyi D,Matthews A.The panasas active scale storage cluster—delivering scalable high bandwidth storage[C]//Proceedings of the 2004 Conference on Supercomputing,Pittsburgh,USA,Nov 6-12,2004.Washington:IEEE Computer Society,2004:53.

[5]Vasudevan V,Phanishayee A,Shah H,et al.Safe and effective fine-grained TCP retransmissions for datacenter communication[J].ACM SIGCOMM Computer Communication Review,2009,39(4):303-314.

[6]Kandula S,Sengupta S,Greenberg A,et al.The nature of data center traffic:measurements&analysis[C]//Proceedings of the 9th ACM SIGCOMM Internet Measurement Conference,Chicago,USA,Nov 4-6,2009.New York:ACM,2009:202-208.

[7]Chen Yanpei,Griffith R,Liu Junda,et al.Understanding TCP Incast throughput collapse in data center networks[C]//Proceedings of the 1st ACM SIGCOMM 2009 Workshop on Research on Enterprise Networking,Barcelona,Spain,Aug 21,2009.New York:ACM,2009:73-82.

[8]Phanishayee A,Krevat E,Vasudevan V,et al.Measurement and analysis of TCP throughput collapse in cluster-based storage systems[C]//Proceedings of the 6th USENIX Conference on File and Storage Technologies,San Jose,USA,Feb 26-29,2008.Berkeley,USA:USENIX Association,2008:175-188.

[9]Zhang Jiao,Ren Fengyuan,Lin Chuang.Modeling and understanding TCP incast in data center networks[C]//Proceedings of the 30th International Conference on Computer Communications,Joint Conference of the IEEE Computer and Communications Societies,Shanghai,Apr 10-11,2011.Piscataway,USA:IEEE,2011:1377-1385.

[10]Chen Wen,Ren Fengyuan,Xie Jing,et al.Comprehensive understanding of TCP Incast problem[C]//Proceedings of the 2015 Conference on Computer Communications,Hong Kong,China,Apr 26-May 1,2015.Piscataway,USA:IEEE,2015:1688-1696.

[11]Bergamasco D.Data center Ethernet congestion management:backward congestion notification[C]//IEEE 802.1 Interim Meeting,Berlin,Germany,May 12,2005.Piscataway,USA:IEEE,2015:1-25.

[12]Alizadeh M,Atikoglu B,Kabbani A,et al.Data center transport mechanisms:congestion control theory and IEEE standardization[C]//Proceedings of the 46th Annual Allerton Conference on Communication,Control,and Computing,Urbana-Champaign,USA,Sep 23-26,2008.Piscataway,USA:IEEE,2008:1270-1277.

[13]KabbaniA,Alizadeh M,Yasuda M,et al.AF-QCN:approximate fairness with quantized congestion notification for multi-tenanted data centers[C]//Proceedings of the 18th Annual Symposium on High Performance Interconnects,Moun-tain View,USA,Aug 18-20,2010.Washington:IEEE Computer Society,2010:58-65.

[14]Zhang Yan,Ansari N.On mitigating TCP Incast in data center networks[C]//Proceedings of the 30th International Conference on Computer Communications,Joint Conference of the IEEE Computer and Communications Societies,Shanghai,Apr 10-15,2011.Piscataway,USA:IEEE,2011:51-55.

[15]Priority flow control:build reliable layer 2 infrastructure[EB/OL].San Jose:Cisco Systems,Inc.(2009-06-15)[2017-03-20].http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white_paper_c11-542809.html.

[16]Vasudevan V,Phanishayee A,Shah H,et al.A(In)cast of thousands:scaling datacenter TCP to kiloservers and gigabits,CMU-PDL-09-101[R].Pittsburgh:Carnegie Mellon University,2009.

[17]Ghobadi M,Yeganeh S H,Ganjali Y.Rethinking end-to-end congestion control in software-defined networks[C]//Proceedings of the 11th Workshop on Hot Topics in Networks,Redmond,USA,Oct 29-30,2012.New York:ACM,2012:61-66.

[18]Jouet S,Pezaros D P.Measurement-based TCP parameter tuning in cloud data centers[C]//Proceedings of the 21st IEEE International Conference on Network Protocols,G?ttingen,Germany,Oct 7-10,2013.Piscataway,USA:IEEE,2013:1-3.

[19]Jouet S,Perkins C,Pezaros D.OTCP:SDN-managed congestion control for data center networks[C]//Proceedings of the 2016 Network Operations and Management Symposium,Istanbul,Turkey,Apr 25-29,2016.Piscataway,USA:IEEE,2016:171-179.

[20]Judd G.Attaining the promise and avoiding the pitfalls of TCP in the datacenter[C]//Proceedings of the 12th Symposium on Networked Systems Design and Implementation,Oakland,USA,May 4-6,2015.Berkeley,USA:USENIX Association,2015:145-157.

[21]Wu Haitao,Feng Zhenqian,Guo Chuanxiong,et al.ICTCP:Incast congestion control for TCP in data-center networks[J].IEEE/ACMTransactions on Networking,2013,21(2):345-358.

[22]Bai Wei,Chen Kai,Wu Haitao,et al.PAC:taming TCP Incast congestion using proactive ACK control[C]//Proceedings of the 22nd International Conference on Network Protocols,Raleigh,USA,Oct 21-24,2014.Washington:IEEE Computer Society,2014:385-396.

[23]Huang Jiawei,Huang Yi,Wang Jianxin,et al.Packet slicing for highly concurrent TCPs in data center networks with COTS switches[C]//Proceedings of the 23rd International Conference on Network Protocols,San Francisco,USA,Nov 10-13,2015.Washington:IEEE Computer Society,2015:22-31.

[24]Cheng Peng,Ren Fengyuan,Shu Ran,et al.Catch the whole lot in an action:rapid precise packet loss notification in data center[C]//Proceedings of the 11th Symposium on Networked Systems Design and Implementation,Seattle,USA,Apr 2-4,2014.Berkeley,USA:USENIX Association,2014:17-28.

[25]Zhang Jiao,Ren Fengyuan,Tang Li,et al.Taming TCP Incast throughput collapse in data center networks[C]//Proceedings of the 21st International Conference on Network Protocols,G?ttingen,Germany,Oct 7-10,2013.Piscataway,USA:IEEE,2013:1-10.

[26]Shukla S,Chan S,TamAS W,et al.TCP PLATO:packet labelling to alleviate time-out[J].IEEE Journal on Selected Areas in Communications,2014,32(1):65-76.

[27]Jiang Changlin,Li Dan,Xu Mingwei,et al.A coding-based approach to mitigate TCP Incast in data center networks[C]//Proceedings of the 32nd Conference on Distributed Computing Systems Workshops,Macau,China,Jun 18-21,2012.Washington:IEEE Computer Society,2012:29-34.

[28]Krevat E,Vasudevan V,Phanishayee A,et al.On applicationlevel approaches to avoiding TCP throughput collapse in cluster-based storage systems[C]//Proceedings of the 2nd International Petascale Data Storage Workshop,Reno,USA,Nov 11,2007.New York:ACM,2007:1-4.

[29]Rajanna V S,Shah S,Jahagirdar A,et al.XCo:explicit coordination for preventing congestion in data center ethernet[C]//Proceedings of the International Workshop on Storage Network Architecture 2010 and Parallel I/Os,Incline Village,USA,May 3,2010.Washington:IEEE Computer Society,2010:81-89.

[30]Yang Yukai,Abe H,Baba K,et al.A scalable approach to avoid Incast poblem from application layer[C]//Proceedings of the 37th Annual Computer Software and Applications Conference,Kyoto,Jul 22-26,2013.Washington:IEEE Computer Society,2013:713-718.

[31]Kajita K,Osada S,Fukushima Y,et al.Improvement of a TCP Incast avoidance method for data center networks[C]//Proceedings of the 2013 International Conference on ICT Convergence,Jeju,Korea,Oct 14-16,2013.Piscataway,USA:IEEE,2013:459-464.

[32]Huang Jiawei,He Tian,Huang Yi,et al.ARS:cross-layer adaptive request scheduling to mitigate TCP Incast in data center networks[C]//Proceedings of the 35th Annual IEEE International Conference on Computer Communications,San Francisco,USA,Apr 10-14,2016.Piscataway,USA:IEEE,2016:1-9.

[33]Guo Chuanxiong,Yuan Lihua,Xiang Dong,et al.Pingmesh:a large-scale system for data center network latency measurement and analysis[J].ACM SIGCOMM Computer Communication Review,2015,45(4):139-152.

[34]Hamilton R,Iyengar J,Swett I,et al.QUIC:a UDP-based secure and reliable transport for HTTP/2,draft-tsvwg-quicprotocol-02[R].The Internet Engineering Task Force,2016.

[35]Samadi P,Gupta V,Birand B,et al.Accelerating incast and multicast traffic delivery for data-intensive applications using physical layer optics[J].ACM SIGCOMM Computer Communication Review,2014,44(4):373-374.

YU Yajun was born in 1994.She is an M.S.candidate at Tsinghua University.Her research interests include transport protocol and congestion control,etc.

余雅君（1994—），女，安徽安慶人，清華大學計算機系碩士研究生，主要研究領域為傳輸協議，擁塞控制算法等。

LIU Zheng was born in 1989.He is a Ph.D.candidate at Tsinghua University.His research interests include Internet architecture,routing protocol and space network,etc.

劉崢（1989—），黑龍江哈爾濱人，清華大學計算機系博士研究生，主要研究領域為互聯網體系結構，路由協議，空間網絡路由機制等。

Research on TCPIncast in Data Center Networks

YU Yajun+,LIU Zheng,XU Mingwei
Department of Computer Science and Technology,Tsinghua University,Beijing 100084,China

Because the traditional TCP protocol does not apply to the operating mode of data center,the TCP Incast problem occurs when there are common many-to-one traffic patterns in the data center,causing a visible throughput collapse of the application layer.Considering the characteristics of the data center,putting forward a comprehensive solution is the research objective of TCP Incast problem.This paper analyzes the root causes of the problem,enumerates the challenges of the problem,introduces the mathematical model based on the problem,analyzes and summarizes the recent solutions which are classified into link layer,transport layer and application layer,then from the effectiveness,deployment and other different aspects,makes a comprehensive comparison,finding that current solutions based on some specific points almost have drawbacks in different degree.Finally,this paper puts forward some feasible solutions to study the problem,and focuses on combining the technology of SDN and machine learning and designing a new transport protocol.

data center network;TCP Incast problem;throughput collapse

the Ph.D.degree in computer science from Tsinghua University in 1998.Now he is a professor and Ph.D.supervisor at Tsinghua University.His research interests include Internet architecture,large-scale network routing and space network,etc.

2017-05, Accepted 2017-07.

A

TP393

+Corresponding author:E-mail:13261706337@163.com

YU Yajun,LIU Zheng,XU Mingwei.Research on TCP Incast in data center networks.Journal of Frontiers of Computer Science and Technology,2017,11(9)：1361-1378.

10.3778/j.issn.1673-9418.1706034

CNKI網絡優先出版: 2017-07-20, http://kns.cnki.net/kcms/detail/11.5602.TP.20170720.1019.002.html

徐明偉（1971—），男，遼寧朝陽人，1998年于清華大學獲得博士學位，現為清華大學教授、博士生導師，主要研究領域為互聯網體系結構，大規模路由，空間網絡等。