數(shù)據(jù)中心網(wǎng)絡(luò)TCP Incast問題研究

余雅君，劉 崢，徐明偉

清華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)系，北京 100084

數(shù)據(jù)中心網(wǎng)絡(luò)TCP Incast問題研究

余雅君+，劉 崢，徐明偉

清華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)系，北京 100084

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

數(shù)據(jù)中心網(wǎng)絡(luò)；TCP Incast問題；吞吐量崩潰

1 引言

隨著互聯(lián)網(wǎng)的發(fā)展，云計(jì)算服務(wù)提供商大量涌現(xiàn)。Amazon、Microsoft、Google等云計(jì)算服務(wù)提供商使用數(shù)據(jù)中心向用戶提供網(wǎng)絡(luò)搜索、存儲(chǔ)、電子商務(wù)和大規(guī)模通用計(jì)算等服務(wù)?，F(xiàn)代數(shù)據(jù)中心承載著成千上萬的服務(wù)和應(yīng)用程序，為了適應(yīng)業(yè)務(wù)和服務(wù)的需求，數(shù)據(jù)中心已由當(dāng)初的計(jì)算中心轉(zhuǎn)變?yōu)閿?shù)據(jù)集群中心[1]?；诩旱拇鎯?chǔ)系統(tǒng)具有低成本、高可靠性、高可用性、可擴(kuò)展性等優(yōu)勢，如今已被廣泛部署到數(shù)據(jù)中心網(wǎng)絡(luò)（data center networks，DCN）中。這些存儲(chǔ)系統(tǒng)由一組網(wǎng)絡(luò)化的小型存儲(chǔ)服務(wù)器組成，數(shù)據(jù)分布在這些服務(wù)器中，以提高性能和可靠性，并通常采用分布/匯總的通信模式，實(shí)現(xiàn)數(shù)據(jù)可靠高效的傳輸。

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

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

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

本文組織結(jié)構(gòu)如下：第2章分析了TCP Incast問題；第3章對該問題的挑戰(zhàn)性進(jìn)行概括；第4章探究了針對該問題所構(gòu)建的模型；第5章對當(dāng)前方案進(jìn)行了分類研究；第6章對各種方案進(jìn)行全面對比；第7章進(jìn)行總結(jié)與展望。

2 TCP Incast問題

2.1 問題描述

2004年，Nagle等人在研究存儲(chǔ)集群使用分布式存取和實(shí)現(xiàn)線性存儲(chǔ)帶寬可擴(kuò)展性時(shí)，發(fā)現(xiàn)在存儲(chǔ)系統(tǒng)中隨著目標(biāo)存儲(chǔ)設(shè)備數(shù)量的增加，數(shù)據(jù)聚合帶寬開始減小，并存在吞吐量下降等問題，首先在分布式存儲(chǔ)系統(tǒng)PanFS中發(fā)現(xiàn)并提出了網(wǎng)絡(luò)傳輸?shù)腎ncast問題[4]。

同步請求工作負(fù)載在如今商業(yè)集群中越來越普遍，例如在集群存儲(chǔ)系統(tǒng)中，多個(gè)存儲(chǔ)節(jié)點(diǎn)同時(shí)響應(yīng)數(shù)據(jù)請求時(shí)；在Web搜索中，當(dāng)多個(gè)站點(diǎn)幾乎同時(shí)響應(yīng)搜索查詢時(shí)；在批處理作業(yè)中，如在MapReduce中的“shuffle”階段，來自多個(gè)Mapper的鍵值對被傳送到Reducer時(shí)。因此在許多典型的數(shù)據(jù)中心應(yīng)用中都可能出現(xiàn)TCP Incast問題。

一般來說，TCP Incast問題指的是存在TCP傳輸性能下降的多對一流量模式。圖1展示了典型的TCP Incast場景。在該模式下，客戶端通過交換機(jī)連接到數(shù)據(jù)中心，同時(shí)該交換機(jī)與多臺(tái)服務(wù)器相連?？蛻舳讼蛞粋€(gè)或多個(gè)服務(wù)器請求數(shù)據(jù)，數(shù)據(jù)從服務(wù)器發(fā)出，通過交換機(jī)，經(jīng)過瓶頸鏈路到達(dá)客戶端，形成多對一模型。該模式中，客戶端一般請求較大邏輯塊大?。ū热? MB）的數(shù)據(jù)，而實(shí)際上數(shù)據(jù)是以較小的數(shù)據(jù)塊大?。ū热?2 KB）即服務(wù)請求單元（server request unit，SRU）分布式地存儲(chǔ)在很多服務(wù)器上?？蛻舳讼虼鎯?chǔ)請求數(shù)據(jù)塊的服務(wù)器發(fā)送請求包，通過TCP服務(wù)請求，直到當(dāng)前請求的所有SRU均成功被客戶端接收，即完成當(dāng)前請求，則開始下一請求。

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

2.2 問題原因與影響

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

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

（2）觸發(fā)超時(shí)重傳。當(dāng)交換機(jī)隊(duì)列溢出時(shí)，多條流會(huì)發(fā)生丟包，又由于擁塞窗口小，某條流可能出現(xiàn)整個(gè)窗口丟包，不能觸發(fā)TCP快速重傳，只能超時(shí)重傳，導(dǎo)致吞吐量下降。

（3）同步阻礙模式影響。當(dāng)同步請求中涉及的某個(gè)服務(wù)器處于超時(shí)階段時(shí)，其他服務(wù)器可以完成其響應(yīng)的發(fā)送，但客戶端必須等待至少TCP最小超時(shí)重傳RTOmin（默認(rèn)為200 ms）才能接收重傳響應(yīng)，在此期間客戶端鏈路可能處于完全空閑狀態(tài)，網(wǎng)絡(luò)利用率顯著下降。

TCP Incast問題導(dǎo)致的災(zāi)難性吞吐量崩潰可能會(huì)使用戶可見吞吐量低至客戶端帶寬容量的1%～10%，且每個(gè)請求的延遲可能高于200 ms，這將極大程度地影響延時(shí)敏感的在線應(yīng)用程序，使系統(tǒng)響應(yīng)緩慢，從而錯(cuò)過流完成期限，對用戶體驗(yàn)造成負(fù)面影響。同時(shí)，Incast模式下造成網(wǎng)絡(luò)資源的浪費(fèi)，在影響用戶的同時(shí)，會(huì)造成服務(wù)提供商的損失。

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

3 問題挑戰(zhàn)

由于數(shù)據(jù)中心網(wǎng)絡(luò)的特點(diǎn)及其復(fù)雜性，解決TCP Incast問題具有較強(qiáng)的挑戰(zhàn)性。

（1）傳輸協(xié)議遷移問題。如前文所說，數(shù)據(jù)中心數(shù)據(jù)的傳輸是基于TCP/IP傳輸協(xié)議，而該協(xié)議是針對傳統(tǒng)網(wǎng)絡(luò)特點(diǎn)設(shè)計(jì)，傳統(tǒng)網(wǎng)絡(luò)對網(wǎng)絡(luò)拓?fù)?、鏈路利用率、交換機(jī)緩存大小等特性都未知，而數(shù)據(jù)中心主要集中管理，能獲取較全面的網(wǎng)絡(luò)信息，同時(shí)數(shù)據(jù)中心網(wǎng)絡(luò)流量模式不同于傳統(tǒng)網(wǎng)絡(luò)，因此當(dāng)傳統(tǒng)TCP應(yīng)用于數(shù)據(jù)中心網(wǎng)絡(luò)時(shí)存在很多弊端。

（2）應(yīng)用需求差異。在數(shù)據(jù)中心網(wǎng)絡(luò)中，各應(yīng)用需求不同，有帶寬饑餓的大流量，同時(shí)存在有嚴(yán)格完成時(shí)間期限的小流量。因此需要權(quán)衡數(shù)據(jù)中心在低延時(shí)敏感的小流量和高吞吐量敏感的大流量間的調(diào)度，盡可能滿足不同應(yīng)用的需求。

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

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

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

（2）一致性問題。如以太網(wǎng)流量控制可緩解隊(duì)列壓力，但存在隊(duì)頭阻塞（head-of-line blocking）問題，影響其他正常流。同時(shí)由于交換機(jī)供應(yīng)商不同，交換機(jī)實(shí)現(xiàn)存在不一致問題。

（3）附加不確定影響。通過減少TCPRTOmin的方法可提高吞吐量。但系統(tǒng)時(shí)鐘實(shí)現(xiàn)微秒級的分辨率依舊存在挑戰(zhàn)，同時(shí)若RTO（retransmission timeout）設(shè)置過小，會(huì)導(dǎo)致超時(shí)誤判，同樣造成不利影響，因此閾值的選取也存在權(quán)衡問題。

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

因此，在基于傳統(tǒng)TCP/IP協(xié)議的數(shù)據(jù)中心網(wǎng)絡(luò)中，兼顧不同應(yīng)用的需求，結(jié)合數(shù)據(jù)中心特點(diǎn)，提出適合大多數(shù)網(wǎng)絡(luò)環(huán)境而非特定網(wǎng)絡(luò)環(huán)境的TCP Incast問題的解決方案依舊存在較大挑戰(zhàn)，需進(jìn)一步對該問題深入研究。

4 建模與分析

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

4.1 實(shí)驗(yàn)數(shù)據(jù)擬合模型

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

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

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

通過模型分析，RTOmin值和包發(fā)送間隔時(shí)間I極大地影響了吞吐量，因此RTOmin較大時(shí)，應(yīng)減小該值；RTOmin較小時(shí)，需控制發(fā)送包的間隔時(shí)間I以解決TCP Incast問題。但是，該模型建立過程中的模型參數(shù)過于依賴實(shí)驗(yàn)數(shù)據(jù)，不具有普適性，同時(shí)部分參數(shù)（如avgMSS）在發(fā)送數(shù)據(jù)前難以獲取，且該模型未進(jìn)行嚴(yán)格的數(shù)學(xué)證明，只是直觀上的解釋，實(shí)驗(yàn)只針對兩種特定的工作負(fù)載和網(wǎng)絡(luò)環(huán)境，對于不同的應(yīng)用、網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)拓?fù)涞鹊倪m用性有待深入分析。

4.2 理論建模分析模型

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

BTTO描述的是，當(dāng)同步發(fā)送者較少，數(shù)據(jù)塊最后3個(gè)包中出現(xiàn)丟包時(shí)，由于接收3個(gè)重復(fù)ACK才快速重傳的機(jī)制將不會(huì)觸發(fā)快速重傳，而是等待RTO時(shí)長觸發(fā)超時(shí)重傳，因此造成吞吐量下降。

而當(dāng)同步發(fā)送者數(shù)量較大時(shí)，會(huì)出現(xiàn)BHTO。這是由于當(dāng)某些流較早完成傳輸，使這些流具有較大的發(fā)送窗口。每個(gè)流根據(jù)其窗口大小將分組注入網(wǎng)絡(luò)。由于同步發(fā)送者過多，容易超出緩沖區(qū)容量，導(dǎo)致其中一些包被丟棄。更加不幸的是可能丟失某窗口中所有包，無ACK包反饋，進(jìn)入超時(shí)重傳階段。這便是同步發(fā)送者數(shù)量增大時(shí)，超時(shí)重傳主要發(fā)生在塊傳輸?shù)拈_始，導(dǎo)致吞吐量急劇下降的原因。

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

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

4.3 解釋模型

不同于上述擬合模型依賴實(shí)驗(yàn)數(shù)據(jù)，分析模型依賴TCP版本，在文獻(xiàn)[10]中并未直接計(jì)算特定場景的吞吐量，而是對流控系統(tǒng)參數(shù)和相關(guān)機(jī)制變量的影響進(jìn)行量化分析，提出解釋模型，理論分析參數(shù)對TCP Incast問題的影響，從而總結(jié)該問題產(chǎn)生的原因。

吞吐量Th定義為：

其中，N代表發(fā)送者數(shù)目；S為數(shù)據(jù)塊大??；C為鏈路容量；PTO為發(fā)生超時(shí)的可能性；τTO為超時(shí)持續(xù)時(shí)長。

通過實(shí)驗(yàn)觀察發(fā)現(xiàn)，流量較多時(shí)主要發(fā)生全損超時(shí)（full loss timeout，F(xiàn)LT），類似于BHTO，且窗口大小w服從正態(tài)分布。

通過理論證明，在一個(gè)輪詢（round）中發(fā)生超時(shí)的可能性與平均窗口大小、標(biāo)準(zhǔn)差σw、丟包率 p有關(guān)，關(guān)系見式（6）。

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

從上面理論公式可以看出，關(guān)于吞吐量的定義考慮了所有關(guān)鍵系統(tǒng)參數(shù)和機(jī)制變量，如系統(tǒng)參數(shù)鏈路容量C、數(shù)據(jù)塊大小S、緩沖區(qū)大小B、機(jī)制變量RTOmin、平均窗口大小和窗口大小的標(biāo)準(zhǔn)差σw，并討論分析了它們對吞吐量的量化影響。

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

5 TCP Incast問題解決方案

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

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

5.1 鏈路層

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

5.1.1 擁塞通知方案

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

（1）BCN

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

Fig.2 BCN model圖2BCN系統(tǒng)模型

（2）QCN

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

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

（3）AF-QCN

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

（4）F-QCN

F-QCN（fair QCN）[14]主要用于改善共享瓶頸鏈路中多個(gè)流的公平性。它將QCN消息反饋給所有流的源端，源端根據(jù)流所占共享瓶頸鏈路容量比例調(diào)節(jié)發(fā)送速率，從而實(shí)現(xiàn)共享瓶頸鏈路的公平性。

以上方法都是通過檢測擁塞交換機(jī)，向發(fā)送方發(fā)送反饋，調(diào)節(jié)發(fā)送速率緩解擁塞。這些基于兩層實(shí)現(xiàn)的擁塞通知方案一定程度上能緩解TCP Incast問題，但效果不顯著。

5.1.2 流控機(jī)制

基于交換機(jī)實(shí)現(xiàn)流控也有相應(yīng)方案。諸如以太網(wǎng)流控[8]和優(yōu)先級流控[15]提供的流控機(jī)制可以有效地管理發(fā)送到單個(gè)交換機(jī)的聚合數(shù)據(jù)量，從而緩解TCP Incast問題。

（1）EFC

支持EFC（Ethernet flow control）的過載交換機(jī)可以向發(fā)送數(shù)據(jù)接口的擁塞緩沖區(qū)發(fā)送“暫?！睅ㄖB接到該接口的所有設(shè)備在給定的時(shí)間內(nèi)停止或轉(zhuǎn)發(fā)數(shù)據(jù)。在此期間，過載交換機(jī)可以減輕其隊(duì)列壓力。EFC對于所有客戶端和服務(wù)器連接到單個(gè)交換機(jī)時(shí)是有效的，然而由于交換機(jī)的先進(jìn)先出（first in first out，F(xiàn)IFO）機(jī)制和隊(duì)頭阻塞，當(dāng)擁塞緩沖區(qū)的暫停幀意圖停止導(dǎo)致?lián)砣牧鲿r(shí)，它會(huì)同時(shí)阻塞其他正常流。同時(shí)由于交換機(jī)供應(yīng)商不同，會(huì)導(dǎo)致交換機(jī)實(shí)現(xiàn)存在不一致問題。

（2）PFC

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

表1總結(jié)了鏈路層解決方案的本質(zhì)及優(yōu)缺點(diǎn)，這些方案主要根據(jù)交換機(jī)反饋或直接控制交換機(jī)緩解擁塞，很多研究通過改進(jìn)先前方案不足實(shí)現(xiàn)更好的功能，其中PFC方案依舊被廣泛應(yīng)用。

5.2 傳輸層

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

（1）參數(shù)調(diào)整。改善DCN中TCP重傳的機(jī)制，使得重傳盡快執(zhí)行，提升吞吐量。

（2）傳輸機(jī)制優(yōu)化。通過改進(jìn)擁塞控制，盡量避免或減少瓶頸鏈路交換機(jī)緩存區(qū)占滿的情況，減少丟包，降低TCP Incast問題發(fā)生概率。

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

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

5.2.1 參數(shù)調(diào)整

（1）減小RTOmin

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

（2）關(guān)閉DelayedACK機(jī)制

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

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

（3）基于SDN初始參數(shù)動(dòng)態(tài)調(diào)整

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

通過SDN獲取全局信息，調(diào)節(jié)TCP中IW和RTO參數(shù)能一定程度緩解該問題，為解決TCP Incast問題提供了全局視角，但由于網(wǎng)絡(luò)流量具有突發(fā)性，更新周期的確定也具有一定挑戰(zhàn)。

Fig.3 Frame of OpenTCP圖3OpenTCP架構(gòu)

5.2.2 傳輸機(jī)制優(yōu)化

（1）DCTCP

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

交換機(jī)預(yù)先被設(shè)置好一個(gè)閾值，當(dāng)隊(duì)列長度超過這個(gè)閾值時(shí)，就會(huì)通過CE標(biāo)記告知接收端，該數(shù)據(jù)包經(jīng)歷了擁塞；然后接收端在ACK上打上ECN標(biāo)簽，告訴發(fā)送方調(diào)節(jié)發(fā)送窗口；發(fā)送方就會(huì)根據(jù)記錄包中ECN標(biāo)記比例數(shù)，通過相應(yīng)方式調(diào)節(jié)發(fā)送窗口，控制發(fā)送速率，從而實(shí)現(xiàn)擁塞避免。

在傳統(tǒng)的TCP中，出現(xiàn)擁塞時(shí)會(huì)將發(fā)送窗口減半，而在DCTCP中，使用式（8）調(diào)節(jié)擁塞窗口：

其中，α為估計(jì)隊(duì)列長度的參數(shù)，范圍在0到1之間，代表擁塞程度。這種發(fā)送窗口的好處是可以在隊(duì)列過長時(shí)減小發(fā)送速率避免擁塞，而且將調(diào)節(jié)的幅度與擁塞程度聯(lián)系，不是每次都減半，這樣可以提升窗口恢復(fù)速度，從而提升吞吐量。

α依據(jù)式（9）計(jì)算：

其中，F(xiàn)為當(dāng)前窗口內(nèi)的包被標(biāo)記ECN的比例；g（0～1）是當(dāng)前擁塞程度占總擁塞程度的權(quán)重，可以通過調(diào)節(jié)該參數(shù)控制所需考慮當(dāng)前擁塞的比重。從上面兩式可見F越大，即被標(biāo)記比例越大，說明隊(duì)列越長，從而α越大，計(jì)算出的擁塞窗口越小。

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

（2）ICTCP

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

首先根據(jù)鏈路容量C和測量帶寬BWT計(jì)算網(wǎng)絡(luò)剩余帶寬BWA：

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

最后定義測量吞吐量和期望吞吐量的差與期望吞吐量的比值為調(diào)節(jié)接收窗口指標(biāo)：

在剩余帶寬BWA足夠的情況下，根據(jù)指標(biāo)調(diào)節(jié)接收窗口的方法為：

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

ICTCP被設(shè)計(jì)為NDIS（network driver interface specification）驅(qū)動(dòng)器，在操作系統(tǒng)的TCP/IP協(xié)議棧和網(wǎng)卡驅(qū)動(dòng)器之間實(shí)現(xiàn)，并且只需要在接收端部署，使ICTCP不改變TCP/IP內(nèi)核實(shí)現(xiàn)，支持更多的操作系統(tǒng)版本，并且支持目前在數(shù)據(jù)中心中廣泛應(yīng)用的虛擬機(jī)。

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

（3）PAC

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

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

in-flight流量的估計(jì)主要分為兩部分。

①發(fā)送ACK包時(shí)

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

②接收包時(shí)

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

由于數(shù)據(jù)中心網(wǎng)絡(luò)中流量的多樣性，在流量大小未知的情況下為實(shí)現(xiàn)自適應(yīng)調(diào)度，巧妙地通過不同優(yōu)先級隊(duì)列執(zhí)行MLFQ（multi-level feedback queue）實(shí)現(xiàn)了不同流的ACK自適應(yīng)調(diào)度。該方案的實(shí)現(xiàn)類似于ICTCP的實(shí)現(xiàn)，在Windows平臺(tái)將PAC設(shè)計(jì)為NDIS驅(qū)動(dòng)，在Linux平臺(tái)將PAC實(shí)現(xiàn)為內(nèi)核模塊。

通過實(shí)驗(yàn)，得出PAC性能優(yōu)于ICTCP、DCTCP大概40多倍的結(jié)論，但同式（17）所示，該算法與慢啟動(dòng)、擁塞避免機(jī)制相關(guān)，因此會(huì)限制可支持的擁塞避免算法。同時(shí)由于利用ACK包觸發(fā)機(jī)制，該算法需考慮DelayedACK機(jī)制的影響。

（4）PS

2015年黃家瑋等人針對大量并行TCP流傳輸場景提出了PS（packet slicing）方案[23]。該方案結(jié)合擁塞窗口和包大小的相關(guān)性，根據(jù)實(shí)時(shí)網(wǎng)絡(luò)狀態(tài)，在交換機(jī)分析計(jì)算并通過發(fā)送ICMP（Internet control message protocol）消息告知發(fā)送方最佳包大小，以減小整個(gè)窗口包丟失的可能性。

TCP超時(shí)主要是因?yàn)檎麄€(gè)窗口的包丟失，所以將整個(gè)窗口包丟失的概率近似為該流出現(xiàn)超時(shí)的概率p，有：

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

其中，B為緩存大?。籲為流數(shù)；s為包大??；w為每條流的擁塞窗口大小。

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

其中，LD和LH分別代表包有效負(fù)載和包頭長度；k為調(diào)節(jié)的分片因子；C和RTTmin分別代表鏈路容量和傳播時(shí)延。

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

（5）CP機(jī)制

CP（cutting payload）機(jī)制[24]是一種丟棄負(fù)載的方式，主要在以下三方面分別實(shí)現(xiàn)，工作原理如圖4所示。

交換機(jī)：當(dāng)交換機(jī)緩沖區(qū)過載時(shí)，把包的有效負(fù)載丟棄，但保留包頭部分，如圖中包4和5；接收端：根據(jù)包頭中五元組等信息設(shè)置PACK（precise ACK）包，明確告知發(fā)送方哪些包經(jīng)歷擁塞；發(fā)送端：根據(jù)PACK包選擇相應(yīng)的調(diào)節(jié)策略和重發(fā)機(jī)制。

Fig.4 CP mechanism圖4 CP機(jī)制示意圖

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

（6）GIP

2013年，張嬌等人在2011年的理論建模分析模型（見4.2節(jié)）的基礎(chǔ)上提出了GIP（guaranteeing important packets）[25]，一種TCP增強(qiáng)協(xié)議。同樣認(rèn)為Incast場景下造成吞吐量下降的主要原因?yàn)閮煞N超時(shí)：FLoss-TO（full window loss timeout）和LAck-TO（lack of ACK timeout），分別對應(yīng)于4.2節(jié)中的BHTO和BTTO。

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

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

（7）TCP PLATO

為解決超時(shí)重傳導(dǎo)致吞吐量下降的影響，Shukla等人于2014年提出了包標(biāo)記系統(tǒng)PLATO（packet labelling to alleviate time-out）[26]，它基于 NewReno 實(shí)現(xiàn)，不同之處主要為丟包檢測機(jī)制。

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

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

PLATO通過改變IP包頭的DSCP字段實(shí)現(xiàn)包的標(biāo)記，要求交換機(jī)支持加權(quán)隨機(jī)早期檢測（weighted random early detection，WRED）。該機(jī)制需要改動(dòng)源端和目的端，且是出現(xiàn)丟包后的處理機(jī)制，網(wǎng)絡(luò)已出現(xiàn)較嚴(yán)重?fù)砣?，并未從根本上解決TCP Incast問題。

5.2.3 基于編碼的UDP

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

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

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

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

表2對傳輸層解決方案的機(jī)制本質(zhì)和優(yōu)缺點(diǎn)進(jìn)行了總結(jié)。這些方案分別從減小超時(shí)影響，避免超時(shí)以及替換TCP角度出發(fā)，能一定程度緩解TCP Incast問題，其中DCTCP受到廣泛認(rèn)可，而其他方案暫時(shí)處于研究階段。

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

5.3 應(yīng)用層

2007年Krevat等人在文獻(xiàn)[28]中針對Incast問題提出了限制并發(fā)流數(shù)、交錯(cuò)數(shù)據(jù)傳輸、數(shù)據(jù)傳輸?shù)娜终{(diào)度等應(yīng)用層解決角度的建議。近幾年基于以上角度，提出了很多應(yīng)用層解決方案。

（1）XCo

XCo[29]是對數(shù)據(jù)中心中廣泛應(yīng)用的虛擬機(jī)的網(wǎng)絡(luò)傳輸進(jìn)行協(xié)調(diào)，實(shí)現(xiàn)避免擁塞以及吞吐量崩潰問題。XCo架構(gòu)思想是一個(gè)或多個(gè)控制器與網(wǎng)絡(luò)相連，控制器掌握互聯(lián)拓?fù)?，?dāng)前流量矩陣，虛擬機(jī)的優(yōu)先級、帶寬、響應(yīng)時(shí)間等策略需求，并周期性地給虛擬機(jī)協(xié)調(diào)器下達(dá)傳輸指令，協(xié)調(diào)網(wǎng)絡(luò)中多個(gè)虛擬機(jī)的傳輸速率，使得提高網(wǎng)絡(luò)利用率的同時(shí)，能保證發(fā)送的數(shù)據(jù)不會(huì)超過交換機(jī)的緩存。該方案與5.2節(jié)利用SDN技術(shù)類似，但存在本質(zhì)區(qū)別。

文中利用循環(huán)掩碼提出了相應(yīng)的時(shí)間調(diào)度算法，控制每個(gè)時(shí)間段激活主機(jī)的數(shù)目，從而實(shí)現(xiàn)擁塞避免。該架構(gòu)也支持其他調(diào)度策略，如速率調(diào)度。

XCo架構(gòu)不改變應(yīng)用、協(xié)議或網(wǎng)絡(luò)交換機(jī)，支持任意拓?fù)洌軓脑搭^解決TCP Incast問題，但數(shù)據(jù)中心網(wǎng)絡(luò)中時(shí)延特性不可忽視；同時(shí)，該架構(gòu)的容錯(cuò)性、協(xié)調(diào)開銷也是必須考慮的方面。

（2）交錯(cuò)流

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

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

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

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

通過阻止并發(fā)流的傳輸可有效緩解交換機(jī)壓力，然而由于網(wǎng)絡(luò)環(huán)境的復(fù)雜性，很難對網(wǎng)絡(luò)中的交錯(cuò)時(shí)間長度進(jìn)行估計(jì)，且接收方向發(fā)送方逐一請求數(shù)據(jù)會(huì)帶來不可忽視的請求時(shí)間開銷，一定程度上會(huì)增大流完成時(shí)間。

（3）并行連接限制

文獻(xiàn)[31]指出將網(wǎng)絡(luò)中最大并發(fā)連接數(shù)限制到預(yù)設(shè)值的方法不適用于SRU很小的情況，且最大連接數(shù)量無法優(yōu)化，可能導(dǎo)致即使Incast沒有發(fā)生，仍出現(xiàn)網(wǎng)絡(luò)吞吐量很小的情況，文中提出了一種對任意SRU大小適用且最大連接數(shù)量可優(yōu)化的方法。

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

假設(shè)初始擁塞窗口設(shè)置為2，由于慢啟動(dòng)機(jī)制，發(fā)送窗口的初始遞增階段時(shí)長T1和到達(dá)BaseBDP開始至連接結(jié)束時(shí)長T2可由以下公式分別計(jì)算：

其中，S為SRU大小。

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

因?yàn)榻菩蛄谢椒ㄖ邢拗茥l件為T2≥2×T1，即

因此當(dāng)S不滿足式（30）時(shí)，采用最優(yōu)序列化方法，通過式（31）求出耦合流數(shù)nmin：

該3種方法的結(jié)合使得控制連接間隔時(shí)間是對于任意的SRU大小定義的，同時(shí)建立連接的數(shù)量是可優(yōu)化的，因此通過控制連接間隔時(shí)間與并行連接數(shù)實(shí)現(xiàn)高吞吐量。

（4）ARS

2016年黃家瑋教授等人在解釋模型（見4.3節(jié)）和2015年提出的PS方案（見5.2節(jié)）基礎(chǔ)上又提出了一種跨層（核心為應(yīng)用層）的設(shè)計(jì)方案ARS[32]（adaptive request schedule），實(shí)現(xiàn)自適應(yīng)的請求調(diào)度。ARS根據(jù)從傳輸層獲得的擁塞狀態(tài)來分批處理應(yīng)用層請求，采用動(dòng)態(tài)調(diào)節(jié)并發(fā)的TCP流數(shù)量來解決Incast問題。

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

因此n條流中至少一條流經(jīng)歷超時(shí)，發(fā)生Incast的可能性P為：

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

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

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

表3對應(yīng)用層解決方案的機(jī)制本質(zhì)和優(yōu)缺點(diǎn)進(jìn)行了總結(jié)。

Table 3 Solutions comparison of application layer表3 應(yīng)用層解決方案對比

6 方案對比

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

從表4中可以發(fā)現(xiàn)，針對TCP Incast問題，鏈路層解決方案的有效性較低，這主要是因?yàn)殒溌穼拥闹饕侄问菗砣答?。可以看出，目前較被看好的解決方案已從鏈路層轉(zhuǎn)向傳輸層和應(yīng)用層，其中傳輸層研究占較大比例。傳輸層方案的主要問題在于需要改變TCP協(xié)議?；蚪粨Q機(jī)。例如DCTCP和ICTCP方案，兩者都能較高效地緩解TCP Incast問題，但都只適用于較小規(guī)模的同步發(fā)送者情況。DCTCP需要修改協(xié)議棧且要求終端和交換機(jī)支持ECN，而ICTCP需在接收端部署相應(yīng)的驅(qū)動(dòng)器。應(yīng)用層方案對底層改動(dòng)較小，使其可部署性整體優(yōu)于傳輸層方案。應(yīng)用層方案的問題主要在于需較全面的流信息、操作的復(fù)雜性以及開銷的控制。

7 總結(jié)與展望

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

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

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

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

鑒于對方案的分析，結(jié)合當(dāng)前學(xué)術(shù)界和工業(yè)界關(guān)注的熱點(diǎn)，總結(jié)了針對TCP Incast問題未來可能的研究方向。

（1）現(xiàn)有技術(shù)交叉融合

①機(jī)器學(xué)習(xí)

很多方案依賴系數(shù)的選取，人們可利用機(jī)器學(xué)習(xí)，建立參數(shù)間的相關(guān)性，在終端設(shè)計(jì)調(diào)節(jié)參數(shù)的控制模型。例如微軟實(shí)現(xiàn)的Pingmesh[33]每天會(huì)生成超過2 000億的探針，產(chǎn)生24 TB的數(shù)據(jù)，可復(fù)用這些數(shù)據(jù)，利用機(jī)器學(xué)習(xí)分析數(shù)據(jù)特征，如周期性等，更好地控制網(wǎng)絡(luò)狀態(tài)，避免TCP Incast問題。

②SDN技術(shù)+在線機(jī)器學(xué)習(xí)

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

（2）設(shè)計(jì)新的傳輸協(xié)議

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

（3）新型架構(gòu)與硬件設(shè)備

從交換機(jī)硬件設(shè)施入手，通過合理的體系結(jié)構(gòu)設(shè)計(jì)解決根本的阻塞等問題。例如，Samadi等人提出了在光纖網(wǎng)絡(luò)中結(jié)合分組交換與電路交換的混合網(wǎng)絡(luò)架構(gòu)，其中采用的光交換機(jī)（optical space switches，OSS）[35]也是解決TCP Incast問題的有力補(bǔ)充。

[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—），女，安徽安慶人，清華大學(xué)計(jì)算機(jī)系碩士研究生，主要研究領(lǐng)域?yàn)閭鬏攨f(xié)議，擁塞控制算法等。

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—），黑龍江哈爾濱人，清華大學(xué)計(jì)算機(jī)系博士研究生，主要研究領(lǐng)域?yàn)榛ヂ?lián)網(wǎng)體系結(jié)構(gòu)，路由協(xié)議，空間網(wǎng)絡(luò)路由機(jī)制等。

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網(wǎng)絡(luò)優(yōu)先出版: 2017-07-20, http://kns.cnki.net/kcms/detail/11.5602.TP.20170720.1019.002.html

徐明偉（1971—），男，遼寧朝陽人，1998年于清華大學(xué)獲得博士學(xué)位，現(xiàn)為清華大學(xué)教授、博士生導(dǎo)師，主要研究領(lǐng)域?yàn)榛ヂ?lián)網(wǎng)體系結(jié)構(gòu)，大規(guī)模路由，空間網(wǎng)絡(luò)等。