CN108092908B - 控制流量的方法和发送端设备 - Google Patents

控制流量的方法和发送端设备 Download PDF

Info

Publication number
CN108092908B
CN108092908B CN201611035844.5A CN201611035844A CN108092908B CN 108092908 B CN108092908 B CN 108092908B CN 201611035844 A CN201611035844 A CN 201611035844A CN 108092908 B CN108092908 B CN 108092908B
Authority
CN
China
Prior art keywords
sub
stream
receiving end
receiving
size
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201611035844.5A
Other languages
English (en)
Other versions
CN108092908A (zh
Inventor
薛开平
韩江萍
徐青
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
University of Science and Technology of China USTC
Huawei Technologies Co Ltd
Original Assignee
University of Science and Technology of China USTC
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by University of Science and Technology of China USTC, Huawei Technologies Co Ltd filed Critical University of Science and Technology of China USTC
Priority to CN201611035844.5A priority Critical patent/CN108092908B/zh
Publication of CN108092908A publication Critical patent/CN108092908A/zh
Application granted granted Critical
Publication of CN108092908B publication Critical patent/CN108092908B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/27Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

本申请实施例公开了一种控制流量的方法和发送端设备,能够提高整体吞吐量。该方法包括:发送端设备根据多个子流中的每个子流的传输参数,预估所述每个子流的接收端缓存占用量,所述多个子流用于所述发送端设备向接收端设备发送数据;所述发送端设备根据预估的所述每个子流的接收端缓存占用量,为所述每个子流分配可用的接收端缓存;所述发送端设备确定所述每个子流可用的接收端缓存的剩余量;所述发送端设备根据所述每个子流可用的接收端缓存的剩余量,确定所述每个子流的接收窗口的大小;所述发送端设备通过所述每个子流的接收窗口的大小,对所述每个子流进行流量控制。

Description

控制流量的方法和发送端设备
技术领域
本申请涉及通信领域,并且更具体地,涉及控制流量的方法和发送端设备。
背景技术
多路径传输控制协议(全称:Multipath Transmission Control Protocol,简称:MPTCP)是一种利用多条路径并发传输的传输层协议,基于MPTCP 协议,发送端设备可以通过多条路径向接收端设备发送数据,目的是提高整体吞吐率,增加网络利用率,多条路径也可以称为多条子流。在MPTCP机制中,多个子流共享接收端缓存,在接收端设备发送的确认(全称: Acknowledge,简称:ACK)信号中携带接收窗口的大小信息,该接收窗口的大小窗口是针对所有的子流的,而不是针对每子流的,因此每个子流之间相互竞争使用接收端缓存,导致子流之间的负载不均衡和乱序问题的加剧,最终导致整体吞吐量的下降。
发明内容
本申请实施例提供一种控制流量的方法和发送端设备,能够提高整体吞吐量。
第一方面,提供了一种控制流量的方法,该方法包括:发送端设备根据多个子流中的每个子流的传输参数,预估该每个子流的接收端缓存占用量,该多个子流用于该发送端设备向接收端设备发送数据;该发送端设备根据预估的该每个子流的接收端缓存占用量,为该每个子流分配可用的接收端缓存;该发送端设备确定该每个子流可用的接收端缓存的剩余量;该发送端设备根据该每个子流可用的接收端缓存的剩余量,确定该每个子流的接收窗口的大小;该发送端设备通过该每个子流的接收窗口的大小,对该每个子流进行流量控制。
因此,该发送端设备可以根据每个子流的传输参数,预估每个子流需要占用的接收端缓存的大小,然后根据预估的接收端缓存占用量,为每个子流分配相应的接收端缓存,因此,发送端设备能够考虑子流之间不同的传输特性,为每个子流分配相应的接收端缓存,最终使得数据在子流上的分发更加合理,更好的实现了子流之间的负载均衡。
可选地,该发送端设备可以根据每个子流的RTT,预估每个子流的接收端缓存占用量,或者该发送端设备可以根据其他参数,例如,每个子流的实际吞吐量、子流的实际发包间隔或子流的单项延时等信息,预估每个子流的接收端缓存占用量,本申请实施例对此不作限制。
在一种可能的实现方式中,该发送端设备根据每个子流的传输参数,预估该每个子流的接收端缓存占用量,包括:该发送端设备根据该每个子流的往返时间RTT,预估该每个子流的接收端缓存占用量。
由于RTT能够反映子流的数据传输速率,该发送端设备根据每组子流的RTT,预估每个子流的接收端缓存占用量,从而该发送端设备可以为传输速率较高的子流预估较高的接收端缓存占用量,给传输速率低的子流预估较低的接收端缓存占用量,从而传输速率高的子流可以承担更多的数据发送量,传输速率低的子流可以承担相对较少的数据发送量,因此,能够更好的实现子流之间的负载均衡,同时提高了整体吞吐量。
在一种可能的实现方式中,该发送端设备根据预估的该每个子流的接收端缓存占用量,为该每个子流分配可用的接收端缓存,包括:该发送端设备按照该每个子流的接收端缓存占用量的比例,为该每个子流分配相应的接收端缓存。
在一种可能的实现方式中,该发送端设备根据该每个子流可用的接收端缓存的剩余量,确定该每个子流的接收窗口的大小,包括:若第一子流向该接收端设备发送的数据中的未被该接收端设备确认的数据量不小于为该第一子流分配的接收端缓存的大小,确定该第一子流的接收窗口大小为零;或若第二子流向该接收端设备发送的数据中的未被该接收端设备确认的数据量小于为该第二子流分配的接收端缓存的大小,根据该第二子流可用的接收端缓存的剩余量占连接级别的可用的接收端缓存的剩余量的比例,确定该第二子流的接收窗口大小,该连接级别的可用的接收端缓存的剩余量是该接收端设备在连接级别确认消息中通知该发送端设备的。
因此,发送端设备可以通过每个子流的接收窗口的大小控制每个子流一次发送的数据量,能够更好的实现子流之间的负载均衡,同时,当子流上出现大量乱序包时,可以通过将暂停或减少该子流上的数据包数量,即设置该子流的接收窗口为0或者为一个较小值,直到该子流上的乱序包数目减小,因此,能够提高整体吞吐量。
在一种可能的实现方式中,该发送端设备根据该每个子流的往返时间 RTT,预估该每个子流的接收端缓存占用量,包括:根据第一子流的RTT和该第一子流变更后的平滑后的拥塞窗口的大小,预估该第一子流的接收端缓存占用量,其中,该第一子流变更后的平滑后的拥塞窗口大小是根据该第一子流变更前的平滑后的拥塞窗口大小和变更后的拥塞窗口大小确定的。
因此,本申请实施例中,发送端设备引入平滑后的拥塞窗口的大小来预估每个子流的接收端缓存占用量,而不是根据某个时刻的拥塞窗口的大小,从而能够充分考虑一段时间内的数据发送情况,因此,对子流的接收窗口的调整更加平滑,并且,能够根据网络状况的变化自适应调整拥塞窗口大小,更加适合实际网络环境。
第二方面,提供了一种发送端设备,用于执行第一方面,第一方面的任一方面的可能实现方式中的方法。具体地,该发送端设备可以包括用于执行第一方面,第一方面的任一可能的实现方式中的方法的单元。
第三方面,提供了一种发送端设备,包括存储器和处理器,该存储器用于存储指令,该处理器用于执行该存储器存储的指令,并且对该存储器中存储的指令的执行使得该处理器执行第一方面,第一方面的任意可能的实现方式中的方法。
第四方面,提供了一种计算机可读存储介质,用于存储计算机程序,该计算机程序包括用于执行第一或第一的任意可能的实现方式中的任意一种方法的指令。
基于上述技术方案,发送端设备可以根据每个子流的传输参数,提前预估每个子流的接收端缓存占用量,然后根据预估的每个子流的接收端缓存占用量,为每个子流分配相应的接收端缓存,因此,本申请实施例的控制流量的方法,能够充分考虑每个子流的传输特性,从而使得接收端缓存资源的分配更加合理。进一步地,发送端设备可以为每个子流确定相应的接收窗口的大小,然后通过每个子流的接收窗口控制每条子流的流量,因此避免了各个子流公用一个接收端缓存造成的子流之竞争使用接收端缓存,最终导致的子流之间的负载不均衡和乱序问题,提高了整体吞吐量。
附图说明
图1是适用于根据本申请实施例的一种应用场景的示意图。
图2是根据本申请实施例的控制流量的方法的示意性流程图。
图3是根据本申请实施例的发送端设备的示意性框图。
图4是根据本申请另一实施例的发送端设备的示意性框图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。
本申请的技术方案,可以应用于各种需要进行流量控制的场景中。例如,发送端的多条子流之间的传输参数差异比较大,需要进行流量控制的情况,或者接收端缓存受限,需要进行流量控制的情况等,本申请实施例不作特别限定。
图1示出了适用于本申请实施例的一种应用场景的示意图。如图1所示,包括:发送端设备110和接收端设备120。
该发送端设备110或接收端设备120可以是具有多个接口的终端设备或服务器,该多个接口为支持MPTCP的接口,或者也可以是具有单个接口的终端设备或服务器,此时可以通过MPTCP代理实现多路径传输功能,或者也可以为具有多个接口的终端设备或服务器,该多个接口不支持MPTCP,此时可以通过MPTCP代理实现多路径传输功能。
需要说明的是,该多个接口可以为无线保真(全称:Wireless Fidelity,简称:WiFi)接口、长期演进(全称:Long Term Evolution,简称:LTE) 接口、有线网接口或者其他类型的接口中的一种或几种,该单个接口可以上述接口中的一种。
具体地,该发送端设备110或接收端设备120可以是笔记本、台式机、手机、服务器或其他可以支持传输控制协议(全称:Transport Control Protocol,简称:TCP)的设备等,本申请实施例对此不作限制。
应理解,该发送端设备110和该接收端设备120可以基于MPTCP进行数据传输,也就是发送端设备可以使用多条路径向接收端设备发送数据,以下,该多条路径称为多条子流,即该发送端设备通过多个子流与该接收端设备进行数据传输。
需要说明的是,在本申请实施例中,发送端设备110和接收端设备120 是以功能单元的形式来呈现。这里的“单元”可以指特定应用集成电路 (application-specificintegrated circuit,ASIC)、电路、执行一个或多个软件或固件程序的处理器和存储器、集成逻辑电路,和/或其他可以提供上述功能的器件。在一个简单的实施例中,本领域的技术人员可以想到发送端设备110 和接收端设备120都可以采用图2所示的计算机设备(或系统)400的方式来实现。
图2是本申请实施例提供的计算机设备(或系统)400的示意图。其中,计算机设备400包括至少一个处理器410、存储器420、通信总线430和至少一个通信接口440。
处理器410可以为中央处理器(CPU)、微处理器、特定应用集成电路(application-specific integrated circuit,ASIC),或一个或多个用于控制本申请方案程序执行的集成电路。
存储器420可以是只读存储器(read-only memory,ROM)或可存储静态信息和指令的其他类型的静态存储设备,随机存取存储器(random access memory,RAM)或者可存储信息和指令的其他类型的动态存储设备,也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-Only Memory,EEPROM)、只读光盘(Compact Disc Read-Only Memory,CD-ROM) 或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器可以是独立存在,通过通信总线430与处理器相连接。存储器也可以和处理器集成在一起。
其中,存储器420用于存储执行本申请方案的应用程序代码,处理器410 用于执行存储器420中存储的应用程序代码。
在具体实现中,作为一种实施例,处理器410可以包括一个或多个CPU。例如图2中所示的CPU0和CPU1。
在具体实现中,作为一种实施例,计算机设备400可以包括多个处理器,每个处理器可以是一个单核(single-CPU)处理器,也可以是一个多核 (multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
在具体实现中,作为一种实施例,计算机设备400还可以包括输出设备 450和输入设备460。输出设备450和处理器410通信,可以以多种方式来显示信息。例如,输出设备450可以是液晶显示器(liquid crystal display, LCD),发光二级管(light emittingdiode,LED)显示设备,阴极射线管(cathode ray tube,CRT)显示设备,或投影仪(projector)等。输入设备460和处理器410通信,可以以多种方式接受用户的输入。例如,输入设备可以是鼠标、键盘、触摸屏设备或传感设备等。
上述的计算机设备400可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中,计算机设备400可以是台式机、便携式电脑、网络服务器、掌上电脑(Personal Digital Assistant,PDA)、移动手机、平板电脑、无线终端设备、通信设备、嵌入式设备或有图2中类似结构的设备。本申请实施例不限定计算机设备400的类型。
在介绍本申请实施例的控制流量的方法之前,首先介绍一下跟本申请实施例有关的术语。
发送端缓存,对于发送端设备而言,可以用于存储以下四类数据:已经发送并被接收端设备确认的数据、已经发送但还未被接收端设备确认的数据、未发送但接收端允许发送的数据以及未发送且接收端端不允许发送的数据。
发送窗口,上述四类数据中的已经发送但还未被接收端设备确认的和未发送但接收端允许发送的数据所处的窗口可以认为是发送窗口。
接收端缓存,对于接收端设备而言,用于存储以下三类数据:已被接收端设备确认但未及时被上层应用读取的数据,已接收但未被接收端设备确认的数据以及尚未接收的数据。
接收窗口,上述三类数据中的已接收但未被接收端设备确认的数据以及尚未接收的数据所处的窗口可以认为是接收窗口。
拥塞窗口,指发送端设备在系统进行拥塞控制情况下一次最多能发送的数据包的数量,发送端设备根据网络的拥塞程度预设的一个值,而这个值就是拥塞窗口。拥塞窗口的大小取决于网络的拥塞程度,并且可以动态地变化。发送端设备可以使发送窗口等于拥塞窗口,但是如果考虑到接收端设备的接收能力,该发送窗口还可能小于拥塞窗口。
发送端设备控制拥塞窗口的原则可以是,只要网络没有出现拥塞,拥塞窗口就可以再增大一些,以便把更多的数据发送出去,只要网络出现拥塞,拥塞窗口就可以减少一些,以减少注入到网络中的数据量。
子流级别的拥塞窗口,是指该拥塞窗口针对单个子流的,用于指示该子流上一次最多能发送的数据包的数量。
连接级别的接收窗口,不分子流,是针对所有子流而言的,所有子流都可以使用该连接级别的接收窗口接收数据。
连接级别的发送窗口,不分子流,是针对所有子流而言的,所有子流都可以使用该连接级别的发送窗口发送数据。
以下,结合图3,详细说明根据本申请实施例的控制流量的方法。
应理解,图3是本申请实施例的控制流量的方法的示意性流程图,示出了该方法的详细的通信步骤或操作,但这些步骤或操作仅是示例,本申请实施例还可以执行其它操作或者图3中的各种操作的变形。此外,图3中的各个步骤可以分别按照与图3所呈现的不同的顺序来执行,并且有可能并非要执行图3中的全部操作。
图3示出了从发送端设备的角度描述的根据本申请实施例的控制流量的方法200的示意性流程图。该方法200可以用于图1中所示的应用场景。
如图3所示,该方法200包括以下步骤:
S210,发送端设备根据多个子流中的每个子流的传输参数,预估该每个子流的接收端缓存占用量,该多个子流用于该发送端设备向接收端设备发送数据;
具体地,发送端设备通过多个子流向接收端设备发送数据,该发送端设备可以根据每个子流的传输参数,预估每个子流需要占用的接收端缓存的大小,即每个子流的接收端缓存占有量。例如,该发送端设备可以根据往返时间(全称:Round Trip Time,简称:RTT),预估每个子流的接收端缓存占用量,其中,该RTT指从发送端设备发送数据开始到该发送端设备接收到接收端设备的ACK信息总共经历的时延。RTT参数可以表征子流的传输速率, RTT小表示子流从发送数据到被接收端设备确认接收的时间较短,即传输速率较快,该发送端设备可以给RTT小的子流预估较多的接收端缓存占有量,从而可以将数据分发到传输速率较快的子流上去传输,因此,能够更好的实现子流之间的负载均衡。
因此,本申请实施例的控制流量的方法,发送端设备能够根据子流之间不同的传输特性,为每个子流分配相应的接收端缓存,最终使得数据在子流上的分发更加合理,能够更好的实现子流之间的负载均衡。
可选地,在一种可能的实现方式中,该发送端设备根据多个子流中的每个子流的传输参数,预估该每个子流的接收端缓存占用量,包括:
该发送端设备根据该每个子流的往返时间RTT,预估该每个子流的接收端缓存占用量。
具体地,该发送端设备可以根据每个子流的RTT,预估每个子流的接收端缓存占有量,例如,若第一子流的RTT参数较大,也就是说该第一子流从发送数据到被接收端设备确定的时延较长,因此该第一子流的传输速率较低,该发送端设备预估的该第一子流的接收端缓存占用量可以相对较低,若第二子流的RTT较小,也就是说该第二子流的传输速率较高,该发送端设备预估的该第二子流的接收端缓存占用量可以相对较高,即该发送端设备预估的每个子流的接收端缓存占用量可以跟每个子流的往返时间成反比,从而该发送端设备可以通过为传输速率较高的子流预估较高的接收端缓存占用量,给传输速率低的子流预估较低的接收端缓存占用量,使得传输速率高的子流可以承担相对较多的数据发送量,传输速率低的子流承担相对较少的数据发送量,因此,能够更好的实现子流之间的负载均衡,同时提高整体吞吐量。
可选地,作为另一种可能的实现方式,该发送端设备根据该每个子流的往返时间RTT,预估该每个子流的接收端缓存占用量,可以包括:
根据第一子流的RTT和该第一子流变更后的平滑后的拥塞窗口的大小,预估该第一子流的接收端缓存占用量,
其中,该第一子流变更后的平滑后的拥塞窗口大小是根据该第一子流变更前的平滑后的拥塞窗口大小和变更后的拥塞窗口大小确定的。
具体而言,每个子流都有属于其自身的子流级别的拥塞窗口的大小,该子流级别的拥塞窗口的大小是根据实际网络状况动态变化的,该发送端设备可以根据每个子流的往返时间以及该每个子流的变更后的平滑后的拥塞窗口的大小,预估每个子流的接收端缓存占用量。例如,该每个子流包括第一子流,该发送端设备可以根据该第一子流的RTT和该第一子流的变更后的平滑后的拥塞窗口的大小,预估该第一子流的接收端缓存占用量。
例如,该发送端设备可以根据公式(1)确定该每个子流的接收端缓存占用量。
Figure BDA0001159675020000091
其中,该Bufi是该发送端设备预估的子流i的接收端缓存占用量,RTTi为子流i的RTT值,RTTmax为每个子流的RTT值中的最大值,aCwndi是子流i平滑后的拥塞窗口的大小,该aCwndi可以根据公式(2)确定。
aCwndi=(1-β)*aCwnd'i+β*Cwndi (2)
其中,Cwndi是子流i变更后的拥塞窗口的大小,即路径状况发生变更后的拥塞窗口的大小,aCwnd'i是变更前的平滑后的拥塞窗口的大小,当Cwndi发生变更时,该发送端设备可以根据该子流i的变更后的拥塞窗口大小和该子流i的变更前的平滑后的拥塞窗口大小,确定变更后的平滑后的拥塞窗口的大小。其中,β可以根据子流上的路径状态变化的剧烈程度来调整,当路径状态变化较为缓慢时,可以设置β为相对较小的值,当路径状态变化比较剧烈时,设置β为相对取大的值,可选地,该β可以默认设置为1/8。
因此,本申请实施例中,发送端设备不是根据某个时刻的拥塞窗口的大小预估每个子流的接收端缓存占用量,而是引入平滑后的拥塞窗口的大小来预估每个子流的接收端缓存占用量,从而能够充分考虑一段时间内的数据发送情况(或者也可以称为路径状态),因此,对子流的接收窗口的调整更加平滑,并且,能够根据路径状况的变化自适应调整拥塞窗口大小,更加适合实际网络环境。
可选地,该发送端设备还可以根据其他参数,例如,每个子流的实际吞吐量、子流的实际发包间隔或子流的单项延时等信息,预估每个子流的接收端缓存占用量,本申请实施例对此不作限制。根据上述信息预估每个子流的接收端缓存占用量的方法可以参考根据RTT预估每个子流的接收端缓存占用量的方法,为了简洁,这里不再赘述。
S220,该发送端设备根据预估的该每个子流的接收端缓存占用量,为该每个子流分配可用的接收端缓存;
具体而言,当发送端设备确定每个子流的接收端缓存占有量的预估值后,该发送端设备可以根据预估的每个子流的接收端缓存占用量,为每个子流分配可用的接收端缓存,此时分配的接收端缓存为该每个子流实际可以使用的接收端缓存。例如,若预估的该第一子流接收端缓存占用量为20字节,预估的该第二子流接收端缓存占用量为10字节,该接收端缓存为100字节,该发送端设备可以给该第一子流分配较大的接收端缓存,给该第二子流分配较小的接收端缓存,例如,可以给第一子流分配30字节,给第二子流分配 20字节,或者也可以给第一子流分配40字节,给第二子流分配20字节,也就是说,该发送端设备可以根据预估的每个子流的接收端缓存占用量,给缓存需求量高的子流分配相对较多的接收端缓存,给缓存需求量低的子流分配相对较低的接收端缓存,因此,本申请实施例的控制流量的方法,能够考虑每个子流的不同的需求,确定每个子流所需占用的接收端缓存,从而为每条子流分配相应的接收端缓存资源,因此,使得数据的分发更加合理。进一步地,避免了子流之间公用同一个接收端缓存导致的子流间相互影响的问题,因此,进一步提高了整体吞吐量。
可选地,该发送端设备根据预估的该每个子流的接收端缓存占用量,为该每个子流分配可用的接收端缓存,包括:
该发送端设备按照该每个子流的接收端缓存占用量的比例,分别为该每个子流分配相应的接收端缓存。
具体地,该发送端设备可以按照每个子流的接收端缓存占用量的比例,分别为该每个子流分配相应的接收端缓存。例如,该发送端设备可以根据公式(3)为该每个子流分配相应的接收端缓存。
Figure BDA0001159675020000101
其中,该Bufi为该发送端设备预估的子流i的接收端缓存占有量,recvBuffer为接收端缓存的大小,该recvBuffer在发送端设备和接收端设备建立连接时由接收端设备通知该发送端设备。Bi是该发送端设备为该子流i分配的接收端缓存的大小,Bi为该子流i实际可使用的接收端缓存大小。
根据公式(3)可知,若预估的该第一子流接收端缓存占用量为20字节,预估的该第二子流接收端缓存占用量为30字节,该接收端缓存为100字节,可以给第一子流分配40字节,给第二子流分配60字节。
应理解,该发送端设备也可以按照其他方法为每个子流分配可用的接收端缓存,例如,按照子流优先级分配接收端缓存,首先将每个子流按照RTT 大小排序,RTT越小优先级越高,分配接收端缓存时,只分配给预估的子流缓存占用量之和小于总的接收端缓存大小的前几条子流,其余子流作为备用子流,例如,若预估的第一子流的接收端缓存占用量为20字节,预估的该第二子流接收端缓存占用量为30字节,预估的该第三子流接收端缓存占用量为30字节,该接收端缓存为60字节,三条子流之和大于60,则第三条子流作为备用子流,可以给第一子流分配24字节,给第二子流分配36字节。
S230该发送端设备确定该每个子流可用的接收端缓存的剩余量;
具体而言,发送端设备为每个子流分配相应的接收端缓存后,发送端设备确定每个子流剩余可用的接收端缓存,即可用的接收端缓存的剩余量。每个子流可用的接收端缓存的剩余量是该发送端设备为该每个子流分配的接收端缓存减去该每个子流上连接级别未被接收端设备确认的数据量,其中,该每个子流上连接级别未被接收端设备确定的数据量包括连接级别乱序的数据和未收到的数据。例如,子流1发送数据1,2,子流2发送数据3,4,某一时刻接收端接收到数据包3,4,未收到1,2,则连接级别乱序的数据为3,4,未收到的数据为1,2,连接级别未确认的数据包为1,2,3,4,其中,子流1上连接级别未确认的数据包为1,2,子流2连接级别未确认的数据包为3,4。
S240,该发送端设备根据该每个子流可用的接收端缓存的剩余量,确定该每个子流的接收窗口的大小;
具体地,在确定每个子流可用的接收端缓存的剩余量后,该发送端设备根据每个子流可用的接收端缓存的剩余量,确定该每个子流的接收窗口的大小,例如,第一子流可用的接收端缓存的剩余量为20字节,第二子流可用的接收端缓存的剩余量为10字节,每个子流的接收窗口的接收端缓存的剩余量之和为50字节,该发送端设备可以确定该第一子流的接收窗口为30字节,该第二子流的接收窗口大小为20字节,即给接收端缓存剩余量较多的子流确定相对较大的接收窗口,给接收端缓存剩余量较少的子流确定相对较小的接收窗口,从而,接收端缓存剩余量较多的子流能够分担相对较多的数据发送量,接收端缓存剩余量较少的子流能够分担相对较少的数据发送量,因此,本申请实施例,能够根据不同子流的当前的路径状态合理调整分发到该子流上的数据发送量,从而能够保证数据发送量既不超过接收端缓存,又能保证子流之间的流量均衡。
可选地,该发送端设备根据该每个子流可用的接收端缓存的剩余量,确定该每个子流的接收窗口的大小,包括:
若第一子流向该接收端设备发送的数据中未被该接收端设备确认的数据量不小于为该第一子流分配的接收端缓存的大小,确定该第一子流的接收窗口大小为零;或
若第二子流向该接收端设备发送的数据中未被该接收端设备确认的数据量小于为该第二子流分配的接收端缓存的大小,根据该第二子流可用的接收端缓存的剩余量占连接级别可用的接收端缓存的剩余量的比例,确定该第二子流的接收窗口大小,该连接级别可用的接收端缓存的剩余量是该接收端设备在连接级别确认消息中通知该发送端设备的。
具体地,该发送端设备可以根据公式(4)确定该每个子流的接收窗口的大小。
Figure BDA0001159675020000121
其中,该Rwndi是子流i的子流级别的接收窗口的大小,也可以理解为发送端设备分配给子流i的可用的接收端缓存的剩余量。Rwnd是连接级别的接收端缓存的剩余量,该Rwnd是接收端设备在连接级别确认消息(DATA_ACK) 中通知该发送端设备的,该Rwnd可以理解为每个子流的接收端缓存的剩余量之和,或者也可以理解为连接级别的接收窗口的大小。unorderedi为子流i 上连接级别未被接收端设备确认的数据量。当Bi≤unorderedi时,可以认为该子流上占用了过多的接收端缓存,应该暂缓该子流上的数据发送。所以可以设置该子流的接收窗口的大小为0,即Rwndi=0。
当Bi>unorderedi时,可以认为该子流上还有可用的接收端缓存,此时,可以根据每个子流的可用的接收端缓存的剩余量占连接级别的接收窗口的大小的比例,确定每个子流的接收窗口的大小。
因此,发送端设备可以通过每个子流的接收窗口的大小控制每个子流一次发送的数据量,从而能够更好的实现子流之间的负载均衡,同时,当子流上出现大量乱序包时,可以通过将暂停或减少该子流上的数据包数量,即设置该子流的接收窗口为0或者为一个较小值,直到该子流上的乱序包数目减小,因此,能够提高整体吞吐量。
S250,该发送端设备通过该每个子流的接收窗口的大小,对该每个子流进行流量控制。
具体地,该每个子流的发送窗口的大小受该每个子流的子流级别的拥塞窗口的大小以及确定的该每个子流的接收窗口的大小的限制,同时该每个子流上发送的数据量的大小不能超过连接级别的发送窗口的大小,其中,连接级别的发送窗口是指发送端缓存和连接级别接收窗口的较小值。
具体地,该每个子流的子流级别的发送窗口的大小可以根据公式(5) 确定。
Send_Windowi=min(Cwndi,Rwndi) (5)
其中,该Send_Windowi为子流i的子流级别的发送窗口的大小,Cwndi是子流i的子流级别的拥塞窗口的大小,该Rwndi是子流i的子流级别的接收窗口的大小,公式(5)表示子流级别的发送窗口的大小不能超过子流级别的拥塞窗口的大小和子流级别的接收窗口的大小中的较小值。
当每个子流发送数据时,每个子流能够继续发送的数据量可以根据公式 (6)确定。
Send_datai=Send_Windowi-Outstandingi (6)
其中,Send_datai是子流i上能够继续发送的数据量,Outstandingi是子流 i上未被接收端设备确认的数据量。
因此,发送端设备可以通过子流级别的接收窗口的大小控制每条子流的流量,即一次发送的数据量,因此,子流之间不会互相干扰,能够更好地实现子流之间的负载均衡。进一步地,本申请实施例不改变拥塞窗口大小,当子流上连接级别的乱序包减少后能够快速恢复到正常的吞吐量,因此,具有更好的网络适应性。
以上,结合图3详细说明了根据本申请实施例的控制流量的方法。以下,结合图4详细说明根据本申请实施例的控制流量的装置。
图4示出了根据本申请实施例的发送端设备300的示意性框图。如图4 所示,该发送端设备300包括:
处理单元310,用于根据多个子流中的每个子流的传输参数,预估该每个子流的接收端缓存占用量,该多个子流用于该发送端设备向接收端设备发送数据;
根据预估的该每个子流的接收端缓存占用量,为该每个子流分配可用的接收端缓存;
确定该每个子流可用的接收端缓存的剩余量;
根据该每个子流可用的接收端缓存的剩余量,确定该每个子流的接收窗口的大小;
通过该每个子流的接收窗口的大小,对该每个子流进行流量控制。
该收发单元320用于该发送端设备300通过多个子流向接收端设备传输数据。
本申请实施例提供的发送端设备300,可以对应上述方法200中描述的发送端设备。并且,发送端设备300中各模块或单元分别用于执行上述方法200中由发送端设备所执行的相应流程。为了简洁,此处不再赘述。
应理解,在本实施例中,发送端设备300是以功能单元的形式来呈现。这里的“单元”可以指特定应用集成电路(application-specific integrated circuit,ASIC)、电路、执行一个或多个软件或固件程序的处理器和存储器、集成逻辑电路,和/或其他可以提供上述功能的器件。
在一些实施例中,发送端设备300可以采用图2所示的形式。处理单元 310可以通过图2的处理器和存储器来实现。具体地,处理器通过执行存储器中存储的计算机程序来实现。
本申请实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的便携式电子设备执行时,能够使该便携式电子设备执行图3所示实施例的方法。
本申请实施例还提出了一种计算机程序,该计算机程序包括指令,当该计算机程序被计算机执行时,使得计算机可以执行图3所示实施例的方法的相应流程。
应理解,本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
应理解,在本申请的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。

Claims (8)

1.一种控制流量的方法,其特征在于,包括:
发送端设备根据多个子流中的每个子流的传输参数,预估所述每个子流的接收端缓存占用量,所述多个子流用于所述发送端设备向接收端设备发送数据;
所述发送端设备根据预估的所述每个子流的接收端缓存占用量,为所述每个子流分配可用的接收端缓存;
所述发送端设备确定所述每个子流可用的接收端缓存的剩余量;
所述发送端设备根据所述每个子流可用的接收端缓存的剩余量,确定所述每个子流的接收窗口的大小;
所述发送端设备通过所述每个子流的接收窗口的大小,对所述每个子流进行流量控制;
其中,所述发送端设备根据所述每个子流可用的接收端缓存的剩余量,确定所述每个子流的接收窗口的大小,包括:
若第一子流向所述接收端设备发送的数据中未被所述接收端设备确认的数据量不小于为所述第一子流分配的接收端缓存的大小,确定所述第一子流的接收窗口大小为零;或
若第二子流向所述接收端设备发送的数据中未被所述接收端设备确认的数据量小于为所述第二子流分配的接收端缓存的大小,根据所述第二子流可用的接收端缓存的剩余量占连接级别可用的接收端缓存的剩余量的比例,确定所述第二子流的接收窗口大小,所述连接级别可用的接收端缓存的剩余量是所述接收端设备在连接级别确认消息中通知所述发送端设备的。
2.根据权利要求1所述的方法,其特征在于,所述发送端设备根据每个子流的传输参数,预估所述每个子流的接收端缓存占用量,包括:
所述发送端设备根据所述每个子流的往返时间RTT,预估所述每个子流的接收端缓存占用量。
3.根据权利要求1或2所述的方法,其特征在于,所述发送端设备根据预估的所述每个子流的接收端缓存占用量,为所述每个子流分配可用的接收端缓存,包括:
所述发送端设备按照所述每个子流的接收端缓存占用量的比例,为所述每个子流分配可用的接收端缓存。
4.根据权利要求2所述的方法,其特征在于,所述发送端设备根据所述每个子流的往返时间RTT,预估所述每个子流的接收端缓存占用量,包括:
根据第一子流的RTT和所述第一子流变更后的平滑后的拥塞窗口的大小,预估所述第一子流的接收端缓存占用量,
其中,所述第一子流变更后的平滑后的拥塞窗口大小是根据所述第一子流变更前的平滑后的拥塞窗口大小和变更后的拥塞窗口大小确定的。
5.一种发送端设备,其特征在于,包括:
处理单元,用于根据多个子流中的每个子流的传输参数,预估所述每个子流的接收端缓存占用量,所述多个子流用于所述发送端设备向接收端设备发送数据;
所述处理单元还用于根据预估的所述每个子流的接收端缓存占用量,为所述每个子流分配可用的接收端缓存;
所述处理单元还用于确定所述每个子流可用的接收端缓存的剩余量;
所述处理单元还用于根据所述每个子流可用的接收端缓存的剩余量,确定所述每个子流的接收窗口的大小;
所述处理单元还用于通过所述每个子流的接收窗口的大小,对所述每个子流进行流量控制;
所述处理单元还用于:
若第一子流向所述接收端设备发送的数据中的未被所述接收端设备确认的数据量不小于为所述第一子流分配的接收端缓存的大小,确定所述第一子流的接收窗口大小为零;或
若第二子流向所述接收端设备发送的数据中的未被所述接收端设备确认的数据量小于为所述第二子流分配的接收端缓存的大小,根据所述第二子流可用的接收端缓存的剩余量占连接级别的可用的接收端缓存的剩余量的比例,确定所述第二子流的接收窗口大小,所述连接级别的可用的接收端缓存的剩余量是所述接收端设备在连接级别确认消息中通知所述发送端设备的。
6.根据权利要求5所述的发送端设备,其特征在于,所述处理单元还用于:
根据所述每个子流的往返时间RTT,预估所述每个子流的接收端缓存占用量。
7.根据权利要求5或6所述的发送端设备,其特征在于,所述处理单元还用于:
按照所述每个子流的接收端缓存占用量的比例,为所述每个子流分配可用的接收端缓存。
8.根据权利要求6所述的发送端设备,其特征在于,所述处理单元还用于:
根据第一子流的RTT和所述第一子流变更后的平滑后的拥塞窗口的大小,预估所述第一子流的接收端缓存占用量,
其中,所述第一子流变更后的平滑后的拥塞窗口大小是根据所述第一子流变更前的平滑后的拥塞窗口大小和变更后的拥塞窗口大小确定的。
CN201611035844.5A 2016-11-23 2016-11-23 控制流量的方法和发送端设备 Active CN108092908B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611035844.5A CN108092908B (zh) 2016-11-23 2016-11-23 控制流量的方法和发送端设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611035844.5A CN108092908B (zh) 2016-11-23 2016-11-23 控制流量的方法和发送端设备

Publications (2)

Publication Number Publication Date
CN108092908A CN108092908A (zh) 2018-05-29
CN108092908B true CN108092908B (zh) 2020-06-26

Family

ID=62168603

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611035844.5A Active CN108092908B (zh) 2016-11-23 2016-11-23 控制流量的方法和发送端设备

Country Status (1)

Country Link
CN (1) CN108092908B (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111064704B (zh) * 2019-11-19 2021-02-09 中国科学院计算技术研究所 一种基于mptcp启动窗口自适应的数据传输方法、装置和介质
CN111200557B (zh) * 2019-11-22 2021-08-10 荣耀终端有限公司 一种连接建立方法及终端设备
CN112422489B (zh) * 2020-03-11 2021-11-02 深圳华锐金融技术股份有限公司 业务数据传输方法、装置、计算机设备和存储介质
CN113852589B (zh) * 2020-06-28 2023-10-24 华为技术有限公司 用于数据传输和数据接收的方法、设备和介质
CN113301398B (zh) * 2020-07-27 2022-12-02 阿里巴巴集团控股有限公司 信息处理方法及系统、服务端设备、客户端设备
CN112230880B (zh) * 2020-10-23 2023-08-11 浪潮(北京)电子信息产业有限公司 一种数据传输控制方法、装置、fpga及介质
CN115665060A (zh) * 2022-12-26 2023-01-31 中国华能集团清洁能源技术研究院有限公司 一种用于异构网络的多路径传输调度方法及装置
CN116527585B (zh) * 2023-07-05 2023-08-29 天地信息网络研究院(安徽)有限公司 一种流长度感知的拥塞控制方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6751665B2 (en) * 2002-10-18 2004-06-15 Alacritech, Inc. Providing window updates from a computer to a network interface device
CN101262437A (zh) * 2008-04-17 2008-09-10 中兴通讯股份有限公司 一种流控制传输协议状态迁移的方法
CN101656653A (zh) * 2008-08-21 2010-02-24 中国移动通信集团公司 一种应用于多路径传输的接收缓存配置方法及装置
CN105049369A (zh) * 2015-08-14 2015-11-11 浙江大学 异构无线网络中基于mptcp的视频传输拥塞控制方法
CN105376173A (zh) * 2014-09-02 2016-03-02 中兴通讯股份有限公司 一种发送窗口流量控制方法和终端

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6751665B2 (en) * 2002-10-18 2004-06-15 Alacritech, Inc. Providing window updates from a computer to a network interface device
CN101262437A (zh) * 2008-04-17 2008-09-10 中兴通讯股份有限公司 一种流控制传输协议状态迁移的方法
CN101656653A (zh) * 2008-08-21 2010-02-24 中国移动通信集团公司 一种应用于多路径传输的接收缓存配置方法及装置
CN105376173A (zh) * 2014-09-02 2016-03-02 中兴通讯股份有限公司 一种发送窗口流量控制方法和终端
CN105049369A (zh) * 2015-08-14 2015-11-11 浙江大学 异构无线网络中基于mptcp的视频传输拥塞控制方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MPTCP动态预留数据调度策略研究;胡庆 等;《重庆邮电大学学报(自然科学版)》;20131231;第25卷(第6期);第820-823页 *

Also Published As

Publication number Publication date
CN108092908A (zh) 2018-05-29

Similar Documents

Publication Publication Date Title
CN108092908B (zh) 控制流量的方法和发送端设备
US9225668B2 (en) Priority driven channel allocation for packet transferring
US11171862B2 (en) Multi-subflow network transmission method and apparatus
US20140036680A1 (en) Method to Allocate Packet Buffers in a Packet Transferring System
CN110391873B (zh) 用于确定数据传送方式的方法、装置以及计算机程序产品
US20220103465A1 (en) Multi-Subflow Network Transmission Method and Apparatus
US8885476B2 (en) TCP flow control optimized for networks having radio segments
US20150004930A1 (en) Method for providing relay network, mobile router and network relay system using the same
US10044632B2 (en) Systems and methods for adaptive credit-based flow
JP2009081595A (ja) パケットデータ中継装置
US20030163619A1 (en) Buffer controller and buffer control method
CN112714081A (zh) 一种数据处理方法及其装置
US9544235B2 (en) Scaling WiFi performance for large-audience environments via access points
US9742706B2 (en) Method for setting capacity of buffer
JP6595419B2 (ja) Api提供装置及びapiリクエスト制御方法
KR100764772B1 (ko) 휴대 단말기의 전송 제어 방법 및 장치
CN108141431B (zh) 发射实体以及由其执行以用于向接收实体传送一个或多个数据分组的方法
JP6620760B2 (ja) 管理ノード、端末、通信システム、通信方法、および、プログラム
US11818050B2 (en) Nonlinear traffic shaper with automatically adjustable cost parameters
CN115174411B (zh) 跨地域带宽的确定方法、装置、设备及存储介质
JP5652891B2 (ja) リモートデスクトップシステム
CN117785762A (zh) 一种信息存储方法、装置、设备和存储介质
KR101421232B1 (ko) 패킷 처리 장치, 방법 및 컴퓨터 판독 가능한 기록 매체
CN116962258A (zh) 一种带宽探测方法、装置、系统、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant