译文2 The Algorithm of Congestion Control 1．Tahoe TCP
Modern TCP implementations contain a number of algorithms aimed at controlling network congestion while maintaining good user throughput. Early TCP implementations followed    del using cumulative positive acknowledgment and requiring a retransmit timer expiration to re-send data lost during transport. These TCPs did little to minimize network congestion.
The Tahoe TCP implementation added a number of new algorithms and refinements to earlier implementations. The new algorithms includeSlow-Start, Congestion Avoidance, and Fast Retransmit. The refinements include a modification to the round-trip time estimator used to set retransmission timeout values. All modifications have been described elsewhere.
The Fast Retransmit algorithm is of special interest in this paper because it is modified subsequent versions of TCP. With Fast Retransmit, after receiving a small number of duplicate acknowledgments for the same TCPsegment (dup ACKs), the data sender infers that a packet has been lost and retransmits the packet without waiting for a retransmission timer to expire, leading to higher channel utilization and connection throughput.
2．Reno TCP
The Reno TCP implementation retained the enhancements incorporated into Tahoe, but modified the Fast Retransmit operation to include Fast Recovery. The new algorithm prevents the communication path (“pipe”) from going empty after Fast Retransmit, thereby avoiding the need to Slow-Start to refill it after a single packet loss. Fast Recovery operates by assuming each dup ACK received represents a single packet having left the pipe. Thus, during Fast Recovery the TCP sender is able to make intelligent estimates of the amount of outstanding data.
In Reno, the sender's usable window becomesother gateways that fail to monitor the average queue size) until the number of dup ACKs reaches
tcprexmtthresh, and thereafter tracks the number of duplicate ACKs. Thus, during Fast Recovery the sender “inflate” its win dow by the number of dup ACKs it has received, according to the observation that each dup ACK indicates some packet has been removed from the network and is now cached at the receiver. After entering Fast Recovery and retransmitting a single packet, the sender effectively waits until half a window of dup ACKs have been received, and then sends a new packet for each additional dup ACK that is received.
3．New-Reno TCP
We include New-Reno TCP in this paper to show how a simple change to TCP makes it possible to avoid some of the performance problems of Reno TCP without the addition of SACK. At the same time, we use New-Reno TCP to explore the fundamental limitations of TCP performance in the absence of SACK.
The New-Reno TCP in this paper includes a small change to the Reno algorithm at the sender that eliminates Reno's wait for a retransmit timer when multiple packets are lost from a window. The change concerns the sender's behavior during Fast Recovery when a partial ACK is received that acknowledges some but not all of the packets that were out-standing at the start of that Fast Recovery period. In Reno, partial ACKs take TCP out of Fast Recovery by “deflating” the usable window back to the size of the congestion window. In New-Reno, partial ACKs do not take TCP out of Fast Recovery. Instead, partial ACKs received during Fast Recovery are treated as an indication that the packet immediately following the acknowledged packet in the sequence space has been lost, and should be retransmitted. Thus, when multiple packets are lost from a single window of data, New-Reno can recover without a retransmission timeout, retransmitting one lost packet per round-trip time until all of the lost packets from that window have been retransmitted. New-Reno remains in Fast Recovery until all of the data outstanding when Fast Recovery was initiated has been acknowledged.
The implementations of New-Reno and SACK TCP in our simulator also use a “maxburst” parameter. In our SACK TCP implementation, the “maxburst” parameter limits to four the number of packets that can be sent in response to a single incoming
ACK, even if the sender's congestion window would allow more packets to be sent. In New-Reno, the “maxburst” parameter is set to four packets outside of Fast Recovery, and to two packets during Fast Recovery, to more closely reproduce the behavior of Reno TCP during Fast Recovery. The “maxburst” parameter is really only needed for the first window of packets that are sent after leaving Fast Recovery. If the sender had been prevented by the receiver's advertised window from sending packets during Fast Recovery, then, without “maxburst” , it is possible for the sender to send a large burst of packets upon exiting Fast Recovery. This applies to Reno and New-Reno TCP, and to a lesser extent, to SACK TCP. In Tahoe TCP the Slow-Start algorithm prevents bursts after recovering from a packet loss. The bursts of packets upon exiting Fast Recovery with New-Reno TCP are illustrated in Section 6 in the simulations with three and four packet drops. Bursts of packets upon exiting Fast Recovery with Reno TCP are illustrated in.
4．SACK TCP
The SACK option follows the format in [MMFR96]. From [MMFR96], the SACK option field contains a number of SACK blocks, where each SACK block reports a non-contiguous set of data that has been received and queued. The first block in a SACK option is required to report the data receiver's most recently received segment, and the additional SACK blocks repeat the most recently reported SACK blocks [MMFR96]. In these simulations each SACK option is assumed to have room for three SACK blocks. When the SACK option is used with the Timestamp option specified for TCP Extensions for High Performance, then the SACK option has room for only three SACK blocks [MMFR96]. If the SACK option were to be used with both the Timestamp option and with T/TCP (TCP Extensions for Transactions), the TCP option space would have room for only two SACK blocks.truncated 翻译
The 1990 “Sack” TCP implementation on our previous simulator is from Steven McCanne and Sally Floyd, and does not conform to the formats in [MMFR96]. The new “Sack1”implementation contains major contributions from Kevin Fall, Jamshid Mahdavi, and Matt Mathis.
The congestion control algorithms implemented in our SACK TCP are a
conservative extension of Reno's congestion control, in that they use the same algorithms for increasing and decreasing the congestion window, The SACK TCP implementation in this paper, called
“Sack1”in our simulator, is also discussed in. and make minimal changes to the other congestion con-trol algorithms. Adding SACK to TCP does not change the basic underlying congestion control algorithms. The SACK TCP implementation preserves the properties of Tahoe and Reno TCP of being robust in the presence of out-of-order packets, and uses retransmit timeouts as the recovery method of last resort. The main difference between the SACK TCP implementation and the Reno TCP implementation is in the behavior when multiple packets are dropped from one window of data.
拥塞控制中的算法
1．Tahoe TCP
TCP Tahoe指的是1988年加入Van Jacobson提出的慢启动、拥塞避免和快速重传算法之后的4.3BSD或类似的TCP实现版本。正如RFC793所要求的，Tahoe 采用了递增式肯定重传策略和"go-back-n"模型(滑动窗口算法)。在慢启动阶段，拥塞窗口(cwnd)随着确认的到来以指数方式递增(这种以ACK来触发TRANSMIT的机制，被VJ称为"ACK clocking"，或"self-clocking")，直到到达阀值ssthresh(slow start threshold)；之后TCP进入拥塞避免阶段，cwnd每隔RTT以线性方式递增1个单位。如果连续收到3个重复确认，TCP不等重传定时器溢出，马上重传丢失的报文段，这称为快速重传；之后TCP返回慢启动状态。早期的TCP实现算法是基于积极响应并通过重传来重发丢失的数据，当丢包时，TCP 减小拥塞窗口，
并重传被丢失的分组，然而在使用网络拥塞达到最小方面，这些算法的性能很差。TCP Tahoe 参考了早期的实现方法，并增加一些算法，包括慢启动：窗口大小以指数速度增加；拥塞避免：窗口的大小以一个线形速度增加；快速重传：从一个丢包的状态恢复而不需要等待重传定时器的超时。Tahoe 还包括对往返时间估计量的修改，这一参数的准确估计是非常重要的，因为它被用来设置重传超时定时器的基值，此外，Tahoe引入快速重传机制，即当接受者收到几个对同一TCP报文的相同应答时，发送方就推断已经发生了丢包，而没有必要的等到重传定时器超时，并且重传相应的包，提高了信道的利用率。
2．Reno TCP
TCP Reno在快速重传之后进入快速恢复(而不是TCP Tahoe采用的慢启动)。VJ给出的原因是，接收方发送重复确认不仅仅意味着有报文段丢失了，还意味着有(其它的)报文段离开了网络，到达了接收方的缓冲区(self-clocking)，也就是说，网络“管道”空出了新的位置，这样TCP可以继续发送新的报文段(当然cwnd 应该减小一些)。另一个不进入慢启动的原因是，dup ACKs的到达已经使得发送方的确认“时钟”得到了同步。快速重传和快速恢复通常一起实现：1. 收到第3个重复确认之后，令ssthresh = max(FlightSize/2，2*SMSS)；2. 重传丢失的报文段，并令cwnd = ssthresh +3；3. 对每个dupACK，cwnd += SMSS，此时，窗口大小允许的话发送一个报文段；4. 当确认了新数据的ACK到达时，令

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。