一种数据中心网络中基于并发度感知的传输控制方法

摘要

本发明公开了一种数据中心网络中基于并发度感知的传输控制方法，在数据传输过程中，发送端根据当前的拥塞窗口和并发度来调整相邻分组的发送时间间隔从而控制发送速率，避免大量分组同时到达交换机而引发丢包和超时。本发明可以有效的调整发送速率，避免TCP连接出现频繁超时，从而减少了流完成时间并且提高了网络吞吐率。

权利要求

1.一种数据中心网络中基于并发度感知的传输控制方法，其特征在于，包括以下步骤：步骤1：参数初始化；

步骤2：发送分组；

步骤3：发送端启动分组间隔调节定时器；

步骤4：发送端判断分组间隔调节定时器是否到期，若是且数据没有发送完毕，则发送下一个分组；若是且数据发送完毕，则结束；否则继续等待；

步骤5：发送端收到ACK后，利用当前时间和上一次接收到ACK的时间估算瓶颈链路的并发度；

步骤6：发送端根据并发度、拥塞窗口、缓存容量和链路容量计算相邻分组的发送时间间隔，使之适应当前的网络拥塞状态；

步骤7：对相邻分组的发送时间间隔进行随机化处理；

步骤8：发送端根据步骤7的处理结果更新分组间隔调节定时器的到期时间，并更新最近一次收到ACK的时间，返回步骤3。

2.根据权利要求1所述的数据中心网络中基于并发度感知的传输控制方法，其特征在于，所述步骤1包括：设置拥塞窗口大小w、分组大小s、分组间隔调节定时器的到期时间t、最近两次收到ACK的时间t0和t1、链路容量C、往返传输延时RTT、分组的发送延时td以及交换机每个端口的缓存容量B。

3.根据权利要求1所述的数据中心网络中基于并发度感知的传输控制方法，其特征在于，所述步骤2中：发送端根据分组的目的IP地址将分组发送到目的主机。

4.根据权利要求2所述的数据中心网络中基于并发度感知的传输控制方法，其特征在于，所述步骤5中：发送端接收到ACK后，记录当前的时间为t1，并判断是否是首次接收到ACK，如果是，则将变量t0更新为t1，用于记录最近一次接收ACK时间，并转步骤4；否则，发送端利用两次收到ACK的时间t0和t1以及发送延时td估算出瓶颈链路上的并发度n，具体计算方法如下：tq＝t1-t0

td＝s/C

其中，tq表示队列延时。

5.根据权利要求4所述的数据中心网络中基于并发度感知的传输控制方法，其特征在于，所述步骤6中：发送端首先结合估算的并发度n、拥塞窗口w、链路容量C和缓存容量B计算出发送下一个分组的时间间隔，具体计算方法如下：然后计算相邻分组的发送时间间隔，具体计算方法如下：

6.根据权利要求5所述的数据中心网络中基于并发度感知的传输控制方法，其特征在于，所述步骤7中：在步骤6的基础上，发送端对相邻分组的发送时间间隔进行随机化处理，将其设置为t×(1+x)；其中，x是一个随机变量，它的取值范围是[-1，1]。

7.根据权利要求6所述的数据中心网络中基于并发度感知的传输控制方法，其特征在于，所述步骤8中：发送端将分组间隔调节定时器的到期时间更新为t，并将变量t0更新为t1，返回步骤3。

说明书

一种数据中心网络中基于并发度感知的传输控制方法

技术领域

[0001] 本发明涉及一种数据中心网络中基于并发度感知的传输控制方法。

背景技术

[0002] 近年来，随着云计算技术的迅猛发展，数据中心已经成为了关键基础设施，不仅承载大量的应用程序并且提供各种各样的用户服务，如推荐系统、网络搜索和MapReduce。为了给用户提供更好的服务，部署在数据中心的各类应用通常需要协调多台服务器共同完成任务。为此，不同服务器之间需要进行通信。由于各服务器之间的通信必须通过网络来实现，而网络问题又是数据中心的瓶颈问题，因此，数据中心中的网络(即数据中心网络)成为了研究的热点。

[0003] 与传统网络相比，数据中心网络具有很多独特的属性。一方面，由于数据中心的服务器和交换机等设备通常部署在一个较小的物理区域，因此往返传输延时(Round Trip Time,RTT)很低，通常只有几百微秒。另一方面，考虑到成本问题，数据中心网络中的交换机并非定制，它所具有的缓存容量通常较小。此外，在数据中心网络具有超高带宽，且一对多或者多对多的通信模式广泛存在于并行编程系统(如Dryad和CIEL等)、分布式文件存储系统和大型排序系统等。这些独特的属性使得数据中心内部流量急剧增长并呈现出与传统互联网不同的新特性。

[0004] 大量的研究表明，数据中心网络中通常采用TCP协议传输数据(占总流量的95％)，以确保给用户提供可靠的服务。尽管TCP协议是一个非常成熟的通信技术，但是TCP协议是针对低带宽和高延迟的广域网设计。上述数据中心网络特有的属性以及特殊的业务需求使得在广域网中运行良好的TCP协议遇到了很多问题，其中TCP Incast就是最重要的问题之一。

[0005] 针对TCP Incast问题，许多研究者深入分析了TCP Incast为何会严重降低网络吞吐率的原因。一方面，高扇入的并发度极易导致交换机出现严重的丢包，使得TCP协议中的快重传机制失效，从而导致超时重传。另一方面，在数据中心网络中，由于RTT通常是微妙级的，而最小超时重传时间(MinimumRetransmission TimeOut,RTOmin)是毫秒级(默认最小值为200ms)的。因此，一旦发生超时，链路会在相当一段时间(约为几百个RTT)内处于空闲状态，严重降低网络性能。为了解决TCP Incast问题，近年来，学术界提出了许多方案解决TCP Incast问题。这些方案大致可分为以下几大类：

[0006] 1.调整系统参数。Vijay Vasudevan等人将最小超时重传时间(默认为200ms)修改成200us，避免超时导致链路长时间空闲。但该方法容易导致大量的假超时和假重传。一些研究者通过修改分组的大小解决TCP Incast问题，但这样增加了分组头的传输开销，降低了网络传输的有效吞吐率。

[0007] 2.设计新的传输协议。DCTCP根据被ECN标记包的比例调整拥塞窗口。DCTCP具有较2 2
好的突发容忍性，实现很好的网络性能。在DCTCP的基础上，研究者们还提出了DTCP和LDCT等协议。但是这些协议的主要缺陷是无法很好的处理高并发的场景。ICTCP根据网络带宽设置接收窗口，从而实现拥塞控制。然而，精确地估计当前可用带宽非常具有挑战性。

[0008] 3.跨层协议设计。PLATO采用包标记方案维持ACK-clocking从而避免超时。TFC利用令牌、可用带宽和有效流的数量计算出每条流的拥塞窗口，从而实现拥塞控制。然而这些方法需要修改交换机，不利于实际环境的部署。此外，一些研究者采用编码的方案来解决TCP Incast问题，如LTTP和TCP-ACC。但是，基于编码的方案不可避免的在网络中传输大量的冗余包，降低带宽的利用率。

[0009] 此外，一些研究者提出了TCP Pacing。它的基本思想是发送端在一个RTT内将整个窗口的分组均匀的发送到网络中。在高并发的应用中，TCP Pacing能够降低流量突发从而减少丢包和超时，有利于提高吞吐量。然而，在低并发的应用中，如果交换机的缓存容量足够容纳突发分组，TCP Pacing导致带宽资源得不到充分利用从而降低网络的性能。

[0010] 因此，如何有效缓解或解决TCP Incast从而避免吞吐率的坍塌已经成为数据中心网络领域一个非常重要和迫切需要解决的问题。

发明内容

[0011] 本发明所解决的技术问题是，针对现有技术的不足，提供了一种数据中心网络中基于并发度感知的传输控制方法，利用高精度定时器控制分组的发送时间，使得到达交换机的分组控制在缓存能够容纳的范围之内，这样能够有效的避免交换机发生大量的丢包和超时，提高了网络吞吐率。

[0012] 本发明解决上述技术问题的技术方案为：

[0013] 一种数据中心网络中基于并发度感知的传输控制方法，其特征在于，在数据传输过程中，发送端根据当前的拥塞窗口和并发度来调整相邻分组的发送时间间隔从而控制发送速率。具体包括以下步骤：

[0014] 步骤1：参数初始化；

[0015] 步骤2：发送分组；

[0016] 步骤3：发送端启动分组间隔调节定时器；定时器为发送端发送数据的一小段程序代码，作为发送数据时的判断条件，这样做可以降低计算和控制开销；

[0017] 步骤4：发送端判断分组间隔调节定时器是否到期，若是且数据没有发送完毕，则发送下一个分组；若是且数据发送完毕，则结束；否则继续等待；

[0018] 步骤5：发送端收到ACK后，利用当前时间和上一次接收到ACK的时间估算瓶颈链路的并发度；

[0019] 步骤6：发送端根据并发度、拥塞窗口、缓存和链路容量计算相邻分组的发送时间间隔，使之适应当前的网络拥塞状态；

[0020] 步骤7：对相邻分组的发送时间间隔进行随机化处理；

[0021] 步骤8：发送端根据步骤7的处理结果更新分组间隔调节定时器的到期时间，并更新最近一次收到ACK的时间，返回步骤3。

[0022] 所述步骤1包括：设置拥塞窗口大小w、分组大小s、分组间隔调节定时器的到期时间t、最近两次收到ACK的时间t0和t1、链路容量C、往返传输延时RTT、分组的发送延时td、设置交换机每个端口的缓存容量为B。

[0023] 所述步骤2中：发送端根据分组的目的IP地址将分组发送到目的主机。

[0024] 所述步骤5中：发送端接收到ACK后，记录当前的时间为t1，并判断是否是首次接收到ACK，如果是，则发送端将变量t0更新为t1，用于记录最近一次接收ACK时间，并转步骤4；否则，发送端利用两次收到ACK的时间t0和t1以及发送延时td估算出瓶颈链路上的并发度n，具体计算方法如下：

[0025] tq＝t1-to

[0026] td＝s/C

[0027]

[0028] 其中，tq表示队列延时。

[0029] 所述步骤6中：发送端结合估算的并发度n、拥塞窗口w、链路容量C和缓存容量B计算出发送下一个分组的时间间隔，具体计算方法如下：

[0030]

[0031] 由于整个窗口的分组需要在一个RTT内发送到网络中，因此相邻分组之间的时间间隔不能超过 此外，无论网络是否发生拥塞，相邻分组之间的时间间隔不能小于0。简言之，相邻分组的发送时间间隔的具体计算方法如下：

[0032]

[0033] 所述步骤7中：在步骤6的基础上，发送端对相邻分组的发送时间间隔进行随机化处理，将其设置为t×(1+x)。其中，x是一个随机变量，它的取值范围是[-1,1]。该方法不仅能够避免不同流出现窗口同步的现象，而且能够保证整个窗口内的分组在一个RTT内发送到网络中。

[0034] 所述步骤8中：发送端将分组间隔调节定时器的到期时间更新为t，并将变量t0更新为t1，返回步骤3。

[0035] 本发明的技术效果在于：

[0036] 本发明发送端可以根据瓶颈链路的并发度及其拥塞窗口等信息动态调整分组的发送时间间隔，从而调控发送速率。针对高并发的应用，发送端增大相邻分组的发送时间间隔，从而降低发送速率，这样可以有效避免交换机丢弃大量的丢包而导致TCP超时，避免高并发导致的TCP Incast问题。反之，针对低并发的应用，发送端减少相邻分组的发送时间间隔，甚至是背靠背的发送分组，这样可以充分利用带宽资源，实现高带宽利用率。

附图说明

[0037] 图1为本发明的流程图。

[0038] 图2为测试本发明性能所使用的网络拓扑图。图2(a)为Incast场景示意图，图2(b)为Fat-tree拓扑。

[0039] 图3为本发明和其他方法在模拟测试环境中，测试不同方法在不同场景下所支持的并发度，其中本发明命名为AP。图3(a)～图3(d)分别为不同的往返时间RTT和链路容量C下，测试不同协议是否结合分组发送间隔调节方法的场景下所支持的最大并发度。

[0040] 图4为本发明在模拟测试环境中，随着时间的变化，流数先增后减的场景下测量评估并发度的准确性。其中本发明命名为AP。

[0041] 图5为本发明和其他方法在模拟实验测试环境中，在Fat-tree网络拓扑下测试流的平均完成时间，其中本发明命名为AP。图5(a)为不同方法随着pod个数的增加，平均流完成时间变化图；图5(b)为不同方法随着流个数的增加，平均流完成时间变化图。

[0042] 图6为本发明和其他方法在测试床环境中，设置不同的缓存大小和服务请求单元大小，测量随着流数增加的吞吐率。其中本发明命名为AP。图6(a)为缓存大小为64KB且服务请求单元大小为64KB，测量随着流数增加的吞吐率；图6(b)为缓存大小为64KB且服务请求单元大小为128KB，测量随着流数增加的吞吐率；图6(c)为缓存大小为32KB且服务请求单元大小为32KB，测量随着流数增加的吞吐率；图6(d)为缓存大小为128KB且服务请求单元大小为32KB，测量随着流数增加的吞吐率。

[0043] 图7为本发明和其他方法在测试床境中，测试Web搜索应用模式下的不同测试指标的结果图，其中本发明命名为AP。图7(a)为不同方法随着流数的增加获得的搜索响应时间；图7(b)为不同方法随着流数增加获得的超时率。

具体实施方式

[0044] 下面结合附图对本发明作进一步的说明。

[0045] 参见图1，图1为本发明的流程图。过程如下：

[0046] 步骤1：参数初始化。设置拥塞窗口大小为w；设置分组大小为s；设置分组间隔调节定时器到期的时间间隔为t；设置最近两次收到ACK的时间为t0和t1；设置并发度为n；设置链路容量为C；设置往返传输延时为RTT；设置分组的发送延时为td；设置交换机每个端口的缓存容量为B；

[0047] 步骤2：发送端根据分组的目的IP地址将分组发送到目的主机；

[0048] 步骤3：发送端启动分组间隔调节定时器；

[0049] 步骤4：发送端判断分组间隔调节定时器是否到期，若是且数据没有发送完毕，则发送下一个分组；若是且数据发送完毕，则结束；否则继续等待；

[0050] 步骤5：接收到ACK后，发送端记录当前的时间为t1；如果发送端是首次接收到ACK，则发送端将变量t0更新为t1，用于记录最近一次接收ACK时间；否则，发送端利用两次收到ACK的时间t0和t1以及发送延时td估算出瓶颈链路上的并发度n，具体计算方法如下：

[0051] tq＝t1-t0

[0052] td＝s/C

[0053]

[0054] 其中，tq表示队列延时。

[0055] 步骤6：发送端结合估算的并发度、拥塞窗口、链路容量和缓存容量计算出发送下一个分组的时间间隔，具体计算方法如下：

[0056]

[0057] 其中，n表示并发度；w表示拥塞窗口；B表示缓存容量；C表示链路容量。

[0058] 由于整个窗口的分组需要在一个RTT内发送到网络中，因此相邻分组之间的时间间隔不能超过 此外，无论网络是否发生拥塞，相邻分组之间的时间间隔不能小于0。简言之，相邻分组的发送时间间隔的具体计算方法如下：

[0059]

[0060] 步骤7：在步骤6的基础上，发送端对相邻分组的发送时间间隔进行随机化处理，将其设置为t×(1+x)。其中，x是一个随机变量，它的取值范围是[-1,1]。该方法不仅能够避免不同流出现窗口同步的现象，而且能够保证整个窗口内的分组在一个RTT内发送到网络中。

[0061] 步骤8：发送端将分组间隔调节定时器的到期时间更新为t，并将变量t0更新为t1，返回步骤3。

[0062] 我们分别在模拟仿真和测试床平台测试上测试本发明的网络性能。本发明AP可以嵌入到不同的TCP传输协议，提升网络性能。在实验结果图中，如果协议的下标含有AP，则表示将AP嵌入到协议中。例如，DCTCP表示原始协议，而DCTCPAP表示已将本发明AP嵌入到DCTCP中。

[0063] 1.模拟实验测试环境测试结果

[0064] 本发明首先利用NS2.35网络仿真平台来实现，并进行了性能测试。NS2已被网络研究者广泛使用，它在互联网上公开发布的网址为：http://www.isi.edu/nsnam/ns。NS2.35是NS2的版本之一。

[0065] 图3使用的实验拓扑和图2(a)所示的Incast场景示意图一致。多个服务器连接到同一交换机，实验参数设置如下：交换机缓存为100个包；交换机进行ECN标记的阈值为65个包；所有链路容量均为10Gbps；包大小为1500bytes；往返时间RTT为400us；最小超时重传时间RTOmin为200ms；SRU大小为32kbytes。

[0066] 图3使用的实验拓扑和图2(a)所示的Incast场景示意图一致。多个服务器连接到同一交换机，每条服务器发送10包且每个包的大小为1500bytes。我们在不同的往返时间RTT和链路容量C的场景下进行测试。

[0067] 图3(a)为往返时间RTT为100us且链路容量C为10Gbps时，测试不同协议是否结合分组发送间隔调节方法的场景下所支持的最大并发度。

[0068] 图3(b)为往返时间RTT为100us且链路容量C为40Gbps时，测试不同协议是否结合分组发送间隔调节方法的场景下所支持的最大并发度。

[0069] 图3(c)为往返时间RTT为300us且链路容量C为10Gbps时，测试不同协议是否结合分组发送间隔调节方法的场景下所支持的最大并发度。

[0070] 图3(d)为往返时间RTT为300us且链路容量C为40Gbps时，测试不同协议是否结合分组发送间隔调节方法的场景下所支持的最大并发度。

[0071] 在图3中，由于相邻分组的发送间隔受限，不可避免限制了AP的有效性。尽管如此，各协议结合AP后，所支持的最大并发度都有所提升，性能提升高达2倍以上。

[0072] 图4使用的实验拓扑和图2(a)所示的Incast场景示意图一致。多个服务器连接到同一交换机，实验场景设置如下：初始阶段，10台服务器各发送一条长流到同一个接收端，然后，每隔10毫秒增加一条流，直至总流数达到50。由于新增加的流仅运行0.6s，因此0.6s后，流的数量将逐渐减少，最终网络中仅有10条长流。在测量的过程中，每隔2ms进行采样得到图4所示的结果。测量结果显示，本发明评估的流数与网络中实际的流数非常接近。

[0073] 除了以上给出的测试床的局部性能测试，为了全面比较该发明的高效性，我们在图2(b)所示的Fat-tree拓扑中进一步测试了平均流完成时间。实验参数设置如下：架顶交换机、汇聚交换机和核心交换机缓存的缓存分别为100、200和400个包；交换机进行ECN标记的阈值为65个包；所有链路容量均为10Gbps；包大小为1500bytes；最小超时重传时间RTOmin为200ms；SRU大小为64kbytes。实验结果如图5所示。

[0074] 图5(a)为同一个pod内的所有服务器随机选择其他pod内某台服务器作为接收端且每台服务器与接收端建立10条TCP链接。实验结果显示，当pod数小于8时，无论各协议是否结合AP，它们获得非常相近的结果。当pod数大于8时，网络拥塞变得更加严重，结合AP后的各协议比原始协议获得更好的网络性能。

[0075] 图5(b)为Fat-tree拓扑中的pod数固定为8，变化每台服务器与接收端建立的TCP链接数。其它实验参数和场景设置与图5(a)相同。实验结果显示，随着每台服务器发送流数的增加，各协议无论是否结合AP，其平均逐渐增加。当每台服务器发送的流数大于8时，结合AP后的各协议比原始协议获得更好的网络性能。

[0076] 2、测试床下的性能提升度

[0077] 为进一步验证本发明的有效性，我们在测试床环境中对两个典型的应用(即网页搜索和MapReduce应用)进行测试。在该次测试中，使用的实验拓扑和图2(a)所示的Incast场景示意图一致。服务器的配置如下：CPU型号为Intel Pentium G645 2.90GHz；内存为4GB；硬盘容量为500GB；网卡速率为1GBps。所有服务器都安装了CentOS6.5的操作系统，其Linux内核版本为2.6.38。此外，所有服务器都安装了本发明的补丁。实验参数设置如下：交换机缓存为100个包；交换机进行ECN标记的阈值为65个包；限制交换机的出口速率为
200Mbps；包大小为1500bytes；往返时间RTT为300us；最小超时重传时间RTOmin为200ms。

[0078] 图6给出了不同协议在Map-Reduce应用模式下面的测试结果。在实验过程中，我们逐渐增加流数，最终流数高达90。图6(a)和图6(b)中交换机的缓存大小固定为64KB，它们的服务器请求单元分别为64KB和128KB。实验结果显示，各协议结合AP后都没有发生超时且获得了很高的吞吐率，而原始协议发生了超时导致吞吐率坍塌。此外，服务请求单元越大，所获得的吞吐率越高。这是因为服务请求单元越大，各发送端所需的传输时间就越多。尽管有一些流发生超时，但未超时的流可充分利用可用的带宽资源，减少链路的空闲时间从而增加吞吐率，图6(c)和图6(d)中服务请求单元的大小固定为32KB，它们的交换机的缓存大小分别为32KB和128KB。实验结果显示，各协议结合AP后都没有发生超时且获得了很高的吞吐率，而原始协议发生了超时导致吞吐率坍塌。此外，交换机的缓存越大，所支持的并发度越多。这是因为缓存越大，能够存储越多的分组，减少丢包和超时。然而，在数据中心网络中部署大缓存的交换机会增加成本。相反，尽管交换机的缓存较小，但是各协议结合AP后都能获得很好的网络性能。

[0079] 图7给出了不同协议在网页搜索应用模式下面的测试结果。在实验过程中，我们逐渐增加流数，最终流数高达90。在实验过程中，所有流发送的总数据量固定为1M。也就是说，每条流的服务请求单元大小为1024/n，其中n为流的数量。图7(a)测量了各协议是否结合AP的搜索响应时间。实验结果显示，TCP NewReno和DCTCP协议首次发生超时的流数分别为12和28。这些协议超时后，它们的搜索相应时间都超过200ms。幸运的是，各协议结合AP方法后没有发生超时，使得它们获得较小的搜索响应时间(大约为50ms)。图7(b)测量了各协议的超时率。实验结果显示，当流数超过12时，TCP NewReno会遭受至少一次超时，而DCTCP是在流数达到28时开始发生超时。然而，各协议结合AP方法后没有发生超时。简言之，本发明在网页搜索应用中所获得的性能指标优于其它方法。