軟件定義網(wǎng)絡(luò)中TCP偽擁塞問題探究

邰冬哲 張 庭 劉 斌

(清華大學(xué)計算機(jī)科學(xué)與技術(shù)系 北京 100084)(tdz13@mails.tsinghua.edu.cn)

軟件定義網(wǎng)絡(luò)中TCP偽擁塞問題探究

邰冬哲 張 庭 劉 斌

(清華大學(xué)計算機(jī)科學(xué)與技術(shù)系 北京 100084)(tdz13@mails.tsinghua.edu.cn)

軟件定義網(wǎng)絡(luò)(software-defined networking, SDN)將控制平面與轉(zhuǎn)發(fā)平面分離，通過控制器配置交換機(jī)流表項來實現(xiàn)網(wǎng)絡(luò)的靈活控制，極大地提高了網(wǎng)絡(luò)帶寬利用率.隨著SDN的蓬勃發(fā)展，越來越多的高校和公司開始部署SDN.同時SDN也面臨著一些傳統(tǒng)IP網(wǎng)絡(luò)中不存在的問題，如一些原本在IP網(wǎng)絡(luò)中運(yùn)行良好的協(xié)議在SDN網(wǎng)絡(luò)中性能卻受到了嚴(yán)重的影響，TCP協(xié)議就是其中之一.從SDN的工作機(jī)制出發(fā)，通過3個場景闡明了SDN在proactive工作模式下依然存在Packet-In短時間內(nèi)高速并發(fā)的可能性.總結(jié)并實驗驗證了高速并發(fā)的Packet-In以及流表更新時舊表項需重排列的特性都會使數(shù)據(jù)包在SDN網(wǎng)絡(luò)中產(chǎn)生較大時延.實驗結(jié)果表明，當(dāng)TCAM支持4 000個流表項時，最壞情況下僅由新插入流表項優(yōu)先級原因?qū)е乱延辛鞅眄椀闹嘏帕芯湍苁箚未蝹鬏敃r延達(dá)到10 s，并發(fā)的高速Packet-In則會使時延加大.以實驗為基礎(chǔ)，揭示了由于SDN網(wǎng)絡(luò)特性造成的偽擁塞現(xiàn)象，即傳統(tǒng)TCP在SDN網(wǎng)絡(luò)中面臨兩大問題：1)TCP建立連接困難；2)TCP協(xié)議傳輸?shù)托?最后通過對實驗現(xiàn)象進(jìn)行分析，提出了解決SDN網(wǎng)絡(luò)中TCP低效問題可能的工作方向.

軟件定義網(wǎng)絡(luò)；傳輸控制協(xié)議；時延；主動模式；擁塞

① TCAM(ternary content addressable memory)是一種3態(tài)內(nèi)容存儲器，支持wildcard查找，可以在1個時鐘周期內(nèi)給出查找結(jié)果.

為了實現(xiàn)網(wǎng)絡(luò)的靈活管理、提高網(wǎng)絡(luò)性能、降低管理成本，軟件定義網(wǎng)絡(luò)(software-defined networking, SDN)被提出并得到了廣泛的研究.SDN將交換機(jī)控制平面(control plane)與數(shù)據(jù)平面(data plane)分離，利用控制器通過南向接口向數(shù)據(jù)平面上的流表下載規(guī)則(rule)，從而指導(dǎo)數(shù)據(jù)包轉(zhuǎn)發(fā).由于TCAM①查找速度快且支持wildcard，因此當(dāng)前大量商用硬件SDN交換機(jī)都采用TCAM存放流表[1-2].目前應(yīng)用最廣泛的南向接口是OpenFlow[3].1條規(guī)則可以包含1個或多個字段(field)，并伴有對匹配到的數(shù)據(jù)包進(jìn)行操作的動作(action).

由于SDN控制器具有集中控制并掌握全局信息的特性，一些在傳統(tǒng)IP網(wǎng)絡(luò)中難以處理的問題在SDN中得到了很好的解決[4].由于流表缺失時SDN交換機(jī)需要與控制器通信才能指導(dǎo)數(shù)據(jù)包的轉(zhuǎn)發(fā)，可能造成較大時延，因此研究人員圍繞SDN交換機(jī)和控制器開展了很多的測量工作[5-6].通過將SDN的工作模式設(shè)定成主動模式，控制器和交換機(jī)很多性能問題得以解決.

TCP提供面向連接的傳輸服務(wù)，需要經(jīng)過3次握手才能建立連接.傳統(tǒng)的TCP已經(jīng)能夠穩(wěn)定地運(yùn)行在IP網(wǎng)絡(luò)中，面臨的擁塞問題也得到了充分的研究[7-8].但是在SDN網(wǎng)絡(luò)中，SDN的網(wǎng)絡(luò)特性是否會影響TCP的性能，目前并沒有工作能很好地說明.

本文提出并實驗驗證了SDN網(wǎng)絡(luò)中TCP可能存在的偽擁塞現(xiàn)象，并對偽擁塞現(xiàn)象產(chǎn)生的原因進(jìn)行了深入的分析.偽擁塞現(xiàn)象使得TCP在建立連接時出現(xiàn)問題，同時在TCP連接建立之后可能使傳輸效率降低.在本文第4節(jié)，我們提出了解決該問題的可能方法.

1 動機(jī)與問題描述

1.1 SDN的工作模式

SDN支持2種工作模式：被動模式(reactive)和主動模式(proactive).

1) reactive工作模式.所謂被動模式，是指任何在交換機(jī)流表中找不到匹配項的數(shù)據(jù)包，都以Packet-In的形式發(fā)送給控制器，由控制器根據(jù)策略生成流表項后，通過Flow-Mod下發(fā)到交換機(jī).在reactive模式下，SDN的網(wǎng)絡(luò)管理將會更加靈活.但是交換機(jī)的性能很容易受到控制器的處理速度、交換芯片與Local CPU之間的帶寬等因素的影響[5].因此在當(dāng)前網(wǎng)絡(luò)基礎(chǔ)設(shè)施下，工業(yè)界普遍偏向于proactive的工作模式[1].

2) proactive工作模式.控制器將所有流表項計算出，并提前下發(fā)到交換機(jī)流表中(盡管該交換機(jī)可能還未轉(zhuǎn)發(fā)過該流表項對應(yīng)的數(shù)據(jù)包).受TCAM大小所限，如果當(dāng)前已知的流表項全部提前下發(fā)到交換機(jī)，需要存放在交換芯片的片上存儲.由于以上原因，TCAM一般充當(dāng)高速緩存(cache).數(shù)據(jù)包到達(dá)后，先在TCAM中查找，如果沒有匹配則從片上存儲中進(jìn)行查找轉(zhuǎn)發(fā).相比于reactive模式，proac-tive模式能在一定程度上解決controller與switch之間通信時延較大的問題.

但是我們觀察到即使SDN網(wǎng)絡(luò)工作在proactive模式下，也無法完全避免交換機(jī)產(chǎn)生Packet-In.為驗證這一結(jié)論，以下列舉了工作在proactive模式下短時間內(nèi)快速產(chǎn)生Packet-In的3種情況.

情況1. 動態(tài)主機(jī)配制協(xié)議(dynamic host configuration protocol, DHCP)導(dǎo)致Packet-In快速產(chǎn)生.由于IP地址數(shù)量有限，很多網(wǎng)絡(luò)(如清華大學(xué)校園網(wǎng))都采用DHCP的工作模式，即相同的IP在不同的時間點可能分配給不同的用戶.在SDN網(wǎng)絡(luò)中，新的用戶接入到網(wǎng)絡(luò)時，必須要通過Packet-In產(chǎn)生DHCP請求來獲取IP地址.在基于SDN的無線網(wǎng)絡(luò)中這種現(xiàn)象尤其嚴(yán)重，移動用戶從1個無線區(qū)域A移動到無線區(qū)域B，IP地址將會被重新分配，這時移動用戶將會再次產(chǎn)生Packet-In進(jìn)行DHCP請求.在網(wǎng)絡(luò)規(guī)模較大、用戶較多的情況下，DHCP有可能造成Packet-In的高速并發(fā).

情況2. 虛擬機(jī)批量遷移.由于主機(jī)資源不足等原因，經(jīng)常需要對虛擬機(jī)進(jìn)行遷移，從1臺主機(jī)遷移到另外1臺主機(jī).當(dāng)前的虛擬化工具都提供遷移組件(如VMware,Xen,KVM等)，這種情況在數(shù)據(jù)中心網(wǎng)絡(luò)中經(jīng)常出現(xiàn).在SDN網(wǎng)絡(luò)中，虛擬機(jī)的批量遷移需要密集地產(chǎn)生Packet-In來完成舊流表項的失效和新的流表項的建立過程.

情況3. SDN主要的功能就是實現(xiàn)網(wǎng)絡(luò)的靈活控制，SDN網(wǎng)絡(luò)中控制器上很多應(yīng)用都需要結(jié)合網(wǎng)絡(luò)實時信息(如鏈路利用率)來制定策略.如文獻(xiàn)[9]中的負(fù)載均衡(load balance)策略需要交換機(jī)不斷地將鏈路利用率等信息上傳到控制器.此時，無疑將產(chǎn)生實時的、持續(xù)的Packet-In分組到控制器.

1.2 SDN性能瓶頸分析

圖1展示了SDN交換機(jī)數(shù)據(jù)包處理流程.數(shù)據(jù)包從端口1進(jìn)入交換機(jī)，交換芯片將分組頭送入TCAM上的流表進(jìn)行查找，找到則根據(jù)相應(yīng)的action進(jìn)行操作.如果在TCAM中沒有相應(yīng)的匹配項，則交換芯片將數(shù)據(jù)包上傳到Local CPU，Local CPU將數(shù)據(jù)包封裝成Packet-In，通過交換機(jī)上的OpenFlow Agent上傳到控制器.控制器通過其處理邏輯下發(fā)Flow-Mod到交換機(jī)上的OpenFlow Agent，進(jìn)而傳到交換芯片將其插入到流表，指導(dǎo)后續(xù)數(shù)據(jù)包轉(zhuǎn)發(fā).

Fig. 1 Processing flow chart for arrival packets in SDN圖1 SDN交換機(jī)中數(shù)據(jù)包處理流程

從整體角度看，在SDN網(wǎng)絡(luò)中有很多因素可能導(dǎo)致數(shù)據(jù)包在1個交換機(jī)中處理時延較大.總結(jié)起來有如下5點：

1) 當(dāng)網(wǎng)絡(luò)拓?fù)湓谀?段時間變動較大且會產(chǎn)生很多DHCP請求，或者用戶定制的策略導(dǎo)致交換機(jī)需要不斷通過Packet-In將網(wǎng)絡(luò)實時信息上傳到控制器時，可能使交換機(jī)上Local CPU的計算能力或者Local CPU與交換芯片的帶寬成為瓶頸，造成時延較大.本文第3節(jié)的實驗結(jié)果表明，單個交換機(jī)上400個Packet-In以1 000 pps(packets per second)的速度產(chǎn)生時可引起高達(dá)1.4 s的時延.

2) TCAM上規(guī)則變化耗時較長導(dǎo)致時延增大.He等人[5]的工作表明，TCAM中的表項發(fā)生更新會對轉(zhuǎn)發(fā)時延產(chǎn)生較大的影響.當(dāng)規(guī)則優(yōu)先級按照一定規(guī)律變化時，時延變大的現(xiàn)象尤其明顯.造成這種現(xiàn)象的主要原因是TCAM中需要保留規(guī)則的重排列.本文第3節(jié)的測量結(jié)果顯示，當(dāng)TCAM的大小達(dá)到4 000個表項時，插入1條流表項在最壞情況下能引發(fā)高達(dá)9.52 s的時延.

3) 控制器與交換機(jī)之間SSL鏈接通信性能不理想造成時延.

4) 控制器上用戶App排隊時延較大，導(dǎo)致Flow-Mod生成時間較長，使得數(shù)據(jù)包等待時延過大.

5) 鏈路擁塞等因素造成時延較大.這些因素在IP網(wǎng)絡(luò)中也同樣存在，鑒于該因素不是SDN網(wǎng)絡(luò)特有的問題，本文的研究中暫不予考慮.

采用proactive模式解決了以上因素3和因素4這2種因素造成時延較大的問題.在proactive工作模式下，由于產(chǎn)生Packet-In的數(shù)目顯著減小，因素1所帶來的壓力減輕.但在一些特殊情況下，如特殊的策略要求、網(wǎng)絡(luò)拓?fù)渥兓^頻繁時，因素1仍然可能成為系統(tǒng)性能的制約因素.

受TCAM大小限制，不可能所有流表項都放在TCAM中，因此無論proactive還是reactive模式，TCAM中的流表項都會頻繁地?fù)Q入換出，因此因素2都將會成為時延較大潛在的原因[10].以清華大學(xué)校園網(wǎng)為例，共70 000端口、2 700無線熱點、10萬用戶終端.根據(jù)對清華網(wǎng)關(guān)截取的Trace進(jìn)行分析，以5元組標(biāo)識的并發(fā)流可以達(dá)到兆級別.在這種網(wǎng)絡(luò)規(guī)模下，即使采用proactive工作模式，商用TCAM仍然無法存儲所有流表項，流表項仍將會從TCAM中頻繁地?fù)Q入換出，造成很大的時延.

1.3 SDN中TCP面臨的問題

TCP提供面向連接的、可靠的網(wǎng)絡(luò)傳輸服務(wù).由于SDN的網(wǎng)絡(luò)特性，TCP在SDN網(wǎng)絡(luò)中面臨著其在IP網(wǎng)絡(luò)中不會出現(xiàn)的問題.SDN網(wǎng)絡(luò)的一些特點，使得數(shù)據(jù)包可能在鏈路輕負(fù)載的情況下使數(shù)據(jù)包產(chǎn)生較大的時延，導(dǎo)致TCP端節(jié)點誤認(rèn)為鏈路產(chǎn)生擁塞，從而對TCP性能產(chǎn)生較大的影響，本文稱之為偽擁塞現(xiàn)象.

SDN對TCP性能的影響主要包括2部分：TCP建立連接困難與TCP傳輸效率低下.

1) TCP建立連接困難

如圖2所示，TCP在通信前必須通過3次握手建立連接[11].客戶端發(fā)出SYN數(shù)據(jù)包的同時設(shè)定了1個計時器，當(dāng)計時器歸零時如果服務(wù)器端的SYN+ACK包沒有返回，客戶端將再次發(fā)送SYN數(shù)據(jù)包建立連接，同時計時器的設(shè)定值不斷變大.服務(wù)器端發(fā)送SYN+ACK后也會設(shè)定相應(yīng)的計時器，計時器超時后也會造成SYN+ACK數(shù)據(jù)包重傳.

Fig. 2 TCP working principles圖2 TCP工作原理圖

由于建立TCP連接的握手包較小，在傳統(tǒng)IP網(wǎng)絡(luò)中(特別是在輕負(fù)載情況下)一般不會造成握手包重傳.但是在SDN網(wǎng)絡(luò)中，即使網(wǎng)絡(luò)狀況很好，TCAM的更新以及Packet-In并發(fā)等原因也都可能造成小數(shù)據(jù)包產(chǎn)生很大時延，從而導(dǎo)致握手包被多次重傳.

本文第3節(jié)的測量結(jié)果表明，即使在同1個SDN網(wǎng)絡(luò)中最簡單的拓?fù)淝闆r下，僅由于流表項的重排列就有可能使得數(shù)據(jù)包往返時延(round-trip time, RTT)達(dá)到將近20 s，而短時間的Packet-In并發(fā)產(chǎn)生現(xiàn)象有可能會加大時延，因此在SDN網(wǎng)絡(luò)中很有可能TCP多次嘗試連接才能成功.

2) TCP傳輸效率低下

在商用的SDN交換機(jī)中，由于TCAM價格昂貴導(dǎo)致其規(guī)模無法做到很大(一般為幾千個).因此無論在proactive模式還是reactive模式下，流表中的表項都需要動態(tài)地?fù)Q入換出.網(wǎng)絡(luò)中產(chǎn)生Packet-In數(shù)目較大或者換入的流表項由于優(yōu)先級原因?qū)е屡f表項需要遷移時，則會造成TCP數(shù)據(jù)包的時延急劇增加，進(jìn)而造成復(fù)原時間目標(biāo)(recovery time objective, RTO)超時重傳.

TCP自身具有擁塞控制能力[12]，能夠根據(jù)數(shù)據(jù)包返回信息動態(tài)地調(diào)整發(fā)送窗口大小.但在SDN網(wǎng)絡(luò)中，即使鏈路狀況良好，也可能造成RTT時間較長，使終端誤判網(wǎng)絡(luò)擁塞，從而使得窗口減小，甚至有可能長時間維持在1，這樣就可能會極大地降低TCP的傳輸性能.

2 SDN時延影響因素分析及驗證

2.1 實驗參數(shù)

實驗采用了PICA8 3297交換機(jī)，TCAM擁有4 000個表項，在流表匹配時轉(zhuǎn)發(fā)時延平均為50 μs.控制器為floodlight，OpenFlow協(xié)議為v1.0，運(yùn)行在Ubuntu 12.04 LTS上.發(fā)包程序由libnet實現(xiàn)，抓包程序由libpcap實現(xiàn)，編寫語言為C.實驗拓?fù)淙鐖D3所示：

Fig. 3 Measurement topology for testing SDN packet delay圖3 測量SDN數(shù)據(jù)包時延的拓?fù)鋱D

如1.2節(jié)所述，通過采用proactive模式，將所有流表項存放到交換芯片的存儲上，使得以上因素3和因素4這2點問題不存在.2.2節(jié)和2.3節(jié)主要通過實驗驗證高速并發(fā)Packet-In以及流表項優(yōu)先級對時延的影響.

2.2 高速Packet-In對時延的影響

在SDN控制平面與轉(zhuǎn)發(fā)平面分離的情況下，為了展示網(wǎng)絡(luò)瓶頸所在，我們測量了新流(hit-miss)在各個環(huán)節(jié)的時延分布情況，實驗拓?fù)鋱D同樣如圖3所示.

初始流表為空，網(wǎng)卡A按照指定的速度發(fā)出新流到SDN交換機(jī)，由于在流表中沒有找到匹配項，交換機(jī)會產(chǎn)生相應(yīng)數(shù)目的Packet-In.控制器根據(jù)流表生成策略生成Flow-Mod，下發(fā)到交換機(jī)，TCAM裝載相應(yīng)流表項指導(dǎo)后續(xù)數(shù)據(jù)包到達(dá)網(wǎng)卡B.網(wǎng)卡B接收相應(yīng)的數(shù)據(jù)包計算時延.由于每個流只含有1個數(shù)據(jù)包，因此發(fā)送數(shù)據(jù)包的速度可被認(rèn)為是產(chǎn)生Packet-In的速度.

令Ts為網(wǎng)卡A捕獲數(shù)據(jù)包x的時間，Tr為網(wǎng)卡B捕獲數(shù)據(jù)包x的時間，總傳輸時延為Tt=Tr-Ts.設(shè)控制器上捕獲x對應(yīng)的Packet-In的時間為Tp，控制器網(wǎng)卡捕獲Flow-Mod的時間為Tf，則控制器上的處理時延為Tc=Tf-Tp.設(shè)定總的新流數(shù)目為400，隨著并發(fā)速度從10 pps增長到5 000 pps，各個環(huán)節(jié)的平均時延分布如表1所示.每個數(shù)據(jù)流的時延情況如圖4所示.

Table 1 Delay Distribution When Table Miss

Fig. 4 Packet delay in specific new flow generate rate圖4 一定速度下新流的時延

數(shù)據(jù)顯示，新流總數(shù)一定時，隨著新流的并發(fā)速度加快，數(shù)據(jù)包的平均時延不斷增大.在5 000 pps速度下，最大時延達(dá)1.624 s.隨著并發(fā)速度的提高，交換機(jī)上Packet-In會批量上傳到控制器，造成一些數(shù)據(jù)包總的時延變長.如表1中，當(dāng)速度達(dá)到5 000 pps時，Packet-In在控制器上的平均耗時為25.38 ms，這是因為有25個Packet-In在交換機(jī)上按組上傳到控制器，25.38 ms為控制器處理25個Packet-In的時間.控制器處理每個新流的平均時延基本沒變，均為1～2 ms.

通過對圖4進(jìn)行分析，發(fā)現(xiàn)新流產(chǎn)生速度較快時，如1 000 pps，5 000 pps，數(shù)據(jù)包時延呈現(xiàn)階梯式增長;當(dāng)速度較慢時，數(shù)據(jù)包時延抖動很劇烈，如在速度為10 pps，100 pps的情況下.后續(xù)的所有時延相關(guān)的實驗都展示了這種特點.

這一現(xiàn)象很可能是由于交換機(jī)處理Packet-In的策略造成的：Packet-In達(dá)到一定數(shù)目時，再上傳到控制器；如果超過一定長度的等待時間，即使沒有達(dá)到相應(yīng)的數(shù)目，也要上傳到控制器.這樣，發(fā)送較慢時，Packet-In產(chǎn)生速度未觸及瓶頸，但抖動很大，數(shù)據(jù)包時延呈周期性變化;當(dāng)發(fā)送較快時，超出Packet-In產(chǎn)生瓶頸，排隊時間越來越長，時延呈階梯狀增長.

當(dāng)并發(fā)速度加快時，總體時延Tt顯著變大，但是控制器處理每個新流的平均時延幾乎沒變.說明當(dāng)Packet-In較小且并發(fā)速度在一定范圍內(nèi)時，SDN瓶頸是在交換機(jī)而不是在控制器.為了驗證這種觀點，我們用CBench工具[13]對控制器進(jìn)行了測試.為了避免控制器與交換機(jī)之間通信性能的干擾，在floodlight所在主機(jī)上配置了CBench.測試模擬了16臺交換機(jī)，每臺交換機(jī)虛擬連接了1 000臺主機(jī)，進(jìn)行10次循環(huán)測試，每次循環(huán)測試持續(xù)10 s，時延測試在吞吐量模式下進(jìn)行.實驗結(jié)果顯示，10組測試結(jié)果中最小吞吐量為360 817.77次s，最大吞吐量為403 931.03次s，平均也有390 514.08次s，這說明在本文實驗范圍內(nèi)的Packet-In速度下，controller生成和下發(fā)規(guī)則的能力不會成為系統(tǒng)瓶頸.

2.3 流表項優(yōu)先級變化對時延的影響

為了測量TCAM中流表項優(yōu)先級在更新時對數(shù)據(jù)包時延的影響，基于拓?fù)鋱D3進(jìn)行了流表項優(yōu)先級相關(guān)的實驗.設(shè)初始情況下TCAM流表為空，共4 000個新流，每個新流包含1個數(shù)據(jù)包.數(shù)據(jù)包以10 pps的速率按照優(yōu)先級依次遞增、遞減、不變3種模式發(fā)出，最終得出實驗結(jié)果如圖5所示.

Fig. 5 Packet delay in three kinds of flow entries priority change mode when rate=10 pps圖5 rate=10 pps時3種流表項優(yōu)先級變化的時延

實驗結(jié)果表明，當(dāng)插入的流表項優(yōu)先級不變或者優(yōu)先級遞減時，處理時延幾乎不變.但是在插入優(yōu)先級遞增時，隨著插入流表項數(shù)量的增加處理時延顯著變大，最大可達(dá)到9.648 s.

調(diào)研結(jié)果顯示，不同的交換機(jī)TCAM中流表項的組織方式不同[5].PICA8的白盒交換機(jī)采用Boradcom公司的交換芯片.該交換芯片在TCAM中按優(yōu)先級從高到低組織流表項.當(dāng)流表項優(yōu)先級隨著插入順序遞增時，每1個插入的流表項優(yōu)先級都要比TCAM中已有的流表項優(yōu)先級高.當(dāng)TCAM中流表項達(dá)到一定規(guī)模后，新插入的流表項會導(dǎo)致大量已有表項的移動，從而造成較大延時.

為了更直觀地展示實驗結(jié)果，我們進(jìn)行了更進(jìn)一步的實驗.設(shè)定TCAM流表中已有指定數(shù)目的流表項，然后分別按照不變、降序、升序的優(yōu)先級順序發(fā)送100個新流，發(fā)送速度為10 pps，統(tǒng)計相應(yīng)的時延情況，分別如圖6～8所示.

rate=10 pps,num=100Fig. 6 Packet delay with the same priority圖6 優(yōu)先級不變、不同表規(guī)模的數(shù)據(jù)包時延

圖6～8中的數(shù)據(jù)顯示，隨著基礎(chǔ)表項不斷增加，優(yōu)先級遞增的實驗組延遲明顯增加.相比而言優(yōu)先級不變或者減小的實驗組則變化很小，實驗結(jié)果驗證了上述觀點.

交換機(jī)時延與優(yōu)先級的特性很大程度上依賴于交換芯片對TCAM中流表的組織形式.如果交換芯片按照低優(yōu)先級在前，那么實驗結(jié)果將完全相反.同時值得注意的是，即使在proactive模式下，也必將伴隨著頻繁的換入換出，也會因為優(yōu)先級的原因造成相應(yīng)的時延.已有算法會對流表的數(shù)據(jù)結(jié)構(gòu)進(jìn)行改造[4,14],可以降低流表中表項的移動次數(shù)，但是這是以降低存儲的利用率和增加算法的復(fù)雜度為代價的，同時也不能完全避免流表中表項的移動.因此，本文提到的問題依舊存在.

rate=10 pps,num=100Fig. 7 Packet delay when the priority decreases圖7 優(yōu)先級遞減、不同表規(guī)模的數(shù)據(jù)包時延

rate=10 pps,num=100Fig. 8 Packet delay when the priority increases圖8 優(yōu)先級遞增、不同表規(guī)模的數(shù)據(jù)包時延

3 對TCP的針對性測量分析

如1.3節(jié)所述，SDN工作模式可能為TCP帶來2類問題，分別為建立連接困難與傳輸?shù)托?

在建立連接時，客戶端在第i(i=1,2,3…)個SYN數(shù)據(jù)包發(fā)出后，如果在Di時間內(nèi)還未收到SYN+ACK，將會再次發(fā)送SYN數(shù)據(jù)包.在伯克利系統(tǒng)中D1即首次重發(fā)時間為5.8 s，D2=24 s，最大值為75 s[15].

在連接建立后，TCP進(jìn)行數(shù)據(jù)傳輸.發(fā)送端第j次發(fā)送的數(shù)據(jù)包在Ej(j=1,2,…)時間內(nèi)還未收到接收方反饋，發(fā)送端將會判斷鏈路出現(xiàn)擁塞，發(fā)送窗口將以“線性加、乘性減”為原則劇烈減小，從而影響發(fā)送性能.實際上，此時很有可能不是真正發(fā)生擁塞，只是上述SDN網(wǎng)絡(luò)特性導(dǎo)致時延很大，造成偽擁塞.伯克利系統(tǒng)實現(xiàn)版本之一E1=1.5 s，E2=3 s，依次倍增，最大值為64 s[15].

3.1 對TCP建立情況的分析

為了準(zhǔn)確描述TCP建立連接在SDN網(wǎng)絡(luò)中所面對的問題，我們按照拓?fù)鋱D3進(jìn)行了握手過程中往返時延的測量.在rule優(yōu)先級遞增的情況下，網(wǎng)卡A向網(wǎng)卡B按照指定的速度發(fā)送250個SYN，網(wǎng)卡B收到后立刻對網(wǎng)卡A返回1個相應(yīng)的SYN+ACK，忽略主機(jī)協(xié)議棧耗時統(tǒng)計往返時延.

從圖9，10，11可知，在流表項優(yōu)先級隨插入順序遞增時，TCAM中原有流表項數(shù)目達(dá)到一定規(guī)模后，相同的并發(fā)速度下往返時延呈階梯式增長.同時，由圖12～15可見，隨著速度增加，時延在不斷地變大.根據(jù)第2節(jié)的實驗結(jié)果分析，在上述負(fù)載情況下，控制器上時延很小，絕大多數(shù)時延消耗在交換機(jī)上.

Fig. 9 RTT when TCAM load=500 and rules priority increases圖9 TCAM load=500優(yōu)先級遞增時的往返時延

Fig. 10 RTT when TCAM load=2 000 and rules priority increases圖10 TCAM load=2 000優(yōu)先級遞增時的往返時延

Fig. 11 RTT when TCAM load=3 500 and rules priority increases圖11 TCAM load=3 500優(yōu)先級遞增時的往返時延

Fig. 12 RTT when Packet-In rate=10 pps圖12 Packet-In rate=10 pps不同流表規(guī)模往返時延

Fig. 13 RTT when Packet-In rate=100 pps圖13 Packet-In rate=100 pps不同流表規(guī)模往返時延

Fig. 14 RTT when Packet-In rate=1 000 pps圖14 Packet-In rate=1 000 pps時不同流表規(guī)模往返時延

Fig.15 RTT when Packet-In rate=5 000 pps圖15 Packet-In rate=5 000 pps時不同流表規(guī)模往返時延

Fig. 16 RTT distribution figure when TCAM load=500圖16 TCAM load=500時不同速度下往返時延分布圖

Fig. 17 RTT distribution figure when TCAM load=2 000圖17 TCAM load=2 000時不同速度下往返時延分布圖

Fig. 18 RTT distribution figure when TCAM load=3 500圖18 TCAM load=3 500時不同速度下往返時延分布圖

按照伯克利系統(tǒng)實現(xiàn)參數(shù)進(jìn)行分析，首先在優(yōu)先級遞增情況下，不同并發(fā)速度對應(yīng)的往返時延分布直方圖分別如圖16～18所示.當(dāng)并發(fā)速度為10 pps，TCAM中已有流表項為500和2 000個流表項的情況下，所有數(shù)據(jù)包的往返時延都在5.8 s內(nèi)，即所有的TCP握手?jǐn)?shù)據(jù)包都能在初始RTO(5.8 s)內(nèi)返回而不必重傳.當(dāng)并發(fā)速度為10 pps、初始流表項為3 500個時，單次數(shù)據(jù)包的往返時延有10%超出了5.8 s，即需要再次發(fā)送握手包.在10 pps的Packet-In速度下，隨著基礎(chǔ)流表裝載規(guī)模變大，圖16～18這3幅直方圖相比分布重心不斷右移，說明往返時延不斷增大，成功建立連接發(fā)送握手包的期望次數(shù)不斷變大.同時，在一定基礎(chǔ)流表裝載規(guī)模下，同一張分布直方圖的重心也在右移，說明在基礎(chǔ)流表裝載規(guī)模一定時，隨著Packet-In速度加快，成功建立連接需要發(fā)送的SYN數(shù)據(jù)包的期望數(shù)目不斷增大.以基礎(chǔ)流表裝載規(guī)模為3 500個表項為例，當(dāng)建立連接速度為10 pps時，處于0～5.8 s,5.8～24 s，24～75 s，75～I(xiàn)nf的數(shù)據(jù)包占比分別占比90%，10%，0%，0%，隨著Packet-In產(chǎn)生速度加快，0～5.8 s即不需重傳的數(shù)據(jù)包占比不斷減小，同時需要重傳的數(shù)據(jù)包占比不斷增大.當(dāng)Packet-In速度達(dá)到5 000 pps時，這一比例已經(jīng)分別達(dá)到20.4%，0%，60%，19.6%.即不需重傳的握手包只占20.4%，且有19.6%的數(shù)據(jù)包超過了75 s，最高達(dá)105.51 s，存在無法完成TCP連接建立的可能性.

值得注意的是，TCP連接需要經(jīng)過3次握手才能建立，所以在建立過程中很有可能發(fā)生多次重傳，造成建立連接困難.

3.2 對TCP傳輸性能的分析

TCP連接建立后TCAM中存在對應(yīng)的流表項.在規(guī)模稍大的網(wǎng)絡(luò)中，并發(fā)流的數(shù)目可以達(dá)到幾兆甚至幾十兆(如清華校園網(wǎng)2011年并發(fā)流就達(dá)到兆級別)，TCAM中的流表項會被頻繁地?fù)Q入換出.換入的過程中由于優(yōu)先級造成的表項移動或者其他新流的產(chǎn)生，都會使TCP傳輸數(shù)據(jù)產(chǎn)生較大時延，超出RTO后可能導(dǎo)致TCP發(fā)送窗口減小，甚至有可能退化成停等協(xié)議，從而影響TCP的性能.

我們按照拓?fù)鋱D3進(jìn)行了數(shù)據(jù)發(fā)送過程中往返時延的模擬測量.在規(guī)則(rule)優(yōu)先級遞增的情況下，網(wǎng)卡A向網(wǎng)卡B按照指定的速度發(fā)送250不同的流，每個流包含1個數(shù)據(jù)包，網(wǎng)卡B收到后立刻給網(wǎng)卡A返回1個相應(yīng)的ACK，忽略主機(jī)協(xié)議棧耗時統(tǒng)計總的往返時延.初始流表里的流表項都不能匹配這些流，需要在交換芯片的片上存儲中進(jìn)行查找，換入TCAM.統(tǒng)計TCP發(fā)送實驗中從數(shù)據(jù)包發(fā)出到ACK返回時間間隔如圖19所示：

Fig. 19 RTT distribution diagram圖19 往返時延分布圖

通過對圖19的數(shù)據(jù)進(jìn)行分析，在初始流表裝載3 500個流表項時，在10 pps的發(fā)送速度下有73.2%的可能性會產(chǎn)生重傳或者多次重傳；在2 500個流表裝載、5 000 pps發(fā)送速度的情況下，有些數(shù)據(jù)包甚至超出了最長等待時間75 s.重傳造成窗口不斷減小，使得TCP一直處于低效的工作狀態(tài).

在3.1節(jié)和3.2節(jié)的實驗中，我們在1個SDN網(wǎng)絡(luò)中最簡單的拓?fù)淝闆r下進(jìn)行了實驗，發(fā)現(xiàn)TCP面對各種問題.在實際網(wǎng)絡(luò)中，TCP連接可能要在多個SDN自治域之間建立，經(jīng)歷多個交換機(jī)和控制器，因此TCP所面臨的問題將會更加嚴(yán)重.

4 總 結(jié)

實驗結(jié)果表明：SDN網(wǎng)絡(luò)中TCP產(chǎn)生偽擁塞主要由交換機(jī)造成.無論主動模式還是被動模式，SDN網(wǎng)絡(luò)由于Packet-In短時間內(nèi)高速并發(fā)、優(yōu)先級不同導(dǎo)致流表項大規(guī)模移動等原因，都會導(dǎo)致基于TCP的鏈接產(chǎn)生偽擁塞現(xiàn)象，造成性能下降.

SDN網(wǎng)絡(luò)中數(shù)據(jù)包時延較大的原因，一方面是由于SDN交換機(jī)的處理速度跟不上Packet-In的產(chǎn)生速度，主要瓶頸體現(xiàn)在交換機(jī)的Local CPU性能較低以及CPU與交換芯片之間的帶寬限制[5]，因此需要不斷提高CPU性能和傳輸帶寬，同時盡量減少二者之間的通信，如將頻繁訪問的流表放在交換芯片的片內(nèi)存儲中而不是放在Local CPU管理的內(nèi)存中；另一方面原因是由交換芯片對TCAM的流表項組織方式造成的.探究如何組織TCAM上的表項，使其最大限度地降低流表項優(yōu)先級特征造成的時延也成為我們下一步工作的重點.

最后，可以從TCP協(xié)議本身入手.實驗結(jié)果顯示，當(dāng)前的TCP在SDN中很容易產(chǎn)生RTO超時，“線性加、乘性減”的窗口變化原則在SDN中是否依舊適用？如何更好地設(shè)計適用于SDN-TCP的RTO？如何設(shè)計適用于SDN網(wǎng)絡(luò)的TCP窗口變化模式？也是未來我們研究的工作重點.

[1]Big Switch. Modern OpenFlow and SDN[EBOL]. [2015-12-15]. http:www.bigswitch.comblog20140502modern-openflow-and-sdn-part-i

[2]Pica8. PicOS OpenFlow[EBOL]. [2015-12-15]. http:www.pica8.comwp-contentuploads201509openflow-tutorials-1.pdf

[3]McKeown N, Anderson T, Balakrishnan H, et al. OpenFlow: Enabling innovation in campus networks[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(2): 69-74

[4]Yan Bo, Xu Yang, Xing Hongya, et al. CAB: A reactive wildcard rule caching system for software-defined networks[C]Proc of the 3rd Workshop on Hot Topics in Software Defined Networking. New York: ACM, 2014: 163-168

[5]He Keqiang, Khalid J, Gember-Jacobson A, et al. Measuring control plane latency in SDN-enabled switches[C]Proc of the 1st ACM SIGCOMM Symp on Software Defined Networking Research. New York: ACM, 2015: 25-30

[6]Jiang Guolong, Fu Binzhang, Chen Mingyu, et al. Survey and quantitative analysis of SDN controllers[J]. Journal of Frontiers of Computer Science and Technology, 2014, 8(6): 653-664 (in Chinese)(江國龍, 付斌章, 陳明宇, 等. SDN控制器的調(diào)研和量化分析[J]. 計算機(jī)科學(xué)與探索, 2014, 8(6): 653-664)

[7]Luo Wanming, Lin Chuang, Yan Baoping. A survey of congestion control in the Internet[J]. Chinese Journal of Computers, 2001, 24(1): 1-18 (in Chinese)(羅萬明, 林闖, 閻保平. TCPIP 擁塞控制研究[J]. 計算機(jī)學(xué)報, 2001, 24(1): 1-18)

[8]Jiang Wengang, Sun Jinsheng, Wang Zhiquan. A random back-off TCP congestion control algorithm[J]. Acta Electronica Sinica, 2011, 20(7): 1689-1692 (in Chinese)(姜文剛, 孫金生, 王執(zhí)銓. 隨機(jī)回退的 TCP 擁塞控制算法[J]. 電子學(xué)報, 2011, 20(7): 1689-1692)

[9]Namal S, Ahmad I, Gurtov A, et al. SDN based inter-technology load balancing leveraged by flow admission control[C]Proc of the 8th Future Networks and Services. Piscataway, NJ: IEEE, 2013: 1-5

[10]Miao Rui, Zafar A Q, Cheng-Chun Tu, et al. SIMPLE-fying middlebox policy enforcement using SDN[J]. ACM SIGCOMM Computer Communication Review, 2013, 43(4): 27-38

[11]Padhye J, Firoiu V, Towsley D F, et al. Modeling TCP Reno performance: A simple model and its empirical validation[J]. IEEEACM Trans on Networking, 2000, 8(2): 133-145

[12]Jacobson V. Congestion avoidance and control[J]. Communication Review, 1988, 32(4): 314-329

[13]Sherwood R, Kok-Kiong Y A P. CBench: An open-flow controller benchmarker[JOL]. 2010 [2013-05-13]. http:www.openflow.orgwkIndex.phpOflops

[14]Zhang Bin, Yang Jiahai, Wu Jianping, et al. Efficient searching with parallel TCAM chips[C]Proc of the 35th Local Computer Networks (LCN). Piscataway, NJ: IEEE, 2010: 228-321

[15]Wright G R, Stevens W R. TCPIP Illustrated[M]. Upper Saddle River, NJ: Addison-Wesley Professional, 1995

Tai Dongzhe, born in 1990. Received his BSc degree in computer science and technology from Tsinghua University, Beijing, China in 2013. MSc from Tsinghua University, Beijing, China. His main research interests include SDN and NDN.

Zhang Ting, born in 1990. PhD candidate at the Department of Computer Science and Technology, Tsinghua University. His main research interests include high performance switchesrouters and software-defined networking (zhangting825@gmail.com).

Liu Bin, born in 1964. Received his MSc and PhD degree in computer science and engineering from Northwestern Polytechnical University, Xi’an, China in 1988 and 1993, respectively. Currently professor and PhD supervisor of Tsinghua University, Beijing, China. Member of CCF. His main research interests include high-performance switchesrouters, network processors, named data networking and software-defined networking.

The Pseudo Congestion of TCP in Software-Defined Networking

Tai Dongzhe, Zhang Ting, and Liu Bin

(DepartmentofComputerScienceandTechnology,TsinghuaUniversity,Beijing100084)

software-defined networking (SDN) separates the control plane and the data plane, and this kind of separation can achieve flexible control via deploying fine-grained rules on the flow tables in switches, while potentially improving the utilization of network bandwidth. With the development of SDN, more and more campus and enterprise network begin to deploy network based on SDN. During this procedure, SDN has encountered some problems which don’t exist in the traditional IP network. For example, some protocols used in the existing IP network are subject to great challenge in SDN based network, such as TCP, which is the most basic protocol in TCPIP network. First, we make a penetrating analysis on the working mechanism of SDN, and three examples are given to illustrate that it is quite possible to generate large volume of Packet-In messages even in proactive mode. Then experiments are carried out and the results show that the end-to-end TCP connections have experienced a large delay caused by the SDN unique operations such as re-organizing of rules in TCAM and fast Packet-In message generating. In the worst case, the delay caused by the reordering of the rules can reach up to 10 seconds when the TCAM contains 4 000 flow entries in our experiments. Based on the experimental results, we highlight two major problems when applying traditional TCP protocol in SDN networks: one is that it is hard to establish the connection, and the other is the transmission inefficiency. Through the analysis of the experimental results, we propose the possible direction to solve TCP inefficiency issue in SDN.

software-defined networking (SDN); transmission control protocol (TCP); delay; proactive mode; congestion

2015-12-21；

2016-03-22

國家自然科學(xué)基金重點項目(61432009) This work was supported by the Key Program of the National Natural Science Foundation of China (61432009).

劉斌(liub@mail.tsinghua.edu.cn)

TP393