自动化专业毕业设计外文翻译5.docx

附录：中英文翻译英文Simulation-based Comparisons of Tahoe, Reno, and SACK TCPKevin Fall and Sally Floyd1 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 cumulative 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, This 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 [SDW92], 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 [MMFR96] 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 which 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 from 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 nu