rfc2582.txt

RFC规范的翻译稿

后才发生。
    接下来对第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-
              [e-mail]", 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-
                 [e-mail]", 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: [phone] x189
   EMail: [e-mail]
   URL:  http://www.aciri.org/floyd/
   Tom Henderson
   University of California at Berkeley
   Phone: [phone]
   EMail: [e-mail]
   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文档中文翻译计划