李樹楠，詹男杰，章 玥

(1.華東師范大學上海市高可信計算重點實驗室，上海 200062;2.華東師范大學教育部軟硬件協(xié)同設計技術與應用工程研究中心,上海 200062;3.復旦大學計算機科學與技術學院，上海 201203)

1 引言

傳統(tǒng)的TCP(Transmission Control Protocol)擁塞控制算法以端主機為中心，將丟包作為擁塞標志。隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)絡層轉(zhuǎn)發(fā)節(jié)點通過對數(shù)據(jù)包進行擁塞標記，即顯式擁塞通知ECN(Explicit Congestion Notification)，大大改進了傳統(tǒng)TCP擁塞控制算法的效率[1]。ECN機制的實現(xiàn)離不開端主機操作系統(tǒng)的支持[2]。在數(shù)據(jù)中心網(wǎng)絡中，并不是所有的主機都實現(xiàn)了ECN，不支持ECN的主機與支持ECN的主機同時傳輸數(shù)據(jù)時，存在不公平現(xiàn)象；擁塞發(fā)生時，不支持ECN的主機占據(jù)的帶寬較低[3,4]。

Figure 1 vCC conversion layer and TCP traffic interaction圖1 vCC轉(zhuǎn)換層與TCP業(yè)務流的交互

針對上述不公平現(xiàn)象，目前的數(shù)據(jù)中心網(wǎng)絡主要采用以下幾種解決方案：(1)根據(jù)需求嚴格分配租戶所使用的帶寬[5]，這種方案會造成帶寬資源的浪費；(2)修改數(shù)據(jù)中心中交換機內(nèi)部的帶寬分配規(guī)則，以實現(xiàn)租戶間帶寬的公平性[6]，這種方案會隨著租戶以及交換機數(shù)目的增加變得非常復雜；(3)在數(shù)據(jù)中心虛擬管理程序中增加一個適配層，對所有經(jīng)過虛擬管理程序的數(shù)據(jù)流進行處理，如虛擬擁塞控制vCC(virtualized Congestion Control)[7]、AC/DC(Administrator Control over Data Center)[8]等。這種方案只需在虛擬管理程序中配置一次即可實現(xiàn)租戶間帶寬的公平性。vCC采用了抑制接收窗口(Throttle Receive Window)的機制，使不支持ECN的主機在訪問數(shù)據(jù)中心網(wǎng)絡時，獲得與帶ECN主機相近的網(wǎng)絡帶寬，提升網(wǎng)絡的公平性，有效地解決了上述問題。

vCC[7]中討論了租戶帶寬同等、流量速率一致的公平性問題，面對租戶帶寬不相同的真實場景時vCC的性能表現(xiàn)未在文中體現(xiàn)。本文從租戶帶寬特征及其中涉及的異常場景兩方面著手，設計相應的仿真場景，對vCC的性能進行實驗分析，明確vCC的工作效果。

2 虛擬擁塞控制

2.1 虛擬擁塞控制原理

當前的數(shù)據(jù)中心網(wǎng)絡中的擁塞控制機制多已支持顯式擁塞通知(ECN)，租戶和部分遺留設備使用的仍舊是尚不支持ECN的傳統(tǒng)的NewReno[9]或者Reno算法。對于當前數(shù)據(jù)中心網(wǎng)絡中因擁塞控制機制所產(chǎn)生的不公平現(xiàn)象，vCC轉(zhuǎn)換層對non-ECN數(shù)據(jù)流主要做了以下三個工作：(1)修改TCP頭部字段實現(xiàn)數(shù)據(jù)中心中underlay網(wǎng)絡對ECN的支持；(2)當接收到ECN擁塞通知信號時，減小TCP頭部字段中的接收窗口值，降低overlay網(wǎng)絡中租戶發(fā)送數(shù)據(jù)包數(shù)量；(3)修改ACK的頭部字段，表明overlay網(wǎng)絡中發(fā)生擁塞。通過這種轉(zhuǎn)換之后的數(shù)據(jù)流被稱為virtual-ECN(vECN)數(shù)據(jù)流。

發(fā)送方的發(fā)送窗口大小取決于擁塞窗口以及接收窗口兩者中的最小值，vCC通過抑制接收窗口大小來通知發(fā)送方網(wǎng)絡發(fā)生了擁塞。圖1給出了vCC對不支持ECN的客戶端發(fā)送的數(shù)據(jù)流的修改情況。圖1a中vCC修改發(fā)送方TCP報頭字段實現(xiàn)底層網(wǎng)絡中對ECN的支持；圖1b中vCC修改數(shù)據(jù)分組中IP頭部的ECT字段并實現(xiàn)ACK的透明轉(zhuǎn)發(fā)；圖1c表明，當vCC收到ECN擁塞通知時，修改ACK報文中RWIN字段，迫使客戶端調(diào)整發(fā)送窗口大小，降低發(fā)送速率，達到擁塞控制的目的。從圖1中可以看出，當數(shù)據(jù)從發(fā)送方經(jīng)過vCC時，vCC把發(fā)送方non-ECN的數(shù)據(jù)流轉(zhuǎn)換為ECN的數(shù)據(jù)流，接收方帶ECN標記的確認幀轉(zhuǎn)換為不帶ECN標記的數(shù)據(jù)幀，使數(shù)據(jù)流所使用的擁塞控制算法對發(fā)送方和接收方透明。

2.2 vCC實現(xiàn)

一個版本的vCC是在Linux內(nèi)核中實現(xiàn)的。仿真實驗要模擬數(shù)據(jù)中心網(wǎng)絡中的虛擬管理程序，因此在Linux下使用Mininet[10]進行仿真時要先對Linux內(nèi)核進行修改，以模擬數(shù)據(jù)中心網(wǎng)絡的虛擬管理程序?qū)W(wǎng)絡中的數(shù)據(jù)流進行管理，并實現(xiàn)non-ECN數(shù)據(jù)流到virtual-ECN數(shù)據(jù)流的轉(zhuǎn)換過程。

另一個版本的vCC則是一個基于VMware(Virtual Machine ware)ESXi虛擬機管理程序中的vSwitch(virtual Switch)實現(xiàn)的概念驗證系統(tǒng)，其本質(zhì)是一個虛擬擁塞控制轉(zhuǎn)換層。vCC在此虛擬機管理程序環(huán)境中可以保證帶寬的公平性。

3 數(shù)據(jù)中心租戶帶寬特征分析

隨著互聯(lián)網(wǎng)的發(fā)展，數(shù)據(jù)中心網(wǎng)絡呈現(xiàn)高帶寬、長延遲的特征，數(shù)據(jù)中心中租戶的需求特征也有了變化。當前數(shù)據(jù)中心租戶需求特征可以總結(jié)為：(1)主機數(shù)目不同；(2)帶寬需求不同；(3)網(wǎng)絡發(fā)生極度擁塞現(xiàn)象；(4)租戶使用不同擁塞控制算法。本文從這四個方面對vCC的性能進行分析。

3.1 租戶主機數(shù)目不同

數(shù)據(jù)中心租戶是使用數(shù)據(jù)中心資源，獲得數(shù)據(jù)中心服務的用戶[11]。伴隨數(shù)據(jù)中心網(wǎng)絡的高速發(fā)展，數(shù)據(jù)中心網(wǎng)絡在體系架構、服務規(guī)模等方面產(chǎn)生了大量的變化。一個當代數(shù)據(jù)中心所擁有的服務器數(shù)目可達數(shù)萬甚至是數(shù)十萬，并且規(guī)模仍有加大的趨勢[12]。數(shù)據(jù)中心租戶作為數(shù)據(jù)中心的服務對象，數(shù)量也在不斷增加。vCC[7]作者在進行仿真實驗時，發(fā)送方主機數(shù)目為固定的10臺，而現(xiàn)有數(shù)據(jù)中心交換機所支持的可連接主機數(shù)目已遠高于這個數(shù)值。討論不同主機數(shù)目對vCC的性能的影響具有一定的必要性。

3.2 租戶帶寬需求不均等

文獻[11]認為，現(xiàn)代數(shù)據(jù)中心廣泛采用虛擬化技術，將基礎物理資源組合成虛擬資源總池，以便靈活高效地利用與分配資源。由于虛擬資源不受物理資源切分限制，租戶可以根據(jù)實際需要購買、使用數(shù)據(jù)中心的虛擬資源。該現(xiàn)象表明數(shù)據(jù)中心租戶帶寬具有需求多樣化的特點。vCC方法作為數(shù)據(jù)中心擁塞控制解決方案，在進行擁塞控制的同時，也為租戶帶寬提供了公平性保證。vCC作者指出了vCC在租戶帶寬均等的情況下能夠保障ECN流與非ECN流之間的公平性。在數(shù)據(jù)中心租戶帶寬不均等的條件下，vCC是否還能保證ECN流與非ECN流之間的公平性是一個值得探究的問題。

3.3 數(shù)據(jù)中心網(wǎng)絡出現(xiàn)極度擁塞現(xiàn)象

數(shù)據(jù)中心網(wǎng)絡中會出現(xiàn)不可預測的異常場景。當瓶頸鏈路極度擁塞時，帶有ECN標記的數(shù)據(jù)段與攜帶抑制接收窗口信息的數(shù)據(jù)段都會發(fā)生丟失，vCC的性能會受到影響。

在數(shù)據(jù)中心網(wǎng)絡中，引起網(wǎng)絡極度擁塞的原因有多個，交換機的隊列長度、隨機早期檢測算法的參數(shù)設置以及瓶頸鏈路帶寬的大小都有可能導致網(wǎng)絡出現(xiàn)極度擁塞的情況。

在網(wǎng)絡傳輸過程中，瓶頸鏈路是整個網(wǎng)絡系統(tǒng)中最容易產(chǎn)生擁塞的節(jié)點。在瓶頸鏈路中，瓶頸鏈路隊列長度指的是瓶頸鏈路節(jié)點的緩沖區(qū)長度。瓶頸鏈路隊列長度過小時，因交換機的處理能力有限，高速傳輸?shù)臄?shù)據(jù)流在一定的時間內(nèi)沒有被處理會導致緩沖區(qū)滿，此時網(wǎng)絡發(fā)生極度擁塞現(xiàn)象，交換機將使用RED(Random Early Detection)等算法對數(shù)據(jù)流進行隨機丟包或標記。

大型數(shù)據(jù)中心網(wǎng)絡中，鏈路帶寬很大，當數(shù)據(jù)流傳輸很快時，交換機的緩沖區(qū)中的數(shù)據(jù)得不到及時處理，很容易被填滿，網(wǎng)絡容易出現(xiàn)擁塞現(xiàn)象。中小型數(shù)據(jù)中心網(wǎng)絡中，受成本限制，交換機的性能有限，本身的緩沖區(qū)比較小，這種情況下，網(wǎng)絡也極易發(fā)生極度擁塞。另外，許多大型數(shù)據(jù)中心網(wǎng)絡是由中小型數(shù)據(jù)中心合并來的，部分網(wǎng)絡區(qū)域的交換機緩沖區(qū)較小，其余部分的緩沖區(qū)較大，傳輸?shù)臄?shù)據(jù)流在性能比較差的區(qū)域會發(fā)生擁塞。

RED的主要參數(shù)包括min，max，prob，limit，burst，avpkt，bandwidth，ecn。隨機早期丟棄的思想是：當交換機或路由器中的平均隊列長度低于min值時，沒有數(shù)據(jù)包被標記或丟棄；當平均隊列長度達到min時，數(shù)據(jù)包被標記或丟棄的可能性以線性增長的幾率逐漸接近prob，直到平均隊列長度達到max值；當平均隊列長度超過max時，數(shù)據(jù)包一定會被標記或丟棄。在網(wǎng)絡極度擁塞的情況下，不同的RED參數(shù)設置將會導致帶有ECN標記的數(shù)據(jù)段發(fā)生不同程度的丟失。

在互聯(lián)網(wǎng)中，發(fā)送方到接收方之間的網(wǎng)絡鏈路通常是有多條，數(shù)據(jù)在傳輸?shù)倪^程中通常會根據(jù)鏈路延時、鏈路是否通暢等因素來選擇最優(yōu)或者次優(yōu)的鏈路。當某一條鏈路中斷時，數(shù)據(jù)可以通過其他鏈路進行傳輸。在大型數(shù)據(jù)中心網(wǎng)絡中，租戶可以通過多條鏈路向服務器發(fā)送或者接收數(shù)據(jù)。當某一條或者某幾條鏈路發(fā)生故障時，其余鏈路就會承擔其數(shù)據(jù)量，出現(xiàn)負載現(xiàn)象。這種情況下，網(wǎng)絡就會發(fā)生極度擁塞現(xiàn)象。而在中小型數(shù)據(jù)中心網(wǎng)絡中，本身鏈路帶寬就不高，當出現(xiàn)故障時，極度擁塞現(xiàn)象就更加明顯。

Figure 2 Network topology for multi-host experiment圖2 多主機實驗網(wǎng)絡拓撲圖

3.4 租戶使用不同擁塞控制算法

互聯(lián)網(wǎng)出現(xiàn)以來，擁塞控制算法就在不斷地更新與完善。在數(shù)據(jù)中心網(wǎng)絡中，遺留設備或者租戶使用的可能是舊版本的擁塞控制算法，例如，實現(xiàn)了慢啟動、擁塞避免、快速重傳與快速恢復的Reno算法，使用二分搜索對擁塞窗口進行調(diào)整的BIC-TCP(Binary Increase Congrestion control TCP)算法、高速網(wǎng)絡中的HSTCP(High Speed TCP)[13]算法及其改進的HHSTCP(noval High Speed TCP)算法等。

vCC的目的之一是使租戶可以自定義自己的擁塞控制算法，平衡不同擁塞控制算法之間的公平性。當租戶更改自己的擁塞控制算法時，數(shù)據(jù)中心網(wǎng)絡的虛擬管理程序不會被通知，vCC需要盡可能地保證不同擁塞控制算法之間的公平性，以給予用戶良好的體驗。

4 仿真實驗設計

文獻[7]只考慮了數(shù)據(jù)中心網(wǎng)絡中帶寬為100 Mbps和1 000 Mbps的情況，且發(fā)送方主機、接收方主機以及瓶頸鏈路的帶寬都相同，這與數(shù)據(jù)中心實際的環(huán)境不是很符合。本文根據(jù)數(shù)據(jù)中心中租戶帶寬需求特征，設計了四個仿真實驗，分別描述如下。

4.1 租戶主機數(shù)目不同vCC性能分析

(1)實驗描述。

文獻[7]中Mininet實驗的主機數(shù)目固定，發(fā)送方均為10臺主機，不能很好地說明vCC的性能表現(xiàn)。本實驗討論了多主機的場景，對non-ECN流與ECN流之間的不公平現(xiàn)象和多主機狀況下vCC的性能進行了實驗分析。

(2)拓撲結(jié)構。

以20臺發(fā)送方主機為例，圖2給出了實驗的網(wǎng)絡拓撲圖。

(3)參數(shù)設置。

以圖2的網(wǎng)絡拓撲結(jié)構的實驗為例，發(fā)送方中10臺主機開啟了ECN，剩余10臺開啟了vECN。主要參數(shù)見表1。

Table 1 Multi-host experiment parameters表1 多主機實驗參數(shù)表

Figure 3 Network topology for tenant bandwidth difference experiment圖3 租戶帶寬差異實驗網(wǎng)絡拓撲圖

4.2 租戶帶寬差異vCC性能分析

(1)實驗描述。

文獻[7]中實驗的鏈路帶寬沒有差異，各發(fā)送方主機帶寬均相同，不符合租戶的實際需求場景。本實驗將發(fā)送方主機分為兩類，分別對應高低兩種不同的鏈路帶寬。為了使鏈路擁塞時低帶寬被完全占用，瓶頸鏈路帶寬與高帶寬數(shù)值一致。

(2)拓撲結(jié)構。

圖3給出了實驗的網(wǎng)絡拓撲圖。

(3)參數(shù)設置。

以圖3的網(wǎng)絡拓撲結(jié)構的實驗為例，發(fā)送方中5臺主機開啟了ECN，剩余5臺開啟了vECN。主要參數(shù)見表2。

Table 2 Experiment parameters of tenants’ bandwidth differences表2 租戶帶寬差異實驗參數(shù)表

4.3 網(wǎng)絡極度擁塞下vCC性能分析

(1)實驗描述。

文獻[7]沒有考慮瓶頸鏈路極度擁塞時，帶有ECN標記的數(shù)據(jù)包及攜帶抑制接收窗口信息的數(shù)據(jù)包會丟失，對vCC的性能產(chǎn)生影響。本實驗分析了交換機的隊列長度、隨機早期檢測算法的參數(shù)以及瓶頸鏈路帶寬的大小引起網(wǎng)絡極度擁塞的場景下對vCC性能的影響。

(2)拓撲結(jié)構。

圖4給出了本實驗的網(wǎng)絡拓撲圖。

Figure 4 Network topology for network extreme congestion experiment圖4 網(wǎng)絡極度擁塞實驗拓撲結(jié)構圖

(3)參數(shù)設置。

本實驗有三種網(wǎng)絡極度擁塞場景，表3給出了不同瓶頸鏈路緩沖隊列長度場景下實驗的部分參數(shù)。其中，bw為所有鏈路帶寬。

Table 3 Network extreme congestion parameters表3 網(wǎng)絡極度擁塞部分參數(shù)表

4.4 租戶使用不同擁塞控制算法時vCC性能分析

(1)實驗描述。

文獻[7]中只對Reno算法進行了仿真實驗，實際上，更多的擁塞控制算法已經(jīng)應用在數(shù)據(jù)中心網(wǎng)絡中，比如HSTCP、BIC-TCP等等。本實驗對不同擁塞控制算法下vCC的性能進行了分析。

(2)拓撲結(jié)構。

圖5給出了本實驗的網(wǎng)絡拓撲圖。

(3)參數(shù)設置。

實驗中使用iperf設置數(shù)據(jù)流使用的擁塞控制算法，表4給出了實驗所使用的擁塞控制算法及其所對應的iperf參數(shù)。

Table 4 Congestion control algorithm and iperf parameters表4 擁塞控制算法與iperf參數(shù)表

5 實驗結(jié)果

5.1 仿真環(huán)境

表5給出了仿真實驗的軟硬件環(huán)境。

5.2 租戶主機數(shù)目對vCC性能的影響

Figure 5 Network topology for different congestion control algorithms experiment圖5 不同擁塞控制算法實驗網(wǎng)絡拓撲圖

Figure 6 Multi-host ECN and vECN fairness experiment圖6 多主機ECN和vECN公平性實驗

圖6是20臺主機數(shù)目下，ECN公平性實驗及vECN公平性實驗的結(jié)果,其中，non-ECN主機數(shù)逐漸減少。圖6a～圖6c表明，在不開啟vCC時，ECN流的吞吐量幾乎總是大于non-ECN流的。ECN流明顯搶占了non-ECN流的帶寬資源。從圖6d～圖6f可以看出,ECN流與vECN流的吞吐量大小較為接近,ECN流與vECN流在鏈路中的公平性基本一致。

Table 5 Environments of simulation experiment表5 仿真實驗環(huán)境

Figure 7 Unequal bandwidth ECN and vECN fairness experiment圖7 不均等帶寬ECN和vECN公平性實驗

5.3 租戶帶寬差異對vCC性能影響

圖7為不同主機帶寬下，ECN公平性實驗與vECN公平性實驗的結(jié)果圖。圖7a～圖7c表明，租戶帶寬不均等且流的總數(shù)目固定時，增加ECN流的數(shù)量會導致non-ECN流獲得的帶寬資源減少，導致non-ECN流饑餓。從圖7d～圖7f可以看出，在租戶主機帶寬不均等的情況下，vECN流的吞吐量提高了100%以上，獲得了較好的公平性。

5.4 網(wǎng)絡極度擁塞對vCC性能影響

本實驗從瓶頸鏈路緩沖隊列大小、RED參數(shù)、瓶頸鏈路帶寬三個方面產(chǎn)生網(wǎng)絡極度擁塞的場景對vCC的性能影響進行分析。圖8為瓶頸鏈路緩沖隊列大小導致的網(wǎng)絡極度擁塞場景下的vCC性能結(jié)果。其余結(jié)果與圖8類似。

Figure 8 Bottleneck link network extreme congestion vCC experiment圖8 瓶頸鏈路網(wǎng)絡極度擁塞vCC實驗

從圖8中可以看出，網(wǎng)絡極度擁塞場景下，vCC的性能表現(xiàn)比較好，盡可能地保證了non-ECN流與ECN流之間的公平性。經(jīng)過vCC轉(zhuǎn)換的non-ECN數(shù)據(jù)流會出現(xiàn)比ECN流帶寬低10%左右的現(xiàn)象，總體相差不大。這主要是因為瓶頸鏈路丟包時，ECN與virtual-ECN數(shù)據(jù)包會同時丟失，兩種數(shù)據(jù)包的處理過程基本相同，vCC的性能表現(xiàn)良好。

5.5 不同擁塞控制算法對vCC性能影響

圖9為幾種常見擁塞控制算法下vCC的性能結(jié)果。從圖9中可以看出，鏈路帶寬較低時，使用Vegas[14]與YeAH-TCP的主機公平性不一致，vCC性能較低；高帶寬時，使用YeAH-TCP的主機吞吐量較低，vCC的性能不穩(wěn)定。vCC能保證使用BIC-TCP、HSTCP和Reno算法的主機在與ECN競爭的過程中的公平性。

Figure 9 vCC experiment for different congestion control algorithms 圖9 不同擁塞控制算法vCC實驗

6 結(jié)束語

本文分析了數(shù)據(jù)中心租戶帶寬需求，設計了不同的仿真實驗。通過在Mininet下的仿真實驗，對vCC工作性能進行了分析。實驗結(jié)果表明，vCC在租戶主機個數(shù)增加以及租戶帶寬存在差異的條件下都能保障ECN流與non-ECN流之間的公平性；vCC在網(wǎng)絡極度擁塞的情況下仍具有較好的性能，但是在主機擁塞控制算法不同時，vCC的性能在擁塞控制算法BIC-TCP、HSTCP和Reno環(huán)境中表現(xiàn)良好，在YeAH-TCP環(huán)境下解決ECN不公平性效果較差。在Mininet下進行仿真實驗時，交換機的每個端口為單隊列，和數(shù)據(jù)中心網(wǎng)絡中的實際情況不是很符合。針對此問題，后續(xù)可以使用MQ-ECN(Multi-Queue ECN)[15]中提出的基于多隊列數(shù)據(jù)中心的動態(tài)的ECN標記閾值調(diào)整機制來進行研究。