软件定义网络中TCP伪拥塞问题探究

邰冬哲 张 庭 刘 斌

(清华大学计算机科学与技术系 北京 100084)(tdz13@mails.tsinghua.edu.cn)

软件定义网络中TCP伪拥塞问题探究

邰冬哲 张 庭 刘 斌

(清华大学计算机科学与技术系 北京 100084)(tdz13@mails.tsinghua.edu.cn)

软件定义网络(software-defined networking, SDN)将控制平面与转发平面分离，通过控制器配置交换机流表项来实现网络的灵活控制，极大地提高了网络带宽利用率.随着SDN的蓬勃发展，越来越多的高校和公司开始部署SDN.同时SDN也面临着一些传统IP网络中不存在的问题，如一些原本在IP网络中运行良好的协议在SDN网络中性能却受到了严重的影响，TCP协议就是其中之一.从SDN的工作机制出发，通过3个场景阐明了SDN在proactive工作模式下依然存在Packet-In短时间内高速并发的可能性.总结并实验验证了高速并发的Packet-In以及流表更新时旧表项需重排列的特性都会使数据包在SDN网络中产生较大时延.实验结果表明，当TCAM支持4 000个流表项时，最坏情况下仅由新插入流表项优先级原因导致已有流表项的重排列就能使单次传输时延达到10 s，并发的高速Packet-In则会使时延加大.以实验为基础，揭示了由于SDN网络特性造成的伪拥塞现象，即传统TCP在SDN网络中面临两大问题：1)TCP建立连接困难；2)TCP协议传输低效.最后通过对实验现象进行分析，提出了解决SDN网络中TCP低效问题可能的工作方向.

软件定义网络；传输控制协议；时延；主动模式；拥塞

① TCAM(ternary content addressable memory)是一种3态内容存储器，支持wildcard查找，可以在1个时钟周期内给出查找结果.

为了实现网络的灵活管理、提高网络性能、降低管理成本，软件定义网络(software-defined networking, SDN)被提出并得到了广泛的研究.SDN将交换机控制平面(control plane)与数据平面(data plane)分离，利用控制器通过南向接口向数据平面上的流表下载规则(rule)，从而指导数据包转发.由于TCAM①查找速度快且支持wildcard，因此当前大量商用硬件SDN交换机都采用TCAM存放流表[1-2].目前应用最广泛的南向接口是OpenFlow[3].1条规则可以包含1个或多个字段(field)，并伴有对匹配到的数据包进行操作的动作(action).

由于SDN控制器具有集中控制并掌握全局信息的特性，一些在传统IP网络中难以处理的问题在SDN中得到了很好的解决[4].由于流表缺失时SDN交换机需要与控制器通信才能指导数据包的转发，可能造成较大时延，因此研究人员围绕SDN交换机和控制器开展了很多的测量工作[5-6].通过将SDN的工作模式设定成主动模式，控制器和交换机很多性能问题得以解决.

TCP提供面向连接的传输服务，需要经过3次握手才能建立连接.传统的TCP已经能够稳定地运行在IP网络中，面临的拥塞问题也得到了充分的研究[7-8].但是在SDN网络中，SDN的网络特性是否会影响TCP的性能，目前并没有工作能很好地说明.

本文提出并实验验证了SDN网络中TCP可能存在的伪拥塞现象，并对伪拥塞现象产生的原因进行了深入的分析.伪拥塞现象使得TCP在建立连接时出现问题，同时在TCP连接建立之后可能使传输效率降低.在本文第4节，我们提出了解决该问题的可能方法.

1 动机与问题描述

1.1 SDN的工作模式

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

1) reactive工作模式.所谓被动模式，是指任何在交换机流表中找不到匹配项的数据包，都以Packet-In的形式发送给控制器，由控制器根据策略生成流表项后，通过Flow-Mod下发到交换机.在reactive模式下，SDN的网络管理将会更加灵活.但是交换机的性能很容易受到控制器的处理速度、交换芯片与Local CPU之间的带宽等因素的影响[5].因此在当前网络基础设施下，工业界普遍偏向于proactive的工作模式[1].

2) proactive工作模式.控制器将所有流表项计算出，并提前下发到交换机流表中(尽管该交换机可能还未转发过该流表项对应的数据包).受TCAM大小所限，如果当前已知的流表项全部提前下发到交换机，需要存放在交换芯片的片上存储.由于以上原因，TCAM一般充当高速缓存(cache).数据包到达后，先在TCAM中查找，如果没有匹配则从片上存储中进行查找转发.相比于reactive模式，proac-tive模式能在一定程度上解决controller与switch之间通信时延较大的问题.

但是我们观察到即使SDN网络工作在proactive模式下，也无法完全避免交换机产生Packet-In.为验证这一结论，以下列举了工作在proactive模式下短时间内快速产生Packet-In的3种情况.

情况1. 动态主机配制协议(dynamic host configuration protocol, DHCP)导致Packet-In快速产生.由于IP地址数量有限，很多网络(如清华大学校园网)都采用DHCP的工作模式，即相同的IP在不同的时间点可能分配给不同的用户.在SDN网络中，新的用户接入到网络时，必须要通过Packet-In产生DHCP请求来获取IP地址.在基于SDN的无线网络中这种现象尤其严重，移动用户从1个无线区域A移动到无线区域B，IP地址将会被重新分配，这时移动用户将会再次产生Packet-In进行DHCP请求.在网络规模较大、用户较多的情况下，DHCP有可能造成Packet-In的高速并发.

情况2. 虚拟机批量迁移.由于主机资源不足等原因，经常需要对虚拟机进行迁移，从1台主机迁移到另外1台主机.当前的虚拟化工具都提供迁移组件(如VMware,Xen,KVM等)，这种情况在数据中心网络中经常出现.在SDN网络中，虚拟机的批量迁移需要密集地产生Packet-In来完成旧流表项的失效和新的流表项的建立过程.

情况3. SDN主要的功能就是实现网络的灵活控制，SDN网络中控制器上很多应用都需要结合网络实时信息(如链路利用率)来制定策略.如文献[9]中的负载均衡(load balance)策略需要交换机不断地将链路利用率等信息上传到控制器.此时，无疑将产生实时的、持续的Packet-In分组到控制器.

1.2 SDN性能瓶颈分析

图1展示了SDN交换机数据包处理流程.数据包从端口1进入交换机，交换芯片将分组头送入TCAM上的流表进行查找，找到则根据相应的action进行操作.如果在TCAM中没有相应的匹配项，则交换芯片将数据包上传到Local CPU，Local CPU将数据包封装成Packet-In，通过交换机上的OpenFlow Agent上传到控制器.控制器通过其处理逻辑下发Flow-Mod到交换机上的OpenFlow Agent，进而传到交换芯片将其插入到流表，指导后续数据包转发.

Fig. 1 Processing flow chart for arrival packets in SDN图1 SDN交换机中数据包处理流程

从整体角度看，在SDN网络中有很多因素可能导致数据包在1个交换机中处理时延较大.总结起来有如下5点：

1) 当网络拓扑在某1段时间变动较大且会产生很多DHCP请求，或者用户定制的策略导致交换机需要不断通过Packet-In将网络实时信息上传到控制器时，可能使交换机上Local CPU的计算能力或者Local CPU与交换芯片的带宽成为瓶颈，造成时延较大.本文第3节的实验结果表明，单个交换机上400个Packet-In以1 000 pps(packets per second)的速度产生时可引起高达1.4 s的时延.

2) TCAM上规则变化耗时较长导致时延增大.He等人[5]的工作表明，TCAM中的表项发生更新会对转发时延产生较大的影响.当规则优先级按照一定规律变化时，时延变大的现象尤其明显.造成这种现象的主要原因是TCAM中需要保留规则的重排列.本文第3节的测量结果显示，当TCAM的大小达到4 000个表项时，插入1条流表项在最坏情况下能引发高达9.52 s的时延.

3) 控制器与交换机之间SSL链接通信性能不理想造成时延.

4) 控制器上用户App排队时延较大，导致Flow-Mod生成时间较长，使得数据包等待时延过大.

5) 链路拥塞等因素造成时延较大.这些因素在IP网络中也同样存在，鉴于该因素不是SDN网络特有的问题，本文的研究中暂不予考虑.

采用proactive模式解决了以上因素3和因素4这2种因素造成时延较大的问题.在proactive工作模式下，由于产生Packet-In的数目显著减小，因素1所带来的压力减轻.但在一些特殊情况下，如特殊的策略要求、网络拓扑变化较频繁时，因素1仍然可能成为系统性能的制约因素.

受TCAM大小限制，不可能所有流表项都放在TCAM中，因此无论proactive还是reactive模式，TCAM中的流表项都会频繁地换入换出，因此因素2都将会成为时延较大潜在的原因[10].以清华大学校园网为例，共70 000端口、2 700无线热点、10万用户终端.根据对清华网关截取的Trace进行分析，以5元组标识的并发流可以达到兆级别.在这种网络规模下，即使采用proactive工作模式，商用TCAM仍然无法存储所有流表项，流表项仍将会从TCAM中频繁地换入换出，造成很大的时延.

1.3 SDN中TCP面临的问题

TCP提供面向连接的、可靠的网络传输服务.由于SDN的网络特性，TCP在SDN网络中面临着其在IP网络中不会出现的问题.SDN网络的一些特点，使得数据包可能在链路轻负载的情况下使数据包产生较大的时延，导致TCP端节点误认为链路产生拥塞，从而对TCP性能产生较大的影响，本文称之为伪拥塞现象.

SDN对TCP性能的影响主要包括2部分：TCP建立连接困难与TCP传输效率低下.

1) TCP建立连接困难

如图2所示，TCP在通信前必须通过3次握手建立连接[11].客户端发出SYN数据包的同时设定了1个计时器，当计时器归零时如果服务器端的SYN+ACK包没有返回，客户端将再次发送SYN数据包建立连接，同时计时器的设定值不断变大.服务器端发送SYN+ACK后也会设定相应的计时器，计时器超时后也会造成SYN+ACK数据包重传.

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

由于建立TCP连接的握手包较小，在传统IP网络中(特别是在轻负载情况下)一般不会造成握手包重传.但是在SDN网络中，即使网络状况很好，TCAM的更新以及Packet-In并发等原因也都可能造成小数据包产生很大时延，从而导致握手包被多次重传.

本文第3节的测量结果表明，即使在同1个SDN网络中最简单的拓扑情况下，仅由于流表项的重排列就有可能使得数据包往返时延(round-trip time, RTT)达到将近20 s，而短时间的Packet-In并发产生现象有可能会加大时延，因此在SDN网络中很有可能TCP多次尝试连接才能成功.

2) TCP传输效率低下

在商用的SDN交换机中，由于TCAM价格昂贵导致其规模无法做到很大(一般为几千个).因此无论在proactive模式还是reactive模式下，流表中的表项都需要动态地换入换出.网络中产生Packet-In数目较大或者换入的流表项由于优先级原因导致旧表项需要迁移时，则会造成TCP数据包的时延急剧增加，进而造成复原时间目标(recovery time objective, RTO)超时重传.

TCP自身具有拥塞控制能力[12]，能够根据数据包返回信息动态地调整发送窗口大小.但在SDN网络中，即使链路状况良好，也可能造成RTT时间较长，使终端误判网络拥塞，从而使得窗口减小，甚至有可能长时间维持在1，这样就可能会极大地降低TCP的传输性能.

2 SDN时延影响因素分析及验证

2.1 实验参数

实验采用了PICA8 3297交换机，TCAM拥有4 000个表项，在流表匹配时转发时延平均为50 μs.控制器为floodlight，OpenFlow协议为v1.0，运行在Ubuntu 12.04 LTS上.发包程序由libnet实现，抓包程序由libpcap实现，编写语言为C.实验拓扑如图3所示：

Fig. 3 Measurement topology for testing SDN packet delay图3 测量SDN数据包时延的拓扑图

如1.2节所述，通过采用proactive模式，将所有流表项存放到交换芯片的存储上，使得以上因素3和因素4这2点问题不存在.2.2节和2.3节主要通过实验验证高速并发Packet-In以及流表项优先级对时延的影响.

2.2 高速Packet-In对时延的影响

在SDN控制平面与转发平面分离的情况下，为了展示网络瓶颈所在，我们测量了新流(hit-miss)在各个环节的时延分布情况，实验拓扑图同样如图3所示.

初始流表为空，网卡A按照指定的速度发出新流到SDN交换机，由于在流表中没有找到匹配项，交换机会产生相应数目的Packet-In.控制器根据流表生成策略生成Flow-Mod，下发到交换机，TCAM装载相应流表项指导后续数据包到达网卡B.网卡B接收相应的数据包计算时延.由于每个流只含有1个数据包，因此发送数据包的速度可被认为是产生Packet-In的速度.

令Ts为网卡A捕获数据包x的时间，Tr为网卡B捕获数据包x的时间，总传输时延为Tt=Tr-Ts.设控制器上捕获x对应的Packet-In的时间为Tp，控制器网卡捕获Flow-Mod的时间为Tf，则控制器上的处理时延为Tc=Tf-Tp.设定总的新流数目为400，随着并发速度从10 pps增长到5 000 pps，各个环节的平均时延分布如表1所示.每个数据流的时延情况如图4所示.

Table 1 Delay Distribution When Table Miss

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

数据显示，新流总数一定时，随着新流的并发速度加快，数据包的平均时延不断增大.在5 000 pps速度下，最大时延达1.624 s.随着并发速度的提高，交换机上Packet-In会批量上传到控制器，造成一些数据包总的时延变长.如表1中，当速度达到5 000 pps时，Packet-In在控制器上的平均耗时为25.38 ms，这是因为有25个Packet-In在交换机上按组上传到控制器，25.38 ms为控制器处理25个Packet-In的时间.控制器处理每个新流的平均时延基本没变，均为1～2 ms.

通过对图4进行分析，发现新流产生速度较快时，如1 000 pps，5 000 pps，数据包时延呈现阶梯式增长;当速度较慢时，数据包时延抖动很剧烈，如在速度为10 pps，100 pps的情况下.后续的所有时延相关的实验都展示了这种特点.

这一现象很可能是由于交换机处理Packet-In的策略造成的：Packet-In达到一定数目时，再上传到控制器；如果超过一定长度的等待时间，即使没有达到相应的数目，也要上传到控制器.这样，发送较慢时，Packet-In产生速度未触及瓶颈，但抖动很大，数据包时延呈周期性变化;当发送较快时，超出Packet-In产生瓶颈，排队时间越来越长，时延呈阶梯状增长.

当并发速度加快时，总体时延Tt显著变大，但是控制器处理每个新流的平均时延几乎没变.说明当Packet-In较小且并发速度在一定范围内时，SDN瓶颈是在交换机而不是在控制器.为了验证这种观点，我们用CBench工具[13]对控制器进行了测试.为了避免控制器与交换机之间通信性能的干扰，在floodlight所在主机上配置了CBench.测试模拟了16台交换机，每台交换机虚拟连接了1 000台主机，进行10次循环测试，每次循环测试持续10 s，时延测试在吞吐量模式下进行.实验结果显示，10组测试结果中最小吞吐量为360 817.77次s，最大吞吐量为403 931.03次s，平均也有390 514.08次s，这说明在本文实验范围内的Packet-In速度下，controller生成和下发规则的能力不会成为系统瓶颈.

2.3 流表项优先级变化对时延的影响

为了测量TCAM中流表项优先级在更新时对数据包时延的影响，基于拓扑图3进行了流表项优先级相关的实验.设初始情况下TCAM流表为空，共4 000个新流，每个新流包含1个数据包.数据包以10 pps的速率按照优先级依次递增、递减、不变3种模式发出，最终得出实验结果如图5所示.

Fig. 5 Packet delay in three kinds of flow entries priority change mode when rate=10 pps图5 rate=10 pps时3种流表项优先级变化的时延

实验结果表明，当插入的流表项优先级不变或者优先级递减时，处理时延几乎不变.但是在插入优先级递增时，随着插入流表项数量的增加处理时延显著变大，最大可达到9.648 s.

调研结果显示，不同的交换机TCAM中流表项的组织方式不同[5].PICA8的白盒交换机采用Boradcom公司的交换芯片.该交换芯片在TCAM中按优先级从高到低组织流表项.当流表项优先级随着插入顺序递增时，每1个插入的流表项优先级都要比TCAM中已有的流表项优先级高.当TCAM中流表项达到一定规模后，新插入的流表项会导致大量已有表项的移动，从而造成较大延时.

为了更直观地展示实验结果，我们进行了更进一步的实验.设定TCAM流表中已有指定数目的流表项，然后分别按照不变、降序、升序的优先级顺序发送100个新流，发送速度为10 pps，统计相应的时延情况，分别如图6～8所示.

rate=10 pps,num=100Fig. 6 Packet delay with the same priority图6 优先级不变、不同表规模的数据包时延

图6～8中的数据显示，随着基础表项不断增加，优先级递增的实验组延迟明显增加.相比而言优先级不变或者减小的实验组则变化很小，实验结果验证了上述观点.

交换机时延与优先级的特性很大程度上依赖于交换芯片对TCAM中流表的组织形式.如果交换芯片按照低优先级在前，那么实验结果将完全相反.同时值得注意的是，即使在proactive模式下，也必将伴随着频繁的换入换出，也会因为优先级的原因造成相应的时延.已有算法会对流表的数据结构进行改造[4,14],可以降低流表中表项的移动次数，但是这是以降低存储的利用率和增加算法的复杂度为代价的，同时也不能完全避免流表中表项的移动.因此，本文提到的问题依旧存在.

rate=10 pps,num=100Fig. 7 Packet delay when the priority decreases图7 优先级递减、不同表规模的数据包时延

rate=10 pps,num=100Fig. 8 Packet delay when the priority increases图8 优先级递增、不同表规模的数据包时延

3 对TCP的针对性测量分析

如1.3节所述，SDN工作模式可能为TCP带来2类问题，分别为建立连接困难与传输低效.

在建立连接时，客户端在第i(i=1,2,3…)个SYN数据包发出后，如果在Di时间内还未收到SYN+ACK，将会再次发送SYN数据包.在伯克利系统中D1即首次重发时间为5.8 s，D2=24 s，最大值为75 s[15].

在连接建立后，TCP进行数据传输.发送端第j次发送的数据包在Ej(j=1,2,…)时间内还未收到接收方反馈，发送端将会判断链路出现拥塞，发送窗口将以“线性加、乘性减”为原则剧烈减小，从而影响发送性能.实际上，此时很有可能不是真正发生拥塞，只是上述SDN网络特性导致时延很大，造成伪拥塞.伯克利系统实现版本之一E1=1.5 s，E2=3 s，依次倍增，最大值为64 s[15].

3.1 对TCP建立情况的分析

为了准确描述TCP建立连接在SDN网络中所面对的问题，我们按照拓扑图3进行了握手过程中往返时延的测量.在rule优先级递增的情况下，网卡A向网卡B按照指定的速度发送250个SYN，网卡B收到后立刻对网卡A返回1个相应的SYN+ACK，忽略主机协议栈耗时统计往返时延.

从图9，10，11可知，在流表项优先级随插入顺序递增时，TCAM中原有流表项数目达到一定规模后，相同的并发速度下往返时延呈阶梯式增长.同时，由图12～15可见，随着速度增加，时延在不断地变大.根据第2节的实验结果分析，在上述负载情况下，控制器上时延很小，绝大多数时延消耗在交换机上.

Fig. 9 RTT when TCAM load=500 and rules priority increases图9 TCAM load=500优先级递增时的往返时延

Fig. 10 RTT when TCAM load=2 000 and rules priority increases图10 TCAM load=2 000优先级递增时的往返时延

Fig. 11 RTT when TCAM load=3 500 and rules priority increases图11 TCAM load=3 500优先级递增时的往返时延

Fig. 12 RTT when Packet-In rate=10 pps图12 Packet-In rate=10 pps不同流表规模往返时延

Fig. 13 RTT when Packet-In rate=100 pps图13 Packet-In rate=100 pps不同流表规模往返时延

Fig. 14 RTT when Packet-In rate=1 000 pps图14 Packet-In rate=1 000 pps时不同流表规模往返时延

Fig.15 RTT when Packet-In rate=5 000 pps图15 Packet-In rate=5 000 pps时不同流表规模往返时延

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时不同速度下往返时延分布图

按照伯克利系统实现参数进行分析，首先在优先级递增情况下，不同并发速度对应的往返时延分布直方图分别如图16～18所示.当并发速度为10 pps，TCAM中已有流表项为500和2 000个流表项的情况下，所有数据包的往返时延都在5.8 s内，即所有的TCP握手数据包都能在初始RTO(5.8 s)内返回而不必重传.当并发速度为10 pps、初始流表项为3 500个时，单次数据包的往返时延有10%超出了5.8 s，即需要再次发送握手包.在10 pps的Packet-In速度下，随着基础流表装载规模变大，图16～18这3幅直方图相比分布重心不断右移，说明往返时延不断增大，成功建立连接发送握手包的期望次数不断变大.同时，在一定基础流表装载规模下，同一张分布直方图的重心也在右移，说明在基础流表装载规模一定时，随着Packet-In速度加快，成功建立连接需要发送的SYN数据包的期望数目不断增大.以基础流表装载规模为3 500个表项为例，当建立连接速度为10 pps时，处于0～5.8 s,5.8～24 s，24～75 s，75～Inf的数据包占比分别占比90%，10%，0%，0%，随着Packet-In产生速度加快，0～5.8 s即不需重传的数据包占比不断减小，同时需要重传的数据包占比不断增大.当Packet-In速度达到5 000 pps时，这一比例已经分别达到20.4%，0%，60%，19.6%.即不需重传的握手包只占20.4%，且有19.6%的数据包超过了75 s，最高达105.51 s，存在无法完成TCP连接建立的可能性.

值得注意的是，TCP连接需要经过3次握手才能建立，所以在建立过程中很有可能发生多次重传，造成建立连接困难.

3.2 对TCP传输性能的分析

TCP连接建立后TCAM中存在对应的流表项.在规模稍大的网络中，并发流的数目可以达到几兆甚至几十兆(如清华校园网2011年并发流就达到兆级别)，TCAM中的流表项会被频繁地换入换出.换入的过程中由于优先级造成的表项移动或者其他新流的产生，都会使TCP传输数据产生较大时延，超出RTO后可能导致TCP发送窗口减小，甚至有可能退化成停等协议，从而影响TCP的性能.

我们按照拓扑图3进行了数据发送过程中往返时延的模拟测量.在规则(rule)优先级递增的情况下，网卡A向网卡B按照指定的速度发送250不同的流，每个流包含1个数据包，网卡B收到后立刻给网卡A返回1个相应的ACK，忽略主机协议栈耗时统计总的往返时延.初始流表里的流表项都不能匹配这些流，需要在交换芯片的片上存储中进行查找，换入TCAM.统计TCP发送实验中从数据包发出到ACK返回时间间隔如图19所示：

Fig. 19 RTT distribution diagram图19 往返时延分布图

通过对图19的数据进行分析，在初始流表装载3 500个流表项时，在10 pps的发送速度下有73.2%的可能性会产生重传或者多次重传；在2 500个流表装载、5 000 pps发送速度的情况下，有些数据包甚至超出了最长等待时间75 s.重传造成窗口不断减小，使得TCP一直处于低效的工作状态.

在3.1节和3.2节的实验中，我们在1个SDN网络中最简单的拓扑情况下进行了实验，发现TCP面对各种问题.在实际网络中，TCP连接可能要在多个SDN自治域之间建立，经历多个交换机和控制器，因此TCP所面临的问题将会更加严重.

4 总 结

实验结果表明：SDN网络中TCP产生伪拥塞主要由交换机造成.无论主动模式还是被动模式，SDN网络由于Packet-In短时间内高速并发、优先级不同导致流表项大规模移动等原因，都会导致基于TCP的链接产生伪拥塞现象，造成性能下降.

SDN网络中数据包时延较大的原因，一方面是由于SDN交换机的处理速度跟不上Packet-In的产生速度，主要瓶颈体现在交换机的Local CPU性能较低以及CPU与交换芯片之间的带宽限制[5]，因此需要不断提高CPU性能和传输带宽，同时尽量减少二者之间的通信，如将频繁访问的流表放在交换芯片的片内存储中而不是放在Local CPU管理的内存中；另一方面原因是由交换芯片对TCAM的流表项组织方式造成的.探究如何组织TCAM上的表项，使其最大限度地降低流表项优先级特征造成的时延也成为我们下一步工作的重点.

最后，可以从TCP协议本身入手.实验结果显示，当前的TCP在SDN中很容易产生RTO超时，“线性加、乘性减”的窗口变化原则在SDN中是否依旧适用？如何更好地设计适用于SDN-TCP的RTO？如何设计适用于SDN网络的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控制器的调研和量化分析[J]. 计算机科学与探索, 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]. 计算机学报, 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)(姜文刚, 孙金生, 王执铨. 随机回退的 TCP 拥塞控制算法[J]. 电子学报, 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

国家自然科学基金重点项目(61432009) This work was supported by the Key Program of the National Natural Science Foundation of China (61432009).

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

TP393