SSRC：時延敏感流的數據源端速率控制算法

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

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

1 引言

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

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

1) 終端設備解決算法

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

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

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

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

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

1) 利用SDN的架構設計能夠對鏈路中出現的長流以及交換機緩存的隊列長度進行監測，快速定位擁塞可能出現的位置，并確認需要進行源端速率調節的目標長流。

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

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

2 算法設計關鍵問題分析

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

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

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

3 算法設計

3.1 算法觸發機制

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

1) 長流的發現

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

2) 隊列長度閾值

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

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

3.2 算法優化問題

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

3.2.1 數學模型

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

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

圖1 可變到達率的數據流生滅過程

以圖1為例，假設緩存隊列長度為k（k≥1），數據流以的概率進入排隊系統，λ為到達率，μ為交換機服務速率。可以得到該生滅過程穩態下的數據流到達概率分布函數，如式(2)所示。

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

3.2.2 優化問題

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

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

排隊系統進入穩定的工作狀態時與時刻t無關，因此式(4)優化的目標函數G(t)可以變形為

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

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

算法1 SWAA

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

4 算法實現

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

圖2 算法設計流程

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

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

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

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

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

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

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

算法2 SSRC

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

5 仿真與評估

5.1 仿真平臺構建

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

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

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

5.2 實驗設計

5.2.1 實驗對象選擇

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

5.2.2 關鍵變量設置

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

1) RTOmin值

圖3 實驗拓撲

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

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

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

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

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

2) 背景流個數

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

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

圖6 背景流數量設置分析

5.2.3 實驗部署

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

5.3 性能評估

5.3.1 數據流完成時間

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

圖7 流完成時間比較

5.3.2 網絡平均吞吐量

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

圖8 吞吐量性能比較

5.3.3 分組丟失率

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

圖9 長短流分組丟失比較

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

圖10 分組丟失率比較

6 結束語

本文針對數據中心網絡如何保證時延敏感流的傳輸時間問題進行了相關研究，在

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