APP下载

基于数据流特性的MPTCP数据流调度算法研究

2018-08-08叶宁董苹苹段桂华王建新

关键词:条子数据流时延

叶宁,董苹苹,段桂华,王建新



基于数据流特性的MPTCP数据流调度算法研究

叶宁1,董苹苹2,段桂华1,王建新1

(1. 中南大学 信息科学与工程学院,湖南 长沙,410083;2. 湖南师范大学 计算机教学部,湖南 长沙,410081 )

基于广域网中使用MPTCP协议进行数据传输时,由于短流的传输数据量小,每条子流的拥塞窗口在其生命周期内保持很小的状态,这使得1个数据包的丢失也可能导致超时现象发生,从而增大数据流的完成时间,为此,提出一种根据MPTCP数据流特性进行MPTCP数据流调度的算法MPTCP-FSFSm(multi-path TCP flow scheduling based on flow size)。首先,MPTCP-FSFS算法根据MPTCP数据流需要发送的数据量将MPTCP数据流分类;然后,发送端根据当前每条路径往返时延进行MPTCP数据流调度:对于短流,选择往返时延最小的若干条路径进行数据流传输;对于长流,使用所有的路径进行数据流传输。研究结果表明:与MPTCP相比,MPTCP-FSFS在保证长流吞吐率的基础上,能够明显降低短流的数据流完成时间,同时提高数据流平均吞吐率。

MPTCP;数据流特性;路径往返时延;数据流调度

随着互联网的迅速发展,互联网上传输的数据量越来越多。据文献[1],网络中99%的数据流小于 100 MB,但90%的数据流量由100 MB到1 GB之间的数据流提供,呈现短流数目多但是传输的数据量小的特性。实时分析[2−3]和在线交互式应用如网页搜索和查询业务、各种社交网站和在线零售业务等,经常产生大量短流,考虑到用户体验感,短流的完成时间要尽可能小,即短流对于数据流完成时间(flow completion time, FCT)敏感。然而,网络中传输的大量数据由长流提供,长流对于吞吐率(throughput)的要求高。当所有流使用TCP 协议时,如果短流与长流竞争,由于队列堆积,会导致短流完成时间长,同时长流不能将拥塞转移,导致吞吐率低且网络的利用率低。另外,在当前互联网中,具有多条并行接入通道的多宿主主机越来越多,多宿主主机配置多块网卡,因此,多宿主主机之间可以建立多条可用路径。为了充分利用多条路径的发送能力并且最大化资源使用率,IETF(Internet Engineering Task Force Internet,互联网工程任务组)提出了MPTCP(multi-path TCP)[4−5]。在完全兼容传统TCP的基础上,MPTCP 能同时利用多个网络接口建立多条子流进行数据传输[6],提升网络吞吐率。KHEIRKHAH等[7]发现在MPTCP协议中,使用多条子流进行长流数据传输,可以提高长流的吞吐率,但传输短流时数据流完成时间长。为了减少短流的完成时间,同时保证长流的吞吐率,国内外学者研究与设计了相关的MPTCP数据流调度算法,如SARWAR等[8−12]对MPTCP数据流数据调度进行了改进,但都是针对单条MPTCP数据流内部数据的调度算法。KHEIRKHAH等[7]提出了一种算法MMPTCP,对于所有的数据流,初始时使用Packet Scatter协议进行数据传输,当传输数据量达到100 KB时,若数据流依旧有数据发送,则将该数据流当作长流,并进行传输协议切换,使用MPTCP协议进行数据传输。MMPTCP与MPTCP相比减少了短流的数据流完成时间,但传输长流时需要进行协议转换。WANG等[13]对路径进行划分,短流路径只传输短流,长流路径只传输长流,路径可根据长、短流的数目变化动态调节,但对于长流没有考虑负载均衡,多条长流可能调度到同一路径导致长流吞吐率低。针对这些问题,本文作者提出一种基于传输的数据流特性进行数据流调度的算法MPTCP-FSFS(multi-path TCP flow scheduling based on flow size),发送端根据每条数据流需发送的数据量将数据流进行分类,根据数据流所属类别选择路径对数据流进行调度,并通过NS3[14−15]网络模拟平台进行仿真。

1 问题分析

网络中存在大量对延时敏感的实时交互式应用,如网页浏览、各种社交平台和在线购物等,这些应用经常产生大量的短流。短流的特点是传输的数据量小,对数据流完成时间敏感。然而,网络中传输的大部分流量都是由长流产生的,长流对吞吐率要求高。同时,网络设备配置多块网卡已经越来越普遍化,多宿主主机之间可以建立多条可达路径进行数据传输,硬件上支持MPTCP协议的部署。

1.1 TCP协议

在长流与短流共存的网络中,当所有的数据流均使用TCP协议时,每条数据流选择1条可达路径进行TCP连接传输数据。对于长流,每条长流只占据1条链路建立TCP连接并且传输所有数据,当某条长流传输路径出现拥塞时,即使其余路径空闲,该长流也无法使用空闲路径的发送能力,导致长流的吞吐率下降,同时网络的利用率低。对于短流,由于长流占据大量的带宽使得使用该路径传输的短流排队延时增大,此外,当多条数据流同时调度到同一条可达路径进行数据传输时,交换机或者路由器缓存会溢出,出现丢包,使得TCP流出现重传或者超时现象[16−17],导致短流的数据流完成时间增大。

1.2 MPTCP协议

针对TCP协议对多网卡设备的利用率不足的问题,IETF提出了MPTCP (multi-path TCP)。MPTCP协议是对TCP协议的扩展,可以通过多个网络接口为1条数据流建立多条子流连接,每条子流有自己独立的拥塞控制窗口,从而提高网络吞吐率。RAICIU等[18]通过研究发现MPTCP协议对长流是有利的,但传输短流时短流的完成时间长。图1所示为发送端通过5条路径并发30条MPTCP数据流传输到接收端时的实验结果,每条路径初始往返时延为20 ms,带宽为 100 MB/s,丢包率为0.2%,每条路径存在1条TCP背景长流。其中,图1(a)所示为实验测试发送30条80 KB的TCP数据流时,数据流使用不同路径数目时短流的平均完成时间。由图1(a)可见:短流的平均数据流完成时间随着路径数目增大而增大,即使用MPTCP协议传输短流时效果比使用TCP协议传输短流的效果差。图1(b)所示为并发30条5 MB的数据流时的吞吐率期望值,可见长流的吞吐率随着路径数目增大而增大。

(a) 短流平均完成时间;(b) 长流吞吐率期望值

MPTCP可以提升长流的吞吐量,但传输短流效果差,其原因在于:对于长流,数据流使用MPTCP协议可以为1条数据流建立多条子流进行数据传输,提高了吞吐率;对于短流,由于传输的数据量少,使用MPTCP协议传输短流时,在该数据流生命周期内,每条子流的拥塞控制窗口都保持在一个很小的状态,当子流发生丢包时,很容易出现超时现象[7](因为不能收到3个重复ACK数据包,导致不能进入快速重传阶段),使得短流的数据流完成时间大大增多。

综上所述,在多宿主主机之间进行数据流传输时,使用TCP协议进行数据传输或者使用MPTCP协议建立多条子流进行数据传输都存在不足之处。TCP协议对于短流传输是有利的,但传输长流时吞吐率低并且链路利用率低。使用MPTCP协议传输长流时优势明显,但传输短流平均完成时间长。因此,本文结合TCP协议对于传输短流的优势以及MPTCP协议对于传输长流的优势,设计基于数据流特性的MPTCP数据流调度算法MPTCP-FSFS。

2 算法设计

MPTCP-FSFS算法是基于MPTCP协议的,所有的数据流都使用MPTCP协议作为传输层协议。文中,使用的符号及含义见表1。

表1 符号含义

2.1 MPTCP-FSFS

MPTCP-FSFS的核心思想是:根据MPTCP数据流需发送的数据量决定该数据流使用的路径以及建立的子流数目,短流使用往返时延最小的若干条路径建立子流进行数据传输,长流使用所有路径建立子流进行数据传输。

首先,根据数据流需要发送的数据量将数据流分为4类,分类方法如表2所示。

表2 数据流分类

MPTCP-FSFS调度算法的思想是:使用TCP协议传输短流时的数据流完成时间比使用MPTCP协议传输短流时数据流完成时间少,但MPTCP协议在传输长流时长流的吞吐率比使用TCP协议时要高,根据数据流传输数据量不同,决定数据流调度的路径,这样就可以充分利用TCP对于传输短流的优势和MPTCP对于传输长流的优势。

首先,对于每条数据流,根据数据流传输数据量进行分类。如表3所示,每条数据流根据传输数据量所属的区间分在不同的类别,在MPTCP-FSFS算法中将数据流分为4类。

表3 数据流分类算法

表4 MPTCP-FSFS调度算法

然后,根据数据流所属的类别进行路径选择,MPTCP-FSFS调度算法将属于0,1和2的数据流都当作短流,将属于3的数据流当作长流。对于短流,总是选取当前所有路径中往返时延最小的1条或多条路径进行数据传输,这样从理论上可以实现短流平均完成时间最小。对于长流,使用所有可用路径进行数据流传输,每条数据流建立多条子流进行数据传输,提高长流的吞吐率。

2.2 数据流分类

数据流分类方法见表2。在广域网中,传输的数据流量近似呈帕累托分布,即传输数据量小的数据流占据总数据流的绝大多数,但传输的数据量大部分由长流提供。从图1(a)可知:当传输数据量小于100 KB时,使用1条路径传输数据流相比于使用多条路径建立多条子流传输的数据流完成时间更小。这是由于数据流传输的数据量小,使用多条路径建立多条子流进行数据传输时每条子流的拥塞窗口在生命周期内保持在很小的状态,即使出现1个数据包丢失也可能会导致超时现象发生,从而导致数据流完成时间长。因此,本文将传输数据量在(0,100) KB区间的数据流划分到类别0中。随着数据流传输数据量增大,使用MPTCP协议建立多条子流进行数据流传输的优势显现。本文将在(100,300) KB区间的数据流划分到类别1中,将在(300,800) KB区间的数据流划分到类别2中。将数据流需传输的数据量大于800 KB的数据流当作长流,划分到类别3中。

2.3 数据流调度

对于每条数据流,根据传输数据量将数据流分为4类。对属于每个类别的数据流,根据传输的数据量不同,选择合适的路径进行数据流调度。

根据图1(a),由于使用1条子流进行数据流传输时,数据流平均完成时间比使用多条路径建立多条子流进行数据流传输时完成时间要小,所以,对于1条数据流,当该数据流属于0时,使用当前所有路径中往返时延最小的路径进行数据传输,这样,可以实现使用最短的时间完成时间敏感的短流传输。对于属于1的数据流,本文使用往返时延最小的2条路径进行数据流传输。对于属于2的数据流,使用往返时延最小的3条路径进行数据流传输。对于属于3的数据流,本文将该类型数据流当作是长流,从图1(b)可知:MPTCP对于长流而言是有利的,可以大大提高长流的吞吐率。所以,对于长流,使用所有的路径建立子流进行数据传输。

3 性能评估

实验基于NS3网络模拟平台实现,性能评价指标包括短流的数据流完成时间(flow completion time, FCT)、长流平均吞吐率(mean throughput)和数据流平均吞吐率 (mean throughput)。

3.1 实验设计

实验设置发送端与接收端之间建立条路径,在[5,20]的范围内变化;路径带宽设置为100 MB/s,往返时延在[20,200] ms范围内变化[19],路由器设置丢包策略为Droptail[20]。MPTCP协议的拥塞控制算法设置为RTT_compensator[21]。设置MPTCP数据流缓冲为

式中:B为第条路径的带宽;max为所有路径中最大的路径往返时延。每条路径分别引入5条FTP长 流[22],其余协议参数均按照NS3的默认值进行设置。所有实验仿真运行时间至少为100 s,忽略仿真时间前5 s的统计数据。

为了模拟真实的广域网环境,发送的数据流分布根据文献[23]中方法生成。设置网络中总的数据流到达速率服从泊松分布,平均到达速率从50条/s变化到2 000条/s,该设置符合真实的网络流量模型。

本实验将需传输数据量小于等于800 KB的数据流当作短流,以数据流完成时间(FCT)作为性能测试指标;将需传输数据量大于800 KB的数据流当作长流,以数据流吞吐率(throughput)作为性能测试指标。

在实验结果图中,MPTCP-FSFS表示数据流使用MPTCP-FSFS调度算法时的实验结果,MPTCP表示使用MPTCP协议并利用条路径建立多条子流时的实验结果,TCP表示所有数据流使用TCP协议时的实验结果。

3.2 数据流到达速率的变化

本组实验在发送端与接收端之间建立10条可达路径时,网络中总的数据流平均到达速率服从泊松分布,在其余条件不变时,数据流的平均到达速率从 50条/s变化到2 000条/s(若每条路径分配相同数目的数据流,则每条路径的数据流平均到达速率从5条/s变化到200条/s),测试不同数据流到达速率场景下调度算法的性能。

3.2.1 短流平均完成时间

图2所示为短流的平均数据流完成时间实验结果。由图2可见:对于属于0~2的数据流,使用MPTCP-FSFS调度算法进行数据流调度时,总是选取当前时刻路径往返时延最小的1~3条路径进行数据流调度,数据流平均完成时间最小。实验中,当网络中总数据流平均到达速率介于50条/s到1 000条/s时,平均每条路径上传输的数据流数目少,即路径负载低。由图2(a)可见:当使用MPTCP时,将建立多条子流进行数据流传输,由于路径负载低,数据流发生丢包的概率低,数据流平均完成时间相比于TCP更低。由于存在路径差异性,使用MPTCP时,数据流可能选择路径往返时延大的路径建立主子流进行传输,导致数据流平均完成时间比MPTCP-FSFS的高。随着数据流到达速率增大,每条路径负载加大,路径拥塞导致丢包的概率增大。当数据流使用MPTCP时,由于传输的数据量少,在其生命周期内子流的拥塞窗口都保持在很小的状态,丢包导致超时现象产生的概率高;同时,由于路径存在差异性,导致数据流的平均完成时间最长。当数据流使用TCP协议时,由于路径差异性导致数据流平均完成时间与使用MPTCP-FSFS调度算法时的平均完成时间相比更大。实验结果显示:当属于0的数据流使用MPTCP-FSFS调度算法进行数据流调度时,与MPTCP相比,数据流平均完成时间减少31.88%以上,与TCP相比减少25.12%以上。

数据流类别:(a) G0;(b) G1;(c) G2

由图2(b)可见:对于属于1的数据流,使用MPTCP建立多条子流进行数据流传输,且当网络负载较小时,与TCP相比,数据流使用多条子流进行传输优势显现,数据流平均完成时间更低。随着数据流到达速率增大,网络负载加大,由于丢包导致超时,从而使得数据流平均完成时间增大。结果显示,当属于1的数据流使用MPTCP-FSFS调度算法进行数据流调度时,与MPTCP相比,数据流平均完成时间减少23.69%以上,与TCP相比减少21.15%以上。

由图2(c)可见:对于属于2的数据流,使用MPTCP-FSFS与MPTCP时,由于数据流建立多条子流进行传输,与TCP相比,数据流平均完成时间更少。当数据流使用MPTCP时,由于链路差异性导致数据流平均完成时间相比于数据流使用MPTCP-FSFS调度算法时更长。实验结果表明:属于2的数据流使用MPTCP-FSFS调度算法进行数据流调度时,与MPTCP相比,数据流平均完成时间减少10.79%以上,与TCP相比减少16.90%以上。

数据流使用MPTCP-FSFS调度算法时,对于每条数据流,总是使用当前时刻路径往返时延最小的若干条路径进行数据流传输,与MPTCP和TCP相比,短流平均完成时间均明显降低。

3.2.2 长流平均吞吐率

图3所示为长流平均吞吐率实验结果。当网络负载低、数据流使用MPTCP-FSFS调度算法时,与TCP相比,长流平均吞吐率明显更高,增长幅度在76.15%以上。与MPTCP相比,由于MPTCP-FSFS调度算法中短流占用路径往返时延小的若干条路径带宽,导致长流的平均吞吐率有所降低,但由于短流传输的数据量小,降低的幅度最大不超过3.49%。当网络负载较高时,由于网络拥塞,数据流使用MPTCP-FSFS,MPTCP和TCP时长流吞吐率接近。

图3 长流平均吞吐率

3.2.3 数据流平均吞吐率

图4所示为数据流平均吞吐率。根据前面的分析可知:使用MPTCP-FSFS调度算法进行数据流调度时,与MPTCP相比,长流的平均吞吐率略下降,但短流的平均吞吐率增幅更大,并且在实验中99%的数据流为短流;与TCP相比,短流的数据流平均完成时间更少,长流的吞吐率更高,因此,数据流平均吞吐率更高。实验结果表明:数据流使用MPTCP-FSFS调度算法进行调度时,与MPTCP相比,数据流平均吞吐率增大39.57%以上,与TCP相比增大30.82%以上。

图4 数据流平均吞吐率

3.3 路径数目变化

本组实验设置网络中总的数据流平均到达速率服从泊松分布,平均数据流到达速率不变,设置为1 000条/s,路径数目由5变化到20。由于网络中总的数据流平均到达速率不变,当传输路径数目变化时,根据每条路径上平均传输的数据流数目变化即路径的负载变化,测试不同路径数目下调度算法的性能。

3.3.1 短流平均完成时间

图5所示为短流的平均数据流完成时间。从图5(a)可见:当数据流属于0时,随着路径数目增大,每条路径上传输的数据流数目减少,即路径负载降低,路径拥塞概率降低,排队时延减少,导致数据流平均完成时间减少。当数据流使用MPTCP-FSFS调度算法时,数据流平均完成时间最小;当路径数目为5时,使用MPTCP时数据流平均完成时间最多。这是由于路径拥塞导致丢包发生概率高,数据流使用MPTCP协议建立多条子流进行数据流传输时,数据流传输的数据量少,容易导致数据流即使只丢失1个数据包也会出现超时现象,从而导致数据流平均完成时间最多。随着路径数目增大,路径负载降低,数据流使用MPTCP-FSFS和MPTCP建立多条子流进行数据传输时,与数据流使用TCP协议相比短流平均完成时间更少。实验结果表明:属于0的数据流使用MPTCP-FSFS调度算法进行数据流调度时,相比于MPTCP,数据流平均完成时间减少31.67%以上,相比于TCP减少了23.32%以上。

从图5(b)可见:当数据流属于1,使用MPTCP- FSFS调度算法进行数据流调度时,数据流使用当前时刻所有路径中路径往返时延最小的2条路径建立2条子流进行数据流传输,数据流的平均完成时间最少。实验结果表明:与MPTCP相比,数据流的平均完成时间减少23.41%以上,与TCP相比减少20.81%以上。

从图5(c)可见:当数据流属于G,使用MPTCP- FSFS和MPTCP时,与TCP相比,由于数据流使用多条子流进行传输,数据流平均完成时间更少。数据流使用MPTCP-FSFS调度算法时,总是使用当前时刻路径往返时延最小的3条路径建立3条子流进行传输,数据流平均完成时间最少。实验结果表明:与MPTCP相比,数据流平均完成时间减少11.05%以上,与TCP相比减少18.10%以上。

(a) G0;(b) G1;(c) G2

3.3.2 长流平均吞吐率

图6所示为长流平均吞吐率。从图6可见:随着路径数目增大,每条路径上传输的长流数目减少,数据流使用MPTCP协议进行传输时,长流的吞吐率相比于数据流使用TCP协议时优势明显,长流吞吐率均比数据流使用TCP协议作为传输层协议时的高;当数据流使用MPTCP-FSFS调度算法时,由于短流占据路径往返时延小的路径带宽,长流的吞吐率相比于MPTCP略有下降。实验结果表明:吞吐率下降不超过2.16%,但与TCP相比提高7.81%以上。

图6 不同路径数目时长流平均吞吐率

3.3.3 数据流平均吞吐率

图7所示为数据流平均吞吐率。从图7可见:随着路径数目增大,每条路径上传输的平均数据流数量减少,即负载减小,数据流由于路径拥塞导致丢包的概率减少,排队时延减少,数据流平均吞吐率增大;当数据流使用MPTCP-FSFS调度算法时,短流的平均完成时间最少,长流吞吐率与MPTCP的长流吞吐率相比相差不超过2.16%,并且短流数目占总的数据流绝大多数,数据流平均吞吐率最高;当使用MPTCP建立多条子流进行数据流传输且路径数为5时,由于网络拥塞导致短流的平均数据流完成时间长,并且短流从数量上而言最多,导致数据流平均吞吐率最低;随着路径数目增大,路径负载降低,数据流使用MPTCP-FSFS和MPTCP相比于TCP短流平均完成时间更少,长流吞吐率更高,数据流平均吞吐率比TCP的高。实验结果表明:当数据流使用MPTCP-FSFS调度算法时,与MPTCP相比,数据流的平均吞吐率增大42.47%以上,与TCP相比增大34.08%以上。

图7 不同路径数目时数据流平均吞吐率

4 结论

1) 针对MPTCP协议传输长流时吞吐率高但传输短流时数据流完成时间长,而TCP协议传输短流时数据流完成时间少但传输长流吞吐率低的特点,提出MPTCP-FSFS调度算法。

2)结合MPTCP协议对于传输长流的优势以及TCP协议对于传输短流的优势,根据数据流传输的数据量进行数据流分类,在进行短流调度时根据短流所属的类别选择当前往返时延最小的若干条路径进行数据流调度,在保证长流吞吐率的基础上,大大减少了短流的数据流完成时间,并且数据流平均吞吐率提高。

[1] GREENBERG A, HAMILTON J, JAIN N, et al. VL2: a scalable and flexible data center network[C]// Proceedings of ACM SIGCOMM. Barcelona, Spain: ACM, 2011: 51−62.

[2] ENGLE C, LUPHER A, XIN R, et al. Shark: fast data analysis using coarse-grained distributed memory[C]// Proceedings of the 2012 ACM SIGMOD International Conference on Management of Data. Scottsdale, Arizona, 2012: 689−692.

[3] MELNIK S, GUBAREV A, LONG J, et al. Dremel: interactive analysis of web-scale datasets[J]. Communications of the ACM, 2011, 54(6): 114−123.

[4] RFC 6182, Architectural guidelines for multipath TCP development[S].

[5] RFC 6897, Multipath TCP (MPTCP) application interface considerations[S].

[6] RFC 6824, TCP extension for multipath operation with multiple address[S].

[7] KHEIRKHAH M, WAKEMAN I, PARISIS G. MMPTCP: a multipath transport protocol for data centers[C]// IEEE INFOCOM. San Francisco, California, 2016: 1−9.

[8] SARWAR G, BORELI R, LOCHIN E, et al. Mitigating receiver’s buffer blocking by delay aware packet scheduling in multipath data transfer[C]// IEEE WAINA. Barcelona, Spain, 2013: 1119−1124.

[9] KUHN N, LOCHIN E, MIFDAOUI A, et al. DAPS: intelligent delay-aware packet scheduling for multipath transport[C]// IEEE International Conference on Communications. Sydney, Australia, 2014: 1222−1227.

[10] YANG Fan, WANG Qi, AMER P. Out-of-order transmission for in-order arrival scheduling for multipath TCP[C]// IEEE WAINA. Victoria, Canada, 2014: 749−752.

[11] FERLIN S, ALAY O, MEHANI O, et al. BLEST: blocking estimation-based MPTCP scheduler for heterogeneous networks[C]// IFIP Networking Conference. Trondheim, Norway, 2016: 431−439.

[12] CHAN M, TSENG C, YEN L. Jitter-aware packet scheduler for concurrent multipath transmission in heterogeneous wireless networks[C]// IEEE WCNC. San Francisco, California, 2016: 1−7.

[13] WANG Wei, SUN Yi, SALAMATIAN K, et al. Adaptive path isolation for elephant and mice flows by exploiting path diversity in data centers[J]. IEEE Transactions on Network and Service Management, 2016, 13(1): 5−18.

[14] CHIHANI B, DENIS C. A multipath TCP model for ns-3 simulator[C]// Workshop on ns-3 Held in Conjunction with SIMUTools 2011. Barceloan, Spain, 2011: 1−6.

[15] KHEIRKHAH M. Multipath-TCP in ns-3[EB/OL]. [2015−04−03]. http://dx.doi.org/10.5281/zenodo.32691/.

[16] FALL K, STEVENS W. TCP/IP illustrated volume 1 : the protocols[M]. 2nd ed. Boston: Addison-Wesley Professional, 2012: 727−803.

[17] ALIZADEH M, GREENBERG A, MALTZ D, et al. Data center TCP (DCTCP)[C]// Proceeding of ACM SIGCOMM. New Delhi, India: ACM, 2010: 63−74.

[18] RAICIU C, BARRE S, PLUNTKE C, et al. Improving datacenter performance and robustness with multipath TCP[C]// Proceeding of ACM SIGCOMM. Barcelona, Spain: ACM, 2011: 266−277.

[19] JIANG Hao, DOVROLIS C. Passive estimation of TCP round trip times[J]. ACM Computer Communications Review, 2002, 32(3): 7−18.

[20] RASTOGI S, ZAHEER H. Comparison analysis of different queuing mechanisms Droptail, RED and NLRED[J]. Social Network Analysis and Mining, 2016, 6(1): 70−76.

[21] WISCHIK D, RAICIU C, GREENHALGH A, et al. Design implementation and evaluation of congestion control for multipath TCP[C]// Proceedings of the USENIX Symposium on Networked Systems Design and Implementation(NSDI). Berkeley, California, 2011: 99−112.

[22] WANG Jianxin, CHEN Jie, ZHANG Shigeng, et al. An explicit congestion control protocol based on bandwidth estimation[C]// Global Communication Conference. Huston, American, 2011: 1−5.

[23] PLONKA D. Internet traffic flow size analysis[EB/OL]. [2002−10−05]. http://net.doit.wisc.edu/data/flow/size/.

Research on MPTCP flows scheduling algorithm based on flow characteristics

YE Ning1, DONG Pingping2, DUAN Guihua1, WANG Jianxin1

(1. School of Information Science and Engineering, Central South University, Changsha 410083, China;2. Department of Computer Education, Hunan Normal University, Changsha 410081, China)

When MPTCP protocol is used as the transmission layer protocol for short flows in the WAN, the congestion window of each subflow keeps small over its lifetime due to the small amount of data to be transmitted, and in this condition, even the loss of one packet may result in timeout, and thus makes the completion time of short flows become long. In order to solve this problem, the MPTCP-FSFS (multi-path TCP flow scheduling based on flow size) algorithm was presented, which scheduled MPTCP data flows based on the characteristics of MPTCP data flows. Firstly, the MPTCP-FSFS algorithm classified the MPTCP flows based on the amount of data to be sent. Then, the sender scheduled MPTCP flows according to the round-trip delay of each path. For short flows, several paths with the smallest RTT were selected for data transmission. For long flows, all the paths were used for transmission. The results show that compared with MPTCP, MPTCP-FSFS can reduce the completion time of short flows and improve the mean throughput of flows, which ensures long flows throughput simultaneously.

MPTCP; flow characteristics; path round-trip delay; flow scheduling

10.11817/j.issn.1672-7207.2018.07.016

TP393.2

A

1672−7207(2018)07−1691−09

2017−10−09;

2017−11−22

国家自然科学基金资助项目(61502539,61572530,61602171,61402542) (Projects(61502539, 61572530, 61602171, 61402542) supported by the National Natural Science Foundation of China)

段桂华,博士,副教授,从事计算机网络、网络安全研究;E-mail: duangh@csu.edu.cn

(编辑 陈灿华)

猜你喜欢

条子数据流时延
条子泥:只此湿地间 万物皆可爱
数据流计算研究进展与概述
汽车维修数据流基础(上)
5G承载网部署满足uRLLC业务时延要求的研究
汽车维修数据流基础(下)
相亲漫画二则
基于GCC-nearest时延估计的室内声源定位
AADL端对端数据流一致性验证方法
简化的基于时延线性拟合的宽带测向算法
条 子