SSRC：時延敏感流的數(shù)據(jù)源端速率控制算法

楊洋，曹敏，楊家海，車嶸，劉偉

（1. 國防科技大學信息通信學院，陜西 西安 710106；2. 清華大學網(wǎng)絡科學與網(wǎng)絡空間研究院，北京 100084；3. 清華信息科學與技術(shù)國家實驗室（籌），北京 100084）

1 引言

當前，數(shù)據(jù)中心95%以上的數(shù)據(jù)流都是TCP流[1]，隨著業(yè)務種類急劇增長，流量的多樣性越來越突出。這些流量可以分為2類：一類是吞吐量敏感型的流量，例如，大量云計算業(yè)務由于虛擬機遷移、數(shù)據(jù)備份等操作產(chǎn)生的長流；另一類是時延敏感型的流量，例如，Web請求（包括搜索流量）業(yè)務、基于MapReduce[2]的并行計算業(yè)務以及社交網(wǎng)絡等在線業(yè)務產(chǎn)生的短流。數(shù)據(jù)中心為業(yè)務提供高可用聚合帶寬保證的同時，網(wǎng)絡擁塞也頻繁發(fā)生，同時網(wǎng)絡中出現(xiàn)的Incast現(xiàn)象逐漸成為數(shù)據(jù)中心區(qū)別于傳統(tǒng)互聯(lián)網(wǎng)的標志性事件。由于當前數(shù)據(jù)中心產(chǎn)生的短流類型業(yè)務大部分是有流傳輸截止時間要求的業(yè)務，一旦傳輸路徑中出現(xiàn)鏈路擁塞，就會導致傳輸超時并嚴重影響用戶體驗。由于TCP長流的“貪婪性”會導致交換機緩存中數(shù)據(jù)分組排隊隊列增長，直到緩存溢出產(chǎn)生分組丟失。如果鏈路中長短流共存，會導致2種情況發(fā)生：一種是短流分組丟失導致Incast出現(xiàn)；另一種是雖然短流分組不丟失，但由于在緩存中排隊的短流數(shù)據(jù)分組轉(zhuǎn)發(fā)優(yōu)先權(quán)低于長流數(shù)據(jù)分組，導致短流數(shù)據(jù)排隊時間超出流傳輸截止時間。由于數(shù)據(jù)中心短流具有突發(fā)、不可預測特性，網(wǎng)絡中任何一條傳輸鏈路都有可能存在因鏈路擁塞而產(chǎn)生的長短流碰撞，導致出現(xiàn)短流分組丟失的可能性。因此，為保證數(shù)據(jù)中心時延敏感流的傳輸時間，有必要在數(shù)據(jù)源端對引起交換機緩存隊列長度超過閾值的長流進行速率調(diào)節(jié)，以避免鏈路中長短流碰撞而導致短流分組丟失。

當前數(shù)據(jù)中心產(chǎn)生短流類型的業(yè)務大部分是有流傳輸截止時間要求的業(yè)務，例如，Web請求類業(yè)務、基于MapReduce并行計算業(yè)務等，一旦傳輸路徑中出現(xiàn)鏈路擁塞，就會導致傳輸超時并嚴重影響用戶體驗。另外，由于網(wǎng)絡中存在大量采用分割/匯聚（partition/aggregate）技術(shù)的業(yè)務，例如，MapReduce以及搜索請求業(yè)務等，這種“多對一”的通信方式帶來的TCP Incast問題也越來越突出[3]。由于 Incast問題通常是由承載匯聚信息的短流分組丟失引起的，因此，Incast問題的解決可以轉(zhuǎn)化為針對時延敏感的短流進行避免傳輸鏈路擁塞的研究[4-6]。當前針對數(shù)據(jù)中心時延敏感流量進行數(shù)據(jù)源端速率控制的研究工作可以分為以下2類。

1) 終端設備解決算法

終端設備的解決算法是指在數(shù)據(jù)發(fā)送端通過調(diào)整發(fā)送窗口值的大小來控制發(fā)送速率的算法。例如，TCP Newreno是對TCP的改進版本，通過引入快速恢復機制避免了快速重傳之后馬上進入慢啟動階段而導致發(fā)送窗口減小過大的問題，是當前網(wǎng)絡通信普遍采用的協(xié)議。文獻[7]通過將最小超時重傳時間RTOmin（retransmission time out）減小到微秒級，緩解由于產(chǎn)生Incast問題而造成的吞吐量下降。另一類算法是設計改進的TCP，例如，D2TCP[8]通過提前獲取數(shù)據(jù)流傳輸?shù)慕刂箷r間，并根據(jù)流截止時間作為調(diào)整擁塞窗口的懲罰因子，計算擁塞窗口大小，達到通過控制數(shù)據(jù)流傳輸速率來消除擁塞的目的。ICTCP[9]以接收端實際測量吞吐量與期望吞吐量之間的差值比率是否超過某個閾值，作為調(diào)整接收窗口大小的依據(jù)，并將調(diào)整的窗口信息以ACK信號反饋給發(fā)送端，達到控制數(shù)據(jù)流速率的目的，從而避免鏈路擁塞導致的短流分組丟失。文獻[10]提出 MMPTCP（maximum multi-path TCP），在終端設置數(shù)據(jù)流傳輸閾值，數(shù)據(jù)流傳輸初始階段是基于分組粒度的多路徑負載均衡，使時延敏感型的數(shù)據(jù)流受益；當傳輸數(shù)據(jù)量超過閾值時，進入第二階段，即由基于數(shù)據(jù)分組粒度的多路徑負載均衡方式切換到 MPTCP（multi-path TCP）[11]模式，有效地保證長流吞吐量。文獻[3]則提出了應用層的解決算法，以一定的隨機概率刻意延遲服務器對請求的響應，從而在某個時間段減少同時參與請求響應的服務器數(shù)量，解決Incast的同步屏障問題。

2) 交換設備支持的解決算法

交換設備支持的解決算法是指由交換機（或路由器）與終端主機共同解決擁塞避免的算法。例如，DCTCP（data center TCP）[1]基于 ECN（explicit congestion notification）[12]的功能，通過設置交換機緩存隊列長度閾值，對超過閾值的數(shù)據(jù)分組進行標記，數(shù)據(jù)源端則根據(jù)反饋的擁塞程度信息按照一定的衰減因子動態(tài)調(diào)整發(fā)送窗口，被標記的分組數(shù)量越多、衰減因子越大，發(fā)送窗口就越小，從而始終保證交換機隊列長度低于某個閾值，防止由于緩存溢出而丟棄數(shù)據(jù)分組。D3[13]則采用帶寬資源預留的方式，提前為數(shù)據(jù)流分配所需傳輸帶寬。數(shù)據(jù)源端首先獲取數(shù)據(jù)流截止時間以及流大小信息，在每一輪 RTT（round trip time）周期內(nèi)發(fā)送相關(guān)傳輸數(shù)據(jù)的帶寬需求信息，交換機收到該信息后計算出預留帶寬并將預留帶寬值寫入數(shù)據(jù)分組頭。數(shù)據(jù)分組傳輸路徑上的所有交換機將執(zhí)行相同的操作，從而保證數(shù)據(jù)流在截止時間內(nèi)傳輸完畢。另外還有通過交換機向數(shù)據(jù)源端發(fā)送“暫?！睅瑢崿F(xiàn)流控的EFC（ethernet flow control）[14]機制以及基于IEEE 802.1Qau以太網(wǎng)標準提出的鏈路層擁塞控制算法 QCN（quantized congestion notification）[15]。

盡管當前的研究算法對于避免數(shù)據(jù)中心出現(xiàn)擁塞鏈路而導致短流分組丟失，以及針對Incast問題的解決都起到了積極的作用，然而在實際部署的可擴展性、實施開銷以及時效性方面都存在不足。其中，終端設備的解決算法對于TCP的改進方法需要接入終端設備修改協(xié)議棧，實施難度高，可擴展性不強。例如，D2TCP 、ICTCP、MMPTCP都需要在終端進行閾值的設定以及相應的判斷、計算操作，D2TCP還需要提前獲取數(shù)據(jù)流截止時間等信息；對TCP參數(shù)進行調(diào)整實施難度雖然低，但是需要其他機制配合，否則效果不理想。例如，減小RTOmin雖然可以提升吞吐量，但也會導致欺騙性重傳。交換設備參與解決的算法需要設備的硬件支持，例如，DCTCP需要在交換機緩沖區(qū)的隊列長度達到閾值時對數(shù)據(jù)分組進行標記；D3則需要交換機根據(jù)數(shù)據(jù)源端的帶寬需求信息計算出預留帶寬，并要求傳輸路徑上的所有交換機對這條數(shù)據(jù)流執(zhí)行相同的操作；EFC和QCN都需要特定的交換機支持。交換設備參與的解決算法對設備硬件要求高，部署開銷較大，尤其對于數(shù)據(jù)中心大多使用低成本的商用交換機的情況，更不適合大規(guī)模的部署。另外，基于TCP連接的反饋回路調(diào)節(jié)源端速率的算法還存在時效性不強的問題，例如，當反饋回路出現(xiàn)鏈路擁塞或者發(fā)生故障時，將影響算法執(zhí)行的效率。

綜上所述，本文基于SDN/OpenFlow的架構(gòu)，提出了數(shù)據(jù)源端控制算法SSRC（SDN-based source rate control）。SSRC依據(jù)網(wǎng)絡的全局視圖，能夠快速定位可能發(fā)生擁塞的節(jié)點，并及時對目標流的源端速率進行調(diào)節(jié)，縮短算法的響應時間。本文的主要貢獻如下。

1) 利用SDN的架構(gòu)設計能夠?qū)︽溌分谐霈F(xiàn)的長流以及交換機緩存的隊列長度進行監(jiān)測，快速定位擁塞可能出現(xiàn)的位置，并確認需要進行源端速率調(diào)節(jié)的目標長流。

2) 控制器利用目標長流建立反饋回路，修改攜帶接收窗口大小的TCP_ACK數(shù)據(jù)分組，并直接將該數(shù)據(jù)分組推送到連接數(shù)據(jù)源端的接入層交換機，極大地縮短了算法機制的響應時間，提高了算法的時效性。

3) 通過將NS3網(wǎng)絡仿真工具與FloodLight外部控制器相結(jié)合，形成基于 SDN架構(gòu)的網(wǎng)絡仿真平臺，仿真實驗結(jié)果證明SSRC能夠保證時延敏感流的傳輸時間，同時能夠很好地解決Incast問題。

2 算法設計關(guān)鍵問題分析

TCP長流的“貪婪性”會導致交換機緩存中數(shù)據(jù)分組排隊隊列增長，直到緩存溢出產(chǎn)生分組丟失。如果鏈路中長短流共存，會導致2種情況發(fā)生：一種是短流分組丟失導致Incast出現(xiàn)；另一種是雖然短流分組不丟失，但由于緩存中排隊的短流數(shù)據(jù)分組轉(zhuǎn)發(fā)優(yōu)先權(quán)低于長流的數(shù)據(jù)分組，導致排隊時間超出流傳輸截止時間。當前在集群化存儲的系統(tǒng)內(nèi)，客戶端的應用請求都以服務請求數(shù)據(jù)單元（SRU, service request unit）方式分別存儲在服務器上，只有當客戶端收到所有服務器的 SRU后，才能繼續(xù)下一個服務請求。然而在鏈路出現(xiàn)擁塞造成排隊隊列處理時延增大甚至導致短流分組丟失嚴重時，會使完成一個TCP應用請求至少經(jīng)歷200 ms的超時[16]。對于時延敏感的業(yè)務，將嚴重影響用戶體驗；對于MapReduce之類的并行計算業(yè)務，將嚴重浪費計算資源。所以，時延敏感的短流受鏈路擁塞影響最大，其根本原因是交換機緩存隊列的積壓導致鏈路中出現(xiàn)的長流與時延敏感的短流出現(xiàn)碰撞，造成短流分組丟失。

D2TCP和D3都是針對時延敏感的短流提出的解決算法，但是兩者都需要提前獲取數(shù)據(jù)流的截止時間，然而實際中這樣的信息可能無法提前獲取。ICTCP主要解決Incast問題，但只是針對最后一跳的鏈路提出的解決算法，沒有考慮承載 SRU的短流分組丟失發(fā)生在中間交換節(jié)點的情況，并且通過接收端窗口大小來控制源端發(fā)送速率需要通過ACK將窗口信息反饋回發(fā)送端，如果反饋回路擁塞或者發(fā)生故障則嚴重影響算法的執(zhí)行效率。DCTCP通過設定交換機隊列長度閾值的方式并基于 ECN將擁塞程度信息反饋回發(fā)送端，這樣的算法除了對交換設備要求高之外，也存在反饋回路影響算法執(zhí)行效率的問題。

綜上所述，本文提出基于SDN/OpenFlow框架的解決算法，能夠克服現(xiàn)有算法存在的不足。由于SDN具有集中化管控的優(yōu)勢，控制器擁有全局的網(wǎng)絡資源視圖，因此更容易提前發(fā)現(xiàn)可能出現(xiàn)擁塞的節(jié)點，通過控制器下發(fā)策略避免擁塞；其次，當發(fā)現(xiàn)可能的擁塞節(jié)點后，控制器能快速進行響應，相對于傳統(tǒng)網(wǎng)絡中接收端通過反饋回路進行數(shù)據(jù)源端速率調(diào)節(jié)的算法，能夠極大地縮短響應時間，提高算法的時效性。本文提出的基于 SDN/OpenFlow的數(shù)據(jù)源端速率控制算法需要解決2個關(guān)鍵問題：一是設計算法的觸發(fā)機制，二是需要獲取數(shù)據(jù)源端優(yōu)化后的目標發(fā)送速率。

3 算法設計

3.1 算法觸發(fā)機制

由于交換機緩存隊列積壓而出現(xiàn)長短流碰撞是導致短流分組丟失的根本原因。同時，必須注意到分組丟失發(fā)生的位置除了包含最后一跳網(wǎng)絡節(jié)點設備外，網(wǎng)絡中間設備都有可能由于交換設備的緩存溢出而導致分組丟失。因此，算法設計的目標是能夠通過全局網(wǎng)絡視圖，提前發(fā)現(xiàn)有可能出現(xiàn)擁塞的網(wǎng)絡節(jié)點，通過觸發(fā)算法避免鏈路由于TCP長流的“貪婪性”造成交換機排隊隊列長度增加從而導致短流分組丟失。因此，算法的觸發(fā)機制由2個關(guān)鍵條件決定：一是鏈路中出現(xiàn)長流，二是出現(xiàn)長流的交換設備中的隊列長度超過閾值。當2個條件同時滿足時算法被觸發(fā)，這樣設計的目的是，針對鏈路中容易引起短流分組丟失的目標長流，快速進行擁塞避免策略響應，增強算法執(zhí)行的時效性。

1) 長流的發(fā)現(xiàn)

當前OpenFlow的版本都支持2種方式統(tǒng)計數(shù)據(jù)流信息[17]：一種是基于控制器發(fā)送Read_State消息，對交換機狀態(tài)信息采用輪詢的方式統(tǒng)計；另一種由交換機發(fā)送異步消息對控制器進行數(shù)據(jù)流信息的推送。由于交換機推送數(shù)據(jù)流信息的方式是當該流傳輸結(jié)束或者流表刪除時向控制器推送消息，并不適合對長流的探測，因此本文采用的方法是控制器以周期輪詢的方式獲取交換機相關(guān)數(shù)據(jù)流信息，并以此發(fā)現(xiàn)長流。采用輪詢的方式探測長流屬于OpenFlow自帶的原生測量，不會產(chǎn)生額外的探測開銷，但需要注意的是輪詢周期不能設置過小，否則會加重控制器與交換機之間的通信負擔。通過對比實驗，在保證能夠探測到目標長流的前提下，將控制器輪詢周期設置為5 s。

2) 隊列長度閾值

設置交換機緩存隊列長度閾值Kt，如式(1)所示。

其中，C代表瓶頸鏈路帶寬，單位為 packet/s，即每秒傳輸數(shù)據(jù)分組的數(shù)量；RTT代表往返時延，單位為 s。在數(shù)據(jù)中心實際環(huán)境中，考慮到流量的突發(fā)特性，Kt往往不能取下限值，通常當鏈路帶寬為1 Gbit/s時，設置Kt= 20；當鏈路帶寬為10 Gbit/s時，設置Kt=65。

3.2 算法優(yōu)化問題

當算法觸發(fā)時，控制器需要計算出合理的數(shù)據(jù)源端發(fā)送速率，而發(fā)送速率值是由數(shù)據(jù)源端的發(fā)送窗口大小決定的。以往的研究工作中，對于數(shù)據(jù)源端發(fā)送窗口大小的反饋調(diào)節(jié)機制大部分都是基于一個前提條件，即N個數(shù)據(jù)源端發(fā)送的響應請求數(shù)據(jù)分組同時到達接收節(jié)點。通過獲取并發(fā)窗口數(shù)從而計算出交換機緩存隊列的長度或者瓶頸鏈路中剩余帶寬的大小，作為調(diào)整數(shù)據(jù)源端發(fā)送速率大小的關(guān)鍵參數(shù)。然而在實際環(huán)境中，由于中間節(jié)點排隊時延以及傳輸路徑的差異，N個數(shù)據(jù)源端發(fā)送的請求數(shù)據(jù)分組同時到達最后一跳節(jié)點的概率非常小，以此為計算基礎所帶來的誤差不可避免。因此，本文采用的方法是基于排隊論對數(shù)據(jù)流的到達行為進行建模，從而設計更為合理的發(fā)送窗口調(diào)節(jié)機制。

3.2.1 數(shù)學模型

目前，數(shù)據(jù)流到達行為的研究主要針對 TCP流，所采用的研究方法主要分為2種：一種是基于長時間粒度統(tǒng)計發(fā)現(xiàn) TCP流具有自相似[18]或者長相關(guān)的特性[19]，對此特性進行具體研究；另一種是根據(jù)排隊論的相關(guān)理論進行研究，例如文獻[20]通過實際測量和仿真分析指出在鏈路帶寬足夠的情況下，數(shù)據(jù)流的到達行為服從泊松分布。由于數(shù)據(jù)中心鏈路具有高帶寬、低時延特性，因此更適合采用排隊論對數(shù)據(jù)流的到達行為進行數(shù)學建模并分析[21]。

文獻[1]指出，當前數(shù)據(jù)中心普遍使用淺緩存的商用以太網(wǎng)交換機，此類交換機的特點是采用共享緩存交換結(jié)構(gòu)。共享緩存結(jié)構(gòu)是指交換機所有的輸出和輸入端口都共享一個緩存池，并且所有經(jīng)過交換機轉(zhuǎn)發(fā)的數(shù)據(jù)分組都需要在緩存中存儲轉(zhuǎn)發(fā)，那么一臺交換機就可以抽象成一個服務窗口，此外，可以認為交換機對數(shù)據(jù)流的轉(zhuǎn)發(fā)即對數(shù)據(jù)流的服務時間服從指數(shù)分布。由于算法被觸發(fā)時，控制器需要立即響應，因此需要對源端發(fā)送速率進行調(diào)整，假設t時刻算法執(zhí)行時需要數(shù)據(jù)源端減小數(shù)據(jù)分組進入系統(tǒng)的概率，那么數(shù)據(jù)流的到達率就不再是穩(wěn)定值，而是依賴t時刻緩存隊列長度k的函數(shù)，因此可以采用基于可變到達率的G/M/1/∞排隊模型進行建模分析[22]，圖1描述了具有可變到達率的數(shù)據(jù)流生滅過程。

圖1 可變到達率的數(shù)據(jù)流生滅過程

以圖1為例，假設緩存隊列長度為k（k≥1），數(shù)據(jù)流以的概率進入排隊系統(tǒng)，λ為到達率，μ為交換機服務速率?？梢缘玫皆撋鷾邕^程穩(wěn)態(tài)下的數(shù)據(jù)流到達概率分布函數(shù)，如式(2)所示。

其中，Pk為t時刻隊列長度處于k狀態(tài)的概率分布，ρ為數(shù)據(jù)流的排隊強度。

3.2.2 優(yōu)化問題

當t時刻算法觸發(fā)時，交換機緩存中隊列長度超過設定閾值，控制器需要計算出數(shù)據(jù)源端合適的發(fā)送窗口大小以防止緩存溢出。此時，t時刻超出閾值部分的隊列長度為

其中，Q(t)為t時刻交換機緩存隊列長度；Kt為所設隊列長度閾值；[?]+表示正值，保證優(yōu)化問題有意義。那么優(yōu)化問題就是使式(3)的隊列長度差值G(t)最小，優(yōu)化問題的目標函數(shù)為

排隊系統(tǒng)進入穩(wěn)定的工作狀態(tài)時與時刻t無關(guān)，因此式(4)優(yōu)化的目標函數(shù)G(t)可以變形為

其中，K為當前隊列長度。將式(2)代入式(5)并對其求和，整理后得到式(6)。

優(yōu)化問題總是伴隨著約束條件。首先，鏈路實際負載不能超過鏈路自身承載能力，鏈路負載能力用Cl表示，即其次，優(yōu)化問題變量的非負取值約束，即ri＞0。最終的優(yōu)化問題為

算法1 SWAA

步驟2)定義了發(fā)送窗口修改函數(shù)，參數(shù)是優(yōu)化后的數(shù)據(jù)源端目標速率值ri以及鏈路的平均時延步驟 3)～步驟 20)具體實現(xiàn)了數(shù)據(jù)源端目標速率調(diào)節(jié)機制，其中，步驟8)鏈路的平均時延由時延抽樣值 sampled_rtt和抽樣次數(shù)sampled_num確定；步驟9)通過控制器輪詢周期及輪詢周期內(nèi)統(tǒng)計到的數(shù)據(jù)流計數(shù)器中的傳輸字節(jié)值計算出數(shù)據(jù)流i初始速率，從而獲得該流的到達率；步驟 17)通過調(diào)用發(fā)送窗口修改函數(shù)，得到數(shù)據(jù)源端的發(fā)送窗口目標值并返回存儲，控制器通過將new_cwnd重新寫入從反饋回路獲取到的TCP_ACK分組，最終達到調(diào)節(jié)數(shù)據(jù)源端速率的目的。

4 算法實現(xiàn)

當前的研究工作中，通常依靠 TCP連接建立的反饋回路傳遞擁塞鏈路信息或者擁塞窗口大小調(diào)節(jié)信息，以達到調(diào)節(jié)發(fā)送速率的目的，避免鏈路擁塞的發(fā)生。但是，如果反饋回路擁塞或者發(fā)生故障則嚴重影響算法的時效性。本文SSRC算法能夠利用SDN/OpenFlow架構(gòu)的優(yōu)勢，很好地解決當前研究算法時效性不高的問題。首先，通過對鏈路中出現(xiàn)的長流以及交換機隊列長度的監(jiān)測，快速定位擁塞可能出現(xiàn)的節(jié)點位置并觸發(fā)算法；控制器利用TCP會話建立的反饋回路修改接入層交換機的反向流表匹配規(guī)則，極大地提高數(shù)據(jù)源端對擁塞節(jié)點的響應時間，提高算法的時效性，在保證短流的傳輸截止時間的同時，防止出現(xiàn)Incast問題。算法流程如圖2所示。具體步驟如下。

圖2 算法設計流程

1) 控制器定時向交換機查詢流表計數(shù)器值，同時監(jiān)控交換機緩存隊列長度。當計數(shù)器值大于長流閾值（判斷為長流），且隊列長度大于設定閾值時，觸發(fā)算法。

2) 控制器向接收端接入交換機下發(fā) FlowMod命令。該 FlowMod關(guān)鍵參數(shù)如下：匹配項為TCP_ACK，優(yōu)先級為最高，HardTimeOut為RTT+ε（ε＜RTT）。

3) 在接入層交換機上，如果數(shù)據(jù)流與更新后的流表匹配成功，則將數(shù)據(jù)分組發(fā)送到控制器。

4) 控制器收到packet_in消息，判斷其reason== OFPR_ACTION后，修改數(shù)據(jù)分組cwnd值。

5) 將修改后的ACK分組，通過packet_out消息，直接推送到數(shù)據(jù)流源端的接入層交換機。

步驟2)的操作是由于數(shù)據(jù)源端速率更新后，至少在一個 RTT時間后接收端才能收到更新的數(shù)據(jù)分組，因此，在RTT+ε內(nèi)都應保持SSRC更新后的發(fā)送窗口值。

將上述步驟轉(zhuǎn)換成控制器端可執(zhí)行的算法程序，并提出數(shù)據(jù)源端控制算法 SSRC（SDN-based source rate control），如算法2所示。

算法2 SSRC

步驟1)～步驟4)設置了SSRC算法的初始值。步驟 5)～步驟 11)定義了長流判斷函數(shù)。步驟 12)～步驟 16)定義了隊列長度是否超過設置閾值的判斷函數(shù)。步驟18)～步驟33)是SSRC的核心代碼，其中，步驟18)～步驟24)判斷當目標長流出現(xiàn)并且隊列長度超出閾值，也就是步驟18)的判斷為真時，控制器會向交換機下發(fā) FlowMod的命令，即步驟 19)～步驟 23)代碼；步驟 25)～步驟 33)執(zhí)行了當控制器接收到 packet_in消息時，判斷出產(chǎn)生packet_in的原因是FlowMod匹配項得以匹配，此時控制器會對數(shù)據(jù)分組進行解析，獲得數(shù)據(jù)分組頭中的擁塞窗口值，調(diào)用SWAA算法進行修改（步驟30)），并將修改后的數(shù)據(jù)分組直接推送到源端的邊緣層交換機。至此，SSRC執(zhí)行完畢。由于算法 2是在一段時間內(nèi)遍歷 n條數(shù)據(jù)流并進行長流的判定，因此算法2時間復雜度為O(n)。

5 仿真與評估

5.1 仿真平臺構(gòu)建

集中架構(gòu)的仿真平臺采用NS3+Floodlight進行搭建。平臺運行的宿主機是戴爾OptiPlex9020服務器，設備硬件的性能參數(shù)為：8核/3.4 GHz主頻的64位處理器，10 GB內(nèi)存，操作系統(tǒng)采用Ubuntu16.04版本。同時，宿主機部署了支持對OpenFlow協(xié)議分析的wireshark軟件。

NS3仿真器采用v3.6版本，使用Floodlight控制器作為外部控制器，并通過Tapbridge與NS3相連。由于NS3具有離散時間仿真的特點，即一旦仿真開始，就不能中途修改參數(shù)。為了實現(xiàn)SSRC的控制功能，本文編寫2個功能模塊預置在Floodlight的應用程序中：一個是 AddDSCPFlowMod，實現(xiàn)下發(fā)流表和添加meter entry；另一個是DSCPController，實現(xiàn)解析數(shù)據(jù)分組和修改發(fā)送窗口值后，將攜帶發(fā)送窗口目標值的數(shù)據(jù)分組直接推送到連接發(fā)送端的接入層交換機。

仿真拓撲選擇當前數(shù)據(jù)中心普遍采用的以交換機為核心的多層拓撲結(jié)構(gòu)，實驗將構(gòu)建K（交換機接入端口數(shù)）值可變的胖樹（fat-tree）拓撲，并以K=8即具有8個POD（performance optimization datacenter）的拓撲規(guī)模進行仿真實驗，如圖3所示。其中，核心層的交換機編號為S101～116，匯聚層的交換機編號為S201～S232，邊緣層的交換機編號為S301～S332，終端主機的編號為H001～H128。

5.2 實驗設計

5.2.1 實驗對象選擇

SSRC性能實驗的對比算法選擇TCP_NewReno以及先前研究工作中具有代表性的2個解決算法。其中，代表終端解決算法采用文獻[3]的方法，即減小最小超時重傳時間 RTOmin，該算法依然基于NewReno算法，只是減小了RTOmin值，實現(xiàn)方法簡單，易于部署；DCTCP則代表交換設備解決算法，基于ECN的標記功能，但是不同于ECN對交換機平均隊列長度閾值做出響應，DCTCP是對交換機瞬時隊列超過閾值的數(shù)據(jù)分組進行標記，其次，ECN的發(fā)送端在收到接收端標記的響應數(shù)據(jù)分組后，發(fā)送窗口減半，而DCTCP發(fā)送端通過感知網(wǎng)絡中間節(jié)點的擁塞程度來動態(tài)調(diào)節(jié)發(fā)送窗口大小，具體做法是被標記的分組數(shù)量越多、衰減因子越大，發(fā)送窗口就越小。相比ECN，DCTCP對網(wǎng)絡擁塞的響應更加及時并且能保證網(wǎng)絡吞吐量的需求，是針對Incast問題比較有效的解決算法。

5.2.2 關(guān)鍵變量設置

考慮到NS3仿真平臺與實際部署的差距，設計實驗時首先需要對仿真過程中的關(guān)鍵變量（即會對實驗結(jié)果產(chǎn)生重要影響但不是實驗研究對象的變量）進行設定，關(guān)鍵變量設置的合理性將直接關(guān)系到實驗結(jié)果的準確性。本實驗需要設置的關(guān)鍵變量是仿真系統(tǒng)默認的 RTOmin值以及背景流個數(shù)（長流）。

1) RTOmin值

圖3 實驗拓撲

NS3-3.26版本內(nèi)核的默認 RTOmin=1 s，但是在實際實驗過程中發(fā)現(xiàn)了虛假重傳的現(xiàn)象。證明實驗如下。20個數(shù)據(jù)源端在沒有背景流的條件下同時發(fā)送請求短流，并保證足夠的鏈路帶寬以及數(shù)據(jù)接收端的緩存容量完全可以容納所有的數(shù)據(jù)分組。通過對實驗數(shù)據(jù)統(tǒng)計發(fā)現(xiàn)并沒有出現(xiàn)分組丟失現(xiàn)象，然而經(jīng)過wireshark抓取分組分析卻發(fā)現(xiàn)了虛假重傳現(xiàn)象，如圖4所示。當RTOmin=1 s時，所有發(fā)送短流都存在虛假重傳。因此，為了準確還原對比算法的實驗效果，仿真中針對RTOmin參數(shù)值的設置需要考慮2個關(guān)鍵要素：首先，需要模擬出DCTCP運行的默認RTOmin值，既能保證不發(fā)生虛假重傳，又能保證不會因為 RTOmin值過大而增大時延；其次，需要模擬出 Linux內(nèi)核中默認的RTOmin=200 ms的TCP連接傳輸效果。為了滿足以上目標，實驗重新設計如下：20個主機同時發(fā)送請求短流，在沒有背景流的情況下，以0.1 s為步長改變RTOmin，統(tǒng)計這20條數(shù)據(jù)流在不同RTOmin值下發(fā)生虛假重傳的比例。實驗結(jié)果如圖4所示，可以觀察到當RTOmin＜3.1 s時，所有的數(shù)據(jù)流都會發(fā)生至少一次的虛假重傳，隨著RTOmin值增加，發(fā)生虛假重傳的百分比減少，當RTOmin＞5 s時，基本達到穩(wěn)定值，即所有數(shù)據(jù)流都不會受到虛假重傳的影響。

圖4 最小超時重傳時間設置分析

為了保證實驗結(jié)果的準確性以及還原比較對象原本的實驗效果，需要進一步確認RTOmin值。從圖4的分析中可以觀察到，RTOmin≥5.8 s時性能比較穩(wěn)定，通過多次測試，最終確認RTOmin=10 s。為了驗證合理性，以默認值 10 s為基準，比較了當RTOmin設置過小的情況下虛假重傳的表現(xiàn)。圖5顯示了主機10.1.1.3在RTOmin= 1 s和RTOmin= 10 s下的實驗結(jié)果對比。

從圖5可以觀察到，當RTOmin=1 s時，在TCP通信連接建立的過程中，所有數(shù)據(jù)分組幾乎同時在22 s左右發(fā)送，導致數(shù)據(jù)流時延增大，而此時的RTOmin值又太小，因此導致在24 s源端又發(fā)送了一次連接請求。當 RTOmin=10 s時，可以明顯看到源端3次握手后順利地建立了連接，縮短了流傳輸?shù)臅r間。

此外，實驗也模擬了 RTOmin設置過大的情況，并以保證 Linux內(nèi)核中默認RTOmin=200 ms時的TCP并發(fā)連接時的網(wǎng)絡性能表現(xiàn)（吞吐量下降2個數(shù)量級），測試后發(fā)現(xiàn)RTOmin=100 s時可以滿足對比要求。最終，對比實驗結(jié)果發(fā)現(xiàn)，當RTOmin=10 s時，流完成時間為 6.3 s，當RTOmin=100 s時，流完成時間變成了103.4 s，因此本實驗設置 RTOmin=10 s能夠模擬出真實的網(wǎng)絡情況。

2) 背景流個數(shù)

圖5 RTOmin分別為1 s和10 s設置分析

在以往研究工作的同類實驗中，一般選擇背景流為5條。但是實際應根據(jù)實驗規(guī)模來確定，因為背景流數(shù)目太大，占總數(shù)據(jù)流的比重過大，一方面會加劇請求短流的分組丟失；另一方面在模擬 Incast環(huán)境時，即使請求短流并發(fā)數(shù)目很小也會有嚴重的分組丟失現(xiàn)象。背景流數(shù)目太少又無法提供客觀的比較值，在計算吞吐量時會有較大誤差。因此應選擇與實際環(huán)境中請求短流和背景流比例相匹配的數(shù)據(jù)流個數(shù)為宜，具體的比例參見DCTCP[1]。圖6是在并發(fā)服務器個數(shù)分別為 20和 30下，改變背景流個數(shù)，對20條請求短流完成時間的統(tǒng)計結(jié)果，目標為盡量減小背景流數(shù)目變化對不同并發(fā)數(shù)下流完成時間的影響，最終選定本次實驗的背景流數(shù)為6條。

圖6 背景流數(shù)量設置分析

5.2.3 實驗部署

通過對實驗關(guān)鍵變量的分析與設置，本文實驗部署如下：實驗瓶頸鏈路帶寬設置為100 Mbit/s，網(wǎng)絡節(jié)點交換機的緩存容量為64 KB。實驗拓撲如圖3所示，每個POD連接16臺服務器主機，共8個POD，編號為1～8。數(shù)據(jù)發(fā)送端和接收端屬于不同POD，故設定POD8中一臺主機為接收端，同時為了避免服務器接入鏈路成為瓶頸鏈路，發(fā)送端主機由其余 POD平均分配，其中，POD1～POD6分別隨機選擇一臺主機，以隨機時間依次開始向接收端發(fā)送的長流作為背景流量；每個POD另外選擇1～12臺主機并發(fā)產(chǎn)生SRU，每個SRU大小設為256 KB，因此接收端共計請求數(shù)據(jù)源端發(fā)送流量大小為N×SRU，N為并發(fā)數(shù)，1≤N≤80。SSRC的性能表現(xiàn)將基于數(shù)據(jù)流完成時間、網(wǎng)絡平均吞吐量以及分組丟失率這3個指標進行評估。

5.3 性能評估

5.3.1 數(shù)據(jù)流完成時間

由于NS3仿真平臺的特殊性，在實際環(huán)境中，平均流完成時間正比于并發(fā)服務器個數(shù)，系數(shù)為同時，考慮到NS3平臺中使用了CSMA信道，以及其他可能的干擾因素，為了保證實驗的嚴謹性，進行圖7 (a)所示的實驗，找出在沒有背景流的情況下，增加并發(fā)服務器個數(shù)與數(shù)據(jù)平均流完成時間擬合的二次函數(shù)。圖7(b)為4種算法在增大并發(fā)服務器個數(shù)下的表現(xiàn)。首先，由于背景流的存在，所有算法下短流的傳輸時間都受到了很大的影響。例如比較并發(fā)數(shù)為45條，增加6條背景流，共 51條數(shù)據(jù)流同時競爭信道時，短流的平均流完成時間最優(yōu)可達到10.50 s（SSRC、NewReno下為30.12 s），而沒有背景流存在時，45條數(shù)據(jù)流傳輸?shù)钠骄魍瓿蓵r間為5.33 s，也就是說出現(xiàn)了成倍的增長。此外，對比4種算法的表現(xiàn)可以得出，并發(fā)數(shù)較少時，不同算法表現(xiàn)沒有太大差異，流完成時間基本維持在7 s左右；隨著數(shù)據(jù)流并發(fā)數(shù)的增多，流完成時間開始增加。相比于其他3種算法，SSRC增加幅度為 62.3%，NewReno、RTOmin和DCTCP分別為411.4%、273.2%和168.1%，SSRC的優(yōu)化效果十分明顯。

圖7 流完成時間比較

5.3.2 網(wǎng)絡平均吞吐量

吞吐量主要針對長流來分析。長流對于時延不是十分敏感，但是對于吞吐量的要求很高，當鏈路發(fā)生擁塞時，長流分組丟失會造成吞吐量的斷崖式下降。另一個特征是TCP NewReno下不同背景流的吞吐量方差很大，反映出部分長流在傳輸過程中的分組丟失可能更多，而一旦發(fā)生分組丟失，很難再和其他正常傳輸?shù)臄?shù)據(jù)流競爭信道，最終表現(xiàn)為鏈路資源分配的不均勻。因此實驗就上述 2個方面進行比較。由圖8(a)可以看出，相比于其他算法，隨著并發(fā)數(shù)的增多，SSRC依然能保持較高的吞吐量；圖8(b)進一步從吞吐量的標準差對比來驗證 SSRC性能。圖 8(b)中不同的虛線是對不同并發(fā)數(shù)下吞吐量標準差的一次線性擬合，可以清晰地看出，通過 SSRC對源端速率的精確控制，能夠保證鏈路充分利用，并且較為平均地將資源分配給每一條數(shù)據(jù)流。

圖8 吞吐量性能比較

5.3.3 分組丟失率

分組丟失對于長流會造成吞吐量的明顯下降，對于時延敏感的短流會造成超時重傳。為了明確NS3中長流和短流在并發(fā)時各自的特性，設計了以下實驗：數(shù)據(jù)中心拓撲中維持6條背景流，在仿真開始后的 23 s左右（此時背景流傳輸穩(wěn)定），30個服務器并發(fā)發(fā)送大小為2 KB的SRU，統(tǒng)計在這30個服務器第一個分組發(fā)送后，每秒內(nèi)長流和短流各種傳輸?shù)臄?shù)據(jù)分組數(shù)目，以及分組丟失的數(shù)目（在RTOmin算法下）。仿真實驗中，第一個短流的數(shù)據(jù)分組在23.484 645 s發(fā)出，最后一個數(shù)據(jù)分組在35.837 998 s收到，統(tǒng)計后得到的結(jié)果如圖9所示。

圖9 長短流分組丟失比較

短流在開始的4 s內(nèi)，發(fā)生了嚴重的分組丟失現(xiàn)象，而長流的分組丟失不嚴重，說明在開始競爭信道時，交換機緩存中基本上都是長流的數(shù)據(jù)分組，后來到達的短流很容易超過閾值而被丟棄，也就是說短流在與長流的競爭中處于劣勢。5～8 s，鏈路依然繁忙，此時已經(jīng)有部分的短流占據(jù)了緩存，導致之后的長流分組丟失率上升，而且短流本身只有2 KB，很容易塞滿交換機而不被丟棄。9 s后短流基本已經(jīng)傳輸完成，通過交換機的數(shù)據(jù)分組占比快速下降，即使緩存溢出，被丟棄的概率也很小。此外，整個實驗結(jié)果都反映了長流的“貪婪性”，因為如果鏈路資源均勻分配，每個時間段內(nèi)發(fā)送的數(shù)據(jù)分組平均應該有 16.67%來自長流，而實際中長流占比最少時（第 7 s）也達到了總傳輸量的33.33%，而且長流占比的下降很可能是之前連續(xù)的分組丟失使源端退避而暫時降低了鏈路資源的占用。通過上面的實驗可以看出，NS3環(huán)境下長短流基本的特性和實際網(wǎng)絡環(huán)境中一致。在長短流特性已知的前提下保證背景流數(shù)目為 6且不變，增加并發(fā)服務器個數(shù)，對短流的分組丟失率進行統(tǒng)計，如圖10所示。對比發(fā)現(xiàn)，SSRC的控制算法降低分組丟失率的表現(xiàn)優(yōu)越，即使在鏈路狀態(tài)十分惡劣的情況下，也基本能夠保證分組丟失總數(shù)在10個以內(nèi)。

圖10 分組丟失率比較

6 結(jié)束語

本文針對數(shù)據(jù)中心網(wǎng)絡如何保證時延敏感流的傳輸時間問題進行了相關(guān)研究，在

SDN/OpenFlow的架構(gòu)下，提出了一種基于數(shù)據(jù)源端速率控制的算法 SSRC。該算法能夠準確定位可能發(fā)生擁塞的節(jié)點設備，通過控制器快速進行應對策略的響應，相較于傳統(tǒng)網(wǎng)絡中接收端通過反饋回路進行數(shù)據(jù)源端速率調(diào)節(jié)的算法，能夠極大地縮短響應時間，解決現(xiàn)有算法時效性不高的問題。最后，通過將NS3仿真工具與Floodlight外部控制器相連，實現(xiàn)SDN/OpenFlow架構(gòu)下的數(shù)據(jù)中心網(wǎng)絡環(huán)境中進行，同時與 DCTCP等 3種解決算法進行比較，仿真實驗結(jié)果證明SSRC能夠保證時延敏感流的傳輸時間，同時能夠很好地解決Incast問題。