TCPVegas-A(译).docVIP

TCP Vegas-A: Improving the Performance of TCP Vegas 摘要：虽然TCP Vegas显示出比TCP Reno更好的性能，但研究已经发现了这个协议的一些问题。我们的目的是修改TCP Vegas的拥塞避免阶段以克服这些限制。不同于以往的解决方法，我们的解决方法命名为TCP Vegas-A。它既不依赖于优化任何关键的参数值，也不依赖于路由器端的缓冲队列管理，而是能单独的运行在端节点。我们的实验通过有线和无线的连接表明TCP Vegas-A能够克服一些已认识到的问题，并且能够获得更好的公平性在有线网络带宽和卫星方案中，处理变更路由的问题，修改Vegas对高带宽流的偏差。 介绍 TCP Vegas和TCP Reno最重要的不同在于他们的拥塞避免阶段。TCP Reno依靠丢包检测来检测网络拥塞，而TCP Vegas用带宽估计来估计网络拥塞状况，TCP Vegas的拥塞窗口使用如下的算法 当一个连接的实际吞吐量接近期望的最大值的时候，中间路由器的缓存空间可能没用被有效的利用，因此应该增大流速，相反，当实际吞吐量大大小于期望的吞吐量时，网络可能拥塞，因此应该减小流速。 一些研究已经确定TCP Vegas比Reno更高效，因为包的转发更少，并且对长RTT没又偏见。然而我们还是发现一些问题。研究表明当vegas和reno竞争是性能较差，对先前的连接不公平，不能很好的处理重路由。 这篇论文叙述了我们的目的，就是修改vegas拥塞避免机制。 tcp vegas的问题 在这部分，我们讨论tcp-vegas的问题并思考我们所提出的tcp vegas-a。 2.1 公平性 Vegas使用一个保守的算法决定在什么时候应该改变拥塞窗口并改变多少。Reno是完全的利用贷款，持续的增加窗口大小直到检测到一个包的丢失。因此，当vegas和reno共享一个瓶颈连接的时候reno占据了大量的贷款和路由器缓存空间。而Vegas则认为这是拥塞信号，减少拥塞窗口，这是有利于reno的。当路由缓存空间增大时更加不公平。 Hasegawa et al.提出了vegas+来处理vegas公平性的问题。然而，vegas+假设一个增加的RTT总是由于竞争的存在，并且排除了像重路由一样的其他可能性。我们感觉这是不合理的假设。而且vegas+的性能依靠新参数Countmax的取值，而它是一个悬而未决的问题。 Hasegawa et al. 和Raghavendra， Kinicki三人证明了使用RED算法取代队尾丢弃算法，vegas和reno之间的公平性能提高同样的程度。但是这存在一个不可避免的交换在公平性和吞吐量之间。例如，如果RED的包的丢失概率设定一个较大的值，vegas所分享的吞吐量就能够提升，但是总的吞吐量就会减少。Feng,、Vanichpun 、Weigle证明了选择a和b作为瓶颈链路缓存容量的参数能够提升公平性。然而，他么没有提出任何的机制来测量缓存容量并且没有为其设置适当的值。 2.2 变更路由 在vegas中，baseRtt指示了最小的往返时延，它常常被用作测量期望的吞吐量。当变更路由发生在一个连接中，这个连接的RTT就要改变。当新的RTT较长时，vegas连接不能推断这个长的RTT是由拥塞还是变更路由造成的。由于vegas把增加的RTT都视为拥塞造成的，因此减少了拥塞窗口。 对什么样的连接就应该做相应的变化。当传播延时增加，带宽时延乘积(bw*d)就应该增加。(cwnd-bw*d)给出了路由缓存中包的数量。Tcp vegas的目标就是保持路由缓存中包的数量在a和b范围之间，当传播延时增加时它应该增加拥塞窗口来保持同样数量的包在路由缓存中。 【12】的作者也提出了一个改进的vegas，他通过在RTT中增加一个持久的路由标记来消除变更路由问题。另外，这可能也不是一个合理的假定，一些新的参数K，N，L，delta，和gmma被引入到这个协议中，对他们设置合适的值这仍然是一个不确定的问题。 对先前连接的不公平性 在【7】中指出的，Tcp vegas拥塞控制机制对以前的连接存在不公平性。因为baseRTT的计算方法，在旧的连接小于新的连接的时候将引起拥塞窗口的减小。类似的，作为关键值的拥塞窗口，引起拥塞窗口增加的是新连接中较小的，它比旧的连接更容易增加拥塞窗口。因此，新的连接能够获得更高的带宽。 与之紧密相关的问题是持续拥塞问题，连接可能过高估计传播延时并且导致网路向持续拥塞的方向发展。La et al研究了这个问题，并提出了同样的解决方法。Lowetal提出了适当增大vegas动态队列管理，例如Random Exponential Marking避免持续拥塞问题。然而，这些解决方法都是在中