TCP快速恢复算法NewReno修正( 四 )

Reno或NewRenoTCP也会发生不必要的快速重传，非凡是假如快速恢复期间发生了一个重
传超时的话。（这在［F98］第6页中作为Reno的例证，第8页中作为NewReno的例证。）有
NewReno的话，数据发送端一直处于快速恢复，直到发生一个超时重传，或者快速重传时发
送的所有数据都已得到确认。因此有了NewReno ，多次快速重传的问题只有在一个超时重传
后才发生。
接下来对第3节中算法的修正消除了多次快速重传的问题。（这个修正在[F98]中称为
“bugfix” ，在第7和第9页中说明。）这个修正使用了一个新变量“send_high” ，它的初始
值是最初发送的序列号。每次超时重传之后，到目前为止发送的最大序列号记录到
“send_high”变量中。
假如在一个超时重传之后， TCP数据发送端重传了三个连续的数据包，而这此数据包数
据接收端已经接收到了，这样的话TCP数据发送端就将接收到三个重复确认，这此确认并没
有确认“send_high”号数据包。在这种情况下，重复确认并不能表明又发生了拥塞。它们
只是表明发送端没有必要地重传了至少三个数据包。
我们注重到假如假如TCP数据发送端接收到三个重复确认，而这些重复确认并没有确认
“send_high”号数据包，这样发送端就不知道这此重复确认是否是由一个新数据包的丢失
引起的。对一个实现了这节描述的用来避免多次快速重传的bugfix的TCP而言，发送端在
这些情况下并不会由重复确认推断出一个数据包丢失了。和往常一样，重传定时器在这种情
况又成了推断数据包丢失的支持机制。
为避免多次快速重传而对快速重传作的修正用下面的步骤1A代了第3节中的步骤1 。
另外，此修正增加了下面的步骤6：
1A.当接收到第三个重复ACK并且发送端还没有进入快速恢复过程时，检查并且看看这
些重复ACK有没有确认“send_high”号数据包。假如有,设置ssthresh的值不大于等式1
中给出的值,在变量"recover"中记录发送的最大序列号,然后转到步骤2.假如重复ACK没
有确认"send_high"号数据包,就什么也不做。也就是不要进入快速重传和快速恢复过程,
不要改变ssthresh值,不要转到步骤2以重传"丢失的"数据段,并且不要在下一个重复ACK
到之前不要执行步骤3 。
步骤2-5和第三节的步骤一样。
6.一个超时重传之后,在变量"send_high"中记录发送的最大序列号,并退出快速恢复
过程,假如可以的话。
上面的1A步骤中检查重复ACK是否确认"send_high"以后的数据包,这是对此算法的
careful变形。另一个可能的改变会是简单地要求三个重复确认在开始另一个快速重传之前
确认"send_high"号数据包。我们称之为对快速重传的lesscareful变形。
在两种个别情况下,TCP发送端能接收到确认"send_high"号数据包的重复确认,但对
大于"send_high"号的数据包不确认。一种情况是数据发送端发送了四个序列号大于
"send_high"的数据包,第一个数据包丢失在网络中,接下来的三个数据包触发了三个重复
确认,这些确认确认了"send_high"号数据包。第二种情况是发送端不必要地重传了三个序
列号小于"send_high"的数据包,并且这三个数据包触发了三个确认了"send_high"号数
据包的重复确认。在没有SACK选项的情况下,TCP发送端不能区分这两种情况。
对快速重传的Careful变形而言,数据发送端在第一种情况下必须等待一个超时重传,
但在第二种情况下不会产生不必要的快速重传。对快速重传的lessCareful变形而言,数据