朱丹红，林清祥，张 栋

福州大学 数学与计算机科学学院，福州 350108

1 引言

随着云计算和互联网应用的快速发展，网页搜索、社交网络和在线直播等实时交互式应用大量部署于数据中心[1]。这些应用在数据中心网络中主要采用划分/聚合的工作模式。聚合者（Aggregator）将用户请求分割成小任务，通过TCP短流同时向多个服务器（Worker）分发，服务器处理后，瞬时将结果返回聚合者，这种多对一的通信方式，造成数据流量突发并带来拥塞，产生TCP Incast问题[2]。同时，这些交互式应用产生大量混合多样的数据流[3]，包括时延敏感短流与时延不敏感长流，长流占用大部分缓存队列，导致短流拥塞，时延性能下降，产生短流高延迟问题[4]，实时应用的服务质量受到严重影响。

数据中心网络的TCP Incast和长短流竞争是引起短流高延迟的主要原因。延时是交互式应用的重要性能指标，短流完成时间大大影响用户体验，高延迟会带来严重的业务流失。因此，如何降低短流完成时间，保证短流低延时成为数据中心网络亟待解决的问题。D2TCP（deadline-aware data center TCP）[5]是基于时限感知的数据中心传输控制协议，针对中心网络的拥塞控制和流调度，引入时限感知，有效提高流在时限内完成的成功率。但D2TCP未能明确区分数据流的时延敏感特性，在短时拥塞中，时延敏感分组和非时延敏感分组交错，增加时延敏感流错过时限的概率。同时，对于数据中心网络的多对一通信模式，D2TCP在一定程度上仍会因TCP Incast而发生数据包丢失[6]。作为新型的网络架构，软件定义网络（Software Defined Networking，SDN）[7]将控制与转发分离，形成逻辑集中的控制平面，负责网络处理动作的调度。借助SDN对数据流进行监控，统一调度全局交换机，保证充足的缓冲资源应对多对一通信，能够减少TCP Incast发生。

本文利用SDN集中控制的特点，针对TCP Incast，在时限感知拥塞控制的基础上，为时延敏感短流赋予较高的优先级，设计SDN-D2TCP方案，解决数据中心网络的长短流竞争和TCP Incast问题。

2 相关工作

数据中心网络的通信广泛采用TCP协议。但传统TCP针对低带宽、低时延的广域网，难以适应高带宽、低时延的数据中心网络要求[8]，导致长短流竞争和TCP Incast等问题。现有的解决方案主要分为两类。一是设计有别于现有TCP的全新传输协议，如HULL[9]，D3[10]，pFabric[11]等；另一类则是基于现有TCP的改进方案，如DCTCP[12]，D2TCP等。

在全新的设计协议中，HULL利用影子队列估计带宽使用率，通过牺牲10%～20%的带宽来消除缓冲使用，预防拥塞，降低延迟。但HULL平等对待所有流，不利于保证短流时延。D3则根据流大小与时限区分优先级分配带宽，避免TCP Incast问题。然而D3交换机对所有流进行集中带宽分配，实际中受硬件计算能力和内存容量限制，可行性低。pFabric将基于优先级的流调度与流速控制解耦，流初始采用线性速率注入，只有多次丢包后才对流速压制，被广泛应用，但因为流速控制过于简单导致大量丢包事件，影响协议性能。

在基于TCP改进上，DCTCP是一种TCP变体，仅需对已有TCP做简单修改就能很好地提升性能。该协议基于ECN消息，根据网络的拥塞程度调节拥塞窗口，降低发送速率，有效减少分组丢失。但由于数据中心网络长短流并存，流的时限要求各不相同，DCTCP未考虑流时限，具有一定局限。D2TCP结合流时限，在传输层引入时限感知，提高短流优先级，显著减小短流完成时间。然而，D2TCP未能区分流的时延敏感性，在短暂拥塞期间，时延敏感分组可能排在拥塞队列后面，增加错过时限的可能性。此外，规模庞大的数据中心网络通常采取缓冲资源少的浅缓存交换机，多对一通信模式产生大量高并发，在缓存较低的状态下，D2TCP传输控制策略会因TCP Incast而造成一定程度的丢包。

SDN作为一种数据控制分离、软件可编程的新型网络体系架构，其核心是将控制和转发分离，控制平面拥有对全网的管控能力，数据转发根据上层控制器的指示进行[13]。本文在D2TCP基础上，引入优先级思想区分数据流的时延敏感特性，为时延敏感流赋予较高优先级，并进一步利用SDN的集中控制思想及数据流的控制技术，预防TCP Incast的发生。在数据中心网络，通过SDN将多对一通信模式数据流与其他流区分，进行单独监控，控制器根据全局交换机资源判断，若当前缓冲资源不足以应对即将发生的多对一通信，则通过下发规则，迫使占据交换机缓冲资源的长流降低发送速率，保证多对一通信。

3 问题描述

3.1 长短流竞争

数据中心网络流量分布的特征是，1～10 KB的短流数量较多，1～50 MB的长流相对较少，但长流所占的字节总量大，占用资源多，造成短流排队延时甚至丢包。如图1所示，短流进入网络前，交换机的缓冲资源已被长流占据，此时短流经过相同的交换机端口，分组将会排到队尾，导致排队时延过长。如果长流已将缓冲资源耗尽，短流将会产生丢包。

图1 长短流竞争示意

DCTCP通过快速响应交换机队列长度变化来降低延迟。交换机使用RED等主动式队列算法，当队列长度大于某个阈值K时，对数据分组进行ECN标记，接收端收到ECN后，在反向ACK分组标记ECN-echo并回传，由发送端统计传回的ACK，利用公式（1）衡量拥塞程度。其中，α表示交换机队列超过阈值K的概率，每隔一个RTT（Round Trip Time，往返时间）被更新。权重参数g用于评估拥塞概率，F是前一个RTT内被标记的分组比例。而后发送端按照公式（2）相应减小拥塞窗口cwnd，保证网络不过载，优化吞吐量和延迟。但DCTCP协议平等对待所有数据流，对延时敏感的短流不利，在最小化流的延迟性能上不是最优。

D2TCP在DCTCP算法中引入时限感知因子d，使用γ校正函数

调节拥塞窗口W。其中：

理论上减少错过时限的短流比例，增加短流竞争力。但由于数据流具有时效性需求，因此引入优先级区分流的时延敏感特性，能够进一步减少时延敏感流错过时限的可能。

定义拥塞发生时数据流的优先级：

其中，VA为流已发送的平均速率，VE为流发送的期望速率。由此，时延敏感的数据流将被分配较高的优先级。进一步定义校正函数：

拥塞窗口仍采用公式（4）调节。可以看出，时限要求越小，时延越不敏感的数据流，窗口退避程度越大，从而为网络腾出带宽，保证时限约束。

3.2 TCP Incast现象

数据中心网络采用的多对一通信模式如图2所示。由Aggregator把任务同时分发给多个Worker，Worker计算处理后几乎同时将结果返回给Aggregator，造成数据流量突发。连接Aggregator的交换机中分组数量迅速增长，超出缓存能力，成为网络瓶颈。过多的Worker甚至会耗尽交换机的缓冲资源，发生丢包，继而触发TCP的超时重传机制，导致流错过时限。

图2 TCP Incast现象

长短流竞争和TCP Incast并存于中心网络，导致短流延时性能明显下降。本文提出基于SDN-D2TCP的解决方案，核心思想是通过SDN技术监控网络流量，侦测网络中多对一的通信行为，预测TCP Incast发生的瓶颈交换机，并考虑数据流的时延敏感特性，结合时限感知和ECN标记调整拥塞窗口，压制该交换机的流注入速率，确保交换机拥有更多的缓冲资源来应对多对一通信。

4 SDN-D2TCP方案

4.1 设计思想

数据中心网络的Aggregator和Worker通常是连接同一机架交换机的服务器。本文方案将数据中心SDN化，交换机接受SDN控制器的控制与管理。如图3所示，首先，在控制器中注册Aggregator的IP地址和Worker通信端口号，根据注册信息，在交换机建立流表；当Aggregator向多个Worker分发客户请求时，交换机对IP和端口号执行匹配，侦测多对一通信行为，并计算流量；最后依据流量结果判别拥塞情况，并由交换机上报控制器，调用D2TCP算法进行拥塞控制。

图3 SDN-D2TCP流程

4.2 控制与转发平面模型

SDN网络架构体系中，控制器能够为上层应用提供管理和控制的可编程接口，因此构建预防TCP Incast的应用TIP（TCP Incast Preventer），如图4所示。在转发平面的SDN交换机中设计三张表，分别为Monitor Table、Set-ECN Table和Route Table。各模块具体如下：

（1）REST API：外部应用（如Map/Reduce应用）和TIP进行通信的接口。

（2）多对一应用注册模块（Register）：即多对一通信模式的应用注册模块。Aggregator利用REST API向TIP注册Aggregator自身IP及与Worker通信使用的端口号等。

（3）网络流量监测模块（Traffic Monitor）：将当前数据中心的网络流量提供给预防决策生成模块，并根据注册信息，向交换机下发监测规则。即在交换机中建立Monitor Table，将关联IP和端口号等特征作为匹配项，一旦侦测到多对一通信分组，上报控制器处理。

（4）预防决策生成模块（Strategy Generator）：交换机上报多对一通信行为后，根据Traffic Monitor提供的流量信息，判断是否造成TCP Incast。具体为，计算网络流量及多对一通信的流量总量并记录于交换机Set-ECN Table，判断拥塞程度，调整拥塞窗口，从而压制瓶颈端口（如连接Aggregator的交换机端口）其他流的发送速度，尽可能保证短流不丢包且能在较短时间内完成传输。

（5）BASIC API：该模块为TIP提供一些和控制器交互的共同API。

图4 控制和转发平面模型

4.3 TCP Incast预防流程

基本流程如图5所示。

（1）register：Aggregator使用REST API向TIP进行注册。

图5 TCP Incast预防流程

（2）set monitoring rules：控制器（TIP）向交换机下发多对一流量监控规则。

（3）delivery request：Aggregator向多个Worker分发客户请求。

（4）report incast：交换机调用算法1，侦测多对一的通信流量，向控制器（TIP）上报。

（5）set incast-avoid rules：TIP向瓶颈交换机下发预防TCP Incast的规则。

（6）response：瓶颈交换机通过预防措施腾出更多缓冲资源，保证多个Worker能几乎同时向Aggregator发送响应数据。

本文基于SDN数据中心网络，提出时限感知的拥塞控制算法如下所示。其中，K为交换机判断是否处于拥塞状态所设的阈值；α为队列长度大于K的概率，体现网络拥塞程度；惩罚函数p在α≤1时，p≤1，保证拥塞加剧或时限结束时收敛；拥塞窗口W根据网络拥塞程度调节。

算法1 SDN时限感知的拥塞控制算法

1：SDN Switch匹配Aggregator ip 与Worker port，侦测many-to-one communication；

2：SDN Switch 根据 many-to-one communication生成Set-ECN Table，计算flow size；

3：if flow size ＜=阈值Kthen保持Aggregator正常发送，转1；

4：else SDN Switch向TIP report incast；

5：TIP 向SDN Switch下发incast-avoid rules：基于D2TCP，对分组标记ECN，利用公式（1）和（6）计算α和p；

6：发送端根据公式（4）调整congestion windowW，压制flow rate，避免产生长队列导致丢包。

5 实验仿真

5.1 实验环境设置

本文采用网络模拟器NS2进行实验，使用数据中心网络的常见拓扑（如FatTree[14]或VL2[15]），如图5所示。模拟某机架（Rack）的交换机（ToR）和服务器之间的连接。实验中服务器为35台，交换机与服务器之间的链路带宽为1 Gb/s，链路延迟为20 μs。交换机的端口队列限制设置为104个分组，取SDN-D2TCP中参数K=35,g=1/16，且为每条流设置时限参数d与期望发送速率VE。所有的服务器中，1台作为Map/Reduce应用中的Aggregator，其余34台作为Worker。短流采用Web搜索场景的查询流模拟，Aggregator向每个Worker发送1.6 KB大小的分组请求，Worker收到后，平均经过50 ms间隔返回2 KB的响应分组；在Aggregator收到所有Worker的响应分组后，等待10 ms，再向Worker发起请求，如此反复。另外，整个实验过程设置3条长流从不同的Worker向Aggregator传输，模拟时间总长度为0.81 s。

5.2 拥塞窗口分析

图6显示实验中长流与查询流的拥塞窗口变化情况。由于TCP要求交换机有大量缓冲，因此长流容易在交换机上集结，影响查询流完成。如图6（a）所示，TCP无法压制长流，其拥塞窗口呈现幅度较高的锯齿形变化，大部分查询流无法完成通信。而DCTCP、D2TCP依据拥塞程度调节拥塞窗口，减小交换机缓冲，提高查询流的完成比例。（b）、（c）显示，DCTCP、D2TCP能稳定压制长流拥塞窗口，只有部分查询流因丢包而无法顺利完成。SDN-D2TCP通过SDN控制器侦测多对一通信，监控网络流量来控制拥塞，由图（d）显示，SDN-D2TCP不仅能稳定压制拥塞窗口，并在一些时刻控制更低，减少丢包产生，保证查询流的多对一通信传输。

5.3 交换机队列长度分析

由图7所示，TCP使交换机的队列平均长度维持在较高值80，而DCTCP、D2TCP及SDN-D2TCP能使平均长度保持在37左右，但在多对一通信过程中，DCTCP和D2TCP无法保证队列长度维持在限制长度104以下。而SDN-D2TCP能将队列最高长度维持在83左右。由于交换机的队列长度控制越短，越不容易丢包，因此SDND2TCP能较好改善数据包丢失情况的发生。

5.4 查询流时延分析

图8显示在TCP、DCTCP、D2TCP以及SDN-D2TCP情况下查询流时延的概率密度分布。TCP协议下，长短流公平共享，长流占用大部分交换机缓存，拥塞发生时，发送端检测到丢包才进行拥塞控制，调整拥塞窗口，导致查询流错过时限，时延性能降低。图8（a）表明TCP下40%的查询流时延超过350 ms。DCTCP通过ECN在拥塞即将发生时，根据拥塞程度，调整发送速率，提升了性能。但该协议平等共享且时限不可知，因此仍有部分数据流错过时限。图8（b）表明DCTCP将大部分查询流时延维持在53 ms左右，但仍有少量查询流的时延超过300 ms。D2TCP引入时限感知，进一步减小错过时限数据流的比例。SDN-D2TCP在D2TCP基础上，借助SDN全局视野和集中控制的特性，考虑时延敏感约束，缩短了查询流时延。（c）和（d）表明D2TCP和SDN-D2TCP均使查询流时延保持在50～53 ms。因此，SDN-D2TCP能较好满足查询流的时限约束。

图6 拥塞窗口对比图

图7 交换机队列长度对比

图8 查询流时延的概率分布对比

图9 查询流完成次数对比

图10 吞吐量对比

5.5 吞吐量和查询流完成次数对比

为了更好地比较SDN-D2TCP与其他传输控制协议，本文在长流数量为1、3、5和7，服务器数量为31、33、35和37的情况下，进行仿真实验，比较吞吐量和查询流完成次数。由图9和图10明显看出，在各种情况下，TCP因为Incast发生，导致查询流完成次数和吞吐量皆小于其他协议。DCTCP和D2TCP的拥塞控制机制能有效缓解Incast，优化传输性能。而SDN-D2TCP针对多对一通信侦测，预防和控制Incast，因此在各种情况下，查询流完成次数和吞吐量都优于其他三种协议。

6 结论

本文以降低数据中心网络短流延迟为主要目标，考虑数据流时延敏感特性，基于D2TCP协议结合SDN控制与转发分离思想，设计SDN-D2TCP方案，通过SDN控制器预测多对一通信行为，提前预防TCP Incast发生，保证在长短流竞争，交换机缓冲资源有限的情况下，短流能够在较短时间内完成传输。实验表明该方案具有较理想的性能。由于D2TCP是根据ECN反馈的拥塞控制策略，部署适应范围具有一定局限性。下一步将针对延时反馈机制，研究数据中心的SDN-延时反馈拥塞控制策略。

[1]Sreekumari P，Jung J I.Transport protocols for data center networks：A survey of issues，solutions and challenges[J].Photonic Network Communication，2016，31（1）：112-128.

[2]Wu H，Feng Z，Guo C，et al.ICTCP：Incast congestion control for TCP in data-center networks[J].IEEE/ACM Transactions on Networking（TON），2013，21（2）：345-358.

[3]Chen G，Zhao Y，Pei D.Alleviating flow interference in data center networks through fine-grained switch queue management[J].Computer Networks the International Journal of Computer&Telecommunications Networking，2015，91（C）：593-613.

[4]Cheng Wenxue，Ren Rengyuan，Jiang Wanchun，et al.Isolating mice and elephant in data centers[J].arXiv preprint arXiv：1605.07732，2016.

[5]Vamanan B，Hasan J，Vijaykumar T N.Deadline-aware datacenter tcp（d2tcp）[C]//ACM SIGCOMM Computer Communication Review，2012，42（4）：115-126.

[6]Chen L，Hu S，Chen K，et al.Towards minimal-delay deadline-driven data center tcp[C]//Proceedings of the Twelfth ACM Workshop on Hot Topics in Networks，2013：21-27.

[7]McKeownN.Software-definednetworking[J].INFOCOM Keynote Talk，2009，17（2）：30-32.

[8]苏凡军，牛咏梅，邵清.数据中心网络快速反馈传输控制协议[J].计算机工程，2015，41（4）：107-111.

[9]Alizadeh M，Kabbani A，Edsall T，et al.Less is more：Trading a little bandwidth for ultra-low latency in the data center[C]//Presented as part of the 9th USENIX Symposium on Networked Systems Design and Implementation（NSDI 12），2012：253-266.

[10]Wilson C，Ballani H，Karagiannis T，et al.Better never than late：Meeting deadlines in datacenter networks[C]//ACM SIGCOMM Computer Communication Review，2011，41（4）：50-61.

[11]Alizadeh M，Yang S，Sharif M，et al.pfabric：Minimal near-optimal datacenter transport[C]//ACM SIGCOMM Computer Communication Review，2013，43（4）：435-446.

[12]Alizadeh M，Greenberg A，Maltz D A，et al.Data center tcp（dctcp）[C]//ACM SIGCOMM Computer Communication Reviews，2010，40（4）：63-74.

[13]张朝昆，崔勇，唐翯祎，等.软件定义网络（SDN）研究进展[J].软件学报，2015，26（1）：62-81.

[14]Al-fares M，Loukissas A，Vahdat A.A Scalable，commodity data center network architecture[C]//ACM SIGCOMM Computer Communication Review，2008，38（4）：63-74.

[15]Greenberg A，Hamilton J R，Jain N.VL2：A scalable and flexible data center network[C]//ACM SIGCOMM Computer Communication Review，2009，39（4）：51-62.