TCP 拥塞窗口检验( 二 )


用程序限制之后,阕值从不降低,在窗口减小以前,阕值被设为它的当前最大值,这种阕值
的使用容许TCP发送方在一段应用程序限制后增加它的发送速率来加快慢启动恢复拥塞窗
口的以前的值,更精确的,在一段应用程序限制后,拥塞窗口减小,假如阕值小于窗口大小
的3/4,那么阕值在拥塞窗口减小之前,阕值增加到窗口的3/4 。
在应用程序限制期间,当拥塞窗口增大时,也会导致无效的拥塞窗口,而拥塞窗口原来
的值可能从来没有使用,我们都知道,当有确认帧到达时,假如接收方的广告窗口和满启动
及拥塞避免算法容许,没有检查拥塞窗口原来的值有没有被使用,当前所有的TCP实现都
增加拥塞窗口大小,本文建议在应用程序限制期间,并不激活窗口增加算法[MSML99],
非凡的,当TCP发送方在应用程序限制时,发送方并不增加拥塞窗口,这种限制防止拥塞
窗口的任意增加,以防止拥塞窗口不被网络支持,在[MSML99SETION5.2]中:“这种限制
保证只有在TCP实际上向网络成功发送数据后,窗口大小才增加 。”
在一段应用程序限制后保持一个大的拥塞窗口一个值得考虑的问题是在一段静止期间
后,发送方忽然有大量的数据要发送,可能立即发送一个满窗口的包的数据,这种发送突发
大量包的问题可以被基于速率的方法(RBP,[VH97])有效的处理,或者最大发送数据控制
[FF96],即使使用限制包的发送机制,一个没有充分使用的拥塞窗口不能被作为当前可用带
宽的表示,
3描述
当一个TCP发送者有足够的数据来充分使用网络容量时,窗口大小和阕值将被设置为与网
络状况相似的值,当TCP发送方停止发送数据时,流将停止采样网络状况,并将导致拥塞
窗口的值不准确,我们相信,在这种环境下,对每个RTT内流不活动的状况,将拥塞窗口
减半是一种正确的处理方法,减半的值是很保守的数值,这是建立在有丢包的情况下,倍减
将多快减小窗口的基础上 。
另一种可能是发送者并不停止发送,是由于应用程序限制而不是网络限制,使得提供的数据
少于拥塞窗口容许发送的数据 。在这种情况下,TCP流仍然采样网络状况,但并不提供足
够的流量来保证在网络中有足够的带宽来以满拥塞窗口来发送数据,在这些情况下,我们相
信,对发送方而言,在每个RTT中跟踪拥塞窗口的最大值,并将拥塞窗口的值设为当前窗
口和曾经的最大值的均值,是一种正确的处理 。
在拥塞窗口减小以前,阕值被设为当前值和窗口的3/4两者之中的最大值,假如发送方
有比减小了的窗口大小有更多的数据发送,TCP将慢启动窗口值到原来窗口的值 。
窗口的3/4可以理解为拥塞窗口的最近一段时间内的保守估计值,且TCP 应能慢启动
到这个值,每次拥塞窗口达到某个最大值,TCP降低其拥塞窗口的大小,当处于这种稳定
状况,拥塞窗口的平均值为最大值的3/4,当连接变为应用程序限制时,窗口大小将变为最
大值的3/4,在这种情况下,窗口大小本身代表了拥塞窗口大小的平均值,然而,当窗口等
于最大值时,假如连接变为应用程序限制,那么拥塞窗口的平均值为窗口的3/4 。
有一种可能性是将阕值设为当前阕值和窗口原来大小两者之间的最大值,容许TCP慢
启动至窗口的原来大小,对于阕值的设置,可以做更进一步的实验来评估这两种选择 。
在对于一个确认帧的回应时,对于拥塞窗口的增加的各种情况,我们相信,当确认帧到

推荐阅读