后才發生。
    接下來對第3節中算法的修正消除了多次快速重傳的問題。（這個修正在[F98]中稱為
“bugfix”，在第7和第9頁中說明。）這個修正使用了一個新變量“send_high”，它的初始
值是最初發送的序列號。每次超時重傳之后，到目前為止發送的最大序列號記錄到
“send_high”變量中。
    如果在一個超時重傳之后，TCP數據發送端重傳了三個連續的數據包，而這此數據包數
據接收端已經接收到了，這樣的話TCP數據發送端就將接收到三個重復確認，這此確認并沒
有確認“send_high”號數據包。在這種情況下，重復確認并不能表明又發生了擁塞。它們
只是表明發送端沒有必要地重傳了至少三個數據包。
    我們注意到如果如果TCP數據發送端接收到三個重復確認，而這些重復確認并沒有確認
“send_high”號數據包，這樣發送端就不知道這此重復確認是否是由一個新數據包的丟失
引起的。對一個實現了這節描述的用來避免多次快速重傳的bugfix的TCP而言，發送端在
這些情況下并不會由重復確認推斷出一個數據包丟失了。和往常一樣，重傳定時器在這種情
況又成了推斷數據包丟失的支持機制。
    為避免多次快速重傳而對快速重傳作的修正用下面的步驟1A代了第3節中的步驟1。
另外，此修正增加了下面的步驟6：
1A.當接收到第三個重復ACK并且發送端還沒有進入快速恢復過程時，檢查并且看看這
些重復ACK有沒有確認“send_high”號數據包。如果有,設置ssthresh的值不大于等式1
中給出的值,在變量"recover"中記錄發送的最大序列號,然后轉到步驟2.如果重復ACK沒
有確認"send_high"號數據包,就什么也不做。也就是不要進入快速重傳和快速恢復過程,
不要改變ssthresh值,不要轉到步驟2以重傳"丟失的"數據段,并且不要在下一個重復ACK
到之前不要執行步驟3。
步驟2-5和第三節的步驟一樣。
6.一個超時重傳之后,在變量"send_high"中記錄發送的最大序列號,并退出快速恢復
過程,如果可以的話。
上面的1A步驟中檢查重復ACK是否確認"send_high"以后的數據包,這是對此算法的
careful變形。另一個可能的改變會是簡單地要求三個重復確認在開始另一個快速重傳之前
確認"send_high"號數據包。我們稱之為對快速重傳的less careful變形。
在兩種個別情況下,TCP發送端能接收到確認"send_high"號數據包的重復確認,但對
大于"send_high"號的數據包不確認。一種情況是數據發送端發送了四個序列號大于
"send_high"的數據包,第一個數據包丟失在網絡中,接下來的三個數據包觸發了三個重復
確認,這些確認確認了"send_high"號數據包。第二種情況是發送端不必要地重傳了三個序
列號小于"send_high"的數據包,并且這三個數據包觸發了三個確認了"send_high"號數
據包的重復確認。在沒有SACK選項的情況下,TCP發送端不能區分這兩種情況。
對快速重傳的Careful變形而言,數據發送端在第一種情況下必須等待一個超時重傳,
但在第二種情況下不會產生不必要的快速重傳。對快速重傳的less Careful變形而言,數據
發送端會按第一種情況的需要快速重傳,并且在第二種情況下會不必要地快速重傳。NS模擬
器已經實現了NewReno的Less Careful變形,Sun的Solaris 7上的TCP實現實現了Careful
變形.這篇文檔推薦上面的1A步驟給出的Careful變形。
6.數據接收端的實現問題
[RFC2001]闡述說“次序混亂的數據段應該迅速確認，以觸發快速重傳算法。” Neal 
Cardwell已經指出，一些數據接收端在發送一個部分確認時不迅速發送一個確認，而是首
先等待它們的延遲確認定時器超時[C98]。正如[C98]指出的，這嚴重限制了來自NewReno的
效益，因為它延遲了數據發送端部分確認的接收。我們的建議是，數據接收端為一個次序混
亂的數據段迅速發送一個確認，即使當次序混亂的段在緩沖區中時也一樣。
7.模擬
有NewReno的模擬在NS模擬器上用用效性測試"tcl/test/test-all-newreno"來例
證。命令“../../ns test-suite-newreno.tcl reno”顯示了Reno TCP的一個模擬，例證
了數據發送端缺乏對一個部分確認的響應。相反地，命令“../../ns test-suite-newreno.tcl 
newreno_B”顯示了這篇文檔描述的使用NewReno算法的相同情境的模擬。
測試“../../ns test-suite-newreno.tcl newreno1_B0”和“../../ns 
test-suite-newreno.tcl newreno1_B”分別顯示了NewReno的Slow-but-Steady變形和
Impatient變形。
8.總結
我們的建議是TCP實現包括第3節給的快速恢復算法的NewReno修正，以及第5節給的
用來避免多次快速重傳的修正。第3節給的NewReno修正即使對支持SACK選項的TCP實現
也是很重要的，因為SACK選項只有當兩個TCP結點都支持SACK選項時才能使用。第3節給
的NewReno修正實現了NewReno的Impatient而不是Slow-but-Steady修正。
盡管這篇文檔提到了許多NewReno算法的可能的變化，但是我們沒有對所有這些可能的
變化進行探討，所以不能提出和其中一些有關的建議。我們相信，任何兩個NewReno變形之
間的不同比Reno和NewReno之間的不同要小。也就是說，重要的是實現NewReno而不是Reno，
對一個沒有SACK的TCP調用來說，具體NewReno的哪個變形被實現并不重要。
9.致謝
感謝Anil Agarwal, Mark Allman, Vern Paxson, Kacheong Poon,和 Bernie Volz關于
這篇文檔的細致的反饋。
10.參考文獻
    [C98]         Neal Cardwell, "delayed ACKs for retransmitted packets:
                 ouch!". November 1998.  Email to the tcpimpl mailing
                 list, Message-ID "Pine.LNX.4.02A.9811021421340.26785-
              100000@sake.cs.washington.edu", archived at
                 "http://tcp-impl.lerc.nasa.gov/tcp-impl".
   [F98]         Sally Floyd.  Revisions to RFC 2001.  Presentation to
                 the TCPIMPL Working Group, August 1998.  URLs
                 "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" and
                 "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf".
   [FF96]        Kevin Fall and Sally Floyd.  Simulation-based
                 Comparisons of Tahoe, Reno and SACK TCP.  Computer
                 Communication Review, July 1996.  URL
                 "ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".

   [Flo94]       S. Floyd, TCP and Successive Fast Retransmits.
                 Technical report, October 1994.  URL
                 "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".
   [Hen98]       Tom Henderson, Re: NewReno and the 2001 Revision.

                 September 1998.  Email to the tcpimpl mailing list,
                 Message ID "Pine.BSI.3.95.980923224136.26134A-
                 100000@raptor.CS.Berkeley.EDU", archived at
                 "http://tcp-impl.lerc.nasa.gov/tcp-impl".
   [Hoe95]       J. Hoe, Startup Dynamics of TCP's Congestion Control
                 and Avoidance Schemes. Master's Thesis, MIT, 1995.  URL
                 "http://ana-www.lcs.mit.edu/anaweb/ps-papers/hoe-
                 thesis.ps".
   [Hoe96]       J. Hoe, "Improving the Start-up Behavior of a
                 Congestion Control Scheme for TCP",  In ACM SIGCOMM,
                 August 1996.  URL
                 "http://www.acm.org/sigcomm/sigcomm96/program.html".
   [HTH98]       Hughes, A., Touch, J.  and J. Heidemann, "Issues in TCP
                 Slow-Start Restart After Idle", Work in Progress, March
                 1998.
   [LM97]        Dong Lin and Robert Morris, "Dynamics of Random Early
                 Detection", SIGCOMM 97, September 1997.  URL
                 "http://www.acm.org/sigcomm/sigcomm97/program.html".
   [MMFR96]      Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
                 Selective Acknowledgement Options", RFC 2018, October
                 1996.
   [NS]          The UCB/LBNL/VINT Network Simulator (NS). URL
                 "http://www-mash.cs.berkeley.edu/ns/".
   [RFC2001]     Stevens, W., "TCP Slow Start, Congestion Avoidance,
                 Fast Retransmit, and Fast Recovery Algorithms", RFC
                 2001, January 1997.
   [RFC2581]     Stevens, W., Allman, M. and V. Paxson, "TCP Congestion
                 Control", RFC 2581, April 1999.
11.安全考慮
    RFC2581討論了有關TCP擁塞控制的一般安全考慮。這篇文檔描述了一個特殊算法，它
符合RFC2581的擁塞控制要求，因此那些考慮也適用此算法。已知的還沒有其它關于這個特
殊算法的安全考慮。
12.作者地址
Sally Floyd
   AT&T Center for Internet Research at ICSI (ACIRI)
   Phone: +1 (510) 642-4274 x189
   EMail: floyd@acm.org
   URL:  http://www.aciri.org/floyd/
   Tom Henderson
   University of California at Berkeley
   Phone: +1 (510) 642-8919
   EMail: tomh@cs.berkeley.edu
   URL: http://www.cs.berkeley.edu/~tomh/
13.完全版權說明
    Copyright (C) The Internet Society (1999).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC2582-The NewReno Modification to TCP's Fast Recovery Algorithm  TCP快速恢復算法NewReno修正


1
RFC文檔中文翻譯計劃