TCP快速恢复算法NewReno修正

【TCP快速恢复算法NewReno修正】本备忘录的状态
本文档讲述了一种Internet社区的Internet标准跟踪协议 , 它需要进一步进行讨论和建
议以得到改进 。请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化
程度和状态 。本备忘录的发布不受任何限制 。
版权声明
Copyright(C)TheInternetSociety(2001).
摘要:
RFC2001[RFC2001]讲述了以下四种相互作用的TCP拥塞控制算法:慢启动 , 拥塞避免 ,
快速重传 , 以及快速恢复 。RFC2581[RFC2581]明确地答应对这些算法进行某些改动 , 包括
如下改动 , 使用TCP选择确认(SACK)选项[MMFR96],以及在没有SACK的情况下响应“部分
确认”(在检测到数据丢失时 , 新数据的ACKs , 而不是发送的所有数据的ACKs) 。这篇文档
描述了响应部分确认的一个特定算法 , 称为NewReno 。对部分确认的响应由JaneyHoe在
[Hoe95]中首次提出 。
目录
1.介绍 2
2.定义 2
3.NewReno中的快速重传和快速恢复算法 2
4.重设重传定时器 4
5.避免多次快速重传 4
6.数据接收端的实现问题 5
8.总结 6
9.致谢 6
10.参考文献 6
11.安全考虑 7
12.作者地址 7
13.完全版权说明 8
1.介绍
对[RFC2581](在1990年的BSDReno发行版中首次实现 , 在[FF96]称之为Reno算法)
中描述的TCP快速恢复算法的典型实现 , TCP数据发送端在发生一个超时重传时仅仅重传一
个数据包 , 或者当三个重复确认到达时触发快速重传算法 。单单一个超时重传可能导致许多
数据包的重传 , 但是每次Reno快速重传算法的启用仅仅导致一个数据包的重传 。
因此 , 当多个数据包从一个数据窗口中丢失并且触发快速重传和快速恢复算法时 , 问题
就会产生 。在这种情况下 , 假如SACK选项可用 , TCP发送端在快速恢复期间就有足够的信
息来决定重传哪个数据包 , 不重传哪个数据包 。这篇文档仅对不能使用TCP选择确认(SACK)
选项的TCP连接适用 。
在没有SACK的情况下 , TCP发送端在快速恢复期间只能得到很少的信息来作出重传决
定 。从三个重复确认中 , 发送端推断出一个数据包丢失了 , 并且重传那个声明了数据包 。在
这之后 , 数据发送端可能接收到另外的重复确认 , 因为在发送端进入快速重传时 , 数据端确
认已经发送的附加数据包 。
在多个数据包从一个数据窗口中丢失这种情况下 , 当发送端从对重传的数据包(就是第
一次进入快速重传时重传的数据包)的一个确认时 , 它获得第一条可用新信息 。假如只有一
个数据包丢失了 , 对这个重传的数据包的确认将确认所有进入快速重传(在没有重新排序的
情况下)之前发送的数据包 。但是 , 当有多个数据包丢失时 , 对此重传数据包的确认将仅确
认一些而不是所有在快速重传之前发送的数据包 。我们称这个包是一个部分确认 。
和许多其它的建议一起 , [Hoe95]建议在快速恢复期间TCP数据发送端通过推断声明的
数据包已经丢失和重传那个数据包的方式响应一个部分确认 。这篇文档描述了对RenoTCP
里的快速恢复算法的一个修正 , RenoTCP包括了快速恢复期间对接收到的部分确认的一个
响应 。我们称这处修正过的快速恢复算法为NewReno , 因为它与基础的Reno算法有一些细
小但是很重要的不同 。这篇文档没有讨论[Hoe95]和[Hoe96]中的其它建议 , 比如在慢启动期
间ssthresh参数的一个变化 , 及在快速恢复期间为每两个重复确认发送一个新数据包的建

推荐阅读