Internet Research Task Force (IRTF) M. Welzl
Request for Comments: 5783 University of Oslo
Category: Informational W. Eddy
ISSN: 2070-1721 MTI Systems
February 2010
Internet Research Task Force (IRTF) M. Welzl
Request for Comments: 5783 University of Oslo
Category: Informational W. Eddy
ISSN: 2070-1721 MTI Systems
February 2010
Congestion Control in the RFC Series
RFC系列中的拥塞控制
Abstract
摘要
This document is an informational snapshot taken by the IRTF's Internet Congestion Control Research Group (ICCRG) in October 2008. It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards.
本文档是IRTF的互联网拥塞控制研究小组（ICCRG）于2008年10月拍摄的信息快照。它提供了对RFC系列中文档描述的拥塞控制主题的调查。这不会修改或更新所讨论的RFC文档的规范或状态。它可以作为研究小组未来工作的参考或起点，特别是在注意当前IETF标准中的差距或开放问题时。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Internet Congestion Control Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。该RFC代表了互联网研究工作组（IRTF）互联网拥塞控制研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5783.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5783.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architectural Documents . . . . . . . . . . . . . . . . . . . 5
3. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 9
4. Challenging Link and Path Characteristics . . . . . . . . . . 10
5. End-Host and Router Cooperative Signaling . . . . . . . . . . 12
5.1. Explicit Congestion Notification . . . . . . . . . . . . . 13
5.2. Quick-Start . . . . . . . . . . . . . . . . . . . . . . . 15
6. Non-TCP Unicast Congestion Control . . . . . . . . . . . . . . 15
7. Multicast Congestion Control . . . . . . . . . . . . . . . . . 18
8. Guidance for Developing and Analyzing Congestion Control
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Historic Interest . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architectural Documents . . . . . . . . . . . . . . . . . . . 5
3. TCP Congestion Control . . . . . . . . . . . . . . . . . . . . 9
4. Challenging Link and Path Characteristics . . . . . . . . . . 10
5. End-Host and Router Cooperative Signaling . . . . . . . . . . 12
5.1. Explicit Congestion Notification . . . . . . . . . . . . . 13
5.2. Quick-Start . . . . . . . . . . . . . . . . . . . . . . . 15
6. Non-TCP Unicast Congestion Control . . . . . . . . . . . . . . 15
7. Multicast Congestion Control . . . . . . . . . . . . . . . . . 18
8. Guidance for Developing and Analyzing Congestion Control
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Historic Interest . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
12. Informative References . . . . . . . . . . . . . . . . . . . . 22
In this document, we define congestion control as the feedback-based adjustment of the rate at which data is sent into the network. Congestion control is an indispensable set of principles and mechanisms for maintaining the stability of the Internet. Congestion control has been closely associated with TCP since 1988 [Jac88], but there has also been a great deal of congestion control work outside of TCP (e.g., for real-time multimedia applications, multicast, and router-based mechanisms). Several such proposals have been produced within the IETF and published as RFCs, along with RFCs that give architectural guidance (e.g., by pointing out the importance of performing some form of congestion control). Several of these mechanisms are in use within the Internet.
在本文中，我们将拥塞控制定义为基于反馈的数据发送到网络的速率调整。拥塞控制是维护互联网稳定必不可少的一套原则和机制。自1988年以来，拥塞控制一直与TCP密切相关[Jac88]，但在TCP之外也有大量的拥塞控制工作（例如，实时多媒体应用、多播和基于路由器的机制）。IETF中已经提出了一些这样的建议，并作为RFC发布，同时RFC也提供了架构指导（例如，通过指出执行某种形式的拥塞控制的重要性）。其中一些机制在互联网中使用。
When designing a new Internet transport protocol, it is therefore important to not only understand how congestion control works in TCP but also have a broader understanding of the other congestion control RFCs -- some give guidance, some of them describe mechanisms that may have a direct influence on a newly designed protocol, and some of them may only be "related work" worth knowing about. The purpose of this document is to facilitate and encourage this search for knowledge by providing an overview of RFCs related to congestion control that have been published thus far. This document is a product of the IRTF's Internet Congestion Control Research Group (ICCRG). It was developed because a strong grasp of the existing literature should benefit further ICCRG work. The ICCRG developed consensus on the content of this document during a two-year development period based on review comments and ICCRG mailing list discussions. A list of the main review contributors is contained in the Acknowledgements section of this document.
因此，在设计新的Internet传输协议时，不仅要了解拥塞控制在TCP中的工作原理，而且要更广泛地了解其他拥塞控制RFC——有些提供指导，有些描述可能对新设计的协议产生直接影响的机制，其中一些可能只是值得了解的“相关工作”。本文件的目的是通过提供到目前为止已发布的与拥塞控制相关的RFC概述，促进和鼓励对知识的搜索。本文件是IRTF的互联网拥塞控制研究小组（ICCRG）的产品。它的发展是因为对现有文献的深刻理解将有助于ICCRG的进一步工作。ICCRG根据审查意见和ICCRG邮件列表讨论，在两年的发展期内就本文件的内容达成共识。主要审查贡献者的列表包含在本文件的确认部分。
While the ICCRG agreed to the document's production, any opinions expressed are the authors' own, and as this document is not an IETF publication, it does not update or modify the status of any published RFCs. The format of this document is similar to an annotated bibliography. Although host and router requirements for congestion control functions are discussed, this is only an informational document and does not contain any formal standards bearing of its own.
尽管ICCRG同意该文件的编制，但所表达的任何意见均为作者自己的意见，并且由于本文件不是IETF出版物，因此不会更新或修改任何已发布RFC的状态。本文件的格式类似于带注释的参考书目。虽然讨论了拥塞控制功能的主机和路由器要求，但这只是一个信息性文档，不包含任何正式的标准。
Congestion control is a large and active topic, and so the scope of this document is limited to published RFCs and a small number of current working group drafts. This allows the document to focus on congestion control principles and mechanisms that are among the most well-supported, well-accepted, or widely used. Significant contributions to this subject also exist in both the academic literature and in the form of Internet-Drafts; however, we exclude
拥塞控制是一个庞大而活跃的主题，因此本文档的范围仅限于已发布的RFC和少量当前工作组草案。这使得本文档能够重点关注最受支持、最被广泛接受或使用的拥塞控制原则和机制。在学术文献和互联网草稿中，对这一主题也有重大贡献；但是，我们排除
these from this study. In many cases the RFC describing some mechanism will contain references to relevant academic publications in journals or conference proceedings that presented the research and validation of the mechanism. For instance, RFC 2581 cites Jacobson's 1988 SIGCOMM paper that has a less standards-oriented but more illustrative treatment and explanation of some of the mechanisms in RFC 2581.
这些都来自本研究。在许多情况下，描述某种机制的RFC将包含对介绍该机制研究和验证的期刊或会议记录中相关学术出版物的引用。例如，RFC 2581引用了雅各布森1988年的SIGCOMM论文，该论文对RFC 2581中的一些机制进行了较少的标准化处理和解释，但更具说明性。
The majority of the documents discussed here pertain to end-host-based congestion control. Many network-based mechanisms, such as a number of queue management algorithms, do not require any protocol exchanges between elements, but merely operate within a single host or router. Thus, network-based congestion control mechanisms have often not been described in any RFC, as they generally fall under the domain of implementation details that do not influence interoperability.
这里讨论的大多数文档都与基于终端主机的拥塞控制有关。许多基于网络的机制，例如许多队列管理算法，不需要在元素之间进行任何协议交换，而仅在单个主机或路由器内运行。因此，基于网络的拥塞控制机制通常未在任何RFC中描述，因为它们通常属于不影响互操作性的实现细节领域。
There are many RFCs related to Quality of Service (QoS), especially within the Integrated Services and Differentiated Services frameworks [RFC1633] [RFC2475] [RFC2998]. These QoS RFCs themselves deserve a similar bibliography to the one that this document provides for congestion control. We specifically do not include the vast amount of QoS work into the scope of this document, as it is a full field in its own right, and deals with issues that are mostly orthogonal to end-host congestion control and router queue management. Although there can certainly be interactions between QoS and congestion control mechanisms, scheduling mechanisms used to implement QoS (on either a per-flow or an aggregate basis), for instance, can be used independently of the end-host congestion control and queue management functions also in use. Similar arguments can be made for traffic-shaping, admission control, and other functions that are intended for QoS and are only side-notes for congestion control.
有许多与服务质量（QoS）相关的RFC，特别是在集成服务和差异化服务框架[RFC1633][RFC2475][RFC2998]中。这些QoS RFC本身应该有一个与本文档提供的拥塞控制类似的参考书目。我们特别不将大量的QoS工作包括在本文档的范围内，因为它本身是一个完整的领域，处理的问题主要与终端主机拥塞控制和路由器队列管理正交。尽管QoS和拥塞控制机制之间肯定存在交互作用，但用于实现QoS的调度机制（例如，在每个流或聚合的基础上）可以独立于也在使用的终端主机拥塞控制和队列管理功能而使用。对于流量整形、接纳控制和其他旨在实现QoS的功能，也可以提出类似的论点，这些功能只是拥塞控制的旁注。
A similar argument can be made for excluding consideration of the media access control (MAC) layer protocols used by the links throughout a path. Although the MAC protocols implement various forms of resolving contention for shared links (and sometimes offer QoS services), these are also distinct from end-to-end congestion control. Furthermore, MAC protocols are not typically discussed in the RFC series, but they are defined in outside documents (e.g., IEEE standards), since the IETF does not generally work on link layers themselves. Few, if any, of the RFCs that describe mappings of IP onto various link layers directly discuss congestion control.
可以进行类似的论证，以排除对链路在整个路径中使用的媒体访问控制（MAC）层协议的考虑。尽管MAC协议实现了各种形式的解决共享链路的争用（有时提供QoS服务），但它们也不同于端到端拥塞控制。此外，MAC协议通常不在RFC系列中讨论，但它们在外部文档（例如IEEE标准）中定义，因为IETF通常不在链路层上工作。很少有（如果有的话）RFC描述IP到不同链路层的映射，直接讨论拥塞控制。
To organize the subject matter in this document, the content is classified into several broad categories. First, we list documents relating to Internet architecture and general architectural concepts in Section 2. Next, the congestion control algorithms used in the
为了组织本文件中的主题，将内容分为几个大类。首先，我们在第2节列出了与Internet架构和一般架构概念相关的文档。接下来，介绍了网络中使用的拥塞控制算法
TCP transport protocol are discussed in Section 3. Interactions between link properties and mechanisms with the kinds of algorithms and heuristics used within end-to-end congestion control are covered in Section 4. One method that has been developed by the IETF (and deployed to some extent) for allowing network-based and host-based congestion control to interact without dropping packets is the subject of Section 5.1. The congestion control algorithms used by unicast transport protocols other than TCP are described in Section 6. Work on congestion control for multicast transports and applications is listed in Section 7. RFCs that give guidance to developers of new algorithms are discussed in Section 8. Finally, documents that have historic significance, but perhaps not current direct technical application, have been classified into Section 9. Note that the use of the term "historic" here has nothing to do with the IETF's formal classification of documents as having "Historic" status.
TCP传输协议将在第3节中讨论。第4节介绍了链路属性和机制与端到端拥塞控制中使用的各种算法和启发式之间的相互作用。IETF开发（并在一定程度上部署）的一种方法是第5.1节的主题，该方法允许基于网络和基于主机的拥塞控制在不丢弃数据包的情况下进行交互。第6节介绍了TCP以外的单播传输协议使用的拥塞控制算法。第7节列出了多播传输和应用程序的拥塞控制工作。第8节讨论了为新算法开发人员提供指导的RFC。最后，具有历史意义但可能不是当前直接技术应用的文件已被归入第9节。请注意，此处使用术语“历史”与IETF将文件正式分类为“历史”状态无关。
Some documents in this section contain architectural guidance and concerns, while others specify congestion-control-related mechanisms that are broadly applicable and have impacts on more than a single class of congestion control techniques. Some of these documents are direct products of the Internet Architecture Board (IAB), giving their guidance on specific aspects of congestion control in the Internet.
本节中的一些文档包含架构指南和关注点，而其他文档则指定了广泛适用的拥塞控制相关机制，并对不止一类拥塞控制技术产生影响。其中一些文件是互联网体系结构委员会（IAB）的直接产品，为互联网拥塞控制的具体方面提供指导。
RFC 1122: "Requirements for Internet Hosts -- Communication Layers" (October 1989)
RFC 1122：“互联网主机的要求——通信层”（1989年10月）
[RFC1122] formally mandates that hosts perform congestion control. For TCP, several congestion control features are described and listed as required elements of conforming implementations, and for UDP, RFC 1122 leaves congestion control as an issue for higher-layered protocols. Although sending and reacting to ICMP Source Quench packets is no longer recommended [RFC1812] [Gont10], the rest of the congestion control guidance in this RFC is still a basis for several current practices in TCP implementations.
[RFC1122]正式要求主机执行拥塞控制。对于TCP，描述了几种拥塞控制功能，并将其列为一致性实现的必要元素；对于UDP，RFC 1122将拥塞控制作为更高层次协议的一个问题。虽然不再建议发送ICMP源猝灭数据包并对其作出反应[RFC1812][Gont10]，但本RFC中的其他拥塞控制指南仍然是TCP实现中几种当前实践的基础。
RFC 1812: "Requirements for IP Version 4 Routers" (June 1995)
RFC 1812：“IP版本4路由器的要求”（1995年6月）
Numerous issues relevant to router behavior are discussed in [RFC1812], and requirements for routers to support are prescribed within the document. Portions of RFC 1812 that are particularly relevant to congestion control include the directive that routers SHOULD NOT originate ICMP Source Quench messages, discussion of precedence in queueing, and Section 5.3.6 titled "Congestion
[RFC1812]中讨论了许多与路由器行为相关的问题，文件中规定了路由器支持的要求。RFC 1812中与拥塞控制特别相关的部分包括路由器不应发起ICMP源猝灭消息的指令、排队优先级的讨论以及标题为“拥塞”的第5.3.6节
Control" that recommends sizing buffers as a function of the product of the bandwidth of the link times the path delay of the flows using the link, and advises on the implementation of active queue management techniques.
“控制”，它建议根据链路带宽乘以使用链路的流的路径延迟的乘积来调整缓冲区的大小，并建议实施主动队列管理技术。
RFC 1958: "Architectural Principles of the Internet" (June 1996)
RFC 1958：“互联网架构原则”（1996年6月）
Several guidelines for network systems design that have proven useful in the evolution of the Internet are sketched in [RFC1958]. Congestion control is not specifically mentioned or alluded to, but the general principles apply to congestion control. For instance, performing end-to-end functions at end nodes, lack of centralized control, heterogeneity, scalability, simplicity, avoiding options and parameters, etc., are all valid concerns in the design and assessment of congestion control schemes for the Internet.
[RFC1958]中概述了在互联网发展过程中证明有用的几个网络系统设计指南。没有特别提及或暗示拥塞控制，但一般原则适用于拥塞控制。例如，在终端节点执行端到端功能、缺乏集中控制、异构性、可扩展性、简单性、避免选项和参数等，都是互联网拥塞控制方案设计和评估中的有效关注点。
RFC 2140: "TCP Control Block Interdependence" (April 1997)
RFC 2140：“TCP控制块相互依赖”（1997年4月）
[RFC2140] suggests that TCP connections between the same endpoints might share some information, including their congestion control state. To some degree, this is done in practice by a few current operating systems; for example, Linux currently has a destination cache with this information, but this behavior is not yet formally standardized or recognized as a best practice by the IETF.
[RFC2140]表明相同端点之间的TCP连接可能共享一些信息，包括它们的拥塞控制状态。在某种程度上，这实际上是由一些当前的操作系统完成的；例如，Linux目前有一个包含此信息的目标缓存，但此行为尚未正式标准化，也未被IETF视为最佳实践。
RFC 2309: "Recommendations on Queue Management and Congestion Avoidance in the Internet" (April 1998)
RFC 2309：“关于互联网队列管理和避免拥塞的建议”（1998年4月）
[RFC2309] briefly discusses the history of congestion and the origin of congestion control in the Internet. The focus is mainly on network- or router-based queue management algorithms. This RFC recommends to test, standardize, and deploy Active Queue Management (AQM) in routers; it provides an overview of one such mechanism, Random Early Detection (RED), and explains how and why AQM mechanisms can improve the performance of the Internet. Finally, this document explains the danger of a possible "congestion collapse" from unresponsive flows and makes a strong recommendation to develop and eventually deploy router mechanisms to protect the Internet from such traffic.
[RFC2309]简要讨论了互联网拥塞的历史和拥塞控制的起源。重点是基于网络或路由器的队列管理算法。本RFC建议在路由器中测试、标准化和部署主动队列管理（AQM）；它提供了一个这样的机制，随机早期检测（RED）的概述，并解释了AQM机制如何以及为什么可以提高互联网的性能。最后，本文解释了无响应流可能导致“拥塞崩溃”的危险，并强烈建议开发并最终部署路由器机制，以保护互联网免受此类流量的影响。
Today, the advice in this document has been followed to some extent. Hardware and software vendors have been receptive, and AQM techniques are widely available in many popular dedicated commercial router products and even in more general operating
今天，在某种程度上遵循了本文件中的建议。硬件和软件供应商已经接受，AQM技术在许多流行的专用商用路由器产品中，甚至在更一般的操作系统中都广泛可用
systems that are sometimes used as routers. However, AQM techniques may not be enabled in default configurations of these systems, and it is often left to users and network engineers to enable and configure AQM mechanisms when desired. In some cases, enabling QoS mechanisms on a device also enables AQM mechanisms by default. The number of production routers that actually have these AQM features enabled is an open question.
有时用作路由器的系统。然而，在这些系统的默认配置中可能无法启用AQM技术，并且通常由用户和网络工程师在需要时启用和配置AQM机制。在某些情况下，默认情况下，在设备上启用QoS机制也会启用AQM机制。实际启用这些AQM功能的生产路由器的数量是一个悬而未决的问题。
RFC 2914 (BCP 41): "Congestion Control Principles" (September 2000)
RFC 2914（BCP 41）：“拥塞控制原则”（2000年9月）
[RFC2914] is an explanation of the principles of congestion control, and the IETF's Best Current Practice for congestion control design. It points out that there are an increasing number of applications that do not use TCP, and elaborates on the importance of performing congestion control for such traffic in order to prevent congestion collapse. The TCP Reno congestion control mechanisms are described as an example of end-to-end congestion control within transport protocols.
[RFC2914]是对拥塞控制原则的解释，以及IETF当前拥塞控制设计的最佳实践。它指出，越来越多的应用程序不使用TCP，并详细阐述了对此类流量执行拥塞控制以防止拥塞崩溃的重要性。TCP Reno拥塞控制机制被描述为传输协议内端到端拥塞控制的示例。
SCTP is one example of a non-TCP transport protocol that implements congestion control based on these principles. The developments of TFRC [RFC3448] and DCCP [RFC4340] are attempts to provide useful tools implementing those principles for applications with needs similar to streaming media, where TCP's reactions are too fast. It would be beneficial for users and the Internet itself if these carefully designed tools become widely deployed in place of other ad hoc schemes that may not be well-grounded in the congestion control principles. This replacement process is ongoing and not yet complete. Appropriate and usable congestion control schemes for non-TCP flows continue to be an open research area.
SCTP是基于这些原理实现拥塞控制的非TCP传输协议的一个示例。TFRC[RFC3448]和DCCP[RFC4340]的开发旨在为需要类似于流媒体的应用程序提供实现这些原则的有用工具，而TCP的反应太快。如果这些精心设计的工具能够被广泛使用，以取代其他可能不符合拥塞控制原则的临时方案，这对用户和互联网本身都是有益的。这一更换过程正在进行中，尚未完成。针对非TCP流的合适且可用的拥塞控制方案仍然是一个开放的研究领域。
RFC 3124: "The Congestion Manager" (June 2001)
RFC 3124：“拥塞管理器”（2001年6月）
[RFC3124] specifies the Congestion Manager, an end-system service that realizes congestion control on a per-host-pair rather than a per-connection basis, which may be a more appropriate way to carry out congestion control. Using the Congestion Manager, multiple streams between two hosts (which may include TCP flows) can adapt to network congestion in a unified fashion.
[RFC3124]指定拥塞管理器，这是一种终端系统服务，可在每主机对而不是每连接的基础上实现拥塞控制，这可能是执行拥塞控制的更合适方式。使用拥塞管理器，两台主机之间的多个流（可能包括TCP流）可以以统一的方式适应网络拥塞。
This proposal is related to RFC 2140, discussed above, but with a wider scope than TCP. Because some pieces of its supporting architecture have not yet been specified, the Congestion Manager's techniques are not commonly used today and have not been widely implemented and deployed yet beyond experimental stacks. Sharing
本提案与上文讨论的RFC 2140相关，但范围比TCP更广。由于其支持架构的某些部分尚未指定，因此拥塞管理器的技术在今天并不普遍使用，也没有在实验堆栈之外广泛实施和部署。分享
of congestion and path information between individual connections continues to be an open research area with branches in detecting shared bottlenecks when using multiple paths, caching of old state for faster startup, and sharing of current state and feedback.
单个连接之间的拥塞和路径信息分析仍然是一个开放的研究领域，分支机构在使用多条路径时检测共享瓶颈，缓存旧状态以加快启动，以及共享当前状态和反馈。
RFC 3426: "General Architectural and Policy Considerations" (November 2002)
RFC 3426：“总体架构和政策考虑”（2002年11月）
[RFC3426] lists a number of questions that can be answered for a particular technical solution to determine its architectural impact and desirability. These are valid for congestion control mechanisms, and end-point congestion management is used as an example case-study several times in RFC 3426. Two salient questions that RFC 3426 advises asking about proposed mechanisms are why they are needed in addition to existing protocols, and why they are needed at a certain layer rather than at other layers. These are particularly relevant for congestion control mechanisms since several already exist and since they can span network, transport, and application layers.
[RFC3426]列出了一系列可以针对特定技术解决方案回答的问题，以确定其架构影响和可取性。这些都适用于拥塞控制机制，并且在RFC 3426中多次将端点拥塞管理用作示例案例研究。RFC 3426建议询问拟议机制的两个突出问题是，为什么除了现有协议之外还需要这些机制，以及为什么在某一层而不是其他层需要这些机制。这些机制与拥塞控制机制特别相关，因为已有几种机制，而且它们可以跨网络、传输和应用层。
RFC 3439: "Some Internet Architectural Guidelines and Philosophy" (December 2002)
RFC 3439：“一些互联网架构指南和理念”（2002年12月）
[RFC3439] supplements RFC 1958. Simplicity is stressed, as the unpredictable results of complexity (due to amplification and coupling) are described. Congestion control issues stemming from layering interactions between transport and lower protocols are presented, as well as other items relevant to congestion control, including asymmetry and the "myth of over-provisioning".
[RFC3439]补充RFC 1958。在描述复杂度（由于放大和耦合）的不可预测结果时，强调了简单性。本文介绍了由传输和较低协议之间的分层交互引起的拥塞控制问题，以及与拥塞控制相关的其他项目，包括不对称性和“过度供应神话”。
RFC 3714: "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet" (March 2004)
RFC 3714：“IAB对互联网语音流量拥塞控制的关注”（2004年3月）
[RFC3714] can be seen as a follow-up to the concerns that were discussed in RFC 2914. It expresses the IAB's concern over the lack of effective end-to-end congestion control for best-effort voice traffic, which is noted as being a current service with growing demand. An example of a VoIP connection between Atlanta, Georgia, USA, and Nairobi, Kenya, is given, where a single VoIP call consumed more than half of the access link capacity (which is normally shared across several different users). This example is used as the basis for further discussion, making it clear that using some form of congestion control for VoIP traffic is highly recommended.
[RFC3714]可视为RFC 2914中讨论的问题的后续行动。它表达了IAB对尽力而为的语音通信缺乏有效的端到端拥塞控制的关注，该业务被认为是当前需求不断增长的一项服务。给出了美国佐治亚州亚特兰大和肯尼亚内罗毕之间的VoIP连接示例，其中单个VoIP呼叫消耗了一半以上的接入链路容量（通常由多个不同的用户共享）。此示例用作进一步讨论的基础，明确表示强烈建议对VoIP流量使用某种形式的拥塞控制。
The TCP specifications found in RFC 793 and its predecessors did not contain any discussion of using or managing a congestion window. Other than a simple retransmission timeout and flow control through the advertised receive window, TCP implementations based only on RFC 793 do not contain congestion control. As several congestion collapse events occurred on the Internet, it was later realized that congestion control was needed. The host requirements in RFC 1122 require conforming TCP implementations to implement Jacobson's slow start and congestion avoidance algorithms (later specified in RFC 2001 and then RFC 2581). RFC 1122 also recommends several other behaviors that influence congestion control like the Nagle algorithm, delayed acknowledgements, Jacobson's retransmission timeout (RTO) estimation algorithm, and exponential backoff of the retransmission timer.
RFC 793及其前身中的TCP规范未包含任何关于使用或管理拥塞窗口的讨论。除了通过广告接收窗口进行简单的重传超时和流量控制外，仅基于RFC 793的TCP实现不包含拥塞控制。由于互联网上发生了几起拥塞崩溃事件，人们后来意识到需要进行拥塞控制。RFC 1122中的主机要求要求一致的TCP实现，以实现Jacobson的慢启动和拥塞避免算法（稍后在RFC 2001和RFC 2581中指定）。RFC 1122还推荐了影响拥塞控制的其他几种行为，如Nagle算法、延迟确认、Jacobson的重传超时（RTO）估计算法和重传计时器的指数后退。
Basic TCP congestion control is defined in RFC 2581, with many other RFCs that specify ancillary modifications and enhancements. RFC 2581 obsoletes the first proposed standard for TCP congestion control in RFC 2001. These two RFCs document the mechanisms that had already been in common use by TCP implementations for many years. The reader may refer to the TCP Roadmap [RFC4614] for more information on the RFCs that specifically describe TCP congestion control, as this material is not replicated here.
基本TCP拥塞控制在RFC 2581中定义，许多其他RFC指定了辅助修改和增强。RFC2581在RFC2001中淘汰了第一个提出的TCP拥塞控制标准。这两个RFC记录了TCP实现已经普遍使用多年的机制。读者可以参考TCP路线图[RFC4614]以了解有关专门描述TCP拥塞控制的RFC的更多信息，因为此处不复制此材料。
Recently, significant effort has been put into experimental TCP congestion control modifications for obtaining high throughput with reduced startup and recovery times. RFCs have been published on some of these modifications, including HighSpeed TCP [RFC3649], and Limited Slow-Start [RFC3742], but high-rate congestion control mechanisms are still considered an open issue in congestion control research. Other schemes have been published as Internet-Drafts or have been discussed a little by the IETF, but much of the work in this area has not been adopted within the IETF yet, so the majority of this work is outside the RFC series and may be discussed in other products of the ICCRG.
最近，为了在减少启动和恢复时间的情况下获得高吞吐量，TCP拥塞控制的实验性修改已经投入了大量的精力。RFC已经发布了其中一些修改，包括高速TCP[RFC3649]和有限慢启动[RFC3742]，但高速拥塞控制机制仍然被认为是拥塞控制研究中的一个开放问题。其他方案已作为互联网草案发布，或已被IETF讨论过一点，但该领域的大部分工作尚未在IETF中采用，因此，大部分工作在RFC系列之外，可能会在ICCRG的其他产品中讨论。
At the time of writing, the IETF's TCP Maintenance and Minor Extensions (TCPM) Working Group was developing an update to RFC 2581 to incorporate small changes from other documents and advance TCP congestion control mechanisms on the IETF Standards Track. The update also clarifies and revises some points. These include the definition of a duplicate ACK, initial congestion window and slow start threshold values, behavior in response to retransmission timeouts, the use of the limited transmit mechanism, and security with regards to misbehaving receivers that practice ACK division.
在撰写本文时，IETF的TCP维护和小型扩展（TCPM）工作组正在对RFC 2581进行更新，以纳入其他文件的小改动，并在IETF标准轨道上推进TCP拥塞控制机制。更新还澄清和修改了一些要点。这些包括重复ACK的定义、初始拥塞窗口和慢启动阈值、响应重传超时的行为、有限传输机制的使用以及与实践ACK分割的行为不正常的接收机有关的安全性。
Links with large and/or variable bandwidth-delay products have traditionally been problematic for congestion control schemes because they can distort the properties of the feedback loop. Links that either expose a high rate of packet losses to the upper layers, or use highly-persistent retransmission mechanisms to prevent losses also cause problems with some of the standard congestion control mechanisms. The documents in this section discuss challenging link characteristics; many of them were written by the Performance Implications of Link Characteristics (PILC) Working Group.
对于拥塞控制方案而言，具有大带宽和/或可变带宽延迟产品的链路传统上是有问题的，因为它们会扭曲反馈环路的特性。向上层暴露高速数据包丢失的链路，或使用高度持久的重传机制来防止丢失的链路，也会导致一些标准拥塞控制机制出现问题。本节中的文件讨论具有挑战性的链路特性；其中许多是由链路特性性能影响（PILC）工作组编写的。
While these documents often refer to specific problems with TCP, the link characteristics that they describe can be expected to affect other congestion control mechanisms too. In particular, interactions between link properties and TCP congestion control will be shared by other protocols that use the similar congestion control behavior, such as SCTP [RFC4960] and DCCP with CCID 2 [RFC4341] (see Section 6), and should be taken into consideration by designers of congestion control mechanisms that utilize the same kind of feedback as TCP.
虽然这些文档经常提到TCP的特定问题，但它们描述的链路特性也可能会影响其他拥塞控制机制。特别是，链路属性和TCP拥塞控制之间的交互将由使用类似拥塞控制行为的其他协议共享，例如SCTP[RFC4960]和带有CCID 2[RFC4341]的DCCP（参见第6节），并且，拥塞控制机制的设计者应该考虑到这一点，这些机制使用与TCP相同的反馈。
Some RFCs only make recommendations regarding the implementation and configuration of TCP based upon characteristics of special links. As these RFCs are so closely connected to the specification of TCP itself, they are not included in this document, but are listed in the TCP Roadmap [RFC4614].
一些RFC仅根据特殊链路的特性对TCP的实现和配置提出建议。由于这些RFC与TCP本身的规范密切相关，因此它们不包含在本文档中，而是列在TCP路线图[RFC4614]中。
RFC 2488 (BCP 28): "Enhancing TCP Over Satellite Channels using Standard Mechanisms" (January 1999)
RFC 2488（BCP 28）：“使用标准机制增强卫星信道上的TCP”（1999年1月）
The summary of recommendations in [RFC2488] came from the TCP over Satellite (TCPSAT) Working Group, whose goal was to identify the performance problems that TCP may have over satellite links and suggest mitigations. The document explains several ways that existing standards can be applied to improve the performance of basic TCP congestion control over paths with characteristics similar to those involving satellite links.
[RFC2488]中的建议摘要来自TCP over Satellite（TCPSAT）工作组，其目标是确定TCP可能在卫星链路上存在的性能问题，并提出缓解建议。该文件解释了几种可以应用现有标准来提高基本TCP拥塞控制在具有类似于卫星链路特性的路径上的性能的方法。
RFC 3135: "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations" (June 2001)
RFC 3135：“旨在缓解链路相关降级的性能增强代理”（2001年6月）
[RFC3135] is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Different types of PEPs are described as well as the mechanisms used to
[RFC3135]是对性能增强代理（PEP）的调查，通常用于改善因特定链路环境（例如卫星、无线WAN和无线LAN环境）的特性而导致的TCP性能下降。描述了不同类型的PEP以及用于
improve performance. While there is a specific focus on TCP in this document, PEPs can operate on any protocol, and the performance enhancements that PEPs achieve are often closely related to congestion control.
提高性能。虽然本文特别关注TCP，但PEPs可以在任何协议上运行，并且PEPs实现的性能增强通常与拥塞控制密切相关。
The use of PEPs has architectural implications as they sometimes violate end-to-end assumptions and can add complexity to the inner portions of a network. Certain types of PEPs are commonly used today in satellite or long-distance networking because it is easier to insert a small number of PEPs near problematic links than to upgrade the TCP implementations on all the end hosts that might use those links. One down-side is that their deployment raises some issues when introducing new or updated congestion control (CC) methods into these deployed networks, since the PEPs may be operating with undocumented algorithms, making assumptions about the end-host CC behavior, and/or altering packet fields that will affect the end-host CC behavior.
PEP的使用具有架构含义，因为它们有时会违反端到端的假设，并会增加网络内部部分的复杂性。某些类型的PEP目前常用于卫星或远程网络，因为在有问题的链路附近插入少量PEP比在可能使用这些链路的所有终端主机上升级TCP实现更容易。不利的一面是，在将新的或更新的拥塞控制（CC）方法引入这些部署的网络时，它们的部署会引发一些问题，因为PEP可能使用未记录的算法运行，对终端主机CC行为做出假设，和/或改变将影响终端主机CC行为的数据包字段。
RFC 3150 (BCP 48): "End-to-end Performance Implications of Slow Links" (July 2001)
RFC 3150（BCP 48）：“慢链路的端到端性能影响”（2001年7月）
[RFC3150] makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. It includes a discussion of interactions between such links and TCP congestion control.
[RFC3150]为穿越“极低比特率”链路的网络路径用户提供与性能相关的建议。它包括对此类链路和TCP拥塞控制之间交互的讨论。
RFC 3155 (BCP 50): "End-to-end Performance Implications of Links with Errors" (August 2001)
RFC 3155（BCP 50）：“有错误链接的端到端性能影响”（2001年8月）
Under the premise that several types of PEP have undesirable implications, [RFC3155] recommends end-to-end alternatives for improving TCP performance over paths with error-prone links.
在几种类型的PEP都有不良影响的前提下，[RFC3155]推荐了端到端的替代方案，以改善具有易出错链路的路径上的TCP性能。
RFC 3366 (BCP 62): "Advice to link designers on link Automatic Repeat reQuest (ARQ)" (August 2002)
RFC 3366（BCP 62）：“关于链路自动重复请求（ARQ）的链路设计者建议”（2002年8月）
Link-layer ARQ techniques are a popular means to increase the robustness of particular links to transmission errors via retransmission and acknowledgement mechanisms. As [RFC3366] explains, ARQ techniques on a link can interact poorly with TCP's end-to-end congestion control if they lead to additional delay variation or reordering. This RFC gives some advice on limiting the extent of these types of problematic interactions. The proper
链路层ARQ技术是通过重传和确认机制提高特定链路对传输错误的鲁棒性的常用方法。正如[RFC3366]所解释的，如果链路上的ARQ技术导致额外的延迟变化或重新排序，那么它们与TCP的端到端拥塞控制之间的交互可能会很差。本RFC提供了一些关于限制这些类型的问题交互的范围的建议。适当的
balance between end-to-end and link-layer reliability mechanisms is still an open research issue that has been explored in many academic papers outside the IETF.
端到端和链路层可靠性机制之间的平衡仍然是一个开放的研究问题，IETF之外的许多学术论文都探讨了这个问题。
RFC 3449 (BCP 69): "TCP Performance Implications of Network Path Asymmetry" (December 2002)
RFC 3449（BCP 69）：“网络路径不对称对TCP性能的影响”（2002年12月）
[RFC3449] describes performance limitations of TCP when the capacity of the ACK path is limited. Several techniques to aid TCP in these circumstances are recommended as Best Current Practices, particularly ACK congestion control and sender pacing are relevant to other non-TCP congestion control schemes, outside the scope of this document. For instance, in the design of the Reliable Multicast Transport (RMT) protocols for multicast, preventing ACK-implosion at multicast sources can be seen as a form of ACK congestion control.
[RFC3449]描述了当ACK路径的容量受到限制时TCP的性能限制。推荐几种在这些情况下帮助TCP的技术作为当前最佳实践，特别是ACK拥塞控制和发送方速度调整与其他非TCP拥塞控制方案相关，不在本文档范围内。例如，在设计用于多播的可靠多播传输（RMT）协议时，可以将防止多播源处的ACK内爆视为ACK拥塞控制的一种形式。
RFC 3481: "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks" (February 2003)
RFC 3481：“第二代（2.5G）和第三代（3G）无线网络上的TCP”（2003年2月）
Among other issues, some mobile data systems exhibit delay spikes, handovers, and bandwidth oscillation. [RFC3481] describes the problems that these conditions cause for TCP congestion control and how some TCP extensions can be used to mitigate them.
在其他问题中，一些移动数据系统表现出延迟峰值、切换和带宽振荡。[RFC3481]描述了这些条件导致TCP拥塞控制的问题，以及如何使用一些TCP扩展来缓解这些问题。
RFC 3819 (BCP 89): "Advice for Internet Subnetwork Designers" (July 2004)
RFC 3819（BCP 89）：“互联网子网设计者的建议”（2004年7月）
Several issues in link design and optimization for carrying IP traffic are discussed in [RFC3819], which recommends Best Current Practices. Many of these principles are motivated by properties of TCP, but most of them also apply to other transport-layer congestion control techniques as well.
[RFC3819]讨论了承载IP流量的链路设计和优化中的几个问题，其中推荐了当前最佳实践。这些原则中的许多都是由TCP的特性驱动的，但其中大多数也适用于其他传输层拥塞控制技术。
Some RFCs define mechanisms that allow routers to add signaling information to packets that makes the network's congestion state less of a mystery to end-host congestion controllers. Routers supporting these can signal information about the current congestion state to flows in-band, providing faster and finer-grained information than inference-based methods. Two examples of this are discussed in this section; the first directs sources to slow down in order to avoid losses, and the other assists in determining an appropriate starting rate for new flows.
一些RFC定义了允许路由器向数据包添加信令信息的机制，从而使网络拥塞状态对终端主机拥塞控制器来说不再那么神秘。支持这些的路由器可以将当前拥塞状态的信息发送给带内的流，提供比基于推断的方法更快、更细粒度的信息。本节讨论了这方面的两个示例；第一种方法指示源减速以避免损失，另一种方法协助确定新流量的适当启动速率。
Traditionally, under congestion, IP routers enqueue packets until some limit is reached, at which point packets are dropped. TCP, and other IETF transport protocols, use a stream of acknowledgements to infer these losses and take congestion control action. This section describes a more advanced way to signal congestion to sources before packet-dropping is required.
传统上，在拥塞情况下，IP路由器将数据包排队，直到达到某个限制，在该限制点数据包被丢弃。TCP和其他IETF传输协议使用确认流来推断这些丢失并采取拥塞控制措施。本节描述了在需要丢包之前向源发送拥塞信号的更高级方法。
There are two Explicit Congestion Notification (ECN) bits in the IP header that enable an AQM mechanism (see [RFC2309] or Section 2) to convey congestion information to endpoints without dropping packets. This can significantly reduce the losses experienced by transport endpoints if they are responsive to ECN. While ECN is most frequently discussed in the context of TCP (and therefore included in the TCP Roadmap [RFC4614]), its applicability is broader, and ECN use has also been specified for protocols such as DCCP and SCTP.
IP报头中有两个显式拥塞通知（ECN）位，使AQM机制（参见[RFC2309]或第2节）能够在不丢弃数据包的情况下向端点传送拥塞信息。如果传输端点响应ECN，则这可以显著减少它们所经历的损失。虽然ECN最常在TCP上下文中讨论（因此包含在TCP路线图[RFC4614]），但其适用范围更广，并且ECN的使用也被指定用于DCCP和SCTP等协议。
RFC 2481: "A Proposal to add Explicit Congestion Notification (ECN) to IP" (January 1999) - Obsoleted by RFC 3168
RFC 2481：“向IP添加明确拥塞通知（ECN）的提案”（1999年1月）-被RFC 3168废除
[RFC2481] introduced ECN into the RFC series, describing when the Congestion Experienced (CE) bit in the IP header should be set in routers, and what modifications are needed to TCP to make it ECN-capable. It includes a discussion of issues related to nodes and routers that are non-compliant, IPsec tunnels, and dropped or corrupted packets, as well as a summary of related work. Many of these issues will also be faced by operators trying to deploy other network-based congestion control methods. RFC 2481 has been obsoleted by RFC 3168.
[RFC2481]在RFC系列中引入了ECN，描述了什么时候应该在路由器中设置IP报头中的拥塞体验（CE）位，以及需要对TCP进行哪些修改才能使其支持ECN。它包括与不兼容的节点和路由器、IPsec隧道、丢弃或损坏的数据包相关的问题的讨论，以及相关工作的总结。试图部署其他基于网络的拥塞控制方法的运营商也将面临其中许多问题。RFC 2481已被RFC 3168淘汰。
RFC 2884: "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks" (July 2000)
RFC 2884：“IP网络中显式拥塞通知（ECN）的性能评估”（2000年7月）
[RFC2884] presents a performance study of ECN as specified in [RFC2481] using an implementation on the Linux operating system. The experiments focused on ECN for both bulk and transactional transfers, showing that there is improvement in throughput over TCP without ECN in the case of bulk transfers and substantial improvement for transactional transfers. Studies like this help to build the community's confidence that extensions like ECN are both safe and valuable. Similar RFCs helped the community accept larger initial windows for TCP [RFC2414] [RFC2415] [RFC2416].
[RFC2884]介绍了使用Linux操作系统上的实现对[RFC2481]中规定的ECN进行的性能研究。实验集中在批量传输和事务传输的ECN上，结果表明，在批量传输的情况下，在没有ECN的情况下，TCP的吞吐量有了提高，而事务传输的吞吐量有了实质性的提高。这样的研究有助于建立社区的信心，即像ECN这样的扩展既安全又有价值。类似的RFC帮助社区接受TCP[RFC2414][RFC2415][RFC2416]的较大初始窗口。
RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to IP" (September 2001)
RFC 3168：“向IP添加显式拥塞通知（ECN）”（2001年9月）
[RFC3168], which obsoletes [RFC2481], specifies the incorporation of ECN into TCP and IP. One notable change in this significantly extended specification is the definition of a bit combination that was not defined in [RFC2481], which can be used to realize a nonce that would prevent a receiver from falsely claiming that there was no congestion. Potential issues related to ECN are discussed at length, including those already included in [RFC2481] and backwards compatibility with implementations that would follow the specification in the obsoleted document.
[RFC3168]淘汰了[RFC2481]，规定将ECN合并到TCP和IP中。这个显著扩展的规范中的一个显著变化是[RFC2481]中未定义的位组合的定义，它可用于实现一个nonce，以防止接收器错误地声称没有拥塞。详细讨论了与ECN相关的潜在问题，包括[RFC2481]中已经包含的问题以及与将遵循废弃文档中规范的实现的向后兼容性。
ECN, as specified in RFC 3168, is implemented in several popular router and end-host platforms. It is in active use, to at least some extent. Problems with ECN "blackholes" (Internet routers misconfigured to discard packets with ECN-capable bits set) were discovered when ECN was enabled by default in some end-host operating systems. Fears about the persisting presence of these blackholes currently may be keeping ECN from being used by default in many end-host operating systems even though it is implemented as an option within them. Some measurements on ECN support and usability are available [PF01] [MAF04] [MAF05].
RFC3168中规定的ECN在几种流行的路由器和终端主机平台上实现。至少在某种程度上，它正在被积极使用。在某些终端主机操作系统中默认启用ECN时，发现了ECN“黑洞”（错误配置为丢弃具有ECN功能位集的数据包的Internet路由器）的问题。目前对这些黑洞持续存在的担忧可能会阻止ECN在许多终端主机操作系统中默认使用，即使它是作为一种选项实现的。有关ECN支持和可用性的一些度量值，请参见[PF01][MAF04][MAF05]。
RFC 3540: "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" (June 2003)
RFC 3540：“具有nonce的健壮显式拥塞通知（ECN）信令”（2003年6月）
[RFC3540] specifies a nonce mechanism that uses an ECN bit combination that is not used in [RFC2481], but that is specified in [RFC3168] to allow a one-bit ECN nonce. This nonce mechanism includes a Nonce Sum (NS) field in the TCP header so that senders can ensure that ACKs that do not indicate congestion are credible. The mechanism improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth.
[RFC3540]指定使用[RFC2481]中未使用但在[RFC3168]中指定的ECN位组合以允许一位ECN nonce的nonce机制。此nonce机制在TCP报头中包含一个nonce Sum（NS）字段，以便发送方可以确保不表示拥塞的ACK是可信的。该机制通过防止接收机利用ECN获得不公平的网络带宽份额，提高了拥塞控制的鲁棒性。
This nonce technique is not understood to have been widely implemented or deployed, and there has been some discussion as to whether the mechanism is really effective or is the best use of these bits (see emails to the IETF Transport Area Working Group (TSVWG) mailing list, in the thread "ECN nonce snag in TCP ESTATS MIB" from December 2006 - January 2007, or [MBJ07]).
目前还不了解这种nonce技术是否已被广泛实施或部署，并且已经就该机制是否真的有效或是这些比特的最佳利用进行了一些讨论（参见发送给IETF传输区域工作组（TSVWG）邮件列表的电子邮件，在“TCP ESTATS MIB中的ECN nonce snag”线程中自2006年12月至2007年1月，或[MBJ07]）。
RFC 4782: "Quick-Start for TCP and IP" (January 2007)
RFC 4782：“TCP和IP的快速启动”（2007年1月）
Quick-Start provides a way for hosts to ask routers to help them select an initial sending rate, and use this rate rather than the traditional small initial congestion window and slow-start algorithm. [RFC4782] describes the Quick-Start mechanism and its use with TCP. In addition to discussing the benefits of Quick-Start, the document also discusses several limitations of the Quick-Start technique with respect to some types of tunnels in use over the Internet today and other potential costs of Quick-Start including those related to router design. Analysis of the effects of misbehaving entities and appendices containing design rationale and related work are also notably present in this RFC.
快速启动为主机提供了一种方法，让路由器帮助他们选择初始发送速率，并使用该速率，而不是传统的小初始拥塞窗口和慢启动算法。[RFC4782]介绍了快速启动机制及其在TCP中的使用。除了讨论快速启动的好处外，本文件还讨论了快速启动技术在当前互联网上使用的某些类型的隧道方面的一些限制，以及快速启动的其他潜在成本，包括与路由器设计相关的成本。本RFC中还特别介绍了行为不当实体的影响分析以及包含设计原理和相关工作的附录。
Many of the issues discussed in RFC 4782, including router architecture, network design / tunnels, and misbehaving agents are all challenges relevant to other proposals that try to add router assistance into the network. The consideration of these issues can be illustrative for other protocol designers, even if they are not interested in Quick-Start itself.
RFC 4782中讨论的许多问题，包括路由器体系结构、网络设计/隧道和行为不端的代理，都是与试图将路由器协助添加到网络中的其他提案相关的挑战。对这些问题的考虑可以为其他协议设计人员提供说明，即使他们对快速启动本身不感兴趣。
In the past, TCP dominated Internet traffic, as it was used for many of the popular applications (email, web browsing, file transfer, remote login, etc.). The majority of early congestion control work focused on TCP, and the introduction of congestion control into TCP alone is often credited with saving the Internet from additional congestion collapse events. Today, TCP has been joined by other transport protocols (e.g., custom UDP-based protocols, SCTP, DCCP, RTP over UDP [RFC3550], etc.), and so having properly functioning congestion control within these other protocols is important for the Internet's health (as explained in RFC 3714, for instance, or see the discussion of the "congestion control arms race" scenario in RFC 2914). Documents that describe unicast congestion control methods for non-TCP transport protocols have been grouped into this section.
在过去，TCP控制着互联网流量，因为它被用于许多流行的应用程序（电子邮件、web浏览、文件传输、远程登录等）。大多数早期的拥塞控制工作都集中在TCP上，而将拥塞控制引入TCP本身往往被认为是避免了额外的拥塞崩溃事件。如今，TCP已经被其他传输协议（例如，基于UDP的自定义协议、SCTP、DCCP、UDP上的RTP[RFC3550]等）加入，因此在这些其他协议中正确运行拥塞控制对于互联网的健康非常重要（例如，如RFC 3714中所述，或参见RFC 2914中的“拥塞控制军备竞赛”场景）。描述非TCP传输协议的单播拥塞控制方法的文档已归入本节。
RFC 4960: "Stream Control Transmission Protocol" (September 2007)
RFC 4960：“流控制传输协议”（2007年9月）
SCTP congestion control is very similar to TCP with Selective Acknowledgements, but there are some differences, as described in Section 7.1 of [RFC4960]. The major difference lies in the fact that SCTP supports multihoming, whereas TCP does not. Thus, SCTP
SCTP拥塞控制与具有选择性确认的TCP非常相似，但存在一些差异，如[RFC4960]第7.1节所述。主要区别在于SCTP支持多主，而TCP不支持。因此，SCTP
keeps a different set of congestion control parameters for each destination address within an association, whereas TCP only keeps a single set of congestion control parameters per connection.
为关联中的每个目标地址保留一组不同的拥塞控制参数，而TCP仅为每个连接保留一组单独的拥塞控制参数。
RFC 5348: "TCP Friendly Rate Control (TFRC): Protocol Specification" (September 2008)
RFC 5348：“TCP友好速率控制（TFRC）：协议规范”（2008年9月）
[RFC5348], which obsoletes [RFC3448], specifies TCP-Friendly Rate
Control (TFRC), a rate-based congestion control mechanism for
unicast flows operating in a best-effort Internet environment
where flows are competing with standard TCP traffic. TFRC ensures
conformance with TCP by continuously calculating the rate that a
TCP sender would obtain under similar circumstances using a
slightly simplified version of the TCP Reno throughput equation in
[PFTK98]. Its sending rate is smoother than the rate of TCP,
making it suitable for multimedia applications. TFRC is not a
wire protocol but rather a mechanism that could, for instance, be
used within a UDP-based application, in a transport protocol such
as RTP, or in the context of endpoint congestion management
[RFC3124].
[RFC5348], which obsoletes [RFC3448], specifies TCP-Friendly Rate
Control (TFRC), a rate-based congestion control mechanism for
unicast flows operating in a best-effort Internet environment
where flows are competing with standard TCP traffic. TFRC ensures
conformance with TCP by continuously calculating the rate that a
TCP sender would obtain under similar circumstances using a
slightly simplified version of the TCP Reno throughput equation in
[PFTK98]. Its sending rate is smoother than the rate of TCP,
making it suitable for multimedia applications. TFRC is not a
wire protocol but rather a mechanism that could, for instance, be
used within a UDP-based application, in a transport protocol such
as RTP, or in the context of endpoint congestion management
[RFC3124].
RFC 3550: "RTP: A Transport Protocol for Real-Time Applications" (July 2003)
RFC3550：“RTP：实时应用的传输协议”（2003年7月）
[RFC3550] specifies the real-time transport protocol RTP along with its control protocol RTCP. RTP/RTCP does not prescribe a specific congestion control behavior, but it is recommended that such a behavior be specified in each RTP profile (which is due to the fact that the potential for reducing the sending rate is often content dependent in the case of real-time streams). Specifically, [RFC3550] states: "For some profiles, it may be sufficient to include an applicability statement restricting the use of that profile to environments where congestion is avoided by engineering. For other profiles, specific methods such as data rate adaptation based on RTCP feedback may be required". [RFC4585], which discusses RTCP feedback and adaptation mechanisms, points out that RTCP feedback may operate on much slower timescales than transport layer feedback mechanisms, and that additional mechanisms are therefore required to perform proper congestion control. One way to make use of such additional mechanisms is to run RTP over DCCP.
[RFC3550]指定实时传输协议RTP及其控制协议RTCP。RTP/RTCP没有规定特定的拥塞控制行为，但建议在每个RTP配置文件中指定此类行为（这是因为在实时流的情况下，降低发送速率的可能性通常取决于内容）。具体而言，[RFC3550]指出：“对于某些配置文件，可能只需包含一份适用性声明，将该配置文件的使用限制在通过工程避免拥塞的环境中即可。对于其他配置文件，可能需要使用基于RTCP反馈的数据速率适配等特定方法。”。[RFC4585]讨论了RTCP反馈和自适应机制，指出RTCP反馈可能在比传输层反馈机制慢得多的时间尺度上运行，因此需要额外的机制来执行适当的拥塞控制。利用这种附加机制的一种方法是在DCCP上运行RTP。
RFC 4336: "Problem Statement for the Datagram Congestion Control Protocol (DCCP)" (March 2006)
RFC 4336：“数据报拥塞控制协议（DCCP）的问题声明”（2006年3月）
[RFC4336] provides the motivation leading to the design of DCCP. In doing so, other possibilities of implementing similar functionality are discussed, including unreliable extensions of SCTP, RTP-based congestion control, and providing congestion control above or below UDP.
[RFC4336]为DCCP的设计提供了动力。在此过程中，讨论了实现类似功能的其他可能性，包括SCTP的不可靠扩展、基于RTP的拥塞控制以及在UDP之上或之下提供拥塞控制。
RFC 4340: "Datagram Congestion Control Protocol" (March 2006)
RFC 4340：“数据报拥塞控制协议”（2006年3月）
[RFC4340] specifies DCCP, the Datagram Congestion Control Protocol. This protocol provides bidirectional unicast connections of congestion-controlled unreliable datagrams. It is suitable for applications that can benefit from control over the tradeoff between timeliness and reliability. The core DCCP specification does not include a specific congestion control behavior; rather, it functions as a framework for such mechanisms, which can be selected via the Congestion Control Identifier (CCID).
[RFC4340]指定数据报拥塞控制协议DCCP。该协议提供拥塞控制的不可靠数据报的双向单播连接。它适用于能够从控制及时性和可靠性之间的权衡中获益的应用程序。核心DCCP规范不包括特定的拥塞控制行为；相反，它作为此类机制的框架，可以通过拥塞控制标识符（CCID）进行选择。
RFC 4341: "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control" (March 2006)
RFC 4341：“数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制”（2006年3月）
[RFC4341] is the specification of TCP-like congestion control within DCCP. This should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. ECN is also supported within RFC 4341.
[RFC4341]是DCCP中类似TCP的拥塞控制规范。如果发送方希望在条件快速变化的环境中利用可用带宽，并且能够适应TCP加性增加乘性减少（AIMD）拥塞控制典型的拥塞窗口的突然变化，则应使用此方法。RFC 4341中也支持ECN。
RFC 4342: "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)" (March 2006)
RFC 4342：“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”（2006年3月）
[RFC4342] is the specification of TFRC congestion control as described in [RFC3448] for DCCP. This should be used by senders who want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes.
[RFC4342]是[RFC3448]中描述的DCCP TFRC拥塞控制规范。这应该被希望TCP友好的发送速率的发送者使用，可能带有显式拥塞通知（ECN），同时最小化突然的速率变化。
In the IETF, congestion control for multicast (one-to-many) communication has primarily been tackled in the Reliable Multicast Transport (RMT) Working Group. Except for [RFC2357] and [RFC3208], all the documents in this section were written by this group. Since a "one size fits all" protocol cannot meet the requirements of all possible applications in this space, the approach taken is a modular one, consisting of "protocol cores" and "building blocks". Multiple congestion control building blocks have been defined, providing both sender-driven and receiver-driven congestion control methods that differ widely in their assumptions and behavior.
在IETF中，多播（一对多）通信的拥塞控制主要由可靠多播传输（RMT）工作组解决。除[RFC2357]和[RFC3208]外，本节中的所有文件均由该小组编写。由于“一刀切”的协议无法满足该领域所有可能应用的要求，因此所采取的方法是模块化的，由“协议核心”和“构建块”组成。定义了多个拥塞控制构建块，提供了发送方驱动和接收方驱动的拥塞控制方法，这两种方法在假设和行为上存在很大差异。
RFC 2357: "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols" (June 1998)
RFC 2357：“IETF评估可靠多播传输和应用协议的标准”（1998年6月）
Some early multicast content dissemination proposals did not incorporate proper congestion control; this is pointed out as being a severe mistake in [RFC2357], as large-scale multicast applications have the potential to do vast congestion-related damage. This document clearly makes the case that congestion control mechanisms should be developed and incorporated into multicast content dissemination protocols intended for use over the Internet.
一些早期的多播内容传播方案没有包含适当的拥塞控制；这被认为是[RFC2357]中的一个严重错误，因为大规模多播应用程序有可能造成巨大的拥塞相关损害。本文件明确指出，应开发拥塞控制机制，并将其纳入互联网上使用的多播内容传播协议中。
RFC 2887: "The Reliable Multicast Design Space for Bulk Data Transfer" (August 2000)
RFC 2887：“批量数据传输的可靠多播设计空间”（2000年8月）
Several classes of potential congestion control schemes for single-sender multicast protocols are briefly sketched as possibilities, but no specific protocols are developed or selected in [RFC2887].
单发送方多播协议的几类潜在拥塞控制方案被简要描述为可能，但[RFC2887]中没有开发或选择特定的协议。
RFC 3048: "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer" (January 2001)
RFC 3048：“用于一对多批量数据传输的可靠多播传输构建块”（2001年1月）
[RFC3048] discusses the building block approach to RMT protocols and mentions that several different congestion control building blocks may be required in order to deal with different situations. Some of the possible interactions between building blocks for congestion control and those for Forward Error Correction (FEC), acknowledgement, and group management are also mentioned.
[RFC3048]讨论了RMT协议的构建块方法，并提到可能需要几个不同的拥塞控制构建块来处理不同的情况。还提到了拥塞控制构建块与前向纠错（FEC）、确认和组管理构建块之间可能存在的一些交互。
RFC 3208: "PGM Reliable Transport Protocol Specification" (December 2001)
RFC 3208：“PGM可靠传输协议规范”（2001年12月）
Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. As discussed in [RFC3208]'s Appendix B, a PGM protocol source can request congestion control feedback from both network elements (routers) and receivers (end hosts). These reports can indicate the load on the worst link in a particular path, or the load on the worst path. The actual procedure used in response to this feedback is not part of RFC 3208, but the notion of using multicast routers to assist in congestion control is significant.
实用通用多播（PGM）是一种可靠的多播传输协议，适用于需要从多个源到多个接收器的有序或无序、无重复的多播数据传输的应用。如[RFC3208]的附录B所述，PGM协议源可以从网元（路由器）和接收器（终端主机）请求拥塞控制反馈。这些报告可以指示特定路径中最差链路上的负载，或最差路径上的负载。响应此反馈所使用的实际过程不是RFC 3208的一部分，但使用多播路由器协助拥塞控制的概念非常重要。
RFC 3450: "Asynchronous Layered Coding (ALC) Protocol Instantiation" (December 2002)
RFC 3450：“异步分层编码（ALC）协议实例化”（2002年12月）
[RFC3450] specifies ALC, a rough header format using the RMT building blocks, that can be used by multicast content dissemination protocols. ALC is intended to use a multi-rate congestion control building block, where the sender does not require any feedback, but where multiple multicast groups with different transmission rates are available within and ALC session, and receivers control their rates by joining or leaving groups.
[RFC3450]指定ALC，一种使用RMT构建块的粗略报头格式，可由多播内容分发协议使用。ALC旨在使用多速率拥塞控制构建块，其中发送方不需要任何反馈，但在ALC会话和ALC会话中可使用具有不同传输速率的多播组，并且接收方通过加入或离开组来控制其速率。
RFC 3738: "Wave and Equation Based Rate Control (WEBRC) Building Block" (April 2004)
RFC 3738：“基于波动和方程的速率控制（WEBRC）构造块”（2004年4月）
The WEBRC mechanism defined in [RFC3738] is a receiver-driven form of congestion control, where each receiver in a multicast group can determine the individual rate at which packets are delivered to it. WEBRC senders create a base channel for control information and several multicast channels for data transmission that each send packets at a varying rate in the form of a wave. The receivers dynamically join and leave channels at chosen points within the wave of sending rates to obtain the desired overall receive rate based on an equation using the estimated loss probability and round-trip time within an epoch. WEBRC is compatible for use within ALC.
[RFC3738]中定义的WEBRC机制是一种接收器驱动的拥塞控制形式，其中多播组中的每个接收器都可以确定向其发送数据包的单独速率。WEBRC发送器为控制信息创建一个基本通道，并为数据传输创建多个多播通道，每个多播通道以波的形式以不同的速率发送数据包。接收机在发送速率波中的选定点处动态地加入和离开信道，以基于使用估计的丢失概率和一个历元内的往返时间的等式来获得期望的总体接收速率。WEBRC与ALC内的使用兼容。
RFC 4654: "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification" (August 2006)
RFC 4654：“TCP友好多播拥塞控制（TFMCC）：协议规范”（2006年8月）
TFMCC, as described in [RFC4654], is a sender-driven congestion control mechanism, where the received rate for the entire multicast group is determined by the worst-connected receiver. TFMCC builds upon TFRC, but scales down the feedback to prevent ACK-implosion effects by having receivers suppress their feedback unless they perceive it to be the worst among the reception group.
如[RFC4654]所述，TFMCC是一种发送方驱动的拥塞控制机制，其中整个多播组的接收速率由连接最差的接收方确定。TFMCC建立在TFRC的基础上，但通过让接收者抑制他们的反馈（除非他们认为反馈是接收组中最差的），来降低反馈以防止ACK内爆效应。
Some recently published RFCs discuss the properties of congestion control protocols that are "safe" for Internet deployment, as well as how to measure the properties of congestion control mechanisms and transport protocols. These documents are particularly relevant to the ICCRG as some of the group's activities involve reviewing congestion control proposals that have been brought to the IETF for publication (see http://www.ietf.org/iesg/statement/congestion-control.html).
最近发布的一些RFC讨论了对Internet部署“安全”的拥塞控制协议的属性，以及如何度量拥塞控制机制和传输协议的属性。这些文件与ICCRG特别相关，因为ICCRG的一些活动涉及审查已提交IETF发布的拥塞控制提案（参见http://www.ietf.org/iesg/statement/congestion-control.html).
RFC 5033 (BCP 133): "Specifying New Congestion Control Algorithms" (August 2007)
RFC 5033（BCP 133）：“指定新的拥塞控制算法”（2007年8月）
The concurrent development of multiple TCP modifications for high-rate use and the deployments of these modifications on the Internet prompted [RFC5033] to be written. RFC 5033 comes from the Transport Area Working Group (TSVWG), and gives guidance on the classes of Experimental RFC that can be published to document algorithms that are either encouraged for investigation on the Internet, and those that are only encouraged for experimentation in less-critical environments. It has been described as a list of things for people to think about when creating new congestion control techniques that they are planning to widely deploy.
为高速使用而同时开发的多个TCP修改以及这些修改在互联网上的部署促使[RFC5033]被编写。RFC 5033来自运输区域工作组（TSVWG），并对可发布的实验性RFC类别提供指导，以记录鼓励在互联网上进行调查的算法，以及仅鼓励在不太关键的环境中进行试验的算法。它被描述为人们在创建他们计划广泛部署的新拥塞控制技术时需要考虑的一系列事情。
RFC 5166: "Metrics for the Evaluation of Congestion Control Mechanisms" (March 2008)
RFC 5166：“拥塞控制机制评估指标”（2008年3月）
The IRTF Transport Modeling Research Group (TMRG) produced [RFC5166] to describe the set of metrics and related tradeoffs between metrics that can be used to compare, contrast, and evaluate congestion control techniques. This RFC gives an overview of many such metrics, and gives references to their detailed descriptions.
IRTF传输建模研究小组（TMRG）编制了[RFC5166]，以描述一组指标和指标之间的相关权衡，这些指标可用于比较、对比和评估拥塞控制技术。本RFC概述了许多此类指标，并参考了它们的详细描述。
Early in the RFC series, there are many documents that represent an author's thoughts on a subject or brief summaries from measurement and experimentation, rather than the result of a long formal IETF process. Some of the RFCs listed in this section have this distinction.
在RFC系列的早期，有许多文档代表了作者对某个主题的想法或测量和实验的简要总结，而不是一个漫长的正式IETF过程的结果。本节中列出的一些RFC具有这种区别。
RFC 889: "Internet Delay Experiments" (December 1983)
RFC 889：“互联网延迟实验”（1983年12月）
Based on reported measurement experiments, changes to the TCP retransmission timeout (RTO) calculation are suggested in [RFC0889]. It is noted that the original TCP RTO calculation leads to congestion when a delay spike occurs because it takes too long for the RTO to adapt, leading to superfluous retransmissions.
根据报告的测量实验，[RFC0889]中建议更改TCP重传超时（RTO）计算。需要注意的是，当出现延迟尖峰时，原始TCP RTO计算会导致拥塞，因为RTO适应时间过长，导致多余的重传。
RFC 896: "Congestion Control in IP/TCP Internetworks" (January 1984)
RFC 896：“IP/TCP互联网中的拥塞控制”（1984年1月）
[RFC0896] is the first document known to the authors where the term "congestion collapse" was used. Here, it refers to the stable state that was observed when a sudden load on the net caused the round-trip time to rise faster than the sending hosts measured round-trip time could be updated. Two problems are discussed: the "small-packet problem" (now commonly known by the name "silly window syndrome") and the "source-quench problem", which is about inappropriately deciding when to send and how to react to ICMP Source Quench messages. Solutions for these problems are presented.
[RFC0896]是作者所知的第一个使用术语“拥塞崩溃”的文档。这里，它指的是当网络上的突然负载导致往返时间上升快于发送主机测量的往返时间可以更新时所观察到的稳定状态。讨论了两个问题：“小数据包问题”（现在通常被称为“傻窗口综合症”）和“源猝灭问题”，即不适当地决定何时发送以及如何对ICMP源猝灭消息作出反应。提出了解决这些问题的方法。
RFC 970: "On Packet Switches with Infinite Storage" (December 1985)
RFC 970：“无限存储分组交换机上”（1985年12月）
Using a thought experiment based on a router with infinite buffering capacity, [RFC0970] develops a different kind of congestion collapse scenario, where few useful packet transmissions occur due to the queue being longer than the time-to-live of the packets within it. As described in RFC 970, this scenario was also demonstrated using real equipment by the author.
使用基于具有无限缓冲容量的路由器的思想实验，[RFC0970]开发了一种不同类型的拥塞崩溃场景，由于队列长于其中数据包的生存时间，因此很少发生有用的数据包传输。如RFC970所述，作者还使用真实设备演示了该场景。
The document also includes discussion of game-theoretic analysis of congestion control and obtaining fairness between behaving and non-behaving flows, by focusing on the order of scheduling packets within the buffer rather than the actual allocation of buffer space between flows.
该文件还讨论了拥塞控制的博弈论分析，并通过关注缓冲区内调度数据包的顺序，而不是流之间缓冲区空间的实际分配，在行为流和非行为流之间获得公平性。
RFC 1016: "Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)" (July 1987)
RFC1016：“主机与源猝灭有关的事情：源猝灭引入延迟（SQuID）”（1987年7月）
[RFC1016] outlines a rate-based congestion control mechanism where end-hosts use Source Quench packets from routers to adjust their sending rates. RFC 1016 also suggests sending congestion notifications before queues are actually full, at a rate that increases with the current queue occupancy. This strategy has been used in several other AQM mechanisms, notably RED [FJ93].
[RFC1016]概述了一种基于速率的拥塞控制机制，其中终端主机使用来自路由器的源猝灭数据包来调整其发送速率。RFC1016还建议在队列实际已满之前发送拥塞通知，发送速率随当前队列占用率的增加而增加。此策略已用于其他几个AQM机制，尤其是RED[FJ93]。
RFC 1254: "Gateway Congestion Control Survey" (August 1991)
RFC 1254：“网关拥塞控制调查”（1991年8月）
[RFC1254] is a survey of congestion control approaches in routers that first discusses general congestion control performance goals (such as fairness), and then elaborates on the use of Source Quench messages (which are now discouraged, as they have been found ineffective), Random Drop (which would now be called "Active Queue Management"), Congestion Indication (DEC Bit; an early form of ECN), "Selective Feedback Congestion Indication" (one particular method for applying ECN), and Fair Queuing. Finally, end-system congestion control policies are discussed, including Jacobson's well-known algorithms [Jac88] and their predecessor -- "CUTE" [Jain86].
[RFC1254]是对路由器中拥塞控制方法的调查，首先讨论一般的拥塞控制性能目标（如公平性），然后详细说明源猝灭消息（现在不鼓励使用，因为发现它们无效）、随机丢弃（现在称为“主动队列管理”），拥塞指示（DEC位；ECN的早期形式）、“选择性反馈拥塞指示”（应用ECN的一种特殊方法）和公平排队。最后，讨论了终端系统拥塞控制策略，包括Jacobson的著名算法[Jac88]及其前身——“CUTE”[Jain86]。
This document introduces no new security considerations. Each RFC listed in this document discusses the security considerations of the specification it contains.
本文档没有引入新的安全注意事项。本文档中列出的每个RFC都讨论了其包含的规范的安全注意事项。
Several participants in the ICCRG contributed useful comments in the development of this document, including Rex Buddenberg, Mitchell Erblichs, Lachlan Andrew, Sally Floyd, Stephen Farrell, Gorry Fairhurst, Lars Eggert, Mark Allman, and Juergen Schoenwaelder.
ICCRG的几位参与者在本文件的编写过程中提供了有用的意见，包括雷克斯·布登伯格、米切尔·埃尔布利希斯、拉克兰·安德鲁、萨利·弗洛伊德、斯蒂芬·法雷尔、戈里·费尔赫斯特、拉尔斯·艾格特、马克·奥尔曼和尤尔根·舍恩瓦尔德。
[FJ93] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, volume 1, number 4, August 1993.
[FJ93]Floyd，S.和V.Jacobson，“避免拥塞的随机早期检测网关”，IEEE/ACM网络事务，第1卷，第4期，1993年8月。
[Gont10] Gont, F., "ICMP attacks against TCP", Work in Progress, January 2010.
[Gont10]Gont，F.，“针对TCP的ICMP攻击”，正在进行的工作，2010年1月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of ACM SIGCOMM 1988, in ACM Computer Communication Review, 18 (4), pp. 314-329.
[Jac88]Jacobson，V.，“拥塞避免和控制”，ACM SIGCOMM会议录，1988年，载于《ACM计算机通信评论》，第18（4）页，第314-329页。
[Jain86] Jain, R., "A Timeout-Based Congestion Control Scheme for Window Flow-Controlled Networks", IEEE Journal on Selected Areas in Communications, volume 4, number 7, October 1986.
[Jain86]Jain，R.，“基于超时的窗口流控制网络拥塞控制方案”，《IEEE通信选定领域期刊》，第4卷，第7期，1986年10月。
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proceedings of the Internet Measurement Conference 2004, August 2004.
[MAF04]Medina，A.，Allman，M.，和S.Floyd，“测量传输协议和中间盒之间的相互作用”，互联网测量会议记录2004年，2004年8月。
[MAF05] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM Computer Communications Review, volume 35, issue 2, April 2005.
[MAF05]Medina，A.，Allman，M.，和S.Floyd，“测量互联网传输协议的演变”，ACM计算机通信评论，第35卷，第2期，2005年4月。
[MBJ07] Moncaster, T., Briscoe, B., and A. Jacquet, "A TCP Test to Allow Senders to Identify Receiver Non-Compliance", Work in Progress, November 2007.
[MBJ07]Moncaster，T.，Briscoe，B.，和A.Jacquet，“允许发送方识别接收方违规的TCP测试”，正在进行的工作，2007年11月。
[PF01] Padhye, J. and S. Floyd, "On Inferring TCP Behavior", Proceedings of ACM SIGCOMM 2001, August 2001.
[PF01]Padhye，J.和S.Floyd，“关于推断TCP行为”，ACM SIGCOMM 2001年会议记录，2001年8月。
[PFTK98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP Throughput: A Simple Model and its Empirical Validation", Proceedings of ACM SIGCOMM 1998.
[PFTK98]Padhye，J.，Firoiu，V.，Towsley，D.，和J.Kurose，“TCP吞吐量建模：一个简单模型及其经验验证”，《ACM SIGCOMM学报》，1998年。
[RFC0889] Mills, D., "Internet delay experiments", RFC 889, December 1983.
[RFC0889]Mills，D.，“互联网延迟实验”，RFC 889，1983年12月。
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC0896]Nagle，J.，“IP/TCP网络中的拥塞控制”，RFC 896，1984年1月。
[RFC0970] Nagle, J., "On packet switches with infinite storage", RFC 970, December 1985.
[RFC0970]Nagle，J.，“具有无限存储的分组交换机”，RFC 970，1985年12月。
[RFC1016] Prue, W. and J. Postel, "Something a host could do with source quench: The Source Quench Introduced Delay (SQuID)", RFC 1016, July 1987.
[RFC1016]Prue，W.和J.Postel，“主机与源猝灭的关系：源猝灭引入延迟（SQuID）”，RFC 1016，1987年7月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1254] Mankin, A. and K. Ramakrishnan, "Gateway Congestion Control Survey", RFC 1254, August 1991.
[RFC1254]Mankin，A.和K.Ramakrishnan，“网关拥塞控制调查”，RFC 1254，1991年8月。
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，B.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC163331994年6月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
[RFC2001]Stevens，W.“TCP慢启动、拥塞避免、快速重传和快速恢复算法”，RFC 2001，1997年1月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140]Touch，J.，“TCP控制块相互依赖”，RFC 2140，1997年4月。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.，和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[RFC2357]Mankin，A.，Romanov，A.，Bradner，S.，和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[RFC2414] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC2414141998年9月。
[RFC2415] Poduri, K., "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415]Poduri，K.，“增加初始TCP窗口大小的模拟研究”，RFC2415，1998年9月。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416]Shepard，T.和C.Partridge，“当TCP启动时，只有四个数据包进入三个缓冲区”，RFC 2416，1998年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[RFC2481]Ramakrishnan，K.和S.Floyd，“向IP添加明确拥塞通知（ECN）的提案”，RFC 2481，1999年1月。
[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月。
[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月。
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks", RFC 2884, July 2000.
[RFC2884]Hadi Salim，J.和U.Ahmed，“IP网络中显式拥塞通知（ECN）的性能评估”，RFC 2884，2000年7月。
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano, L., and M. Luby, "The Reliable Multicast Design Space for Bulk Data Transfer", RFC 2887, August 2000.
[RFC2887]Handley，M.，Floyd，S.，Whetten，B.，Kermode，R.，Vicisano，L.，和M.Luby，“批量数据传输的可靠多播设计空间”，RFC 2887，2000年8月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.
[RFC2998]Bernet，Y.，Ford，P.，Yavatkar，R.，Baker，F.，Zhang，L.，Speer，M.，Braden，R.，Davie，B.，Wroclawski，J.，和E.Felstaine，“区分服务网络上的综合服务运营框架”，RFC 2998，2000年11月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048]Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.，和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124]Balakrishnan，H.和S.Seshan，“拥堵管理者”，RFC31242001年6月。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3135]Border，J.，Kojo，M.，Griner，J.，黑山，G.，和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 31352001年6月。
[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月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208]Speakman，T.，Crowcroft，J.，Gemmell，J.，Farinaci，D.，Lin，S.，Leshchiner，D.，Luby，M.，Montgomery，T.，Rizzo，L.，Tweedy，A.，Bhaskar，N.，Edmonstone，R.，Sumanasekera，R.，和L.Vicisano，“PGM可靠传输协议规范”，RFC 32082001年12月。
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[RFC3366]Fairhurst，G.和L.Wood，“链接自动重复请求（ARQ）对链接设计者的建议”，BCP 62，RFC 3366，2002年8月。
[RFC3426] Floyd, S., "General Architectural and Policy Considerations", RFC 3426, November 2002.
[RFC3426]Floyd，S.，“一般建筑和政策考虑”，RFC 3426，2002年11月。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439]Bush，R.和D.Meyer，“一些互联网架构指南和哲学”，RFC 3439，2002年12月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449]Balakrishnan，H.，Padmanabhan，V.，Fairhurst，G.，和M.Sooriyabandara，“网络路径不对称的TCP性能影响”，BCP 69，RFC 3449，2002年12月。
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 3450, December 2002.
[RFC3450]Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，和J.Crowcroft，“异步分层编码（ALC）协议实例化”，RFC 3450，2002年12月。
[RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", BCP 71, RFC 3481, February 2003.
[RFC3481]Inamura，H.，黑山，G.，路德维希，R.，Gurtov，A.，和F.Khafizov，“第二代（2.5G）和第三代（3G）无线网络上的TCP”，BCP 71，RFC 3481，2003年2月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[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月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738]Luby，M.和V.Goyal，“基于波动和方程的速率控制（WEBRC）构造块”，RFC 3738，2004年4月。
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004.
[RFC3742]Floyd，S.，“具有大拥塞窗口的TCP有限慢启动”，RFC 3742，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月。
[RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement for the Datagram Congestion Control Protocol (DCCP)", RFC 4336, March 2006.
[RFC4336]Floyd，S.，Handley，M.，和E.Kohler，“数据报拥塞控制协议（DCCP）的问题陈述”，RFC 4336，2006年3月。
[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月。
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006.
[RFC4341]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞控制ID 2的配置文件：类似TCP的拥塞控制”，RFC 43412006年3月。
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006.
[RFC4342]Floyd，S.，Kohler，E.，和J.Padhye，“数据报拥塞控制协议（DCCP）拥塞控制ID 3的配置文件：TCP友好速率控制（TFRC）”，RFC 43422006年3月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]Duke，M.，Braden，R.，Eddy，W.，和E.Blanton，“传输控制协议（TCP）规范文件路线图”，RFC 46142006年9月。
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification", RFC 4654, August 2006.
[RFC4654]Widmer，J.和M.Handley，“TCP友好多播拥塞控制（TFMCC）：协议规范”，RFC 4654，2006年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月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, August 2007.
[RFC5033]Floyd，S.和M.Allman，“指定新的拥塞控制算法”，BCP 133，RFC 5033，2007年8月。
[RFC5166] Floyd, S., "Metrics for the Evaluation of Congestion Control Mechanisms", RFC 5166, March 2008.
[RFC5166]Floyd，S.，“拥塞控制机制评估指标”，RFC 5166，2008年3月。
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008.
[RFC5348]Floyd，S.，Handley，M.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 5348，2008年9月。
Authors' Addresses
作者地址
Michael Welzl University of Oslo Department of Informatics PO Box 1080 Blindern N-0316 Oslo, Norway
米迦勒WelZl奥斯陆大学信息学系PO盒1080盲板N-0316奥斯陆，挪威
Phone: +47 22 85 24 20
EMail: michawe@ifi.uio.no
Phone: +47 22 85 24 20
EMail: michawe@ifi.uio.no
Wesley M. Eddy MTI Systems NASA Glenn Research Center 21000 Brookpark Rd, MS 500-ASRC Cleveland, OH 44135
卫斯理M.艾迪MTI系统美国宇航局格伦研究中心，密歇根州布鲁克公园路21000号，俄亥俄州克利夫兰市ASRC，邮编：44135
Phone: (216) 433-6682 EMail: wes@mti-systems.com
电话：（216）433-6682电子邮件：wes@mti-系统网