TCP 拥塞窗口检验

剑心通明

本备忘录的状态
本文档讲述了一种Internet社区的实验
协议
，它并没有制定一种Internet标准，需要进
一步进行讨论和建议以得到改进。本备忘录的发布不受任何限制。
版权声明
Copyright(C)TheInternetSociety(2001).
摘要
TCP
拥塞窗口控制网络中一个
TCP
流的包的数目，然而，发送方长时间无响应或者由
于应用程序的限制会导致拥塞窗口的无效，此时，拥塞窗口不在反映网络的当前状况，本文
档描述了对
TCP
拥塞控制算法的一种简单修正，使得在发送后一段足够长的时间后，拥塞
窗口。同时使用慢启动决值来保存拥塞窗口以前的值。
当拥塞窗口在应用程序限制期间增加时，也会导致一个无效窗口，而原来拥塞窗口的值
可能从来没有利用，我们建议在
TCP
发送方有应用程序限制时，不增加拥塞窗口的大小，
我们从采用模拟和FREEBSD中实现的实验揭示了这些算法。
目录
1转换和异义 2
2介绍 2
3描述 3
3．1减小拥塞窗口的基本算法 4
3．2减小拥塞窗口的伪码 4
4模拟 5
5实验 5
6结论 6
7参考 6
8
安全
性考虑 7
9.作者地址 7
10.版权说明 8
致谢 8
1转换和异义
关键字MUST,MUSTNOT,REQUIRED,SHALL,SHALLNOT,SHOULD,SHOULDNOT,
RECOMMENDED,MAY,andOPTIONAL,出现在本文中时，参照[97]中的解释。
2介绍
TCP
拥塞窗口控制网络中一个
TCP
流中包的数量，拥塞窗口采用慢增快减(AIMD)的机
制来试探网络带宽，作动态调整了改善网络状态。AIMD机制在发送方有连续的数据发送时
工作良好，这对使用缓冲数据的
TCP
来说是很典型的。对于使用
TCP
的
TELNET
应用程序
来说，发送方只有很少的数据或没有数据发送，发送速率也是由用户产生数据的速率决定的，
随着WEB的诞生，包括动态产生数据的
TCP
发送方和持续连接
TCP
的HTTP1.1的发展，
应用程序限制和网络限制之间的交互变得越来越重要，更精确的说，我们把网络限制期间定
义为发送者以满窗口大小发送数据，
当发送者由于应用程序限制而造成时间太长会导致拥塞窗口的无效，在由于网络限制期
间，由于窗口数据总是没有丢失，拥塞窗口总是被检验有效，此时，总是有超时新数据的确
认输入流给出网络中最近可用的带宽，与之相反，在由于应用程序限制期间，用拥塞窗口来
估计可用带宽随着时间流逝而准确性降低，特别的，被用来网络限制的容量可能会被其他的
流量占用，
当前的
TCP
实现在一段时间的IDLE后，有一些启动的措施，在IDLE的时间超过RTO
估计值(正如
RFC
2581和附录[VJ88]所建议的)后，一些
TCP
实现采用慢启动机制，而其他
的实现则并不降低它们的拥塞窗口，
RFC
2581中推荐：如果
TCP
在超过超时重发的间隔内
没有数据发送，
TCP
应将窗口大小设置成不超过原来窗口大小，在[HTH98]中讨论了在IDLE
后
TCP
慢启动的建议，除了在
TCP
和IP环境中，拥塞信息的检验也在其他的环境中提到，
如在
ATM
网络中的“或使用它，或丢弃它”的机制中。
在一段应用程序限制后，为了讨论拥塞窗口的有限性，我们对
TCP
的拥塞控制算法作
了一点简单的修改，使得在发送后拥塞窗口的大小从一段足够长的应用程序限制退化到网络
限制期间，特别的，在一段IDLE后，对于在每个数据流保持IDLE的RTT内，发送方都应
将它的拥塞窗口减半。
当拥塞窗口大小减小时，慢启动的阕值保留为最近拥塞窗口的大小，特别的，在一段应
用程序限制之后，阕值从不降低，在窗口减小以前，阕值被设为它的当前最大值，这种阕值
的使用容许
TCP
发送方在一段应用程序限制后增加它的发送速率来加快慢启动恢复拥塞窗
口的以前的值，更精确的，在一段应用程序限制后，拥塞窗口减小，如果阕值小于窗口大小
的3/4，那么阕值在拥塞窗口减小之前，阕值增加到窗口的3/4。
在应用程序限制期间，当拥塞窗口增大时，也会导致无效的拥塞窗口，而拥塞窗口原来
的值可能从来没有使用，我们都知道，当有确认帧到达时，如果接收方的广告窗口和满启动
及拥塞避免算法容许，没有检查拥塞窗口原来的值有没有被使用，当前所有的
TCP
实现都
增加拥塞窗口大小，本文建议在应用程序限制期间，并不激活窗口增加算法[MSML99]，
特别的，当
TCP
发送方在应用程序限制时，发送方并不增加拥塞窗口，这种限制防止拥塞
窗口的任意增加，以防止拥塞窗口不被网络支持，在[MSML99SETION5.2]中：“这种限制
保证只有在
TCP
实际上向网络成功发送数据后，窗口大小才增加。”
在一段应用程序限制后保持一个大的拥塞窗口一个值得考虑的问题是在一段静止期间
后，发送方突然有大量的数据要发送，可能立即发送一个满窗口的包的数据，这种发送突发
大量包的问题可以被基于速率的方法(RBP,[VH97])有效的处理，或者最大发送数据控制
[FF96]，即使使用限制包的发送机制，一个没有充分使用的拥塞窗口不能被作为当前可用带
宽的表示，
3描述
当一个
TCP
发送者有足够的数据来充分使用网络容量时，窗口大小和阕值将被设置为与网
络状况相似的值，当
TCP
发送方停止发送数据时，流将停止采样网络状况，并将导致拥塞
窗口的值不准确，我们相信，在这种环境下，对每个RTT内流不活动的状况，将拥塞窗口
减半是一种正确的处理方法，减半的值是很保守的数值，这是建立在有丢包的情况下，倍减
将多快减小窗口的基础上。
另一种可能是发送者并不停止发送，是由于应用程序限制而不是网络限制，使得提供的数据
少于拥塞窗口容许发送的数据。在这种情况下，
TCP
流仍然采样网络状况，但并不提供足
够的流量来保证在网络中有足够的带宽来以满拥塞窗口来发送数据，在这些情况下，我们相
信，对发送方而言，在每个RTT中跟踪拥塞窗口的最大值，并将拥塞窗口的值设为当前窗
口和曾经的最大值的均值，是一种正确的处理。
在拥塞窗口减小以前，阕值被设为当前值和窗口的3/4两者之中的最大值，如果发送方
有比减小了的窗口大小有更多的数据发送，
TCP
将慢启动窗口值到原来窗口的值。
窗口的3/4可以理解为拥塞窗口的最近一段时间内的保守估计值，且
TCP
应能慢启动
到这个值，每次拥塞窗口达到某个最大值，
TCP
降低其拥塞窗口的大小，当处于这种稳定
状况，拥塞窗口的平均值为最大值的3/4，当连接变为应用程序限制时，窗口大小将变为最
大值的3/4，在这种情况下，窗口大小本身代表了拥塞窗口大小的平均值，然而，当窗口等
于最大值时，如果连接变为应用程序限制，那么拥塞窗口的平均值为窗口的3/4。
有一种可能性是将阕值设为当前阕值和窗口原来大小两者之间的最大值，容许
TCP
慢
启动至窗口的原来大小，对于阕值的设置，可以做更进一步的实验来评估这两种选择。
在对于一个确认帧的回应时，对于拥塞窗口的增加的各种情况，我们相信，当确认帧到
达时，只要窗口是满的，增加拥塞窗口都是正确的处理方法。
我们把这种改进称为
TCP
拥塞窗口校验(CWV)，因为这总是保证拥塞窗口总反映当前
的网络状况，
3．1减小拥塞窗口的基本算法
在CWV算法中，一个关键的问题是在应用程序限制的流中，对每一个往返时间内，如
何将这些原则应用于降低拥塞窗口中去，我们使用
TCP
的重发超时器作为往返时间的合理
上限，并在每一个重发超时内迅速降低拥塞窗口大小。
基本算法在
TCP
中可按如下进行实现：当
TCP
发送一个新包时，它检查自从前一包发
送后，是否已过了一个重发超时，如果是，则阕值设为窗口的3/4和当前阕值两者之间的最
大值，然后，自从前一包发送后过一个重发超时，则将拥塞窗口减半，另外，T_prev被设
置为当前时间，而W_used被重置为0，T_prev被用来决定自从发送的上一次网络限制或在
一段IDLE已经减小了窗口后的流逝的时间，当发送方是应用程序时，W_used保留自从发
送方为上一次网络限制来的被使用的最大拥塞窗口值。
在最近IDLE时间内决定RTO的数目的机制可以通过一个计时器来实现，计时器在最
后一次的包发送后的每一个RTO内超时，而不是检查每一个包，在不同操作系统上的效率
将表现那一个更容易实现。
在
TCP
发送一个包以后，它会检查这个包是否填满了拥塞窗口，如果是，发送者是受
网络限制的，并把T_prev的值设为当前
TCP
的时钟，W_used被置为0。
当
TCP
发送一个没有填满拥塞窗口的包时，并且
TCP
发送队列为空时，发送者是受应
用限制的，发送方检查未确认的帧是否比W_used大，如果是，W_used被置为未确认的帧
数，另外，
TCP
检查自从T_prev以来流逝的时间是否大于RTO，如果是，
TCP
在一个RTO
间隔内，但小于两个RTO内是应用程序限制，而不是网络限制的，在这种情况下，
TCP
将
阕值设为窗口的3/4和当前阕值两者之间的最大值，并将其拥塞窗口减小到(cwnd+W_used)/2.
W_used被置为0，T_prev的值设为当前的时钟，这样直到另一个RTO流逝，才会进一步减
小拥塞窗口，因此，在应用程序限制时，CWV算法每个RTO减低拥塞窗口的大小。
3．2减小拥塞窗口的伪码
Initially:
T_last=tcpnow,T_prev=tcpnow,W_used=0
Aftersendingadatasegment:
Iftcpnow-T_last>=RTO
(Thesenderhasbeenidle.)
ssthresh=max(ssthresh,3*cwnd/4)
Fori=1To(tcpnow-T_last)/RTO
win=min(cwnd,receiver'sdeclaredmaxwindow)
cwnd=max(win/2,MSS)
T_prev=tcpnow
W_used=0
T_last=tcpnow
Ifwindowisfull
T_prev=tcpnow
W_used=0
Else
Ifnomoredataisavailabletosend
W_used=max(W_used,amountofunacknowledgeddata)
Iftcpnow-T_prev>=RTO
(Thesenderhasbeenapplication-limited.)
ssthresh=max(ssthresh,3*cwnd/4)
win=min(cwnd,receiver'sdeclaredmaxwindow)
cwnd=(win+W_used)/2
T_prev=tcpnow
W_used=0
4模拟
在网络模拟器[NS]中已将CWV作为一个选项加以实现，在对CWV的有效性检验时，可以
在"tcl/test"下运行"./test-all-tcp"命令。模拟器显示了在
TCP
连接过了一段应用程序限
制后用CWV来降低拥塞窗口的大小，并在传输是应用限制时，来限制拥塞窗口的增加。正如
在模拟器显示的，保持连接历史的阕值的使用是拥塞窗口有效性检验的关键部分。在[HPF99]
对这些模拟有详细的讨论。
5实验
在FREEBSD3.2的
TCP
实现中，我们实现了CWV机制，在[HPF99]对这些实验有详细
的讨论。
第一个实验检测了在应用程序限制期间用拥塞窗口有效性检验的机制来限制窗口的增
长的效果。实验采用使用Dummynet的modem连接，速率为30Kb/s，有5个包缓冲可用，
现在大部分的modem的缓冲区都比5个缓冲区多，但较旧的modem太多的缓冲区可能有限
制，在传输的开始部分，用户输入通过连接发送，之后，用户造成有大量数据的发送。
对于没有修改的
TCP
，在开始时，每个返回的确认帧将导致窗口的增加。结果导致从应用
程序的大量数据传到传输层，导致数据丢失而重发，
对于用拥塞窗口有效性检验改进了的
TCP
，当窗口没有填满时，拥塞窗口并不增加，而
在应用程序限制的时间与用户实际使用接近时，拥塞窗口会减小。大量突发数据被拥塞窗口
限制，使得流的丢失达到最少，最终的结果是由于为了避免超时重发，传输速率比没有使用
CWV的要快近30%。
第二个实验是采用拨号的
PPP
连接，有更多的缓冲区，对于没有修改的
TCP
，最早大
量数据的发送并没有造成丢失，当导致RTT增加到近5秒，连接变得为接收方的窗口限制。
对于用拥塞窗口有效性检验改进了的
TCP
，流的处理进行的很好，没有产生大量的突发
数据，在这种情况下，窗口的线形增加在缓冲区慢慢填满时也只造成RTT的缓慢增长。
对于第二个实验，改进和没改进的
TCP
以几乎同等的时间发送完数据，这是由于modem
的缓冲区比接收方的窗口大，连接在两种情况下都被充分利用，很明显，modem的缓冲区
在RTT上的影响并没有期望，但对当前产生突发数据的
TCP
实现而言，是很有必要的。
6结论
本文列举了在一段IDLE期间或者发送方是应用程序限制并在增加拥塞窗口之前采用的
用拥塞窗口有效性检验的几种
TCP
算法。这些算法的目的是为了让
TCP
的拥塞窗口网络路径
上
TCP
连接状况，而同时保留网络路径上的一些原来的状况。我们相信，这些改进通过防止
由于
TCP
发送方没有更新关于目前网络状况而造成的包丢失，无论对网络还是
TCP
流本身都
是有益的，将来的工作在于使用模拟器和实验来调查这些算法带来的益处。另外的工作是在
发送方在对于
TCP
往还时间没有准确的估计时，描述对于
TCP
实现的一种更复杂的CWV算法。
7参考
[FF96]Fall,K.,andFloyd,S.,Simulation-basedComparisonsof
Tahoe,Reno,andSACK
TCP
,ComputerCommunicationReview,
V.26N.3,July1996,pp.5-21.URL
"http://www.aciri.org/floyd/papers.html".
[HPF99]MarkHandley,JitendraPadhye,SallyFloyd,
TCP
Congestion
WindowValidation,UMassCMPSCITechnicalReport99-77,
September1999.URL"ftp://www-
net.cs.umass.edu/pub/Handley99-tcpq-tr-99-77.ps.gz".
[HTH98]AmyHughes,JoeTouch,JohnHeidemann,"Issuesin
TCP
Slow-StartRestartAfterIdle",WorkinProgress.
[J88]Jacobson,V.,CongestionAvoidanceandControl,Originally
fromProceedingsofSIGCOMM'88(PaloAlto,CA,Aug.
1988),andrevisedin1992.URL"http://www-
nrg.ee.lbl.gov/nrg-papers.html".
[JKBFL96]RajJain,ShivKalyanaraman,RohitGoyal,SoniaFahmy,and
FangLu,Commentson"Use-itorLose-it",
ATM
Forum
DocumentNumber:
ATM
Forum/96-0178,URL
"http://www.netlab.ohio-
state.edu/~jain/atmf/af_rl5b2.htm".
[JKGFL95]R.Jain,S.Kalyanaraman,R.Goyal,S.Fahmy,andF.Lu,A
FixforSourceEndSystemRule5,AF-TM95-1660,December
1995,URL"http://www.netlab.ohio-
state.edu/~jain/atmf/af_rl52.htm".
[MSML99]MattMathis,JeffSemke,JamshidMahdavi,andKevinLahey,
TheRate-HalvingAlgorithmfor
TCP
CongestionControl,
June1999.URL
"http://www.psc.edu/networking/ftp/papers/draft-
ratehalving.txt".
[NS]NS,theUCB/LBNL/VINTNetworkSimulator.URL
"http://www-mash.cs.berkeley.edu/ns/".
[
RFC
2581]Allman,M.,Paxson,V.andW.Stevens,
TCP
Congestion
Control,
RFC
2581,April1999.
[VH97]VikramVisweswaraiahandJohnHeidemann.ImprovingRestart
ofIdle
TCP
Connections,TechnicalReport97-661,
UniversityofSouthernCalifornia,November,1997.
[Dummynet]LuigiRizzo,"DummynetandForwardErrorCorrection",
Freenix98,June1998,NewOrleans.URL
"http://info.iet.unipi.it/~luigi/ip_dummynet/".
8
安全
性考虑
通常有关
TCP
拥塞控制的
安全
性考虑在
RFC
2581中讨论。本文描述了那些拥塞控制过程的
一个方面的一种算法。因此，在
RFC
2581中讨论的
安全
性考虑也适合本算法，对于本算法
还没有其他的
安全
性问题。
9.作者地址
MarkHandley
AT&TCenterforInternetResearchatICSI(ACIRI)
Phone:+15106662946
EMail:mjh@aciri.org
URL:http://www.aciri.org/mjh/
JitendraPadhye
AT&TCenterforInternetResearchatICSI(ACIRI)
Phone:+15106662887
EMail:padhye@aciri.org
URL:http://www-net.cs.umass.edu/~jitu/
SallyFloyd
AT&TCenterforInternetResearchatICSI(ACIRI)
Phone:+15106662989
EMail:floyd@aciri.org
URL:http://www.aciri.org/floyd/
10.版权说明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,
INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
致谢
Fundingforthe
RFC
Editorfunctioniscurrentlyprovidedbythe
InternetSociety.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/4206/showart_506667.html