自动化专业毕业设计5

附录中英文翻译英文Simulation-based Comparisonsof Tahoe,Reno,and SACK TCPKevin Falland SallyFloyd1IntroductionIn thispaper weillustrate someof thebenefits ofadding selectiveacknowledgmentSACK to TCP.Current implementationsof TCPuse anacknowledgment numberfield thatcontainsa cumulativeacknowledgment,indicating the TCP receiverhas receivedall of thedata upto theindicated byte.A selectiveacknowledgment optionallows receiverstoadditionally reportnon-sequential datathey havereceived.When coupledwith aselectiveretransmission policyimplemented inTCP senders,This workwas supportedby theDirector,office ofEnergy Re-search,Scientific ComputingStaff,of theU.S.Department ofEnergyunder considerablesavings can be achievedSeveral transportprotocols haveprovidedfor selectiveacknowledgment SACKof receiveddata.These includeNETBLT[CLZ87],XTP[SDW92],RDP[HSV84]and VMTP[Che88].The firstproposals for addingSACK to TCP[BJ88,BJZ90]were laterremoved fromthe TCPRFCs RequestForComments[BBJ92]pending furtherresearch.The cur-rent proposalforaddingSACK toTCP is givenin[MMFR96].We usesimulations toshow howthe SACK option definein[MMFR96]can beof substantialbenefits relativetoTCP without SACK.Without SACK,Reno TCPhas performance problems when multiple packets aredropped from one window of data.These problemsresult fromthe needto awaita包直到所有的数据包被传完New Reno保持在快速恢复状态，直到在快速恢复阶段初始化未被成功传送的数据全被响应5SACK TCP前面这几种算法，在单包丢弃时，效果是不错的，但如果在同一个窗口下同一个数据窗口下，它们的性能都有比较大的局限性后来浮现了基于选择应答sack的算法，它较好的解决了在同一个数据包丢失的问题，这种算法的基本原理是这样的SACK算法中，有一个称作选择域option的数据段SACK的选择域的数据段，ACK中的SACK域包含一定数量的SACK块，每一个SACK块都记录了信宿端接收或者缓存的非连续分组SACK块的多少因应用和需要的不同而有所不同与Reno相似，当发送端收到prexmtthresh个重复的ACK时，重发丢失的分组，并将拥塞窗口减半，进入快速恢复过程期间，SACK维护了一个称为“pipe”的变量用来估计浮现在网络中的分组数当“pipe”小于拥塞窗口的大小时，发送端发送新的或者需要重发的分组，并将变量“pipe”加一当发送端接收了一个带SACK选项的重复ACK,表明新分组已被接收端接收,pipe变量减一Pipe变量的使用将何时发送与发送哪一个分组有效的解偶当发送端被许可发送分组时，挨次将发送丢失列表中记录的分组如果没有这样的分组，而接收端的通报窗口又足够大，则发送端将发出新的数据分组当重传分组本身被丢弃后，SACK用重传超时来探测丢失，再次重传后进入慢启动过程，在确认了所有浮现在进入快速恢复阶段的分组后，发送端将从快速恢复中退出TCP SACK与TCP Reno最主要的区别是在多个数据包丢失的情况下进行拥塞避免的方式的不同retransmission timer expiration beforere-initiating dataflow.Situations inwhich thisproblemoccurs are illustrated laterin thispaper forexample,see Section

6.

4.Not all of Reno1s performanceproblems area necessaryconsequence of the absenceof SACK.To showwhy,we implementeda variantof the Reno algorithmsin oursimulator,called New-Reno.Using asuggestion fromJaney Hoe[Hoe95,Hoe96],New-Reno avoidsmanyof theretransmit timeoutsof Reno without requiringSACK.Nevertheless,New-Renodoes notperform aswell asTCPwith SACK whena largenumber of packets are droppedfrom a window of data.The purposeof ourdiscussion of New-Reno isto clarifythefundamental limitationsof the absence of SACK.In the absence of SACK,both Reno andNew-Reno senderscan retransmitat most one dropped packet per round-trip time,even ifsendersrecover frommultiple dropsin awindow of data withoutwaiting fora retransmittimeout.This characteristicis notshared byTahoe TCP,which isnot limitedtoretransmitting atmost onedroppedpacketper round-trip time.However,it is^fundamentalconsequence of theabsenceofSACKthat thesender hasto choosebetween thefollowingstrategies to recover fromlost data:1retransmitting atmostonedroppedpacket perround-trip time,or2retransmitting packets that mighthave alreadybeen successfullydelivered.To illustratethe advantagesof TCPwithSACK,we showsimulations withSACKTCP,using theSACK implementationin oursimulator.SACK TCPis basedon aconservativeextension ofthe Renocongestion control algorithms withthe additionofselective acknowledgmentsand selectiveretransmission.With SACK,a senderhas abetteridea ofexactly whichpackets have been successfullydelivered ascompared withcomparableprotocols lackingSACK.Given suchinformation,a sendercan avoidunnecessarydelays andretransmissions,resulting inimproved throughput.We believetheaddition ofSACK toTCPisone ofthe mostimportant changesthat shouldbe madeto TCPatthis timeto improveits performance.In Sections2through5we describethe congestion control andpacket retransmissionalgorithmsin Tahoe,Reno,New-Reno,and SACK TCP.Section6shows simulationswithTahoe,Reno,New-Reno,and SACK TCP inscenarios rangingfrom oneto fourpacketsdropped from awindow ofdata.Section7shows atrace of Reno TCPtaken fromactualInternet traffic,showing that the performanceproblems of RenowithoutSACK areof morethantheoretical interest.Finally,Section8discusses possiblefuture directionsfor TCPwithselective acknowledgments,and Section9gives conclusions.2Tahoe TCPModernTCP implementationscontain a number ofalgorithms aimedat controllingnetworkcongestion whilemaintaining gooduser throughput.Early TCP implementationsfollowed ago-back-n.model usingcumulative positiveacknowledgment andrequiring aretransmittimerexpirationtore-send datalost duringtransport.These TCPsdid littletominimize networkcongestion.The Tahoe TCP implementationadded anumber ofnew algorithmsand refinementstoearlier implementations.The newalgorithms includeSlow-Start,Congestion Avoidance,and FastRetransmit[Jac88].The refinementsinclude amodification to the round-trip timeestimatorused toset retransmission timeout values.All modificationshave beendescribedelsewhere[Jac88,Ste94].The FastRetransmit algorithmis ofspecial interestin thispaper becauseit ismodifiedsubsequent versionsof TCP.With FastRetransmit,after receivinga smallnumber ofduplicateacknowledgments for the sameTCP segmentdup ACKs\the datasender infersthata packethas been lost andretransmits thepacket withoutwaiting fora retransmissiontimerto expire,leading tohigher channelutilization andconnection throughput.3Reno TCPTheReno TCP implementation retainedthe enhancementsincorporated intoTahoe,but modifiedthe FastRetransmit operationto includeFast Recovery[Jac90].The newalgorithmprevents thecommunication pathpipe fromgoing emptyafter FastRetransmit,thereby avoidingthe needto Slow-Start torefill itafter a single packet loss.Fast Recoveryoperatesby assumingeach dup ACK receivedrepresents a single packethaving leftthe pipe.Thus,during Fast Recovery theTCP senderis ableto makeintelligent estimatesof theamountof outstandingdata.In Reno,the sendersusable windowbecomes othergateways thatfail tomonitor theaveragequeue sizeuntil the number of dup ACKsre^chestcprexmtthresh,and thereaftertracksthe number of duplicateACKs.Thus,during Fast Recovery thesender“inflate”itswindow by thenumberofdup ACKs ithas received,according to the observationthat eachdupACK indicatessome packethas beenremoved fromthe networkand isnow cachedatthe receiver.After enteringFast Recoveryand retransmittinga singlepacket,the sendereffectivelywaits untilhalf awindow ofdup ACKshave been received,and thensends anewpacket foreach additionaldupACKthat is received.4New-Reno TCPWeinclude New-Reno TCPin thispaper toshow howa simplechange toTCP makesitpossible toavoid someoftheperformanceproblemsofReno TCP withoutthe additionofSACK.At the same time,we useNew-Reno TCPto explorethe fundamentallimitations ofTCPperformance in theabsenceofSACK.The New-Reno TCPin thispaper includesa smallchange tothe Renoalgorithm atthesender thateliminates Renoswait fora retransmittimer whenmultiple packetsare lost froma window[Hoe95,CH95].The changeconcerns thesender*s behaviorduring Fast Recoverywhen apartial ACKisreceivedthat acknowledgessome butnot allofthepackets thatwereout-standing atthe startof thatFast Recoveryperiod.In Reno,partial ACKstake TCPout ofFast Recovery by“deflating“the usablewindow backtothesize ofthe congestionwindow.In New-Reno,partial ACKsdo nottake TCPout of FastRecovery.Instead,partial ACKsreceivedduring FastRecovery aretreated asan indicationthatthepacket immediatelyfollowingthe acknowledgedpacket inthe sequencespace hasbeenlost,and shouldberetransmitted.Thus,whenmultiple packetsarelostfromasinglewindow ofdata,New-Renocan recoverwithout aretransmissiontimeout,retransmitting onelost packetperround-triptime until allofthe lostpackets fromthat windowhavebeenretransmitted.New-Renoremains inFastRecoveryuntilallofthe data outstandingwhen FastRecovery wasinitiatedhas beenacknowledged.The implementationsofNew-Reno andSACKTCPin oursimulator alsouse a“maxburst”parameter.In our SACKTCP implementation,the maxburstparameter limitsto four thenumberofpacketsthatcanbe sent inresponse toasingleincoming ACK,even ifthesenders congestionwindow wouldallow morepackets tobesent.In New-Reno,themaxburst parameter is settofourpackets outsideofFastRecovery,and totwo packetsduring FastRecovery,to moreclosely reproducethe behaviorofReno TCP duringFastRecovery.The“maxburst“parameterisreally onlyneeded forthe firstwindowofpacketsthat aresent afterleaving FastRecovery.If thesender hadbeen preventedbythereceiver sadvertisedwindow fromsending packetsduringFastRecovery,then,without maxburst,itis possibleforthesender tosend alarge burstofpackets upon exiting FastRecovery.Thisapplies toRenoandNew-Reno TCP,and toa lesserextent,to SACKTCP.In TahoeTCP theSlow-Start algorithmprevents burstsafter recoveringfromapacketloss.The burstsofpackets uponexiting FastRecovery withNew-RenoTCP areillustrated in Section6in thesimulationswith threeand fourpacket drops.Bursts ofpacketsuponexitingFastRecoverywith RenoTCP areillustratedin[Flo95].5SACK TCPThe SACK optionfollows theformat in[MMFR96].From[MMFR96],the SACKoptionfield containsanumberofSACK blocks,where each SACKblockreports anon-contiguous setofdatathat hasbeenreceivedand queued.The firstblock ina SACKoption is requiredto reportthedatareceivers most recently receivedsegment,and theadditionalSACK blocksrepeat themostrecentlyreported SACK blocks[MMFR96].Inthese simulationseachSACK option isassumed tohave roomfor three SACKblocks.Whenthe SACKoptionisused withthe Timestampoption specifiedfor TCPExtensions forHighPerformance[BBJ92],then theSACKoptionhas roomfor onlythreeSACKblocks[MMFR96].If theSACKoptionwere tobe usedwith boththe Timestampoption andwithT/TCP TCPExtensions forTransactions[Bra94]theTCPoption spacewould haveroom9for onlytwo SACKblocks.The1990“Sack TCPimplementation onour previoussimulator isfrom StevenMcCanneand SallyFloyd,and does not conformtotheformats in[MMFR96].The new“Saeki“implementation containsmajor contributionsfrom KevinFall,Jamshid Mahdavi,and MattMathis.The congestion control algorithmsimplemented in ourSACKTCParea conservativeextensionof Renoscongestioncontrol,in thatthey usethesamealgorithms forincreasingand decreasingthe congestionwindow,The SACKTCPimplementationin thispaper,calledSaeki“inoursimulator,is alsodiscussed in[Flo96b,Flo96a].and makeminimal changestothe othercongestioncon-trolalgorithms.Adding SACKtoTCPdoesnotchange thebasicunderlying congestioncontrol algorithms.TheSACKTCPimplementationpreserves thepropertiesof Tahoeand RenoTCP ofbeing robustinthepresence ofout-of-order packets,and usesretransmit timeoutsas therecovery methodof lastresort.The maindifferencebetween theSACKTCPimplementation andtheRenoTCPimplementationis inthebehavior whenmultiplepacketsaredroppedfromonewindowofdata.中文翻译1介绍在这篇论文中，我们将介绍使用选择重发（sack）选项的TCP协议的益处，拥塞控制，算法普通分为两类基于窗口的和基于位率的拥塞控制算法，基于窗口的控制算法是通过源端限制数据报的传送，并且不应答这种机制在源端不需对发送的数据进行整形，它的优点在于易于实现，并对内在的由于限制最大量数据量所造成的不良影响能进行控制，然而，基于位率的控制党法，要对即将发送的流量进行整形，以防止爆发数据流的浮现这种算法的优点在于如果源端的传输率和网络匹配，那末就缩减了交换机所需的缓存区许多传输协议提供选择重传选项中描述的TCP快速恢复算法的典型实现，TCP数据发送端在发生一个超时重传时仅仅重传一个数据包，或者当三个重复确认到达时触发快速重传算法单单一个超时重传可能导致许多数据包的重传，但是每次Reno快速重传算法的启用仅仅导致一个数据包的重传因此，当多个数据包从一个数据窗口中丢失并且触发快速重传和快速恢复算法时，问题就会产生在这种情况下，如果SACK选项可用，TCP发送端在快速恢复期间就有足够的信息来决定重传哪个数据包，不重传哪个数据包这篇文档仅对不能使用TCP选择确认SACK选项的TCP连接合用在没有SACK的情况下，TCP发送端在快速恢复期间只能得到很少的信息来作出重传决定从三个重复确认中，发送端判断出一个数据包丢失了，并且重传那个声明了数据包在这之后，数据发送端可能接收到此外的重复确认，因为在发送端进入快速重传时，数据端确认已经发送的附加数据包在多个数据包从一个数据窗口中丢失这种情况下，当发送端从对重传的数据包就是第一次进入快速重传时重传的数据包的一个确认时，它获得第一条可用新信息如果惟独一个数据包丢失了，对这个重传的数据包的确认将确认所有进入快速重传在没有重新排序的情况下之前发送的数据包但是，当有多个数据包丢失时，对此重传数据包的确认将确认一些而不是所有在快速重传之前发送的数据包我们称这个包是一个部份确认和许多其它的建议一起，［Hoe95］建议在快速恢复期间TCP数据发送端通过判断声明的数据包已经丢失和重传那个数据包的方式响应一个部份确认为了说明使用选择重传sack TCP协议的好处，我们仿真了TCP SACK使用网络仿真器并且TCP SACK是TCP Reno的适当扩展解决拥塞是采用基于窗口的端到端的算法，以前主要有两种Tahoe和Reno.分别对通过重复应答者收到重复应答时，一律认为网络发生了拥塞，而Reno在收到重复的应答时却认为网络可能是暂时的而不是持久的拥塞，Reno可能导致在同一窗口中浮现多个数据包被丢失的现象Tahoe包括慢启动、拥塞避免和快速重传等几个主要阶段后来随着网络技术的发展，在Reno算法的基础上，浮现了New Reno算法下面是几种算法的分析TahoeTCP2TCP Tahoe指的是1988年加入Van Jacobson提出的慢启动、拥塞避免和快速重传算法之后的

4.3BSD或者类似的TCP实现版本正如RFC793所要求的,Tahoe采用了递增式肯定重传策略和模型（滑动窗口算法）在慢启动阶段，拥塞窗口（cwnd）随着确认的到来以指数方式递增（这种以ACK来触发TRANSMIT的机制，被VJ称为，或者，直到到达阀值ssthresh（slow startthreshold）之后TCP进入拥塞避免阶段，cwnd每隔RTT以线性方式递增1个单位如果连续收到3个重复确认，TCP不等重传定时器溢出，即将重传丢失的报文段，这称为快速重传；之后TCP返回T曼启动状态早期的TCP实现算法是基于积极响应并通过重传来重发丢失的数据，当丢包时，TCP减小拥塞窗口，并重传被丢失的分组，然而在使用网络拥塞达到最小方面，这些算法的性能很差TCP Tahoe参考了早期的实现方法，并增加一些算法，包括慢启动窗口大小以指数速度增加；拥塞避免窗口的大小以一个线形速度增加；快速重传从一个丢包的状态恢复而不需要等待重传定时器的超时Tahoe还包括对往返时间估计量的修改，这一参数的准确估计是非常重要的，因为它被用来设置重传超时定时器的基值，此外，Tahoe引入快速重传机制，即当接受者收到几个对同一TCP报文的相同应答时，发送方就判断已经发生了丢包，而没有必要的等到重传定时器超时，并且重传相应的包，提高了信道的利用率RenoTCP3TCP Reno在快速重传之后进入快速恢复（而不是TCP Tahoe采用的慢启动）VJ给出的原因是，接收方发送重复确认不仅仅意味着有报文段丢失了，还意味着有（其它的）报文段离开了网络，到达了接收方的缓冲区（self-clocking）,也就是说，网络“管道”空出了新的位置，这样TCP可以继续发送新的报文段（当然cwnd应该减小一些）另一个不进入慢启动的原因是，dup ACKs的到达已经使得发送方的确认“时钟”得到了同步快速重传和快速恢复通常一起实现L收到第3个重复确认之后，令ssthresh=max（FlightSize/2,2*SMSS）；

2.重传丢失的报文段，并令cwnd二ssthresh+3；

3.对每一个dupACK,cwnd+=SMSS,此时，窗口大小允许的话发送一个报文段;

4.当确认了新数据的ACK到达时，令cwnd=ssthresh,即进入拥塞避免状态TCP Reno在一个窗口中的多个报文段同时丢失的情况下会浮现性能问题，因为此时引起TCP退出快速恢复的“确认了新数据的ACK”没有确认进入快速重传之前丢失的所有报文段其它丢失的报文段会使得TCP不断执行快速重传和快速恢复，而cwnd和ssthresh亦会多次被减半，大大降低了吞吐量Reno修改了Tahoe的快速重传为快速恢复（指由三个重复的应答判断有包丢失时，仅使窗口值减半）新的算法防止通信管道在快速重传之后变为空，于是避免了慢启动在单包丢失之重填快速重传主要决定于收到的重复应答数目的初始门限值，一旦达到了门限值，发送方就重传一个数据包，同时使拥塞窗口减半，与Tahoe的慢启动不同，Reno的发送方用额外到达的应答来为后续包定时发送方的可用窗口变为发送窗口与拥塞窗口的最小值，于是在快速恢复中，发送方根据收到的重复的应答来变动自己的窗口相应地，每一个重复应答表示有一些包已被移出网络,并且现在已经到达接收方在进入快速恢复阶段并重发一个数据包后，对应每一个额外重复地应答传出一个新包，当接受到新数据地应答时，发送方退出快速恢复阶段并设置Ndup为0Reno的理想情况是在一个窗口中单包丢失时，Reno发送方在每一个往返时间中最多重传一个包，但是它在同一个窗口中浮现多包丢失时可能浮现的问题4New RenoTCPTCP NewReno修改了TCP Reno的快速恢复算法，以处理一个窗口中的多个报文段同时丢失时浮现的“部份确认”（partial ACKs,它在快速恢复阶段到达并且确认了新数据，但它只确认了进入快速重传之前发送的一部份数据）在这种情况下，TCP Reno会退出快速恢复状态，等待重传定时器溢出或者dupACKs的到达，但是TCP NewReno并不退出快速恢复状态，而是

（1）重传紧接着那个partial ACK之后的报文段，

（2）cwnd-=partialACK确认的新数据,cwnd+;SMSS,

（3）对第一个（另一个建议是每一个）partial ACK,复位重传定时器New Reno做了一个变化，即当多包丢弃时，去掉了Reno的等待重传定时器，在快速恢复的阶段，当发送端收到一个部份应答来表征一些包而不是所有包，在这个阶段的起始时间没有被成功传送在Reno中，部份包通过减少可用窗口至拥塞窗口大小以使TCP退出快速恢复在New Reno中，部份应答的包已经丢失，需要重传New Reno的恢复不需要重传超时，每一个往返时间重传一个。