邰冬哲 張 庭 劉 斌

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

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

邰冬哲 張 庭 劉 斌

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

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

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

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

為了實(shí)現(xiàn)網(wǎng)絡(luò)的靈活管理、提高網(wǎng)絡(luò)性能、降低管理成本，軟件定義網(wǎng)絡(luò)(software-defined networking, SDN)被提出并得到了廣泛的研究.SDN將交換機(jī)控制平面(control plane)與數(shù)據(jù)平面(data plane)分離，利用控制器通過(guò)南向接口向數(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個(gè)或多個(gè)字段(field)，并伴有對(duì)匹配到的數(shù)據(jù)包進(jìn)行操作的動(dòng)作(action).

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

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

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

1 動(dòng)機(jī)與問(wèn)題描述

1.1 SDN的工作模式

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

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

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

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

情況1. 動(dòng)態(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在不同的時(shí)間點(diǎn)可能分配給不同的用戶(hù).在SDN網(wǎng)絡(luò)中，新的用戶(hù)接入到網(wǎng)絡(luò)時(shí)，必須要通過(guò)Packet-In產(chǎn)生DHCP請(qǐng)求來(lái)獲取IP地址.在基于SDN的無(wú)線網(wǎng)絡(luò)中這種現(xiàn)象尤其嚴(yán)重，移動(dòng)用戶(hù)從1個(gè)無(wú)線區(qū)域A移動(dòng)到無(wú)線區(qū)域B，IP地址將會(huì)被重新分配，這時(shí)移動(dòng)用戶(hù)將會(huì)再次產(chǎn)生Packet-In進(jìn)行DHCP請(qǐng)求.在網(wǎng)絡(luò)規(guī)模較大、用戶(hù)較多的情況下，DHCP有可能造成Packet-In的高速并發(fā).

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

情況3. SDN主要的功能就是實(shí)現(xiàn)網(wǎng)絡(luò)的靈活控制，SDN網(wǎng)絡(luò)中控制器上很多應(yīng)用都需要結(jié)合網(wǎng)絡(luò)實(shí)時(shí)信息(如鏈路利用率)來(lái)制定策略.如文獻(xiàn)[9]中的負(fù)載均衡(load balance)策略需要交換機(jī)不斷地將鏈路利用率等信息上傳到控制器.此時(shí)，無(wú)疑將產(chǎn)生實(shí)時(shí)的、持續(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中沒(méi)有相應(yīng)的匹配項(xiàng)，則交換芯片將數(shù)據(jù)包上傳到Local CPU，Local CPU將數(shù)據(jù)包封裝成Packet-In，通過(guò)交換機(jī)上的OpenFlow Agent上傳到控制器.控制器通過(guò)其處理邏輯下發(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個(gè)交換機(jī)中處理時(shí)延較大.總結(jié)起來(lái)有如下5點(diǎn)：

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

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

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

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

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

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

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

1.3 SDN中TCP面臨的問(wèn)題

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

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

1) TCP建立連接困難

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

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

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

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

2) TCP傳輸效率低下

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

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

2 SDN時(shí)延影響因素分析及驗(yàn)證

2.1 實(shí)驗(yàn)參數(shù)

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

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

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

2.2 高速Packet-In對(duì)時(shí)延的影響

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

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

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

Table 1 Delay Distribution When Table Miss

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

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

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

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

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

2.3 流表項(xiàng)優(yōu)先級(jí)變化對(duì)時(shí)延的影響

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

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

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

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

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

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

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

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

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

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

3 對(duì)TCP的針對(duì)性測(cè)量分析

如1.3節(jié)所述，SDN工作模式可能為T(mén)CP帶來(lái)2類(lèi)問(wèn)題，分別為建立連接困難與傳輸?shù)托?

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

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

3.1 對(duì)TCP建立情況的分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 對(duì)TCP傳輸性能的分析

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

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

Fig. 19 RTT distribution diagram圖19 往返時(shí)延分布圖

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

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

4 總 結(jié)

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

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

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

[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)(江國(guó)龍, 付斌章, 陳明宇, 等. SDN控制器的調(diào)研和量化分析[J]. 計(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)(羅萬(wàn)明, 林闖, 閻保平. TCPIP 擁塞控制研究[J]. 計(jì)算機(jī)學(xué)報(bào), 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é)報(bào), 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

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

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

TP393