1、附录：中英文翻译 英文 Simulation-based Comparisons of Tahoe, Reno, and SACK TCP Kevin Fall and Sally Floyd 1 Introduction In this paper we illustrate some of the benefits of adding selective acknowledgment (SACK) to TCP. Current implementations of TCP use an acknowledgment number field that contains a cumulat
2、ive acknowledgment, indicating the TCP receiver has received all of the data up to the indicated byte. A selective acknowledgment option allows receivers to additionally report non-sequential data they have received. When coupled with a selective retransmission policy implemented in TCP senders, Thi
3、s work was supported by the Director, office of Energy Re-search, Scientific Computing Staff, of the U.S. Department of Energy under considerable savings can be achievedSeveral transport protocols have provided for selective acknowledgment (SACK) of received data. These include NETBLT CLZ87, XTP SDW
4、92, RDP HSV84 and VMTP Che88. The first proposals for adding SACK to TCP BJ88, BJZ90 were later removed from the TCP RFCs (Request For Comments) BBJ92 pending further research. The cur-rent proposal for adding SACK to TCP is given in MMFR96. We use simulations to show how the SACK option define in M
5、MFR96 can be of substantial benefits relative to TCP without SACK. Without SACK, Reno TCP has performance problems when multiple packets are dropped from one window of data. These problems result from the need to await a retransmission timer expiration before re-initiating data flow. Situations in w
6、hich this problem occurs are illustrated later in this paper (for example, see Section 6.4). Not all of Renos performance problems are a necessary consequence of the absence of SACK. Toshow why, we implemented a variant of the Reno algorithms in our simulator, called New-Reno. Using a suggestion fro
7、m Janey Hoe Hoe95, Hoe96, New-Reno avoids many of the retransmit timeouts of Reno without requiring SACK. Nevertheless, New-Reno does not perform as well as TCP with SACK when a large number of packets are dropped from a window of data. The purpose of our discussion of New-Reno is to clarify the fun
8、damental limitations of the absence of SACK. In the absence of SACK, both Reno and New-Reno senders can retransmit at most one dropped packet per round-trip time, even if senders recover from multiple drops in a window of data without waiting for a retransmit timeout. This characteristic is not shar
9、ed by Tahoe TCP, which is not limited to retransmitting at most one dropped packet per round-trip time. However, it is a fundamental consequence of the absence of SACK that the sender has to choose between the following strategies to recover from lost data: 1 retransmitting atmost one dropped packet
10、 per round-trip time, or 2 retransmitting packets that might have already been successfully delivered. To illustrate the advantages of TCP with SACK, we show simulations with SACK TCP, using the SACK implementation in our simulator. SACK TCP is based on a conservative extension of the Reno congestio
11、n control algorithms with the addition of selective acknowledgments and selective retransmission. With SACK, a sender has a better idea of exactly which packets have been successfully delivered as compared with comparable protocols lacking SACK. Given such information, a sender can avoid unnecessary
12、 delays and retransmissions, resulting in improved throughput. We believe the addition of SACK to TCP is one of the most important changes that should be made to TCP at this time to improve its performance. In Sections 2 through 5 we describe the congestioncontrol and packet retransmission algorithm
13、s in Tahoe, Reno, New-Reno, and SACK TCP. Section 6 shows simulations with Tahoe, Reno, New-Reno, and SACK TCP in scenarios ranging from one to four packets dropped from a window of data. Section 7 shows a trace of Reno TCP taken from actual Internet traffic, showing that the performance problems of
14、 Reno without SACK are of more than theoretical interest. Finally, Section 8 discusses possible future directions for TCP with selective acknowledgments, and Section 9 gives conclusions. 2 Tahoe TCP Modern TCP implementations contain a number of algorithms aimed at controlling network congestion whi
15、le maintaining good user throughput. Early TCP implementations followed a go-back-n.model 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 add
16、ed a number of new algorithms and refinements to earlier implementations. The new algorithms includeSlow-Start, Congestion Avoidance, and Fast Retransmit Jac88. The refinements include a modification to the round-trip time estimator used to set retransmission timeout values. All modifications have b
17、een described elsewhere Jac88, Ste94. 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 tha
18、t 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. 3 Reno TCP The Reno TCP implementation retained the enhancements incorporated into Tahoe, but modified the Fast Retransmit operat
19、ion to include Fast Recovery Jac90. 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
