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
估計值(正如RFC2581和附錄[VJ88]所建議的)后，一些TCP實現采用慢啟動機制，而其他
的實現則并不降低它們的擁塞窗口，RFC2581中推薦：如果TCP在超過超時重發的間隔內
沒有數據發送，TCP應將窗口大小設置成不超過原來窗口大小，在[HTH98]中討論了在IDLE
后TCP慢啟動的建議，除了在TCP和IP環境中，擁塞信息的檢驗也在其他的環境中提到，
如在ATM網絡中的“或使用它，或丟棄它”的機制中。
在一段應用程序限制后，為了討論擁塞窗口的有限性，我們對TCP的擁塞控制算法作
了一點簡單的修改，使得在發送后擁塞窗口的大小從一段足夠長的應用程序限制退化到網絡
限制期間，特別的，在一段IDLE后，對于在每個數據流保持IDLE的RTT內，發送方都應
將它的擁塞窗口減半。
當擁塞窗口大小減小時，慢啟動的闋值保留為最近擁塞窗口的大小，特別的，在一段應
用程序限制之后，闋值從不降低，在窗口減小以前，闋值被設為它的當前最大值，這種闋值
的使用容許TCP發送方在一段應用程序限制后增加它的發送速率來加快慢啟動恢復擁塞窗
口的以前的值，更精確的，在一段應用程序限制后，擁塞窗口減小，如果闋值小于窗口大小
的3/4，那么闋值在擁塞窗口減小之前，闋值增加到窗口的3/4。
在應用程序限制期間，當擁塞窗口增大時，也會導致無效的擁塞窗口，而擁塞窗口原來
的值可能從來沒有使用，我們都知道，當有確認幀到達時，如果接收方的廣告窗口和滿啟動
及擁塞避免算法容許，沒有檢查擁塞窗口原來的值有沒有被使用，當前所有的TCP實現都
增加擁塞窗口大小，本文建議在應用程序限制期間，并不激活窗口增加算法[MSML99]，
特別的，當TCP發送方在應用程序限制時，發送方并不增加擁塞窗口，這種限制防止擁塞
窗口的任意增加，以防止擁塞窗口不被網絡支持，在[MSML99SETION5.2]中：“這種限制
保證只有在TCP實際上向網絡成功發送數據后，窗口大小才增加?！?BR>在一段應用程序限制后保持一個大的擁塞窗口一個值得考慮的問題是在一段靜止期間
后，發送方突然有大量的數據要發送，可能立即發送一個滿窗口的包的數據，這種發送突發
大量包的問題可以被基于速率的方法(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,andSACKTCP,ComputerCommunicationReview,
V.26N.3,July1996,pp.5-21.URL
"http://www.aciri.org/floyd/papers.html".

[HPF99]MarkHandley,JitendraPadhye,SallyFloyd,TCPCongestion
WindowValidation,UMassCMPSCITechnicalReport99-77,
September1999.URL"ftp://www-
net.cs.umass.edu/pub/Handley99-tcpq-tr-99-77.ps.gz".

[HTH98]AmyHughes,JoeTouch,JohnHeidemann,"IssuesinTCP
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",ATMForum
DocumentNumber:ATMForum/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-HalvingAlgorithmforTCPCongestionControl,
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/".

[RFC2581]Allman,M.,Paxson,V.andW.Stevens,TCPCongestion
Control,RFC2581,April1999.

[VH97]VikramVisweswaraiahandJohnHeidemann.ImprovingRestart
ofIdleTCPConnections,TechnicalReport97-661,
UniversityofSouthernCalifornia,November,1997.

[Dummynet]LuigiRizzo,"DummynetandForwardErrorCorrection",
Freenix98,June1998,NewOrleans.URL
"http://info.iet.unipi.it/~luigi/ip_dummynet/".
8安全性考慮
通常有關TCP擁塞控制的安全性考慮在RFC2581中討論。本文描述了那些擁塞控制過程的
一個方面的一種算法。因此，在RFC2581中討論的安全性考慮也適合本算法，對于本算法
還沒有其他的安全性問題。
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
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,
INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

致謝

FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.