TCP Friendly Rate Control(TFRC):Protocol Specification 《TCP友好速率控制：协议定义》
TCP Friendly Rate Control(TFRC):Protocol Specification
《TCP友好速率控制：协议定义》
目录
1主要观点和解决的问题2
2关键技术2
2.1协议机制：2
2.2数据发送方协议3
2.3丢包率的计算4
2.4数据接收方协议4
3 论文的主要贡献5
4思考6
1主要观点和解决的问题
这篇论文是互联网标准RFC3448关于一种能够用于传输协议的拥塞控制机制TFRC(TCP Friendly Rate Control)的说明书。讲述了在端到端系统的拥塞管理中，一种与TCP流公平的竞争带宽，适合于电话视频流等强调流畅发送速率的服务的拥塞控制机制TFRC。TFRC是一个基于接收方的机制，发送方根据接收方对于拥塞控制信息的计算（比如丢包率）等反馈信息，按照模型计算出来的速率值来调节发送数据的速度。
TFRC有固定的数据包大小，通过不同的发送速率来响应当前拥塞情况。TFRC的缺陷在于对于可变带宽的反应上比TCP要慢，因此只适用于那些要求流畅吞吐量的应用。
2关键技术
2.1协议机制：
TFRC 的运行过程如下：首先是“慢启动”阶段，直至丢失事件的发生。丢失事件发生后将按照吞吐量公式进行计算：
(1) 接收方接收数据包，计算出丢失事件率p ，并把p 值和时间戳信息反馈至发送方；
(2) 发送方从反馈信息中得到丢失事件率p 和时间戳信息，并通过时间戳计算出往返时间RTT；
(3) 把参数p、RTT 和包的大小s (发送方已知道包的大小) 代入吞吐量公式， 得到一个速率(在TFRC 中, RTO 取4 RTT)；
(4) 最后把计算而得的速率与接收方上次接收速率的2倍进行比较(发送方有接收速率的拷贝) ，取两者中的较小者作为最终的发送速率，发送方以这个速率把数据包发送出去。
TFRC的吞吐量方程式根据Reno方程而来，其理想方程应该是基于SACK的TCP方程，但是从仿真和实验的结果来看，两者之间的区别较小 。
具体吞吐量方程为：
X =
其中X是每秒发送的传输速率
s是数据包大小的字节数；
R是往返时间；
P是丢包率，在0到1.0之间，丢包数目除以总的发送数据包数目；
t_RTO是超时计时器设定的时间；
b是被TCP确认的数据包数目；
作者分别在后面的章节讲述了s、p、R的计算方法。
接下来作者描述了发送方数据包内容和接收方反馈报文内容，分别是：
（1）数据包：
1序列号；
2时间戳（毫秒）此时间戳用于接收方来确定哪些丢包属于同一丢失的事件；
3 发送方当前估计的RTT。
（2）反馈包：
1上次收到包的时间戳ts_i；
2 发送方收到最近一次数据包所花时间t_delay；
3 接收方根据最近一次接收数据发送反馈的时间估计出来的速率。
2.2数据发送方协议
由前面可知，发送方主要根据接收方返回的这个反馈包的信息来调整自己的发送速率，以此保证网络的传输的正常。反馈包如果在两个RTT时间内都不能到达，发送方将会将发送速率减半。该规则体现了网络拥塞控制的一个关键技术的特点，就是根据接收方的情况来确定发送方的发送速率。
发送方协议主要分以下几步：
一、测量将要发送的平均包的大小，取得s值；
二、收到反馈包后发送方的行为，计算和更新RTT，更新超时时间和发送速率；
三、无反馈包计时器超时后发送方的行为，即调整发送速率以适应当前网络状况；
四、防止振荡（可选的），通过低程度的统计方法来改变发送方的发送速率；
五、非实时操作系统的传输调度。
2.3丢包率的计算
丢失事件率的计算是TFRC中最关键的一个内容。
TFRC需要维护丢失检测的鲁棒性，比如在一些数据包丢失是同一丢失事件的一部分。因此接收方需要将一个包丢失历史映射为一个丢包事件记录，丢包事件指的是在一个RTT内一个或多个包丢失。
决定一个包丢失是否是一起新的丢包事件的开始，还是被计入已有的丢包事件当中去，我们需要比较到达接收方的包的序列号和时间戳。
在文中关于丢包率的具体计算，作者采用了历史折扣的方法进行计算。具体做法是：
首先计算各个折算因子：
I_tot0 = I_0 * w_0
I_tot1 = 0;
W_tot0 = w_0
W_tot1 = 0;
for (i = 1 to n-1) {
I_tot0 = I_tot0 + (I_i * w_i * DF_i * DF);
W_tot0 = W_tot0 + w_i * DF_i * DF;
}
for (i = 1 to n) {
I_tot1 = I_tot1 + (I_i * w_(i-1) * DF_i);
W_tot1 = W_tot1 + w_(i-1) * DF_i;
}
然后对于时隙I_tot 再进行带有折算因子的加权平均：
p = min(W_tot0/I_tot0, W_tot1/I_tot1);
2.4数据接收方协议
接收方提供反馈以使发送方能够计算RTT时间。同时，接收方也计算丢失事件率，反馈给发送方。
接收方在接收到数据包后，将进行如下动作：
（1）添加该包到包的历史记录，计算出新的p值；
（2）如果p>p_prev,释放反馈计时器,执行相应操作；
（3）然后进行接收数据包初始化，若出现第一个丢失事件则对丢失历史记录进行初始化；
（4）提供反馈包给发送方。
此外，作者还介绍了基于发送方的变种，指出在可以可靠的传递接收方发给发送方有关丢包信息的环境中，可以由发送方计算丢包率和可承受的传输速率，而不需要依靠接收方计算丢包率。但这种协议对于网络环境和传输协议有更严格的限制。
相反，基于接收方的TFRC变种对于丢包具有很好的鲁棒性，不需要有可靠的传递反馈报文的要求。更适合于流媒体（web 服务器）这种需要服务器为客户端提供的服务。
最后作者阐述了TFRC的实现问题，指出历史折扣机制可用于计算平均丢失
率。
关于TFRC的安全注意事项，作者指出了TFRC本身不是一个传输协议，而是与传输协议配合使用的用于拥塞控制的一种机制，因此安全问题要是由特定的传输协议和其认证机制来保证。因此有可能会被用于攻击者创造拒绝服务或者霸占更多的带宽，因此需要进一步的完善。
3 论文的主要贡献
随着互联网的发展、流媒体应用日益丰富，这些面向音视频的应用以其大数据量、实时性要求高等特性对网络的可用资源提出了巨大的挑战。
传统基于UDP的实时媒体传输服务不具有TCP友好性，在瓶颈链路上很容易造成严重的资源不公平占用，甚至出现严重的拥塞，造成数据交付延迟、吞吐量下降、丢弃概率增加等等服务质量恶化的负面影响。在TCP流占主要成分的Internet，要实现实时流媒体传输必须保证其能同TCP流共同公平友好地分享链路资源，才能保证网络的高效稳定的运行。
因此本文提出了一种基于接收方的传输控制机制，它在该善了传统AIMD慢收敛性的基础上，不仅具有很好的拥塞控制能力，同时还具有良好的TCP友好性。这就是TFRC协议。
作者首先介绍了TCP吞吐量方程的计算方法，指出了在网络传输过程接收方和发送方各自应负责的任务与协议，指出了丢包率的具体算法。最后简略比较了基于发送方和接收方两种机制以及实现和安全问题的讨论。
我们可以看到，在现今与多个TCP流竞争时TFRC所表现出来的高效的网络资源利用率、平稳的传输速率以及低的突发性等诸多良好的性能，已经为互联网拥塞控制的发展做出了很大的贡献。
4思考
同时我们要看到的是，尽管新机制有着如此优越的性能，但是TFRC机制仍然在一些方面不尽如人意：
(1)对不断改变的网络状态的反应慢，因此在在要求快速响应的传输中，我们仍然建议使用TCP中有关拥塞控制模式。TFRC仅适用于稳定流畅的发送速率环境中。
(2)由于TFRC本身不是一个传输协议，而是与传输协议配合使用的用于拥塞控制的一种机制，因此安全问题要是由特定的传输协议和其认证机制来保证。
(3) 拥塞控制机制可能会被利用来创造拒绝服务，可能通过欺骗性的反馈发生这种情况。
(4)拥塞控制机制可能会被一个贪婪的接收方操作，希望得到更多的网络带宽。可能的防御措施是接收方随机放入一些随机数反馈给发送方表明证据，然后这种随机数的实现细节也依赖于传输协议。
