Internet Research Task Force (IRTF) D. Papadimitriou, Ed.
Request for Comments: 6077 Alcatel-Lucent
Category: Informational M. Welzl
ISSN: 2070-1721 University of Oslo
M. Scharf
University of Stuttgart
B. Briscoe
BT & UCL
February 2011
Internet Research Task Force (IRTF) D. Papadimitriou, Ed.
Request for Comments: 6077 Alcatel-Lucent
Category: Informational M. Welzl
ISSN: 2070-1721 University of Oslo
M. Scharf
University of Stuttgart
B. Briscoe
BT & UCL
February 2011
Open Research Issues in Internet Congestion Control
Internet拥塞控制中的开放性研究问题
Abstract
摘要
This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed.
本文档描述了目前已知的Internet拥塞控制中的一些公开问题。这包括随着网络的发展而变得越来越重要的几个新挑战，以及多年来已知的一些问题。这些挑战通常被认为是开放的研究课题，可能需要更多的研究或创新技术的应用，然后才能自信地设计和部署互联网规模的解决方案。
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 (ICCRG) 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）互联网拥塞控制研究小组（ICCRG）的共识。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/rfc6077.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6077.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Global Challenges ...............................................5
2.1. Heterogeneity ..............................................5
2.2. Stability ..................................................7
2.3. Fairness ...................................................8
3. Detailed Challenges ............................................10
3.1. Challenge 1: Network Support ..............................10
3.1.1. Performance and Robustness .........................14
3.1.2. Granularity of Network Component Functions .........15
3.1.3. Information Acquisition ............................16
3.1.4. Feedback Signaling .................................17
3.2. Challenge 2: Corruption Loss ..............................17
3.3. Challenge 3: Packet Size ..................................19
3.4. Challenge 4: Flow Startup .................................24
3.5. Challenge 5: Multi-Domain Congestion Control ..............26
3.5.1. Multi-Domain Transport of Explicit
Congestion Notification ............................26
3.5.2. Multi-Domain Exchange of Topology or
Explicit Rate Information ..........................27
3.5.3. Multi-Domain Pseudowires ...........................28
3.6. Challenge 6: Precedence for Elastic Traffic ...............30
3.7. Challenge 7: Misbehaving Senders and Receivers ............31
3.8. Other Challenges ..........................................33
3.8.1. RTT Estimation .....................................33
3.8.2. Malfunctioning Devices .............................35
3.8.3. Dependence on RTT ..................................36
3.8.4. Congestion Control in Multi-Layered Networks .......36
3.8.5. Multipath End-to-End Congestion Control and
Traffic Engineering ................................37
3.8.6. ALGs and Middleboxes ...............................37
4. Security Considerations ........................................38
5. References .....................................................39
5.1. Informative References ....................................39
6. Acknowledgments ................................................50
7. Contributors ...................................................50
1. Introduction ....................................................3
2. Global Challenges ...............................................5
2.1. Heterogeneity ..............................................5
2.2. Stability ..................................................7
2.3. Fairness ...................................................8
3. Detailed Challenges ............................................10
3.1. Challenge 1: Network Support ..............................10
3.1.1. Performance and Robustness .........................14
3.1.2. Granularity of Network Component Functions .........15
3.1.3. Information Acquisition ............................16
3.1.4. Feedback Signaling .................................17
3.2. Challenge 2: Corruption Loss ..............................17
3.3. Challenge 3: Packet Size ..................................19
3.4. Challenge 4: Flow Startup .................................24
3.5. Challenge 5: Multi-Domain Congestion Control ..............26
3.5.1. Multi-Domain Transport of Explicit
Congestion Notification ............................26
3.5.2. Multi-Domain Exchange of Topology or
Explicit Rate Information ..........................27
3.5.3. Multi-Domain Pseudowires ...........................28
3.6. Challenge 6: Precedence for Elastic Traffic ...............30
3.7. Challenge 7: Misbehaving Senders and Receivers ............31
3.8. Other Challenges ..........................................33
3.8.1. RTT Estimation .....................................33
3.8.2. Malfunctioning Devices .............................35
3.8.3. Dependence on RTT ..................................36
3.8.4. Congestion Control in Multi-Layered Networks .......36
3.8.5. Multipath End-to-End Congestion Control and
Traffic Engineering ................................37
3.8.6. ALGs and Middleboxes ...............................37
4. Security Considerations ........................................38
5. References .....................................................39
5.1. Informative References ....................................39
6. Acknowledgments ................................................50
7. Contributors ...................................................50
This document, the result of the Internet Congestion Control Research Group (ICCRG), describes some of the open research topics in the domain of Internet congestion control that are known today. We begin by reviewing some proposed definitions of congestion and congestion control based on current understandings.
本文件是互联网拥塞控制研究小组（ICCRG）的成果，描述了目前已知的互联网拥塞控制领域的一些开放性研究主题。我们首先回顾了一些基于当前理解提出的拥塞和拥塞控制的定义。
Congestion can be defined as a state or condition that occurs when network resources are overloaded, resulting in impairments for network users as objectively measured by the probability of loss and/or delay. The overload results in the reduction of utility in networks that support both spatial and temporal multiplexing, but no reservation [Keshav07]. Congestion control is a (typically distributed) algorithm to share network resources among competing traffic sources.
拥塞可以定义为当网络资源过载时发生的一种状态或状况，通过丢失和/或延迟的概率客观地衡量网络用户的损害。过载导致支持空间和时间复用但无保留的网络中的效用降低[Keshav07]。拥塞控制是一种（典型的分布式）算法，用于在竞争流量源之间共享网络资源。
Two components of distributed congestion control have been defined in the context of primal-dual modeling [Kelly98]. Primal congestion control refers to the algorithm executed by the traffic sources for controlling their sending rates or window sizes. This is normally a closed-loop control, where this operation depends on feedback. TCP algorithms fall in this category. Dual congestion control is implemented by the routers through gathering information about the traffic traversing them. A dual congestion control algorithm updates, implicitly or explicitly, a congestion measure or congestion rate and sends it back, implicitly or explicitly, to the traffic sources that use that link. Queue management algorithms such as Random Early Detection (RED) [Floyd93] or Random Exponential Marking (REM) [Ath01] fall into the "dual" category.
分布式拥塞控制的两个组成部分是在原始-对偶建模的背景下定义的[Kelly98]。原始拥塞控制是指由业务源执行的算法，用于控制其发送速率或窗口大小。这通常是一个闭环控制，该操作取决于反馈。TCP算法属于这一类。路由器通过收集穿越它们的流量信息来实现双重拥塞控制。双拥塞控制算法隐式或显式地更新拥塞度量或拥塞率，并隐式或显式地将其发送回使用该链路的流量源。诸如随机早期检测（RED）[Floyd93]或随机指数标记（REM）[Ath01]之类的队列管理算法属于“双重”类别。
Congestion control provides for a fundamental set of mechanisms for maintaining the stability and efficiency of the Internet. Congestion control has been associated with TCP since Van Jacobson's work in 1988, but there is also congestion control outside of TCP (e.g., for real-time multimedia applications, multicast, and router-based mechanisms) [RFC5783]. The Van Jacobson end-to-end congestion control algorithms [Jacobson88] [RFC2581] [RFC5681] are used by the Internet transport protocol TCP [RFC4614]. They have been proven to be highly successful over many years but have begun to reach their limits, as the heterogeneity of the data link and physical layer on the one hand, and of applications on the other, are pulling TCP congestion control beyond its natural operating regime. This is because it performs poorly as the bandwidth or delay increases. A side effect of these deficiencies is that an increasing share of hosts use non-standardized congestion control enhancements (for instance, many Linux distributions have been shipped with "CUBIC" [Ha08] as the default TCP congestion control mechanism).
拥塞控制为维护互联网的稳定性和效率提供了一套基本的机制。自1988年Van Jacobson的工作以来，拥塞控制一直与TCP相关，但TCP之外也有拥塞控制（例如，用于实时多媒体应用、多播和基于路由器的机制）[RFC5783]。互联网传输协议TCP[RFC4614]使用Van Jacobson端到端拥塞控制算法[Jacobson88][RFC2581][RFC5681]。多年来，它们已被证明非常成功，但已开始达到极限，因为数据链路和物理层的异构性以及应用程序的异构性正在将TCP拥塞控制拉到其自然运行机制之外。这是因为随着带宽或延迟的增加，它的性能很差。这些缺陷的一个副作用是，越来越多的主机使用非标准化的拥塞控制增强功能（例如，许多Linux发行版都附带了“CUBIC”[Ha08]作为默认TCP拥塞控制机制）。
While the original Van Jacobson algorithm requires no congestion-related state in routers, more recent modifications have departed from the strict application of the end-to-end principle [Saltzer84] in order to avoid congestion collapse. Active Queue Management (AQM) in routers, e.g., RED and some of its variants such as Adaptive RED (ARED), improves performance by keeping queues small (implicit feedback via dropped packets), while Explicit Congestion Notification
虽然最初的Van Jacobson算法不需要路由器中与拥塞相关的状态，但最近的修改已经偏离了严格应用端到端原则[Saltzer84]，以避免拥塞崩溃。路由器中的主动队列管理（AQM），例如RED及其一些变体，如自适应RED（ARED），通过保持队列较小（通过丢弃的数据包进行隐式反馈），而显式拥塞通知，提高了性能
(ECN) [Floyd94] [RFC3168] passes one bit of congestion information back to senders when an AQM would normally drop a packet. It is to be noted that other variants of RED built on AQM, such as Weighted RED (WRED) and RED with In/Out (RIO) [Clark98] are for quality enforcement, whereas Stabilized RED (SRED), and CHOKe [Pan00] and its extensions such as XCHOKe [Chhabra02], are flow policers. In [Bonald00], authors analytically evaluated RED performance.
（ECN）[Floyd94][RFC3168]在AQM通常会丢弃数据包时，将一位拥塞信息传递回发送方。需要注意的是，基于AQM构建的其他RED变体，如加权RED（WRED）和带输入/输出的RED（RIO）[Clark98]用于质量强制，而稳定RED（SRED）和扼流[Pan00]及其扩展（如XCHOKe[Chhabra02]）则是流量警察。在[Bonald00]中，作者分析评估了RED性能。
These measures do improve performance, but there is a limit to how much can be accomplished without more information from routers. The requirement of extreme scalability together with robustness has been a difficult hurdle for acceleration of this information flow. Primal-dual TCP/AQM distributed algorithm stability and equilibrium properties have been extensively studied (cf. [Low02], [Low03.1], [Low03.2], [Kelly98], and [Kelly05]).
这些措施确实提高了性能，但如果没有来自路由器的更多信息，可以完成的工作是有限的。极端可扩展性和健壮性的要求一直是加速这种信息流的一个困难障碍。原始-对偶TCP/AQM分布式算法的稳定性和平衡性已经得到了广泛的研究（参见[Low02]、[Low03.1]、[Low03.2]、[Kelly98]和[Kelly05]）。
Congestion control includes many new challenges that are becoming important as the network grows, in addition to the issues that have been known for many years. These are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed. In what follows, an overview of some of these challenges is given.
拥塞控制包括许多新的挑战，这些挑战随着网络的发展变得越来越重要，此外还有许多多年来一直存在的问题。这些通常被认为是开放的研究课题，可能需要更多的研究或创新技术的应用，才能自信地设计和部署互联网规模的解决方案。下文概述了其中一些挑战。
This section describes the global challenges to be addressed in the domain of Internet congestion control.
本节描述了在互联网拥塞控制领域需要解决的全球挑战。
The Internet encompasses a large variety of heterogeneous IP networks that are realized by a multitude of technologies, which result in a tremendous variety of link and path characteristics: capacity can be either scarce in very-slow-speed radio links (several kbps), or there may be an abundant supply in high-speed optical links (several gigabit per second). Concerning latency, scenarios range from local interconnects (much less than a millisecond) to certain wireless and satellite links with very large latencies up to or over a second). Even higher latencies can occur in space communication. As a consequence, both the available bandwidth and the end-to-end delay in the Internet may vary over many orders of magnitude, and it is likely that the range of parameters will further increase in the future.
Internet包含大量由多种技术实现的异构IP网络，这导致了各种各样的链路和路径特性：在非常低速的无线链路（几kbps）中，容量可能很稀少，或者高速光链路中可能有大量的供应（每秒数千兆位）。关于延迟，场景范围从本地互连（远小于一毫秒）到某些无线和卫星链路（延迟高达或超过一秒）。在空间通信中甚至可能出现更高的延迟。因此，互联网中的可用带宽和端到端延迟可能会在许多数量级上发生变化，未来参数范围可能会进一步扩大。
Additionally, neither the available bandwidth nor the end-to-end delay is constant. At the IP layer, competing cross-traffic, traffic management in routers, and dynamic routing can result in sudden changes in the characteristics of an end-to-end path. Additional
此外，可用带宽和端到端延迟都不是常数。在IP层，相互竞争的交叉流量、路由器中的流量管理和动态路由可能导致端到端路径特性的突然变化。附加的
dynamics can be caused by link layer mechanisms, such as shared-media access (e.g., in wireless networks), changes to new links due to mobility (horizontal/vertical handovers), topology modifications (e.g., in ad hoc or meshed networks), link layer error correction, and dynamic bandwidth provisioning schemes. From this, it follows that path characteristics can be subject to substantial changes within short time frames.
动态可由链路层机制引起，例如共享媒体接入（例如，在无线网络中）、由于移动性（水平/垂直切换）对新链路的更改、拓扑修改（例如，在自组织或网状网络中）、链路层纠错和动态带宽供应方案。由此可知，路径特征可在短时间内发生实质性变化。
Congestion control algorithms have to deal with this variety in an efficient and stable way. The congestion control principles introduced by Van Jacobson assume a rather static scenario and implicitly target configurations where the bandwidth-delay product is of the order of some dozens of packets at most. While these principles have proved to work in the Internet for almost two decades, much larger bandwidth-delay products and increased dynamics challenge them more and more. There are many situations where today's congestion control algorithms react in a suboptimal way, resulting, among other things, in low resource utilization.
拥塞控制算法必须以高效和稳定的方式处理这种变化。Van Jacobson介绍的拥塞控制原理假设了一个相当静态的场景，并隐式地针对带宽延迟乘积最多为几十个数据包的配置。虽然这些原则在互联网上已经被证明有效了近二十年，但更大的带宽延迟产品和更高的动态性对它们提出了越来越大的挑战。在许多情况下，今天的拥塞控制算法的反应都不理想，导致资源利用率低下。
This has resulted in a multitude of new proposals for congestion control algorithms. For instance, since the Additive Increase Multiplicative Decrease (AIMD) behavior of TCP is too conservative in practical environments when the congestion window is large, several high-speed congestion control extensions have been developed. However, these new algorithms may be less robust or starve legacy flows in certain situations for which they have not been designed. At the time of writing, there is no common agreement in the IETF on which algorithm(s) and protocol(s) to choose.
这就产生了大量关于拥塞控制算法的新建议。例如，由于在实际环境中，当拥塞窗口较大时，TCP的加法-递增-乘法-递减（AIMD）行为过于保守，因此开发了几种高速拥塞控制扩展。然而，这些新算法可能不那么健壮，或者在某些情况下无法满足遗留流的需求，而这些情况并不是为这些算法设计的。在撰写本文时，IETF中没有关于选择哪种算法和协议的共同协议。
It is always possible to tune congestion control parameters based on some knowledge of the environment and the application scenario. However, the interaction between multiple congestion control techniques is not yet well understood. The fundamental challenge is whether it is possible to define one congestion control mechanism that operates reasonably well in a whole range of scenarios that exist in the Internet. Hence, important research questions are how new Internet congestion control mechanisms would have to be designed, which maximum degree of dynamics they can efficiently handle, and whether they can keep the generality of the existing end-to-end solutions.
根据对环境和应用场景的一些了解，始终可以调整拥塞控制参数。然而，多种拥塞控制技术之间的相互作用还没有得到很好的理解。根本的挑战是，是否有可能定义一种在互联网上存在的各种场景中运行良好的拥塞控制机制。因此，重要的研究问题是如何设计新的互联网拥塞控制机制，它们能够有效处理的最大程度的动态，以及它们是否能够保持现有端到端解决方案的通用性。
Some improvements to congestion control could be realized by simple changes to single functions in end-systems or optimizations of network components. However, new mechanism(s) might also require a fundamental redesign of the overall network architecture, and they may even affect the design of Internet applications. This can imply significant interoperability and backward compatibility challenges and/or create network accessibility obstacles. In particular,
通过对终端系统中单个功能的简单更改或网络组件的优化，可以实现对拥塞控制的一些改进。然而，新的机制也可能需要对整个网络架构进行根本性的重新设计，甚至可能影响互联网应用程序的设计。这可能意味着巨大的互操作性和向后兼容性挑战和/或造成网络可访问性障碍。特别地，
networks and/or applications that do not use or support a new congestion control mechanism could be penalized by a significantly worse performance compared to what they would get if everybody used the existing mechanisms (cf. the discussion on fairness in Section 2.3). [RFC5033] defines several criteria to evaluate the appropriateness of a new congestion control mechanism. However, a key issue is how much performance deterioration is acceptable for "legacy" applications. This tradeoff between performance and cost has to be very carefully examined for all new congestion control schemes.
与每个人都使用现有机制相比，不使用或不支持新拥塞控制机制的网络和/或应用程序的性能可能会显著降低（参见第2.3节中关于公平性的讨论）。[RFC5033]定义了几个标准来评估新拥塞控制机制的适当性。然而，一个关键问题是“遗留”应用程序的性能恶化程度是可以接受的。对于所有新的拥塞控制方案，必须非常仔细地检查性能和成本之间的权衡。
Control theory is a mathematical tool for describing dynamic systems. It lends itself to modeling congestion control -- TCP is a perfect example of a typical "closed loop" system that can be described in control theoretic terms. However, control theory has had to be extended to model the interactions between multiple control loops in a network [Vinnic02]. In control theory, there is a mathematically defined notion of system stability. In a stable system, for any bounded input over any amount of time, the output will also be bounded. For congestion control, what is actually meant by global stability is typically asymptotic stability: a mechanism should converge to a certain state irrespective of the initial state of the network. Local stability means that if the system is perturbed from its stable state it will quickly return toward the locally stable state.
控制理论是描述动态系统的数学工具。它有助于对拥塞控制进行建模——TCP是一个典型的“闭环”系统的完美例子，可以用控制理论的术语来描述。然而，必须扩展控制理论，以模拟网络中多个控制回路之间的相互作用[Vinnic02]。在控制理论中，有一个数学定义的系统稳定性概念。在一个稳定的系统中，对于任意时间内的任何有界输入，输出也将有界。对于拥塞控制，全局稳定性实际上是指典型的渐近稳定性：无论网络的初始状态如何，机制都应收敛到某一状态。局部稳定性意味着，如果系统从其稳定状态受到扰动，它将迅速返回到局部稳定状态。
Some fundamental facts known from control theory are useful as guidelines when designing a congestion control mechanism. For instance, a controller should only be fed a system state that reflects its output. A (low-pass) filter function should be used in order to pass to the controller only states that are expected to last long enough for its action to be meaningful [Jain88]. Action should be carried out whenever such feedback arrives, as it is a fundamental principle of control that the control frequency should ideally be equal to the feedback frequency. Reacting faster leads to oscillations and instability, while reacting more slowly makes the system tardy [Jain90].
在设计拥塞控制机制时，控制理论中的一些基本事实可以作为指导。例如，一个控制器应该只提供反映其输出的系统状态。应使用（低通）滤波器功能，以便仅将预期持续足够长时间的状态传递给控制器，使其动作有意义[Jain88]。当此类反馈到达时，应采取措施，因为控制频率理想情况下应等于反馈频率是控制的基本原则。反应速度越快，会导致振荡和不稳定，而反应速度越慢，则会使系统变得迟钝[Jain90]。
Control theoretic modeling of a realistic network can be quite difficult, especially when taking distinct packet sizes and heterogeneous round-trip times (RTTs) into account. It has therefore become common practice to model simpler cases and to leave the more complicated (realistic) situations for simulations. Clearly, if a mechanism is not stable in a simple scenario, it is generally useless; this method therefore helps to eliminate faulty congestion control candidates at an early stage. However, a mechanism that is
现实网络的控制理论建模可能相当困难，特别是当考虑到不同的数据包大小和异构往返时间（RTT）时。因此，对更简单的情况建模并将更复杂（现实）的情况留待模拟已成为普遍做法。显然，如果一个机制在一个简单的场景中不稳定，它通常是无用的；因此，这种方法有助于在早期阶段消除错误的拥塞控制候选者。然而，一种机制是
found to be stable in simulations can still not be safely deployed in real networks, since simulation scenarios make simplifying assumptions.
在模拟中被发现是稳定的，但仍然不能安全地部署在实际网络中，因为模拟场景会简化假设。
TCP stability can be attributed to two key aspects that were introduced in [Jacobson88]: the AIMD control law during congestion avoidance, which is based on a simple, vector-based analysis of two controllers sharing one resource with synchronous RTTs [Chiu89]; and the "conservation of packets principle", which, once the control has reached "steady state", tries to maintain an equal amount of packets in flight at any time by only sending a packet into the network when a packet has left the network (as indicated by an ACK arriving at the sender). The latter aspect has guided many decisions regarding changes that were made to TCP over the years.
TCP稳定性可归因于[Jacobson88]中介绍的两个关键方面：拥塞避免期间的AIMD控制律，其基于对与同步RTT共享一个资源的两个控制器的简单矢量分析[Chiu89]；以及“数据包守恒原理”，一旦控制达到“稳定状态”，它试图通过在数据包离开网络时仅向网络发送数据包（如到达发送方的ACK所示），在任何时候保持等量的数据包飞行。后一个方面指导了多年来对TCP所做更改的许多决策。
The reasoning in [Jacobson88] assumes all senders to be acting at the same time. The stability of TCP under more realistic network conditions has been investigated in a large number of ensuing works, leading to no clear conclusion that TCP would also be asymptotically stable under arbitrary network conditions. On the other hand, research has concluded that stability can be assured with constraints on dynamics that are less stringent than the "conservation of packets principle". From control theory, only rate increase (not the target rate) needs to be inversely proportional to RTT (whereas window-based control converges on a target rate inversely proportional to RTT). A congestion control mechanism can therefore converge on a rate that is independent of RTT as long as its dynamics depend on RTT (e.g., FAST TCP [Jin04]).
[Jacobson88]中的推理假设所有发送者同时行动。在随后的大量工作中，研究了TCP在更现实的网络条件下的稳定性，没有明确的结论表明TCP在任意网络条件下也是渐近稳定的。另一方面，研究得出的结论是，与“数据包守恒原则”相比，动力学约束的严格程度较低，可以确保稳定性。根据控制理论，只有速率增加（而不是目标速率）需要与RTT成反比（而基于窗口的控制收敛于与RTT成反比的目标速率）。因此，拥塞控制机制可以收敛于与RTT无关的速率，只要其动力学依赖于RTT（例如，快速TCP[Jin04]）。
In the stability analysis of TCP and of these more modern controls, the impact of slow-start on stability (which can be significant as short-lived HTTP flows often never leave this phase) is not entirely clear.
在TCP和这些更现代的控件的稳定性分析中，慢启动对稳定性的影响（这可能非常重要，因为短命HTTP流通常不会离开此阶段）并不完全清楚。
Recently, the way the Internet community reasons about fairness has been called deeply into question [Bri07]. Much of the community has taken fairness to mean approximate equality between the rates of flows (flow rate fairness) that experience equivalent path congestion as with TCP [RFC2581] [RFC5681] and TCP-Friendly Rate Control (TFRC) [RFC5348]. [RFC3714] depicts the resulting situation as "The Amorphous Problem of Fairness".
最近，互联网社区对公平的思考方式受到了深刻的质疑[Bri07]。大部分社区将公平性视为与TCP[RFC2581][RFC5681]和TCP友好速率控制（TFRC）[RFC5348]具有同等路径拥塞的流量（流量公平性）之间的近似相等。[RFC3714]将由此产生的情况描述为“无定形的公平问题”。
A parallel tradition has been built on [Kelly98] where, as long as each user is accountable for the cost their rate causes to others [MacK95], the set of rates that everyone chooses is deemed fair (cost fairness) -- because with any other set of choices people would lose more value than they gained overall.
在[Kelly98]的基础上建立了一个类似的传统，只要每个用户都对自己的费率给他人造成的成本负责[MacK95]，每个人选择的费率集就被认为是公平的（成本公平）——因为在任何其他选择集中，人们损失的价值将大于他们获得的整体价值。
In comparison, the debate between max-min, proportional, and TCP fairness is about mere details. These three all share the assumption that equal flow rates are desirable; they merely differ in the second-order issue of how to share out excess capacity in a network of many bottlenecks. In contrast, cost fairness should lead to extremely unequal flow rates by design. Equivalently, equal flow rates would typically be considered extremely unfair.
相比之下，max-min、proportional和TCP公平性之间的争论只涉及细节。这三者都有相同的假设，即需要相等的流速；它们只是在如何在一个由许多瓶颈组成的网络中分担过剩容量的第二个问题上有所不同。相比之下，成本公平性应导致设计流量极不平等。同样地，相等的流速通常被认为是极不公平的。
The two traditional approaches are not protocol options that can each be followed in different parts of an internetwork. They lead to research agendas that are different in their respective objectives, resulting in a different set of open issues.
这两种传统方法并不是在互联网的不同部分都可以遵循的协议选项。它们导致的研究议程在各自的目标上有所不同，导致了一系列不同的开放性问题。
If we assume TCP-friendliness as a goal with flow rate as the metric, open issues would be:
如果我们以TCP友好性为目标，以流量为衡量标准，则未决问题将是：
- Should flow fairness depend on the packet rate or the bit rate?
- 流公平性应该取决于数据包速率还是比特率？
- Should the target flow rate depend on RTT (as in TCP) or should only flow dynamics depend on RTT (e.g., as in FAST TCP [Jin04])?
- 目标流量应该取决于RTT（如TCP）还是只取决于RTT（如FAST TCP[Jin04]）？
- How should we estimate whether a particular flow start strategy is fair, or whether a particular fast recovery strategy after a reduction in rate due to congestion is fair?
- 我们应该如何估计特定的流启动策略是否公平，或者在由于拥塞而降低速率后的特定快速恢复策略是否公平？
- Should we judge what is reasonably fair if an application needs, for example, even smoother flows than TFRC, or it needs to burst occasionally, or with any other application behavior?
- 例如，如果一个应用程序需要比TFRC更平滑的流，或者它偶尔需要突发，或者任何其他应用程序行为，我们是否应该判断什么是合理的公平？
- During brief congestion bursts (e.g., due to new flow arrivals), how should we judge at what point it becomes unfair for some flows to continue at a smooth rate while others reduce their rate?
- 在短暂的拥堵爆发期间（例如，由于新流量的到来），我们应该如何判断在什么情况下，某些流量以平稳的速度继续，而另一些流量则降低其速度变得不公平？
- Which mechanism(s) could be used to enforce approximate flow rate fairness?
- 哪种机制可用于实施近似流量公平性？
- Should we introduce some degree of fairness that takes into account different users' flow activity over time?
- 我们是否应该引入某种程度的公平性，以考虑不同用户随时间的流量活动？
- How should we judge the fairness of applications using a large number of flows over separate paths (e.g., via an overlay)?
- 我们应该如何判断在不同路径（例如，通过覆盖）上使用大量流的应用程序的公平性？
If we assume cost fairness as a goal with congestion-volume as the metric, open issues would be:
如果我们将成本公平性作为一个目标，以拥堵量作为衡量标准，则未决问题将是：
- Can one application's sensitivity to instantaneous congestion really be protected by longer-term accountability of competing applications?
- 一个应用程序对瞬时拥塞的敏感性真的可以通过竞争应用程序的长期责任来保护吗？
- Which protocol mechanism(s) are needed to give accountability for causing congestion?
- 需要哪种协议机制来说明造成拥塞的原因？
- How might we design one or two weighted transport protocols (such as TCP, UDP, etc.) with the addition of application policy control over the weight?
- 我们如何设计一个或两个加权传输协议（如TCP、UDP等），并添加对权重的应用程序策略控制？
- Which policy enforcement might be used by networks, and what are the interactions between application policy and network policy enforcement?
- 网络可能使用哪些策略实施，应用程序策略和网络策略实施之间的交互是什么？
- How should we design a new policy enforcement framework that will appropriately compete with existing flows aiming for rate equality (e.g., TCP)?
- 我们应该如何设计一个新的策略实施框架，与现有的旨在实现速率平等的流（如TCP）进行适当的竞争？
The question of how to reason about fairness is a prerequisite to agreeing on the research agenda. If the relevant metric is flow rate, it places constraints at protocol design time, whereas if the metric is congestion-volume, the constraints move to run-time while design-time constraints can be relaxed [Bri08]. However, that question does not require more research in itself; it is merely a debate that needs to be resolved by studying existing research and by assessing how bad fairness problems could become if they are not addressed rigorously, and whether we can rely on trust to maintain approximate fairness without requiring policing complexity [RFC5290]. The latter points may themselves lead to additional research. However, it is also accepted that more research will not necessarily lead to convincing either side to change their opinions. More debate would be needed. It seems also that if the architecture is built to support cost fairness, then equal instantaneous cost rates for flows sharing a bottleneck result in flow-rate fairness; that is, flow-rate fairness can be seen as a special case of cost fairness. One can be used to build the other, but not vice-versa.
如何对公平性进行推理的问题是就研究议程达成一致的先决条件。如果相关指标是流量，则在协议设计时设置约束，而如果指标是拥塞量，则约束移动到运行时，而设计时约束可以放松[Bri08]。然而，这个问题本身并不需要更多的研究；这仅仅是一个需要通过研究现有研究和评估如果不严格解决公平问题会变得多么糟糕，以及我们是否可以依靠信任来维持近似的公平而不需要复杂的警务来解决的争论[RFC5290]。后几点本身可能导致额外的研究。然而，人们也承认，更多的研究不一定能说服任何一方改变他们的观点。需要更多的辩论。同样，如果构建的体系结构支持成本公平性，那么共享瓶颈的流的相等瞬时成本率将导致流量公平性；也就是说，流量公平可以看作是成本公平的特例。一个可以用来构建另一个，但反之亦然。
This challenge is perhaps the most critical to get right. Changes to the balance of functions between the endpoints and network equipment could require a change to the per-datagram data plane interface
这一挑战也许是最关键的。改变端点和网络设备之间的功能平衡可能需要改变每数据报数据平面接口
between the transport and network layers. Network equipment vendors need to be assured that any new interface is stable enough (on decade timescales) to build into firmware and hardware, and operating-system vendors will not use a new interface unless it is likely to be widely deployed.
在传输层和网络层之间。网络设备供应商需要确保任何新接口都足够稳定（在十年的时间尺度上），可以内置到固件和硬件中，并且操作系统供应商不会使用新接口，除非它可能被广泛部署。
Network components can be involved in congestion control in two ways: first, they can implicitly optimize their functions, such as queue management and scheduling strategies, in order to support the operation of end-to-end congestion control. Second, network components can participate in congestion control via explicit signaling mechanisms. Explicit signaling mechanisms, whether in-band or out-of-band, require a communication between network components and end-systems. Signals realized within or over the IP layer are only meaningful to network components that process IP packets. This always includes routers and potentially also middleboxes, but not pure link layer devices. The following section distinguishes clearly between the term "network component" and the term "router"; the term "router" is used whenever the processing of IP packets is explicitly required. One fundamental challenge of network-supported congestion control is that typically not all network components along a path are routers (cf. Section 3.1.3).
网络组件可以通过两种方式参与拥塞控制：首先，它们可以隐式优化其功能，如队列管理和调度策略，以支持端到端拥塞控制的操作。其次，网络组件可以通过显式信令机制参与拥塞控制。显式信令机制，无论是带内还是带外，都需要网络组件和终端系统之间的通信。在IP层内或IP层上实现的信号仅对处理IP数据包的网络组件有意义。这通常包括路由器和潜在的中间盒，但不包括纯链路层设备。以下章节明确区分术语“网络组件”和术语“路由器”；只要明确要求处理IP数据包，就使用术语“路由器”。网络支持的拥塞控制的一个基本挑战是，通常不是一条路径上的所有网络组件都是路由器（参见第3.1.3节）。
The first (optimizing) category of implicit mechanisms can be implemented in any network component that processes and stores packets. Various approaches have been proposed and also deployed, such as different AQM techniques. Even though these implicit techniques are known to improve network performance during congestion phases, they are still only partly deployed in the Internet. This may be due to the fact that finding optimal and robust parameterizations for these mechanisms is a non-trivial problem. Indeed, the problem with various AQM schemes is the difficulty in identifying correct values of the parameters that affect the performance of the queuing scheme (due to variation in the number of sources, the capacity, and the feedback delay) [Firoiu00] [Hollot01] [Zhang03]. Many AQM schemes (RED, REM, BLUE, and PI-Controller, but also Adaptive Virtual Queue (AVQ)) do not define a systematic rule for setting their parameters.
隐式机制的第一类（优化）可以在处理和存储数据包的任何网络组件中实现。已经提出并部署了各种方法，例如不同的AQM技术。尽管已知这些隐式技术可以在拥塞阶段改善网络性能，但它们仍仅部分部署在Internet中。这可能是因为为这些机制寻找最佳和稳健的参数化是一个非常重要的问题。事实上，各种AQM方案的问题在于难以识别影响排队方案性能的参数的正确值（由于信源数量、容量和反馈延迟的变化）[Firoiu00][Hollot01][Zhang03]。许多AQM方案（RED、REM、BLUE和PI控制器，以及自适应虚拟队列（AVQ））没有定义设置其参数的系统规则。
The second class of approaches uses explicit signaling. By using explicit feedback from the network, connection endpoints can obtain more accurate information about the current network characteristics on the path. This allows endpoints to make more precise decisions that can better control congestion.
第二类方法使用显式信令。通过使用来自网络的显式反馈，连接端点可以获得关于路径上当前网络特征的更准确信息。这允许端点做出更精确的决策，从而更好地控制拥塞。
Explicit feedback techniques fall into three broad categories:
明确反馈技术可分为三大类：
- Explicit congestion feedback: one-bit Explicit Congestion Notification (ECN) [RFC3168] or proposals for more than one bit [Xia05];
- 显式拥塞反馈：一位显式拥塞通知（ECN）[RFC3168]或一位以上的建议[Xia05]；
- Explicit per-datagram rate feedback: the eXplicit Control Protocol (XCP) [Katabi02] [Falk07], or the Rate Control Protocol (RCP) [Dukki05];
- 显式每数据报速率反馈：显式控制协议（XCP）[Katabi02][Falk07]或速率控制协议（RCP）[Dukki05]；
- Explicit rate feedback: by means of in-band signaling, such as by Quick-Start [RFC4782], or by means of out-of-band signaling, e.g., Congestion Avoidance with Distributed Proportional Control/Performance Transparency Protocol (CADPC/PTP) [Welzl03].
- 显式速率反馈：通过带内信令，例如通过快速启动[RFC4782]，或通过带外信令，例如通过分布式比例控制/性能透明协议（CADPC/PTP）避免拥塞[Welzl03]。
Explicit router feedback can address some of the inherent shortcomings of TCP. For instance, XCP was developed to overcome the inefficiency and instability that TCP suffers from when the per-flow bandwidth-delay product increases. By decoupling resource utilization/congestion control from fairness control, XCP achieves equal bandwidth allocation, high utilization, a small standing queue size, and near-zero packet drops, with both steady and highly varying traffic. Importantly, XCP does not maintain any per-flow state in routers and requires few CPU cycles per packet, hence making it potentially applicable in high-speed routers. However, XCP is still subject to research: as [Andrew05] has pointed out, XCP is locally stable but globally unstable when the maximum RTT of a flow is much larger than the mean RTT. This instability can be removed by changing the update strategy for the estimation interval, but this makes the system vulnerable to erroneous RTT advertisements. The authors of [Pap02] have shown that when flows with different RTTs are applied, XCP sometimes discriminates among heterogeneous traffic flows, even if XCP generally equalizes rates among different flows. [Low05] provides for a complete characterization of the XCP equilibrium properties.
明确的路由器反馈可以解决TCP固有的一些缺点。例如，开发XCP是为了克服TCP在每流带宽延迟乘积增加时的低效性和不稳定性。通过将资源利用率/拥塞控制与公平性控制解耦，XCP实现了同等带宽分配、高利用率、较小的固定队列大小和接近零的丢包，同时具有稳定和高度变化的流量。重要的是，XCP在路由器中不保持任何每流状态，并且每个数据包需要很少的CPU周期，因此它可能适用于高速路由器。然而，XCP仍有待研究：正如[Andrew05]所指出的，当流量的最大RTT远大于平均RTT时，XCP是局部稳定的，但全局不稳定。这种不稳定性可以通过改变估计间隔的更新策略来消除，但这使得系统容易受到错误RTT广告的影响。[Pap02]的作者已经表明，当应用具有不同RTT的流时，即使XCP通常均衡不同流之间的速率，XCP有时也会在异构业务流之间进行区分。[Low05]提供了XCP平衡特性的完整表征。
Several other explicit router feedback schemes have been developed with different design objectives. For instance, RCP uses per-packet feedback similar to XCP. But unlike XCP, RCP focuses on the reduction of flow completion times [Dukki06], taking an optimistic approach to flows likely to arrive in the next RTT and tolerating larger instantaneous queue sizes [Dukki05]. XCP, on the other hand, gives very poor flow completion times for short flows.
其他几个明确的路由器反馈方案已开发出不同的设计目标。例如，RCP使用与XCP类似的每包反馈。但与XCP不同，RCP侧重于减少流完成时间[Dukki06]，对可能在下一个RTT中到达的流采取乐观的方法，并容忍更大的瞬时队列大小[Dukki05]。另一方面，对于短流，XCP给出的流完成时间非常差。
Both implicit and explicit router support should be considered in the context of the end-to-end argument [Saltzer84], which is one of the key design principles of the Internet. It suggests that functions that can be realized both in the end-systems and in the network
隐式和显式路由器支持都应该在端到端参数[Saltzer84]的上下文中考虑，这是互联网的关键设计原则之一。它表明，可以在终端系统和网络中实现的功能
should be implemented in the end-systems. This principle ensures that the network provides a general service and that it remains as simple as possible (any additional complexity is placed above the IP layer, i.e., at the edges) so as to ensure evolvability, reliability, and robustness. Furthermore, the fate-sharing principle ([Clark88], "Design Philosophy of the DARPA Internet Protocols") mandates that an end-to-end Internet protocol design should not rely on the maintenance of any per-flow state (i.e., information about the state of the end-to-end communication) inside the network and that the network state (e.g., routing state) maintained by the Internet shall minimize its interaction with the states maintained at the endpoints/hosts [RFC1958].
应在最终系统中实施。这一原则确保网络提供通用服务，并尽可能保持简单（任何额外的复杂性都置于IP层之上，即边缘），以确保可进化性、可靠性和健壮性。此外，命运共享原则（[Clark88]，“DARPA互联网协议的设计理念”）规定，端到端互联网协议设计不应依赖于维护网络内的任何每流状态（即，关于端到端通信状态的信息），以及网络状态（例如，路由状态）由互联网维护的系统应尽量减少其与端点/主机上维护的状态的交互[RFC1958]。
However, as discussed in [Moors02] for instance, congestion control cannot be realized as a pure end-to-end function only. Congestion is an inherent network phenomenon and can only be resolved efficiently by some cooperation of end-systems and the network. Congestion control in today's Internet protocols follows the end-to-end design principle insofar as only minimal feedback from the network is used, e.g., packet loss and delay. The end-systems only decide how to react and how to avoid congestion. The crux is that on the one hand, there would be substantial benefit by further assistance from the network, but, on the other hand, such network support could lead to duplication of functions, which might even harmfully interact with end-to-end protocol mechanisms. The different requirements of applications (cf. the fairness discussion in Section 2.3) call for a variety of different congestion control approaches, but putting such per-flow behavior inside the network should be avoided, as such a design would clearly be at odds with the end-to-end and fate-sharing design principles.
然而，如[Moors02]中所述，拥塞控制不能仅作为纯端到端功能来实现。拥塞是一种固有的网络现象，只有通过终端系统和网络的一些合作才能有效地解决。当今互联网协议中的拥塞控制遵循端到端设计原则，只要使用来自网络的最小反馈，例如数据包丢失和延迟。终端系统只决定如何反应以及如何避免拥塞。关键是，一方面，网络的进一步援助将带来巨大的好处，但另一方面，这种网络支持可能导致功能重复，甚至可能与端到端协议机制产生有害的交互作用。应用程序的不同要求（参见第2.3节中的公平性讨论）需要各种不同的拥塞控制方法，但应避免将这种每流行为放入网络中，因为这种设计显然与端到端和命运共享设计原则不符。
The end-to-end and fate-sharing principles are generally regarded as the key ingredients for ensuring a scalable and survivable network design. In order to ensure that new congestion control mechanisms are scalable, violating these principles must therefore be avoided.
端到端和命运共享原则通常被视为确保可扩展和可生存网络设计的关键要素。为了确保新的拥塞控制机制是可伸缩的，因此必须避免违反这些原则。
For instance, protocols like XCP and RCP seem not to require flow state in the network, but this is only the case if the network trusts i) the receiver not to lie when feeding back the network's delta to the requested rate; ii) the source not to lie when declaring its rate; and iii) the source not to cheat when setting its rate in response to the feedback [Katabi04].
例如，像XCP和RCP这样的协议似乎不需要网络中的流状态，但只有当网络信任i）接收器在将网络的增量反馈到请求的速率时不说谎时，才会出现这种情况；ii）来源在声明其费率时不得撒谎；以及iii）信息来源在根据反馈设定利率时不得作弊[Katabi04]。
Solving these problems for non-cooperative environments like the public Internet requires flow state, at least on a sampled basis. However, because flows can create new identifiers whenever they want, sampling does not provide a deterrent -- a flow can simply cheat until it is discovered and then switch to a whitewashed identifier [Feldman04], and continue cheating until it is discovered again ([Bri09], S7.3).
在公共互联网等非合作环境中解决这些问题需要流状态，至少是在抽样的基础上。然而，由于流可以在任何时候创建新的标识符，因此采样并不能提供威慑——流可以简单地欺骗，直到被发现，然后切换到经过粉饰的标识符[Feldman04]，并继续欺骗，直到再次被发现为止（[Bri09]，S7.3）。
However, holding flow state in the network only seems to solve these policing problems in single autonomous system settings. A multi-domain system would seem to require a completely different protocol structure, as the information required for policing is only seen as packets leave the internetwork, but the networks where packets enter will also want to police compliance.
然而，在网络中保持流状态似乎只能在单个自治系统设置中解决这些警务问题。一个多域系统似乎需要一个完全不同的协议结构，因为监控所需的信息仅在数据包离开互联网时才被视为，但数据包进入的网络也希望监控合规性。
Even if a new protocol structure were found, it seems unlikely that network flow state could be avoided given the network's per-packet flow rate instructions would need to be compared against variations in the actual flow rate, which is inherently not a per-packet metric. These issues have been outstanding ever since integrated services (IntServ) was identified as unscalable in 1997 [RFC2208]. All subsequent attempts to involve network elements in limiting flow rates (XCP, RCP, etc.) will run up against the same open issue if anyone attempts to standardize them for use on the public Internet.
即使找到了新的协议结构，也不太可能避免网络流状态，因为需要将网络的每包流量指令与实际流量的变化进行比较，实际流量的变化本质上不是每包指标。自1997年确定集成服务（IntServ）不可扩展以来，这些问题一直很突出[RFC2208]。如果有人试图将网络元素标准化以在公共互联网上使用，则所有后续尝试将网络元素纳入限制流量（XCP、RCP等）的尝试都将遇到相同的公开问题。
In general, network support of congestion control raises many issues that have not been completely solved yet.
总的来说，网络对拥塞控制的支持提出了许多尚未完全解决的问题。
Congestion control is subject to some tradeoffs: on the one hand, it must allow high link utilizations and fair resource sharing, but on the other hand, the algorithms must also be robust.
拥塞控制需要进行一些权衡：一方面，它必须允许高链路利用率和公平的资源共享，但另一方面，算法也必须具有鲁棒性。
Router support can help to improve performance, but it can also result in additional complexity and more control loops. This requires a careful design of the algorithms in order to ensure stability and avoid, e.g., oscillations. A further challenge is the fact that feedback information may be imprecise. For instance, severe congestion can delay feedback signals. Also, in-network measurement of parameters such as RTTs or data rates may contain estimation errors. Even though there has been significant progress in providing fundamental theoretical models for such effects, research has not completely explored the whole problem space yet.
路由器支持有助于提高性能，但也可能导致额外的复杂性和更多的控制循环。这需要仔细设计算法，以确保稳定性并避免（例如）振荡。另一个挑战是反馈信息可能不精确。例如，严重的拥塞会延迟反馈信号。此外，在网络中，诸如RTT或数据速率等参数的测量可能包含估计误差。尽管在为这些效应提供基本理论模型方面取得了重大进展，但研究尚未完全探索整个问题空间。
Open questions are:
开放性问题包括：
- How much can network elements theoretically improve performance in the complete range of communication scenarios that exist in the Internet without damaging or impacting end-to-end mechanisms already in place?
- 从理论上讲，网络元素能够在不破坏或影响现有端到端机制的情况下，在互联网中存在的一系列通信场景中提高多少性能？
- Is it possible to design robust congestion control mechanisms that offer significant benefits with minimum additional risks, even if Internet traffic patterns will change in the future?
- 即使未来互联网流量模式将发生变化，是否有可能设计鲁棒的拥塞控制机制，以最小的额外风险提供显著的好处？
- What is the minimum support that is needed from the network in order to achieve significantly better performance than with end-to-end mechanisms and the current IP header limitations that provide at most unary ECN signals?
- 为了获得比端到端机制和当前IP报头限制（最多提供一元ECN信号）更好的性能，网络需要的最低支持是什么？
There are several degrees of freedom concerning the involvement of network entities, ranging from some few additional functions in network management procedures on the one end to additional per-packet processing on the other end of the solution space. Furthermore, different amounts of state can be kept in routers (no per-flow state, partial per-flow state, soft state, or hard state). The additional router processing is a challenge for Internet scalability and could also increase end-to-end latencies.
网络实体的参与有几个自由度，从一端的网络管理过程中的一些附加功能到解决方案空间另一端的附加每个数据包处理。此外，路由器中可以保持不同数量的状态（无每流状态、部分每流状态、软状态或硬状态）。额外的路由器处理对互联网的可扩展性是一个挑战，也可能增加端到端的延迟。
Although there are many research proposals that do not require per-flow state and thus do not cause a large processing overhead, there are no known full solutions (i.e., including anti-cheating) that do not require per-flow processing. Also, scalability issues could be caused, for instance, by synchronization mechanisms for state information among parallel processing entities, which are, e.g., used in high-speed router hardware designs.
尽管有许多研究建议不需要每个流状态，因此不会造成很大的处理开销，但还没有不需要每个流处理的已知完整解决方案（即，包括反作弊）。此外，可伸缩性问题可能由并行处理实体之间的状态信息同步机制引起，例如，在高速路由器硬件设计中使用。
Open questions are:
开放性问题包括：
- What granularity of router processing can be realized without affecting Internet scalability?
- 在不影响互联网可扩展性的情况下，路由器处理的粒度是多少？
- How can additional processing efforts be kept to a minimum?
- 如何将额外的处理工作保持在最低限度？
In order to support congestion control, network components have to obtain at least a subset of the following information. Obtaining that information may result in complex tasks.
为了支持拥塞控制，网络组件必须至少获得以下信息的子集。获取这些信息可能会导致复杂的任务。
1. Capacity of (outgoing) links
1. （传出）链路的容量
Link characteristics depend on the realization of lower protocol layers. Routers operating at the IP layer do not necessarily know the link layer network topology and link capacities, and these are not always constant (e.g., on shared wireless links or bandwidth-on-demand links). Depending on the network technology, there can be queues or bottlenecks that are not directly visible at the IP networking layer.
链路特性取决于较低协议层的实现。在IP层运行的路由器不一定知道链路层网络拓扑和链路容量，并且这些并不总是恒定的（例如，在共享无线链路或按需带宽链路上）。根据网络技术的不同，可能存在在IP网络层无法直接看到的队列或瓶颈。
Difficulties also arise when using IP-in-IP tunnels [RFC2003], IPsec tunnels [RFC4301], IP encapsulated in the Layer Two Tunneling Protocol (L2TP) [RFC2661], Generic Routing Encapsulation (GRE) [RFC1701] [RFC2784], the Point-to-Point Tunneling Protocol (PPTP) [RFC2637], or Multiprotocol Label Switching (MPLS) [RFC3031] [RFC3032]. In these cases, link information could be determined by cross-layer information exchange, but this requires interfaces capable of processing link layer technology specific information. An alternative could be online measurements, but this can cause significant additional network overhead. It is an open research question as to how much, if any, online traffic measurement would be acceptable (at run-time). Encapsulation and decapsulation of explicit congestion information have been specified for IP-in-IP tunnelling [RFC6040] and for MPLS-in-MPLS or MPLS-in-IP [RFC5129].
在IP隧道[RFC2003]、IPsec隧道[RFC4301]、封装在第二层隧道协议（L2TP）[RFC2661]中的IP、通用路由封装（GRE）[RFC1701][RFC2784]、点对点隧道协议（PPTP）[RFC2637]或多协议标签交换（MPLS）[RFC3031][RFC3032]中使用IP时也会遇到困难。在这些情况下，链路信息可以通过跨层信息交换来确定，但这需要能够处理链路层技术特定信息的接口。另一种方法是在线测量，但这可能会导致额外的网络开销。在线流量测量（在运行时）可以接受多少（如果有的话），这是一个开放的研究问题。已为IP隧道中的IP[RFC6040]和MPLS中的MPLS或IP中的MPLS[RFC5129]指定显式拥塞信息的封装和解除封装。
2. Traffic carried over (outgoing) links
2. 通过（传出）链路的流量
Accurate online measurement of data rates is challenging when traffic is bursty. For instance, measuring a "current link load" requires defining the right measurement interval / sampling interval. This is a challenge for proposals that require knowledge, e.g., about the current link utilization.
当流量突发时，准确在线测量数据速率是一项挑战。例如，测量“当前链路负载”需要定义正确的测量间隔/采样间隔。对于需要了解当前链路利用率等信息的提案而言，这是一个挑战。
3. Internal buffer statistics
3. 内部缓冲区统计
Some proposals use buffer statistics such as a virtual queue length to trigger feedback. However, network components can include multiple distributed buffer stages that make it difficult to obtain such metrics.
有些建议使用缓冲区统计信息（如虚拟队列长度）来触发反馈。然而，网络组件可以包括多个分布式缓冲阶段，这使得获得此类度量变得困难。
Open questions are:
开放性问题包括：
- Can and should this information be made available, e.g., by additional interfaces or protocols?
- 该信息是否可以，是否应该，例如，通过附加接口或协议提供？
- Which information is so important to higher-layer controllers that machine architecture research should focus on designing to provide it?
- 哪些信息对更高层的控制器如此重要，以至于机器架构研究应该专注于设计以提供这些信息？
Explicit notification mechanisms can be realized either by in-band signaling (notifications piggybacked along with the data traffic) or by out-of-band signaling [Sarola07]. The latter case requires additional protocols and a secure binding between the signals and the packets they refer to. Out-of-band signaling can be further subdivided into path-coupled and path-decoupled approaches.
显式通知机制可以通过带内信令（通知与数据流量一起携带）或带外信令实现[Sarola07]。后一种情况需要附加协议以及信号和它们所指的数据包之间的安全绑定。带外信令可进一步细分为路径耦合和路径解耦方法。
Open questions concerning feedback signaling include:
关于反馈信号的开放性问题包括：
- At which protocol layer should the feedback signaling occur (IP/network layer assisted, transport layer assisted, hybrid solutions, shim layer, intermediate sub-layer, etc.)? Should the feedback signaling be path-coupled or path-decoupled?
- 反馈信令应该发生在哪个协议层（IP/网络层辅助、传输层辅助、混合解决方案、垫片层、中间子层等）？反馈信号应该是路径耦合还是路径解耦？
- What is the optimal frequency of feedback (only in case of congestion events, per RTT, per packet, etc.)?
- 反馈的最佳频率是多少（仅在发生拥塞事件时，每个RTT、每个数据包等）？
- What direction should feedback take (from network resource via receiver to sender, or directly back to sender)?
- 反馈应该采取什么方向（从网络资源通过接收者到发送者，或直接返回到发送者）？
It is common for congestion control mechanisms to interpret packet loss as a sign of congestion. This is appropriate when packets are dropped in routers because of a queue that overflows, but there are other possible reasons for packet drops. In particular, in wireless networks, packets can be dropped because of corruption loss, rendering the typical reaction of a congestion control mechanism inappropriate. As a result, non-congestive loss may be more prevalent in these networks due to corruption loss (when the wireless link cannot be conditioned to properly control its error rate or due to transient wireless link interruption in areas of poor coverage).
拥塞控制机制通常将数据包丢失解释为拥塞的标志。当由于队列溢出而在路由器中丢弃数据包时，这是合适的，但数据包丢弃还有其他可能的原因。特别是，在无线网络中，数据包可能因为损坏丢失而丢失，这使得拥塞控制机制的典型反应不合适。因此，在这些网络中，由于损坏损失（当无线链路无法调节以适当控制其错误率时，或由于在覆盖较差的区域中的瞬时无线链路中断），非拥塞性损失可能更为普遍。
TCP over wireless and satellite is a topic that has been investigated for a long time [Krishnan04]. There are some proposals where the congestion control mechanism would react as if a packet had not been dropped in the presence of corruption (cf. TCP HACK [Balan01]), but
无线和卫星上的TCP是一个长期研究的主题[Krishnan04]。有一些建议认为，拥塞控制机制的反应就像数据包没有在存在损坏的情况下被丢弃一样（参见TCP HACK[Balan01]），但是
discussions in the IETF have shown (see, for instance, the discussion that occurred in April 2003 on the Datagram Congestion Control Protocol (DCCP) working group list http://www.ietf.org/mail-archive/web/dccp/current/mail6.html) that there is no agreement that this type of reaction is appropriate. For instance, it has been said that congestion can manifest itself as corruption on shared wireless links, and it is questionable whether a source that sends packets that are continuously impaired by link noise should keep sending at a high rate because it has lost the integrity of the feedback loop.
IETF中的讨论显示（例如，参见2003年4月关于数据报拥塞控制协议（DCCP）工作组列表的讨论）http://www.ietf.org/mail-archive/web/dccp/current/mail6.html)没有人同意这种反应是合适的。例如，有人说，拥塞会表现为共享无线链路上的损坏，发送连续受到链路噪声损害的数据包的源是否应该保持高速发送，因为它已经失去了反馈回路的完整性，这是值得怀疑的。
Generally, two questions must be addressed when designing a congestion control mechanism that takes corruption loss into account:
通常，在设计考虑腐败损失的拥塞控制机制时，必须解决两个问题：
1. How is corruption detected?
1. 如何发现腐败？
2. What should be the reaction?
2. 反应应该是什么？
In addition to question 1 above, it may be useful to consider detecting the reason for corruption, but this has not yet been done to the best of our knowledge.
除了上面的问题1，考虑腐败的原因可能是有用的，但这还没有做到我们所知。
Corruption detection can be done using an in-band or out-of-band signaling mechanism, much in the same way as described for Challenge 1. Additionally, implicit detection can be considered: link layers sometimes retransmit erroneous frames, which can cause the end-to-end delay to increase -- but, from the perspective of a sender at the transport layer, there are many other possible reasons for such an effect.
可以使用带内或带外信令机制进行损坏检测，其方式与质询1中描述的方式大致相同。此外，还可以考虑隐式检测：链路层有时会重新传输错误帧，这可能会导致端到端延迟增加——但是，从传输层发送方的角度来看，这种影响还有许多其他可能的原因。
Header checksums provide another implicit detection possibility: if a checksum only covers all the necessary header fields and this checksum does not show an error, it is possible for errors to be found in the payload using a second checksum. Such error detection is possible with UDP-Lite and DCCP; it was found to work well over a General Packet Radio Service (GPRS) network in a study [Chester04] and poorly over a WiFi network in another study [Rossi06] [Welzl08]. Note that while UDP-Lite and DCCP enable the detection of corruption, the specifications of these protocols do not foresee any specific reaction to it for the time being.
报头校验和提供了另一种隐式检测可能性：如果校验和仅覆盖所有必要的报头字段，并且该校验和未显示错误，则可以使用第二个校验和在有效负载中找到错误。使用UDP Lite和DCCP可以进行这种错误检测；在一项研究[Chester04]中，它在通用分组无线服务（GPRS）网络上运行良好，而在另一项研究[Rossi06][Welzl08]中，它在WiFi网络上运行较差。请注意，虽然UDP Lite和DCCP能够检测损坏，但这些协议的规范暂时无法预见对它的任何特定反应。
The idea of having a transport endpoint detecting and accordingly reacting (or not) to corruption poses a number of interesting questions regarding cross-layer interactions. As IP is designed to operate over arbitrary link layers, it is therefore difficult to design a congestion control mechanism on top of it that appropriately reacts to corruption -- especially as the specific data link layers that are in use along an end-to-end path are typically unknown to entities at the transport layer.
让传输端点检测并相应地应对（或不应对）损坏的想法提出了许多关于跨层交互的有趣问题。由于IP被设计为在任意链路层上运行，因此很难在其上设计一个拥塞控制机制来适当地对损坏做出反应——特别是当传输层的实体通常不知道沿端到端路径使用的特定数据链路层时。
While the IETF has not yet specified how a congestion control mechanism should react to corruption, proposals exist in the literature, e.g., [Tickoo05]. For instance, TCP Westwood [Mascolo01] sets the congestion window equal to the measured bandwidth at the time of congestion in response to three DupACKs or a timeout. This measurement is obtained by counting and filtering the ACK rate. This setting provides a significant goodput improvement in noisy channels because the "blind" by half window reduction of standard TCP is avoided, i.e., the window is not reduced by too much.
虽然IETF尚未规定拥塞控制机制应如何应对腐败，但文献中存在建议，例如[Tickoo05]。例如，TCP Westwood[Mascolo01]将拥塞窗口设置为拥塞时测量的带宽，以响应三次重复或超时。该测量通过对确认率进行计数和滤波来获得。此设置在噪声信道中提供了显著的良好输出改善，因为避免了标准TCP窗口减少一半的“盲”，即窗口不会减少太多。
Open questions concerning corruption loss include:
关于腐败损失的开放性问题包括：
- How should corruption loss be detected?
- 如何检测腐败损失？
- How should a source react when it is known that corruption has occurred?
- 当已知已发生腐败时，消息来源应如何反应？
- Can an ECN-capable flow infer that loss must be due to corruption just from lack of explicit congestion notifications around a loss episode [Tickoo05]? Or could this inference be dangerous, given the transport does not know whether all queues on the path are ECN-capable or not?
- 支持ECN的流是否可以推断丢失一定是由于丢失事件周围缺少明确的拥塞通知而导致的损坏[Tickoo05]？或者，如果传输不知道路径上的所有队列是否都支持ECN，那么这种推断会很危险吗？
TCP does not take packet size into account when responding to losses or ECN. Over past years, the performance of TCP congestion avoidance algorithms has been extensively studied. The well-known "square root formula" provides an estimation of the performance of the TCP congestion avoidance algorithm for TCP Reno [RFC2581]. [Padhye98] enhances the model to account for timeouts, receiver window, and delayed ACKs.
TCP在响应丢失或ECN时不考虑数据包大小。在过去的几年中，TCP拥塞避免算法的性能得到了广泛的研究。众所周知的“平方根公式”为TCP Reno[RFC2581]提供了TCP拥塞避免算法性能的估计。[Padhye98]增强了模型，以解释超时、接收器窗口和延迟确认。
For the sake of the present discussion, we will assume that the TCP throughput is expressed using the simplified formula. Using this formula, the TCP throughput B is proportional to the segment size and inversely proportional to the RTT and the square root of the drop probability:
为了便于目前的讨论，我们将假设TCP吞吐量使用简化公式表示。使用此公式，TCP吞吐量B与段大小成正比，与RTT和丢弃概率的平方根成反比：
S 1
B ~ C --- -------
RTT sqrt(p)
S 1
B ~ C --- -------
RTT sqrt(p)
where
哪里
C is a constant S is the TCP segment size (in bytes) RTT is the end-to-end round-trip time of the TCP connection (in seconds) p is the packet drop probability
C是常数S是TCP段大小（以字节为单位）RTT是TCP连接的端到端往返时间（以秒为单位）p是丢包概率
Neglecting the fact that the TCP rate linearly depends on it, choosing the ideal packet size is a tradeoff between high throughput (the larger a packet, the smaller the relative header overhead) and low packet latency (the smaller a packet, the shorter the time that is needed until it is filled with data). Observing that TCP is not optimal for applications with streaming media (since reliable in-order delivery and congestion control can cause arbitrarily long delays), this tradeoff has not usually been considered for TCP applications. Therefore, the influence of the packet size on the sending rate has not typically been seen as a significant issue, given there are still few paths through the Internet that support packets larger than the 1500 bytes common with Ethernet.
忽略TCP速率线性依赖于它的事实，选择理想的数据包大小是在高吞吐量（数据包越大，相对报头开销越小）和低数据包延迟（数据包越小，直到充满数据所需的时间越短）之间的折衷。观察到TCP对于具有流媒体的应用程序不是最优的（因为可靠的顺序传递和拥塞控制可能会导致任意长的延迟），TCP应用程序通常不考虑这种权衡。因此，分组大小对发送速率的影响通常不被视为重要问题，因为通过因特网的路径仍然很少支持大于以太网常见的1500字节的分组。
The situation is already different for the Datagram Congestion Control Protocol (DCCP) [RFC4340], which has been designed to enable unreliable but congestion-controlled datagram transmission, avoiding the arbitrary delays associated with TCP. DCCP is intended for applications such as streaming media that can benefit from control over the tradeoffs between delay and reliable in-order delivery.
数据报拥塞控制协议（DCCP）[RFC4340]的情况已经不同，该协议旨在实现不可靠但拥塞控制的数据报传输，避免与TCP相关的任意延迟。DCCP适用于流媒体等应用程序，这些应用程序可以通过控制延迟和可靠有序交付之间的权衡而获益。
DCCP provides for a choice of modular congestion control mechanisms. DCCP uses Congestion Control Identifiers (CCIDs) to specify the congestion control mechanism. Three profiles are currently specified:
DCCP提供了模块化拥塞控制机制的选择。DCCP使用拥塞控制标识符（CCID）来指定拥塞控制机制。目前指定了三个配置文件：
- DCCP Congestion Control ID 2 (CCID 2) [RFC4341]: TCP-like Congestion Control. CCID 2 sends data using a close approximation of TCP's congestion control as well as incorporating a variant of Selective Acknowledgment (SACK) [RFC2018] [RFC3517]. CCID 2 is suitable for senders that can adapt to the abrupt changes in the congestion window typical of TCP's AIMD congestion control, and particularly useful for senders that would like to take advantage of the available bandwidth in an environment with rapidly changing conditions.
- DCCP拥塞控制ID 2（CCID 2）[RFC4341]：类似TCP的拥塞控制。CCID2使用TCP拥塞控制的近似值发送数据，并加入选择性确认（SACK）[RFC2018][RFC3517]的变体。CCID 2适用于能够适应TCP的AIMD拥塞控制中典型的拥塞窗口的突然变化的发送方，尤其适用于希望在条件快速变化的环境中利用可用带宽的发送方。
- DCCP Congestion Control ID 3 (CCID 3) [RFC4342]: TCP-Friendly Rate Control (TFRC) [RFC5348] is a congestion control mechanism designed for unicast flows operating in a best-effort Internet environment. When competing for bandwidth, its window is similar to TCP flows but has a much lower variation of throughput over time than TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance. CCID 3 is appropriate for flows that would prefer to minimize abrupt changes in the sending rate, including streaming media applications with small or moderate receiver buffering before playback.
- DCCP拥塞控制ID 3（CCID 3）[RFC4342]：TCP友好速率控制（TFRC）[RFC5348]是一种为在尽力而为的Internet环境中运行的单播流设计的拥塞控制机制。当竞争带宽时，它的窗口类似于TCP流，但吞吐量随时间的变化比TCP小得多，这使得它更适合于相对平滑的发送速率非常重要的流媒体等应用。CCID 3适用于希望最小化发送速率的突然变化的流，包括在回放之前具有小型或中度接收器缓冲的流媒体应用。
- DCCP Congestion Control ID 4 (CCID 4) [RFC5622]: TFRC Small Packets (TFRC-SP) [RFC4828], a variant of the TFRC mechanism, has been designed for applications that exchange small packets. The objective of TFRC-SP is to achieve the same bandwidth in bits per second as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently. CCID 4 has been designed to be used either by applications that use a small fixed segment size, or by applications that change their sending rate by varying the segment size. Because CCID 4 is intended for applications that use a fixed small segment size, or that vary their segment size in response to congestion, the transmit rate derived from the TCP throughput equation is reduced by a factor that accounts for the packet header size, as specified in [RFC4828].
- DCCP拥塞控制ID 4（CCID 4）[RFC5622]：TFRC小包（TFRC-SP）[RFC4828]，TFRC机制的一种变体，专为交换小包的应用程序而设计。TFRC-SP的目标是使用高达1500字节的数据包实现与TCP流相同的带宽（以比特/秒为单位）。TFRC-SP强制数据包之间的最小间隔为10 ms，以防止单个流任意频繁地发送小数据包。CCID4设计用于使用较小固定段大小的应用程序，或通过改变段大小来改变发送速率的应用程序。由于CCID 4适用于使用固定小段大小的应用程序，或根据拥塞改变其段大小的应用程序，因此从TCP吞吐量方程推导出的传输速率减少了一个因子，该因子可解释数据包头大小，如[RFC4828]中所述。
The resulting open questions are:
由此产生的开放性问题有：
- How does TFRC-SP operate under various network conditions?
- TFRC-SP如何在各种网络条件下运行？
- How can congestion control be designed so as to scale with packet size (dependency of congestion algorithm on packet size)?
- 如何设计拥塞控制，使其与数据包大小（拥塞算法对数据包大小的依赖性）成比例？
Today, many network resources are designed so that packet processing cannot be overloaded even for incoming loads at the maximum bit rate of the line. If packet processing can handle sustained load r [packet per second] and the minimum packet size is h [bit] (i.e., frame, packet, and transport headers with no payload), then a line rate of x [bit per second] will never be able to overload packet processing as long as x =< r*h.
今天，许多网络资源的设计使得数据包处理即使在线路的最大比特率下也不会过载。如果数据包处理可以处理持续的负载r[每秒数据包]，并且最小数据包大小为h[位]（即，没有有效负载的帧、数据包和传输报头），那么只要x=<r*h，x[每秒数据包]的线速率将永远无法使数据包处理过载。
However, realistic equipment is often designed to only cope with a near-worst-case workload with a few larger packets in the mix, rather than the worst-case scenario of all minimum-size packets. In this case, x = r*(h + e) for some small value of e. Therefore, packet congestion is not impossible for runs of small packets (e.g., TCP
然而，现实的设备通常被设计为只处理几乎最坏情况下的工作负载，而不是所有最小大小的数据包的最坏情况。在这种情况下，对于一些较小的e值，x=r*（h+e）。因此，对于小数据包（例如TCP）的运行，数据包拥塞并非不可能
ACKs or denial-of-service (DoS) attacks with TCP SYNs or small UDP datagrams). But absent such anomalous workloads, equipment vendors at the 2008 ICCRG meeting believed that equipment could still be designed so that any congestion should be due to bit overload and not packet overload.
使用TCP SYNs或小型UDP数据报的ACK或拒绝服务（DoS）攻击。但在没有这种异常工作负载的情况下，设备供应商在2008年ICCRG会议上认为，设备的设计仍然可以确保任何拥塞都是由于位过载而不是数据包过载造成的。
This observation raises additional open issues:
这一观察提出了其他未决问题：
- Can bit congestion remain prevalent?
- 比特拥塞会继续流行吗？
Being able to assume that congestion is generally due to excess bits and not excess packets is a useful simplifying assumption in the design of congestion control protocols. Can we rely on this assumption for the future? An alternative view is that in-network processing will become commonplace, so that per-packet processing will as likely be the bottleneck as per-bit transmission [Shin08].
在拥塞控制协议的设计中，能够假设拥塞通常是由于多余的比特而不是多余的数据包造成的是一个有用的简化假设。我们能否在未来依靠这一假设？另一种观点是，网络内处理将变得司空见惯，因此每包处理很可能成为每比特传输的瓶颈[Shin08]。
Over the last three decades, performance gains have mainly been achieved through increased packet rates and not bigger packets. But if bigger maximum segment sizes do become more prevalent, tiny segments (e.g., ACKs) will not stop being widely used -- leading to a widening range of packet sizes.
在过去三十年中，性能的提高主要是通过提高数据包速率而不是更大的数据包来实现的。但是，如果更大的最大数据段大小确实变得更普遍，那么微小的数据段（如ACK）将不会停止被广泛使用——这将导致数据包大小范围的扩大。
The open question is thus whether or not packet processing rates (r) will keep up with growth in transmission rates (x). A superficial look at Moore's Law-type trends would suggest that processing (r) will continue to outstrip growth in transmission (x). But predictions based on actual knowledge of technology futures would be useful. Another open question is whether there are likely to be more small packets in the average packet mix. If the answers to either of these questions predict that packet congestion could become prevalent, congestion control protocols will have to be more complicated.
因此，公开的问题是分组处理速率（r）是否会跟上传输速率（x）的增长。从表面上看摩尔定律类型的趋势表明，处理（r）将继续超过传输（x）的增长。但基于技术未来的实际知识进行预测是有用的。另一个悬而未决的问题是，在平均分组组合中是否可能有更多的小分组。如果这两个问题的答案都预测数据包拥塞可能会变得普遍，那么拥塞控制协议就必须更加复杂。
- Confusable causes of loss
- 可混淆的损失原因
There is a considerable body of research on how to distinguish whether packet drops are due to transmission corruption or to congestion. But the full list of confusable causes of loss is longer and includes transmission corruption loss, congestion loss (bit congestion and packet congestion), and policing loss.
关于如何区分数据包丢失是由于传输损坏还是由于拥塞，有大量的研究。但可混淆的丢失原因的完整列表更长，包括传输损坏损失、拥塞损失（位拥塞和数据包拥塞）以及监控损失。
If congestion is due to excess bits, the bit rate should be reduced. If congestion is due to excess packets, the packet rate can be reduced without reducing the bit rate -- by using larger packets. However, if the transport cannot tell which of these causes led to a specific packet drop, its only safe response is to reduce the bit rate. This is why the Internet would be more
如果拥塞是由于位过多造成的，则应降低比特率。如果拥塞是由于过多的数据包造成的，则可以在不降低比特率的情况下降低数据包速率——通过使用较大的数据包。但是，如果传输无法判断这些原因中的哪一个导致了特定的数据包丢失，那么它唯一的安全响应就是降低比特率。这就是为什么互联网会更强大
complicated if packet congestion were prevalent, as reducing the bit rate normally also reduces the packet rate, while reducing the packet rate does not necessarily reduce the bit rate.
如果数据包拥塞普遍存在，则情况复杂，因为降低比特率通常也会降低数据包速率，而降低数据包速率并不一定会降低比特率。
Given distinguishing between corruption loss and congestion is already an open issue (Section 3.2), if that problem is ever solved, a further open issue would be whether to standardize a solution that distinguishes all the above causes of loss, and not just two of them.
考虑到区分腐败损失和拥堵已经是一个悬而未决的问题（第3.2节），如果该问题得以解决，另一个悬而未决的问题将是是否要标准化一个解决方案，以区分上述所有损失原因，而不仅仅是其中两个。
Nonetheless, even if we find a way for network equipment to explicitly distinguish which sort of loss has occurred, we will never be able to assume that such a smart AQM solution is deployed at every congestible resource throughout the Internet -- at every higher-layer device like firewalls, proxies, and servers; and at every lower-layer device like low-end hubs, DSLAMs, Wireless LAN (WLAN) cards, cellular base-stations, and so on. Thus, transport protocols will always have to cope with packet drops due to unpredictable causes, so we should always treat AQM as an optimization, given it will never be ubiquitous throughout the public Internet.
尽管如此，即使我们找到一种方法让网络设备明确区分发生了哪种类型的丢失，我们也永远无法假设这样一个智能AQM解决方案部署在整个互联网的每一个拥挤的资源上——部署在防火墙、代理和服务器等每一个更高层的设备上；在每一个底层设备上，如低端集线器、DSLAM、无线局域网（WLAN）卡、蜂窝基站等。因此，传输协议将始终必须处理由于不可预测的原因导致的数据包丢失，因此我们应该始终将AQM视为一种优化，因为它永远不会在整个公共互联网中无处不在。
- What does a congestion notification on a packet of a certain size mean?
- 特定大小的数据包上的拥塞通知意味着什么？
The open issue here is whether a loss or explicit congestion mark should be interpreted as a single congestion event irrespective of the size of the packet lost or marked, or whether the strength of the congestion notification is weighted by the size of the packet. This issue is discussed at length in [Bri10], along with other aspects of packet size and congestion control.
这里的公开问题是，丢失或显式拥塞标记是否应解释为单个拥塞事件，而与丢失或标记的数据包的大小无关，或者拥塞通知的强度是否由数据包的大小加权。[Bri10]详细讨论了这个问题，以及数据包大小和拥塞控制的其他方面。
[Bri10] makes the strong recommendation that network equipment should drop or mark packets with a probability independent of each specific packet's size, while congestion controls should respond to dropped or marked packets in proportion to the packet's size.
[Bri10]强烈建议网络设备丢弃或标记数据包的概率与每个特定数据包的大小无关，而拥塞控制应根据数据包的大小对丢弃或标记的数据包做出相应的响应。
- Packet size and congestion control protocol design
- 数据包大小与拥塞控制协议设计
If the above recommendation is correct -- that the packet size of a congestion notification should be taken into account when the transport reads, and not when the network writes, the notification -- it opens up a significant problem of protocol engineering and re-engineering. Indeed, TCP does not take packet size into account when responding to losses or ECN. At present, this is not a pressing problem because use of 1500 byte data segments is very prevalent for TCP, and the incidence of alternative maximum
如果上面的建议是正确的——在传输读取通知时，而不是在网络写入通知时，应该考虑拥塞通知的数据包大小——这就带来了协议工程和重新工程的一个重大问题。实际上，TCP在响应丢失或ECN时不考虑数据包大小。目前，这并不是一个紧迫的问题，因为对于TCP来说，使用1500字节的数据段是非常普遍的，并且替代数据段的发生率是最大的
segment sizes is not large. However, we should design the Internet's protocols so they will scale with packet size. So, an open issue is whether we should evolve TCP to be sensitive to packet size, or expect new protocols to take over.
段大小不是很大。然而，我们应该设计互联网的协议，以便它们能够随着数据包的大小而扩展。所以，一个悬而未决的问题是，我们是否应该改进TCP，使其对数据包大小敏感，或者期待新的协议接管。
As we continue to standardize new congestion control protocols, we must then face the issue of how they should account for packet size. It is still an open research issue to establish whether TCP was correct in not taking packet size into account. If it is determined that TCP was wrong in this respect, we should discourage future protocol designs from following TCP's example. For example, as explained above, the small-packet variant of TCP-friendly rate control (TFRC-SP [RFC4828]) is an experimental protocol that aims to take packet size into account. Whatever packet size it uses, it ensures that its rate approximately equals that of a TCP using 1500 byte segments. This raises the further question of whether TCP with 1500 byte segments will be a suitable long-term gold standard, or whether we need a more thorough review of what it means for a congestion control mechanism to scale with packet size.
当我们继续标准化新的拥塞控制协议时，我们必须面对这样一个问题：它们应该如何解释数据包大小。确定TCP不考虑数据包大小是否正确仍然是一个开放的研究问题。如果确定TCP在这方面是错误的，我们应该阻止未来的协议设计遵循TCP的例子。例如，如上所述，TCP友好速率控制的小数据包变体（TFRC-SP[RFC4828]）是一种旨在考虑数据包大小的实验协议。无论使用何种数据包大小，它都确保其速率大约等于使用1500字节段的TCP速率。这进一步提出了这样一个问题：1500字节段的TCP是否是一个合适的长期黄金标准，或者我们是否需要更彻底地审查拥塞控制机制随数据包大小扩展意味着什么。
The beginning of data transmissions imposes some further, unique challenges: when a connection to a new destination is established, the end-systems have hardly any information about the characteristics of the path in between and the available bandwidth. In this flow startup situation, there is no obvious choice as to how to start to send. A similar problem also occurs after relatively long idle times, since the congestion control state then no longer reflects current information about the state of the network (flow restart problem).
数据传输的开始带来了一些进一步的、独特的挑战：当建立到新目的地的连接时，终端系统几乎没有关于路径特征和可用带宽的任何信息。在这种流启动情况下，对于如何开始发送，没有明显的选择。由于拥塞控制状态不再反映有关网络状态的当前信息（流重启问题），因此在相对较长的空闲时间后也会出现类似的问题。
Van Jacobson [Jacobson88] suggested using the slow-start mechanism both for the flow startup and the flow restart, and this is today's standard solution [RFC2581] [RFC5681]. Per [RFC5681], the slow-start algorithm is used when the congestion window (cwnd) < slow-start threshold (ssthresh), whose initial value is set arbitrarily high (e.g., to the size of the largest possible advertised window) and reduced in response to congestion. During slow-start, TCP increments the cwnd by at most Sender Maximum Segment Size (MSS) bytes for each ACK received that cumulatively acknowledges new data. Slow-start ends when cwnd exceeds ssthresh or when congestion is observed. However, the slow-start is not optimal in many situations. First, it can take quite a long time until a sender can fully utilize the available bandwidth on a path. Second, the exponential increase may be too aggressive and cause multiple packet loss if large congestion
Van Jacobson[Jacobson88]建议在流启动和流重启时使用慢启动机制，这是今天的标准解决方案[RFC2581][RFC5681]。根据[RFC5681]，当拥塞窗口（cwnd）<慢启动阈值（ssthresh）时，使用慢启动算法，其初始值设置为任意高（例如，最大可能广告窗口的大小），并响应拥塞而减小。在慢启动期间，对于接收到的每个累计确认新数据的ACK，TCP最多将cwnd增加发送方最大段大小（MSS）字节。慢启动在cwnd超过ssthresh或观察到拥塞时结束。但是，在许多情况下，慢启动不是最佳的。首先，发送方可能需要相当长的时间才能充分利用路径上的可用带宽。第二，指数增长可能过于激进，如果拥塞过大，会导致多个数据包丢失
windows are reached (slow-start overshooting). Finally, the slow-start does not ensure that new flows converge quickly to a reasonable share of resources, particularly when the new flows compete with long-lived flows and come out of slow-start early (slow-start vs overshoot tradeoff). This convergence problem may even worsen if more aggressive congestion control variants are widely used.
到达窗口（缓慢启动超调）。最后，慢启动并不能确保新流量迅速收敛到合理的资源份额，特别是当新流量与长寿命流量竞争并提前退出慢启动（慢启动与超调权衡）时。如果更激进的拥塞控制变体被广泛使用，这种收敛问题甚至可能恶化。
The slow-start and its interaction with the congestion avoidance phase was largely designed by intuition [Jacobson88]. So far, little theory has been developed to understand the flow startup problem and its implication on congestion control stability and fairness. There is also no established methodology to evaluate whether new flow startup mechanisms are appropriate or not.
慢启动及其与拥塞避免阶段的相互作用主要由直觉设计[Jacobson88]。到目前为止，对于流量启动问题及其对拥塞控制稳定性和公平性的影响，理论研究还很少。也没有既定的方法来评估新的流启动机制是否合适。
As a consequence, it is a non-trivial task to address the shortcomings of the slow-start algorithm. Several experimental enhancements have been proposed, such as congestion window validation [RFC2861] and limited slow-start [RFC3742]. There are also ongoing research activities, focusing, e.g., on bandwidth estimation techniques, delay-based congestion control, or rate-pacing mechanisms. However, any alternative end-to-end flow startup approach has to cope with the inherent problem that there is no or only little information about the path at the beginning of a data transfer. This uncertainty could be reduced by more expressive feedback signaling (cf. Section 3.1). For instance, a source could learn the path characteristics faster with the Quick-Start mechanism [RFC4782]. But even if the source knew exactly what rate it should aim for, it would still not necessarily be safe to jump straight to that rate. The end-system still does not know how a change in its own rate will affect the path, which also might become congested in less than one RTT. Further research would be useful to understand the effect of decreasing the uncertainty by explicit feedback separately from control theoretic stability questions. Furthermore, flow startup also raises fairness questions. For instance, it is unclear whether it could be reasonable to use a faster startup when an end-system detects that a path is currently not congested.
因此，解决慢启动算法的缺点是一项非常重要的任务。已经提出了一些实验性增强，例如拥塞窗口验证[RFC2861]和有限慢启动[RFC3742]。还有一些正在进行的研究活动，例如，侧重于带宽估计技术、基于延迟的拥塞控制或速率调整机制。然而，任何替代的端到端流启动方法都必须解决一个固有的问题，即在数据传输开始时没有或只有很少的路径信息。这种不确定性可以通过更具表现力的反馈信号来减少（参见第3.1节）。例如，使用快速启动机制[RFC4782]，源可以更快地了解路径特征。但是，即使消息来源确切地知道它的目标利率，直接跳到这个利率也不一定是安全的。终端系统仍然不知道其自身速率的变化将如何影响路径，在不到一个RTT的情况下，路径也可能变得拥挤。进一步的研究将有助于从控制理论稳定性问题中了解显式反馈降低不确定性的效果。此外，流启动也提出了公平性问题。例如，当终端系统检测到路径当前不拥挤时，使用更快的启动是否合理尚不清楚。
In summary, there are several topics for further research concerning flow startup:
综上所述，关于流量启动，有几个课题需要进一步研究：
- Better theoretical understanding of the design and evaluation of flow startup mechanisms, concerning their impact on congestion risk, stability, and fairness.
- 更好地从理论上理解流启动机制的设计和评估，了解它们对拥塞风险、稳定性和公平性的影响。
- Evaluating whether it may be appropriate to allow alternative starting schemes, e.g., to allow higher initial rates under certain constraints [Chu10]; this also requires refining the definition of fairness for startup situations.
- 评估允许替代启动方案是否合适，例如，在某些约束条件下允许更高的初始速率[10]；这还需要对启动情况下的公平性定义进行细化。
- Better theoretical models for the effects of decreasing uncertainty by additional network feedback, particularly if the path characteristics are very dynamic.
- 通过附加网络反馈降低不确定性效果的更好的理论模型，特别是当路径特性非常动态时。
Transport protocols such as TCP operate over the Internet, which is divided into autonomous systems. These systems are characterized by their heterogeneity as IP networks are realized by a multitude of technologies.
TCP等传输协议在互联网上运行，互联网被划分为自治系统。这些系统的特点是其异构性，因为IP网络是通过多种技术实现的。
Different conditions and their variations lead to correlation effects between policers that regulate traffic against certain conformance criteria.
不同的条件及其变化会导致警察之间的相关效应，这些警察根据特定的一致性标准来调节交通。
With the advent of techniques allowing for early detection of congestion, packet loss is no longer the sole metric of congestion. ECN (Explicit Congestion Notification) marks packets -- set by active queue management techniques -- to convey congestion information, trying to prevent packet losses (packet loss and the number of packets marked gives an indication of the level of congestion). Using TCP ACKs to feed back that information allows the hosts to realign their transmission rate and thus encourages them to efficiently use the network. In IP, ECN uses the two least significant bits of the (former) IPv4 Type of Service (TOS) octet or the (former) IPv6 Traffic Class octet [RFC2474] [RFC3260]. Further, ECN in TCP uses two bits in the TCP header that were previously defined as reserved [RFC793].
随着允许早期检测拥塞的技术的出现，分组丢失不再是拥塞的唯一度量。ECN（显式拥塞通知）标记数据包（由主动队列管理技术设置）以传递拥塞信息，试图防止数据包丢失（数据包丢失和标记的数据包数量指示拥塞级别）。使用TCP ACK反馈该信息可以使主机重新调整其传输速率，从而鼓励它们有效地使用网络。在IP中，ECN使用（前）IPv4服务类型（TOS）八位字节或（前）IPv6通信类八位字节[RFC2474][RFC3260]中的两个最低有效位。此外，TCP中的ECN使用TCP头中先前定义为保留[RFC793]的两个位。
ECN [RFC3168] is an example of a congestion feedback mechanism from the network toward hosts. The congestion-based feedback scheme, however, has limitations when applied on an inter-domain basis. Indeed, Sections 8 and 19 of [RFC3168] detail the implications of two possible attacks:
ECN[RFC3168]是从网络到主机的拥塞反馈机制的一个示例。然而，基于拥塞的反馈方案在域间应用时存在局限性。事实上，[RFC3168]第8节和第19节详细说明了两种可能攻击的含义：
1. non-compliance: a network erasing a Congestion Experienced (CE) codepoint introduced earlier on the path, and
1. 不合规性：网络擦除先前在路径上引入的拥塞体验（CE）码点，以及
2. subversion: a network changing Not ECN-Capable Transport (Not-ECT) to ECT.
2. subversion：将不支持ECN的传输（非ECT）更改为ECT的网络。
Both of these problems could allow an attacking network to cause excess congestion in an upstream network, even if the transports were behaving correctly. There are to date two possible solutions to the non-compliance problem (number 1 above): the ECN-nonce [RFC3540] and the [CONEX] work item inspired by the re-ECN incentive system
这两个问题都可能导致攻击网络在上游网络中造成过度拥塞，即使传输行为正常。迄今为止，有两种可能的不合规问题解决方案（上文第1项）：ECN nonce[RFC3540]和受re ECN激励系统启发的[CONEX]工作项
[Bri09]. Nevertheless, accidental rather than malicious erasure of ECN is an issue for IPv6 where the absence of an IPv6 header checksum implies that corruption of ECN could be more impacting than in the IPv4 case.
[09]。然而，意外而非恶意地擦除ECN是IPv6的一个问题，因为缺少IPv6报头校验和意味着ECN的损坏可能比IPv4的情况更具影响。
Fragmentation is another issue: the ECN-nonce cannot protect against misbehaving receivers that conceal marked fragments; thus, some protection is lost in situations where path MTU discovery is disabled. Note also that ECN-nonce wouldn't protect against the subversion issue (number 2 above) because, by definition, a Not-ECT packet comes from a source without ECN enabled, and therefore without the ECN-nonce enabled. So, there is still room for improvement on the ECN mechanism when operating in multi-domain networks.
碎片是另一个问题：ECN nonce不能防止隐藏标记碎片的行为不端的接收者；因此，在禁用路径MTU发现的情况下，会丢失一些保护。还要注意的是，ECN nonce不会防止subversion问题（上面的数字2），因为根据定义，Not ECT数据包来自未启用ECN的源，因此未启用ECN nonce。因此，在多域网络中运行时，ECN机制仍有改进的余地。
Operational/deployment experience is nevertheless required to determine the extent of these problems. The second problem is mainly related to deployment and usage practices and does not seem to result in any specific research challenge.
然而，要确定这些问题的严重程度，还需要操作/部署经验。第二个问题主要与部署和使用实践有关，似乎不会导致任何特定的研究挑战。
Another controversial solution in a multi-domain environment may be the TCP rate controller (TRC), a traffic conditioner that regulates the TCP flow at the ingress node in each domain by controlling packet drops and delays of the packets in a flow. The outgoing traffic from a TRC-controlled domain is shaped in such a way that no packets are dropped at the policer. However, the TRC interferes with the end-to-end TCP model, and thus it would interfere with past and future diversity of TCP implementations (violating the end-to-end principle). In particular, the TRC embeds the flow rate equality view of fairness in the network, and would prevent evolution to forms of fairness based on congestion-volume (Section 2.3).
多域环境中的另一个有争议的解决方案可能是TCP速率控制器（TRC），它是一种流量调节器，通过控制流中分组的丢包和延迟来调节每个域中入口节点处的TCP流。来自TRC控制域的传出流量以这样一种方式成形，即在policr处不丢弃任何分组。但是，TRC会干扰端到端TCP模型，因此它会干扰过去和未来TCP实现的多样性（违反端到端原则）。特别是，TRC在网络中嵌入了公平的流量平等观点，并将防止演变为基于拥塞量的公平形式（第2.3节）。
Security is a challenge for multi-domain exchange of explicit rate signals, whether in-band or out-of-band. At domain boundaries, authentication and authorization issues can arise whenever congestion control information is exchanged. From this perspective, the Internet does not so far have any security architecture for this problem.
对于显式速率信号的多域交换，无论是带内还是带外，安全性都是一个挑战。在域边界，每当交换拥塞控制信息时，就会出现身份验证和授权问题。从这个角度来看，到目前为止，互联网还没有针对这个问题的任何安全架构。
The future evolution of Internet inter-domain operation has to show whether more multi-domain information exchange can be effectively realized. This is of particular importance for congestion control schemes that make use of explicit per-datagram rate feedback (e.g., RCP or XCP) or explicit rate feedback that uses in-band congestion signaling (e.g., Quick-Start) or out-of-band signaling (e.g., CADPC/PTP). Explicit signaling exchanges at the inter-domain level that result in local domain triggers are currently absent from the
互联网跨域运营的未来演变必须表明是否能够有效地实现更多的多域信息交换。这对于使用显式每数据报速率反馈（例如，RCP或XCP）或使用带内拥塞信令（例如，快速启动）或带外信令（例如，CADPC/PTP）的显式速率反馈的拥塞控制方案尤其重要。在域间级别上导致本地域触发器的显式信令交换目前不存在于
Internet. From this perspective, security issues resulting from limited trust between different administrative units result in policy enforcement that exacerbates the difficulty encountered when explicit feedback congestion control information is exchanged between domains. Note that even though authentication mechanisms could be extended for this purpose (by recognizing that explicit rate schemes such as RCP or XCP have the same inter-domain security requirements and structure as IntServ), they suffer from the same scalability problems as identified in [RFC2208]. Indeed, in-band rate signaling or out-of-band per-flow traffic specification signaling (like in the Resource Reservation Protocol (RSVP)) results in similar scalability issues (see Section 3.1).
互联网从这个角度来看，由于不同管理单元之间的信任有限而导致的安全问题会导致策略执行，从而加剧了在域之间交换显式反馈拥塞控制信息时遇到的困难。请注意，尽管可以为此目的扩展身份验证机制（通过认识到显式速率方案（如RCP或XCP）具有与IntServ相同的域间安全要求和结构），但它们仍存在[RFC2208]中确定的可伸缩性问题。实际上，带内速率信令或带外每流流量规范信令（如资源预留协议（RSVP））会导致类似的可伸缩性问题（参见第3.1节）。
Also, many autonomous systems only exchange some limited amount of information about their internal state (topology hiding principle), even though having more precise information could be highly beneficial for congestion control. Indeed, revealing the internal network structure is highly sensitive in multi-domain network operations and thus also a concern when it comes to the deployability of congestion control schemes. For instance, a network-assisted congestion control scheme with explicit signaling could reveal more information about the internal network dimensioning than TCP does today.
此外，许多自治系统只交换一些关于其内部状态的有限信息（拓扑隐藏原理），即使拥有更精确的信息对拥塞控制非常有利。事实上，揭示内部网络结构在多域网络操作中是高度敏感的，因此当涉及到拥塞控制方案的可部署性时，也是一个值得关注的问题。例如，一个带有显式信令的网络辅助拥塞控制方案可以比现在的TCP揭示更多关于内部网络规模的信息。
Extending pseudowires across multiple domains poses specific issues. Pseudowires (PWs) [RFC3985] may carry non-TCP data flows (e.g., Time-Division Multiplexing (TDM) traffic or Constant Bit Rate (CBR) ATM traffic) over a multi-domain IP network. Structure-Agnostic TDM over Packet (SAToP) [RFC4553], Circuit Emulation Service over Packet Switched Network (CESoPSN) [RFC5086], and TDM over IP (TDMoIP) [RFC5087] are not responsive to congestion control as discussed in [RFC2914] (see also [RFC5033]). The same observation applies to ATM circuit emulating services (CESs) interconnecting CBR equipment (e.g., Private Branch Exchanges (PBX)) across a Packet Switched Network (PSN).
跨多个域扩展伪线带来了特定的问题。伪线（PW）[RFC3985]可在多域IP网络上承载非TCP数据流（例如，时分复用（TDM）通信量或恒定比特率（CBR）ATM通信量）。与结构无关的分组TDM（SAToP）[RFC4553]、分组交换网络电路仿真服务（CESoPSN）[RFC5086]和IP TDM（TDMoIP）[RFC5087]不响应[RFC2914]中讨论的拥塞控制（另请参见[RFC5033]）。同样的观察也适用于通过分组交换网络（PSN）互连CBR设备（例如，专用分支交换机（PBX））的ATM电路模拟服务（CESs）。
Moreover, it is not possible to simply reduce the flow rate of a TDM PW or an ATM PW when facing packet loss. Providers can rate-control corresponding incoming traffic, but they may not be able to detect that PWs carry TDM or CBR ATM traffic (mechanisms for characterizing the traffic's temporal properties may not necessarily be supported).
此外，当面临分组丢失时，不可能简单地降低TDM PW或ATM PW的流量。提供商可以对相应的传入流量进行速率控制，但他们可能无法检测到PWs承载TDM或CBR ATM流量（不一定支持描述流量时间特性的机制）。
This can be illustrated with the following example.
这可以用下面的例子来说明。
........... ............
. . .
S1 --- E1 --- . .
. | . .
. === E5 === E7 ---
. | . . |
S2 --- E2 --- . . |
. . . | |
........... . | v
. ----- R --->
........... . | ^
. . . | |
S3 --- E3 --- . . |
. | . . |
. === E6 === E8 ---
. | . .
S4 --- E4 --- . .
. . .
........... ............
........... ............
. . .
S1 --- E1 --- . .
. | . .
. === E5 === E7 ---
. | . . |
S2 --- E2 --- . . |
. . . | |
........... . | v
. ----- R --->
........... . | ^
. . . | |
S3 --- E3 --- . . |
. | . . |
. === E6 === E8 ---
. | . .
S4 --- E4 --- . .
. . .
........... ............
\---- P1 ---/ \---------- P2 -----
\---- P1 ---/ \---------- P2 -----
Sources S1, S2, S3, and S4 are originating TDM over IP traffic. P1 provider edges E1, E2, E3, and E4 are rate-limiting such traffic. The Service Level Agreement (SLA) of provider P1 with transit provider P2 is such that the latter assumes a BE traffic pattern and that the distribution shows the typical properties of common BE traffic (elastic, non-real time, non-interactive).
源S1、S2、S3和S4是发起的TDM-over-IP流量。P1提供商边缘E1、E2、E3和E4是速率限制这样的通信量。提供商P1与公交提供商P2之间的服务水平协议（SLA）使得后者假设BE流量模式，并且分布显示公共BE流量的典型特性（弹性、非实时、非交互）。
The problem arises for transit provider P2 because it is not able to detect that IP packets are carrying constant-bit-rate service traffic for which the only useful congestion control mechanism would rely on implicit or explicit admission control, meaning self-blocking or enforced blocking, respectively.
对于传输提供商P2，问题出现了，因为它无法检测到IP分组承载恒定比特率的服务流量，对于该流量，唯一有用的拥塞控制机制将依赖于隐式或显式接纳控制，这分别意味着自阻塞或强制阻塞。
Assuming P1 providers are rate-limiting BE traffic, a transit P2 provider router R may be subject to serious congestion as all TDM PWs cross the same router. TCP-friendly traffic (e.g., each flow within another PW) would follow TCP's AIMD algorithm of reducing the sending rate by half, in response to each packet drop. Nevertheless, the PWs carrying TDM traffic could take all the available capacity while other more TCP-friendly or generally congestion-responsive traffic reduced itself to nothing. Note here that the situation may simply occur because S4 suddenly turns on additional TDM channels.
假设P1提供商对BE流量进行速率限制，则传输P2提供商路由器R可能会受到严重拥塞的影响，因为所有TDM PW都会穿过同一路由器。TCP友好流量（例如，另一个PW中的每个流）将遵循TCP的AIMD算法，该算法将发送速率减少一半，以响应每个数据包丢失。然而，承载TDM流量的PWs可能会占用所有可用容量，而其他对TCP更友好或通常对拥塞做出响应的流量则会将其自身缩减为零。注意，这种情况可能只是因为S4突然打开额外的TDM信道而发生。
It is neither possible nor desirable to assume that edge routers will soon have the ability to detect the responsiveness of the carried traffic, but it is still important for transit providers to be able to police a fair, robust, responsive, and efficient congestion control technique in order to avoid impacting congestion-responsive Internet traffic. However, we must not require only certain specific responses to congestion to be embedded within the network, which would harm evolvability. So designing the corresponding mechanisms in the data and control planes still requires further investigation.
假设边缘路由器很快就能检测所承载流量的响应性既不可能也不可取，但对于公交供应商来说，能够监督一个公平、稳健、响应性强的，以及有效的拥塞控制技术，以避免影响拥塞响应的互联网流量。然而，我们不能只要求在网络中嵌入对拥塞的特定响应，这将损害可进化性。因此，在数据和控制平面上设计相应的机制仍需进一步研究。
Traffic initiated by so-called elastic applications adapts to the available bandwidth using feedback about the state of the network.
由所谓的弹性应用程序发起的通信量使用有关网络状态的反馈来适应可用带宽。
For elastic applications, the transport dynamically adjusts the data traffic sending rate to different network conditions. Examples encompass short-lived elastic traffic including HTTP and instant-messaging traffic, as well as long file transfers with FTP and applications targeted by [LEDBAT]. In brief, elastic data applications can show extremely different requirements and traffic characteristics.
对于弹性应用，传输根据不同的网络条件动态调整数据流量发送速率。示例包括短期弹性通信，包括HTTP和即时消息通信，以及使用FTP和[LEDBAT]针对的应用程序进行的长文件传输。简言之，弹性数据应用程序可以显示极其不同的需求和流量特征。
The idea to distinguish several classes of best-effort traffic types is rather old, since it would be beneficial to address the relative delay sensitivities of different elastic applications. The notion of traffic precedence was already introduced in [RFC791], and it was broadly defined as "An independent measure of the importance of this datagram". For instance, low-precedence traffic should experience lower average throughput than higher-precedence traffic. Several questions arise here: What is the meaning of "relative"? What is the role of the transport layer?
区分几类尽力而为的业务类型的想法相当古老，因为解决不同弹性应用的相对延迟敏感性将是有益的。[RFC791]中已经引入了流量优先的概念，它被广泛定义为“对该数据报重要性的独立度量”。例如，低优先级流量的平均吞吐量应低于高优先级流量。这里出现了几个问题：“相对”是什么意思？传输层的作用是什么？
The preferential treatment of higher-precedence traffic combined with appropriate congestion control mechanisms is still an open issue that may, depending on the proposed solution, impact both the host and the network precedence awareness, and thereby congestion control. [RFC2990] points out that the interactions between congestion control and DiffServ [RFC2475] remained unaddressed until recently.
优先处理优先级较高的流量并结合适当的拥塞控制机制仍然是一个悬而未决的问题，这可能会影响主机和网络的优先级意识，从而影响拥塞控制。[RFC2990]指出拥塞控制和DiffServ[RFC2475]之间的交互直到最近才得到解决。
Recently, a study and a potential solution have been proposed that introduce Guaranteed TFRC (gTFRC) [Lochin06]. gTFRC is an adaptation of TCP-Friendly Rate Control providing throughput guarantees for unicast flows over the DiffServ/Assured Forwarding (AF) class. The purpose of gTFRC is to distinguish the guaranteed part from the best-effort part of the traffic resulting from AF conditioning. The proposed congestion control has been specified and tested inside DCCP/CCID 3 for DiffServ/AF networks [Lochin07] [Jourjon08].
最近，一项研究和一个潜在的解决方案被提出，引入保证TFRC（gTFRC）[Lochin06]。gTFRC是TCP友好速率控制的一种改编，为DiffServ/Assured Forwarding（AF）类上的单播流提供吞吐量保证。gTFRC的目的是区分保证部分和AF调节产生的流量的最大努力部分。针对DiffServ/AF网络[Lochin07][Jourjon08]，已在DCCP/CCID 3中指定并测试了提议的拥塞控制。
Nevertheless, there is still work to be performed regarding lower-precedence traffic -- data transfers that are useful, yet not important enough to warrant significantly impairing other traffic. Examples of applications that could make use of such traffic are web caches and web browsers (e.g., for pre-fetching) as well as peer-to-peer applications. There are proposals for achieving low precedence on a pure end-to-end basis (e.g., TCP Low Priority (TCP-LP) [Kuzmanovic03]), and there is a specification for achieving it via router mechanisms [RFC3662]. It seems, however, that network-based lower-precedence mechanisms are not yet a common service on the Internet. Since early 2010, end-to-end mechanisms for lower precedence, e.g., [Shal10], have become common -- at least when competing with other traffic as part of its own queues (e.g., in a home router). But it is less clear whether users will be willing to make their background traffic yield to other people's foreground traffic, unless the appropriate incentives are created.
尽管如此，对于低优先级的通信量，仍有工作要做——数据传输是有用的，但还不足以保证显著损害其他通信量。可利用此类流量的应用程序示例包括web缓存和web浏览器（例如，用于预取）以及对等应用程序。有人建议在纯端到端的基础上实现低优先级（例如，TCP低优先级（TCP-LP）[Kuzmanovic03]），有一个通过路由器机制实现低优先级的规范[RFC3662]。然而，基于网络的低优先级机制似乎还不是互联网上的一种常见服务。自2010年初以来，用于较低优先级的端到端机制（如[Shal10]）已变得普遍——至少在与其他流量作为其自身队列的一部分竞争时是如此（如在家庭路由器中）。但不太清楚用户是否愿意让他们的背景流量屈从于其他人的前景流量，除非制定适当的激励措施。
There is an issue over how to reconcile two divergent views of the relation between traffic class precedence and congestion control. One view considers that congestion signals (losses or explicit notifications) in one traffic class are independent of those in another. The other relates marking of the classes together within the active queue management (AQM) mechanism [Gibbens02]. In the independent case, using a higher-precedence class of traffic gives a higher scheduling precedence and generally lower congestion level. In the linked case, using a higher-precedence class of traffic still gives higher scheduling precedence, but results in a higher level of congestion. This higher congestion level reflects the extra congestion higher-precedence traffic causes to both classes combined. The linked case separates scheduling precedence from rate control. The end-to-end congestion control algorithm can separately choose to take a higher rate by responding less to the higher level of congestion. This second approach could become prevalent if weighted congestion controls were common. However, it is an open issue how the two approaches might co-exist or how one might evolve into the other.
对于交通等级优先和拥塞控制之间的关系，如何调和两种不同的观点是一个问题。一种观点认为，一个流量类别中的拥塞信号（丢失或显式通知）独立于另一个流量类别中的拥塞信号。另一种方法是在主动队列管理（AQM）机制中将类标记在一起[Gibbens02]。在独立的情况下，使用更高优先级的通信流可以提供更高的调度优先级，并且通常可以降低拥塞级别。在链接的情况下，使用更高优先级的流量类别仍然会提供更高的调度优先级，但会导致更高级别的拥塞。这一更高的拥塞级别反映了更高优先级的流量对这两个类别造成的额外拥塞。链接案例将调度优先级与速率控制分开。端到端拥塞控制算法可以通过对更高级别的拥塞做出更少的响应来分别选择采用更高的速率。如果加权拥塞控制很普遍，第二种方法可能会流行。然而，这两种方法如何共存或如何演变成另一种方法是一个悬而未决的问题。
In the current Internet architecture, congestion control depends on parties acting against their own interests. It is not in a receiver's interest to honestly return feedback about congestion on the path, effectively requesting a slower transfer. It is not in the sender's interest to reduce its rate in response to congestion if it can rely on others to do so. Additionally, networks may have strategic reasons to make other networks appear congested.
在当前的互联网架构中，拥塞控制依赖于违反自身利益的各方。诚实地返回关于路径拥塞的反馈，有效地请求较慢的传输，这不符合接收者的利益。如果发送方可以依赖其他方降低速率以应对拥塞，则降低速率不符合发送方的利益。此外，网络可能有战略原因使其他网络显得拥挤。
Numerous strategies to improve congestion control have already been identified. The IETF has particularly focused on misbehaving TCP receivers that could confuse a compliant sender into assigning excessive network and/or server resources to that receiver (e.g., [Savage99], [RFC3540]). But, although such strategies are worryingly powerful, they do not yet seem common (however, evidence of attack prevalence is itself a research requirement).
已经确定了许多改善拥塞控制的策略。IETF特别关注行为不当的TCP接收器，这些接收器可能会混淆合规发送方，使其向该接收器分配过多的网络和/或服务器资源（例如，[Savage99]，[RFC3540]）。但是，尽管这些策略令人担忧地强大，但它们似乎还不常见（然而，攻击流行的证据本身就是一项研究要求）。
A growing proportion of Internet traffic comes from applications designed not to use congestion control at all, or worse, applications that add more forward error correction as they experience more losses. Some believe the Internet was designed to allow such freedom, so it can hardly be called misbehavior. But others consider it misbehavior to abuse this freedom [RFC3714], given one person's freedom can constrain the freedom of others (congestion represents this conflict of interests). Indeed, leaving freedom unchecked might result in congestion collapse in parts of the Internet. Proportionately, large volumes of unresponsive voice traffic could represent such a threat, particularly for countries with less generous provisioning [RFC3714]. Also, Internet video on demand services that transfer much greater data rates without congestion control are becoming popular. In general, it is recommended that such UDP applications use some form of congestion control [RFC5405].
越来越多的互联网流量来自于完全不使用拥塞控制的应用程序，或者更糟糕的是，随着损失的增加，这些应用程序增加了更多的前向纠错功能。一些人认为互联网是为了允许这种自由而设计的，因此它很难被称为不当行为。但另一些人认为滥用这种自由是错误行为[RCF314]，因为一个人的自由可以约束他人的自由（拥堵代表了利益的冲突）。事实上，让自由不受约束可能会导致部分互联网的拥塞崩溃。相应地，大量无响应的语音通信可能构成这种威胁，特别是对于资源调配不那么慷慨的国家[RFC3714]。此外，在不进行拥塞控制的情况下传输更高数据速率的互联网视频点播服务也越来越流行。通常，建议此类UDP应用程序使用某种形式的拥塞控制[RFC5405]。
Note that the problem is not just misbehavior driven by a self-interested desire for more bandwidth. Indeed, congestion control may be attacked by someone who makes no gain for themselves, other than the satisfaction of harming others (see Security Considerations in Section 4).
请注意，问题不仅仅是出于对更多带宽的自利欲望而导致的不当行为。事实上，拥塞控制可能会受到某些人的攻击，这些人除了满足于伤害他人之外，对自己没有任何好处（参见第4节中的安全考虑）。
Open research questions resulting from these considerations are:
这些考虑因素导致的开放性研究问题包括：
- By design, new congestion control protocols need to enable one end to check the other for protocol compliance. How would such mechanisms be designed?
- 根据设计，新的拥塞控制协议需要允许一端检查另一端是否符合协议。如何设计这种机制？
- Which congestion control primitives could safely satisfy more demanding applications (smoother than TFRC, faster than high-speed TCPs), so that application developers and users do not turn off congestion control to get the rate they expect and need?
- 哪些拥塞控制原语可以安全地满足要求更高的应用程序（比TFRC更平滑，比高速TCP更快），从而使应用程序开发人员和用户不会关闭拥塞控制以获得他们期望和需要的速率？
Note also that self-restraint could disappear from the Internet. So, it may no longer be sufficient to rely on developers/users voluntarily submitting themselves to congestion control. As a consequence, mechanisms to enforce fairness (see Sections 2.3, 3.4, and 3.5) need to have more emphasis within the research agenda.
还要注意的是，自我约束可能会从互联网上消失。因此，仅仅依靠开发者/用户自愿接受拥塞控制可能已经不够了。因此，加强公平性的机制（见第2.3、3.4和3.5节）需要在研究议程中得到更多的重视。
This section provides additional challenges and open research issues that are not (at this point in time) deemed so significant, or they are of a different nature compared to the main challenges depicted so far.
本节提供了其他挑战和开放性研究问题，这些问题（目前）并不重要，或者与迄今为止描述的主要挑战相比性质不同。
Several congestion control schemes have to precisely know the round-trip time (RTT) of a path. The RTT is a measure of the current delay on a network. It is defined as the delay between the sending of a packet and the reception of a corresponding response, if echoed back immediately by the receiver upon receipt of the packet. This corresponds to the sum of the one-way delay of the packet and the (potentially different) one-way delay of the response. Furthermore, any RTT measurement also includes some additional delay due to the packet processing in both end-systems.
一些拥塞控制方案必须精确地知道路径的往返时间（RTT）。RTT是网络上当前延迟的度量。它被定义为发送数据包和接收相应响应之间的延迟，如果接收器在收到数据包后立即回显。这对应于分组的单向延迟和响应的（可能不同的）单向延迟之和。此外，任何RTT测量还包括由于两个终端系统中的分组处理而产生的一些额外延迟。
There are various techniques to measure the RTT: active measurements inject special probe packets into the network and then measure the response time, using, e.g., ICMP. In contrast, passive measurements determine the RTT from ongoing communication processes, without sending additional packets.
测量RTT有多种技术：主动测量将特殊探测数据包注入网络，然后使用ICMP等测量响应时间。相反，被动测量通过正在进行的通信过程确定RTT，而不发送额外的数据包。
The connection endpoints of transport protocols such as TCP, the Stream Control Transmission Protocol (SCTP), and DCCP, as well as several application protocols, keep track of the RTT in order to dynamically adjust protocol parameters such as the retransmission timeout (RTO) or the rate-control equation. They can implicitly measure the RTT on the sender side by observing the time difference between the sending of data and the arrival of the corresponding acknowledgments. For TCP, this is the default RTT measurement procedure; it is used in combination with Karn's algorithm, which prohibits RTT measurements from retransmitted segments [RFC2988]. Traditionally, TCP implementations take one RTT measurement at a time (i.e., about once per RTT). As an alternative, the TCP timestamp option [RFC1323] allows more frequent explicit measurements, since a sender can safely obtain an RTT sample from every received acknowledgment. In principle, similar measurement mechanisms are used by protocols other than TCP.
传输协议（如TCP、流控制传输协议（SCTP）和DCCP）以及若干应用协议的连接端点跟踪RTT，以便动态调整协议参数，如重传超时（RTO）或速率控制方程。他们可以通过观察数据发送和相应确认到达之间的时间差，隐式地测量发送方的RTT。对于TCP，这是默认的RTT测量过程；它与Karn算法结合使用，Karn算法禁止RTT测量来自重传段[RFC2988]。传统上，TCP实现一次只进行一次RTT测量（即，大约每个RTT一次）。作为替代方案，TCP时间戳选项[RFC1323]允许更频繁的显式测量，因为发送方可以从每个接收到的确认中安全地获得RTT样本。原则上，TCP以外的协议也使用类似的测量机制。
Sometimes it would be beneficial to know the RTT not only at the sender, but also at the receiver, e.g., to find the one-way variation in delay due to one-way congestion. A passive receiver can deduce some information about the RTT by analyzing the sequence numbers of received segments. But this method is error-prone and only works if the sender permanently sends data. Other network entities on the
有时，不仅在发送方，而且在接收方了解RTT是有益的，例如，发现由于单向拥塞引起的单向延迟变化。无源接收机可以通过分析接收段的序列号来推断RTT的一些信息。但是这种方法容易出错，并且只有在发送方永久发送数据时才有效。网络上的其他网络实体
path can apply similar heuristics in order to approximate the RTT of a connection, but this mechanism is protocol-specific and requires per-connection state. In the current Internet, there is no simple and safe solution to determine the RTT of a connection in network entities other than the sender. The more fundamental question is to determine whether it is necessary or not for network elements to measure or know the RTT.
path可以应用类似的启发式方法来近似连接的RTT，但这种机制是特定于协议的，并且需要每个连接状态。在当前的Internet中，除了发送方之外，没有简单而安全的解决方案来确定网络实体中连接的RTT。更基本的问题是确定网元是否有必要测量或了解RTT。
As outlined earlier in this document, the round-trip time is typically not a constant value. For a given path, there is a theoretical minimum value, which is given by the minimum transmission, processing, and propagation delay on that path. However, additional variable delays might be caused by congestion, cross-traffic, shared-media access control schemes, recovery procedures, or other sub-IP layer mechanisms. Furthermore, a change of the path (e.g., route flapping, hand-over in mobile networks) can result in completely different delay characteristics.
如本文件前面所述，往返时间通常不是一个常量。对于给定的路径，存在一个理论最小值，该值由该路径上的最小传输、处理和传播延迟给出。但是，拥塞、交叉流量、共享媒体访问控制方案、恢复过程或其他子IP层机制可能会导致额外的可变延迟。此外，路径的改变（例如，移动网络中的路由摆动、切换）可导致完全不同的延迟特性。
Due to this variability, one single measured RTT value is hardly sufficient to characterize a path. This is why many protocols use RTT estimators that derive an averaged value and keep track of a certain history of previous samples. For instance, TCP endpoints derive a smoothed round-trip time (SRTT) from an exponential weighted moving average [RFC2988]. Such a low-pass filter ensures that measurement noise and single outliers do not significantly affect the estimated RTT. Still, a fundamental drawback of low-pass filters is that the averaged value reacts more slowly to sudden changes in the measured RTT. There are various solutions to overcome this effect: For instance, the standard TCP retransmission timeout calculation considers not only the SRTT, but also a measure for the variability of the RTT measurements [RFC2988]. Since this algorithm is not well suited for frequent RTT measurements with timestamps, certain implementations modify the weight factors (e.g., [Sarola02]). There are also proposals for more sophisticated estimators, such as Kalman filters or estimators that utilize mainly peak values.
由于这种可变性，单个测量的RTT值几乎不足以描述路径。这就是为什么许多协议使用RTT估计器来推导平均值并跟踪以前样本的特定历史。例如，TCP端点从指数加权移动平均[RFC2988]推导出平滑往返时间（SRTT）。这种低通滤波器确保测量噪声和单个异常值不会显著影响估计的RTT。尽管如此，低通滤波器的一个基本缺点是，平均值对测量RTT的突然变化的反应更慢。有多种解决方案可以克服这种影响：例如，标准TCP重传超时计算不仅考虑SRTT，还考虑RTT测量的可变性[RFC2988]。由于该算法不适合于带有时间戳的频繁RTT测量，因此某些实现修改了权重因子（例如，[Sarola2]）。也有人建议使用更复杂的估计器，如卡尔曼滤波器或主要利用峰值的估计器。
However, open questions related to RTT estimation in the Internet remain:
然而，与互联网RTT估算相关的开放性问题仍然存在：
- Optimal measurement frequency: Currently, there is no theory or common understanding of the right time scale of RTT measurement. In particular, the necessity for rather frequent measurements (e.g., per packet) is not well understood. There is some empirical evidence that such frequent sampling may not have a significant benefit [Allman99].
- 最佳测量频率：目前，对于RTT测量的正确时间尺度没有理论或共识。特别是，对相当频繁的测量（例如，每个数据包）的必要性还没有很好地理解。有一些经验证据表明，这种频繁的抽样可能没有显著的好处[Allman99]。
- Filter design: A closely related question is how to design good filters for the measured samples. The existing algorithms are known to be robust, but they are far from being perfect. The fundamental problem is that there is no single set of RTT values that could characterize the Internet as a whole, i.e., it is hard to define a design target.
- 过滤器设计：一个密切相关的问题是如何为测量样本设计好过滤器。已知现有的算法是健壮的，但它们还远远不够完美。基本问题是，没有一组RTT值可以作为整个互联网的特征，也就是说，很难定义设计目标。
- Default values: RTT estimators can fail in certain scenarios, e.g., when any feedback is missing. In this case, default values have to be used. Today, most default values are set to conservative values that may not be optimal for most Internet communication. Still, the impact of more aggressive settings is not well understood.
- 默认值：RTT估计器在某些情况下可能失败，例如，当任何反馈丢失时。在这种情况下，必须使用默认值。如今，大多数默认值都设置为保守值，这对于大多数Internet通信来说可能不是最佳值。尽管如此，人们对更具攻击性的环境的影响还没有很好的理解。
- Clock granularities: RTT estimation depends on the clock granularities of the protocol stacks. Even though there is a trend toward higher-precision timers, limited granularity (particularly on low-cost devices) may still prevent highly accurate RTT estimations.
- 时钟粒度：RTT估计取决于协议栈的时钟粒度。尽管有更高精度计时器的趋势，但有限的粒度（特别是在低成本设备上）仍可能阻止高精度RTT估计。
There is a long history of malfunctioning devices harming the deployment of new and potentially beneficial functionality in the Internet. Sometimes, such devices drop packets or even crash completely when a certain mechanism is used, causing users to opt for reliability instead of performance and disable the mechanism, or operating-system vendors to disable it by default. One well-known example is ECN, whose deployment was long hindered by malfunctioning firewalls and is still hindered by malfunctioning home-hubs, but there are many other examples (e.g., the Window Scaling option of TCP) [Thaler07].
长期以来，出现故障的设备损害了互联网上新的和潜在的有益功能的部署。有时，当使用某种机制时，此类设备会丢弃数据包，甚至完全崩溃，导致用户选择可靠性而不是性能，并禁用该机制，或者操作系统供应商默认禁用该机制。一个众所周知的例子是ECN，它的部署长期以来受到防火墙故障的阻碍，并且仍然受到家庭集线器故障的阻碍，但还有许多其他例子（例如TCP的窗口缩放选项）[Thaler07]。
As new congestion control mechanisms are developed with the intention of eventually seeing them deployed in the Internet, it would be useful to collect information about failures caused by devices of this sort, analyze the reasons for these failures, and determine whether there are ways for such devices to do what they intend to do without causing unintended failures. Recommendations for vendors of these devices could be derived from such an analysis. It would also be useful to see whether there are ways for failures caused by such devices to become more visible to endpoints, or to the maintainers of such devices.
由于开发新的拥塞控制机制的目的是最终在互联网上部署它们，因此收集此类设备导致的故障信息，分析这些故障的原因，并确定此类设备是否有方法在不造成意外故障的情况下完成其预期任务。通过这样的分析，可以得出对这些设备供应商的建议。看看是否有办法使这些设备引起的故障对端点或这些设备的维护人员更加可见，这也是很有用的。
A possible way to reduce such problems in the future would be guidelines for standards authors to ensure that "forward compatibility" is considered in all IETF work. That is, the default behavior of a device should be precisely defined for all possible
未来减少此类问题的一种可能方法是为标准制定者提供指南，以确保在所有IETF工作中考虑“前向兼容性”。也就是说，设备的默认行为应该在所有可能的情况下精确定义
values and combinations of protocol fields, and not just the minimum necessary for the protocol being defined. Then, when previously unused or reserved fields start to be used by newer devices to comply with a new standard, older devices encountering unusual fields should at least behave predictably.
协议字段的值和组合，而不仅仅是定义协议所需的最小值。然后，当更新的设备开始使用以前未使用或保留的字段以符合新标准时，遇到异常字段的旧设备至少应具有可预测的行为。
AIMD window algorithms that have the goal of packet conservation end up converging on a rate that is inversely proportional to RTT. However, control theoretic approaches to stability have shown that only the increase in rate (acceleration), and not the target rate, needs to be inversely proportional to RTT [Jin04].
以数据包保护为目标的AIMD窗口算法最终以与RTT成反比的速率收敛。然而，稳定性的控制理论方法表明，只有速率（加速度）的增加，而不是目标速率，需要与RTT成反比[Jin04]。
It is possible to have more aggressive behaviors for some demanding applications as long as they are part of a mix with less aggressive transports [Key04]. This beneficial effect of transport type mixing is probably how the Internet currently manages to remain stable even in the presence of TCP slow-start, which is more aggressive than the theory allows for stability. Research giving deeper insight into these aspects would be very useful.
对于某些要求较高的应用程序，只要它们是与攻击性较低的传输混合的一部分，就可能有更具攻击性的行为[Key04]。传输类型混合的这种有益影响可能是互联网目前如何在TCP慢启动的情况下保持稳定，而TCP慢启动比理论允许的稳定性更具攻击性。深入了解这些方面的研究将非常有用。
A network of IP nodes is just as vulnerable to congestion in the lower layers between IP-capable nodes as it is to congestion on the IP-capable nodes themselves. If network elements take a greater part in congestion control (ECN, XCP, RCP, etc. -- see Section 3.1), these techniques will either need to be deployed at lower layers as well, or they will need to interwork with lower-layer mechanisms.
IP节点网络在支持IP的节点之间的较低层中容易发生拥塞，就像在支持IP的节点上容易发生拥塞一样。如果网元在拥塞控制（ECN、XCP、RCP等）中扮演更大的角色——参见第3.1节），则这些技术要么也需要部署在较低层，要么需要与较低层机制交互。
[RFC5129] shows how to propagate ECN from lower layers upwards for the specific case of MPLS, but to the authors' knowledge the layering problem has not been addressed for explicit rate protocol proposals such as XCP and RCP. Some issues are straightforward matters of interoperability (e.g., how exactly to copy fields up the layers) while others are less obvious (e.g., re-framing issues: if RCP were deployed in a lower layer, how might multiple small RCP frames, all with different rates in their headers, be assembled into a larger IP layer datagram?).
[RFC5129]展示了如何在MPLS的特定情况下从较低层向上传播ECN，但据作者所知，对于XCP和RCP等显式速率协议提案，尚未解决分层问题。一些问题是直接的互操作性问题（例如，如何准确地将字段复制到各层），而另一些问题则不太明显（例如，重新框架问题：如果RCP部署在较低的层中，那么如何将多个小RCP帧（所有帧头中的速率不同）组装成一个较大的IP层数据报？）。
Multi-layer considerations also confound many mechanisms that aim to discover whether every node on the path supports a new congestion control protocol. For instance, some proposals maintain a secondary Time to Live (TTL) field parallel to that in the IP header. Any nodes that support the new behavior update both TTL fields, whereas legacy IP nodes will only update the IP TTL field. This allows the endpoints to check whether all IP nodes on the path support the new
多层考虑还混淆了许多旨在发现路径上的每个节点是否支持新的拥塞控制协议的机制。例如，一些提案维护一个与IP报头中的字段平行的次要生存时间（TTL）字段。任何支持新行为的节点都会更新两个TTL字段，而传统IP节点只会更新IP TTL字段。这允许端点检查路径上的所有IP节点是否支持新的
behavior, in which case both TTLs will be equal at the receiver. But mechanisms like these overlook nodes at lower layers that might not support the new behavior.
行为，在这种情况下，两个TTL在接收器处相等。但是像这样的机制忽略了可能不支持新行为的较低层的节点。
A further related issue is congestion control across overlay networks of relays [Hilt08] [Noel07] [Shen08].
另一个相关问题是中继重叠网络的拥塞控制[Hilt08][Noel07][Shen08]。
Section 3.5.3 deals with inelastic multi-domain pseudowires (PWs), where the identity of the pseudowire itself implies the characteristics of the traffic crossing the multi-domain PSN (independently of the actual characteristics of the traffic carried in the PW). A more complex situation arises when inelastic traffic is carried as part of a pseudowire (e.g., inelastic traffic over Ethernet PW over PSN) whose edges do not have the means to characterize the properties of the traffic encapsulated in the Ethernet frames. In this case, the problem explained in Section 3.5.3 is not limited to multi-domain pseudowires but more generally arises from a "pseudowire carrying inelastic traffic" (whether over a single- or multi-domain PSN).
第3.5.3节涉及非弹性多域伪线（PW），其中伪线本身的特性意味着穿过多域PSN的流量特性（独立于PW中承载的流量的实际特性）。当非弹性业务作为伪线（例如，通过以太网PW通过PSN的非弹性业务）的一部分承载时，会出现更复杂的情况，其边缘无法表征封装在以太网帧中的业务的特性。在这种情况下，第3.5.3节中解释的问题不限于多域伪线，而是更一般地由“承载非弹性业务的伪线”（无论是单域PSN还是多域PSN）引起。
The problem becomes even more intricate when the Ethernet PW carries both inelastic and elastic traffic. Addressing this issue further supports our observation that a general framework to efficiently deal with congestion control problems in multi-layer networks without harming evolvability is absolutely necessary.
当以太网PW同时承载非弹性和弹性流量时，问题变得更加复杂。解决这个问题进一步支持我们的观察，即在不损害可进化性的情况下，有效处理多层网络中的拥塞控制问题的通用框架是绝对必要的。
Recent work has shown that multipath endpoint congestion control [Kelly05] offers considerable benefits in terms of resilience and resource usage efficiency. The IETF has since initiated a work item on multipath TCP [MPTCP]. By pooling the resources on all paths, even nodes not using multiple paths benefit from those that are.
最近的研究表明，多路径端点拥塞控制[Kelly05]在恢复能力和资源使用效率方面提供了相当大的好处。此后，IETF启动了多路径TCP[MPTCP]的工作项。通过汇集所有路径上的资源，即使不使用多条路径的节点也能从使用多条路径的节点中获益。
There is considerable further research to do in this area, particularly to understand interactions with network-operator-controlled route provisioning and traffic engineering, and indeed whether multipath congestion control can perform better traffic engineering than the network itself, given the right incentives [Arkko09].
在这一领域还有大量的进一步研究要做，特别是要了解与网络运营商控制的路由供应和流量工程的相互作用，以及在适当的激励条件下，多径拥塞控制是否能够比网络本身执行更好的流量工程[Arkko09]。
An increasing number of application layer gateways (ALGs), middleboxes, and proxies (see Section 3.6 of [RFC2775]) are deployed at domain boundaries to verify conformance but also filter traffic
越来越多的应用层网关（ALG）、中间盒和代理（见[RFC2775]第3.6节）部署在域边界，以验证一致性，同时过滤流量
and control flows. One motivation is to prevent information beyond routing data leaking between autonomous systems. These systems split up end-to-end TCP connections and disrupt end-to-end congestion control. Furthermore, transport over encrypted tunnels may not allow other network entities to participate in congestion control.
和控制流量。一个动机是防止自治系统之间路由数据之外的信息泄漏。这些系统会分割端到端TCP连接并中断端到端拥塞控制。此外，加密隧道上的传输可能不允许其他网络实体参与拥塞控制。
Basically, such systems disrupt the primal and dual congestion control components. In particular, end-to-end congestion control may be replaced by flow-control backpressure mechanisms on the split connections. A large variety of ALGs and middleboxes use such mechanisms to improve the performance of applications (Performance Enhancing Proxies, Application Accelerators, etc.). However, the implications of such mechanisms, which are often proprietary and not documented, have not been studied systematically so far.
基本上，这样的系统破坏了原始和双重拥塞控制组件。特别是，端到端拥塞控制可以被分流连接上的流量控制背压机制所取代。大量ALG和中间盒使用此类机制来提高应用程序的性能（性能增强代理、应用程序加速器等）。然而，迄今为止尚未系统地研究这些机制的影响，这些机制往往是专有的，没有记录在案。
There are two levels of interference:
有两种级别的干扰：
- The "transparent" case, i.e., the endpoint address from the sender perspective is still visible to the receiver (the destination IP address). Relay systems that intercept payloads but do not relay congestion control information provide an example. Such middleboxes can prevent the operation of end-to-end congestion control.
- “透明”情况，即从发送方的角度来看，端点地址对接收方仍然可见（目标IP地址）。拦截有效负载但不中继拥塞控制信息的中继系统提供了一个示例。这种中间盒可以阻止端到端拥塞控制的运行。
- The "non-transparent" case, which causes fewer problems for congestion control. Although these devices interfere with end-to-end network transparency, they correctly terminate network, transport, and application layer protocols on both sides, which individually can be congestion controlled.
- “不透明”的情况，导致拥塞控制问题较少。尽管这些设备会干扰端到端网络的透明性，但它们会正确终止双方的网络、传输和应用层协议，这些协议可以单独进行拥塞控制。
Misbehavior may be driven by pure malice, or malice may in turn be driven by wider selfish interests, e.g., using distributed denial-of-service (DDoS) attacks to gain rewards by extortion [RFC4948]. DDoS attacks are possible both because of vulnerabilities in operating systems and because the Internet delivers packets without requiring congestion control.
不当行为可能由纯粹的恶意驱动，或者恶意又可能由更广泛的私利驱动，例如，使用分布式拒绝服务（DDoS）攻击通过勒索获得奖励[RFC4948]。DDoS攻击是可能的，既因为操作系统中存在漏洞，也因为互联网在不需要拥塞控制的情况下传输数据包。
To date, compliance with congestion control rules and being fair require endpoints to cooperate. The possibility of uncooperative behavior can be regarded as a security issue; its implications are discussed throughout these documents in a scattered fashion.
迄今为止，遵守拥塞控制规则和公平要求端点进行合作。不合作行为的可能性可视为安全问题；其含义在这些文件中以分散的方式进行了讨论。
Currently the focus of the research agenda against denial of service is about identifying attack-packets that attack machines and the networks hosting them, with a particular focus on mitigating source address spoofing. But if mechanisms to enforce congestion control
目前，针对拒绝服务的研究议程的重点是识别攻击机器和承载它们的网络的攻击数据包，特别是减少源地址欺骗。但如果有机制来实施拥塞控制
fairness were robust to both selfishness and malice [Bri06], they would also naturally mitigate denial of service against the network, which can be considered (from the perspective of a well-behaved Internet user) as a congestion control enforcement problem. Even some denial-of-service attacks on hosts (rather than the network) could be considered as a congestion control enforcement issue at the higher layer. But clearly there are also denial-of-service attacks that would not be solved by enforcing congestion control.
公平性对自私和恶意都具有鲁棒性[Bri06]，它们还可以自然地缓解针对网络的拒绝服务，这可以被视为（从行为良好的互联网用户的角度）拥塞控制实施问题。甚至对主机（而不是网络）的某些拒绝服务攻击也可以被视为更高层的拥塞控制实施问题。但显然，也存在拒绝服务攻击，这些攻击无法通过实施拥塞控制来解决。
Sections 3.5 and 3.7 on multi-domain issues and misbehaving senders and receivers also discuss some information security issues suffered by various congestion control approaches.
关于多域问题和行为不端的发送方和接收方的第3.5节和第3.7节还讨论了各种拥塞控制方法所面临的一些信息安全问题。
[Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", Proceedings of ACM SIGCOMM'99, September 1999.
[Allman99]Allman，M.和V.Paxson，“关于估算端到端网络路径属性”，ACM SIGCOMM'99会议记录，1999年9月。
[Andrew05] Andrew, L., Wydrowski, B., and S. Low, "An Example of Instability in XCP", Manuscript available at <http://netlab.caltech.edu/maxnet/XCP_instability.pdf>.
[Andrew05]Andrew，L.，Wydrowski，B.，和S.Low，“XCP中不稳定的一个例子”，手稿可在<http://netlab.caltech.edu/maxnet/XCP_instability.pdf>.
[Arkko09] Arkko, J., Briscoe, B., Eggert, L., Feldmann, A., and M. Handley, "Dagstuhl Perspectives Workshop on End-to-End Protocols for the Future Internet," ACM SIGCOMM Computer Communication Review, Vol. 39, No. 2, pp. 42-47, April 2009.
[Arkko09]Arkko，J.，Briscoe，B.，Eggert，L.，Feldmann，A.，和M.Handley，“关于未来互联网端到端协议的Dagstuhl展望研讨会”，ACM SIGCOMM计算机通信评论，第39卷，第2期，第42-47页，2009年4月。
[Ath01] Athuraliya, S., Low, S., Li, V., and Q. Yin, "REM: Active Queue Management", IEEE Network Magazine, Vol. 15, No. 3, pp. 48-53, May 2001.
[Ath01]Athuraliya，S.，Low，S.，Li，V.，and Q.Yin，“REM:主动队列管理”，IEEE网络杂志，第15卷，第3期，第48-53页，2001年5月。
[Balan01] Balan, R.K., Lee, B.P., Kumar, K.R.R., Jacob, L., Seah, W.K.G., and A.L. Ananda, "TCP HACK: TCP Header Checksum Option to Improve Performance over Lossy Links", Proceedings of IEEE INFOCOM'01, Anchorage (Alaska), USA, April 2001.
[Balan01]Balan，R.K.，Lee，B.P.，Kumar，K.R.R.，Jacob，L.，Seah，W.K.G.，和A.L.Ananda，“TCP黑客：TCP头校验和选项以改善有损链路的性能”，IEEE INFOCOM'01会议录，安克雷奇（阿拉斯加），美国，2001年4月。
[Bonald00] Bonald, T., May, M., and J.-C. Bolot, "Analytic Evaluation of RED Performance", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000.
[Bonald00]Bonald，T.，May，M.，和J.-C.Bolot，“红色性能的分析评估”，IEEE INFOCOM'00会议记录，以色列特拉维夫，2000年3月。
[Bri06] Briscoe, B., "Using Self-interest to Prevent Malice; Fixing the Denial of Service Flaw of the Internet", Workshop on the Economics of Securing the Information Infrastructure, October 2006, <http://wesii.econinfosec.org/draft.php?paper_id=19>.
[Bri06]Briscoe，B.，“利用自身利益防止恶意；修复互联网的拒绝服务漏洞”，信息基础设施安全经济学研讨会，2006年10月<http://wesii.econinfosec.org/draft.php?paper_id=19>.
[Bri07] Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", ACM SIGCOMM Computer Communication Review, Vol. 37, No. 2, pp. 63-74, April 2007.
[Bri07]Briscoe，B.，“流量公平：摧毁宗教”，ACM SIGCOMM计算机通信评论，第37卷，第2期，第63-74页，2007年4月。
[Bri08] Briscoe, B., Moncaster, T. and L. Burness, "Problem Statement: Transport Protocols Don't Have To Do Fairness", Work in Progress, July 2008.
[Bri08]Briscoe，B.，Moncaster，T.和L.Burness，“问题陈述：传输协议不必做到公平”，正在进行的工作，2008年7月。
[Bri09] Briscoe, B., "Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork", UCL PhD Thesis (2009).
[Bri09]Briscoe，B.，“重新反馈：在无连接的互联网中造成拥塞的责任自由”，加州大学学院博士论文（2009年）。
[Bri10] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification," Work in Progress, October 2010.
[Bri10]Briscoe，B.和J.Way，“字节和数据包拥塞通知”，正在进行的工作，2010年10月。
[Chester04] Chesterfield, J., Chakravorty, R., Banerjee, S., Rodriguez, P., Pratt, I., and J. Crowcroft, "Transport level optimisations for streaming media over wide-area wireless networks", WIOPT'04, March 2004.
[Chester04]切斯特菲尔德，J.，查克拉沃蒂，R.，班纳吉，S.，罗德里格斯，P.，普拉特，I.，和J.克劳克罗夫特，“广域无线网络流媒体的传输级优化”，WIOPT'04，2004年3月。
[Chhabra02] Chhabra, P., Chuig, S., Goel, A., John, A., Kumar, A., Saran, H., and R. Shorey, "XCHOKe: Malicious Source Control for Congestion Avoidance at Internet Gateways," Proceedings of IEEE International Conference on Network Protocols (ICNP'02), Paris, France, November 2002.
[Chhabra02]Chhabra，P.，Chuig，S.，Goel，A.，John，A.，Kumar，A.，Saran，H.，和R.Shorey，“XCHOKe：互联网网关上避免拥塞的恶意源控制”，IEEE网络协议国际会议录（ICNP'02），法国巴黎，2002年11月。
[Chiu89] Chiu, D.M. and R. Jain, "Analysis of the increase and decrease algorithms for congestion avoidance in computer networks", Computer Networks and ISDN Systems, Vol. 17, pp. 1-14, 1989.
[Chiu89]Chiu，D.M.和R.Jain，“计算机网络中避免拥塞的增减算法分析”，计算机网络和ISDN系统，第17卷，第1-14页，1989年。
[Clark88] Clark, D., "The design philosophy of the DARPA internet protocols", ACM SIGCOMM Computer Communication Review, Vol. 18, No. 4, pp. 106-114, August 1988.
[Clark88]Clark，D.，“DARPA互联网协议的设计理念”，ACM SIGCOMM计算机通信评论，第18卷，第4期，第106-114页，1988年8月。
[Clark98] Clark, D. and W. Fang, "Explicit Allocation of Best-Effort Packet Delivery Service", IEEE/ACM Transactions on Networking, Vol. 6, No. 4, pp. 362-373, August 1998.
[Clark98]Clark，D.和W.Fang，“尽力而为数据包交付服务的明确分配”，IEEE/ACM网络交易，第6卷，第4期，第362-373页，1998年8月。
[Chu10] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", Work in Progress, October 2010.
[Chu10]Chu，J.，Dukkipati，N.，Cheng，Y.，和M.Mathis，“增加TCP的初始窗口”，正在进行的工作，2010年10月。
[CONEX] IETF WG Action: Congestion Exposure (conex).
[CONEX]IETF工作组行动：拥塞暴露（CONEX）。
[Dukki05] Dukkipati, N., Kobayashi, M., Zhang-Shen, R., and N. McKeown, "Processor Sharing Flows in the Internet", Proceedings of International Workshop on Quality of Service (IWQoS'05), Passau, Germany, June 2005.
[Dukki05]Dukkipati，N.，Kobayashi，M.，Zhang Shen，R.，和N.McKeown，“互联网中的处理器共享流”，服务质量国际研讨会论文集（IWQoS'05），帕索，德国，2005年6月。
[Dukki06] Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is the Right Metric for Congestion Control", ACM SIGCOMM Computer Communication Review, Vol. 36, No. 1, January 2006.
[Dukki06]Dukkipati，N.和N.McKeown，“为什么流量完成时间是拥塞控制的正确度量”，ACM SIGCOMM计算机通信评论，第36卷，第1期，2006年1月。
[ECODE] "ECODE Project", European Commission Seventh Framework Program, Grant No. 223936, <http://www.ecode-project.eu>.
[ECODE]“ECODE项目”，欧盟委员会第七框架计划，批准号223936<http://www.ecode-project.eu>.
[Falk07] Falk, A., Pryadkin, Y., and D. Katabi, "Specification for the Explicit Control Protocol (XCP)", Work in Progress, January 2007.
[Falk07]Falk，A.，Pryadkin，Y.，和D.Katabi，“显式控制协议（XCP）规范”，正在进行的工作，2007年1月。
[Feldman04] Feldman, M., Papadimitriou, C., Chuang, J., and I. Stoica, "Free-Riding and Whitewashing in Peer-to-Peer Systems" Proceedings of ACM SIGCOMM Workshop on Practice and Theory of Incentives in Networked Systems (PINS'04) 2004.
[Feldman04]Feldman，M.，Papadimitriou，C.，Chuang，J.，和I.Stoica，“点对点系统中的搭便车和粉饰”，ACM SIGCOMM网络系统激励实践和理论研讨会论文集（PINS'04），2004年。
[Firoiu00] Firoiu, V. and M. Borden, "A Study of Active Queue Management for Congestion Control", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000.
[Firoiu 00]Firoiu，V.和M.Borden，“用于拥塞控制的主动队列管理研究”，IEEE INFOCOM'00会议记录，以色列特拉维夫，2000年3月。
[Floyd93] Floyd, S. and V. Jacobson, "Random early detection gateways for congestion avoidance", IEEE/ACM Transactions on Networking, Vol. 1, No. 4, pp. 397-413, August 1993.
[Floyd93]Floyd，S.和V.Jacobson，“避免拥塞的随机早期检测网关”，IEEE/ACM网络交易，第1卷，第4期，第397-413页，1993年8月。
[Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, Vol. 24, No. 5, pp. 10-23, October 1994.
[Floyd94]Floyd，S.，“TCP和显式拥塞通知”，ACM计算机通信评论，第24卷，第5期，第10-23页，1994年10月。
[Gibbens02] Gibbens, R. and Kelly, F., "On Packet Marking at Priority Queues", IEEE Transactions on Automatic Control, Vol. 47, No. 6, pp. 1016-1020, 2002.
[Gibbens02]Gibbens，R.和Kelly，F.，“优先队列上的数据包标记”，IEEE自动控制交易，第47卷，第6期，第1016-1020页，2002年。
[Ha08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A new TCP-friendly high-speed TCP variant", ACM SIGOPS Operating System Review, Vol. 42, No. 5, pp. 64-74, 2008.
[Ha08]Ha，S.，Rhee，I.，和L.Xu，“CUBIC：一种新的TCP友好型高速TCP变体”，ACM SIGOPS操作系统评论，第42卷，第5期，第64-74页，2008年。
[Hilt08] Hilt, V. and I. Widjaja, "Controlling Overload in Networks of SIP Servers", Proceedings of IEEE International Conference on Network Protocols (ICNP'08), Orlando (Florida), USA, October 2008.
[Hilt 08]Hilt，V.和I.Widjaja，“控制SIP服务器网络中的过载”，IEEE网络协议国际会议记录（ICNP'08），美国奥兰多（佛罗里达），2008年10月。
[Hollot01] Hollot, C., Misra, V., Towsley, D., and W.-B. Gong, "A Control Theoretic Analysis of RED", Proceedings of IEEE INFOCOM'01, Anchorage (Alaska), USA, April 2001.
[Hollot01]Hollot，C.，Misra，V.，Towsley，D.，和W.-B.Gong，“RED的控制理论分析”，IEEE INFOCOM'01会议记录，安克雷奇（阿拉斯加），美国，2001年4月。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of ACM SIGCOMM'88 Symposium, August 1988.
[Jacobson88]Jacobson，V.，“拥塞避免和控制”，ACM SIGCOMM'88研讨会论文集，1988年8月。
[Jain88] Jain, R. and K. Ramakrishnan, "Congestion Avoidance in Computer Networks with a Connectionless Network Layer: Concepts, Goals, and Methodology", Proceedings of IEEE Computer Networking Symposium, Washington DC, USA, April 1988.
[Jain88]Jain，R.和K.Ramakrishnan，“具有无连接网络层的计算机网络中的拥塞避免：概念、目标和方法”，IEEE计算机网络研讨会论文集，华盛顿特区，美国，1988年4月。
[Jain90] Jain, R., "Congestion Control in Computer Networks: Trends and Issues", IEEE Network, pp. 24-30, May 1990.
[Jain90]Jain，R.，“计算机网络中的拥塞控制：趋势和问题”，IEEE网络，第24-30页，1990年5月。
[Jin04] Jin, Ch., Wei, D.X., and S. Low, "FAST TCP: Motivation, Architecture, Algorithms, Performance", Proceedings of IEEE INFOCOM'04, Hong-Kong, China, March 2004.
[Jin04]Jin，Ch.，Wei，D.X.，和S.Low，“快速TCP：动机，架构，算法，性能”，IEEE INFOCOM'04会议记录，中国香港，2004年3月。
[Jourjon08] Jourjon, G., Lochin, E., and P. Senac, "Design, Implementation and Evaluation of a QoS-aware Transport Protocol", Elsevier Computer Communications, Vol. 31, No. 9, pp. 1713-1722, June 2008.
[Jourjon08]Jourjon，G.，Lochin，E.，和P.Senac，“QoS感知传输协议的设计、实施和评估”，爱思唯尔计算机通信，第31卷，第9期，第1713-1722页，2008年6月。
[Katabi02] Katabi, D., M. Handley, and C. Rohrs, "Internet Congestion Control for Future High Bandwidth-Delay Product Environments", Proceedings of ACM SIGCOMM'02 Symposium, August 2002.
[Katabi02]Katabi，D.，M.Handley和C.Rohrs，“未来高带宽延迟产品环境的互联网拥塞控制”，ACM SIGCOMM'02研讨会论文集，2002年8月。
[Katabi04] Katabi, D., "XCP Performance in the Presence of Malicious Flows", Proceedings of PFLDnet'04 Workshop, Argonne (Illinois), USA, February 2004.
[Katabi04]Katabi，D.，“存在恶意流时的XCP性能”，PFLDnet'04研讨会论文集，美国阿贡（伊利诺伊州），2004年2月。
[Kelly05] Kelly, F. and Th. Voice, "Stability of end-to-end algorithms for joint routing and rate control", ACM SIGCOMM Computer Communication Review, Vol. 35, No. 2, pp. 5-12, April 2005.
[Kelly05]Kelly，F.和Th。Voice，“用于联合路由和速率控制的端到端算法的稳定性”，《ACM SIGCOMM计算机通信评论》，第35卷，第2期，第5-12页，2005年4月。
[Kelly98] Kelly, F., Maulloo, A., and D. Tan, "Rate control in communication networks: shadow prices, proportional fairness, and stability", Journal of the Operational Research Society, Vol. 49, pp. 237-252, 1998.
[Kelly98]Kelly，F.，Malloo，A.，和D.Tan，“通信网络中的速率控制：影子价格、比例公平和稳定性”，《运筹学学会杂志》，第49卷，第237-252页，1998年。
[Keshav07] Keshav, S., "What is congestion and what is congestion control", Presentation at IRTF ICCRG Workshop, PFLDnet 2007, Los Angeles (California), USA, February 2007.
[Keshav07]Keshav，S.，“什么是拥堵，什么是拥堵控制”，在IRTF ICCRG研讨会上的演讲，PFLDnet 2007，美国洛杉矶（加利福尼亚），2007年2月。
[Key04] Key, P., Massoulie, L., Bain, A., and F. Kelly, "Fair Internet Traffic Integration: Network Flow Models and Analysis", Annales des Telecommunications, Vol. 59, No. 11-12, pp. 1338-1352, November-December 2004.
[Key04]Key，P.，Massoulie，L.，Bain，A.，和F.Kelly，“公平互联网流量整合：网络流量模型和分析”，《电信年鉴》，第59卷，第11-12期，第1338-1352页，2004年11月至12月。
[Krishnan04] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and M. Allman, "Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks", Computer Networks, Vol. 46, No. 3, October 2004.
[Krishnan04]Krishnan，R.，Sterbenz，J.，Eddy，W.，Partridge，C.，和M.Allman，“易出错无线和卫星网络的显式传输错误通知（ETEN）”，计算机网络，第46卷，第3期，2004年10月。
[Kuzmanovic03] Kuzmanovic, A. and E.W. Knightly, "TCP-LP: A Distributed Algorithm for Low Priority Data Transfer", Proceedings of IEEE INFOCOM'03, San Francisco (California), USA, April 2003.
[KuZnMaViV03]库茨曼诺维奇，A.和E.W. Knightly，“TCP-LP：一种低优先级数据传输的分布式算法”，IEEE ICOFCOM的03，旧金山（加利福尼亚），美国，2003年4月。
[LEDBAT] IETF WG Action: Low Extra Delay Background Transport (ledbat).
[LEDBAT]IETF工作组行动：低额外延迟背景传输（LEDBAT）。
[Lochin06] Lochin, E., Dairaine, L., and G. Jourjon, "Guaranteed TCP Friendly Rate Control (gTFRC) for DiffServ/AF Network", Work in Progress, August 2006.
[Lochin06]Lochin，E.，Dairaine，L.，和G.Jourjon，“DiffServ/AF网络的保证TCP友好速率控制（gTFRC）”，正在进行的工作，2006年8月。
[Lochin07] Lochin, E., Jourjon, G., and L. Dairaine, "Study and enhancement of DCCP over DiffServ Assured Forwarding class", 4th Conference on Universal Multiservice Networks (ECUMN 2007), Toulouse, France, February 2007.
[Lochin07]Lochin，E.，Jourjon，G.，和L.Dairaine，“区分服务保证转发类DCCP的研究和增强”，第四届通用多服务网络会议（ECUMN 2007），法国图卢兹，2007年2月。
[Low02] Low, S., Paganini, F., Wang, J., Adlakha, S., and J.C. Doyle, "Dynamics of TCP/RED and a Scalable Control", Proceedings of IEEE INFOCOM'02, New York (New Jersey), 2002.
[Low02]Low，S.，Paganini，F.，Wang，J.，Adlakha，S.，和J.C.Doyle，“TCP/RED的动态和可伸缩控制”，IEEE INFOCOM'02会议记录，纽约（新泽西），2002年。
[Low03.1] Low, S., "A duality model of TCP and queue management algorithms", IEEE/ACM Transactions on Networking, Vol. 11, No. 4, pp. 525-536, August 2003.
[Low03.1]Low，S.，“TCP和队列管理算法的二元模型”，IEEE/ACM网络事务，第11卷，第4期，第525-536页，2003年8月。
[Low03.2] Low, S., Paganini, F., Wang, J., and J. Doyle, "Linear stability of TCP/RED and a scalable control", Computer Networks Journal, Vol. 43, No. 5, pp. 633-647, December 2003.
[Low03.2]Low，S.，Paganini，F.，Wang，J.，和J.Doyle，“TCP/RED和可伸缩控制的线性稳定性”，计算机网络杂志，第43卷，第5期，第633-647页，2003年12月。
[Low05] Low, S., Andrew, L., and B. Wydrowski, "Understanding XCP: equilibrium and fairness", Proceedings of IEEE INFOCOM'05, Miami (Florida), USA, March 2005.
[Low05]Low，S.，Andrew，L.，和B.Wydrowski，“理解XCP：平衡和公平”，IEEE信息通信会议录，2005年3月，美国迈阿密（佛罗里达州）。
[MacK95] MacKie-Mason, J. and H. Varian, "Pricing Congestible Network Resources", IEEE Journal on Selected Areas in Communications, Advances in the Fundamentals of Networking, Vol. 13, No. 7, pp. 1141-1149, 1995.
[MacK95]MacKie Mason，J.和H.Varian，“拥挤网络资源的定价”，IEEE通信选定领域杂志，网络基础进展，第13卷，第7期，第1141-1149页，1995年。
[Mascolo01] Mascolo, S., Casetti, Cl., Gerla M., Sanadidi, M.Y., and R. Wang, "TCP Westwood: Bandwidth estimation for enhanced transport over wireless links", Proceedings of MOBICOM 2001, Rome, Italy, July 2001.
[Mascolo01]Mascolo，S.，Casetti，Cl.，Gerla M.，Sanadidi，M.Y.，和R.Wang，“TCP Westwood：无线链路上增强传输的带宽估计”，MOBICOM 2001年论文集，意大利罗马，2001年7月。
[Moors02] Moors, T., "A critical review of "End-to-end arguments in system design"", Proceedings of IEEE International Conference on Communications (ICC) 2002, New York City (New Jersey), USA, April/May 2002.
[Moors02]Moors，T.，“系统设计中端到端论点的批判性评论”，IEEE国际通信会议（ICC）2002年会议记录，美国纽约市（新泽西州），2002年4月/5月。
[MPTCP] IETF WG Action: Multipath TCP (mptcp).
[MPTCP]IETF工作组操作：多路径TCP（MPTCP）。
[Noel07] Noel, E. and C. Johnson, "Initial Simulation Results That Analyze SIP Based VoIP Networks Under Overload", International Teletraffic Congress (ITC'07), Ottawa, Canada, June 2007.
[Noel07]Noel，E.和C.Johnson，“分析过载情况下基于SIP的VoIP网络的初始模拟结果”，国际电信流量大会（ITC'07），加拿大渥太华，2007年6月。
[Padhye98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP Throughput: A Simple Model and Its Empirical Validation", University of Massachusetts (UMass), CMPSCI Tech. Report TR98-008, February 1998.
[PADHY98] PADHEE，J.，FiRiu，V.，Towsley，D.和J. Kurose，“建模TCP吞吐量：一个简单的模型和它的经验验证”，麻州大学（UMASS），CMPSCI Teal.报告Tr98－00，1998年2月。
[Pan00] Pan, R., Prabhakar, B., and K. Psounis, "CHOKe: a stateless AQM scheme for approximating fair bandwidth allocation", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000.
[Pan00]Pan，R.，Prabhakar，B.，和K.Psounis，“扼流圈：近似公平带宽分配的无状态AQM方案”，IEEE INFOCOM'00会议记录，以色列特拉维夫，2000年3月。
[Pap02] Papadimitriou, I. and G. Mavromatis, "Stability of Congestion Control Algorithms using Control Theory with an application to XCP", Technical Report, 2002. <http://www.stanford.edu/class/ee384y/projects/ reports/ionnis.pdf>.
[Pap02]Papadimitriou，I.和G.Mavromatis，“使用控制理论的拥塞控制算法的稳定性及其在XCP中的应用”，技术报告，2002年<http://www.stanford.edu/class/ee384y/projects/ reports/Ionis.pdf>。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701]Hanks，S.，Li，T.，Farinaci，D.，和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.
[RFC2208]Mankin，A.，Ed.，Baker，F.，Braden，B.，Bradner，S.，O'Dell，M.，Romanow，A.，Weinrib，A.，和L.Zhang，“资源保留协议（RSVP）--版本1适用性声明—一些部署指南”，RFC 2208，1997年9月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[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月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[RFC2637]Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.，和G.Zorn，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000.
[RFC2861]Handley，M.，Padhye，J.，和S.Floyd，“TCP拥塞窗口验证”，RFC 28612000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[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月。
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.
[RFC2990]Huston，G.，“IP QoS架构的下一步”，RFC 29902000年11月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[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月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC3517]Blanton，E.，Allman，M.，Fall，K.，和L.Wang，“基于保守选择确认（SACK）的TCP丢失恢复算法”，RFC 3517，2003年4月。
[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月。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662]Bless，R.，Nichols，K.，和K.Wehrle，“区分服务的低域行为（PDB）”，RFC 36622003年12月。
[RFC3714] Floyd, S., Ed., and J. Kempf, Ed., "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714]Floyd，S.，Ed.，和J.Kempf，Ed.，“IAB对互联网语音流量拥塞控制的关注”，RFC 3714，2004年3月。
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004.
[RFC3742]Floyd，S.，“具有大拥塞窗口的TCP有限慢启动”，RFC 3742，2004年3月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[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月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553]Vainstein，A.，Ed.，和YJ。Stein，Ed.“数据包上的结构不可知时分复用（TDM）（SAToP）”，RFC4553，2006年6月。
[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月。
[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月。
[RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007.
[RFC4828]Floyd，S.和E.Kohler，“TCP友好速率控制（TFRC）：小数据包（SP）变体”，RFC 48282007年4月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948]Andersson，L.，Davies，E.，和L.Zhang，“IAB 2006年3月9日至10日不必要交通研讨会报告”，RFC 4948，2007年8月。
[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月。
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007.
[RFC5086]Vainstein，A.，Ed.，Sasson，I.，Metz，E.，Frost，T.，和P.Pate，“分组交换网络上的结构感知时分多路复用（TDM）电路仿真服务（CESoPSN）”，RFC 5086，2007年12月。
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, December 2007.
[RFC5087]Stein，Y（J.），Shashoua，R.，Insler，R.，和M.Anavi，“IP时分多路复用（TDMoIP）”，RFC 5087，2007年12月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]Davie，B.，Briscoe，B.，和J.Tay，“MPLS中的显式拥塞标记”，RFC 5129，2008年1月。
[RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of Simple Best-Effort Traffic", RFC 5290, July 2008.
[RFC5290]Floyd，S.和M.Allman，“关于简单尽力而为流量有用性的评论”，RFC 52902008年7月。
[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月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, August 2009.
[RFC5622]Floyd，S.和E.Kohler，“数据报拥塞控制协议（DCCP）拥塞ID 4的配置文件：小数据包的TCP友好速率控制（TFRC-SP）”，RFC 5622，2009年8月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681 (Obsoletes RFC 2581), September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 5681（废弃RFC 2581），2009年9月。
[RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC Series", RFC 5783, February 2010.
[RFC5783]Welzl，M.和W.Eddy，“RFC系列中的拥塞控制”，RFC 5783，2010年2月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 60402010年11月。
[Rossi06] Rossi, M., "Evaluating TCP with Corruption Notification in an IEEE 802.11 Wireless LAN", Master Thesis, University of Innsbruck, November 2006. Available from http://heim.ifi.uio.no/michawe/research/projects/ corruption/.
[RSSI06]罗西，M，“评估TCP在IEEE 802.11无线局域网中的腐败通知”，硕士论文，因斯布鲁克大学，2006年11月。可从http://heim.ifi.uio.no/michawe/research/projects/ 腐败/。
[Saltzer84] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments in system design", ACM Transactions on Computer Systems, Vol. 2, No. 4, November 1984.
[Saltzer84]Saltzer，J.，Reed，D.，和D.Clark，“系统设计中的端到端参数”，ACM计算机系统交易，第2卷，第4期，1984年11月。
[Sarola02] Sarolahti, P. and A. Kuznetsov, "Congestion Control in Linux TCP", Proceedings of the USENIX Annual Technical Conference, 2002.
[Sarola2]Sarolahti，P.和A.Kuznetsov，“Linux TCP中的拥塞控制”，USENIX年度技术会议记录，2002年。
[Sarola07] Sarolahti, P., Floyd, S., and M. Kojo, "Transport-layer Considerations for Explicit Cross-layer Indications", Work in Progress, March 2007.
[Sarola07]Sarolahti，P.，Floyd，S.，和M.Kojo，“明确跨层指示的传输层考虑”，正在进行的工作，2007年3月。
[Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM SIGCOMM Computer Communication Review, 1999.
[Savage99]Savage，S.，Cardwell，N.，Wetheral，D.，和T.Anderson，“具有不正常接收器的TCP拥塞控制”，ACM SIGCOMM计算机通信评论，1999年。
[Shal10] Shalunov, S., Hazel, G., and J. Iyengar, "Low Extra Delay Background Transport (LEDBAT)", Work in Progress, October 2010.
[Shal10]Shalunov，S.，Hazel，G.，和J.Iyengar，“低额外延迟背景传输（LEDBAT）”，正在进行的工作，2010年10月。
[Shen08] Shen, C., Schulzrinne, H., and E. Nahum, "Session Initiation Protocol (SIP) Server Overload Control: Design and Evaluation, Principles", Systems and Applications of IP Telecommunications (IPTComm'08), Heidelberg, Germany, July 2008.
[Shen08]Shen，C.，Schulzrinne，H.，和E.Nahum，“会话启动协议（SIP）服务器过载控制：设计和评估，原则”，IP电信系统和应用（IPTComm'08），德国海德堡，2008年7月。
[Shin08] Shin, M., Chong, S., and I. Rhee, "Dual-Resource TCP/AQM for Processing-Constrained Networks", IEEE/ACM Transactions on Networking, Vol. 16, No. 2, pp. 435-449, April 2008.
[Shin08]Shin，M.，Chong，S.，和I.Rhee，“处理受限网络的双资源TCP/AQM”，IEEE/ACM网络交易，第16卷，第2期，第435-449页，2008年4月。
[Thaler07] Thaler, D., Sridharan, M., and D. Bansal, "Implementation Report on Experiences with Various TCP RFCs", Presentation to the IETF Transport Area, March 2007. <http://www.ietf.org/proceedings/07mar/ slides/tsvarea-3/>.
[Thaler07]Thaler，D.，Sridharan，M.，和D.Bansal，“关于各种TCP RFC经验的实施报告”，向IETF传输领域的介绍，2007年3月<http://www.ietf.org/proceedings/07mar/ 幻灯片/tsvarea-3/>。
[Tickoo05] Tickoo, O., Subramanian, V., Kalyanaraman, S., and K.K. Ramakrishnan, "LT-TCP: End-to-End Framework to Improve TCP Performance over Networks with Lossy Channels", Proceedings of International Workshop on QoS (IWQoS), Passau, Germany, June 2005.
[Tickoo05]Tickoo，O.，Subramanian，V.，Kalyanaraman，S.，和K.K.Ramakrishnan，“LT-TCP：在有损信道的网络上改进TCP性能的端到端框架”，QoS国际研讨会论文集，帕索，德国，2005年6月。
[TRILOGY] "Trilogy Project", European Commission Seventh Framework Program (FP7), Grant No: 216372, <http://www.trilogy-project.org>.
[三部曲]“三部曲项目”，欧盟委员会第七框架计划（FP7），批准号：216372<http://www.trilogy-project.org>.
[Vinnic02] Vinnicombe, G., "On the stability of networks operating TCP-like congestion control," Proceedings of IFAC World Congress, Barcelona, Spain, 2002.
[Vinnic02]Vinnicombe，G.，“关于运行TCP类拥塞控制的网络的稳定性”，IFAC世界大会论文集，西班牙巴塞罗那，2002年。
[Welzl03] Welzl, M., "Scalable Performance Signalling and Congestion Avoidance", Springer (ISBN 1-4020-7570-7), September 2003.
[Welzl03]Welzl，M.，“可扩展性能信令和拥塞避免”，Springer（ISBN 1-4020-7570-7），2003年9月。
[Welzl08] Welzl, M., Rossi, M., Fumagalli, A., and M. Tacca, "TCP/IP over IEEE 802.11b WLAN: the Challenge of Harnessing Known-Corrupt Data", Proceedings of IEEE International Conference on Communications (ICC) 2008, Beijing, China, May 2008.
[Welzl08]Welzl，M.，Rossi，M.，Fumagalli，A.，和M.Tacca，“IEEE 802.11b WLAN上的TCP/IP：利用已知损坏数据的挑战”，2008年IEEE国际通信会议记录（ICC），中国北京，2008年5月。
[Xia05] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, "One more bit is enough", ACM SIGCOMM Computer Communication Review, Vol. 35, No. 4, pp. 37-48, 2005.
[Xia05]夏，Y.，苏伯拉曼尼亚，L.，斯托伊卡，I.，和S.卡利亚纳拉曼，“多一点就足够了”，ACM SIGCOMM计算机通信评论，第35卷，第4期，第37-48页，2005年。
[Zhang03] Zhang, H., Towsley, D., Hollot, C., and V. Misra, "A Self-Tuning Structure for Adaptation in TCP/AQM Networks", Proceedings of ACM SIGMETRICS'03 Conference, San Diego (California), USA, June 2003.
[Zhang03]Zhang，H.，Towsley，D.，Hollot，C.，和V.Misra，“TCP/AQM网络自适应的自调整结构”，ACM SIGMETRICS'03会议记录，圣地亚哥（加利福尼亚州），美国，2003年6月。
The authors would like to thank the following people whose feedback and comments contributed to this document: Keith Moore, Jan Vandenabeele, and Larry Dunn (his comments at the Manchester ICCRG and discussions with him helped with the section on packet-congestibility).
作者要感谢以下人士，他们的反馈和评论对本文件做出了贡献：Keith Moore、Jan Vandenabeele和Larry Dunn（他在曼彻斯特ICCRG上的评论和与他的讨论有助于关于数据包拥塞性的部分）。
Dimitri Papadimitriou's contribution was partly funded by [ECODE], a Seventh Framework Program (FP7) research project sponsored by the European Commission.
Dimitri Papadimitriou的贡献部分由[ECODE]资助，ECODE是由欧盟委员会赞助的第七个框架计划（FP7）研究项目。
Bob Briscoe's contribution was partly funded by [TRILOGY], a research project supported by the European Commission.
Bob Briscoe的贡献部分由欧洲委员会支持的研究项目[三部曲]资助。
Michael Scharf is now with Alcatel-Lucent.
迈克尔·沙尔夫现在就职于阿尔卡特朗讯公司。
The following additional people have contributed to this document:
以下其他人员对本文件作出了贡献：
- Wesley Eddy <weddy@grc.nasa.gov>
- 卫斯理·艾迪<weddy@grc.nasa.gov>
- Bela Berde <bela.berde@gmx.de>
- 贝拉·贝尔德<贝拉。berde@gmx.de>
- Paulo Loureiro <loureiro.pjg@gmail.com>
- 保罗·卢雷罗<卢雷罗。pjg@gmail.com>
- Chris Christou <christou_chris@bah.com>
- 克里斯·克里斯托_chris@bah.com>
Authors' Addresses
作者地址
Dimitri Papadimitriou (editor) Alcatel-Lucent Copernicuslaan, 50 2018 Antwerpen, Belgium
Dimitri Papadimitriou（编辑）阿尔卡特朗讯哥白尼公司，2018年5月50日，比利时安特卫普
Phone: +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel-lucent.com
Phone: +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel-lucent.com
Michael Welzl University of Oslo, Department of Informatics PO Box 1080 Blindern N-0316 Oslo, Norway
米迦勒WelZl奥斯陆大学信息学系PO盒1080盲板N-0316奥斯陆，挪威
EMail: michawe@ifi.uio.no
EMail: michawe@ifi.uio.no
Michael Scharf University of Stuttgart Pfaffenwaldring 47 70569 Stuttgart, Germany
米迦勒S查夫斯图加特大学PfffunWaldin 47 70569斯图加特，德国
EMail: michael.scharf@googlemail.com
EMail: michael.scharf@googlemail.com
Bob Briscoe BT & UCL B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE, UK
Bob Briscoe英国电信和伦敦大学学院B54/77，英国阿达斯特拉尔公园马特勒沙姆希思伊普斯维奇IP5 3RE
EMail: bob.briscoe@bt.com
EMail: bob.briscoe@bt.com