組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：mailto:ouyang@china-pub.com
譯者：（）
譯文發布時間：2001-11-4
版權：本中文翻譯文檔版權歸中國互動出版網所有?？梢杂糜诜巧虡I用途自由轉載，但必須
保留本文檔的翻譯及版權信息。




Network Working Group                                            S. Floyd
Request for Comments: 2582                                          ACIRI
Category: Experimental                                         T. Henderson
                                                           U.C. Berkeley
April 1999


TCP快速恢復算法NewReno修正
（RFC2582——The NewReno Modification to TCP's Fast Recovery Algorithm）

本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準” (STD1)來獲得本協議的標準化
程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright (C) The Internet Society (2001).
摘要： 
RFC 2001 [RFC2001]講述了以下四種相互作用的TCP擁塞控制算法：慢啟動，擁塞避免，
快速重傳，以及快速恢復。RFC 2581 [RFC2581]明確地允許對這些算法進行某些改動，包括
如下改動，使用TCP選擇確認（SACK）選項[MMFR96],以及在沒有SACK的情況下響應“部分
確認”(在檢測到數據丟失時，新數據的ACKs，而不是發送的所有數據的ACKs)。這篇文檔
描述了響應部分確認的一個特定算法，稱為NewReno。對部分確認的響應由Janey Hoe在
[Hoe95]中首次提出。


                             目錄
1.介紹	2
2.定義	2
3.NewReno中的快速重傳和快速恢復算法	2
4.重設重傳定時器	4
5.避免多次快速重傳	4
6.數據接收端的實現問題	5
8.總結	6
9.致謝	6
10.參考文獻	6
11.安全考慮	7
12.作者地址	7
13.完全版權說明	8

1.介紹
對[RFC2581]（在1990年的BSD Reno發行版中首次實現，在[FF96]稱之為Reno算法）
中描述的TCP快速恢復算法的典型實現，TCP數據發送端在發生一個超時重傳時僅僅重傳一
個數據包，或者當三個重復確認到達時觸發快速重傳算法。單單一個超時重傳可能導致許多
數據包的重傳，但是每次Reno快速重傳算法的啟用僅僅導致一個數據包的重傳。
因此，當多個數據包從一個數據窗口中丟失并且觸發快速重傳和快速恢復算法時，問題
就會產生。在這種情況下，如果SACK選項可用，TCP發送端在快速恢復期間就有足夠的信
息來決定重傳哪個數據包，不重傳哪個數據包。這篇文檔僅對不能使用TCP選擇確認（SACK）
選項的TCP連接適用。
在沒有SACK的情況下，TCP發送端在快速恢復期間只能得到很少的信息來作出重傳決
定。從三個重復確認中，發送端推斷出一個數據包丟失了，并且重傳那個聲明了數據包。在
這之后，數據發送端可能接收到另外的重復確認，因為在發送端進入快速重傳時，數據端確
認已經發送的附加數據包。
在多個數據包從一個數據窗口中丟失這種情況下，當發送端從對重傳的數據包（就是第
一次進入快速重傳時重傳的數據包）的一個確認時，它獲得第一條可用新信息。如果只有一
個數據包丟失了，對這個重傳的數據包的確認將確認所有進入快速重傳（在沒有重新排序的
情況下）之前發送的數據包。但是，當有多個數據包丟失時，對此重傳數據包的確認將僅確
認一些而不是所有在快速重傳之前發送的數據包。我們稱這個包是一個部分確認。
和許多其它的建議一起，[Hoe95]建議在快速恢復期間TCP數據發送端通過推斷聲明的
數據包已經丟失和重傳那個數據包的方式響應一個部分確認。這篇文檔描述了對Reno TCP
里的快速恢復算法的一個修正，Reno TCP包括了快速恢復期間對接收到的部分確認的一個
響應。我們稱這處修正過的快速恢復算法為NewReno，因為它與基礎的Reno算法有一些細
小但是很重要的不同。這篇文檔沒有討論[Hoe95]和[Hoe96]中的其它建議，比如在慢啟動期
間ssthresh參數的一個變化，及在快速恢復期間為每兩個重復確認發送一個新數據包的建
議。這篇文檔里的NewReno方案也使用了文獻[LM97]中的NewReno的討論。
    我們沒有說對于不能使用SACK的TCP，這里描述的快速恢復的NewReno方案是響
應部分確認的一個可選修正。根據我們在NS模擬器上的NewReno修正經驗，我們相信這個
修正在很多地方都改善了快速重傳和快速恢復的性能，我們僅僅是為了IETF團體的利益而
將它文檔化。我們鼓勵使用對快速恢復的這一修正，并且我們還鼓勵反饋關于此修正或相關
修正的操作經驗。
2.定義
這篇文檔假設讀者熟悉[RFC2581]中定義的術語：最大段尺寸(MSS), 擁塞窗口(cwnd),
和傳送尺寸（FlightSize）。傳送尺寸在[RFC2581] 中是如下定義的：
傳送尺寸：已經發送但還沒有確認的數據量。
3.NewReno中的快速重傳和快速恢復算法
標準的快速重傳和快速恢復算法實現在[RFC2581]給出。這些算法的NewReno修正在下
面給出。NewReno修正[RFC2581]里的實現的不同僅在于步驟1中的變量“recover”的引入，
以及步驟5中對一個部分或新的確認的響應。修正定義了一個“快速恢復過程”，它在接收
到三個重復ACK時開始，并在一個超時重傳發生或一個確認所有在快速恢復過程開始后發送
的數據的ACK到達時結束。
1.當收到第三個重復ACK并且發送端還沒有處于快速恢復過程時，設置ssthresh不大
于下面等式1中給出的值。（這是[RFC2581]中的等式3）。
ssthresh = max (FlightSize / 2, 2*MSS)           (1)
用變量“recover”記錄傳送的最大序列號。
2.重傳丟失的段并設置cwnd為ssthresh乘以3*MSS。這將人為地按已經離開網絡的報
文段數目（3）和接收端緩沖數據量來擴充擁塞窗口。
3.對每個接收到的額外的重復ACK，將cwnd增大SMSS字節。這將人為地擴充擁塞窗口
以反映已經離開網絡的附加數據段。
4.發送一個數據段，如果cwnd和接收端的通知窗口的值允許的話。
5.當一個確認新數據的ACK到達時，此ACK可能是由步驟2中的重傳引發的確認，或者
是由稍后的一次重傳引起的。
  如果這個ACK確認了直到并包含“recover”的數據，那么這個ACK確認了所有在丟
失段的原始傳送和第三個重復ACK接收之間的段。設置cwnd為（1）
min(ssthresh,FlightSize+MSS)；或者(2)ssthresh,這里的ssthresh是步驟1中設置的值；
這稱為“deflating”窗口。（我們注意到步驟1中“FlightSize”指的是當進入快速恢復時
步驟1中發送的數據量，步驟5中的“FlightSize”指的是當退出快速恢復時發送的數據量。）
如果選擇了另一個選項，實現應該采取措施避免可能的數據爆發，萬一向網絡中發送的數據
量遠小于新擁塞窗口允許的量[HTH98]的話。退出快速恢復過程。
如果這個ACK不確認所有并包含到“recover”的數據的話，就產生一個部分ACK。在
此種情況下，重傳第一個沒有確認的數據段。按確認的新數據量來減小擁塞窗口，然后加回
一個MSS并發送一個新數據段，如果cwnd的新值允許的話。這個“部分窗口縮減”試圖確
定這一點，當快速恢復最終結束時，大約ssthresh數量的數據還在向網絡中傳送。不要退
出快速恢復過程（也就是說，如果任何重復ACK隨后到達，執行上面的步驟3和4）。
對在快速恢復期間第一個到達的部分ACK，也要重設重傳定時器。
注意到在步驟5中，擁塞窗口在一個部分確認收到時減小。擁塞窗口在部分確認收到時
可能已經大幅膨脹。另外，根據丟失數據包的類型，部分確認可能確認將近一個窗口的數據。
在這種情況下，如果擁塞窗口沒有減小，數據端可能能夠緊接著發送將近一個窗口的數據。
上面描述的對部分確認的簡單響應可能有許多變形。首先，一個問題是部分確認之后何
時重設定時器。這在下面的第4節進一步討論。
一個相關的問題是在每一個部分確認之后，重傳多少數據包。上面描述的算法在每個部
分確認之后重傳一個數據包。這是最保守的選擇，因為這種辦法最沒有可能導致一個沒有必
要重傳的數據包。有效地慢啟動也是一個變形，它能從丟失了許多數據包的窗口中更快地恢
復過來，但是要求從丟失了N個數據包 [Hoe96]的恢復必須少于N來回時間。對部分確認采
用這種稍微激烈一點的響應的話，在每個重傳之后重設重傳定時器就會很有利。因為我們還
沒有在我們的模擬器上試驗這種變形，我們在這篇文檔中不會進一步對此進行討論。
第三個問題是避免由接收端已經到的數據包的重傳引起的多次快速重傳。這在下面的第
5節中討論。避免多次快速重傳在對部分確認采用更激烈的響應的情況下特別重要，因為在
這種情況下，發送端更可能重傳接收端已經接收的數據包。
最后，我們考察一下沒有SACK選項的情況，數據發送端在沒有足夠信息的情況下工作。
一個發送端可能花很長時間仔細考慮在這種情況哪個快速恢復的變形對這種環境是最優的。
因為從丟失了多個數據包的一個窗口中恢復的問題特別重要，所以最好的選擇是使用SACK
選項。
4.重設重傳定時器
第3節的算法僅在第一個部分ACK之后重設重傳定時器。在這種情況下，如果很多數據
包從一個窗口中丟失了，TCP數據發送端的重傳定時器最終將超時，接著TCP數據發送端將
調用慢啟動。（這在[F98]在12頁中被例證。）我們稱此為NewReno的Impatient變形。
相反地，[FF96]中的NewReno模擬例證了上面描述的算法，不同的是重傳定時器在每個
部分確認之后都要重設。我們稱此為Slow-but-Steady變形。在這種情況下，對于一個丟失
了大量數據包的窗口來說，TCP數據發送端每個來回時間至少發送一個數據包。（這種行為
在[FF96]中的NewReno TCP模擬和[F98]的11頁中被例證。）
對于超時重傳值（RTO）一般不大于往返時間（RTT）的TCP實現來說，Impatient變形
即使在只有少量數據包丟失的情況下也會導致一個超時重傳。對于超時重傳值（RTO）一般
遠大于往返時間(RTT)的TCP實現來說，Slow-but-Steady變形當多個數據包從一個窗口中
丟失時能夠長時間維持快速恢復。這些變形沒有一個是最優的；一個更優的算法可能是某個
從多個數據包丟失中迅速恢復，并且在重設重傳定時器時與Slow-but-Steady進行混合的算
法。然而我們注意到，在沒有SACK選項的情況下，對潛在性能有個限制。
5.避免多次快速重傳 
    在沒有SACK選項時，一個重復確認沒有攜帶任何有關信息，這種信息是用來確定TCP
數據接收端觸發重復確認的一個或多個數據包的。TCP數據發送端不能把區分重復確認是由
數據包丟失或延時引起的，還是由發送端重傳了一個TCP接收端已經接收到的數據包引起
的。由于這個原因，一個窗口的多個數據段丟失某些時候能導致不必要的多次重傳（以及擁
塞窗口的多次縮減）[Flo94]。
    在Reno或NewReno TCP中使用了快速重傳和快速恢復算法的話，由多次快速重傳引起
的性能問題就相對小一些（和Tahoe TCP的潛在問題相比，它沒有實現快速恢復）。然而，
Reno或NewReno TCP也會發生不必要的快速重傳，特別是如果快速恢復期間發生了一個重
傳超時的話。（這在［F98］第6頁中作為Reno的例證，第8頁中作為NewReno的例證。）有
NewReno的話，數據發送端一直處于快速恢復，直到發生一個超時重傳，或者快速重傳時發
送的所有數據都已得到確認。因此有了NewReno，多次快速重傳的問題只有在一個超時重傳