延迟抖动在TFRC拥塞控制策略中的应用

谭志勇，赵甫哲

(1.武汉软件工程职业学院现代教育技术中心，湖北 武汉 430033； 2.华中师范大学计算机学院，湖北 武汉 430079)

1 概 述

当今的Internet中，在线影音、视频会议等大量多媒体实时业务得到了广泛应用，多媒体流占据了Internet整体流量相当大的部分，而Internet上的业务流主要是基于TCP和UDP这2种基本传输协议的。多媒体流的传输过程中，能够容忍少量报文的丢失，但实时性和速率的平滑性却至关重要。TCP协议虽然拥有比较好的拥塞控制机制，但是其采用的AIMD策略会导致发送速率出现较大的波动，难以满足多媒体流发送速率平滑的要求[1]。因此目前大量多媒体实时业务采用的是无连接的传输协议UDP,但UDP协议最大的缺点是没有任何拥塞控制机制，当UDP流与TCP流共享网络带宽时，UDP流显得非常具有“竞争性”。一旦发生网络拥塞，在TCP流自动减低发送速率的同时，UDP流仍以原定速率向网络中发送数据[2]。这样，UDP流就不公平地获得了原应属于TCP流的大量带宽，并导致网络拥塞的加剧，甚至可能造成网络的崩溃。

为了解决上述问题，国内外研究者为Internet上多媒体流的传输提出TCP-Friendly拥塞控制机制，这里“TCP-Friendly(TCP友好)”的定义是“非TCP流在长期范围内吞吐率不超过相同情况下的TCP流的吞吐率”。在诸TCP-Friendly拥塞控制机制中，由Floyd设计的TFRC(TCP-Friendly Rate Control)算法得到广泛认同[3]，该机制已形成FRC3448[4]。TFRC的核心思想是多媒体实时业务的发送方根据TCP的吞吐率公式来调节发送速率，以此实现对TCP流的公平性。

2 TFRC分析

在TFRC中，接收方计算丢失事件率并反馈给发送方，发送方据此判断网络状况并平滑地调整发送速率[5]。这里的平滑是指发送速率的变化在长时间跨度下能对网络变化趋势及时进行响应，而在短时间跨度下能尽量不出现大的波动。一个图像质量稍差但稳定的视频给人的主观感受要比一个图像质量很高但频繁变化的视频要好，所以保持视频流的稳定很重要，这就要求发送速率的变化要尽可能地平滑[6]。

2.1 TFRC拥塞控制的工作机制

TFRC拥塞控制的工作机制分为以下3个步骤：

1)发送方发送数据分组至接收方，接收方据此计算丢失事件率并将其反馈给发送方；

2)发送方利用收到的反馈分组里的信息，计算往返时间和超时重传时间，然后将其和丢失事件率代入TCP吞吐量公式，计算出相应的TCP发送速率；

3)发送方根据计算结果更新发送速率。

从上述分析可知，TFRC算法的关键是吞吐量模型的选择，而模型里所含有的参数影响着最终的发送速率。

2.2 吞吐量模型

TFRC中采用了最常用的TCP吞吐率公式——TCP Reno的简化形式[7]：

(1)

其中,X表示吞吐率(B/s)；S表示数据包的大小(B)；tRTT表示往返时间(s)；b表示TCP接收方一次确认的包数，通常为1；P表示丢失事件率；tRTO表示重传超时值，一般取4tRTT。

2.3 计算往返时间RTT

当发送方在Trec_ack时刻收到来自接收方的反馈分组时，能从该反馈包中得到：

1)接收方收到的最后一个数据分组的时间戳Tsend_data(即发送方发送该数据分组的时刻)；

2)接收方从收到这个数据分组到发送该反馈分组之间的时间延迟Tdelay。

发送方据此计算当前的往返时间RTTnow为：

RTTnow=(Trec_ack-Tsend_data)-Tdelay

(2)

如果发送方以前没有收到过反馈分组，则新的RTT估计值为RTTnow；否则，为避免一次往返时间RTT的样本对发送速率有过大的影响，可加入滤波因子[8]，新的RTT的估计值为：

RTTnew=α×RTTold+(1-α)×RTTnow

(3)

其中，RTTnew表示新的经过滤波的往返时间，RTTold表示上一次经过滤波的往返时间，α为滤波因子，FRC3448中推荐的α值为0.9。

2.4 计算丢失事件率P

在TFRC中，一次丢失事件是指在一个RTT时间内数据包的丢失[9]。接收方维护一张表，该表用下面3种标记来记录发送方发送数据包的接收情况：REC表示成功接收的包；LOSS表示一次丢失事件的第一个丢包；NOT_REC表示其他的丢包。

接收方通过这张表来计算丢失事件率P。在TFRC中，2个连续丢失事件的LOSS包序列号之差被称为丢失事件间隔。如果一个丢失事件k的LOSS包序列号为Sk，丢失事件k+1的LOSS包序列号为Sk+1，那么丢失事件间隔Ik定义为：

Ik=Sk+1-Sk

(4)

为避免瞬时的变化引起发送速率的剧烈波动，丢失事件率P的计算采用了加权平均丢失间隔算法[10]，即设最近n次的丢失间隔为Ik，…，Ik-n+1，wi为加权值，则加权平均丢失间隔Iavg(k)为：

(5)

事件丢失率P为Iavg(k)的倒数，即：

(6)

n的取值决定了TFRC对网络拥塞反应的敏感度，一般取8。当n=8时，w0到w7的值为1.0，1.0，1.0，1.0，0.8，0.6，0.4，0.2。

2.5 调整发送速率

若发送方收到反馈，如果有丢失事件发生，则按照公式(1)的计算结果对当前发送速率进行更新；如果丢失事件率P为0，则发送方进入慢启动阶段，发送速率在每个RTT时间内加倍，直至有丢失事件发生。算法的伪代码描述如下：

getAck();//发送方收到反馈包

if(P﹥0)

//有丢失事件发生，按公式(1)计算X并调整发送速率

sendRate=max(min(X, 2Xrec), S/64);

else

//否则进入慢启动阶段

sendRate=max(min(2sendRate, 2Xrec), S/RTT);

其中，sendRate为发送速率，Xrec为从上个反馈包被发送之后到本反馈包被发送这段时间内，接收方估算的接收速率；S/64表示当P﹥0时，发送方至少每64 s发送一个包；而S/RTT给出了发送方在慢启动阶段的最小发送速率，即每个往返时间一个包。

3 TFRC的改进

3.1 存在的问题

由以上分析可知，TFRC利用丢失事件率P来判断网络处于何种状态：

if(P﹥0)→congestion

之所以用丢失事件率P作为网络处于拥塞的信号，是为了与TCP数据流保持公平友好性。但由此带来一个问题，即此时丢失事件已经发生，网络已经处于拥塞状态。而对于多媒体数据流业务而言，实时性是至关重要的，如果能够在丢包之前就检测到网络可能将要产生拥塞并及时调整发送速率，就可以提高网络多媒体服务的质量。

3.2 延迟抖动预警

延迟抖动的变化趋势是在链路满负荷前，随着发送速率的变大而变小；在链路满负荷后突然变大[11]。由此可得延迟抖动的突然增大是网络拥塞的前兆。因此，本文提出用丢失事件率P和延迟抖动J这2个参数来判断网络的拥塞情况。如果P大于0或者J大于实时业务所允许的最大值Jmax，则网络处于拥塞状态(congested)。这里Jmax的取值视具体的实时业务而定，如视频会议，大于40 ms的抖动就会造成图像的闪烁[12]；如果网络没有处于拥塞状态，则判断延迟抖动是否稳定，不稳定的判断条件是J﹥Jth，其中Jth是抖动阈值，其取值在下文中说明。若延迟抖动不稳定，则认为网络拥塞即将发生(congesting)，过程如下：

if(P﹥0‖J﹥Jmax)→congested

else if(J﹥Jth)→congesting

然后根据网络处于congested状态还是congesting状态来采取相应的措施，以此对TFRC的拥塞控制机制进行改进。

3.2.1 计算延迟抖动J

在一次连接传输的过程中，各分组延迟并非一样，分组延迟的变化程度称之为延迟抖动，根据TFRC协议中规定的报文内容，接收方可以计算出分组的延迟抖动[13]。

记S(k)为分组k的发送时间(即分组k的时间戳)，R(k)为分组k的接收时间。则分组k的端到端网络传输延迟为R(k)-S(k)。记分组k和分组k-1的传输延迟之差为D(k-1, k)，则：

D(k-1,k)=[R(k)-R(k-1)]-[S(k)-S(k-1)]

(7)

同发送方对往返时间RTT的计算类似，这里接收方对新的延迟抖动预测值J(k)的估算也加入了过滤因子，计算如下：

J(k)=β×J(k-1)+(1-β)×|D(k-1,k)|

(8)

其中，β为过滤因子，这里可取值为0.9。

3.2.2 更新发送速率

如果有丢失事件发生或者延时抖动超出允许的最大值，则按照公式(1)的计算结果对当前发送速率进行更新；否则，看延迟抖动是否稳定，若稳定，则进入慢启动阶段；若不稳定，则认为拥塞即将发生，进入拥塞避免阶段，对当前的发送速率进行调整，算法的伪代码描述如下：

getAck();//发送方收到反馈包

if(P﹥0‖J﹥Jmax)

//网络处于拥塞状态，按式(1)计算X并调整发送速率

sendRate=max(min(X, 2Xrec), S/64);

else if(J≤Jth)

//判断延迟抖动是否稳定，若稳定则进入慢启动阶段

sendRate=max(min(2sendRate, 2Xrec), S/RTT);

else

//网络即将出现拥塞，进入拥塞避免阶段

sendRate=w×sendRate;

其中，w为调整因子，且0﹤w﹤1。如果w使用固定值，则很难适应网络状况的实时变化，故w的取值为动态可变的，同时它还要满足以下2个条件：1)延迟抖动越大，w的取值就越小；2)w能对发送速率进行平滑地调整。

设延迟抖动J相对于阈值Jth的波动率为x，则:

(9)

由式(9)得x>0，且x与J成正比。取调整因子为:

w=e-x

(10)

w的函数曲线如图1所示，由图1可看出w∈(0,1)，在(0,+∞)上单减且曲线光滑，w可以起到平滑调整发送速率的作用。典型地，当延迟抖动相对于阈值的波动率为50%时，算法将发送速率降为原发送速率的60%左右。

图1 w=exp(-x)的函数曲线

3.2.3 阈值Jth的选取

在本算法中，抖动阈值Jth的合理选取是一个关键。如果Jth取得过大，则算法对抖动的检测不够敏感，最终导致无法准确地预测拥塞的即将到来；而如果Jth取得太小，算法对抖动的检测又过于敏感，甚至可能对那些正常的小抖动也提示拥塞即将出现。由此可见使用固定的阈值并不是最佳选择，故本文提出一种自适应的阈值调节方案：

1)设有序序列A为(0,…,Jmax)，采用类似折半查找的方法来确定阈值Jth，其初始值为Jmax/2，而每次确定Jth值都把有序序列分为左右2个半区；

2)如果在网络进入拥塞前没有检测到延迟抖动超出阈值Jth，则说明Jth的值太大，将Jth取左半区的中间值；

3)如果连续3次都检测到延迟抖动超出阈值Jth，则说明Jth的值过小，将Jth取右半区的中间值。

不断重复第2步和第3步，动态调整Jth的取值，以此让延迟抖动更准确地反映网络的实时状况。

4 仿真分析

4.1 拓扑结构及参数设置

改进后的算法称之为TFRC-DJ。下面使用NS-2.38仿真平台进行仿真分析，拓扑结构采用经典的哑铃型单瓶颈链路进行配置，如图2所示。

图2 网络拓扑结构

在图2中，节点1和节点2之间建立TCP流连接，其中1为发送方，2为接收方；节点3和节点4之间先后分别建立TFRC流连接和TFRC-DJ流连接，其中3为发送方，4为接收方。R1和R2是2个路由器，其间的瓶颈链路带宽为10 M/s，瓶颈链路延迟最小为10 ms；两边的发送终端和接收终端与路由器之间的带宽为100 M/s，延迟为3 ms。各链路采用RED的队列管理机制。TCP流、TFRC流和TFRC-DJ流的数据包大小均为1000 B，仿真时间为200 s。

4.2 实验结果及分析

4.2.1 TCP友好性

实验引入友好因子比较TFRC和改进后的TFRC(即TFRC-DJ)的TCP友好性[14]。记T0为TCP流的吞吐量，Tf为其他协议流f的吞吐量，则协议流f的友好因子af为：

(11)

根据友好因子的定义知TCP流的友好因子为1，而其他协议流的友好因子值越接近1，则说明其TCP友好性越好。图3为各协议流友好因子的比较结果。

图3 各协议流的友好因子

从图3可以看出，虽然2条曲线随着瓶颈延迟的改变都在数字1的上下浮动，但显然TFRC-DJ相对于TFRC更接近1，表现出更好的TCP友好性。

4.2.2 速率平滑性

为分析发送速率的平滑性，本文采用协议流吞吐量的方差系数CoV(Coefficient of Variation)来对协议流的平滑性进行评估[15]。设测量的时间尺度为δ，协议流f在时间段(t0,t0+δ)内发送的数据量为Tf(t0,t0+δ)，则定义协议流f在时间段(t0,t0+δ)内的平均吞吐量为：

(12)

时间序列[t0,T]所对应的平均吞吐量序列为{Rf,δ(t0+i×δ)}，其中i=1,2,…,(T-t0)/δ。协议流吞吐量的CoV定义为吞吐量标准方差与其均值之比，其表达式为：

(13)

其中,Rf,T(t0)为协议流f在时间段[t0,T]内的平均吞吐量。CoV的值越小，表示协议流的速率变化越平滑。图4为各协议流吞吐量方差系数的比较结果。

图4 各协议流吞吐量的方差系数

从图4可以看出，TFRC-DJ流的CoV更小，即其发送速率更为平滑，且随着时间尺度的变化更趋于稳定。

5 结束语

本文在分析TFRC现有算法的基础上，提出将延迟抖动信息作为潜在的网络拥塞信号，并采用自适应延迟抖动阈值，提高了发送端感知网络拥塞的敏感度，同时用调整因子对发送速率进行平滑约束，降低了发送速率的波动性。通过仿真实验，验证了改进算法具有较好的性能。如何在更为复杂的网络环境中改进算法的鲁棒性是今后研究的重点。

参考文献：

[1] Vardhan S V, Reddy P C. Congestion control in real time applications[J]. International Journal of Computer Applications, 2012,51(8):31-37.

[2] 朱海婷,丁伟,缪丽华,等. UDP流量对TCP往返延迟的影响[J]. 通信学报, 2013,34(1):19-29.

[3] Floyd S, Handley M, Padhye J, et al. Equation-based Congestion Control for Unicast Applications: The Extended Version[R]. International Computer Science Institute, 2000.

[4] Handley M, Floyd S, Padhye J, et al. IETF RFC 3448, TCP Friendly Rate Control(TFRC): Protocol Specification[S].

[5] Janani M, Reddy P C. TFRC for congestion control in real time applications[J]. International Journal of Networks and Systems, 2013,2(6):45-52.

[6] Zhang Junbiao, Joseph H. Applying traffic smoothing techniques for quality of service control in VBR video transmissions[J]. Computer Communications, 1998,21(4):375-389.

[7] Padhye J, Firoiu V, Towsley D, et al. Modeling TCP throughput: A simple model and its empirical validation[J]. ACM SIGCOMM, 1998,28(4):303-314.

[8] Everette S, Gardner J. Exponential smoothing： The state of the art—Part II[J]． International Journal of Forecasting, 2006,22(4)：637-666.

[9] 曾晶萍,杨文俊,彭力,等. TCP友好速率控制协议的分析及应用[J]. 计算机技术与发展, 2007,17(1):210-212.

[10] 黄奎,吴亦川,郑建平,等. 基于自适应加权平均的TCP友好拥塞控制机制[J]. 软件学报, 2005,16(12):2124-2131.

[11] 王海兰,何泾沙. 网络延迟和抖动分析[J]. 计算机科学, 2008,35(4A):284-287.

[12] Fred Halsall. 多媒体通信[M]. 蔡安妮, 孙景鳌译. 北京:人民邮电出版社, 2004.

[13] Li Qi, Chen Di, Liu Yuncai, et al. Jitter ratio based TFRC scheme in wireless-wired hybrid network[C]// IEEE International Conference on Digital Telecommunications. 2006:38.

[14] Miyabayashi M, Wakamiya N, Murata M, et al. MPEG-TFRCP: Video transfer with TCP-friendly rate control protocol[C]// IEEE International Conference on Communications. 2001:137-141.

[15] Widmer J. Equation-based Congestion Control[D]. Mannheim: University of Mannheim, 2000.