一种数据中心网络中基于任务感知的传输控制方法与流程

本发明涉及一种数据中心网络中基于任务感知的传输控制方法。

背景技术：

在现代数据中心中，普遍使用基于树形的分治算法来下发数据或者计算到数以千记的服务器中去，在每台服务器计算或者处理完毕之后，会把结果传输到聚合机(Aggregator)进行组合和处理，聚合机处理完成之后才能把最终的结果返回给用户。这样的并行处理做法可以很大程度上的提高运行效率，降低用户请求的等待时间，改善和提高用户体验。但是很明显，如果某些服务器对下发的工作处理很慢，这样聚合机就必须等待到所有的数据到达之后才能开始工作，从而导致用户的等待时间加长。这被称为掉队者现象。最近的研究已经表明，在使用了新的硬件技术的数据中心内，网络延时已经占据了85％的端到端应用延时。因此，很多现有的研究都在努力减少网络延时(即拖尾流)，以求达到更好的用户体验。总体来说目前的方法可以分为两大类：基于流的和基于任务的网络传输控制方法。

基于流的网络传输控制方法由于操作和逻辑相对简单，实现和部署起来比较容易，响应也比较迅速。这些方法或者优化和提高流完成时间(例如DCTCP、L²DCT和pFabric)，或者减少截止期限缺失率(例如D2TCP和D3)。但是由于它们都只专注于优化流级别的性能而忽略了一个事实：其实一次用户请求，或者说是任务，是由成百上千条流组成的，任何一条流没有完成，则这次任务就没有完成，也就是说拖尾流决定了这个任务的最终完成时间。因此，这些基于流的机制都不可避免的在不同程度上降低了数据中心所提供的应用的性能。下面的一个例子则可以很好的说明这个问题。最短流优先调度算法会选择调度任务中的最短流，即使这些流分属于不同的任务。这样做可以很好的降低平均流完成时间(Average flow completion time)。而在应用和任务的层面上看，平均任务完成时间则升高了(Average task completion time)，因为在任务完成过程中，不断的有别的任务的流的来阻断自己的传输。这样加大了任务的完成时间，从而影响了用户的体验。

相比基于流的传输控制方法，基于任务的传输控制方法可以减少任务的完成时间，也就减少了用户的等待时间。这些基于任务的传输控制方法总体来看可以分为两个大类：一个是基于分布式架构的，另一个则是中心控制器架构的。分布式架构的控制方法，例如Baraat，通过下发调度策略到不同的交换机上面，成功的避免了交换机与中心控制器的计算和通信开销。但是由于计算机基于本地任务信息来决定调度顺序，而缺乏所调度的任务的全局信息。这样会导致存在一种情况：即选中的任务的流，一部分会在某些交换机上成功调度，但是其它部分则会在某些交换机被阻塞，这样仍然不能降低任务的完成时间。而基于中心控制器架构的方法，例如Varys和Rapier，需要一个复杂的系统来收集任务的全局信息，进行调度决策，以及保证决策的正确执行。这个系统包括了中心调度器和安装在网络节点(例如服务器)上的中间件。虽然它们很接近最优调度结果，但是这些方法的计算复杂度和控制开销会随着网络规模的扩大而迅速的上升。在数据中心中，接近80％的流都是10KB到100KB的小流。这些只有10KB的小流在某些方法中，甚至可以在一个往返延时(Round trip time)中就可以完成。而如果这些小流还需要花费额外的一个RTT甚至更久的时间来等待中心调度器的调度决策，它们的完成时间则至少增加了100％。

可见，数据中心网络中，现有的传输控制方法，或者使用了庞大的系统来保证精准的控制，但是增大了计算开销和传输延迟，同时由于对现有的数据中心网络改动较大，失去了普适性；或者使用了灵活的部署和简单的机制来保证快速响应，但是结果也往往不准确，没有办法减少任务完成时间以及用户的等待时间。因此，如何设计一个轻量级的、有效的、可兼容的基于任务的数据中心网络传输控制方法，在减少任务完成时间的同时，也不增加计算和传输开销，从而减少用户的等待时间，是一个亟待解决的问题。

技术实现要素：

为了解决上述数据中心网络中传输控制方法存在的准确性以及快速响应和庞大系统以及灵活部署这两对矛盾，本发明提供了一种数据中心网络中基于任务感知的传输控制方法。该方法基于传统传输层，普遍适用的以任务为单位进行传输控制，通过接收端驱动的协调机制，来实现了流拖尾信息的共享，在保证控制准确度的同时，也由于使用了传统TCP协议栈的功能，实现了灵活部署以及较低的开销。

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

基于支持ECN的交换机或者路由器、接收端和发送端；

一种数据中心网络中基于任务感知的传输控制方法，包括以下步骤：

步骤1：发送端在传输层的报文头部中增加任务信息和流信息字段，包括任务ID字段和流大小字段，并将报文发送给路由器或者交换机；

步骤2：路由器或者交换机根据网络负载信息决定是否给发送端报文打上ECN标记用于显示网络负载信息，然后将报文转发给接收端；

步骤3：接收端根据接收到的报文头部携带的信息，更新任务表相关信息，并计算出任务预期完成时间T_t，并且通过返回给发送端的ACK报文的头部捎带回去该任务预期完成时间T_t以及路由器或者交换机加入的网络负载信息；

步骤4：发送端接收接收端返回的ACK报文；

步骤5：发送端根据接收端返回的ACK报文，解析出任务预期完成时间和网络负载信息，并且通过任务预期完成时间和其所发送的流的预期完成时间来算出拖尾度因子ω；

步骤6：发送端根据拖尾度因子和网络负载信息调整自身拥塞窗口(发送速率)，使之适应当前的网络拥塞状态，并通过对拥塞窗口不同程度的改变，调整流的预期完成时间与任务预期完成时间之间的差距。

所述步骤3中，接收端维持一个任务表，任务表记录以下信息：任务ID、任务中的每条流的流ID、每条流对应的流大小以及流的已接收的字节数；任务ID用于标识流所属的任务，即一个任务可能由多条流组成，它们共享一个相同的任务ID，它是数据中心边界服务器在收到相应用户请求时随机生成并且下发的；流ID通过TCP/IP协议的本身的五元组得到，用于区分不同的流，以便接收端更新任务表中对应流的表项；每条流的流大小字段的数值为应用层的具体应用所要传输的数据量，即数据的字节数，该值在应用准备发送数据时已经确定，无需更新；每条流的已接收的字节数，则在传输层协议自带的序列号字段的基础上，通过每条流的当前序列号与建立连接时最初的序列号的差值计算得出；流的已接收的字节数会随着流已接收的序列号的增加而增加；

所述步骤3中，任务表的更新流程为：接收端根据接收报文头部的任务ID字段，查找任务表；若任务表中不存在该任务ID，则在表中插入一个新表项，其值为该任务ID、该任务中的流ID、对应的流大小和流的已接收字节数；若任务表中存在该任务ID，则进一步比对该任务ID对应的表项中是否存在接收报文头部的流ID；若不存在该流ID，则新建一个表项并且写入该任务ID、流ID、对应的流大小和流的已接收字节数；若存在该流ID，则更新对应的流大小和流的已接收字节数；

所述步骤3中，任务预期完成时间T_t＝(任务大小-任务已接收字节数)/历史接收速率；其中任务大小通过累加该任务ID下每条流的流大小得到；任务已接收字节数通过累加该任务ID下每条流的已接收字节数得到；历史接收速率则通过任务已接收字节数比上花费的时间得出。

所述步骤5中，拖尾度因子ω计算方法如下：

$\mathrm{\ω}=\frac{T_f}{T_t}$

其中，T_f为发送端所发送的流的预期完成时间，该值等于流的剩余字节数比上当前的发送速率(T_f由发送端计算得到)。

所述步骤6分为两种情况：

1)当接收端收到没有打上ECN标记的ACK报文时，首先根据以下公式计算拥塞窗口的增窗因子k：

$k=\frac{\mathrm{\ω}}{{\mathrm{\ω}}_{max}}(1-\mathrm{\α})$

上式中，ω_max为拖尾度因子的最大值，通过实验验证得到(经验值为2.25)；α为链路的拥塞程度，该值的计算方式为一次往返延时时间内发送的所有数据包(所有数据包的个数为拥塞窗口大小)中，被交换机打了ECN标记的数据包的比例，其取值范围介于0到1之间，越大则说明网络越拥塞；

然后，根据增窗因子k计算新的拥塞窗口，其计算公式如下：

${\mathrm{cwnd}}_{i+1}={\mathrm{cwnd}}_i+{\mathrm{cwnd}}_i^k$

其中，cwnd_i+1为下一轮拥塞窗口的数值，cwnd_i为当前拥塞窗口数值；当增窗因子较高时，本方法采用乘性增长(MI)算法计算拥塞窗口，其具体表现为，当链路没有拥塞(α＝0)，且拖尾度较高(ω＝ω_max)时，增窗因子k的值为1，那么通过上述公式，下一轮拥塞窗口数值为cwnd_i+1＝2cwnd_i；否则，当增窗因子较低时，采用加性增长(AI)计算拥塞窗口，其具体表现为，当链路拥塞最大(α＝1)，或是拖尾度较低(ω→0)时，增窗因子k的数值为0，那么通过上述公式，下一轮拥塞窗口数值为cwnd_i+1＝cwnd_i+1；

2)当接收端收到打了ECN标记的ACK报文时，首先根据以下公式计算拥塞窗口的减窗因子β：

β＝α^ω；

然后根据减窗因子β计算新的拥塞窗口，其计算公式如下：

${\mathrm{cwnx}}_{+1}={\mathrm{cwnd}}_i\×(1-\frac{\mathrm{\β}}{2}).$

在步骤4与步骤5之间还存在以下步骤：发送端判断计时器是否超时，以及是否收到三个重复的ACK报文；若计时器超时或收到三个重复的ACK报文，则传统的拥塞控制方法进行传输控制；若计时器没有超时，且未收到三个重复的ACK报文，则进入步骤5。

所述步骤2具体为：交换机或者路由器根据队列长度是否超过预设的阈值决定是否给发送端报文打上ECN标记；若超过则打上ECN标记然后将报文转发给接收端，若没有超过则直接转发。

本发明中，通信过程的发送端通过显式反馈信息计算网络当前可用带宽，并且根据它以及所发送的流的拖尾度来调整发送速率，路由器通过分组头ECN信息反馈网络负载，接收端回显该ECN信息并且计算任务预期完成时间；发送端通过接收端在ACK中捎带的任务预期完成时间以及自己计算的流预期完成时间，计算出拖尾度，并且和显式反馈信息一起作为调整发送速率的依据。本发明通过结合端到端任务信息和网络拥塞信息反馈，从而避免了额外的控制开销、减少了部署的难度、提高协议普及性的同时保证了较低的任务完成时间和较高的吞吐率，因此，减少了用户发送请求之后的等待时间。

有益效果：

本发明通过支持ECN的交换机或者路由器，以及接收端的任务信息统计和反馈，接收端可以得到任务的全局信息和链路上的拥塞信息。这样在极少的改动网络现有的架构的情况下，任务中的每条流就可以更加准确的知道自己在所属的任务中的完成进度情况(包括是否拖尾，是否领先)，并且发送端可以根据当前的链路状况和这条流的拖尾程度动态的调节它的发送速率。当拖尾程度较重的时候，发送端会根据链路的拥塞情况使拥塞窗口的增加在乘性增长(MI，拥塞较轻的时候)和加性增长(AI，拥塞较重的时候)之间变化；而拖尾程度较重的流，即使在减窗的时候，发送端也会根据它的权重和链路拥塞状况来使窗口减少得较少。反之，若流的拖尾程度较轻，则不论链路的拥塞情况怎么样，发送端都会使这条流的窗口增长限制在加性增长附近，而减窗则会接近原本窗口的1/2。但是值得注意的是，若链路的拥塞很严重(α＝1)，则无论流的拖尾度为多少，所有流都要按照加性增长增窗(cwnd_i+1＝cwnd_i+1)，且减窗也要按照传统传输层一样，减去1/2的窗口虽然其效果已经退化为传统的拥塞控制方法，但是因为本方法在某轮发送返回的被ECN标记比例为100％(即α＝1)的时候采取这样操作，而传统拥塞控制算法只有当队列满了丢包之后(对于发送端，重复ACK即为发生丢包)才会有这样的操作，所以本发明操作时间一般要早于传统拥塞控制方法，从而减少了拥塞的时间。这样做是为了在高链路负载的情况下实现公平性，也是为了能够更快的减轻拥塞状况。简而言之，这些操作的目的是为了实现拖尾程度高的流能够加速自己的发送速率，积极的抢占带宽，来减少它的完成时间，同时也就减少了任务的完成时间，因为任务的完成时间是由拖尾程度最高的那些流决定的。而拖尾程度较低的流，由于自己本身的流完成时间并不决定任务的完成时间，即使自己提前完成了，任务还是需要等待剩下的流完成才能结束。这样之前所利用的带宽可以说是白白浪费了。所以这些流可以适当的降低自己的发送速率，从而把带宽让给那些需要提速的拖尾程度较重的流。这样通过这些不同拖尾程度的流之间的抢带宽和让带宽，从而达到更好地、更合理地带宽方式，来减少任务的完成时间，也就最终减少了用户的等待时间。

附图说明

图1为本发明的流程图；图1(a)、图1(b)、图1(c)分别为发送端、交换机或路由器、接收端的处理流程图。

图2为本发明的测试床环境。

图3为本发明的模拟测试环境。

图4为本发明在测试床环境中，不同方法的吞吐率变化图，其中本发明命名为TaTCP。图4(a)为DCTCP的吞吐率变化图，图4(b)为L²DCT的吞吐率变化图，图4(c)为TaTCP的吞吐率变化图。

图5为本发明在测试床环境中，随着网络中任务的个数的增加，对于其他方法的任务完成时间的提升度。其中本发明命名为TaTCP。

图6为本发明和其他方法在模拟实验测试环境中，模拟网页查询应用模式下的不同测试指标的结果图，其中本发明命名为TaTCP。图6(a)为不同方法随着任务中流个数增加，平均任务完成时间变化图；图6(b)为不同方法随着任务中流个数增加超时率变化图。

图7为本发明在模拟实验测试环境中，模拟云存储应用模式下，相对其他方法在任务完成时间的提升度。其中本发明命名为TaTCP。图7(a)为本发明相对于DCTCP的提升比例、图7(b)为本发明相对于L²DCT的提升比例、图7(c)为本发明相对于Baraat的提升比例。

图8为本发明和其他方法在模拟实验测试环境中，模拟Map-Reduce应用模式下的不同测试指标的结果图，其中本发明命名为TaTCP。图8(a)为不同方法随着任务中流个数的增加，平均任务完成时间变化图；图8(b)为不同方法随着任务中流个数增加，有效吞吐率变化图。

具体实施方式

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

参见图1(a)(b)(c)，它们为本发明的流程图，分别描述了本发明所涉及的三个部分的处理过程。其过程如下：在连接建立后，发送端在每次发送之间判断是否数据已经发送完毕。若发送完毕则结束；若没有发送完毕，则会在发送的传输层报文头部加入任务信息和流信息(包括任务ID和流大小，以便接收端计算任务的预期完成时间)。发送端所发送的数据报文，在经过交换机或者路由器的时候，该设备会根据队列长度是否超过预设的阈值来对发送端的报文进行标记。若超过则进行标记ECN位然后转发，若没有超过则直接转发。接收端在收到报文之后，会根据发送端在报文头部加入的任务信息更新任务记录，并且重新计算任务预期完成时间。在接收端生成ACK报文的时候，接收端会把该任务预期完成时间写入ACK报文头部，并且同时根据收到报文标记ECN位。发送端在收到ACK报文的时候，根据ACK报文头部的任务预期完成时间和流自己的预期完成时间计算出拖尾程度。并且发送端会根据拖尾程度、ECN位和拥塞程度来计算下一轮拥塞窗口的大小。

本发明中采用拖尾程度来调节该方法的增窗因子和减窗因子。通过增窗和减窗因子，发送端可以实时的调节流的发送速率。具体地，如果发送端收到的ACK报文没有标记ECN位，则在下一轮发送端的窗口可以增长为如下的数值：

${\mathrm{cwnd}}_{i+1}={\mathrm{cwnd}}_i+{\mathrm{cwnd}}_i^k$

其中cwnd_i+1为下一轮拥塞窗口的数值，cwnd_i为当前拥塞窗口数值。k则为增窗因子。当增窗因子较高时，即链路拥塞度较低且流的拖尾度较高，此时本方法采用乘性增长(MI)算法计算拥塞窗口；否则，采用加性增长(AI)计算拥塞窗口。而若收到了带有ECN标记的ACK报文，发送端则需要根据减窗因子进行减窗操作，从而避免拥塞继续加重，其计算方式如下：

${\mathrm{cwnd}}_{i+1}={\mathrm{cwnd}}_i\×(1-\frac{\mathrm{\β}}{2})$

其中，cwnd_i+1下一轮拥塞窗口的数值，cwnd_i为当前拥塞窗口数值。β则为减窗因子。可以看到，当减窗因子较小时，下一轮拥塞窗口减少的较少。反之当减窗因子较大时，下一轮拥塞窗口的值则变得较小。但是，由于β的值最大只为1，因此，在链路拥塞很重，或者流的拖尾度较轻的时候，拥塞窗口会减半，这样不仅可以在链路拥塞严重时候各条流之间实现公平共享带宽，也可以每条流都可以快速的退避以减少链路拥塞的时间。

综上所述，采用本发明方法可以在不改变网络现有拓扑结构的同时，把传输控制的单元由流变为了任务，从而成功避免了基于流传输控制方法中拖尾流对任务完成时间的影响，大幅减少了任务完成时间和用户等待时间。

利用NS2.35网络仿真平台，和真实的测试床对其性能进行了测试。NS网络模拟器是一种通用的多协议网络模拟软件，它是互联网上公开发布的(网址：http://www.isi.edu/nsnam/ns)，目前已被网络研究者广泛使用。NS2.35是它的版本之一。

我们分别采用图2和图3两种拓扑结构，在测试床和模拟测试两种不同的测试环境下面测试本发明的性能。在如图2所示的拓扑中，从架顶交换机(ToR Switch)开启ECN功能，且设置到接收端的两条瓶颈链路带宽为600Mbps，其他链路的带宽为1Gbps。没有排队延迟的逐跳往返延时为100微妙且报文大小和和超时时间分别设置为1.5KB和200毫秒。所有机器运行加载了本发明补丁的CentOS 6.5操作系统。而如图3所示的拓扑中，整个拓扑使用的是一个树形结构。并且发送端到架顶交换机和架顶交换机到汇聚交换机的链路带宽都为1Gbps，而汇聚交换机到接收端的链路带宽为4Gbps。交换机的缓存大小设置为250个报文大小，并且ECN标记阈值为65个报文大小。

1、有效性验证

该实验验证了本发明在TCP协议栈内工作的有效性。f_A1、f_A2和f_B分别为发送端3、发送端1和发送端2发送的相同大小的流。由于发送端1和发送端2在共享一条出口带宽，所以同属于同一个任务A的流f_A2会逐步的落后于f_A1，从而变成拖尾流。在图4(a)和图4(b)中可以看到由于DCTCP和L²DCT都是基于流的传输控制方法，因此不能够加快拖尾流f_A2。而在图4(c)中，本发明(TaTCP)通过接收端的任务信息反馈，流f_A2发现自己是拖尾流。接下来它的数据发送速率就会逐步加快，以追赶领先流f_A1。这样任务A的完成时间就会减少。通过减少任务A的完成时间，任务A和B的平均任务完成时间相比于DCTCP和L²DCT下降了近15％。从本实验结果来看，本发明对现有的TCP协议栈的修改很好的实现了预计目标，减少了任务的平均完成时间。

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

该实验测试本发明在较高网络负载情况下的性能。该实验仍然使用了测试床环境来进行测试。在该次测试中，存在两种任务存在于网络中。第一种任务由两条流组成，由发送端1或者发送端3发送并且分别经过两个不同的交换机，通过两条不同的瓶颈链路到达接收端。另一种任务由单条流组成，且通过发送端2发往接收端。每条流的大小相同，且所有流都是同时发送。本实验逐步增加第一种任务的个数，由原本的1条增加8条。第二种任务保持为一条不变。从图5可以看到，随着网络中任务的个数增加，也就是网络负载逐步变重，相比较于其他数据中心常见的传输控制协议，本发明仍然能够减少最多14％，最低6％的平均任务完成时间。

3、模拟实验测试环境测试结果

除了以上给出的测试床的局部性能测试，为了全面比较该发明的高效性，我们进一步测试了在复杂拓扑结构情况下，该发明的各项性能指标，包括了：平均任务完成时间，超时率和有效吞吐率。实验场景包括了网页查询、云存储和Map-Reduce这些不同的应用场景。测试的传输控制机制包括了：DCTCP、L²DCT、TaTCP和Baraat。其中DCTCP和L²DCT是基于流的传输控制方法，TaTCP(本发明)和Baraat只是基于任务的传输控制方法。

(1)图6给出了不同机制在网页查询应用模式下的测试结果。在该测试中，一共有40个任务，每个任务由i条流组成，任务的总大小为2MB保持不变，任务中流大小为2MB/i。在实验过程中，任务中流的个数i由8逐步增加到40。图6分别统计了不同流个数下任务的平均完成时间和超时率。从图6(a)中可以看到，本发明一直都具有最小的平均任务完成时间。并且在任务中流个数为28之前都低于100毫秒，远远低于其他方法。图6(b)汇总了40条任务中，经历过至少一次超时的任务所占的比例。图中所示，TaTCP至少在22条流才开始超时，明显大于其他机制的15或16条流。可见本发明在网页查询模拟测试环境下，性能指标要明显优于其它方法。

(2)图7给出了不同机制在云储存应用模式下的测试结果。在该测试中每个任务中的流个数保持不变，但是每条流的大小服从10KB到4MB的帕累托分布。在实验过程中，任务的个数由20逐步的增加到50。如图7(a)和(b)所示，在轻网络负载的时候，本发明TaTCP可以保持相对于基于流的传输控制机制(DCTCP和L²DCT)20％以上的提升度。即使网络负载变重，TaTCP也能保持近10％的优势。虽然对于Baraat这种基于任务的传输控制性能提升没有相比于基于流的那么大，但是也能够最少提升了5％的平均任务完成时间。

(3)图8给出了不同机制在Map-Reduce应用模式下面的测试结果。在该测试中，一共有40个任务，每个任务中得流所发送的字节数都相等且为32KB。在实验过程中，任务中得流个数由8条逐步增加到40条。图8分别统计了不同流个数下任务平均完成时间和任务的平均有效吞吐率。从图8(a)可以看到，本发明TaTCP的平均任务完成时间直到29条流才开始增加，而基于流的传输控制协议在20左右就已经开始增长了。虽然Baraat由于本身的基于任务的机制使得他得性能优于上述两种协议，但是也只能支持到24条流。同样，在图8(b)中，TaTCP也取得了最高的平均有效吞吐率，性能优于其他三种不同的方法。

从以上实验数据看来，本发明方法在以上几个方面具有比其他方法更优秀的性能。这是因为本方法使用了基于任务的拥塞控制方法，从而成功避免了基于流的方法所忽视掉的拖尾问题。而由于本发明具有链路全局信息，相比于只能知道交换机本地任务信息的Baraat能够能加合理的利用带宽，从而达到更优秀的性能，成功的减少了任务的平均完成时间。并且该方法对现有的网络架构修改较少，可以很轻易的部署到现有的网络中，保证了本发明的普及型。