自动化专业毕业设计5.docx

《自动化专业毕业设计5.docx》由会员分享，可在线阅读，更多相关《自动化专业毕业设计5.docx（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、附录：中英文翻译英文Simulation-based Comparisons of Tahoe, Reno, and SACK TCPKevin Fall and Sally Floyd1 IntroductionIn 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 a

2、cknowledgment, 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 wo

3、rk 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 achieved Several transport protocols have provided for selective acknowledgment (SACK) of received data. These include NETBLT CLZ87, XTP SDW92,

4、 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 MMFR

5、9 6 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包直到所有的数据包被传完。New Reno保持在快速恢复状态，直到在快速恢复 阶段初始化未被成功传送的数据全被响应。5 SACK TCP前面这几种算法，在单包丢弃时，

6、效果是不错的，但如果在同一个窗口下 同一个数据窗口下，它们的性能都有比较大的局限性。后来浮现了基于选择应答 (sack)的算法，它较好的解决了在同一个数据包丢失的问题，这种算法的基本 原理是这样的：SACK算法中，有一个称作选择域(option)的数据段：SACK的 选择域的数据段，ACK中的SACK域包含一定数量的SACK块，每一个SACK块都 记录了信宿端接收或者缓存的非连续分组。SACK块的多少因应用和需要的不同 而 有所不同。与Reno相似，当发送端收到prexmtthresh个重复的ACK时，重 发丢失的分组，并将拥塞窗口减半，进入快速恢复过程。期间，SACK维护了 一个称为“pip

7、e ”的变量用来估计浮现在网络中的分组数。当“pipe”小于拥 塞窗口的大小时，发送端发送新的或者需要重发的分组，并将变量“pipe”加 一。当发送端接收了一个带SACK选项的重复ACK,表明新分组已被接收端接收, pipe变量减一。Pipe变量的使用将何时发送与发送哪一个分组有效的解偶。 当发送端被许可发送分组时，挨次将发送丢失列表中记录的分组。如果没有这 样的分组，而接收端的通报窗口又足够大，则发送端将发出新的数据分组。当重传分组本身被丢弃后，SACK用重传超时来探测丢失，再次重传后进入慢启动过程，在确认了所有浮现在进入快速恢复阶段的分组后，发送端将从快速 恢复中退出。TCP SACK与T

8、CP Reno最主要的区别是在多个数据包丢失的情况下 进行拥塞避免的方式的不同。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 Reno1 s performance problems are a necessary consequence of the absence of SAC

9、K. To show 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 l

10、arge number of packets are dropped from a window of data. The purpose of our discussion of New-Reno is to clarify the fundamental 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

11、recover from multiple drops in a window of data without waiting for a retransmit timeout. This characteristic is not shared by Tahoe TCP, which is not limited to retransmitting at most one dropped packet per round-trip time. However, it is fundamental consequence of the absence of SACK that the send

12、er has to choose between the following strategies to recover from lost data:1 retransmitting at most one droppedpacket per round-trip time, or2 retransmitting packets that might have already been successfully delivered.To illustrate the advantages of TCP with SACK, we show simulations with SACK TCP,

13、 using the SACK implementation in our simulator. SACK TCP is based on a conservative extension of the Reno congestion 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

14、delivered as compared with comparable protocols lacking SACK. Given such information, a sender can avoid unnecessary 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 im

15、prove its performance.In Sections 2 through 5 we describe the congestion control and packet retransmission algorithms 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 da

16、ta. Section 7 shows a trace of Reno TCP taken from actual Internet traffic, showing that the performance problems of 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 conclusion

17、s.2 Tahoe TCPModern 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 a retransmit timer expiration to re-send

18、 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 include Slow-Start, Congestion Avoidance, and Fast Retransmit Jac88. The refinements include

19、a modification to the round -trip time estimator used to set retransmission timeout values. All modifications have been 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 r

20、eceiving a small number of duplicate acknowledgments for the same TCP segment (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.3 Reno TCPThe Re

21、no TCP implementation retained the enhancements incorporated into Tahoe, but modified the Fast Retransmit operation 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 aft

22、er 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 window becomes other gatewa

23、ys that fail to monitor the average queue size) until the number of dup ACKs rechestcprexmtthresh, 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 observation that each dup ACK

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

25、 received.4 New-Reno TCPWe 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 th

26、e 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 Hoe95, CH95. The change concerns the sender*s behavior during Fast Recovery when a partial ACK i

27、s 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 ou

28、t 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-

29、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.Th

30、e 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 senders congestion window would allow more packet

31、s 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

32、 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,

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

34、 exiting Fast Recovery with Reno TCP are illustrated in Flo95.5 SACK TCPThe 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

35、a SACK option is required to report the data receivers 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 Times

36、tamp option specified for TCP Extensions for High Performance BBJ92, 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) Bra949 the TCP option space would have room for onl

37、y two SACK blocks.The 1990 “Sack TCP implementation on our previous simulator is from StevenMcCanne and Sally Floyd, and does not conform to the formats in MMFR96. The new “Saeki “implementation contains major contributions from Kevin Fall, Jamshid Mahdavi, and Matt Mathis.The congestion control alg

38、orithms implemented in our SACK TCP are a conservative extension of Renos congestion control, in that they use the same algorithms for increasing and decreasing the congestion window, The SACK TCP implementation in this paper, called Saeki “in our simulator, is also discussed in Flo96b, Flo96a. and

39、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 retr

40、ansmit 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介绍在这篇论文中，我们将介绍使用选择重发（sack）选项的TCP协议的益处， 拥塞控制，算法普通分为两类：基于窗口的和基于位率的拥塞控制算法，基于窗

41、 口的控制算法是通过源端限制数据报的传送，并且不应答。这种机制在源端不需 对发送的数据进行整形，它的优点在于易于实现，并对内在的由于限制最大量数 据量所造成的不良影响能进行控制，然而，基于位率的控制党法，要对即将发送 的流量进行整形，以防止爆发数据流的浮现。这种算法的优点在于如果源端的传 输率和网络匹配，那末就缩减了交换机所需的缓存区。许多传输协议提供选择重传选项中描述的TCP快速恢复算法的典型实现，TCP数据发送端在发生一个超时重传时仅仅重传一个数据包，或者当三个重复确 认到达时触发快速重传算法。单单一个超时重传可能导致许多数据包的重传， 但是每次Reno快速重传算法的启用仅仅导致一个数据包

42、的重传。因此，当多个 数据包从一个数据窗口中丢失并且触发快速重传和快速恢复算法时，问题 就会 产生。在这种情况下，如果SACK选项可用，TCP发送端在快速恢复期间就有足 够的信息来决定重传哪个数据包，不重传哪个数据包。这篇文档仅对不能使用 TCP选择确认(SACK)选项的TCP连接合用。 在没有SACK的情况下，TCP发送 端在快速恢复期间只能得到很少的信息来作出重传决定。从三个重复确认中， 发送端判断出一个数据包丢失了，并且重传那个声明了数据包。在 这之后，数 据发送端可能接收到此外的重复确认，因为在发送端进入快速重传时，数据端确 认已经发送的附加数据包。在多个数据包从一个数据窗口中丢失这种

43、情况下， 当发送端从对重传的数据包(就是第一次进入快速重传时重传的数据包)的一 个确认时，它获得第一条可用新信息。如果惟独一个数据包丢失了，对这个重 传的数据包的确认将确认所有进入快速重传(在没有重新排序的情况下)之前 发送的数据包。但是，当有多个数据包丢失时，对此重传数据包的确认将确 认一些而不是所有在快速重传之前发送的数据包。我们称这个包是一个部份确认。 和许多其它的建议一起，Hoe95建议在快速恢复期间TCP数据发送端通过判断 声明的数据包已经丢失和重传那个数据包的方式响应一个部份确认。为了说明使用选择重传(sack) TCP协议的好处，我们仿真了 TCP SACK使 用网络仿真器。并且

44、TCP SACK是TCP Reno的适当扩展。 解决拥塞是采用基于 窗口的端到端的算法，以前主要有两种：Tahoe和Reno.分别对通过重复应答者 收到重复应答时，一律认为网络发生了拥塞，而Reno在收到重复的应答时却认 为网络可能是暂时的而不是持久的拥塞，Reno可能导致在同一窗口中浮现多个 数据包被丢失的现象。Tahoe包括慢启动、拥塞避免和快速重传等几个主要阶段。 后来随着网络技术的发展，在Reno算法的基础上，浮现了 New Reno算法。下 面是几种算法的分析：2 Tahoe TCPTCP Tahoe指的是1988年加入Van Jacobson提出的慢启动、拥塞避免和 快速重传算法之

45、后的4. 3BSD或者类似的TCP实现版本。正如RFC793所要求的,Tahoe采用了递增式肯定重传策略和模型（滑动窗口算法）。在慢启动阶段，拥塞窗口（cwnd）随着确认的到来以指数方式递增（这种以ACK来触发 TRANSMIT的机制，被VJ称为，或者，直到到达阀值ssthresh （slow start threshold ）之后TCP进入拥塞避免阶段，cwnd每 隔RTT以线性方式递增1个单位。如果连续收到3个重复确认，TCP不等重传定 时器溢出，即将重传丢失的报文段，这称为快速重传；之后TCP返回T曼启动状态。 早期的TCP实现算法是基于积极响应并通过重传来重发丢失的数据，当丢包时， T

46、CP减小拥塞窗口，并重传被丢失的分组，然而在使用网络拥塞达到最小方面， 这些算法的性能很差。TCP Tahoe参考了早期的实现方法，并增加一些算法，包 括慢启动：窗口大小以指数速度增加；拥塞避免：窗口的大小以一个线形速度增 加；快速重传：从一个丢包的状态恢复而不需要等待重传定时器的超时。Tahoe还 包括对往返时间估计量的修改，这一参数的准确估计是非常重要的，因为它被用 来设置重传超时定时器的基值，此外，Tahoe引入快速重传机制，即当接受者收 到几个对同一 TCP报文的相同应答时，发送方就判断已经发生了丢包，而没有必 要的等到重传定时器超时，并且重传相应的包，提高了信道的利用率。3 Reno

47、 TCPTCP Reno在快速重传之后进入快速恢复（而不是TCP Tahoe采用的慢启 动）。VJ给出的原因是，接收方发送重复确认不仅仅意味着有报文段丢失了，还 意味着有（其它的）报文段离开了网络，到达了接收方的缓冲区（self-clocking）, 也就是说，网络“管道”空出了新的位置，这样TCP可以继续发送新的报文段（当 然cwnd应该减小一些）。另一个不进入慢启动的原因是，dup ACKs的到达已经 使得发送方的确认“时钟”得到了同步。快速重传和快速恢复通常一起实现：L收到第3个重复确认之后，令ssthresh =max（FlightSize/2, 2*SMSS） ； 2.重传丢失的报文

48、段，并令 cwnd 二 ssthresh +3； 3.对每一个dupACK, cwnd +=SMSS,此时，窗口大小允许的话发送一个报文段;4 .当确认了新数据的ACK到达时，令cwnd=ssthresh,即进入拥塞避免状态。TCP Reno在一个窗口中的多个报文段同时丢失的情况下会浮现性能问题， 因为此时引起TCP退出快速恢复的“确认了新数据的ACK”没有确认进入快速重 传之前丢失的所有报文段。其它丢失的报文段会使得TCP不断执行快速重传和快速恢复，而cwnd和ssthresh亦会多次被减半，大大降低了吞吐量。Reno修改 了 Tahoe的快速重传为快速恢复（指由三个重复的应答判断有包丢失时

49、，仅使窗 口值减半）新的算法防止通信管道在快速重传之后变为空，于是避免了慢启动在 单包丢失之重填。快速重传主要决定于收到的重复应答数目的初始门限值，一旦 达到了门限值，发送方就重传一个数据包，同时使拥塞窗口减半，与Tahoe的慢 启动不同，Reno的发送方用额外到达的应答来为后续包定时。发送方的可用窗 口变为发送窗口与拥塞窗口的最小值，于是在快速恢复中，发送方根据收到的重 复的应答来变动自己的窗口。相应地，每一个重复应答表示有一些包已被移出网络, 并且现在已经到达接收方。在进入快速恢复阶段并重发一个数据包后，对应每一 个额外重复地应答传出一个新包，当接受到新数据地应答时，发送方退出快速恢 复阶段并设置Ndup为0Reno的理想情况是在一个窗口中单包丢失时，Reno发送方在每一个往返时间 中最多重传一个包，但是它在同一个窗口中浮现多包丢失时可能浮现的问题。4 New Reno TCPTCP NewReno修改了 TCP Reno的