Network Working Group S. Floyd
Request for Comments: 5033 M. Allman
BCP: 133 ICIR / ICSI
Category: Best Current Practice August 2007
Network Working Group S. Floyd
Request for Comments: 5033 M. Allman
BCP: 133 ICIR / ICSI
Category: Best Current Practice August 2007
Specifying New Congestion Control Algorithms
指定新的拥塞控制算法
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF.
IETF的标准拥塞控制方案已被广泛证明不适用于各种环境（例如，高速网络）。最近的研究产生了许多不同于IETF拥塞控制原则的替代拥塞控制方案。在全球互联网上使用这些新的拥塞控制方案可能会对使用新的拥塞控制的流量和使用当前标准化的拥塞控制的流量产生影响。因此，IETF在处理备用拥塞控制方案时必须谨慎行事。本文件的目的是为考虑IETF内的备用拥塞控制算法提供指导。
This document provides guidelines for the IETF to use when evaluating suggested congestion control algorithms that significantly differ from the general congestion control principles outlined in [RFC2914]. The guidance is intended to be useful to authors proposing alternate congestion control and for the IETF community when evaluating whether a proposal is appropriate for publication in the RFC series.
本文件提供了IETF在评估建议的拥塞控制算法时使用的指南，这些算法与[RFC2914]中概述的一般拥塞控制原则存在显著差异。本指南旨在帮助提出替代拥塞控制的作者和IETF社区评估提案是否适合在RFC系列中发布。
The guidelines in this document are intended to be consistent with the congestion control principles from [RFC2914] of preventing congestion collapse, considering fairness, and optimizing the flow's own performance in terms of throughput, delay, and loss. [RFC2914] also discusses the goal of avoiding a congestion control "arms race" among competing transport protocols.
本文件中的指南旨在与[RFC2914]中的拥塞控制原则保持一致，即防止拥塞崩溃，考虑公平性，并在吞吐量、延迟和损失方面优化流自身的性能。[RFC2914]还讨论了避免竞争传输协议之间的拥塞控制“军备竞赛”的目标。
This document does not give hard-and-fast requirements for an appropriate congestion control scheme. Rather, the document provides a set of criteria that should be considered and weighed by the IETF in the context of each proposal. The high-order criteria for any new proposal is that a serious scientific study of the pros and cons of the proposal needs to have been done such that the IETF has a well-rounded set of information to consider.
本文件并未对适当的拥塞控制方案提出严格要求。相反，该文件提供了一套标准，IETF应在每个提案的上下文中考虑和权衡这些标准。任何新提案的高标准是需要认真研究科学提案的利弊，以便IETF有一个全面的信息来考虑。
After initial studies, we encourage authors to write a specification of their proposals for publication in the RFC series to allow others to concretely understand and investigate the wealth of proposals in this space.
在初步研究之后，我们鼓励作者编写一份RFC系列出版物的提案规范，以使其他人能够具体了解和调查该领域提案的丰富内容。
Following the lead of HighSpeed TCP [RFC3649], alternate congestion control algorithms are expected to be published as "Experimental" RFCs until such time that the community better understands the solution space. Traditionally, the meaning of "Experimental" status has varied in its use and interpretation. As part of this document we define two classes of congestion control proposals that can be published with the "Experimental" status. The first class includes algorithms that are judged to be safe to deploy for best-effort traffic in the global Internet and further investigated in that environment. The second class includes algorithms that, while promising, are not deemed safe enough for widespread deployment as best-effort traffic on the Internet, but are being specified to facilitate investigations in simulation, testbeds, or controlled environments. The second class can also include algorithms where the IETF does not yet have sufficient understanding to decide if the algorithm is or is not safe for deployment on the Internet.
在高速TCP[RFC3649]的引领下，预计替代拥塞控制算法将作为“实验性”RFC发布，直到社区更好地理解解决方案空间。传统上，“实验”状态的含义在使用和解释上有所不同。作为本文档的一部分，我们定义了两类可以以“实验”状态发布的拥塞控制方案。第一类包括被认为是安全的算法，可以在全球互联网上部署尽最大努力的流量，并在该环境中进行进一步研究。第二类包括一些算法，这些算法虽然很有前途，但被认为不足以作为尽力而为的流量在互联网上广泛部署，但被指定用于促进模拟、试验台或受控环境中的调查。第二类还可以包括IETF尚未充分理解的算法，以确定该算法在互联网上部署是否安全。
Each alternate congestion control algorithm published is required to include a statement in the abstract indicating whether or not the proposal is considered safe for use on the Internet. Each alternate congestion control algorithm published is also required to include a statement in the abstract describing environments where the protocol is not recommended for deployment. There may be environments where the protocol is deemed *safe* for use, but still is not *recommended* for use because it does not perform well for the user.
发布的每个备用拥塞控制算法都需要在摘要中包含一个声明，表明该提案是否被认为是安全的，可以在互联网上使用。发布的每个备用拥塞控制算法还需要在摘要中包含一条语句，描述不建议部署该协议的环境。在某些环境中，协议被视为“安全”使用，但仍然不“推荐”使用，因为它对用户的性能不好。
As examples of such statements, [RFC3649] specifying HighSpeed TCP includes a statement in the abstract stating that the proposal is Experimental, but may be deployed in the current Internet. In contrast, the Quick-Start document [RFC4782] includes a paragraph in the abstract stating the mechanism is only being proposed for controlled environments. The abstract specifies environments where the Quick-Start request could give false positives (and therefore would be unsafe to deploy). The abstract also specifies environments where packets containing the Quick-Start request could be dropped in the network; in such an environment, Quick-Start would not be unsafe to deploy, but deployment would still not be recommended because it could cause unnecessary delays for the connections attempting to use Quick-Start.
作为此类声明的示例，指定高速TCP的[RFC3649]在摘要中包含一条声明，说明该提案是试验性的，但可能部署在当前的互联网上。相比之下，快速启动文件[RFC4782]在摘要中包含一段，说明该机制仅针对受控环境提出。摘要指定了快速启动请求可能出现误报（因此部署起来不安全）的环境。摘要还规定了包含快速启动请求的数据包可以在网络中丢弃的环境；在这样的环境中，快速启动部署不会不安全，但仍不建议部署，因为它可能会导致尝试使用快速启动的连接出现不必要的延迟。
For authors of alternate congestion control schemes who are not ready to bring their congestion control mechanisms to the IETF for standardization (either as Experimental or as Proposed Standard), one possibility would be to submit an internet-draft that documents the alternate congestion control mechanism for the benefit of the IETF and IRTF communities. This is particularly encouraged in order to get algorithm specifications widely disseminated to facilitate further research. Such an internet-draft could be submitted to be considered as an Informational RFC, as a first step in the process towards standardization. Such a document would also be expected to carry an explicit warning against using the scheme in the global Internet.
对于未准备好将其拥塞控制机制提交IETF进行标准化（无论是作为实验标准还是建议标准）的备用拥塞控制方案的作者，一种可能是提交一份互联网草案，记录IETF和IRTF社区的备用拥塞控制机制。特别鼓励这样做，以便广泛传播算法规范，以便于进一步研究。这种互联网草案可以作为信息RFC提交，作为标准化进程的第一步。这样一份文件还将明确警告不要在全球互联网上使用该计划。
Note: we are not changing the RFC publication process for non-IETF produced documents (e.g., those from the IRTF or Independent Submissions via the RFC-Editor). However, we would hope the guidelines in this document inform the IESG as they consider whether to add a note to such documents.
注：对于非IETF生成的文件（例如，来自IRTF的文件或通过RFC编辑器提交的独立文件），我们不会更改RFC发布流程。然而，我们希望这份文件中的指导方针告知IESG，因为他们考虑是否向这些文件添加注释。
As noted above, authors are expected to do a well-rounded evaluation of the pros and cons of proposals brought to the IETF. The following are guidelines to help authors and the IETF community. Concerns that
如上所述，作者应全面评估提交给IETF的提案的利弊。以下是帮助作者和IETF社区的指南。担心
fall outside the scope of these guidelines are certainly possible; these guidelines should not be considered as an all-encompassing check-list.
不属于这些准则的范围当然是可能的；这些准则不应被视为一份包罗万象的检查表。
(0) Differences with Congestion Control Principles [RFC2914]
(0) 与拥塞控制原则的差异[RFC2914]
Proposed congestion control mechanisms should include a clear explanation of the deviations from [RFC2914].
提议的拥塞控制机制应包括对[RFC2914]偏差的明确解释。
(1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].
(1) 对标准TCP、SCTP[RFC2960]和DCCP[RFC4340]的影响。
Proposed congestion control mechanisms should be evaluated when competing with standard IETF congestion control [RFC2581, RFC2960, RFC4340]. Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism.
在与标准IETF拥塞控制[RFC2581、RFC2960、RFC4340]竞争时，应评估提议的拥塞控制机制。可能会怀疑使用标准拥塞控制对交通产生重大负面影响的备用拥塞控制器，这一方面应成为社区关于备用拥塞控制机制适用性的决策的一部分。
We note that this bullet is not a requirement for strict TCP-friendliness as a prerequisite for an alternate congestion control mechanism to advance to Experimental. As an example, HighSpeed TCP is a congestion control mechanism that is Experimental, but that is not TCP-friendly in all environments. We also note that this guideline does not constrain the fairness offered for non-best-effort traffic.
我们注意到，这个项目并不是严格的TCP友好性的要求，它不是替代拥塞控制机制进入实验阶段的先决条件。例如，高速TCP是一种实验性的拥塞控制机制，但并非在所有环境中都对TCP友好。我们还注意到，该指南并不限制为非尽力而为流量提供的公平性。
As an example from an Experimental RFC, fairness with standard TCP is discussed in Sections 4 and 6 of [RFC3649] (HighSpeed TCP) and using spare capacity is discussed in Sections 6, 11.1, and 12 of [RFC3649].
作为实验性RFC的一个示例，[RFC3649]（高速TCP）的第4节和第6节讨论了标准TCP的公平性，而[RFC3649]的第6节、第11.1节和第12节讨论了使用备用容量。
(2) Difficult Environments.
(2) 困难的环境。
The proposed algorithms should be assessed in difficult environments such as paths containing wireless links. Characteristics of wireless environments are discussed in [RFC3819] and in Section 16 of [Tools]. Other difficult environments can include those with multipath routing within a connection. We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments. For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like. A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments.
建议的算法应该在困难的环境中进行评估，例如包含无线链路的路径。[RFC3819]和[Tools]第16节讨论了无线环境的特征。其他困难的环境可能包括连接中具有多路径路由的环境。我们注意到，在某些困难的环境中，TCP的性能仍有许多需要改进的地方。对于具有来自路由器的显式反馈的拥塞控制机制，困难环境可以包括在第二层具有非IP队列的路径、IP隧道等。为在Internet上广泛部署而提出的实验机制的最低目标应该是，在这些环境中，它们的性能不会明显低于TCP。
While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with paths with long delays [RFC2488], high delay bandwidth products [RFC3649], high packet corruption rates [RFC3155], packet reordering [RFC4653], and significantly slow links [RFC3150]. Aspects of alternate congestion control that impact networks with these characteristics should be detailed.
虽然不可能列举所有可能的“困难环境”，但我们注意到，IETF之前曾处理过长延迟[RFC2488]、高延迟带宽积[RFC3649]、高数据包损坏率[RFC3155]、数据包重新排序[RFC4653]和显著慢链路[RFC3150]的路径。应详细说明影响具有这些特征的网络的备用拥塞控制方面。
As an example from an Experimental RFC, performance in difficult environments is discussed in Sections 6, 9.2, and 10.2 of [RFC4782] (Quick-Start).
[RFC4782]（快速入门）的第6、9.2和10.2节讨论了在困难环境中的性能，作为实验RFC的一个示例。
(3) Investigating a Range of Environments.
(3) 调查一系列环境。
Similar to the last criteria, proposed alternate congestion controllers should be assessed in a range of environments. For instance, proposals should be investigated across a range of bandwidths, round-trip times, levels of traffic on the reverse path, and levels of statistical multiplexing at the congested link. Similarly, proposals should be investigated for robust performance with different queueing mechanisms in the routers, especially Random Early Detection (RED) [FJ03] and Drop-Tail. This evaluation is often not included in the internet-draft itself, but in related papers cited in the draft.
与上一个标准类似，建议的备用拥塞控制器应在一系列环境中进行评估。例如，应跨一系列带宽、往返时间、反向路径上的流量级别以及拥塞链路上的统计多路复用级别对提案进行调查。同样，应该研究路由器中不同排队机制的鲁棒性能，特别是随机早期检测（RED）[FJ03]和掉尾。这一评价通常不包括在互联网草案本身中，而是包括在草案中引用的相关论文中。
A particularly important aspect of evaluating a proposal for standardization is in understanding where the algorithm breaks down. Therefore, particular attention should be paid to characterizing the areas where the proposed mechanism does not perform well.
评估标准化提案的一个特别重要的方面是理解算法在哪里出现故障。因此，应特别注意说明拟议机制执行情况不佳的领域。
As an example from an Experimental RFC, performance in a range of environments is discussed in Section 12 of [RFC3649] (HighSpeed TCP) and Section 9.7 of [RFC4782] (Quick-Start).
[RFC3649]（高速TCP）第12节和[RFC4782]（快速启动）第9.7节讨论了实验性RFC在各种环境中的性能。
(4) Protection Against Congestion Collapse.
(4) 防止阻塞崩溃。
The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold [RFC3714], or should include some notion of "full backoff". For "full backoff", at some point the algorithm would reduce the sending rate to one packet per round-trip time and then exponentially backoff the time between single packet transmissions if congestion persists. Exactly when either "full backoff" or a pause in sending comes into play will be algorithm-specific. However, as discussed in [RFC2914], this requirement is crucial to protect the network in times of extreme congestion.
备用拥塞控制机制应在数据包丢弃率超过某个阈值时停止发送[RFC3714]，或应包括一些“完全退避”的概念。对于“完全退避”，在某一点上，该算法会将发送速率降低到每往返时间一个数据包，然后在拥塞持续的情况下以指数方式退避单数据包传输之间的时间。“完全退避”或暂停发送的确切时间取决于算法。然而，如[RFC2914]中所述，这一要求对于在极度拥塞时保护网络至关重要。
If "full backoff" is used, this bullet does not require that the full backoff mechanism must be identical to that of TCP [RFC2988]. As an example, this bullet does not preclude full backoff mechanisms that would give flows with different round-trip times comparable bandwidth during backoff.
如果使用“完全回退”，则此项目符号不要求完全回退机制必须与TCP相同[RFC2988]。例如，此项目符号并不排除完全回退机制，该机制将在回退期间提供具有不同往返时间的流，并提供可比较的带宽。
(5) Fairness within the Alternate Congestion Control Algorithm.
(5) 备用拥塞控制算法中的公平性。
In environments with multiple competing flows all using the same alternate congestion control algorithm, the proposal should explore how bandwidth is shared among the competing flows.
在多个竞争流都使用相同的备用拥塞控制算法的环境中，提案应探讨如何在竞争流之间共享带宽。
(6) Performance with Misbehaving Nodes and Outside Attackers.
(6) 行为异常的节点和外部攻击者的性能。
The proposal should explore how the alternate congestion control mechanism performs with misbehaving senders, receivers, or routers. In addition, the proposal should explore how the alternate congestion control mechanism performs with outside attackers. This can be particularly important for congestion control mechanisms that involve explicit feedback from routers along the path.
该提案应探讨备用拥塞控制机制如何处理行为不端的发送方、接收方或路由器。此外，提案还应探讨备用拥塞控制机制如何与外部攻击者协作。这对于包含路由器沿路径的显式反馈的拥塞控制机制尤为重要。
As an example from an Experimental RFC, performance with misbehaving nodes and outside attackers is discussed in Sections 9.4, 9.5, and 9.6 of [RFC4782] (Quick-Start). This includes discussion of misbehaving senders and receivers; collusion between misbehaving routers; misbehaving middleboxes; and the potential use of Quick-Start to attack routers or to tie up available Quick-Start bandwidth.
[RFC4782]（快速入门）第9.4、9.5和9.6节讨论了作为实验性RFC的一个示例，行为不端的节点和外部攻击者的性能。这包括对行为不端的发送者和接收者的讨论；行为不端的路由器之间的串通；行为不端的中间人；以及快速启动攻击路由器或占用可用快速启动带宽的潜在用途。
(7) Responses to Sudden or Transient Events.
(7) 对突发或短暂事件的反应。
The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as sudden congestion, a routing change, or a mobility event. Routing changes, link disconnections, intermittent link connectivity, and mobility are discussed in more detail in Section 17 of [Tools].
建议应考虑备用拥塞控制机制如何在瞬态事件如突发拥塞、路由改变或移动性事件的存在下执行。[工具]第17节详细讨论了路由更改、链路断开、间歇性链路连接和移动性。
As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of [RFC4782] (Quick-Start).
作为实验RFC的一个示例，[RFC4782]（快速启动）的第9.2节讨论了瞬态事件的响应。
(8) Incremental Deployment.
(8) 增量部署。
The proposal should discuss whether the alternate congestion control mechanism allows for incremental deployment in the targeted environment. For a mechanism targeted for deployment in the current Internet, it would be helpful for the proposal to
提案应讨论备用拥塞控制机制是否允许在目标环境中进行增量部署。对于在当前互联网上部署的机制，建议
discuss what is known (if anything) about the correct operation of the mechanism with some of the equipment installed in the current Internet, e.g., routers, transparent proxies, WAN optimizers, intrusion detection systems, home routers, and the like.
讨论当前Internet中安装的一些设备（例如路由器、透明代理、WAN优化器、入侵检测系统、家庭路由器等）的机制正确运行的已知信息（如果有的话）。
As a similar concern, if the alternate congestion control mechanism is intended only for specific environments (and not the global Internet), the proposal should consider how this intention is to be carried out. The community will have to address the question of whether the scope can be enforced by simply stating the restrictions or whether additional protocol mechanisms are required to enforce the scoping. The answer will necessarily depend on the change being proposed.
作为类似的担忧，如果备用拥塞控制机制仅针对特定环境（而不是全球互联网），建议应考虑如何执行该意图。社区必须解决的问题是，是否可以通过简单说明限制来实施范围，或者是否需要额外的协议机制来实施范围界定。答案必然取决于提议的变更。
As an example from an Experimental RFC, deployment issues are discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start).
作为一个实验性RFC的示例，部署问题在[RFC4782]（快速启动）的第10.3节和第10.4节中进行了讨论。
This section suggests minimum requirements for a document to be approved as Experimental with approval for widespread deployment in the global Internet.
本节提出了在全球互联网上广泛部署的试验性批准文件的最低要求。
The minimum requirements for approval for widespread deployment in the global Internet include the following guidelines on: (1) assessing the impact on standard congestion control, (3) investigation of the proposed mechanism in a range of environments, (4) protection against congestion collapse, and (8) discussing whether the mechanism allows for incremental deployment.
批准在全球互联网上广泛部署的最低要求包括以下准则：（1）评估对标准拥塞控制的影响，（3）在一系列环境中调查拟议机制，（4）防止拥塞崩溃，以及（8）讨论该机制是否允许增量部署。
For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet.
对于其他指南，即（2）、（5）、（6）和（7），作者必须执行建议的评估并提供建议的分析。在批准在全球互联网上广泛部署时，有证据表明提议的机制比TCP的问题多得多，这应该引起关注。
This document does not represent a change to any aspect of the TCP/IP protocol suite and therefore does not directly impact Internet security. The implementation of various facets of the Internet's current congestion control algorithms do have security implications (e.g., as outlined in [RFC2581]). Alternate congestion control schemes should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise.
本文档不代表对TCP/IP协议套件的任何方面的更改，因此不会直接影响Internet安全。互联网当前拥塞控制算法的各个方面的实现确实具有安全含义（如[RFC2581]中所述）。备用拥塞控制方案也应注意此类陷阱，并应检查可能出现的任何潜在安全问题。
Discussions with Lars Eggert and Aaron Falk seeded this document. Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, Colin Perkins, Pekka Savola, members of TSVWG, and participants at the TCP Workshop at Microsoft Research for feedback and contributions. This document also draws from [Metrics].
与Lars Eggert和Aaron Falk的讨论是这份文件的种子。感谢Bob Briscoe、Gorry Fairhurst、Doug Leith、Jitendra Padhye、Colin Perkins、Pekka Savola、TSVWG的成员以及Microsoft Research TCP研讨会的参与者的反馈和贡献。本文件还引用了[Metrics]。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[FJ03] Floyd, S., and Jacobson, V., Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993.
[FJ03]Floyd，S.和Jacobson，V.，《避免拥塞的随机早期检测网关》，IEEE/ACM网络事务，第1卷第4期，1993年8月。
[Metrics] S. Floyd, Metrics for the Evaluation of Congestion Control Mechanisms, Work in Progress, July 2007.
[Metrics]S.Floyd，《拥塞控制机制评估指标》，进展中，2007年7月。
[RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[RFC2488]Allman，M.，Glover，D.，和L.Sanchez，“使用标准机制增强卫星信道上的TCP”，BCP 28，RFC 2488，1999年1月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150]Dawkins，S.，黑山，G.，Kojo，M.，和V.Magret，“慢链路的端到端性能影响”，BCP 48，RFC 3150，2001年7月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3155]Dawkins，S.，黑山，G.，Kojo，M.，Magret，V.，和N.Vaidya，“带错误链接的端到端性能影响”，BCP 50，RFC 3155，2001年8月。
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, December 2003.
[RFC3649]Floyd，S.，“用于大拥塞窗口的高速TCP”，RFC 3649，2003年12月。
[RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]Floyd，S.和J.Kempf，“IAB对互联网语音流量拥塞控制的关注”，RFC 3714，2004年3月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC4653] Bhandarkar, S., Reddy, A. N., Allman, M., and E. Blanton, "Improving the Robustness of TCP to Non-Congestion Events", RFC 4653, August 2006.
[RFC4653]Bhandarkar，S.，Reddy，A.N.，Allman，M.，和E.Blanton，“提高TCP对非拥塞事件的鲁棒性”，RFC 46532006年8月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782]Floyd，S.，Allman，M.，Jain，A.，和P.Sarolahti，“TCP和IP的快速启动”，RFC 4782，2007年1月。
[Tools] S. Floyd and E. Kohler, Tools for the Evaluation of Simulation and Testbed Scenarios, Work in Progress, July 2007.
[工具]S.Floyd和E.Kohler，《模拟和试验台场景评估工具》，进展中的工作，2007年7月。
Authors' Addresses
作者地址
Sally Floyd
ICIR (ICSI Center for Internet Research)
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Sally Floyd
ICIR (ICSI Center for Internet Research)
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
URL: http://www.icir.org/floyd/
Mark Allman
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: (440) 235-1792
EMail: mallman@icir.org
URL: http://www.icir.org/mallman/
Mark Allman
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704-1198
Phone: (440) 235-1792
EMail: mallman@icir.org
URL: http://www.icir.org/mallman/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.