外文翻译--拥塞控制中的算法

《外文翻译--拥塞控制中的算法》由会员分享，可在线阅读，更多相关《外文翻译--拥塞控制中的算法（7页珍藏版）》请在毕设资料网上搜索。

1、 译文 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 a go-back-n.model using cumulative positive acknowledgment and requiring

2、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 Re

3、transmit. 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 Fas

4、t 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 throu

5、ghput. 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-S

6、tart 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 senders usable windo

7、w 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 window by the number of dup ACKs it has received, according to the observa

8、tion 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 add

9、itional 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

10、 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 Renos wait for a retransmit timer when multiple packets are lost from a window. The change concerns the senders behavior during Fast Recovery when a

11、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

12、 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 o

13、f 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