CN103999409B

CN103999409B - 用于带宽变化移动数据网络的链路缓冲器大小和队列长度估算的方法

Info

Publication number: CN103999409B
Application number: CN201280048658.9A
Authority: CN
Inventors: 李耀斌; 陈志丰
Original assignee: Chinese University of Hong Kong CUHK
Current assignee: Chinese University of Hong Kong CUHK
Priority date: 2011-10-04
Filing date: 2012-09-28
Publication date: 2017-02-15
Anticipated expiration: 2032-09-28
Also published as: US20130083654A1; WO2013049993A1; HK1197119A1; CN103999409A; US8923270B2

Abstract

数字移动通信带宽变化的网络中的延迟之和算法被采用以估算底层网络连接中的链路缓冲器大小和队列长度。具体地，与过程相关联的机制补偿链路带宽变化。在具体的实施方式中，被动估算被采用以通过简单地测量带内数据分组定时执行估算来实现过程，由此消除额外的测量分组的传输的需要。此方法能够将链路缓冲器大小估算算法融合到现有的传输协议（例如，TCP）以优化流和拥塞控制。作为本发明的一部分，新的拥塞控制方法，所谓的TCP队列长度自适应（TCP‑QA），被开发以在TCP发送方计算机中采用延迟之和算法来控制TCP连接中的数据流。与现有的TCP变型相比，TCP‑QA可在带宽变化的网络中实现明显更好的网络带宽利用率。

Description

用于带宽变化移动数据网络的链路缓冲器大小和队列长度估算的方法

联邦政府资助的研究和开发的声明

此文献不是由美国联邦机构资助而是部分地由香港SAR创新科技署提供的创新科技基金(ITS/014/10)资助，它不要求本发明的专有权益。

所提交的光盘上的“序列清单”、表或计算机程序清单附件的参考

不适用

技术领域

本发明涉及无线通信，更具体地涉及无线移动互联网数字数据通信。

背景技术

已知互联网传输和应用协议的性能严重依赖于底层网络链路(具体地，瓶颈链路)的特性。除了竞争流量的影响以外，瓶颈链路具有三个主要参数，即链路带宽、缓冲器大小和队列长度。参考下面由括号内的数字列出的引文，许多先前文献已经研究了估算这些链路参数的方法，例如链路带宽估算[1-3]、链路缓冲器大小估算[4-6]和队列长度估算[7-9]。这些先前文献之间的共同假设是链路带宽是恒定的，其中此假设在很大程度上对有线网络有效，因为物理链路典型地具有固定的数据传输速率。然而，对于快速发展的移动数据网络(例如，3G[10]、HSPA[11]和LTE[12])，此假设不再有效。

为了说明，图1绘出了在10秒时间间隔内测量的生产3G网络的带宽，其中仅存在从有线服务器至3G连接的接收器的单个UDP数据流。显然，不同于固定网络，即使不存在去往相同接收器的竞争流量，移动数据网络可在短时段内(以及在未示出的长时段内)呈现明显的带宽波动。这对现有的链路属性估算算法造成根本的挑战，因为固定链路带宽的假设不再有用。

已知的用于估算链路缓冲器大小的算法是最大-最小[5-6]和丢包对[6]和在TCPVegas[7]、Veno[9]和FAST TCP[8]中使用的队列长度估算。考虑图2中所描绘的系统模型，其中单个发送器经由瓶颈链路将分组发送至接收器。瓶颈链路的参数不是已知先验的，并且传播延迟是恒定的。目标是经由对确认分组到达时间的观察，而在发送器处连续估算由q_i表示的队列长度和由L表示的链路缓冲器大小。表I总结了在下面讨论中使用的符号。

表1

Liu和Crovella[6]建议了最大-最小方法以从估算的传输延迟和最大往返时间(RTT)与最小往返时间(RTT)的差估算链路缓冲器大小。Claypool等人[5]还将最大-最小方法并入在接入网中使用的测量工具中。

最大-最小[5-6]方法和丢包对[6]方法的原理是使用RTT作为测量链路缓冲器大小的手段。具体地，设为总的下行链路传播延迟，T是一个分组的传输延迟，并且U是上行链路延迟，它们都是恒定的。接下来，设q_i为分组i在瓶颈链路上经历的排队延迟，并且n_i为在其到达队列时瓶颈链路缓冲器处已经排队等候的分组数。由rtt_i表示的用于分组i的RTT可从下式计算：

rtt_i＝P+T+U+q_i (1)

在固定带宽链路中，分组i的排队延迟简单地等于使已经在队列中的n_i个分组出列的总时间加上已经在服务中的分组的由rtt_i表示的剩余传输时间，即

q_i＝n_iT+δ (2)

给定链路缓冲器大小L，则n_i≤L-1。而且，剩余传输时间由δ≤T限定。因此，由q_max表示的最大排队延迟由下式给出：

q_max＝max{(L-1)T+δ}

＝LT (3)

当在分组到达时队列中没有分组时，最小排队延迟简单地等于0。由于传播延迟和传输延迟是恒定的，因此最大和最小RTT可从下式计算：

rtt_max＝P+T+U+q_max (4)

rtt_min＝P+T+U (5)

将(3)和(5)代入(4)中，得到

rtt_max＝rtt_min+LT (6)

类似地，将(2)和(5)代入(1)中，产生

rtt_i＝rtt_min+n_iT+δ (7)

重新整理(6)中的项，链路缓冲器大小可根据[4]被确定：

通过所测量的链路容量(C)和已知的分组大小(S)，估算的传输延迟(T)可从下式计算：

T＝S/C (9)

由此链路缓冲器大小可由下式确定：

最大-最小方法[5-6]被设计用于主动估算，其中发送器通过瓶颈链路以高于链路带宽的速率发送一系列测量分组以引起队列溢出。接收器为每个接收的分组将确认(ACK)分组返回发送器。发送器然后可根据ACK分组到达时间测量最小RTT rtt_min、最大RTT rtt_max和链路带宽C。对于S已知，发送器可使用(10)计算L。估算过程还可由接收器进行并且感兴趣的读者可更参考由Hirabru[4]的文献得到更多的细节。

从(10)可见，最大-最小方法的精确度取决于测量三个参数即rtt_max、rtt_min和C的精确度。具体地，如果存在共享同一瓶颈链路的背景流量，则通过竞争流调制RTT测量。

Liu和Crovella[6]通过它们改进的丢包对方法解决此问题。首先，在丢包事件之前和之后仅捕获两个分组的RTT。这过滤掉与瓶颈链路处的缓冲器溢出不相关的样本。其次，分析样本的分布来确定其数学模型以进一步过滤掉因背景流量引起的噪声。这两种技术提高了丢包对方法的精确度。

队列长度估算

当前没有被设计为仅用于队列长度估算目的的已知测量工具。不同于作为物理网络属性的链路缓冲器大小，队列长度可根据许多参数(包括所提供的流量负载、流量特性、链路容量等)随时间改变。因此队列长度测量仅在由传输和/或应用协议生成的实际数据流的上下文中有意义。

一些TCP变型实现算法以内隐地或明显地估算瓶颈链路处的队列长度用于拥塞控制目的。一个已知的实施例是TCP Vegas[7]，其采用算法以根据拥塞窗口大小和当前往返时间(RTT)与最小往返时间(RTT)的差估算队列长度。相似的算法还在TCP Veno[9]和FASTTCP[8]中被采用。

这些队列长度估算算法是固有被动的，因为仅实际的数据和ACK分组定时用于估算队列长度。在过程中没有生成额外的测量分组。

在操作期间，TCP发送器连续测量由rtt_i表示的RTT，并且在ACK分组i被接收的时候记录由cwnd_i表示的拥塞窗口大小。然后由下式追踪最小rtt_min：

然后在最后一个往返时间[7]中从所期望的吞吐量即cwnd_i×rtt_min与实际测量的吞吐量即cwnd_i×rtt_i的差计算由n’_i表示的估算的队列长度：

Vegas方法的一个缺点是，它使用当前拥塞窗口大小估算前一RTT中的队列长度。万一拥塞窗口大小明显不同于最后一个RTT，估算精确度将受到影响。这就是TCP Vegas仅在拥塞窗口大小缓慢改变的拥塞避免阶段执行队列长度估算的原因。

FAST TCP[8]通过追踪过去的拥塞窗口并且使用原始数据发送瞬间时刻的拥塞窗口计算(12)来解决此缺点。这提高了精确度，而且能够在慢启动阶段和拥塞避免阶段启用FAST TCP估算队列长度。

通过使用仿真，发明人通过使用UDP作为传输协议实现了最大-最小算法和丢包对算法，通过使用TCP CUBIC(Linux中的默认拥塞控制)作为传输协议实现了Vegas算法，并且通过使用图2中的网络设置进行仿真。

为了帮助评估，定义了两个性能度量，分别由E_A和E_R表示的所谓的绝对和相对链路缓冲器大小估算误差，以评估算法的性能：

E_A＝估算的链路缓冲器大小-实际的链路缓冲器大小 (13)

图3绘出了缓冲器大小为100至1000个分组的瓶颈链路的主动估算中的最大-最小和丢包对的估算误差。算法在固定带宽网络中良好地执行并不奇怪。它们的精确度也随链路缓冲器大小的增加(因(14)的分母增加)而提高。

两个队列长度估算算法(即TCP Vegas[7]中的Vegas算法和FAST TCP[8]中的FAST算法)都使用被动估算实现。另外，我们还在TCP CUBIC[14]上实现了Vages算法。在此情况下，TCP流根据TCP CUBIC操作，而RTT和拥塞窗口大小测量然后被馈送到Vegas算法中以计算估算的队列长度。此特殊组合使我们能够在互联网中被最广泛部署的TCP变型之一上评估Vegas估算算法的性能。

相对的队列长度估算误差Q_R和绝对的队列长度估算误差Q_A被定义为性能度量：

Q_A＝估算的队列长度-实际的队列长度 (15)

图4示出了用于固定瓶颈链路带宽的不同TCP变型中的相对队列长度估算误差的比较。曲线是瓶颈链路缓冲器大小范围为100至1000个分组下三种情况的估算误差。存在两个异常现象。首先，FAST TCP在所有情况下实现了最佳精确度，除了估算误差跳至60％左右的链路缓冲器大小为100个分组的情况之外。这是由FAST TCP[8]中的参数设置引起的，其中FAST TCP[8]规定了空中分组的目标数量以维持数据流。由于根据[8]的默认值为100个分组，这意味着如果瓶颈链路的缓冲器的大小接近或小于参数值则FAST TCP容易溢出瓶颈链路的缓冲器。结果FAST TCP的参数的调谐将对队列长度估算的性能具有显著影响。

其次，结果表示Vegas算法被应用至TCP Vegas流时与被应用至TCP CUBIC流时一样表现不佳。这是因为TCP Vegas算法与TCP CUBIC拥塞控制算法之间的差异。特别地，TCPVegas被设计为在瓶颈链路缓冲器中维持小数量的分组(在我们的仿真中为6个左右)。相比之下，TCP CUBIC更有进取性，在仿真中TCP CUBIC将平均队列长度维持在90％的链路缓冲器大小。因此，(14)中的分母越大导致TCP CUBIC的估算误差越低。

如果估算误差与图5中所示的分组的绝对数值相比，可看出与TCP Vegas和FASTTCP相比，TCP CUBIC没有呈现出更高的绝对误差。这是因为在TCP CUBIC中，窗口大小越大，拥塞窗口生长得越快。在缓冲器溢出发生之前大的链路缓冲器大小允许拥塞窗口生长得越大，因此在计算(12)中导致更高的估算误差，其中在(12)中当前的拥塞窗口大小用于替代之前RTT的窗口大小。FAST TCP没有受此问题影响，因为它记录过去窗口大小的顺序并且在计算(12)时使用正确的窗口大小，因此为宽范围的链路缓冲器大小维持一致的估算精确度。

如本文中所解释的，这些工具可用于评估根据本发明的新方法的效能。

本文中使用的引文如下：

[1]A.Akella、S.Seshan和A.Shaikh,“An Empirical Evaluation of Wide-AreaInternet Bottlenecks(广域互联网瓶颈的经验评估),”Proceedings of the ACMInternet Measurement Conference(IMC),2003年10月；

[2]K.Lakshminarayanan和V.Padmanabhan,“Some Findings on the NetworkPerformance of Broadband Hosts(对宽带主机的网络性能的一些发现),”Proceedingsof the ACM Internet Measurement Conference(IMC),2003年10月；

[3]V.Ribeiro、R.Riedi、R.Baraniuk,J.Navratil和L.Cottrell,“pathChirp:Efficient Available Bandwidth Estimation for Network Paths(pathChirp：用于网络路径的有效可用带宽估算),”PAM,2003；

[4]M.Hirabaru,“Impact of Bottleneck Queue Size on TCP Protocols andIts Measurement(瓶颈队列大小对TCP协议的影响极其测量)”,IEICE Transactions onInformation and Systems,第E89-D卷,第1期,2006年1月,第132-138页；

[5]M.Claypool、R.Kinicki、M.Li,J.Nichols和H.Wu,“Inferring Queue Sizesin Access Networks by Active Measurement(通过主动测量推理接入网中的队列大小)”,PAM,2004；

[6]J.Liu和M.Crovella,“Using Loss Pairs to Discover Network Properties(使用丢包对探索网络属性)”,ACM SIGCOMM Workshop on Internet Measurement,第127-138页,2001；

[7]L.S.Brakmo,S.W.O’Malley,and L.L.Peterson,“TCP Vegas:New techniquesfor congestion detection and avoidance(TCP Vegas：用于拥塞检测和逃避的新技术),”Proceedings of the SIGCOMM’94,London,U.K.,1994年10月,第24-35页；

[8]S.Hegde、D.Lapsley、B.Wydrowski、J.Lindheim、D.Wei、C.Jin、S.Low和H.Newman,“FAST TCP in High Speed Networks:An Experimental Study(高速网络中的FAST TCP：实验研究),”Proceeding of GridNets,2004年10月；

[9]C.P.Fu,and S.C.Liew,“TCP Veno:TCP enhancement for wireless accessnetworks(TCP Veno：用于无线接入网的TCP增强),”IEEE Journal of Selected Areas inCommunications,第21卷第2期,2003年2月；

[10]V.K.Garg,Wireless Network Evolution:2G to 3G(无线网络演进：2G到3G),Prentice Hall PTR,Upper Saddle River,NJ,USA,2001；

[11]E.Dahiman、S.Parkvall、J.Skold、P.Beming,3G Evolution:HSPA and LTEfor Mobile Broadband(3G演进：移动宽带的HSPA和LTE),2nd ed.,Academic Press,2008；

[12]D.Astely、E.Dahlman、A.Furuskar、Y.Jading、M.Lindstrom和S.Parkvall,“LTE:The Evolution of Mobile Broadband(LTE：移动宽带的演进)”,IEEECommunications Magazine,第47(4)卷,2009年4月,第44-51页；

[13]K.Liu和J.Y.B.Lee,“Mobile Accelerator:A New Approach to ImproveTCP Performance in Mobile Data Networks(移动加速器：提高移动数据网络中的TCP性能的新方法),”Proc.7th IEEE International Wireless Communications and MobileComputing Conference(IWCMC 2011),Istanbul,Turkey,2011年7月5-8日；

[14]A.B.Downey,“Using pathchar to estimate internet linkcharacteristics(使用pathchar估算互联网链路特性),”Proceedings of ACM SIGCOMM1999,1999年8月；

[15]S.Ha、I.Rhee和L.Xu,“CUBIC:A New TCP-Friendly High-Speed TCPVariant(新的TCP友好的高速TCP变型),”International Workshop on Protocols forFast and Long Distance Networks,2005；

[16]NS2,Network Simulator,http://www.isi.edu/nsnam/ns/；

[17]S.Floyd、J.Mahdavi、M.Mathis和M.Podolsky,An extension to theselective acknowledgement(SACK)option for TCP(TCP的选择确认(SACK)选项的延伸),Request for Comments 2883,2000；

[18]FAST TCP ns2 module(FAST TCP ns2模块),http://www.cubinlab.ee.unimelb.edu.au/ns2FASTtcp/；

[19]O.Ait Hellal,E.Altman“Problems in TCP Vegas and TCP Reno(TCPVegas和TCP Reno中的问题)”,DNAC Cong.(De Nouvelles Architectures pourlesCommunications),UVSQ,Paris,1996年12月3-5日；

[20]S.Mascolo、C.Casetti、M.Geria、M.Y.Sanadidi和R.Wang,“TCP Westwood:Bandwidth Estimation for Enhanced Transport over Wireless Links(TCP Westwood：用于无线链路上的增强的传输的带宽估算),”in Proceedings of ACM SIGMOBILE,2001年7月；

[21]Apache,http://www.apache.org/；

[22]Wget,http://gnuwin32.sourceforge.net/packages/wget.htm；

[23]Wireshark,http://www.wireshark.org/。

发明内容

根据本发明，提供了在数字移动通信带宽变化网络中使用延迟之和算法以在底层网络连接中估算链路缓冲器大小和队列长度的方法。在具体实施方式中，延迟之和算法使用主动估算和被动估算实现。与过程相关的机制补偿链路带宽变化。本发明可在变化带宽条件(例如，无线网络)下精确地估算链路缓冲器大小并且在固定和变化带宽条件下比传统技术优多个数量级。

在具体实施方式中，被动估算被采用以通过简单测量带内数据分组定时执行估算来实现此过程，从而避免额外测量分组的传输。此方法能够将链路缓冲器大小估算算法融合到现有的传输协议(例如，TCP)中以优化拥塞控制。作为本发明的一部分，新的拥塞控制方法，所谓的队列长度自适应(TCP-QA)，被开发以在TCP发送方计算机中采用延迟之和算法来控制TCP连接中的数据流。与现有的TCP变型相比，TCP-QA可在带宽变化的网络中实现明显更好的网络带宽利用率。

链路缓冲器大小的精确估算具有许多显著的优点。首先，传输协议(例如，TCP)原始被设计用于链路缓冲器大小通常较小(例如每个端口几十千字节)的有线网络。在缓冲器大小常为几百千字节的移动数据网络中情况就不同了，正因如此TCP在移动数据网络中常常运行欠佳。因此链路缓冲器大小的知识能够开发为移动数据网络优化的新一代TCP变型。

其次，许多应用协议采用来自接收器的反馈调节业务流。大的链路缓冲器的存在可将实质延迟引入反馈并且潜在地造成闭环控制协议中的稳定性问题。链路缓冲器大小的知识能使这些协议补偿额外的延迟并且确保移动数据网络上的稳定操作。

第三，估算瓶颈链路处的队列长度的能力开创了一种使移动运营商监视他们的用户和蜂窝基站的性能的新方式。由于移动网络的固有带宽波动，与链路/传输层吞吐量测量相比，队列长度潜在地在反映移动用户体验的利用率和拥塞等级时更精确。

通过结合附图参考下面的详细描述将更好地理解本发明。

附图说明

图1是示出了现有技术的测量的带宽的时序图；

图2是示出了现有技术的链路缓冲器大小估算的系统模型的框图；

图3是示出了固定瓶颈链路带宽的估算误差的比较的图表；

图4是示出了固定瓶颈链路带宽的各种TCP变型中的队列长度估算误差的图表；

图5是示出了固定瓶颈链路带宽的不同TCP变型中的队列长度估算算法中的绝对队列长度偏差的比较的图表；

图6是示出了变化瓶颈链路带宽的相对链路缓冲器大小估算误差的比较的图表，其中L是实际的链路缓冲器大小；

图7是示出了变化瓶颈链路带宽的不同TCP变型中的相对队列长度估算误差的比较的图表；

图8是示出了变化瓶颈链路带宽的不同TCP变型中的队列长度估算算法中的绝对队列长度偏差的比较的图表；

图9是示出了瓶颈链路带宽的变化效果被并入链路缓冲器大小估算中的系统模型的框图；

图10是示出了固定瓶颈链路带宽的主动估算的估算误差的比较的图表；

图11是示出了固定瓶颈链路带宽的被动估算的估算误差的比较的图表；

图12是示出了根据本发明的变化瓶颈链路带宽的主动估算的估算误差的比较的图表；

图13是示出了根据本发明的变化瓶颈链路带宽的被动估算的估算误差的比较的图表；

图14是示出了固定瓶颈链路带宽的各种TCP变型中的相对队列长度估算误差的比较的图表；

图15是示出了固定瓶颈链路带宽的各种TCP变型中的队列长度估算算法中的绝对队列长度估算的比较的图表；

图16是示出了变化瓶颈链路带宽的各种TCP变型中的相对队列长度估算误差的图表；

图17是示出了变化瓶颈链路带宽的各种TCP变型中的绝对队列长度估算误差的图表；

图18a是示出了固定瓶颈链路带宽为0.8Mbps的主动估算的估算误差与估算持续时间之间的比较的图表；

图18b是示出了固定瓶颈链路带宽为4.8Mbps的主动估算的估算误差与估算持续时间之间的比较的图表；

图18c是示出了固定瓶颈链路带宽为7.2Mbps的主动估算的估算误差与估算持续时间之间的比较的图表；

图19a是示出了固定瓶颈链路带宽为0.8Mbps的被动估算的估算误差与估算持续时间之间的比较的图表；

图19b是示出了固定瓶颈链路带宽为4.8Mbps的被动估算的估算误差与估算持续时间之间的比较的图表；

图19c是示出了固定瓶颈链路带宽为7.2Mbps的被动估算的估算误差与估算持续时间之间的比较的图表；

图20是示出了变化瓶颈链路带宽的主动估算的估算误差与估算持续时间之间的比较的图表；

图21是示出了变化瓶颈链路带宽的被动估算的估算误差与估算持续时间之间的比较的图表；

图22是示出了根据本发明在发送主机处执行延迟技术的总和的装置的框图；

图23是延迟算法的总和的伪代码清单；

图24是主动估算系统的框图；

图25是延迟之和的被动估算的方法中修改的LINUX内核的描述；

图26是核心TCP-QA程序的流程图；

图27是在操作系统中实现延迟技术总和的系统的功能框图；

图28是在应用程序中实现延迟技术总和的系统的功能框图；以及

图29是根据本发明的具有移动无线设备和互联网通信的数据通信系统的高级框图，其示出了具有被动、实施网络监视设备的移动操作系统基础设施网络。

具体实施方式

为了在估算链路缓冲器大小和队列长度中并入带宽变化效果，必须找到使该效果可被间接测量然后并入到估算模型中的手段。

图9描绘了具有变化瓶颈链路带宽的网络的修订网络模型。链路带宽的变化将显示为分组传输时间的变化。特别地，当分组通过瓶颈链路传输时，分组传输时间等于分组大小除以平均带宽。设t_i为分组i的传输时间，则可并入系列{t_i}的带宽变化的效果，t_i可从分别由r_i和r_i-1表示的分组i和(i-1)的测量的ACK分组到达间隔时间计算得到，假设链路在此时间段内不会空闲：

t_i＝r_i-r_i-1 (17)

考虑分组i到达瓶颈链路，发现n_i个分组已经在排队以及分组(i-n_i-1)当前正被传输的情况。然后由q_i表示的分组i的排队延迟等于使所有n_i个分组出列的总时间，即分组(i-1)至(i-n_i)的传输延迟的总和加上由δ_i表示的传输分组(i-n_i-1)的剩余时间：

剩余传输时间δ_i的上限为分组的传输延迟并且其下限为0，即

将(19)的界限代入(18)，可获得q_i的相应界限：

或

现在传输延迟{t_k}可使用(17)从测量的ACK分组到达间隔时间计算。为了确定作为分组i到达瓶颈链路时的队列长度的n_i，必须首先得到q_i。

显然，由于带宽变化，排队时间q_i不能直接被测量。然而，能够获得q_i的下限。

特别地，考虑由发送器测量的分组i的RTT：

并且所测量的最小RTT将等于

将(21)减去(22)得到

然后重新排列项，得到q_i的下限：

q_i＞rtt_i-rtt_min-t_i (24)

此下限必须满足(20)中的上限，因此可增大(20)中的n_i值直到其R.H.S变为大于(24)中的下限：

满足上限和下限的最小n_i变为估算的队列长度n_i’。链路缓冲器大小然后可从所有队列长度估算的最大值计算得到：

值得注意的是，上面的估算方法是近似法，因此可能高估或低估链路缓冲器大小。估算精确度在下文被评估。

将发明应用至传输协议

延迟之和方法需要被实现和融合到传输或应用协议中，以在网络流量控制(例如，拥塞控制或流量路由)中利用链路缓冲器大小和队列长度信息。本部分探讨实现该目的的两种一般方法，即主动估算和被动估算。

在这两种情况下都需要两个测量参数：分组的传输延迟和往返时间。前者可从ACK分组到达间隔时间计算得到，而后者可从分组的发送时间与其ACK接收时间的差计算得到。图23概述了延迟之和算法的简化伪代码，图22描绘了实现该方法的装置。参考图22，部件在发送主机中实现以响应来自网络接口的ACK分组。在内部时钟控制下的操作，ACK接收时间测量模块测量r_i并且将其传送至传输时间估算模块来执行等式17，等式17的结果被提供作为队列长度估算模块的一个输入。通过使用分组发送时间记录，往返时间测量模块执行等式21，并且将其结果提供给排队时间估算模块，排队时间估算模块根据等式22-24执行，提供其输出作为队列长度估算模块的第二输入，而队列长度估算模块根据等式25处理其输入。结果被提供给链路缓冲器大小估算模块，链路缓冲器大小估算模块执行等式26，结果根据本发明作为估算的队列长度记录。

主动估算

在主动估算中，系统如图24所示可生成明显测量分组并且以受控的传输速率发送分组以便于链路缓冲器大小估算。特别地，如上面所讨论的，传输延迟计算的精确度依赖于如下假设：瓶颈链路在测量周期不会空闲或者链路缓冲器大小可能被低估。

由于主动估算允许发送器简单地通过以期望的数据速率生成测量分组而直接控制传输速率，因此我们可通过以足够高的数据速率发送测量分组或者逐渐增加发送速率直到瓶颈链路上队列溢出，来满足所述假设。注意这需要使用UDP作为底层传输，因为TCP的内置流和拥塞控制模块将干扰发送速率控制。在接收器侧需要为每个接收的测量分组生成ACK分组并且发送回ACK分组使得发送器可计算两个测量参数。

在实践中，主动估算将更适于在网络测量工具中使用以测量链路缓冲器大小，因为传输协议的选择和明显测量流量的生成可容易地被支持。

被动估算

在被动估算中，系统不被设计为生成任意明显测量分组而是被设计为依赖于对正常数据分组传送的测量。估算过程可被并入Linux内核实现，如图25所示。唯一的修改是计算传输延迟(步骤A)，将其保存到内核(步骤B)并且一旦接收到有效的ACK就使用延迟之和模块计算估算的队列长度(步骤C)。在修改客户端软件不一定每次都可行的情况下或者当传输协议受限于TCP时，此方法最适于与现有应用(例如，视频流)融合。

被动估算的主要挑战是缺乏对数据发送速率的控制。在例如TCP的情况下，其内置流和拥塞控制算法限制受客户端和网络条件约束的发送速率。在例如丢包情况下，TCP的发送速率将显著下降，由此影响(17)中的分组传输延迟的测量精确度。

存在两种方式来解决此问题，首先，由于发送器可经由TCP中的双重ACK识别拥塞事件，因此可在TCP的拥塞恢复阶段过滤掉测量样本。其次，TCP的拥塞控制算法可被修改以适应发送速率的明显控制，从而提高测量精确度。

延迟之和系统和方法的实现

根据本发明的延迟之和(SoD)技术可在系统中以多种方式实现，包括但不限于操作系统中的传输协议(例如，TCP)的一部分、操作系统中的应用程序接口(API)的一部分、客户端或服务器或两者中的互联网应用的一部分、以及经由窃听器监视网络流量的被动网络监视设备的一部分。

参考图27，作为说明性，本发明的SoD技术100可被并入操作系统中作为通过网络接口(NI)104通信的互联网协议(IP)102与通过TCP变型108通信的基于TCP的应用106之间的内核(例如，Linux内核)的一部分。可选地，它可被实现为操作系统的一部分以通过SoD数据API 112与其它应用110通信。实现两种操作系统技术的具体步骤包括为ACK分组到达时间打上时间戳(步骤AA)然后根据等式21、21和24(步骤AB、AC)和等式17和20(步骤BB、BC)执行计算以根据等式25和26为估算队列长度和链路缓冲器大小提供输入(步骤AD)。结果被应用至基于TCP或不基于TCP的目标应用。

作为又一可选项，参考图28，SoD技术可被实现为经由在互联网协议(IP)或IP上的UDP(116)上运行的特定应用协议114通信的应用程序的元素，其IP或IP上的UDP(116)又在网络接口104上运行。基于应用的技术的步骤基本与操作系统实现和被动网络监视设备的一部分相同。输出是瓶颈链路缓冲器大小和正在运行的队列长度的估算。

参考图29，SoD实现被显示为被动网络监视设备120的一部分。应用层性能监视器122执行图28或图27的技术，通过网络分流器124接收数据和在基于针对网络操作中心128的输出而证明实时性能查看的同时将输出存储在跟踪数据数据集126中。网络分流器124被设置于通过收发器接口140在互联网136与无线网络138之间路由分组的路由器130、132之间。在这种方式，移动运营商基础设施网络142桥接在具有各种服务器144、146的互联网136与移动电话148之间，其中移动电话148与无线接入点150通信。

延迟之和算法的使用

根据本发明的延迟之和算法已经被显示为在网络的队列长度和链路缓冲器大小估算中具有精确的性能。除了链路缓冲器大小估算之外，所建议的算法还可用于连续估算TCP流的队列长度，以估算其在网络缓冲器中的资源消耗。以这种方式，我们可评估和分析不同网络环境下的不同TCP变型的性能。这些信息例如对提高不同场景下的TCP变型的性能有用，我们可将目标队列长度占用率设置得足够高以提高网络利用率(尤其带宽变化的网络链路中)，但是不会过高从而发生链路缓冲器溢出。这使得TCP发送器更好地控制传输速率以增加带宽变化网络中的带宽利用率，其中传统的TCP拥塞控制将或过于激进(导致链路缓冲器溢出)或过于保守(导致带宽利用率低)。

所谓的TCP队列长度自适应(TCP-QA)的新颖传输协议已经被实现，其展示了并入延迟之和方法以连续估算队列长度用于传输速率控制和拥塞控制的一种方式。

TCP队列长度自适应(TCP-QA)

TCP在许多年前被开发并且自那之后已经发展了许多年。然而其设计仍然基于链路带宽相对恒定且链路缓冲器大小相对小的固定网络模型。然而，这些假设在移动和无线网络中不再有效，在移动和无线网络中链路带宽变化是基准而非异常。而且，由于无线网络中的较高误比特率，大多数无线网络实现链路层的误差控制，结果它们需要维持相对大的链路缓冲器以进行链路层误差控制。最后，甚至链路层误差控制可能不能恢复所有传输误差，并且因此非拥塞引起的丢包在无线网络中是常见的。

所有这些因素负面影响了无线网络中的传统TCP的性能。这些和其它挑战被下面描述的所建议的TCP-QA协议解决。值得注意的是，TCP-QA仅需要修改TCP发送器。它与现有的传统TCP接收器兼容。

TCP-QA包括三个阶段：突发启动阶段、慢减缩阶段、突发初始化阶段。前两个阶段发生在TCP的原始拥塞避免阶段和慢启动阶段中。第三个阶段仅在TCP变型开始时操作。TCP-QA的原理是，根据由队列长度估算算法(例如延迟之和算法)估算的队列长度，用可配置的目标队列长度(由target_qs表示)调整发送速率，以控制在网络缓冲器处排队等候的分组数。此目标队列长度是可调谐的，并且根据底层网络属性被调整。目标队列长度的值应该小于网络的链路缓冲器大小以防止拥塞。此参数的物理影响是，在瓶颈链路的缓冲器中维持充足数量的分组，使得当带宽变化(例如，向上变化)时，在缓冲器中存在可用的充足分组以利用可用的带宽，因此防止瓶颈链路空闲(浪费带宽)。TCP-QA的一个具体实施方式的伪代码在下面列出，其中TCP_QA_CA()为控制传输速率的拥塞控制模块、TCP_QA_SSTH()为对丢包事件做出反应的模块、TCP_QA_INIT()为TCP流开始时执行一次的突发-初始化阶段。变量Queue_length表示使用队列长度估算算法(例如延迟之和算法)估算的瓶颈链路处的当前队列长度。图26概述了TCP-QA程序的流程图。这些伪代码和流程图用于示出队列长度信息至传输协议(例如，TCP)中的拥塞控制的一个可能应用。TCP_QA_CA()的伪代码产生了拥塞控制方法的具体步骤，包括初始化阶段(TCP_QA_INIT())、拥塞避免阶段(TCP_QA_CA())和慢启动阈值的更新(TCP_QA_SSTH())。这已经在Linux中实现并且在实际的网络中被测试。

TCP_QA模块的伪代码

TCP_QA中的突发-初始化阶段(TCP_QA_INIT)允许TCP连接以在较高的发送速率下生长但是不会溢出接收器缓冲器大小。在突发-启动阶段，只要估算的队列长度小于目标阈值(即，target_qs)，则经历突发-启动阶段以逐渐增加其发送速率直到队列长度超过目标值(参见TCP_QA_CA的“if”部分)。然后，经历慢减缩阶段以逐渐减少其发送速率直到队列长度到达目标值(参见TCP_QA_CA的“else”部分)并且再次进入突发-启动阶段。当丢包事件发生时，根据队列长度信息确定发送速率，以防止因随机丢包引起的不必要的发送速率下降(参见TCP_QA_SSTH)。

TCP-QA可被实现为图10中的修改内核内的可插式模块。在这种情况下它与Linux内核内的现有拥塞控制模块接口兼容。

性能评估

作为本发明的一部分，如上所述进行大量仿真并且进行性能评估，其结果已在同行评议的杂志中报告。为了完整性，本文中包括此评估结果。

SoD的估算精确度已通过使用NS2[16]实现的仿真器与现有技术进行比较。值得注意的是，尽管NS2已经具有内置的TCP实现，但是它们的实现偏离现今以重要的方式在互联网中使用的实际TCP实现。因此，仿真器基于当前Linux内核中的实际TCP实现而实现并且还通过广泛部署的任选TCP特征(例如，TCP SACK[17])被实现以建立更理想的仿真平台。

表II

图9中描绘了仿真的网络技术，并且表II概括了仿真参数。对于被动估算，TCP被采用作为传输，并且发送器简单地以TCP允许的速度尽可能快地发送数据。来自Linux 2.6的TCP CUBIC[14]内核模块被并入仿真器中，因为它是互联网中最广泛使用的TCP变型。附加地，TCP SACK[17]在仿真器中被实现以更精确地模拟实际的TCP行为。为了比较目的，TCPVegas[7]上的SoD通过将其Linux内核模型并入NS2中被实现。

最后，由于开放源Linux内核当前不实现FAST TCP，在这些仿真中采用由CUBINLab[18]开发的FAST TCP NS2模型。

固定带宽网络中的链路缓冲器大小估算

首先考虑使用主动估算来估算具有固定瓶颈链路带宽的网络中的链路缓冲器大小的基线情况。表III和图10比较最大-最小、丢包对和延迟之和算法的估算误差。最大-最小和丢包对在此设置中良好地执行并不奇怪，在所有的情况下估算误差低于2％。本发明的延迟之和方法以0误差(至小数点后两位)实现非常精确的估算。而且，与估算误差随链路缓冲器大小变小而增大的最大-最小/丢包对相反，延迟之和方法的精确度对所有链路缓冲器大小而言都是一致的。

表III

接下来研究被动估算，在被动估算中没有生成明显测量分组。仅从根据TCP CUBIC的流和拥塞控制算法被控制和调度的正常数据分组的定时来计算估算。尽管这不是最大-最小/丢包对的原始期望应用，但是表IV和图11中的结果表明它们的性能没有明显差于它们的固定带宽副本。对大多数链路缓冲器大小范围(例如，从300至1000)而言，所建议的SoD算法仍然优于最大-最小/丢包对。

表IV

可变带宽网络中的链路缓冲器大小估算

带宽变化的网络仿真运行包括从生产3G/HSPA网络获得的10份实际带宽跟踪数据以调制图9中的瓶颈链路的带宽。跟踪数据通过使用USB 3G/HSPA调制解调器在与3G/HSPA网络连接的移动计算机处被捕获。客户端计算机在跟踪捕获过程中保持静止。因此它没有并入移动性引起的带宽波动的效果。

表V和表VI比较分别在主动估算和被动估算下的三种估算算法的估算误差的平均值和标准偏差。结果还在图12和图13中可视给出，其中标准偏差由误差条指示。

表V

表VI

首先，与固定带宽情况相比，最大-最小的性能在变化带宽的情况下明显降低。这在估算误差超过100％的较小链路缓冲器大小(例如，L＝100,200)的情况下尤其显著。低性能的原因是导致传输延迟显著变化的带宽变化。由于最大-最小方法是基于最大RTT与最小RTT的差，因此传输延迟变化使链路缓冲器大小估算显著失真。

其次，在主动估算下，丢包对算法基本优于最大-最小执行。这是因为丢包对不基于最坏情况测量实现其估算，但是确定所测量的样本的数学模型以过滤掉噪声[6]。

比较表VI中的被动估算结果与表V中的主动估算结果，将观察到对于最大-最小算法和丢包对算法，估算误差还在增加。相反，根据本发明的SoD实现低水平的估算误差，在所有情况下都小于0.8，这比最大-最小和丢包对低两个数量级。

固定带宽网络中的队列长度估算

在TCP流上评估队列长度估算算法，即数据流由底层TCP流和拥塞控制模块调节。在三个队列长度估算算法即Vegas、FAST和本发明的SoD与三个TCP变型即TCP CUBIC、TCPVegas和FAST TCP之间，存在六个研究的组合：

·TCP CUBIC上的Vegas—在TCP CUBIC流的拥塞避免阶段使用Vegas方法估算队列长度；

·TCP Vegas上的Vegas—在TCP Vegas流的拥塞避免阶段使用Vegas方法估算队列长度；

·FAST TCP上的FAST—在FAST TCP流的慢启动和拥塞避免阶段使用FAST方法估算队列长度

·TCP CUBIC上SoD—在所有三个阶段即TCP CUBIC流的慢启动、拥塞避免和丢包恢复阶段使用SoD方法估算队列长度；

·TCP Vegas上的SoD—在所有三个阶段即TCP Vegas流的慢启动、拥塞避免和丢包恢复阶段使用SoD方法估算队列长度；

·FAST TCP上的SoD—在所有三个阶段即FAST TCP流的慢启动、拥塞避免和丢包恢复阶段使用SoD方法估算的队列长度。

图14和图15比较固定瓶颈链路带宽网络中六种组合的相对和绝对估算误差。除了100个分组的链路缓冲器大小之外，FAST算法优于Vegas估算算法的两种情况。FAST算法的异常也是因为其目标队列长度设置(默认为100个分组)太接近链路缓冲器大小，因此导致频繁的缓冲器溢出。

相反，本发明的SoD方法的运行优于所有TCP变型。表VII显示对所有三个TCP变型在所有链路缓冲器大小上估算误差不高于0.1％，其表明SoD性能一致而不管底层传输协议中的实质变化。

表VII

可变带宽网络中的队列长度估算

接下来使用从生产3G/HSPA网络捕获的带宽跟踪数据研究移动数据网络中的算法性能。

图16和图17绘出了移动数据网络上的六种组合的相对和绝对估算误差。相同的结果还在表VIII中列出。与部分C中的固定带宽情况相比，所有三个现有估算算法的估算精确度在可变带宽网络中显著增加。FAST TCP上的FAST的估算精确度的劣化尤其明显(例如，对于L＝300，0.48％至14.3％)。其原因尚不清楚，FAST TCP算法的进一步分析将确保识别其原因。

表VIII

在比较中，所有SoD情况一致实现低水平的估算误差，在所有情况下低于1％，因此比现有的算法优多个数量级。这清楚地表明SoD在估算可变带宽网络中的队列长度方面的优越性。

收敛

链路缓冲器大小估算算法需要花费时间来收集测量数据以提高估算精确度。因此，使用主动和被动估算在固定和可变带宽网络中调查最大-最小、丢包对和SoD的收敛速率。

首先，考虑固定带宽网络中的主动估算的基线场景。图18a至图18c分别绘出了0.8Mbps、4.8Mbps和7.2Mbps瓶颈链路带宽的相对估算误差。具有三个观察。首先，0.8Mbps情况与两个更高带宽情况相比花费更长的时间达到精确估算(20秒vs 4秒)。这是所期望的，因为测量数据被收集的速率与链路带宽成正比。其次，所有三种算法一旦收敛则保持精确。第三，最大-最小和SoD比丢包对收敛得更快，这是因为后者的设计是从所收集的样本的数学模型确定估算。

接下来考虑固定带宽网络中的(TCP CUBIC上的)被动估算的情况。图19a至图19c分别绘出了0.8Mbps、4.8Mbps和7.2Mbps瓶颈链路带宽的相对估算误差。与主动估算情况相比，在此情况中SoD算法比最大-最小算法收敛得更快，尤其在两个更高带宽情况中(参考图19b和图19c)。值得注意的是，收敛时间一般类似于主动估算情况。这是由于所采用的TCP变型即CUBIC，其收敛控制算法倾向于在瓶颈链路中构建长分组队列。

接下来考虑变化带宽环境，结果更有意思。图20和图21分别比较主动和被动估算中的算法。一个明显的观察是最大-最小算法不会收敛。从低估的链路缓冲器大小开始，估算的链路缓冲器大小连续增加以在5秒之后变成过估。原因是最大-最小假设恒定的分组传输时间，这在带宽变化网络中是不真实的。带宽变化调制传输时间，因此将误差引入估算的结果。由于最大-最小估算是基于最大和最小测量样本之间的差别，该差别清楚地随着所收集的样本越多而增大。这又表明了不被设计用于带宽变化网络的最大-最小算法不适于在移动数据网络中使用。

相反，本发明的SoD技术一致地执行并且能够在4秒至5秒内到达精确估算，即使在带宽变化网络上的被动估算的极端情况中。

被动估算中的限制

Vegas队列长度估算算法受限于TCP拥塞避免阶段，并且FAST TCP的算法受限于TCP的慢启动和拥塞避免阶段。相反，本发明的SoD技术可被应用于TCP的所有三个阶段，因为它在其估算时不依赖于TCP的拥塞窗口。

为了进一步调查它们在不同TCP阶段的性能，我们在分别用于固定(C＝7.2Mbps，L＝700个分组)和变化(在10组带宽跟踪上平均)带宽情况的表IX和X在单独为三个TCP阶段列出估算误差。SoD不仅在所有三个阶段中起作用，它还一致比Vega和FAST算法优多个数量级。丢包恢复阶段中的SoD的一致精确度在非拥塞引起的丢包常见的移动数据网络中是尤其期望的属性。

表IX

表X

最后，如上面的仿真结果所示，本发明的延迟之和技术在链路缓冲器大小和队列长度估算中一致地实现非常低的估算误差，在大多数情况下不多于1％，即使在大多数具有挑战性的条件下。这证实了通过在估算链路缓冲器大小和队列长度中并入测量的传输延迟，我们可有效地并入和补偿链路带宽变化。延迟之和技术是应用至两种网络测量工具的有力候选者(甚至在短命测量中)，也是被融合到现有传输/应用协议中的带内测量的有力候选者。

已经参考具体实施方式解释了本发明。对本领域技术人员而言其它实施方式是明显的。本发明具有许多用途并且是开发其它发明的机制。链路缓冲器大小和队列长度的知识可在各个层中被利用以增强网络应用的性能。例如，传输层协议(例如，TCP)可被修改以融合延迟之和算法以执行链路缓冲器大小的被动估算，从而后者可在其拥塞控制算法中被利用以在防止网络拥塞的同时提高带宽利用率。上面描述的TCP-QA模块是实现它的具体方法。在应用层，延迟之和算法还可被采用以将链路缓冲器大小和队列长度信息并入拥塞控制、资源分配、流量监管、误差控制等。因此，本发明不应该被认为受限，除了所附权利要求所指示的。

Claims

1.一种在数字计算机中操作的方法，包括：

估算经由受可变带宽影响的无线网络发送的分组的分组传输延迟；

将已在排队的全部分组和当前正在传输的分组的分组传输延迟之和作为在发送器与接收器之间经由所述无线网络发送的分组的排队延迟的上限，并将所述发送器测量的当前到达瓶颈链路的分组的往返时间减去最小往返时间并减去所述当前到达瓶颈链路的分组的分组传输延迟得到的差值作为所述排队延迟的下限，估算使所述上限大于所述下限的最小队列长度，作为网络队列长度。

2.根据权利要求1所述的方法，其中所述分组传输延迟之和包括被动估算中的带内数据和ACK分组定时的测量，以避免额外测量分组的传输。

3.根据权利要求1所述的方法，其中所述网络队列长度的估算结果用于通信协议中的拥塞控制。

4.根据权利要求3所述的方法，其中，所述方法适于被并入到传输协议中。

5.根据权利要求3所述的方法，其中，所述方法适于被并入到传输协议TCP-QA中，所述TCP-QA仅在所述发送器实现，并且与现有的标准TCP接收器兼容。

6.一种在计算机中操作的方法，包括：

估算经由无线网络发送的分组的分组传输延迟；

将已在排队的全部分组和当前正在传输的分组的分组传输延迟之和作为在发送器与接收器之间经由所述无线网络发送的分组的排队延迟的上限，并将所述发送器测量的当前到达瓶颈链路的分组的往返时间减去最小往返时间并减去所述当前到达瓶颈链路的分组的分组传输延迟得到的差值作为所述排队延迟的下限，估算使所述上限大于所述下限的最小队列长度，作为网络队列长度；以及

根据估算的网络队列长度估算网络链路缓冲器大小。

7.根据权利要求6所述的方法，其中所述分组传输延迟之和包括在被动估算中测量带内数据和ACK分组定时，以避免额外测量分组的传输。

8.根据权利要求6所述的方法，其中所述网络链路缓冲器大小根据在所有队列长度估算中取最大值而估算。