本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化程
度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2001).
摘要：
這篇文檔定義了TCP的四種相互交織的擁塞控制算法：慢啟動、擁塞避免、快速重傳、
以及快速恢復。文檔也講述了在一數據段相當長的閑置之后，TCP應該如何開始傳送，并討
論了各種確認產生方法。
目錄
1.介紹 2
2．定義 2
3．擁塞控制算法 3
3．1慢啟動和擁塞避免 3
3．2快速重傳/快速恢復 4
4．附加考慮 5
4．1閑置后重啟連接 5
4．2確認生成 5
4．3丟失恢復機制 6
5.安全考慮 6
6．相對于RFC2001的變化 7
感謝 7
參考文獻： 7
作者地址： 9

1.介紹
這篇文檔講述了四種TCP擁塞控制算法：慢啟動、擁塞避免、快速重傳和快速恢復。這
些算法是在[Jac88]和[Jac90]中被設計出來的。它們在TCP中的使用在[Bra89]中被標準化。
這篇文檔是對[Ste97]的更新。除了講述擁塞控制算法外，這篇文檔也講述了在相當長的
閑置期后TCP連接應該做些什么，講述并澄清了關于產生TCPACK的一些問題。
[Ste94]提供了實際使用的這些算法的例子，[WS95]解釋了這些算法的BSD實現的源代
碼。
這篇文檔組織結構如下。第二節提供了文檔中要使用的各種定義。第三節講述了擁塞控
制算法。第四節概括了和擁塞控制算法相關的問題，最后，第五節概括了安全方面的考慮。
要害字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD","SHOULD
NOT","RECOMMENDED","MAY"及"OPTIONAL"在這篇文檔里面的含義同[Bra97]里描述的一樣。
2．定義
這一節提供了此文檔其余節要使用的一些術語的定義。
數據段：一個數據段就是任意的TCP/ip數據或確認包（或兩者兼備）。
發送端最大數據段尺寸（SMSS）:SMSS是發送端能發送的最大數據段的尺寸。這個值是
以網絡最大傳送單元（MTU），MTU路徑發現算法，RMSS(見下一項)，或其它因素為基礎的。
該尺寸不包括TCP/IP頭和選項。
接收端最大數據段尺寸（RMSS）:RMSS是接收端愿意接收的最大數據段的尺寸。這個值
在連接開始時接收端發送的MSS選項中說明。又或者，假如MSS選項沒有使用，就是536字
節[Bra89].該尺寸不包括TCP/IP頭和選項。
滿尺寸數據段：一個包括答應最大數目數據的數據段（也就是說，一個包括SMSS字節數
據的數據段）。
接收端窗口（rwnd）：最近通知的接收端窗口。
擁塞窗口（cwnd）：一個TCP狀態參量，代表著一個TCP答應發送的最大數據量。在任意
一個給定的時刻，TCP不會發送序號大于最大確認序號和cwnd、rwnd中較小者的數據。
初始窗口（iw）：初始窗口是三次握手完成后發送端的擁塞窗口的尺寸。
丟失窗口（lw）：丟失窗口是在一個TCP根據它的重傳定時器檢測到了數據丟失之后，擁
塞窗口的尺寸。
重啟窗口（rw）：重啟窗口是TCP在一段閑置期之后重新開始傳送后擁塞窗口的尺寸（如
果使用慢啟動算法；參見4.1節以獲取更多的討論）。
傳送尺寸：已經被發送但還沒有確認的數據的總量。
3．擁塞控制算法
這節定義了四種擁塞控制算法：慢啟動，擁塞避免，快速重傳和快速恢復，它們在[Jac88]
和[Jac90]中被提出。在某些情況下，比算法的限定更加保守地行事也許對一個TCP發送端更
有益，無論如何，TCP不能超出下列算法的限定（也就是說，當下列算法計算出來的cwnd值
不答應數據被發送時，就不能發送數據）。
3．1慢啟動和擁塞避免
　　慢啟動和擁塞避免算法必須被TCP發送端用來控制正在向網絡輸送的數據量。為了
實現這些算法，必須向TCP每連接狀態加入兩個參量。擁塞窗口（cwnd）是對發送端收到確
認（ACK）之前能向網絡傳送的最大數據量的一個發送端限制，接收端通知窗口（rwnd）是對
未完成數據量的接收端限制。Cwnd和rwnd的最小值決定了數據傳送。
　　另一個狀態參量，慢啟動閥值（ssthresh），被用來確定是用慢啟動還是用擁塞避免
算法來控制數據傳送，討論如下：
　　在不清楚環境的情況下向網絡傳送數據，要求TCP緩慢地探測網絡以確定可用流量，
以避免忽然傳送大量數據而使網絡擁塞。在傳送開始時，或者在修復了由重發定時器探測到
的數據丟失之后使用慢啟動算法來達到此目的。
　　IW，cwnd的初始值，必須小于或等于2*SMSS字節而且不能大于兩個數據段。
　　我們注重到一個非標準的，實驗性的TCP的擴充答應TCP使用一個更大的初始窗口
（IW），在等式1中給予定義[AFP98]：
　　　IW=min(4*SMSS,max(2*SMSS,4380bytes))(1)
　　有了這個擴充，TCP發送端可以使用一個3或4數據段的初始窗口，只要這些數據
段的總尺寸不超過4380字節。我們沒有將這一改變作為這篇文檔定義的標準的一部分。但是，
我們在這篇文檔的剩余部分包含了對（1）的討論，將它作為那些實驗的指導方針，而不是遵
守目前的TCP擁塞控制標準。
　　Ssthresh的初始值可以任意大（比如，一些實現使用通知窗口的尺寸），但是作為
對擁塞的響應，其大小可能會被減小。慢啟動算法在cwnd<ssthresh時使用，擁塞避免算法
在cwnd>ssthresh時使用。當cwnd和ssthresh相等時，發送端既可以使用慢啟動也可以使
用擁塞避免。
　　在慢啟動期間，一個TCP的cwnd對每一個接收到的用于確認新數據的ACK至多增加
SMSS字節。當cwnd超過ssthresh（或者，當cwnd大小達到ssthresh的大小，如上所述）
或者當觀察到擁塞時慢啟動結束。
　　在擁塞避免期間，cwnd以每個往返（RTT）1滿尺寸數據段的速度遞增。擁塞避免繼
續保持直到擁塞被檢測到。等式2給出了一個普通使用的在擁塞避免期間用來修正cwnd值的
公式
　　　　　　　　cwnd+=SMSS*SMSS/cwnd(2)
　　此修正被實行于每個新到的非重復ACK。等式（2）為cwnd以每個往返（RTT）1滿
尺寸數據段的速度遞增的潛在原則提供了一個可接受的近似值。（注重，假如連接的接收端對
每一個數據段都要確認，（2）被證實了比每RTT一數據段更有冒險，對每隔一個包進行一次
確認的接收端來說，（2）冒的險更少一些。
　　實現說明：因為整數式經常用于TCP實現，等式2中給出的公式在擁塞窗口非常大
時也許不能夠增加cwnd值。假如上述公式結果為0，結果應被設成1字節。
　　實現說明：早期的實現在等式（2）的右邊有一個另外的附加值。這是不合理的，在
實際中能導致性能降低[PAD+98]。
　　另一種在擁塞避免期間增加cwnd值的可接受的方法是計算由ACK確認的數據的字節
數（這種實現的一個缺點是它要求維持一個另外的狀態參量）。當確認的數據的字節數達到
cwnd值，cwnd值能被增加到SMSS字節。注重到在擁塞避免期間，cwnd每次的增加量既不能
大于每RTT一滿尺寸數據段，也不能大于等式2計算的值。
　　實現說明：一些實現以字節為單位維持cwnd，另外一些實現以滿尺寸數據段為單位。
后者很難使用等式（2），因此可能會選擇上一段討論的計算方法。
　　當一個TCP用重傳定時器檢測到數據段丟失時，ssthresh的值必須設定大于等式（3）
中給出的值：
　　ssthresh=max(FlightSize/2,2*SMSS)(3)
　　正如上面所討論的，FlightSize是仍在網絡中傳送的數據量。
　　實現說明：一個輕易犯的錯誤是一味地使用cwnd而不使用FlightSize，FlightSize
在一些實現里可能比rwnd增長得更快。
此外，一旦超時，cwnd值必須設定不大于丟失窗口尺寸，LW，它和一個滿尺寸數據
段的大小相等（不管IW的值）。因此，在重發丟失數據段之后，TCP發送端使用慢啟動算法將
窗口尺寸從一個滿尺寸數據段增加到ssthresh的新值，此時擁塞避免再次發揮決定作用。
3．2快速重傳/快速恢復
當一個次序紊亂的數據段到達時TCP接受端應該迅速發送一個重復ACK。這個ACK
的目的是通知發送端收到了一個次序紊亂的數據段，以及期望的序列號。從發送端的觀點來
看，重復ACK可以由許多網絡問題引起。首先，可以由數據段丟失引起。在這種情況下，所
有在丟失的數據段之后發送的數據段都將觸發重復ACK。第二，可以由網絡對數據的重新排序
引起（這在某些網絡路徑上并不少見[Pax97]）。最后，重復ACK可以由網絡對ACK或數據數
據段的復制引起。另外，當接收數據段填補了全部或部分序列號間隔時，TCP接收端應該立即
發送一個ACK。這將為一個通過重傳超時機制來從數據丟失中恢復的發送端提供更多的及時的
信息，此機制可能是一個快速重傳，或者一個實驗性的數據丟失恢復算法，比如
NewReno[FH98]。
TCP發送端應該使用“快速重傳”算法來探測或者修復數據丟失，以收到的重復ACK
為基礎?？焖僦貍魉惴ㄒ匀齻€重復ACK的到達（收到四個一樣的ACK，其間沒有任何其他包到
達）為一個數據段已經丟失的標志。在收到三個重復ACK之后，TCP不等重傳定時器超時就重
傳看來已經丟失的數據段。
在快速重傳算法發送了看來已經丟失的數據段之后，“快速恢復”算法支配了新數據
的傳送，直到一個非重復ACK到達。不進行慢啟動的原因是收到重復ACK不僅意味著一個數
據段已經丟失，而且意味著數據段非常可能從網絡丟失（盡管網絡產生大量的重復數據段可
以保證不丟失）。換句話說，因為接收端只有在當一個數據段已經到達時才產生一個重復ACK，
由此我們可以知道，已經脫離網絡，存儲在接收端的緩沖區里的數據段不會再消耗網絡資源。
另外，因為ACK"clock"保存起來了，TCP發送端可以繼續發送新的數據段（盡管傳送必須
繼續使用一個減小的cwnd）。
　　　　快速傳送和快速恢復算法經常像下面那樣一起實現。
1． 當第三個重復ACK收到時，設置ssthresh不大于等式3給定的值。
2． 重傳丟失的數據段并設置cwnd的值為ssthresh乘以3*SMSS。這將人為地按已經離開網
絡的報文段數目（3）和接收端緩沖數據量來擴充擁塞窗口。
3． 對每個接收到的附加的重復ACK，將cwnd增大SMSS字節。這將人為地擴充擁塞窗口以反
映已經離開網絡的附加數據段。
4． 發送一個數據段，假如cwnd和接收端的通知窗口的值答應的話。
5． 當下一個確認新數據的ACK到達時，設定cwnd值為ssthresh（步驟1設置的值）。這稱
作“deflating"窗口。這個ACK必須是步驟1觸發的重發引起的確認，重發之后一個RTT
（在接收端有了次序紊亂的數據段的情況下，它可能一會兒就到達）。
另外，此ACK應該確認丟失數據段和第三個ACK副本期間的數據段，假如它們一個也沒
有丟失的話。
注重：當包的一個傳送期間就有很多丟失時，這個算法不能夠有效地恢復[FF96]。為解
決這個問題而提出的一系列修正可以在[FH98]中找到。
4．附加考慮
4．1閑置后重啟連接
上面描述的TCP擁塞控制算法有一個眾所周知的問題，就是TCP閑置了相當長一段時間
后，上述算法答應潛在的大量數據爆發性地傳送。在一段閑置期之后，TCP不能使用ACK　時
鐘過濾新進入網絡的數據段，因為所有的ACK都已經從網絡中丟失。因此，正如上面所述，
在一段閑置期之后TCP可能暗地里發送大量的cwnd尺寸的數據到網絡。
[Jac88]推薦TCP在一段相當長的閑置期之后使用慢啟動來重新開始傳輸。慢啟動負責重
啟ACK時鐘，正如它在傳輸開始時所做的那樣。這種機制廣泛地通過下面的方式來使用。當
TCP在長于一個超時重傳時間里沒有收到一個數據段，cwnd就在傳輸之前被減小為重啟窗口
（RW）的值。為了實現這個標準，我們定義RW=IW。
我們注重到非標準的實驗性的TCP擴充在[AFP98]定義RW=min(IW,cwnd)，其中IW的定
義經過等式（1）調整過。使用最后一次收到數據段的時間來決定是否減小cwnd不能夠在常
見的HTTP永久連接情況下縮減cwnd[HTH98]。在這種情況下，WWW服務器在傳輸數據到WWW
瀏覽器之前接收一個請求。這個請求的接收導致一個對閑置連接的測試失敗，并且答應TCP
使用可能的不恰當大的cwnd開始傳輸。
因此，假如TCP在超過超時重傳的時間里沒有發送數據的話，TCP應該在開始傳輸之前
設置cwnd小于RW。
4．2確認生成
TCP接收端應該使用[Bra89]中描述的ACK延遲算法。使用時，TCP接收端不能過分延遲
確認?？梢悦鞔_的是，至少應該每隔一個滿尺寸數據段生成一個ACK，而且應該在第一個沒有
確認的包到達后500毫秒內生成。
ACK“應該”每隔一個滿尺寸數據段生成一個的要求在[Bra89]的一個地方顯示為“應該”，
另一個地方為“必須”。這里我們明確地說它是“應該”。我們也強調這是一個“應該”，它意
味著一個實現在仔細考慮了它的含意之后可以而且只能“偏離”此要求。參見[PAD+98]里的
“StretchACKviolation”和那里對比每隔一個滿尺寸數據段更頻繁生成ACK可能帶來的性
能問題的討論。
在某些情況下，發送端和接收端可能對一個滿尺寸數據段的組成沒有達成一致意見。如
果一個實現每從發送端接收到2*RMSS字節數據就發送至少一個確認的話，那么此實現就被認
為符合要求（達成一致意見），RMSS是接收端向發送端指定的最大數據段尺寸（據[Bra89]，
假如接收端沒有在連接期間指定一個MSS選項，就是默認的536字節）。發送端可能被迫使用
尺寸小于RMSS的數據段，由于最大傳輸單元（MTU），MTU路徑發現算法或其它因素的緣故。
比如，考慮如下情況：接收端通知RMSS為X字節，但是發送端因為MTU路徑發現算法（或者
發送端的MTU尺寸）而以一個尺寸為Y字節的數據段結束。在一個ACK發送之前假如接收端
等待2*X字節到達，那么它將生成擴展ACK。很明顯這將占據多于兩個的尺寸大于Y字節的數
據段。因此，當一個特定的算法沒有定義時，接收端最好是試著阻止這種情況，比如通過至
少每隔一個數據段進行確認，不管尺寸。最后，我們重申，ACK不能被延遲長于500毫秒來等
待另一個滿尺寸數據段到來。
序號混亂的數據段應該立即被確認，這樣可以加速數據丟失恢復。為了觸發快速重傳算
法，接收端應該在接收到序號間隔上的一個數據數據段時迅速發送一個ACK副本。為了向發
送端反饋丟失恢復的信息，接收端應該在接收到填補部分或全部序號間隔的數據數據段時迅
速發送一個ACK。
TCP接收端不應該為每個到來的數據段產生多于一個的ACK，otherthantoupdatethe
offeredwindowasthereceivingapplicationconsumesnewdata[page
42,Pos81][cla82].
4．3丟失恢復機制
TCP研究人員已經提出了許多丟失恢復算法，這些算法擴充了快速重傳和快速恢復算法。
其中一些算法以TCP的選擇性確認選項為基礎[MMFR96],比如[FF96,MM96a,MM96b],其它的不
要求SACKs[Hoe96,FF96,FH98]。不使用SACK的算法使用“部分確認”（當檢測到丟失時僅對
包含新數據的數據段進行ACK確認，而不是所有傳輸中的數據）來觸發重傳。盡管這篇文檔
沒有標準化任何可能改進快速重傳/快速恢復的特定算法，但是這些算法暗地里是答應的，只
要它們遵守上面概括的基本的四個算法的一般原則。
因此，當數據窗口首次被檢測到丟失時，ssthresh必須被設定為不大于等式（3）中給
出的值。其次，直到數據窗口中所有可疑的丟失數據段都被修復為止，每個RTT中傳送的數
據段數量在檢測到丟失時不能大于未傳送的數據段的數目的一半。最后，當給定的窗口中的
所有丟失數據段都被重傳后，cwnd必須設定不大于ssthresh，并且必須使用擁塞避免來進一
步增大cwnd。兩個連續的數據窗口的丟失，或者重傳的丟失，應該被視為擁塞的標志，在這
種情況下，cwnd（以及ssthresh）必須減小兩倍。
[Hoe96,FF96,MM96a,MM6b]里概括的算法遵循這篇文檔里概括的四個基本擁塞控制算法
的原則。
5.安全考慮
這篇文檔要求TCP在出現超時重傳和確認副本的情況下減小它的發送速率。因此攻擊者能
夠通過引起數據包或者它們的確認丟失的方式來削減TCP連接的性能，也可以通過偽造額
外的確認副本來達到此目的。接連引起兩個擁塞控制事件經常使ssthresh減小到它的最
小值2*SMSS，并使連接迅速進入低速運行的擁塞避免狀態。
Internet很大程度上依靠于這些算法的正確實現來保持網絡的穩定、避免擁塞崩潰。攻
擊者能夠通過偽造額外的重復確認或對新數據的額外確認的方式來使TCP端點對擁塞作
出更激烈的反應。這樣的攻擊甚至可以使網絡的一部分陷入擁塞崩潰。
6．相對于RFC2001的變化
　這篇文檔已經詳盡地重寫了，逐條列出兩篇文檔之間的不同是不現實的。這篇文檔的目
的不是為了改變RFC2001中給出的建議，而是為了進一步闡明在2001中沒有具體討論其
細節的情況。非凡是，這篇文檔對長時間閑置后TCP連接應該如何動作提出了建議，同時
也闡明了一些屬于TCPACK生成范疇的問題。最后，初始擁塞窗口的答應上界從一個數據
段增大到兩個數據段。
感謝
這里描述的四個算法是由VanJacobson提出的。
這篇文檔的一些文字摘自W.RichardStevens的"TCP/IPIllustrated,Volume1:The
“TCP/IPIllustrated,Volume2:TheImplementation”(Addison-Wesley,1995)。這
些材料的使用得到了Addison-Wesley的答應。
NealCardwell,SallyFloyd,CraigPartridge和JoeToUCh提供了許多有價值的建議。
參考文獻：
[AFP98]Allman,M.,Floyd,S.andC.Partridge,"IncreasingTCP's
InitialWindowSize,RFC2414,September1998.

[Bra89]Braden,R.,"RequirementsforInternetHosts--
CommunicationLayers",STD3,RFC1122,October1989.

[Bra97]Bradner,S.,"KeyWordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.

[Cla82]Clark,D.,"WindowandAcknowledgmentStrategyinTCP",RFC
813,July1982.

[FF96]Fall,K.andS.Floyd,"Simulation-basedComparisonsof
Tahoe,RenoandSACKTCP",ComputerCommunicationReview,
July1996.FTP://ftp.ee.lbl.gov/papers/sacks.ps.Z.

[FH98]Floyd,S.andT.Henderson,"TheNewRenoModificationto
TCP'sFastRecoveryAlgorithm",RFC2582,April1999.

[Flo94]Floyd,S.,"TCPandSuccessiveFastRetransmits.Technical
report",October1994.
ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.

[Hoe96]Hoe,J.,"ImprovingtheStart-upBehaviorofaCongestion
ControlSchemeforTCP",InACMSIGCOMM,August1996.

[HTH98]Hughes,A.,Touch,J.andJ.Heidemann,"IssuesinTCP
Slow-StartRestartAfterIdle",WorkinProgress.

[Jac88]Jacobson,V.,"CongestionAvoidanceandControl",Computer
CommunicationReview,vol.18,no.4,pp.314-329,Aug.
1988.ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

[Jac90]Jacobson,V.,"ModifiedTCPCongestionAvoidanceAlgorithm",
end2end-interestmailinglist,April30,1990.
ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.

[MD90]Mogul,J.andS.Deering,"PathMTUDiscovery",RFC1191,
November1990.

[MM96a]Mathis,M.andJ.Mahdavi,"ForwardAcknowledgment:Refining
TCPCongestionControl",ProceedingsofSIGCOMM'96,August,
1996,Stanford,CA.Available
fromhttp://www.psc.edu/networking/papers/papers.Html

[MM96b]Mathis,M.andJ.Mahdavi,"TCPRate-HalvingwithBounding
Parameters",Technicalreport.Availablefrom
http://www.psc.edu/networking/papers/FACKnotes/current.

[MMFR96]Mathis,M.,Mahdavi,J.,Floyd,S.andA.Romanow,"TCP
SelectiveAcknowledgementOptions",RFC2018,October1996.

[PAD+98]Paxson,V.,Allman,M.,Dawson,S.,Fenner,W.,Griner,J.,
Heavens,I.,Lahey,K.,Semke,J.andB.Volz,"KnownTCP
ImplementationProblems",RFC2525,March1999.

[Pax97]Paxson,V.,"End-to-EndInternetPacketDynamics",

ProceedingsofSIGCOMM'97,Cannes,France,Sep.1997.

[Pos81]Postel,J.,"TransmissionControlProtocol",STD7,RFC793,
September1981.

[Ste94]Stevens,W.,"TCP/IPIllustrated,Volume1:TheProtocols",
Addison-Wesley,1994.

[Ste97]Stevens,W.,"TCPSlowStart,CongestionAvoidance,Fast
Retransmit,andFastRecoveryAlgorithms",RFC2001,January
1997.

[WS95]Wright,G.andW.Stevens,"TCP/IPIllustrated,Volume2:
TheImplementation",Addison-Wesley,1995.
作者地址：
MarkAllman
NASAGlennResearchCenter/SterlingSoftware
LewisField
21000BrookparkRd.MS54-2
Cleveland,OH44135
216-433-6586

EMail:mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman


VernPaxson
ACIRI/ICSI
1947CenterStreet
Suite600
Berkeley,CA94704-1198

Phone:+1510/642-4274x302
EMail:vern@aciri.org


W.RichardStevens
1202E.PaSEOdelZorro
Tucson,AZ85718
520-297-9416

EMail:rstevens@kohala.com
http://www.kohala.com/~rstevens

FullCopyrightStatement

Copyright(C)TheInternetSociety(1999).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.