CN109104742A - 拥塞窗口调整方法及发送设备 - Google Patents

拥塞窗口调整方法及发送设备 Download PDF

Info

Publication number
CN109104742A
CN109104742A CN201710471830.6A CN201710471830A CN109104742A CN 109104742 A CN109104742 A CN 109104742A CN 201710471830 A CN201710471830 A CN 201710471830A CN 109104742 A CN109104742 A CN 109104742A
Authority
CN
China
Prior art keywords
packet loss
transmitting path
data transmitting
sending device
window
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.)
Pending
Application number
CN201710471830.6A
Other languages
English (en)
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 CN201710471830.6A priority Critical patent/CN109104742A/zh
Publication of CN109104742A publication Critical patent/CN109104742A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0242—Determining whether packet losses are due to overload or to deterioration of radio communication conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/11—Identifying congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0284—Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0289—Congestion control

Landscapes

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

Abstract

本申请实施例提供拥塞窗口调整方法及发送设备，能够使得调整后的拥塞窗口不影响数据发送路径上数据的最大可吞吐量。方法包括：发送设备获取第一序列号和第二序列号，所述第一序列号为数据发送路径上当前数据丢包时已确认的连续数据包的最大序列号，所述第二序列号为所述数据发送路径上上次数据丢包时已确认的连续数据包的最大序列号；所述发送设备根据所述第一序列号和所述第二序列号确定所述数据发送路径上当前的丢包间隔；所述发送设备根据所述丢包间隔确定所述数据发送路径上当前的丢包类型；所述发送设备根据所述丢包类型调整所述数据发送路径对应的拥塞窗口。

Description

拥塞窗口调整方法及发送设备
技术领域
本申请涉及通信技术领域，尤其涉及拥塞窗口调整方法及发送设备。
背景技术
多路径传输控制协议(Multipath Transmission Control Protocol，TCP)是使具有多种网络接口的通信设备之间可使用多条路径同时进行数据传输的技术。为满足MPTCP提升吞吐量、保证公平性和均衡拥塞的原则，MPTCP设计了联合拥塞控制算法。MPTCP默认使用的联合拥塞控制算法是链路增长算法(Linked increase algorithm，LIA)算法，该算法基于丢包事件进行拥塞控制。其中，子流i上每发生一个丢包时，就将其拥塞窗口wi减小至wi/2。
然而，目前MPTCP中主要存在两种类型的丢包：一种是由于网络拥塞即路由器溢出而引起的拥塞丢包(Congestion Loss)；一种是由于无线链路噪声干扰等造成的接收信息错误、分组无法解出而引起的链路随机丢包(Link random loss)。若在发生链路随机丢包时，盲目地减小拥塞窗口、降低发送速率，会限制MPTCP子流的最大可吞吐量，导致子流之间负载不均衡，从而影响MPTCP整体的吞吐量。
因此，如何在丢包情况下调整拥塞窗口，使得调整后的拥塞窗口不影响数据发送路径上数据的最大可吞吐量，是目前亟待解决的问题。
发明内容
本申请实施例提供拥塞窗口调整方法及发送设备，能够使得调整后的拥塞窗口不影响数据发送路径上数据的最大可吞吐量。
为达到上述目的，本申请实施例提供如下技术方案：
第一方面，提供一种拥塞窗口调整方法，该方法包括：发送设备获取第一序列号和第二序列号，该第一序列号为数据发送路径上当前数据丢包时已确认的连续数据包的最大序列号，该第二序列号为该数据发送路径上上次数据丢包时已确认的连续数据包的最大序列号；发送设备根据该第一序列号和该第二序列号确定该数据发送路径上当前的丢包间隔；发送设备根据该丢包间隔确定该数据发送路径上当前的丢包类型；发送设备根据该丢包类型调整该数据发送路径对应的拥塞窗口。基于该方案，一方面，考虑到若丢包是由于无线链路噪声干扰等造成的接收信息错误、分组无法解出而引起的链路随机丢包，则丢包率较低且较为稳定，每个包丢包概率相同，表现为随机丢包，丢包间隔较大；而若丢包是由于网络拥塞即路由器溢出而引起的拥塞丢包，则该丢包具有突发性，且丢包较为连续，丢包间隔较小。也就是说，拥塞丢包与链路随机丢包的丢包间隔一般来说差别较大，因此对平均丢包间隔的阈值设置的准确度要求不高，进而基于丢包间隔确定数据发送路径上当前的丢包类型的机制确定出的丢包类型更为准确。另一方面，由于本申请实施例可以根据丢包类型调整数据发送路径对应的拥塞窗口，不像现有技术一样盲目地减小拥塞窗口，因此可以减小链路随机丢包导致的拥塞窗口不必要的减小，从而可以使得调整后的拥塞窗口不影响数据发送路径上数据的最大可吞吐量。比如，以通信***是使用MPTCP协议的通信***为例，则基于该方案，不会限制TCP子流的最大可吞吐量。进一步的，在使用MPTCP协议的通信***中，由于未限制TCP子流的最大可吞吐量，因此更有利于TCP子流之间的负载均衡，进而保证MPTCP整体的吞吐量。
在一种可能的设计中，发送设备根据该丢包间隔确定该数据发送路径上当前的丢包类型，包括：若该丢包间隔小于平均丢包间隔，发送设备确定该数据发送路径上当前的丢包类型为拥塞丢包；或者，若该丢包间隔不小于平均丢包间隔，发送设备确定该数据发送路径上当前的丢包类型为链路随机丢包。考虑到若丢包是由于无线链路噪声干扰等造成的接收信息错误、分组无法解出而引起的链路随机丢包，则丢包率较低且较为稳定，每个包丢包概率相同，表现为随机丢包，丢包间隔较大；而若丢包是由于网络拥塞即路由器溢出而引起的拥塞丢包，则该丢包具有突发性，且丢包较为连续，丢包间隔较小。也就是说，拥塞丢包与链路随机丢包的丢包间隔一般来说差别较大，因此对平均丢包间隔的阈值设置的准确度要求不高，进而基于丢包间隔确定数据发送路径上当前的丢包类型的机制确定出的丢包类型更为准确。
在一种可能的设计中，发送设备根据该丢包类型调整该数据发送路径对应的拥塞窗口，包括：若该丢包类型为链路随机丢包，该发送设备将该数据发送路径对应的拥塞窗口的大小从w1调整为w3，其中，w1不小于w3。也就是说，当丢包类型为链路随机丢包时，由于丢包原因不是由于拥塞导致的，因此可以保持拥塞窗口不变或者在可允许的范围内减小拥塞窗口，从而不会影响数据发送路径上数据的发送速率，进而不会限制数据发送路径上数据的最大可吞吐量。
在一种可能的设计中，在发送设备将该数据发送路径对应的拥塞窗口的大小从w1调整为w3之后，还包括：发送设备在该数据发送路径上重传丢包，其中，该数据发送路径对应的第一发送窗口的大小为Send_window1＝min(w3,rwnd)，Send_window1表示该数据发送路径对应的第一发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。也即是说，在调整拥塞窗口后，发送设备一次实际最多能发送的数据包的数量，是由拥塞窗口和接收设备通告的总体接收窗口的大小中的较小者确定的。
在一种可能的设计中，发送设备根据该丢包类型调整该数据发送路径对应的拥塞窗口，包括：若该丢包类型为拥塞丢包，发送设备将该数据发送路径对应的拥塞窗口的大小从w1调整为w2，其中，w1大于w2。也就是说，当丢包类型为拥塞丢包时，由于丢包原因是由于拥塞即路由器溢出导致的，因此需要减小拥塞窗口以减少拥塞，比如，可以令w2＝w1/2。
在一种可能的设计中，在发送设备将该数据发送路径对应的拥塞窗口的大小从w1调整为w2之后，还包括：发送设备在该数据发送路径上重传丢包，其中，该数据发送路径对应的第二发送窗口的大小为Send_window2＝min(w2,rwnd)，Send_window2表示该数据发送路径对应的第二发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。也即是说，在调整拥塞窗口后，发送设备一次实际最多能发送的数据包的数量，是由拥塞窗口和接收设备通告的总体接收窗口的大小中的较小者确定的。
在一种可能的设计中，发送设备根据该第一序列号和该第二序列号确定该数据发送路径上当前的丢包间隔，包括：发送设备将该第一序列号和该第二序列号的差值确定为该数据发送路径上当前的丢包间隔。也就是说，丢包间隔可以定义为两次丢包事件之间成功传输的数据包的数量。其中，成功传输的数据包包括第一次丢包重传的数据包。
在一种可能的设计中，该平均丢包间隔小于其中，p表示该数据发送路径上的链路随机丢包率的实验值。
在一种可能的设计中，该平均丢包间隔为：其中，gapave表示平均丢包间隔，
第二方面，提供一种发送设备，该发送设备具有实现上述第一方面所述的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
第三方面，提供一种发送设备，包括：处理器、存储器、总线和通信接口；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当该发送设备运行时，该处理器执行该存储器存储的该计算机执行指令，以使该发送设备执行如上述第一方面中任一所述的拥塞窗口调整方法。
第四方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面中任意一项的拥塞窗口调整方法。
第五方面，本申请实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述第一方面中任意一项的拥塞窗口调整方法。
本申请的这些方面或其他方面在以下实施例的描述中会更加简明易懂。
附图说明
图1为本申请实施例提供的通信***的架构示意图；
图2为本申请实施例提供的MPTCP协议架构示意图；
图3为本申请实施例提供的MPTCP的典型应用场景示意图；
图4为本申请实施例提供的发送设备的硬件结构示意图；
图5为本申请实施例提供的拥塞窗口的调整方法的流程示意图；
图6为本申请实施例提供的丢包间隔示意图；
图7为本申请实施例提供的丢包间隔与丢包类型的关系示意图；
图8为本申请实施例提供的发送设备的结构示意图一；
图9为本申请实施例提供的发送设备的结构示意图二。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请的描述中，“多个”是指两个或多于两个。
如图1所示，为本申请实施例提供的通信***10的架构示意图，该通信***10包括发送设备101和接收设备102。其中，发送设备101用于执行本申请下述实施例提供的拥塞窗口调整方法，并根据调整后的拥塞窗口向接收设备102发送数据；接收设备102用于接收来自发送设备101的数据。
需要说明的是，图1中的发送设备101和接收设备102可能直接通信，也可能通过其他设备的转发进行通信，本申请实施例对此不作具体限定。
具体的，上述通信***101可以是使用MPTCP协议的通信***，也可以是使用TCP协议的通信***，本申请实施例对此不作具体限定。
其中，在标准TCP中，接收设备102和发送设备101之间只使用一条路径进行数据传输。在MPTCP中，接收设备102和发送设备101具有多种网络接口，例如无线保真(wirelessfidelity，WiFi)和蜂窝网络(cellular network)接口，这时，接收设备102和发送设备101之间可使用多条路径同时进行数据传输，从而可以保证更高水平的用户体验，减少无线网络因链路变化、高误码率等特点受到的影响。
如图2所示，MPTCP的核心思想是在应用层和传输层中间加入支持多路径传输的MPTCP层，将传统的TCP数据分为多个TCP子流，不同TCP子流在传输层沿不同路径传输，并在通信设备处聚合。原有的TCP层只对MPTCP的TCP子流起作用，从而使MPTCP与原TCP可以兼容，对网络其他层次透明，网络不必做太大的变化。
图3所示为MPTCP的典型应用场景。通信设备A和通信设备B是两个相互通信的多接口(分别包括一个WiFi接口和一个蜂窝网络接口)通信设备。两个通信设备上各个接口的IP地址分别是A1，A2和B1，B2。当通信设备A要使用MPTCP与通信设备B进行通信时，通信设备A可以同时使用WiFi接口和蜂窝网络接口与通信设备B进行通信，即分别在WiFi接口和蜂窝网络接口上建立一个TCP子流，因此通信设备A和通信设备B就可以同时利用两个接口来进行通信，从而提高通信带宽。
需要说明的是，图3中的通信设备A可以对应图1中的发送设备101，通信设备B可以对应图1中的接收设备102；或者，图3中的通信设备A可以对应图1中的接收设备102，通信设备B可以对应图1中的发送设备101，本申请实施例对此不作具体限定。
可选的，图1中的接收设备102、发送设备101以及图3中的通信设备A和通信设备B可以是服务器，也可以是各种类型的终端设备，比如各种具有无线通信功能的手持设备、车载设备、可穿戴设备、计算设备或连接到无线调制解调器的其它处理设备，以及各种形式的终端，移动台(mobile station，MS)，用户设备(user equipment，UE)，终端设备(terminalequipment)，客户端设备(customer premise equipment，CPE)软终端等等，本申请实施例对此不作具体限定。
如图4所示，为本申请实施例提供的一种发送设备400的硬件结构示意图，该发送设备400包括至少一个处理器401，通信总线402，存储器403以及至少一个通信接口404。
处理器401可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
通信总线402可包括一通路，在上述组件之间传送信息。
通信接口404，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local areanetworks，WLAN)等。
存储器403可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器403用于存储执行本申请方案的应用程序代码，并由处理器401来控制执行。处理器401用于执行存储器403中存储的应用程序代码，从而实现本申请下述实施例提供的拥塞窗口调整方法。
在具体实现中，作为一种实施例，处理器401可以包括一个或多个CPU，例如图4中的CPU0和CPU1。
在具体实现中，作为一种实施例，通信设备400可以包括多个处理器，例如图4中的处理器401和处理器408。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
在具体实现中，作为一种实施例，通信设备400还可以包括输出设备405和输入设备406。输出设备405和处理器401通信，可以以多种方式来显示信息。例如，输出设备405可以是液晶显示器(liquid crystal display，LCD),发光二级管(Light Emitting Diode，LED)显示设备，阴极射线管(cathode ray tube，CRT)显示设备，或投影仪(projector)等。输入设备406和处理器401通信，可以以多种方式接受用户的输入。例如，输入设备406可以是鼠标、键盘、触摸屏设备或传感设备等。
上述的发送设备400可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，发送设备400可以是服务器，也可以是各种类型的终端设备或有图4中类似结构的设备，本申请实施例不限定发送设备400的类型。示例性的，终端设备可以包括各种具有无线通信功能的手持设备、车载设备、可穿戴设备、计算设备或连接到无线调制解调器的其它处理设备，以及各种形式的终端，移动台(mobile station，MS)，用户设备(userequipment，UE)，客户端设备(customer premise equipment，CPE)软终端等等，本申请实施例对此不作具体限定。
下面将结合图1至图4对本申请实施例提供的拥塞窗口调整方法进行具体阐述。
如图5所示，为本申请实施例提供的拥塞窗口调整方法的流程示意图，包括如下步骤：
S501、发送设备获取第一序列号和第二序列号。
其中，第一序列号为数据发送路径上当前数据丢包时已确认的连续数据包的最大序列号，第二序列号为数据发送路径上上次数据丢包时已确认的连续数据包的最大序列号。
示例性的，以通信***101是使用MPTCP协议的通信***为例，如图6所示，MPTCP每条TCP子流的发送设备接收到三个重复确认(DupACK)指示丢包事件的发生。则第一序列号可以为图6中的Seqm，第二序列号可以为图6中的Seqold。
S502、发送设备根据第一序列号和第二序列号确定数据发送路径上当前的丢包间隔。
可选的，发送设备根据第一序列号和第二序列号确定数据发送路径上当前的丢包间隔具体可以包括：发送设备将第一序列号和第二序列号的差值确定为数据发送路径上当前的丢包间隔。也就是说，丢包间隔可以定义为两次丢包事件之间成功传输的数据包的数量。本申请实施例中，成功传输的数据包包括第一次丢包重传的数据包。
示例性的，参照图6，则丢包间隔＝Seqm-Seqold。
S503、发送设备根据丢包间隔确定数据发送路径上当前的丢包类型。
可选的，本申请实施例中，发送设备根据丢包间隔确定数据发送路径上当前的丢包类型具体可以包括：若丢包间隔小于平均丢包间隔，发送设备确定数据发送路径上当前的丢包类型为拥塞丢包；或者，若丢包间隔不小于平均丢包间隔，发送设备确定数据发送路径上当前的丢包类型为链路随机丢包。
考虑到若丢包是由于无线链路噪声干扰等造成的接收信息错误、分组无法解出而引起的链路随机丢包，则丢包率较低且较为稳定，每个包丢包概率相同，表现为随机丢包，丢包间隔较大；而若丢包是由于网络拥塞即路由器溢出而引起的拥塞丢包，则该丢包具有突发性，且丢包较为连续，丢包间隔较小。也就是说，拥塞丢包与链路随机丢包的丢包间隔一般来说差别较大，因此对平均丢包间隔的阈值设置的准确度要求不高，进而基于丢包间隔确定数据发送路径上当前的丢包类型的机制确定出的丢包类型更为准确。
可选的，本申请实施例中的平均丢包间隔小于其中，p表示数据发送路径上的链路随机丢包率的实验值。
示例性的，其中，gapave表示平均丢包间隔，
示例性的，以通信***101是使用MPTCP协议的通信***为例，数据发送路径为TCP子流i对应的数据发送路径，则该数据发送路径上的链路随机丢包率的实验值可以记作pri。当时，时，丢包间隔与丢包类型的关系可以如图7所示，即丢包间隔时为拥塞丢包；丢包间隔时为链路随机丢包。
S504、发送设备根据丢包类型调整数据发送路径对应的拥塞窗口。
其中，本申请实施例中，拥塞窗口具体是指发送设备在拥塞控制情况下一次最多能发送的数据包的数量。其中，拥塞控制情况下的丢包类型可以包括拥塞丢包和链路随机丢包，在此进行统一说明，以下不再赘述。
其中，发送设备根据丢包类型调整数据发送路径对应的拥塞窗口之后，可以根据调整后的拥塞窗口向接收设备发送数据，以使得接收设备接收来自发送设备的数据，具体可参考现有的实现方式，本申请实施例对此不作具体限定。
可选的，发送设备根据丢包类型调整数据发送路径对应的拥塞窗口具体可以包括：若丢包类型为链路随机丢包，发送设备将数据发送路径对应的拥塞窗口的大小从w1调整为w3，其中，w1不小于w3。也就是说，当丢包类型为链路随机丢包时，由于丢包原因不是由于拥塞导致的，因此可以保持拥塞窗口不变或者在可允许的范围内减小拥塞窗口，从而不会影响数据发送路径上数据的发送速率，进而不会限制数据发送路径上数据的最大可吞吐量。比如，以通信***101是使用MPTCP协议的通信***为例，则基于该方案，不会限制TCP子流的最大可吞吐量。进一步的，在使用MPTCP协议的通信***中，由于未限制TCP子流的最大可吞吐量，因此更有利于TCP子流之间的负载均衡，进而保证MPTCP整体的吞吐量。
进一步的，本申请实施例中，在发送设备将数据发送路径对应的拥塞窗口的大小从w1调整为w3之后，还可以包括：发送设备在数据发送路径上重传丢包，其中，数据发送路径对应的第一发送窗口的大小为Send_window1＝min(w3,rwnd)，Send_window1表示数据发送路径对应的第一发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。
其中，本申请实施例中，发送窗口具体指发送设备一次实际最多能发送的数据包的数量，是由拥塞窗口和接收设备通告的总体接收窗口的大小中的较小者确定的，在此进行统一说明，以下不再赘述。
示例性的，假设w3＝w1＝10，rwnd＝9，则：
Send_window1＝min(w3,rwnd)＝min(10,9)＝9。
或者，示例性的，假设w3＝w1＝10，rwnd＝11，则：
Send_window1＝min(w3,rwnd)＝min(10,11)＝10。
可选的，发送设备根据丢包类型调整数据发送路径对应的拥塞窗口具体可以包括：若丢包类型为拥塞丢包，发送设备将数据发送路径对应的拥塞窗口的大小从w1调整为w2，其中，w1大于w2。也就是说，当丢包类型为拥塞丢包时，由于丢包原因是由于拥塞即路由器溢出导致的，因此需要减小拥塞窗口以减少拥塞，比如，可以令w2＝w1/2。
进一步的，本申请实施例中，在发送设备将数据发送路径对应的拥塞窗口的大小从w1调整为w2之后，还可以包括：发送设备在数据发送路径上重传丢包，其中，数据发送路径对应的第二发送窗口的大小为Send_window2＝min(w2,rwnd)，Send_window2表示数据发送路径对应的第二发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。
示例性的，假设w2＝w1/2＝5，rwnd＝9，则：
Send_window2＝min(w2,rwnd)＝min(5,9)＝5。
或者，示例性的，假设w2＝w1/2＝5，rwnd＝4，则：
Send_window2＝min(w2,rwnd)＝min(5,4)＝4。
本申请实施例提供的拥塞窗口调整方法中，发送设备根据两次丢包的丢包间隔确定数据发送路径上当前的丢包类型，进而根据丢包类型调整数据发送路径对应的拥塞窗口。一方面，考虑到若丢包是由于无线链路噪声干扰等造成的接收信息错误、分组无法解出而引起的链路随机丢包，则丢包率较低且较为稳定，每个包丢包概率相同，表现为随机丢包，丢包间隔较大；而若丢包是由于网络拥塞即路由器溢出而引起的拥塞丢包，则该丢包具有突发性，且丢包较为连续，丢包间隔较小。也就是说，拥塞丢包与链路随机丢包的丢包间隔一般来说差别较大，因此对平均丢包间隔的阈值设置的准确度要求不高，进而基于丢包间隔确定数据发送路径上当前的丢包类型的机制确定出的丢包类型更为准确。另一方面，由于本申请实施例可以根据丢包类型调整数据发送路径对应的拥塞窗口，不像现有技术一样盲目地减小拥塞窗口，因此可以减小链路随机丢包导致的拥塞窗口不必要的减小，从而可以使得调整后的拥塞窗口不影响数据发送路径上数据的最大可吞吐量。比如，以通信***101是使用MPTCP协议的通信***为例，则基于该方案，不会限制TCP子流的最大可吞吐量。进一步的，在使用MPTCP协议的通信***中，由于未限制TCP子流的最大可吞吐量，因此更有利于TCP子流之间的负载均衡，进而保证MPTCP整体的吞吐量。
其中，上述步骤S501至S504中发送设备的动作可以由图4所示的发送设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限制。
上述主要从发送设备的角度对本申请实施例提供的方案进行了介绍。可以理解的是，上述发送设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对发送设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
比如，在采用对应各个功能划分各个功能模块的情况下，图8示出了上述实施例中所涉及的发送设备80的一种可能的结构示意图。该发送设备80包括获取模块801、确定模块802和调整模块803。获取模块801，用于获取第一序列号和第二序列号，第一序列号为数据发送路径上当前数据丢包时已确认的连续数据包的最大序列号，第二序列号为数据发送路径上上次数据丢包时已确认的连续数据包的最大序列号；确定模块802，用于根据第一序列号和第二序列号确定数据发送路径上当前的丢包间隔。确定模块802，还用于根据丢包间隔确定数据发送路径上当前的丢包类型。调整模块803，用于根据丢包类型调整数据发送路径对应的拥塞窗口。
可选的，确定模块802具体用于：若丢包间隔小于平均丢包间隔，确定数据发送路径上当前的丢包类型为拥塞丢包；或者，若丢包间隔不小于平均丢包间隔，确定数据发送路径上当前的丢包类型为链路随机丢包。
一种可能的实现方式中，调整模块803具体用于：若丢包类型为链路随机丢包，将数据发送路径对应的拥塞窗口的大小从w1调整为w3，其中，w1不小于w3。
可选的，如图8所示，发送设备80还包括发送模块804。发送模块804，用于在调整模块803将数据发送路径对应的拥塞窗口的大小从w1调整为w3之后，在数据发送路径上重传丢包，其中，数据发送路径对应的第一发送窗口的大小为Send_window1＝min(w3,rwnd)，Send_window1表示数据发送路径对应的第一发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。
一种可能的实现方式中，调整模块803具体用于：若丢包类型为拥塞丢包，将数据发送路径对应的拥塞窗口的大小从w1调整为w2，其中，w1大于w2。
可选的，如图8所示，发送设备80还包括发送模块804。发送模块804，用于在调整模块803将数据发送路径对应的拥塞窗口的大小从w1调整为w2之后，在数据发送路径上重传丢包，其中，数据发送路径对应的第二发送窗口的大小为Send_window2＝min(w2,rwnd)，Send_window2表示数据发送路径对应的第二发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。
可选的，确定模块802具体用于：将第一序列号和第二序列号的差值确定为数据发送路径上当前的丢包间隔。
可选的，平均丢包间隔小于其中，p表示数据发送路径上的链路随机丢包率的实验值。
可选的，平均丢包间隔为：其中，gapave表示平均丢包间隔，
其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
以采用集成的方式划分各个功能模块的情况下，图9示出了上述实施例中所涉及的发送设备90的一种可能的结构示意图，该发送设备90包括：处理模块901。其中，处理模块901用于执行图8中获取模块801、确定模块802和调整模块803所能执行的操作，具体可参考图8所示的实施例，本申请实施例在此不再赘述。
可选的，如图9所示，该发送设备90还可以包括通信模块902，该通信模块902用于执行图9中发送模块804所能执行的操作，具体可参考图8所示的实施例，本申请实施例在此不再赘述。
其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
在本实施例中，该发送设备以对应各个功能划分各个功能模块的形式来呈现，或者，该发送设备以采用集成的方式划分各个功能模块的形式来呈现。这里的“模块”可以指特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，电路，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。在一个简单的实施例中，本领域的技术人员可以想到发送设备80或者发送设备90可以采用图4所示的形式。比如，图8中的获取模块801、确定模块802和调整模块803可以通过图4的处理器401和存储器403来实现。具体的，获取模块801、确定模块802和调整模块803可以通过由处理器401来调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限制。或者，图8中的获取模块801、确定模块802、调整模块803和发送模块804可以通过图4的处理器401和存储器403来实现。具体的，获取模块801、确定模块802、调整模块803和发送模块804可以通过由处理器401来调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限制。或者，比如，图9中的处理模块901可以通过图4的处理器401和存储器403来实现。具体的，处理模块901可以通过由处理器401来调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限制。或者，比如，图9中的处理模块901和通信模块902可以通过图4的处理器401和存储器403来实现。具体的，处理模块901和通信模块902可以通过由处理器401来调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限制。
由于本申请实施例提供的发送设备可用于执行上述报文转发方法，因此其所能获得的技术效果可参考上述方法实施例，在此不再赘述。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。
尽管在此结合各实施例对本申请进行了描述，然而，在实施所要求保护的本申请过程中，本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书，可理解并实现所述公开实施例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。
尽管结合具体特征及其实施例对本申请进行了描述，显而易见的，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (18)

1.一种拥塞窗口调整方法，其特征在于，所述方法包括：
发送设备获取第一序列号和第二序列号，所述第一序列号为数据发送路径上当前数据丢包时已确认的连续数据包的最大序列号，所述第二序列号为所述数据发送路径上上次数据丢包时已确认的连续数据包的最大序列号；
所述发送设备根据所述第一序列号和所述第二序列号确定所述数据发送路径上当前的丢包间隔；
所述发送设备根据所述丢包间隔确定所述数据发送路径上当前的丢包类型；
所述发送设备根据所述丢包类型调整所述数据发送路径对应的拥塞窗口。
2.根据权利要求1所述的所述的方法，其特征在于，所述发送设备根据所述丢包间隔确定所述数据发送路径上当前的丢包类型，包括：
若所述丢包间隔小于平均丢包间隔，所述发送设备确定所述数据发送路径上当前的丢包类型为拥塞丢包；或者，
若所述丢包间隔不小于平均丢包间隔，所述发送设备确定所述数据发送路径上当前的丢包类型为链路随机丢包。
3.根据权利要求1或2所述的方法，其特征在于，所述发送设备根据所述丢包类型调整所述数据发送路径对应的拥塞窗口，包括：
若所述丢包类型为链路随机丢包，所述发送设备将所述数据发送路径对应的拥塞窗口的大小从w1调整为w3，其中，w1不小于w3。
4.根据权利要求3所述的方法，其特征在于，在所述发送设备将所述数据发送路径对应的拥塞窗口的大小从w1调整为w3之后，还包括：
所述发送设备在所述数据发送路径上重传丢包，其中，所述数据发送路径对应的第一发送窗口的大小为Send_window1＝min(w3,rwnd)，Send_window1表示所述数据发送路径对应的第一发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。
5.根据权利要求1或2所述的方法，其特征在于，所述发送设备根据所述丢包类型调整所述数据发送路径对应的拥塞窗口，包括：
若所述丢包类型为拥塞丢包，所述发送设备将所述数据发送路径对应的拥塞窗口的大小从w1调整为w2，其中，w1大于w2。
6.根据权利要求5所述的方法，其特征在于，在所述发送设备将所述数据发送路径对应的拥塞窗口的大小从w1调整为w2之后，还包括：
所述发送设备在所述数据发送路径上重传丢包，其中，所述数据发送路径对应的第二发送窗口的大小为Send_window2＝min(w2,rwnd)，Send_window2表示所述数据发送路径对应的第二发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。
7.根据权利要求1-6任一项所述的方法，其特征在于，所述发送设备根据所述第一序列号和所述第二序列号确定所述数据发送路径上当前的丢包间隔，包括：
所述发送设备将所述第一序列号和所述第二序列号的差值确定为所述数据发送路径上当前的丢包间隔。
8.根据权利要求2-6任一项所述的方法，其特征在于，所述平均丢包间隔小于其中，p表示所述数据发送路径上的链路随机丢包率的实验值。
9.根据权利要求8所述的方法，其特征在于，所述平均丢包间隔为：
其中，gapave表示平均丢包间隔，
10.一种发送设备，其特征在于，所述发送设备包括：获取模块、确定模块和调整模块；
所述获取模块，用于获取第一序列号和第二序列号，所述第一序列号为数据发送路径上当前数据丢包时已确认的连续数据包的最大序列号，所述第二序列号为所述数据发送路径上上次数据丢包时已确认的连续数据包的最大序列号；
所述确定模块，用于根据所述第一序列号和所述第二序列号确定所述数据发送路径上当前的丢包间隔；
所述确定模块，还用于根据所述丢包间隔确定所述数据发送路径上当前的丢包类型；
所述调整模块，用于根据所述丢包类型调整所述数据发送路径对应的拥塞窗口。
11.根据权利要求10所述的所述的发送设备，其特征在于，所述确定模块具体用于：
若所述丢包间隔小于平均丢包间隔，确定所述数据发送路径上当前的丢包类型为拥塞丢包；或者，
若所述丢包间隔不小于平均丢包间隔，确定所述数据发送路径上当前的丢包类型为链路随机丢包。
12.根据权利要求10或11所述的发送设备，其特征在于，所述调整模块具体用于：
若所述丢包类型为链路随机丢包，将所述数据发送路径对应的拥塞窗口的大小从w1调整为w3，其中，w1不小于w3。
13.根据权利要求12所述的发送设备，其特征在于，所述发送设备还包括发送模块；
所述发送模块，用于在所述调整模块将所述数据发送路径对应的拥塞窗口的大小从w1调整为w3之后，在所述数据发送路径上重传丢包，其中，所述数据发送路径对应的第一发送窗口的大小为Send_window1＝min(w3,rwnd)，Send_window1表示所述数据发送路径对应的第一发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。
14.根据权利要求10或11所述的发送设备，其特征在于，所述调整模块具体用于：
若所述丢包类型为拥塞丢包，将所述数据发送路径对应的拥塞窗口的大小从w1调整为w2，其中，w1大于w2。
15.根据权利要求14所述的发送设备，其特征在于，所述发送设备还包括发送模块；
所述发送模块，用于在所述调整模块将所述数据发送路径对应的拥塞窗口的大小从w1调整为w2之后，在所述数据发送路径上重传丢包，其中，所述数据发送路径对应的第二发送窗口的大小为Send_window2＝min(w2,rwnd)，Send_window2表示所述数据发送路径对应的第二发送窗口的大小；rwnd表示接收设备通告的总体接收窗口的大小。
16.根据权利要求10-15任一项所述的发送设备，其特征在于，所述确定模块具体用于：
将所述第一序列号和所述第二序列号的差值确定为所述数据发送路径上当前的丢包间隔。
17.根据权利要求11-15任一项所述的发送设备，其特征在于，所述平均丢包间隔小于其中，p表示所述数据发送路径上的链路随机丢包率的实验值。
18.一种发送设备，其特征在于，包括：处理器、存储器、总线和通信接口；
所述存储器用于存储计算机执行指令，所述处理器与所述存储器通过所述总线连接，当所述发送设备运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述发送设备执行如权利要求1-9中任意一项所述的拥塞窗口调整方法。
CN201710471830.6A 2017-06-20 2017-06-20 拥塞窗口调整方法及发送设备 Pending CN109104742A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710471830.6A CN109104742A (zh) 2017-06-20 2017-06-20 拥塞窗口调整方法及发送设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710471830.6A CN109104742A (zh) 2017-06-20 2017-06-20 拥塞窗口调整方法及发送设备

Publications (1)

Publication Number Publication Date
CN109104742A true CN109104742A (zh) 2018-12-28

Family

ID=64796073

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710471830.6A Pending CN109104742A (zh) 2017-06-20 2017-06-20 拥塞窗口调整方法及发送设备

Country Status (1)

Country Link
CN (1) CN109104742A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111181864A (zh) * 2020-02-27 2020-05-19 上海掌门科技有限公司 确定从应用至服务器的链路拥塞状态的方法与设备
CN111246312A (zh) * 2020-01-15 2020-06-05 安徽文香信息技术有限公司 一种丢包处理方法及装置
CN111542089A (zh) * 2020-05-14 2020-08-14 海南大学 一种基于时延和窗口抖动的多路径拥塞控制方法和装置
CN115086200A (zh) * 2022-05-06 2022-09-20 北京达佳互联信息技术有限公司 丢包类型确定方法、装置、电子设备及存储介质
WO2023179538A1 (zh) * 2022-03-23 2023-09-28 维沃移动通信有限公司 数据传输方法、装置、电子设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011137773A1 (zh) * 2010-11-18 2011-11-10 华为技术有限公司 网络丢包处理方法及装置
CN103986548A (zh) * 2013-02-07 2014-08-13 华为技术有限公司 一种确定丢包原因的方法和终端
CN104683259A (zh) * 2015-02-15 2015-06-03 上海帝联信息科技股份有限公司 Tcp拥塞控制方法及装置
CN105634875A (zh) * 2016-02-05 2016-06-01 中国科学院计算技术研究所 识别可靠传输协议的数据传输中的丢包类型的方法及***

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011137773A1 (zh) * 2010-11-18 2011-11-10 华为技术有限公司 网络丢包处理方法及装置
CN103986548A (zh) * 2013-02-07 2014-08-13 华为技术有限公司 一种确定丢包原因的方法和终端
CN104683259A (zh) * 2015-02-15 2015-06-03 上海帝联信息科技股份有限公司 Tcp拥塞控制方法及装置
CN105634875A (zh) * 2016-02-05 2016-06-01 中国科学院计算技术研究所 识别可靠传输协议的数据传输中的丢包类型的方法及***

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111246312A (zh) * 2020-01-15 2020-06-05 安徽文香信息技术有限公司 一种丢包处理方法及装置
CN111181864A (zh) * 2020-02-27 2020-05-19 上海掌门科技有限公司 确定从应用至服务器的链路拥塞状态的方法与设备
CN111181864B (zh) * 2020-02-27 2023-05-09 上海掌门科技有限公司 确定从应用至服务器的链路拥塞状态的方法与设备
CN111542089A (zh) * 2020-05-14 2020-08-14 海南大学 一种基于时延和窗口抖动的多路径拥塞控制方法和装置
CN111542089B (zh) * 2020-05-14 2021-11-09 海南大学 一种基于时延和窗口抖动的多路径拥塞控制方法和装置
WO2023179538A1 (zh) * 2022-03-23 2023-09-28 维沃移动通信有限公司 数据传输方法、装置、电子设备和存储介质
CN115086200A (zh) * 2022-05-06 2022-09-20 北京达佳互联信息技术有限公司 丢包类型确定方法、装置、电子设备及存储介质
CN115086200B (zh) * 2022-05-06 2023-09-01 北京达佳互联信息技术有限公司 丢包类型确定方法、装置、电子设备及存储介质

Similar Documents

Publication Publication Date Title
US10680928B2 (en) Multi-stream transmission method and device in SDN network
CN109104742A (zh) 拥塞窗口调整方法及发送设备
EP3278514B1 (en) Data transmission
KR101670642B1 (ko) 클라이언트 디바이스 상에서의 패킷 송신을 스케줄링하기 위한 시스템 및 방법
US8638686B2 (en) Buffer sizing for multi-hop networks
US20190149475A1 (en) Unified streamlining for data traffic
EP3103218A1 (en) Bandwidth and latency estimation in a communication network
CN108471629A (zh) 传输网络中业务服务质量的控制方法、设备及***
CN110944358B (zh) 数据传输方法和设备
US10374945B1 (en) Application-centric method to find relative paths
CN104092625B (zh) 一种用于dcn中的自适应请求分批调度方法
CN113726681B (zh) 一种网络拥塞控制方法及网络设备
Zeng et al. Combining ECN and RTT for datacenter transport
CN109428842A (zh) 一种QoS信息传送方法和装置
CN116868553A (zh) 用于管理端点资源和拥塞缓解的数据中心网络上的动态网络接收器驱动的数据调度
US11509587B2 (en) Multiple QoS traffic splitting over multiple heterogeneous links
WO2018157819A1 (zh) 多子流网络传输方法及装置
Oljira et al. Mdtcp: Towards a practical multipath transport protocol for telco cloud datacenters
CN112714072B (zh) 一种调整发送速率的方法及装置
CN111224884B (zh) 拥塞控制的处理方法、报文转发装置及报文接收装置
Kumar et al. Device‐centric data reordering and buffer management for mobile Internet using Multipath Transmission Control Protocol
Cai et al. D-OLIA: The packet loss differentiation based opportunistic linked-increases algorithm for MPTCP in wireless heterogeneous network
Kheirkhah Sabetghadam Mmptcp: a novel transport protocol for data centre networks
Shreedhar et al. High throughputs and information freshness over the internet via transport layer advancements
Khan et al. Adaptive fast retransmission with respect to receiver buffer (Rbuf) space in simultaneous multipath transmission (Smt)

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20181228

RJ01 Rejection of invention patent application after publication