Internet Engineering Task Force (IETF) B. Briscoe, Ed.
Request for Comments: 6789 BT
Category: Informational R. Woundy, Ed.
ISSN: 2070-1721 Comcast
A. Cooper, Ed.
CDT
December 2012
Internet Engineering Task Force (IETF) B. Briscoe, Ed.
Request for Comments: 6789 BT
Category: Informational R. Woundy, Ed.
ISSN: 2070-1721 Comcast
A. Cooper, Ed.
CDT
December 2012
Congestion Exposure (ConEx) Concepts and Use Cases
拥塞暴露（ConEx）概念和用例
Abstract
摘要
This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today.
本文档提供了有关拥塞暴露（ConEx）协议的一组文档的入口点。它解释了在IP层包含ConEx标记的动机：向网络节点公开有关拥塞的信息。尽管此类信息可能有多种用途，但本文件重点介绍了ConEx标记传达的信息如何作为比目前互联网上存在的信息更高效和有效的交通管理的基础。
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 Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc6789.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6789.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5
2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 6
2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Core Use Case: Informing Traffic Management . . . . . . . . . 7
3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 7
3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 9
3.3. Comparison with Existing Approaches . . . . . . . . . . . 9
4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11
5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 12
6. Experimental Considerations . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Congestion . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Congestion-Volume . . . . . . . . . . . . . . . . . . . . 5
2.3. Rest-of-Path Congestion . . . . . . . . . . . . . . . . . 6
2.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Core Use Case: Informing Traffic Management . . . . . . . . . 7
3.1. Use Case Description . . . . . . . . . . . . . . . . . . . 7
3.2. Additional Benefits . . . . . . . . . . . . . . . . . . . 9
3.3. Comparison with Existing Approaches . . . . . . . . . . . 9
4. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 11
5. Deployment Arrangements . . . . . . . . . . . . . . . . . . . 12
6. Experimental Considerations . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Informative References . . . . . . . . . . . . . . . . . . . . 15
The power of Internet technology comes from multiplexing shared capacity with packets rather than circuits. Network operators aim to provide sufficient shared capacity, but when too much packet load meets too little shared capacity, congestion results. Congestion appears as either increased delay, dropped packets, or packets explicitly marked with Explicit Congestion Notification (ECN) markings [RFC3168]. As described in Figure 1, congestion control currently relies on the transport receiver detecting these 'Congestion Signals' and informing the transport sender in 'Congestion Feedback Signals'. The sender is then expected to reduce its rate in response.
互联网技术的力量来自于将共享容量与数据包而不是电路进行多路复用。网络运营商的目标是提供足够的共享容量，但当太多的数据包负载满足太少的共享容量时，就会导致拥塞。拥塞表现为延迟增加、丢包或用显式拥塞通知（ECN）标记显式标记的数据包[RFC3168]。如图1所述，拥塞控制目前依赖于传输接收器检测这些“拥塞信号”，并在“拥塞反馈信号”中通知传输发送方。然后期望发送方降低其响应速率。
This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It focuses on the motivation for including a ConEx marking at the IP layer. (A companion document, [CONEX-ABS], focuses on the mechanics of the protocol.) Briefly, the idea is for the sender to continually signal expected congestion in the headers of any data it sends. To a first approximation, the sender does this by relaying the 'Congestion Feedback Signals' back into the IP layer. They then travel unchanged across the network to the receiver (shown as 'IP-Layer-ConEx-Signals' in Figure 1). This enables IP-layer devices on the path to see information about the whole-path congestion.
本文档提供了有关拥塞暴露（ConEx）协议的一组文档的入口点。它着重于在IP层包含ConEx标记的动机。（附带文档[CONEX-ABS]着重于协议的机制。）简单地说，其思想是让发送方在其发送的任何数据的报头中不断发出预期拥塞的信号。在第一种近似情况下，发送方通过将“拥塞反馈信号”中继回IP层来实现这一点。然后，它们在网络中以不变的方式传输到接收器（如图1中的“IP层ConEx信号”所示）。这使路径上的IP层设备能够查看有关整个路径拥塞的信息。
,---------. ,---------.
|Transport| |Transport|
| Sender | . |Receiver |
| | /|___________________________________________| |
| ,-<---------------Congestion-Feedback-Signals--<--------. |
| | |/ | | |
| | |\ Transport Layer Feedback Flow | | |
| | | \ ___________________________________________| | |
| | | \| | | |
| | | ' ,-----------. . | | |
| | |_____________| |_______________|\ | | |
| | | IP Layer | | Data Flow \ | | |
| | | |(Congested)| \ | | |
| | | | Network |--Congestion-Signals--->-' |
| | | | Device | \| |
| | | | | /| |
| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |
| | | | / | |
| |_____________| |_______________ / | |
| | | | |/ | |
`---------' `-----------' ' `---------'
,---------. ,---------.
|Transport| |Transport|
| Sender | . |Receiver |
| | /|___________________________________________| |
| ,-<---------------Congestion-Feedback-Signals--<--------. |
| | |/ | | |
| | |\ Transport Layer Feedback Flow | | |
| | | \ ___________________________________________| | |
| | | \| | | |
| | | ' ,-----------. . | | |
| | |_____________| |_______________|\ | | |
| | | IP Layer | | Data Flow \ | | |
| | | |(Congested)| \ | | |
| | | | Network |--Congestion-Signals--->-' |
| | | | Device | \| |
| | | | | /| |
| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |
| | | | / | |
| |_____________| |_______________ / | |
| | | | |/ | |
`---------' `-----------' ' `---------'
Figure 1: The ConEx Protocol in the Internet Architecture
图1：互联网架构中的ConEx协议
One of the key benefits of exposing this congestion information at the IP layer is that it makes the information available to network operators for use as input into their traffic management procedures. A ConEx-enabled sender signals expected whole-path congestion, which is approximately the congestion at least a round-trip time earlier as reported by the receiver to the sender (Figure 1). The ConEx signal is a mark in the IP header that is easy for any IP device to read. Therefore, a node performing traffic management can count congestion as easily as it might count data volume today by simply counting the volume of packets with ConEx markings.
在IP层公开这些拥塞信息的一个关键好处是，它使网络运营商可以使用这些信息作为其流量管理程序的输入。启用ConEx的发送方发出预期全路径拥塞的信号，该拥塞约为接收方向发送方报告的至少一个往返时间之前的拥塞（图1）。ConEx信号是IP报头中的一个标记，便于任何IP设备读取。因此，执行流量管理的节点可以通过简单地计算带有ConEx标记的数据包的数量，轻松地计算拥塞，就像它现在计算数据量一样。
ConEx-based traffic management can make highly efficient use of capacity. In times of no congestion, all traffic management restraints can be removed, leaving the network's full capacity available to all its users. If some users on the network cause disproportionate congestion, the traffic management function can learn about this and directly limit those users' traffic in order to protect the service of other users sharing the same capacity. ConEx-based traffic management thus presents a step change in terms of the options available to network operators for managing traffic on their networks.
基于ConEx的流量管理可以高效利用容量。在没有拥堵的情况下，所有的流量管理限制都可以取消，让网络的所有用户都可以使用全部容量。如果网络上的某些用户造成过度拥塞，流量管理功能可以了解这一点，并直接限制这些用户的流量，以保护共享相同容量的其他用户的服务。因此，基于ConEx的流量管理在网络运营商管理其网络流量的可用选项方面呈现出一种逐步变化。
The remainder of this document explains the concepts behind ConEx and how exposing congestion can significantly improve Internet traffic management, among other benefits. Section 2 introduces a number of concepts that are fundamental to understanding how ConEx-based traffic management works. Section 3 shows how ConEx can be used for traffic management, discusses additional benefits from such usage, and compares ConEx-based traffic management to existing traffic management approaches. Section 4 discusses other related use cases. Section 5 briefly discusses deployment arrangements. Section 6 suggests open issues that experiments in the use of ConEx could usefully be designed to answer. The final sections are standard RFC back matter.
本文档的其余部分解释了ConEx背后的概念，以及暴露拥塞如何显著改善互联网流量管理，以及其他好处。第2节介绍了一些概念，这些概念对于理解基于ConEx的交通管理工作方式至关重要。第3节展示了如何将ConEx用于交通管理，讨论了使用ConEx带来的其他好处，并将基于ConEx的交通管理与现有的交通管理方法进行了比较。第4节讨论了其他相关用例。第5节简要讨论部署安排。第6节提出了使用ConEx的实验可以有效解决的开放性问题。最后的部分是标准的RFC背景材料。
The remainder of the core ConEx document suite consists of:
核心ConEx文档套件的其余部分包括：
[CONEX-ABS], which provides an abstract encoding of ConEx signals, explains the ConEx audit and security mechanisms, and describes incremental deployment features;
[CONEX-ABS]提供了CONEX信号的抽象编码，解释了CONEX审计和安全机制，并描述了增量部署功能；
[CONEX-DESTOPT], which specifies the IPv6 destination option encoding for ConEx;
[CONEX-DESTOPT]，指定CONEX的IPv6目标选项编码；
[TCP-MOD], which specifies TCP-sender modifications for use of ConEx;
[TCP-MOD]，指定使用ConEx的TCP发送方修改；
and the following documents, which describe some feasible scenarios for deploying ConEx:
以下文件描述了部署ConEx的一些可行方案：
[CONEX-DEPLOY], which describes a scenario around a fixed broadband access network;
[CONEX-DEPLOY]，描述了固定宽带接入网络的一个场景；
[CONEX-MOBILE], which describes a scenario around a mobile communications provider;
[CONEX-MOBILE]，描述了移动通信提供商的情景；
[CONEX-DATA], which describes how ConEx could be used for performance isolation between tenants of a data centre.
[CONEX-DATA]，描述了如何使用CONEX在数据中心租户之间进行性能隔离。
ConEx relies on a precise definition of congestion and a number of newer concepts that are introduced in this section. Definitions are summarized in Section 2.4.
ConEx依赖于对拥塞的精确定义以及本节介绍的一些较新概念。第2.4节概述了定义。
Despite its central role in network control and management, congestion is a remarkably difficult concept to define. Experts in different disciplines and with different perspectives define congestion in a variety of ways [Bauer09].
尽管拥塞在网络控制和管理中起着核心作用，但它是一个非常难以定义的概念。不同学科和不同观点的专家以多种方式定义拥堵[Bauer09]。
The definition used for the purposes of ConEx is expressed as the probability of packet loss (or the probability of packet marking if ECN is in use). This definition focuses on how congestion is measured, rather than describing congestion as a condition or state.
ConEx中使用的定义表示为数据包丢失的概率（如果使用ECN，则表示数据包标记的概率）。该定义侧重于如何测量拥塞，而不是将拥塞描述为一种条件或状态。
The metric that ConEx exposes is congestion-volume: the volume of bytes dropped or ECN-marked in a given period of time. Counting congestion-volume allows each user to be held responsible for his or her contribution to congestion. Congestion-volume can only be a property of traffic, whereas congestion can be a property of traffic or a property of a link or a path.
ConEx公开的度量标准是拥塞量：在给定时间段内丢弃或标记ECN的字节数。计算拥塞量可以让每个用户对自己造成的拥塞负责。拥塞量只能是流量的属性，而拥塞可以是流量的属性或链路或路径的属性。
To understand congestion-volume, consider a simple example. Imagine Alice sends 1 GB of a file while the loss-probability is a constant 0.2%. Her contribution to congestion -- her congestion-volume -- is 1 GB x 0.2% = 2 MB. If she then sends another 3 GB of the file while the loss-probability is 0.1%, this adds 3 MB to her congestion-volume. Her total contribution to congestion is then 2 MB + 3 MB = 5 MB.
为了理解拥塞量，考虑一个简单的例子。假设Alice发送1 GB的文件，而丢失概率为常数0.2%。她对拥塞的贡献——她的拥塞量——是1Gbx0.2%=2MB。如果她在丢失概率为0.1%的情况下再发送3GB的文件，则会增加3MB的拥塞量。她对拥塞的总贡献是2MB+3MB=5MB。
Fortunately, measuring Alice's congestion-volume on a real network does not require the kind of arithmetic shown above, because congestion-volume can be directly measured by counting the total volume of Alice's traffic that gets discarded or ECN-marked. (A queue with varying percentage loss does these multiplications and additions inherently.) With ConEx, network operators can count congestion-volume using techniques very similar to those they use for counting volume.
幸运的是，在真实网络上测量Alice的拥塞量不需要上面所示的算法，因为可以通过计算Alice丢弃或标记ECN的流量总量直接测量拥塞量。（一个损失百分比不同的队列本质上会进行这些乘法和加法运算。）有了ConEx，网络运营商可以使用非常类似于计算流量的技术来计算拥塞量。
At a particular measurement point within a network, "rest-of-path congestion" (also known as "downstream congestion") is the level of congestion that a traffic flow is expected to experience between the measurement point and its final destination. "Upstream congestion" is the congestion experienced up to the measurement point.
在网络内的特定测量点，“剩余路径拥堵”（也称为“下游拥堵”）是指交通流在测量点与其最终目的地之间预计会经历的拥堵程度。“上游拥堵”是指在测量点之前经历的拥堵。
If traffic is ECN-capable, ECN signals monitored in the middle of a network will indicate the congestion experienced so far on the path (upstream congestion). In contrast, the ConEx signals inserted into IP headers as shown in Figure 1 indicate the congestion along a whole path from transport source to transport destination. Therefore, if a measurement point detects both of these signals, it can subtract the level of ECN (upstream congestion) from the level of ConEx (whole path) to derive a measure of the congestion that packets are likely to experience between the monitoring point and their destination (rest-of-path congestion). A measurement point can calculate this measurement in the aggregate, across all flows.
如果业务是ECN能力，在网络中间监视的ECN信号将指示迄今为止在路径上经历的拥塞（上行拥塞）。相反，如图1所示，插入IP报头的ConEx信号表示从传输源到传输目的地的整个路径上的拥塞。因此，如果测量点检测到这两个信号，它可以从ConEx（整个路径）的水平中减去ECN（上游拥塞）的水平，从而得出数据包可能在监测点与其目的地（剩余路径拥塞）之间经历的拥塞的测量值。测量点可以在所有流的集合中计算此测量值。
A network monitor can usually accurately measure upstream congestion only if the traffic it observes is ECN-capable. [CONEX-ABS] further discusses the constraints around the network's ability to measure upstream and rest-of-path congestion in these circumstances. However, there are a number of initial deployment arrangements that benefit from ConEx but work without ECN (see Section 5).
网络监视器通常只有在其观察到的流量能够进行ECN时才能准确地测量上游拥塞。[CONEX-ABS]进一步讨论了网络在这些情况下测量上行和其余路径拥塞的能力所受到的限制。然而，有许多初始部署安排受益于ConEx，但在没有ECN的情况下有效（见第5节）。
Congestion: In general, congestion occurs when any user's traffic suffers loss, ECN marking, or increased delay as a result of one or more network resources becoming overloaded. For the purposes of ConEx, congestion is measured using the concrete signals provided by loss and ECN markings (delay is not considered). Congestion is measured as the probability of loss or the probability of ECN marking, usually expressed as a dimensionless percentage.
拥塞：一般来说，当任何用户的流量由于一个或多个网络资源过载而遭受损失、ECN标记或延迟增加时，就会发生拥塞。就ConEx而言，使用损耗和ECN标记提供的具体信号测量拥堵（不考虑延迟）。拥塞被测量为丢失概率或ECN标记概率，通常表示为无量纲百分比。
Congestion-volume: For any granularity of traffic (packet, flow, aggregate, link, etc.), the volume of bytes dropped or ECN-marked in a given period of time. Conceptually, data volume multiplied by the congestion each packet of the volume experienced. This is usually expressed in bytes (or kB, MB, etc.).
拥塞量：对于任何粒度的流量（数据包、流量、聚合、链路等），在给定时间段内丢弃或标记ECN的字节量。从概念上讲，数据量乘以卷的每个数据包所经历的拥塞。这通常以字节（或kB、MB等）表示。
Congestion policer: A logical entity that allows a network operator to monitor each user's congestion-volume and enforce congestion-volume limits (discussed in Section 3.1).
拥塞策略：一种逻辑实体，允许网络运营商监控每个用户的拥塞量并强制实施拥塞量限制（在第3.1节中讨论）。
Rest-of-path congestion (or downstream congestion): The congestion a flow of traffic is expected to experience on the remainder of its path. In other words, at a measurement point in the network, the rest-of-path congestion is the congestion the traffic flow has yet to experience as it travels from that point to the receiver. Upstream congestion is usually expressed as a dimensionless percentage.
剩余路径拥堵（或下游拥堵）：交通流在其剩余路径上预计会遇到的拥堵。换句话说，在网络中的一个测量点上，剩余的路径拥塞是交通流从该点到接收器时尚未经历的拥塞。上游拥堵通常表示为无量纲百分比。
Upstream congestion: The accumulated congestion experienced by a traffic flow thus far, relative to a point along its path. In other words, at a measurement point in the network, the upstream congestion is the accumulated congestion the traffic flow has experienced as it travels from the sender to that point. At the receiver, this is equivalent to the end-to-end congestion level that (usually) is reported back to the sender. This is usually expressed as a dimensionless percentage.
上游拥堵：相对于其路径上的某一点，交通流迄今为止所经历的累积拥堵。换句话说，在网络中的一个测量点上，上行拥塞是交通流从发送方到该点时经历的累积拥塞。在接收方，这相当于（通常）向发送方报告的端到端拥塞级别。这通常表示为无量纲百分比。
Network operator (or provider): Operator of a residential, commercial, enterprise, campus, or other network.
网络运营商（或提供商）：住宅、商业、企业、校园或其他网络的运营商。
User: The contractual entity that represents an individual, household, business, or institution that uses the service of a network operator. There is no implication that the contract has to be commercial; for instance, the users of a university or enterprise network service could be students or employees who do not pay for access, but may be required to comply with some form of contract or acceptable use policy. There is also no implication that every user is an end user. Where two networks form a customer-provider relationship, the term "user" applies to the customer network.
用户：代表使用网络运营商服务的个人、家庭、企业或机构的合同实体。并不意味着合同必须是商业性的；例如，大学或企业网络服务的用户可能是学生或员工，他们不支付访问费用，但可能需要遵守某种形式的合同或可接受的使用政策。也不意味着每个用户都是最终用户。如果两个网络形成客户-提供商关系，则术语“用户”适用于客户网络。
[CONEX-ABS] gives further definitions for aspects of ConEx related to protocol mechanisms.
[CONEX-ABS]给出了与协议机制相关的CONEX方面的进一步定义。
This section explains how ConEx could be used as the basis for traffic management, highlights additional benefits derived from having ConEx-aware nodes on the network, and compares ConEx-based traffic management to existing approaches.
本节解释了如何将ConEx用作流量管理的基础，强调了网络上具有ConEx感知节点的额外好处，并将基于ConEx的流量管理与现有方法进行了比较。
One of the key benefits that ConEx can deliver is in helping network operators to improve how they manage traffic on their networks. Consider the common case of a commercial broadband network where a relatively small number of users place disproportionate demand on network resources, at times resulting in congestion. The network
ConEx能够提供的一个关键好处是帮助网络运营商改进其网络流量管理方式。考虑商业宽带网络的常见情况，其中相对较少的用户对网络资源产生不成比例的需求，有时导致拥塞。网络
operator seeks a way to manage traffic such that the traffic that contributes more to congestion bears more of the brunt of the management.
运营商寻求一种管理交通的方法，使导致拥堵的交通承担更多的管理责任。
Assuming ConEx signals are visible at the IP layer, the network operator can accomplish this by placing a congestion policer at an enforcement point within the network and configuring it with a traffic management policy that monitors each user's contribution to congestion. As described in [CONEX-ABS] and elaborated in [CongPol], one way to implement a congestion policer is in a similar way to a bit-rate policer, except that it monitors congestion-volume (based on IP-layer ConEx signals) rather than bit rate. When implemented as a token bucket, the tokens provide users with the right to cause bits of congestion-volume, rather than to send bits of data volume. The fill rate represents each user's congestion-volume quota.
假设ConEx信号在IP层可见，则网络运营商可以通过在网络内的实施点放置拥塞策略并使用流量管理策略对其进行配置来实现这一点，该策略监控每个用户对拥塞的贡献。如[CONEX-ABS]所述并在[CongPol]中详细阐述的，实现拥塞策略的一种方法与比特率策略类似，只是它监控拥塞量（基于IP层CONEX信号）而不是比特率。当作为令牌桶实现时，令牌为用户提供了导致拥塞量位的权利，而不是发送数据量位的权利。填充率表示每个用户的拥塞量配额。
The congestion policer monitors the ConEx signals of the traffic entering the network. As long as the network remains uncongested and users stay within their quotas, no action is taken. When the network becomes congested and a user exhausts his quota, some action is taken against the traffic that breached the quota in accordance with the network operator's traffic management policy. For example, the traffic may be dropped, delayed, or marked with a lower QoS class. In this way, traffic is managed according to its contribution to congestion -- not some application- or flow-specific policy -- and is not managed at all during times of no congestion.
拥塞策略监控进入网络的流量的ConEx信号。只要网络保持畅通，用户保持在配额范围内，就不会采取任何行动。当网络变得拥挤且用户耗尽其配额时，将根据网络运营商的流量管理策略对违反配额的流量采取一些措施。例如，业务可以被丢弃、延迟或标记为较低的QoS等级。通过这种方式，流量是根据其对拥塞的贡献来管理的——而不是某些特定于应用程序或流的策略——并且在没有拥塞的情况下根本不进行管理。
As an example of how a network operator might employ a ConEx-based traffic management system, consider a typical DSL network architecture (as elaborated in [TR-059] and [TR-101]). Traffic is routed from regional and global IP networks to an operator-controlled IP node, the Broadband Remote Access Server (BRAS). From the BRAS, traffic is delivered to access nodes. The BRAS carries enhanced functionality, including IP QoS and traffic management capabilities.
作为网络运营商如何使用基于CONEX的流量管理系统的一个例子，考虑典型的DSL网络体系结构（如[TR 059]和[TR 101]中阐述的）。流量从区域和全球IP网络路由到运营商控制的IP节点，即宽带远程访问服务器（BRAS）。从BRAS，流量被传送到访问节点。BRAS具有增强的功能，包括IP QoS和流量管理功能。
By deploying a congestion policer at the BRAS location, the network operator can measure the congestion-volume created by users within the access nodes and police misbehaving users before their traffic affects others on the access network. The policer would be provisioned with a traffic management policy, perhaps directing the BRAS to drop packets from users that exceed their congestion-volume quotas during times of congestion. Those users' apps would be likely to react in the typical way to drops, backing off (assuming at least some use TCP), and thereby lowering the users' congestion-volumes back within the quota limits. If none of a user's apps responds, the policer would continue to increase focused drops and effectively enforce its own congestion control.
通过在BRAS位置部署拥塞策略，网络运营商可以测量接入节点内用户创建的拥塞量，并在其流量影响接入网络上的其他用户之前对行为不端的用户进行监控。policr将配备一个流量管理策略，可能会指示BRAS在拥塞期间丢弃来自超过其拥塞量配额的用户的数据包。这些用户的应用程序可能会以典型的方式对丢弃做出反应，退出（假设至少有一些用户使用TCP），从而将用户的拥塞量降低到配额限制内。如果用户的应用程序都没有响应，那么policer将继续增加重点丢弃，并有效地实施自己的拥塞控制。
The ConEx-based approach to traffic management has a number of benefits in addition to efficient management of traffic. It provides incentives for users to make use of "scavenger" transport protocols, such as the Low Extra Delay Background Transport [LEDBAT], that provide ways for bulk-transfer applications to rapidly yield when interactive applications require capacity (thereby "scavenging" remaining bandwidth). With a congestion policer in place as described in Section 3.1, users of these protocols will be less likely to run afoul of the network operator's traffic management policy than those whose bulk-transfer applications generate the same volume of traffic without being sensitive to congestion. In short, two users who produce similar traffic volumes over the same time interval may produce different congestion-volumes if one of them is using a scavenger transport protocol and the other is not; in that situation, the scavenger user's traffic is less likely to be managed by the network operator.
基于ConEx的交通管理方法除了有效管理交通外，还有许多好处。它鼓励用户使用“清道夫”传输协议，如低额外延迟后台传输[LEDBAT]，该协议为批量传输应用程序提供了在交互应用程序需要容量时快速生成的方法（从而“清道夫”剩余带宽）。如第3.1节所述，有了拥塞策略，这些协议的用户与批量传输应用程序产生相同流量且对拥塞不敏感的用户相比，不太可能违反网络运营商的流量管理策略。简言之，如果两个用户中的一个使用清道夫传输协议，而另一个不使用清道夫传输协议，那么在同一时间间隔内产生相似通信量的两个用户可能会产生不同的拥塞量；在这种情况下，清道夫用户的流量不太可能由网络运营商管理。
ConEx-based traffic management also makes it possible for a user to control the relative performance among its own traffic flows. If a user wants some flows to have more bandwidth than others, it can reduce the rate of some traffic so that it consumes less congestion-volume "budget", leaving more congestion-volume "budget" for the user to "spend" on making other traffic go faster. This approach is most relevant if congestion is signalled by ECN, because no impairment due to loss is involved and delay can remain low.
基于ConEx的流量管理还使得用户能够控制其自身流量之间的相对性能。如果用户希望某些流量具有比其他流量更多的带宽，则可以降低某些流量的速率，以便消耗更少的拥塞量“预算”，为用户留下更多的拥塞量“预算”，以便用户“花费”使其他流量更快。如果ECN发出拥塞信号，则此方法最为相关，因为不涉及因丢失而造成的损害，并且延迟可以保持较低。
A variety of approaches already exist for network operators to manage congestion, traffic, and the disproportionate usage of scarce capacity by a small number of users. Common approaches can be categorized as rate-based, volume-based, or application-based.
网络运营商已经有多种方法来管理拥塞、流量以及少数用户对稀缺容量的过度使用。常见的方法可以分为基于速率的、基于卷的或基于应用程序的。
Rate-based approaches constrain the traffic rate per user or per network. A user's peak and average (or "committed") rate may be limited. These approaches have the potential to either over- or under-constrain the network, suppressing rates even when the network is uncongested or not suppressing them enough during heavy usage periods.
基于速率的方法限制每个用户或每个网络的通信速率。用户的峰值和平均（或“承诺”）速率可能会受到限制。这些方法有可能过度或不足限制网络，甚至在网络未被占用的情况下抑制速率，或者在大量使用期间抑制速率不够。
Round-robin scheduling and fair queuing were developed to address these problems. They equalize relative rates between active users (or flows) at a known bottleneck. The bit rate allocated to any one user depends on the number of active users at each instant. The drawback of these approaches is that they favor heavy users over light users over time, because they do not have any memory of usage.
为了解决这些问题，开发了循环调度和公平排队。它们在已知瓶颈处平衡活动用户（或流）之间的相对速率。分配给任何一个用户的比特率取决于每个时刻活动用户的数量。这些方法的缺点是，随着时间的推移，它们更喜欢重用户而不是轻用户，因为它们没有任何使用记忆。
These approaches share bit rate instant by instant; however, heavy users are active at every instant, whereas light users only occupy their share of the link occasionally.
这些方法在瞬间共享比特率；然而，重用户在每一个瞬间都是活跃的，而轻用户只是偶尔占据他们的链接份额。
Volume-based approaches measure the overall volume of traffic a user sends (and/or receives) over time. Users may be subject to an absolute volume cap (for example, 10GB per month) or the "heaviest" users may be sanctioned in some other manner. Many providers use monthly volume limits, and count volume regardless of whether the network is congested or not, creating the potential for over- or under-constraining problems, as with the original rate-based approaches.
基于流量的方法测量用户随时间发送（和/或接收）的总流量。用户可能会受到绝对容量上限的限制（例如，每月10GB），或者“最重”的用户可能会受到其他方式的制裁。许多提供商使用每月的流量限制，并计算流量，而不管网络是否拥挤，这就产生了过度或不足约束的问题，就像最初基于费率的方法一样。
ConEx-based approaches, by comparison, only react during times of congestion and in proportion to each user's congestion contribution, making more efficient use of capacity and more proportionate management decisions.
相比之下，基于ConEx的方法仅在拥塞期间作出反应，并与每个用户的拥塞贡献成比例，从而更有效地利用容量和更均衡的管理决策。
Unlike ConEx-based approaches, neither rate-based nor volume-based approaches provide incentives for applications to use scavenger transport protocols. They may even penalize users of applications that employ scavenger transports for the large amount of volume they send, rather than rewarding them for carefully avoiding congestion while sending it. While the volume-based approach described in "Comcast's Protocol-Agnostic Congestion Management System" [RFC6057] aims to overcome the over-/under-constraining problem by only measuring volume and triggering traffic management action during periods of high utilization, it still does not provide incentives to use scavenger transports, because congestion-causing volume cannot be distinguished from volume overall. ConEx provides this ability.
与基于ConEx的方法不同，基于速率和基于容量的方法都不能激励应用程序使用清道夫传输协议。他们甚至可能会惩罚那些使用清道夫传输的应用程序的用户，因为他们发送了大量的数据，而不是奖励他们在发送数据时小心地避免拥塞。虽然“Comcast的协议不可知拥塞管理系统”[RFC6057]中描述的基于流量的方法旨在通过仅测量流量并在高利用率期间触发流量管理操作来克服过度/不足的问题，但它仍然没有提供使用清道夫传输的激励，因为导致拥塞的卷无法与整个卷区分开来。ConEx提供了这种能力。
Application-based approaches use deep packet inspection or other techniques to determine what application a given traffic flow is associated with. Network operators may then use this information to rate-limit or otherwise sanction certain applications, in some cases only during peak hours. These approaches suffer from being at odds with IPsec and some application-layer encryption, and they may raise additional policy concerns. In contrast, ConEx offers an application-agnostic metric to serve as the basis for traffic management decisions.
基于应用程序的方法使用深度数据包检查或其他技术来确定给定流量与哪个应用程序相关。然后，网络运营商可以使用此信息对某些应用程序进行费率限制或其他制裁，在某些情况下，仅在高峰时段。这些方法与IPsec和某些应用层加密不一致，可能会引起额外的策略问题。相比之下，ConEx提供了一个应用程序无关的指标，作为交通管理决策的基础。
The existing types of approaches share a further limitation that ConEx can help to overcome: performance uncertainty. Flat-rate pricing plans are popular because users appreciate the certainty of having their monthly bill amount remain the same for each billing period, allowing them to plan their costs accordingly. But while flat-rate pricing avoids billing uncertainty, it creates performance uncertainty: users cannot know whether the performance of their
现有类型的方法有一个共同的限制，ConEx可以帮助克服：性能不确定性。统一费率定价计划很受欢迎，因为用户喜欢在每个计费周期内每月账单金额保持不变，从而可以相应地规划成本。但是，虽然统一费率定价避免了计费的不确定性，但它也造成了性能的不确定性：用户无法知道他们的系统的性能是否稳定
connections is being altered or degraded based on how the network operator is attempting to manage congestion. By exposing congestion information at the IP layer, ConEx instead provides a metric that can serve as an open, transparent basis for traffic management policies that both providers and their customers can measure and verify. It can be used to reduce the performance uncertainty that some users currently experience, without having to sacrifice their billing certainty.
连接正在根据网络运营商试图管理拥塞的方式进行更改或降级。相反，通过在IP层公开拥塞信息，ConEx提供了一个指标，可以作为流量管理政策的开放、透明的基础，提供商及其客户都可以测量和验证流量管理政策。它可以用来减少一些用户当前体验到的性能不确定性，而不必牺牲他们的计费确定性。
ConEx information can be put to a number of uses other than informing traffic management. These include:
除了通知交通管理，ConEx信息还可用于其他用途。这些措施包括：
Informing inter-operator contracts: ConEx information is made visible to every IP node, including border nodes between networks. Network operators can use ConEx combined with ECN markings to measure how much traffic from each network contributes to congestion in the other. As such, congestion-volume could be included as a metric in inter-operator contracts, just as volume or bit rate are included today. This would not be an initial deployment scenario, unless ECN became widely deployed.
通知运营商间合同：ConEx信息对每个IP节点可见，包括网络之间的边界节点。网络运营商可以使用ConEx结合ECN标记来测量每个网络中有多少流量会导致另一个网络中的拥塞。因此，拥塞量可以作为一个指标包含在运营商间合同中，就像今天包含的容量或比特率一样。这将不是一个初始部署场景，除非ECN得到广泛部署。
Enabling more efficient capacity provisioning: Section 3.2 explains how operators can use ConEx-based traffic management to encourage use of scavenger transport protocols, which significantly improves the performance of interactive applications while still allowing heavy users to transfer high volumes. Here we explain how this can also benefit network operators.
实现更高效的容量调配：第3.2节解释了运营商如何使用基于ConEx的流量管理来鼓励使用清道夫传输协议，这将显著提高交互式应用程序的性能，同时仍允许重用户传输高容量。在这里，我们将解释这如何也有利于网络运营商。
Today, when loss, delay, or average utilization exceeds a certain threshold, some operators just buy more capacity without attempting to manage the traffic. Other operators prefer to limit a minority of heavy users at peak times, but they still eventually buy more capacity when utilization rises.
如今，当损失、延迟或平均利用率超过某个阈值时，一些运营商只是购买更多容量，而不尝试管理流量。其他运营商更愿意在高峰时段限制少数重度用户，但当利用率上升时，他们最终还是会购买更多容量。
With ConEx-based traffic management, a network operator should be able to provision capacity more efficiently. An operator could benefit from this in a variety of ways. For example, the operator could add capacity as it would do without ConEx, but deliver better quality of service for its users. Or, the operator could delay adding capacity while delivering similar quality of service to what it currently provides.
通过基于ConEx的流量管理，网络运营商应该能够更有效地提供容量。运营商可以通过多种方式从中受益。例如，运营商可以像没有ConEx一样增加容量，但为用户提供更好的服务质量。或者，运营商可以延迟增加容量，同时提供与其当前提供的服务质量相似的服务。
ConEx is designed so that it can be incrementally deployed in the Internet and still be valuable for early adopters. As long as some senders are ConEx-enabled, a network on the path can unilaterally use ConEx-aware policy devices for traffic management; no changes to network forwarding elements are needed, and ConEx still works if there are other networks on the path that are unaware of ConEx marks.
ConEx的设计目的是，它可以逐步部署在互联网上，对早期采用者仍然很有价值。只要某些发送方启用了ConEx，路径上的网络就可以单方面使用ConEx感知策略设备进行流量管理；不需要对网络转发元素进行任何更改，如果路径上存在不知道ConEx标记的其他网络，则ConEx仍然有效。
The above two steps seem to represent a stand-off where neither step is useful until the other has made the first move: i) some sending hosts must be modified to give information to the network, and ii) a network must deploy policy devices to monitor this information and act on it. Nonetheless, the developer of a scavenger transport protocol like LEDBAT does stand to benefit from deploying ConEx. In this case, the developer makes the first move, expecting it will prompt at least some networks to move in response, using the ConEx information to reward users of the scavenger transport protocol.
上述两个步骤似乎代表了一种僵局，在另一个步骤采取第一步之前，这两个步骤都没有用处：i）必须修改某些发送主机以向网络提供信息，ii）网络必须部署策略设备来监视此信息并对其采取行动。尽管如此，像LEDBAT这样的清道夫传输协议的开发人员确实可以从部署ConEx中获益。在这种情况下，开发人员会采取第一步行动，希望它会提示至少一些网络做出响应，使用ConEx信息奖励清道夫传输协议的用户。
On the host side, we have already shown (Figure 1) how the sender piggy-backs ConEx signals on normal data packets to re-insert feedback about packet drops (and/or ECN) back into the IP layer. In the case of TCP, [TCP-MOD] proposes the required sender modifications. ConEx works with any TCP receiver as long as it uses SACK (selective acknowledgment), which most do. There is a receiver optimisation [TCPM-ECN] that improves ConEx precision when using ECN, but ConEx can still use ECN without it. Networks can make use of ConEx even if the implementations of some of the transport protocols on a host do not support ConEx (e.g., the implementation of DNS over UDP might not support ConEx, while perhaps RTP over UDP and TCP will).
在主机端，我们已经展示了（图1）发送方如何将ConEx信号装载到正常数据包上，以将关于丢包（和/或ECN）的反馈重新插入IP层。对于TCP，[TCP-MOD]提出了所需的发送方修改。ConEx可以与任何TCP接收器一起工作，只要它使用SACK（选择性确认），而大多数TCP接收器都使用SACK。有一种接收机优化[TCPM-ECN]，可以在使用ECN时提高ConEx的精度，但ConEx在没有ECN的情况下仍然可以使用ECN。即使主机上某些传输协议的实现不支持ConEx，网络也可以使用ConEx（例如，通过UDP实现DNS可能不支持ConEx，而通过UDP和TCP实现RTP可能会支持ConEx）。
On the network side, the provider solely needs to place ConEx congestion policers at each ingress to its network in a similar arrangement to the edge-policed architecture of Diffserv [RFC2475].
在网络方面，提供商只需在其网络的每个入口处放置ConEx拥塞策略，其安排与Diffserv的边缘策略架构类似[RFC2475]。
A sender can choose whether to send packets that support ConEx or packets that don't. ConEx-enabled packets bring information to the policer about congestion expected on the rest of the path beyond the policer. Packets that do not support ConEx bring no such information. Therefore, the network will tend to conservatively rate-limit non-ConEx-enabled packets in order to manage the unknown risk of congestion. In contrast, a network doesn't normally need to rate-limit ConEx-enabled packets unless they reveal a persistently high contribution to congestion. This natural tendency for networks to favour senders that provide ConEx information reinforces ConEx deployment.
发送方可以选择发送支持ConEx的数据包还是不支持ConEx的数据包。启用ConEx的数据包会向策略器提供关于超出策略器的路径的其余部分上预期的拥塞的信息。不支持ConEx的数据包不会带来此类信息。因此，网络将倾向于保守地对未启用ConEx的数据包进行速率限制，以便管理未知的拥塞风险。相反，网络通常不需要对启用ConEx的数据包进行速率限制，除非它们显示出对拥塞的持续高贡献。网络偏爱提供ConEx信息的发送者的这种自然趋势加强了ConEx的部署。
Feasible initial deployment scenarios exist for a broadband access network [CONEX-DEPLOY], a mobile communications network [CONEX-MOBILE], and a multi-tenant data centre [CONEX-DATA]. The first two of these scenarios are believed to work well without ECN support, while the data center scenario works best with ECN (and ECN can be deployed unilaterally).
对于宽带接入网络[CONEX-DEPLOY]、移动通信网络[CONEX-mobile]和多租户数据中心[CONEX-data]，存在可行的初始部署场景。据信，前两种方案在没有ECN支持的情况下运行良好，而数据中心方案在使用ECN时效果最好（ECN可以单方面部署）。
The above gives only the most salient aspects of ConEx deployment. For further detail, [CONEX-ABS] describes the incremental deployment features of the ConEx protocol and the components that need to be deployed for ConEx to work.
以上仅给出了ConEx部署的最突出方面。为了进一步了解详情，[CONEX-ABS]介绍了CONEX协议的增量部署功能以及为使CONEX正常工作而需要部署的组件。
ConEx is initially designed as an experimental protocol because it makes an ambitious change at the interoperability (IP) layer, so no amount of careful design can foresee all the potential feature interactions with other uses of IP. This section identifies a number of questions that would be useful to answer through well-designed experiments:
ConEx最初设计为一个实验性协议，因为它在互操作性（IP）层进行了雄心勃勃的更改，因此再仔细的设计也无法预见与IP其他用途的所有潜在功能交互。本节确定了通过精心设计的实验回答的一些问题：
o Are the compromises that were made in order to fit the ConEx encoding into IP (for example, that the initial design was solely for IPv6 and not for IPv4, and that the encoding has limited visibility when tunnelled [CONEX-DESTOPT]) the right ones?
o 为了将ConEx编码融入IP而做出的妥协（例如，最初的设计仅针对IPv6而非IPv4，并且在隧道传输[ConEx-DESTOPT]时编码的可见性有限）是否正确？
o Is it possible to combine techniques for distinguishing self-congestion from shared congestion with ConEx-based traffic management such that users are not penalized for congestion that does not impact others on the network? Are other techniques needed?
o 是否有可能将区分自拥塞和共享拥塞的技术与基于ConEx的流量管理结合起来，这样用户就不会因为不影响网络上其他人的拥塞而受到惩罚？还需要其他技术吗？
o In practice, how does traffic management using ConEx compare with traditional techniques (Section 3.3)? Does it give the benefits claimed in Sections 3.1 and 3.2?
o 在实践中，使用ConEx的交通管理与传统技术相比如何（第3.3节）？它是否提供了第3.1节和第3.2节中要求的福利？
o Approaches are proposed for congestion policing of ConEx traffic alongside existing management (or lack thereof) of non-ConEx traffic, including UDP traffic [CONEX-ABS]. Are they strategy-proof against users selectively using both? Are there better transition strategies?
o 除了现有的非ConEx流量（包括UDP流量）管理（或缺乏管理）外，还提出了ConEx流量的拥塞管理方法[ConEx-ABS]。它们是否能够防止用户选择性地使用这两种方法？是否有更好的过渡策略？
o Audit devices have been designed and implemented to assure ConEx signal integrity [CONEX-ABS]. Do they achieve minimal false hits and false misses in a wide range of traffic scenarios? Are there new attacks? Are there better audit designs to defend against these?
o 设计并实施了审计装置，以确保ConEx信号完整性[ConEx-ABS]。他们是否在广泛的交通场景中实现了最小的误命中和误命中？有新的攻击吗？是否有更好的审计设计来防范这些问题？
o If ECN deployment remains patchy, are the proposed initial ConEx deployment scenarios (Section 5) still useful enough to kick-start deployment? Is auditing effective when based on loss at a primary bottleneck? Can rest-of-path congestion be approximated accurately enough without ECN? Are there other useful deployment scenarios?
o 如果ECN部署仍然不完善，那么提议的初始ConEx部署场景（第5节）是否仍足以启动部署？基于主要瓶颈的损失进行审计是否有效？在没有ECN的情况下，剩余的路径拥塞是否可以足够精确地近似？还有其他有用的部署场景吗？
ConEx is intended to be a generative technology that might be used for unexpected purposes unforeseen by the designers. Therefore, this list of experimental considerations is not intended to be exhaustive.
ConEx旨在成为一种生成性技术，可用于设计师无法预见的意外目的。因此，本实验注意事项列表并非详尽无遗。
This document does not specify a mechanism, it merely motivates congestion exposure at the IP layer. Therefore, security considerations are described in the companion document that gives an abstract description of the ConEx protocol and the components that would use it [CONEX-ABS].
本文档没有指定机制，它只是在IP层激发拥塞暴露。因此，配套文件中描述了安全注意事项，该文件对ConEx协议和将使用该协议的组件进行了抽象描述[ConEx-ABS]。
Bob Briscoe was partly funded by Trilogy, a research project (ICT-216372) supported by the European Community under its Seventh Framework Programme. The views expressed here are those of the author only.
Bob Briscoe的部分资金来自Trilogy，这是一个研究项目（ICT-216372），由欧洲共同体在其第七个框架计划下支持。这里表达的观点仅是作者的观点。
The authors would like to thank the many people that have commented on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan, Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis, Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis, Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig, and Stuart Venters. Please accept our apologies if your name has been missed off this list.
作者要感谢对本文件发表评论的许多人：伯纳德·阿博巴、米凯尔·阿布拉罕松、若昂·塔维拉·阿劳约、马塞洛·巴格鲁·布劳恩、史蒂夫·鲍尔、凯特琳·贝斯勒、史蒂文·布莱克、路易斯·伯恩斯、肯·卡尔伯格、南迪塔·杜基帕蒂、戴夫·麦克迪桑、韦斯·艾迪、马修·福特、英格玛·约翰逊、乔治奥斯·卡拉吉安尼斯、，Mirja Kuehlewind、Dirk Kutscher、Zhu Lei、Kevin Mason、Matt Mathis、Michael Meth、Chris Morrow、Tim Shepard、Hannes Tschofenig和Stuart Venters。如果您的名字从名单中漏掉，请接受我们的道歉。
Philip Eardley and Andrea Soppera made helpful text contributions to this document.
Philip Eardley和Andrea Soppera对本文件做出了有益的文本贡献。
The following co-edited this document through most of its life:
以下人员在本文件的大部分时间内共同编辑了本文件：
Toby Moncaster Computer Laboratory William Gates Building JJ Thomson Avenue Cambridge, CB3 0FD UK EMail: toby.moncaster@cl.cam.ac.uk
托比·蒙卡斯特计算机实验室威廉·盖茨大楼JJ汤姆森大道剑桥CB3 0FD英国电子邮件：托比。moncaster@cl.cam.ac.uk
John Leslie JLC.net 10 Souhegan Street Milford, NH 03055 US EMail: john@jlc.net
John Leslie JLC.net 10 Souhegan Street Milford，NH 03055美国电子邮件：john@jlc.net
[Bauer09] Bauer, S., Clark, D., and W. Lehr, "The Evolution of Internet Congestion", 2009.
[Bauer09]Bauer，S.，Clark，D.，和W.Lehr，“互联网拥塞的演变”，2009年。
[CONEX-ABS] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", Work in Progress, October 2012.
[CONEX-ABS]Mathis，M.和B.Briscoe，“拥堵暴露（CONEX）概念和抽象机制”，正在进行的工作，2012年10月。
[CONEX-DATA] Briscoe, B. and M. Sridharan, "Network Performance Isolation in Data Centres using Congestion Exposure (ConEx)", Work in Progress, July 2012.
[CONEX-DATA]Briscoe，B.和M.Sridharan，“使用拥塞暴露（CONEX）的数据中心网络性能隔离”，正在进行的工作，2012年7月。
[CONEX-DEPLOY] Briscoe, B., "Initial Congestion Exposure (ConEx) Deployment Examples", Work in Progress, July 2012.
[CONEX-DEPLOY]Briscoe，B.，“初始拥塞暴露（CONEX）部署示例”，正在进行的工作，2012年7月。
[CONEX-DESTOPT] Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 Destination Option for ConEx", Work in Progress, September 2012.
[CONEX-DESTOPT]Krishnan，S.，Kuehlewind，M.，和C.Ucendo，“CONEX的IPv6目的地选项”，正在进行的工作，2012年9月。
[CONEX-MOBILE] Kutscher, D., Mir, F., Winter, R., Krishnan, S., Zhang, Y., and C. Bernardos, "Mobile Communication Congestion Exposure Scenario", Work in Progress, July 2012.
[CONEX-MOBILE]Kutscher，D.，Mir，F.，Winter，R.，Krishnan，S.，Zhang，Y.，和C.Bernardos，“移动通信拥塞暴露场景”，正在进行的工作，2012年7月。
[CongPol] Briscoe, B., Jacquet, A., and T. Moncaster, "Policing Freedom to Use the Internet Resource Pool", ReArch 2008 hosted at the 2008 CoNEXT conference , December 2008.
[CongPol]Briscoe，B.，Jacquet，A.，和T.Moncaster，“维护使用互联网资源池的自由”，2008年12月在2008年CoNEXT会议上主办的2008年研究报告。
[LEDBAT] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", Work in Progress, September 2012.
[LEDBAT]Shalunov，S.，Hazel，G.，Iyengar，J.，和M.Kuehlewind，“低额外延迟背景传输（LEDBAT）”，在建工程，2012年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[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月。
[RFC6057] Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. Woundy, "Comcast's Protocol-Agnostic Congestion Management System", RFC 6057, December 2010.
[RFC6057]Bastian，C.，Klieber，T.，Livingood，J.，Mills，J.，和R.Woundy，“康卡斯特的协议不可知拥塞管理系统”，RFC 60572010年12月。
[TCP-MOD] Kuehlewind, M. and R. Scheffenegger, "TCP modifications for Congestion Exposure", Work in Progress, May 2012.
[TCP-MOD]Kuehlewind，M.和R.Scheffenegger，“拥塞暴露的TCP修改”，正在进行的工作，2012年5月。
[TCPM-ECN] Kuehlewind, M. and R. Scheffenegger, "More Accurate ECN Feedback in TCP", Work in Progress, July 2012.
[TCPM-ECN]Kuehlewind，M.和R.Scheffenegger，“TCP中更准确的ECN反馈”，正在进行的工作，2012年7月。
[TR-059] Anschutz, T., Ed., "DSL Forum Technical Report TR-059: Requirements for the Support of QoS-Enabled IP Services", September 2003.
[TR-059]Anschutz，T.，编辑，“DSL论坛技术报告TR-059：支持QoS支持IP服务的要求”，2003年9月。
[TR-101] Cohen, A., Ed. and E. Schrum, Ed., "DSL Forum Technical Report TR-101: Migration to Ethernet-Based DSL Aggregation", April 2006.
[TR-101]Cohen，A.，Ed.和E.Schrum，Ed.，“DSL论坛技术报告TR-101：迁移到基于以太网的DSL聚合”，2006年4月。
Authors' Addresses
作者地址
Bob Briscoe (editor) BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK
鲍勃·布里斯科（编辑）英国电信B54/77，英国亚达斯特拉尔公园马特勒沙姆希思伊普斯维奇IP5 3RE
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Richard Woundy (editor) Comcast 1701 John F Kennedy Boulevard Philadelphia, PA 19103 US
理查德·沃迪（编辑）康卡斯特1701美国宾夕法尼亚州费城肯尼迪大道约翰·F·肯尼迪大道19103号
EMail: richard_woundy@cable.comcast.com
URI: http://www.comcast.com
EMail: richard_woundy@cable.comcast.com
URI: http://www.comcast.com
Alissa Cooper (editor) CDT 1634 Eye St. NW, Suite 1100 Washington, DC 20006 US
Alissa Cooper（编辑）CDT 1634 Eye St.NW，美国华盛顿特区1100号套房，邮编：20006
EMail: acooper@cdt.org
EMail: acooper@cdt.org