朱丹紅，林清祥，張 棟

福州大學 數學與計算機科學學院，福州 350108

1 引言

隨著云計算和互聯網應用的快速發(fā)展，網頁搜索、社交網絡和在線直播等實時交互式應用大量部署于數據中心[1]。這些應用在數據中心網絡中主要采用劃分/聚合的工作模式。聚合者（Aggregator）將用戶請求分割成小任務，通過TCP短流同時向多個服務器（Worker）分發(fā)，服務器處理后，瞬時將結果返回聚合者，這種多對一的通信方式，造成數據流量突發(fā)并帶來擁塞，產生TCP Incast問題[2]。同時，這些交互式應用產生大量混合多樣的數據流[3]，包括時延敏感短流與時延不敏感長流，長流占用大部分緩存隊列，導致短流擁塞，時延性能下降，產生短流高延遲問題[4]，實時應用的服務質量受到嚴重影響。

數據中心網絡的TCP Incast和長短流競爭是引起短流高延遲的主要原因。延時是交互式應用的重要性能指標，短流完成時間大大影響用戶體驗，高延遲會帶來嚴重的業(yè)務流失。因此，如何降低短流完成時間，保證短流低延時成為數據中心網絡亟待解決的問題。D2TCP（deadline-aware data center TCP）[5]是基于時限感知的數據中心傳輸控制協議，針對中心網絡的擁塞控制和流調度，引入時限感知，有效提高流在時限內完成的成功率。但D2TCP未能明確區(qū)分數據流的時延敏感特性，在短時擁塞中，時延敏感分組和非時延敏感分組交錯，增加時延敏感流錯過時限的概率。同時，對于數據中心網絡的多對一通信模式，D2TCP在一定程度上仍會因TCP Incast而發(fā)生數據包丟失[6]。作為新型的網絡架構，軟件定義網絡（Software Defined Networking，SDN）[7]將控制與轉發(fā)分離，形成邏輯集中的控制平面，負責網絡處理動作的調度。借助SDN對數據流進行監(jiān)控，統(tǒng)一調度全局交換機，保證充足的緩沖資源應對多對一通信，能夠減少TCP Incast發(fā)生。

本文利用SDN集中控制的特點，針對TCP Incast，在時限感知擁塞控制的基礎上，為時延敏感短流賦予較高的優(yōu)先級，設計SDN-D2TCP方案，解決數據中心網絡的長短流競爭和TCP Incast問題。

2 相關工作

數據中心網絡的通信廣泛采用TCP協議。但傳統(tǒng)TCP針對低帶寬、低時延的廣域網，難以適應高帶寬、低時延的數據中心網絡要求[8]，導致長短流競爭和TCP Incast等問題?，F有的解決方案主要分為兩類。一是設計有別于現有TCP的全新傳輸協議，如HULL[9]，D3[10]，pFabric[11]等；另一類則是基于現有TCP的改進方案，如DCTCP[12]，D2TCP等。

在全新的設計協議中，HULL利用影子隊列估計帶寬使用率，通過犧牲10%～20%的帶寬來消除緩沖使用，預防擁塞，降低延遲。但HULL平等對待所有流，不利于保證短流時延。D3則根據流大小與時限區(qū)分優(yōu)先級分配帶寬，避免TCP Incast問題。然而D3交換機對所有流進行集中帶寬分配，實際中受硬件計算能力和內存容量限制，可行性低。pFabric將基于優(yōu)先級的流調度與流速控制解耦，流初始采用線性速率注入，只有多次丟包后才對流速壓制，被廣泛應用，但因為流速控制過于簡單導致大量丟包事件，影響協議性能。

在基于TCP改進上，DCTCP是一種TCP變體，僅需對已有TCP做簡單修改就能很好地提升性能。該協議基于ECN消息，根據網絡的擁塞程度調節(jié)擁塞窗口，降低發(fā)送速率，有效減少分組丟失。但由于數據中心網絡長短流并存，流的時限要求各不相同，DCTCP未考慮流時限，具有一定局限。D2TCP結合流時限，在傳輸層引入時限感知，提高短流優(yōu)先級，顯著減小短流完成時間。然而，D2TCP未能區(qū)分流的時延敏感性，在短暫擁塞期間，時延敏感分組可能排在擁塞隊列后面，增加錯過時限的可能性。此外，規(guī)模龐大的數據中心網絡通常采取緩沖資源少的淺緩存交換機，多對一通信模式產生大量高并發(fā)，在緩存較低的狀態(tài)下，D2TCP傳輸控制策略會因TCP Incast而造成一定程度的丟包。

SDN作為一種數據控制分離、軟件可編程的新型網絡體系架構，其核心是將控制和轉發(fā)分離，控制平面擁有對全網的管控能力，數據轉發(fā)根據上層控制器的指示進行[13]。本文在D2TCP基礎上，引入優(yōu)先級思想區(qū)分數據流的時延敏感特性，為時延敏感流賦予較高優(yōu)先級，并進一步利用SDN的集中控制思想及數據流的控制技術，預防TCP Incast的發(fā)生。在數據中心網絡，通過SDN將多對一通信模式數據流與其他流區(qū)分，進行單獨監(jiān)控，控制器根據全局交換機資源判斷，若當前緩沖資源不足以應對即將發(fā)生的多對一通信，則通過下發(fā)規(guī)則，迫使占據交換機緩沖資源的長流降低發(fā)送速率，保證多對一通信。

3 問題描述

3.1 長短流競爭

數據中心網絡流量分布的特征是，1～10 KB的短流數量較多，1～50 MB的長流相對較少，但長流所占的字節(jié)總量大，占用資源多，造成短流排隊延時甚至丟包。如圖1所示，短流進入網絡前，交換機的緩沖資源已被長流占據，此時短流經過相同的交換機端口，分組將會排到隊尾，導致排隊時延過長。如果長流已將緩沖資源耗盡，短流將會產生丟包。

圖1 長短流競爭示意

DCTCP通過快速響應交換機隊列長度變化來降低延遲。交換機使用RED等主動式隊列算法，當隊列長度大于某個閾值K時，對數據分組進行ECN標記，接收端收到ECN后，在反向ACK分組標記ECN-echo并回傳，由發(fā)送端統(tǒng)計傳回的ACK，利用公式（1）衡量擁塞程度。其中，α表示交換機隊列超過閾值K的概率，每隔一個RTT（Round Trip Time，往返時間）被更新。權重參數g用于評估擁塞概率，F是前一個RTT內被標記的分組比例。而后發(fā)送端按照公式（2）相應減小擁塞窗口cwnd，保證網絡不過載，優(yōu)化吞吐量和延遲。但DCTCP協議平等對待所有數據流，對延時敏感的短流不利，在最小化流的延遲性能上不是最優(yōu)。

D2TCP在DCTCP算法中引入時限感知因子d，使用γ校正函數

調節(jié)擁塞窗口W。其中：

理論上減少錯過時限的短流比例，增加短流競爭力。但由于數據流具有時效性需求，因此引入優(yōu)先級區(qū)分流的時延敏感特性，能夠進一步減少時延敏感流錯過時限的可能。

定義擁塞發(fā)生時數據流的優(yōu)先級：

其中，VA為流已發(fā)送的平均速率，VE為流發(fā)送的期望速率。由此，時延敏感的數據流將被分配較高的優(yōu)先級。進一步定義校正函數：

擁塞窗口仍采用公式（4）調節(jié)?？梢钥闯觯瑫r限要求越小，時延越不敏感的數據流，窗口退避程度越大，從而為網絡騰出帶寬，保證時限約束。

3.2 TCP Incast現象

數據中心網絡采用的多對一通信模式如圖2所示。由Aggregator把任務同時分發(fā)給多個Worker，Worker計算處理后幾乎同時將結果返回給Aggregator，造成數據流量突發(fā)。連接Aggregator的交換機中分組數量迅速增長，超出緩存能力，成為網絡瓶頸。過多的Worker甚至會耗盡交換機的緩沖資源，發(fā)生丟包，繼而觸發(fā)TCP的超時重傳機制，導致流錯過時限。

圖2 TCP Incast現象

長短流競爭和TCP Incast并存于中心網絡，導致短流延時性能明顯下降。本文提出基于SDN-D2TCP的解決方案，核心思想是通過SDN技術監(jiān)控網絡流量，偵測網絡中多對一的通信行為，預測TCP Incast發(fā)生的瓶頸交換機，并考慮數據流的時延敏感特性，結合時限感知和ECN標記調整擁塞窗口，壓制該交換機的流注入速率，確保交換機擁有更多的緩沖資源來應對多對一通信。

4 SDN-D2TCP方案

4.1 設計思想

數據中心網絡的Aggregator和Worker通常是連接同一機架交換機的服務器。本文方案將數據中心SDN化，交換機接受SDN控制器的控制與管理。如圖3所示，首先，在控制器中注冊Aggregator的IP地址和Worker通信端口號，根據注冊信息，在交換機建立流表；當Aggregator向多個Worker分發(fā)客戶請求時，交換機對IP和端口號執(zhí)行匹配，偵測多對一通信行為，并計算流量；最后依據流量結果判別擁塞情況，并由交換機上報控制器，調用D2TCP算法進行擁塞控制。

圖3 SDN-D2TCP流程

4.2 控制與轉發(fā)平面模型

SDN網絡架構體系中，控制器能夠為上層應用提供管理和控制的可編程接口，因此構建預防TCP Incast的應用TIP（TCP Incast Preventer），如圖4所示。在轉發(fā)平面的SDN交換機中設計三張表，分別為Monitor Table、Set-ECN Table和Route Table。各模塊具體如下：

（1）REST API：外部應用（如Map/Reduce應用）和TIP進行通信的接口。

（2）多對一應用注冊模塊（Register）：即多對一通信模式的應用注冊模塊。Aggregator利用REST API向TIP注冊Aggregator自身IP及與Worker通信使用的端口號等。

（3）網絡流量監(jiān)測模塊（Traffic Monitor）：將當前數據中心的網絡流量提供給預防決策生成模塊，并根據注冊信息，向交換機下發(fā)監(jiān)測規(guī)則。即在交換機中建立Monitor Table，將關聯IP和端口號等特征作為匹配項，一旦偵測到多對一通信分組，上報控制器處理。

（4）預防決策生成模塊（Strategy Generator）：交換機上報多對一通信行為后，根據Traffic Monitor提供的流量信息，判斷是否造成TCP Incast。具體為，計算網絡流量及多對一通信的流量總量并記錄于交換機Set-ECN Table，判斷擁塞程度，調整擁塞窗口，從而壓制瓶頸端口（如連接Aggregator的交換機端口）其他流的發(fā)送速度，盡可能保證短流不丟包且能在較短時間內完成傳輸。

（5）BASIC API：該模塊為TIP提供一些和控制器交互的共同API。

圖4 控制和轉發(fā)平面模型

4.3 TCP Incast預防流程

基本流程如圖5所示。

（1）register：Aggregator使用REST API向TIP進行注冊。

圖5 TCP Incast預防流程

（2）set monitoring rules：控制器（TIP）向交換機下發(fā)多對一流量監(jiān)控規(guī)則。

（3）delivery request：Aggregator向多個Worker分發(fā)客戶請求。

（4）report incast：交換機調用算法1，偵測多對一的通信流量，向控制器（TIP）上報。

（5）set incast-avoid rules：TIP向瓶頸交換機下發(fā)預防TCP Incast的規(guī)則。

（6）response：瓶頸交換機通過預防措施騰出更多緩沖資源，保證多個Worker能幾乎同時向Aggregator發(fā)送響應數據。

本文基于SDN數據中心網絡，提出時限感知的擁塞控制算法如下所示。其中，K為交換機判斷是否處于擁塞狀態(tài)所設的閾值；α為隊列長度大于K的概率，體現網絡擁塞程度；懲罰函數p在α≤1時，p≤1，保證擁塞加劇或時限結束時收斂；擁塞窗口W根據網絡擁塞程度調節(jié)。

算法1 SDN時限感知的擁塞控制算法

1：SDN Switch匹配Aggregator ip 與Worker port，偵測many-to-one communication；

2：SDN Switch 根據 many-to-one communication生成Set-ECN Table，計算flow size；

3：if flow size ＜=閾值Kthen保持Aggregator正常發(fā)送，轉1；

4：else SDN Switch向TIP report incast；

5：TIP 向SDN Switch下發(fā)incast-avoid rules：基于D2TCP，對分組標記ECN，利用公式（1）和（6）計算α和p；

6：發(fā)送端根據公式（4）調整congestion windowW，壓制flow rate，避免產生長隊列導致丟包。

5 實驗仿真

5.1 實驗環(huán)境設置

本文采用網絡模擬器NS2進行實驗，使用數據中心網絡的常見拓撲（如FatTree[14]或VL2[15]），如圖5所示。模擬某機架（Rack）的交換機（ToR）和服務器之間的連接。實驗中服務器為35臺，交換機與服務器之間的鏈路帶寬為1 Gb/s，鏈路延遲為20 μs。交換機的端口隊列限制設置為104個分組，取SDN-D2TCP中參數K=35,g=1/16，且為每條流設置時限參數d與期望發(fā)送速率VE。所有的服務器中，1臺作為Map/Reduce應用中的Aggregator，其余34臺作為Worker。短流采用Web搜索場景的查詢流模擬，Aggregator向每個Worker發(fā)送1.6 KB大小的分組請求，Worker收到后，平均經過50 ms間隔返回2 KB的響應分組；在Aggregator收到所有Worker的響應分組后，等待10 ms，再向Worker發(fā)起請求，如此反復。另外，整個實驗過程設置3條長流從不同的Worker向Aggregator傳輸，模擬時間總長度為0.81 s。

5.2 擁塞窗口分析

圖6顯示實驗中長流與查詢流的擁塞窗口變化情況。由于TCP要求交換機有大量緩沖，因此長流容易在交換機上集結，影響查詢流完成。如圖6（a）所示，TCP無法壓制長流，其擁塞窗口呈現幅度較高的鋸齒形變化，大部分查詢流無法完成通信。而DCTCP、D2TCP依據擁塞程度調節(jié)擁塞窗口，減小交換機緩沖，提高查詢流的完成比例。（b）、（c）顯示，DCTCP、D2TCP能穩(wěn)定壓制長流擁塞窗口，只有部分查詢流因丟包而無法順利完成。SDN-D2TCP通過SDN控制器偵測多對一通信，監(jiān)控網絡流量來控制擁塞，由圖（d）顯示，SDN-D2TCP不僅能穩(wěn)定壓制擁塞窗口，并在一些時刻控制更低，減少丟包產生，保證查詢流的多對一通信傳輸。

5.3 交換機隊列長度分析

由圖7所示，TCP使交換機的隊列平均長度維持在較高值80，而DCTCP、D2TCP及SDN-D2TCP能使平均長度保持在37左右，但在多對一通信過程中，DCTCP和D2TCP無法保證隊列長度維持在限制長度104以下。而SDN-D2TCP能將隊列最高長度維持在83左右。由于交換機的隊列長度控制越短，越不容易丟包，因此SDND2TCP能較好改善數據包丟失情況的發(fā)生。

5.4 查詢流時延分析

圖8顯示在TCP、DCTCP、D2TCP以及SDN-D2TCP情況下查詢流時延的概率密度分布。TCP協議下，長短流公平共享，長流占用大部分交換機緩存，擁塞發(fā)生時，發(fā)送端檢測到丟包才進行擁塞控制，調整擁塞窗口，導致查詢流錯過時限，時延性能降低。圖8（a）表明TCP下40%的查詢流時延超過350 ms。DCTCP通過ECN在擁塞即將發(fā)生時，根據擁塞程度，調整發(fā)送速率，提升了性能。但該協議平等共享且時限不可知，因此仍有部分數據流錯過時限。圖8（b）表明DCTCP將大部分查詢流時延維持在53 ms左右，但仍有少量查詢流的時延超過300 ms。D2TCP引入時限感知，進一步減小錯過時限數據流的比例。SDN-D2TCP在D2TCP基礎上，借助SDN全局視野和集中控制的特性，考慮時延敏感約束，縮短了查詢流時延。（c）和（d）表明D2TCP和SDN-D2TCP均使查詢流時延保持在50～53 ms。因此，SDN-D2TCP能較好滿足查詢流的時限約束。

圖6 擁塞窗口對比圖

圖7 交換機隊列長度對比

圖8 查詢流時延的概率分布對比

圖9 查詢流完成次數對比

圖10 吞吐量對比

5.5 吞吐量和查詢流完成次數對比

為了更好地比較SDN-D2TCP與其他傳輸控制協議，本文在長流數量為1、3、5和7，服務器數量為31、33、35和37的情況下，進行仿真實驗，比較吞吐量和查詢流完成次數。由圖9和圖10明顯看出，在各種情況下，TCP因為Incast發(fā)生，導致查詢流完成次數和吞吐量皆小于其他協議。DCTCP和D2TCP的擁塞控制機制能有效緩解Incast，優(yōu)化傳輸性能。而SDN-D2TCP針對多對一通信偵測，預防和控制Incast，因此在各種情況下，查詢流完成次數和吞吐量都優(yōu)于其他三種協議。

6 結論

本文以降低數據中心網絡短流延遲為主要目標，考慮數據流時延敏感特性，基于D2TCP協議結合SDN控制與轉發(fā)分離思想，設計SDN-D2TCP方案，通過SDN控制器預測多對一通信行為，提前預防TCP Incast發(fā)生，保證在長短流競爭，交換機緩沖資源有限的情況下，短流能夠在較短時間內完成傳輸。實驗表明該方案具有較理想的性能。由于D2TCP是根據ECN反饋的擁塞控制策略，部署適應范圍具有一定局限性。下一步將針對延時反饋機制，研究數據中心的SDN-延時反饋擁塞控制策略。

[1]Sreekumari P，Jung J I.Transport protocols for data center networks：A survey of issues，solutions and challenges[J].Photonic Network Communication，2016，31（1）：112-128.

[2]Wu H，Feng Z，Guo C，et al.ICTCP：Incast congestion control for TCP in data-center networks[J].IEEE/ACM Transactions on Networking（TON），2013，21（2）：345-358.

[3]Chen G，Zhao Y，Pei D.Alleviating flow interference in data center networks through fine-grained switch queue management[J].Computer Networks the International Journal of Computer&Telecommunications Networking，2015，91（C）：593-613.

[4]Cheng Wenxue，Ren Rengyuan，Jiang Wanchun，et al.Isolating mice and elephant in data centers[J].arXiv preprint arXiv：1605.07732，2016.

[5]Vamanan B，Hasan J，Vijaykumar T N.Deadline-aware datacenter tcp（d2tcp）[C]//ACM SIGCOMM Computer Communication Review，2012，42（4）：115-126.

[6]Chen L，Hu S，Chen K，et al.Towards minimal-delay deadline-driven data center tcp[C]//Proceedings of the Twelfth ACM Workshop on Hot Topics in Networks，2013：21-27.

[7]McKeownN.Software-definednetworking[J].INFOCOM Keynote Talk，2009，17（2）：30-32.

[8]蘇凡軍，牛詠梅，邵清.數據中心網絡快速反饋傳輸控制協議[J].計算機工程，2015，41（4）：107-111.

[9]Alizadeh M，Kabbani A，Edsall T，et al.Less is more：Trading a little bandwidth for ultra-low latency in the data center[C]//Presented as part of the 9th USENIX Symposium on Networked Systems Design and Implementation（NSDI 12），2012：253-266.

[10]Wilson C，Ballani H，Karagiannis T，et al.Better never than late：Meeting deadlines in datacenter networks[C]//ACM SIGCOMM Computer Communication Review，2011，41（4）：50-61.

[11]Alizadeh M，Yang S，Sharif M，et al.pfabric：Minimal near-optimal datacenter transport[C]//ACM SIGCOMM Computer Communication Review，2013，43（4）：435-446.

[12]Alizadeh M，Greenberg A，Maltz D A，et al.Data center tcp（dctcp）[C]//ACM SIGCOMM Computer Communication Reviews，2010，40（4）：63-74.

[13]張朝昆，崔勇，唐翯祎，等.軟件定義網絡（SDN）研究進展[J].軟件學報，2015，26（1）：62-81.

[14]Al-fares M，Loukissas A，Vahdat A.A Scalable，commodity data center network architecture[C]//ACM SIGCOMM Computer Communication Review，2008，38（4）：63-74.

[15]Greenberg A，Hamilton J R，Jain N.VL2：A scalable and flexible data center network[C]//ACM SIGCOMM Computer Communication Review，2009，39（4）：51-62.