Network Working Group S. Floyd, Ed.
Request for Comments: 5166 March 2008
Category: Informational
Network Working Group S. Floyd, Ed.
Request for Comments: 5166 March 2008
Category: Informational
Metrics for the Evaluation of Congestion Control Mechanisms
拥塞控制机制评估指标
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
IESG Note
IESG注释
This document is not an IETF Internet Standard. It represents the individual opinion(s) of one or more members of the TMRG Research Group of the Internet Research Task Force. It may be considered for standardization by the IETF or adoption as an IRTF Research Group consensus document in the future.
本文件不是IETF互联网标准。它代表互联网研究工作组TMRG研究小组一名或多名成员的个人意见。IETF可能会考虑将其标准化，或在将来将其作为IRTF研究小组的共识文件采用。
Abstract
摘要
This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.
本文讨论了在评估新的或改进的互联网拥塞控制机制时要考虑的指标。其中包括评估新传输协议、对TCP的拟议修改、应用程序级拥塞控制和路由器中的主动队列管理（AQM）机制的指标。本文档是旨在改进我们在评估传输协议时使用的模型的一系列文档中的第一个。
This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric.
本文件是交通建模研究组（TMRG）的产品，已收到研究组（RG）许多成员的详细反馈。正如本文件试图阐明的那样，研究界（或IETF界、供应商界、运营界或任何其他界）对于拥塞控制机制应设计为优化吞吐量和延迟之间权衡的指标，不一定存在共识，竞争流之间的公平性等。然而，我们认为，有一个明确的共识，即应该根据一系列指标之间的权衡来评估拥塞控制机制，而不是针对单个指标进行优化。
Table of Contents
目录
1. Introduction ....................................................2
2. Metrics .........................................................3
2.1. Throughput, Delay, and Loss Rates ..........................4
2.1.1. Throughput ..........................................5
2.1.2. Delay ...............................................6
2.1.3. Packet Loss Rates ...................................6
2.2. Response Times and Minimizing Oscillations .................7
2.2.1. Response to Changes .................................7
2.2.2. Minimizing Oscillations .............................8
2.3. Fairness and Convergence ...................................9
2.3.1. Metrics for Fairness between Flows .................10
2.3.2. Metrics for Fairness between Flows with
Different Resource Requirements ....................10
2.3.3. Comments on Fairness ...............................12
2.4. Robustness for Challenging Environments ...................13
2.5. Robustness to Failures and to Misbehaving Users ...........14
2.6. Deployability .............................................14
2.7. Metrics for Specific Types of Transport ...................15
2.8. User-Based Metrics ........................................15
3. Metrics in the IP Performance Metrics (IPPM) Working Group .....15
4. Comments on Methodology ........................................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Informative References .........................................17
1. Introduction ....................................................2
2. Metrics .........................................................3
2.1. Throughput, Delay, and Loss Rates ..........................4
2.1.1. Throughput ..........................................5
2.1.2. Delay ...............................................6
2.1.3. Packet Loss Rates ...................................6
2.2. Response Times and Minimizing Oscillations .................7
2.2.1. Response to Changes .................................7
2.2.2. Minimizing Oscillations .............................8
2.3. Fairness and Convergence ...................................9
2.3.1. Metrics for Fairness between Flows .................10
2.3.2. Metrics for Fairness between Flows with
Different Resource Requirements ....................10
2.3.3. Comments on Fairness ...............................12
2.4. Robustness for Challenging Environments ...................13
2.5. Robustness to Failures and to Misbehaving Users ...........14
2.6. Deployability .............................................14
2.7. Metrics for Specific Types of Transport ...................15
2.8. User-Based Metrics ........................................15
3. Metrics in the IP Performance Metrics (IPPM) Working Group .....15
4. Comments on Methodology ........................................16
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Informative References .........................................17
As a step towards improving our methodologies for evaluating congestion control mechanisms, in this document we discuss some of the metrics to be considered. We also consider the relationship between metrics, e.g., the well-known trade-off between throughput and delay. This document doesn't attempt to specify every metric that a study might consider; for example, there are domain-specific metrics that researchers might consider that are over and above the metrics laid out here.
作为改进拥塞控制机制评估方法的一个步骤，在本文中，我们将讨论一些需要考虑的指标。我们还考虑度量之间的关系，例如，众所周知的吞吐量和延迟之间的权衡。本文档不试图指定研究可能考虑的每一个度量；例如，有特定领域的指标，研究人员可能会认为，超出了这里规定的度量标准。
We consider metrics for aggregate traffic (taking into account the effect of flows on competing traffic in the network) as well as the heterogeneous goals of different applications or transport protocols (e.g., of high throughput for bulk data transfer, and of low delay for interactive voice or video). Different transport protocols or AQM mechanisms might have goals of optimizing different sets of metrics, with one transport protocol optimized for per-flow throughput and another optimized for robustness over wireless links, and with different degrees of attention to fairness with competing traffic. We hope this document will be used as a step in evaluating
我们考虑总流量的度量（考虑到流对网络中的竞争流量的影响）以及不同应用或传输协议（例如，大容量数据传输的高吞吐量，以及交互式语音或视频的低延迟）的异构目标。不同的传输协议或AQM机制的目标可能是优化不同的度量集，其中一个传输协议针对每流吞吐量进行优化，另一个针对无线链路上的健壮性进行优化，并对竞争流量的公平性给予不同程度的关注。我们希望本文件将作为评估的一个步骤
proposed congestion control mechanisms for a wide range of metrics, for example, noting that Mechanism X is good at optimizing Metric A, but pays the price with poor performance for Metric B. The goal would be to have a broad view of both the strengths and weaknesses of newly proposed congestion control mechanisms.
针对广泛指标提出的拥塞控制机制，例如，注意到机制X擅长优化指标a，但为指标B付出了性能差的代价。目标是全面了解新提出的拥塞控制机制的优缺点。
Subsequent documents are planned to present sets of simulation and testbed scenarios for the evaluation of transport protocols and of congestion control mechanisms, based on the best current practice of the research community. These are not intended to be complete or final benchmark test suites, but simply to be one step of many to be used by researchers in evaluating congestion control mechanisms. Subsequent documents are also planned on the methodologies in using these sets of scenarios.
随后的文件计划根据研究界当前的最佳实践，提出一系列模拟和试验台场景，用于评估传输协议和拥塞控制机制。这些并不是完整的或最终的基准测试套件，只是研究人员在评估拥塞控制机制时使用的许多测试套件中的一个步骤。后续文件还计划介绍使用这些场景集的方法。
This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric.
本文件是交通建模研究组（TMRG）的产品，已收到研究组（RG）许多成员的详细反馈。正如本文件试图阐明的那样，研究界（或IETF界、供应商界、运营界或任何其他界）对于拥塞控制机制应设计为优化吞吐量和延迟之间权衡的指标，不一定存在共识，竞争流之间的公平性等。然而，我们认为，有一个明确的共识，即应该根据一系列指标之间的权衡来评估拥塞控制机制，而不是针对单个指标进行优化。
The metrics that we discuss are the following:
我们讨论的指标如下：
o Throughput;
o 吞吐量
o Delay;
o 延迟
o Packet loss rates;
o 丢包率；
o Response to sudden changes or to transient events;
o 对突然变化或瞬态事件的响应；
o Minimizing oscillations in throughput or in delay;
o 最小化吞吐量或延迟的波动；
o Fairness and convergence times;
o 公平与融合时代；
o Robustness for challenging environments;
o 对挑战性环境的鲁棒性；
o Robustness to failures and to misbehaving users;
o 对故障和行为不端的用户具有鲁棒性；
o Deployability;
o 可部署性；
o Metrics for specific types of transport;
o 特定运输类型的指标；
o User-based metrics.
o 基于用户的度量。
We consider each of these below. Many of the metrics have network-based, flow-based, and user-based interpretations. For example, network-based metrics can consider aggregate bandwidth and aggregate drop rates, flow-based metrics can consider end-to-end transfer times for file transfers or end-to-end delay and packet drop rates for interactive traffic, and user-based metrics can consider user wait time or user satisfaction with the multimedia experience. Our main goal in this document is to explain the set of metrics that can be relevant, and not to legislate on the most appropriate methodology for using each general metric.
我们考虑下面的每一个。许多指标都有基于网络、基于流和基于用户的解释。例如，基于网络的度量可以考虑总带宽和总丢包率，基于流的度量可以考虑文件传输的端到端传输时间或交互业务的端到端延迟和丢包率，并且基于用户的度量可以考虑用户等待时间或用户对多媒体体验的满意度。我们在本文档中的主要目标是解释可能相关的度量集，而不是为使用每个通用度量制定最合适的方法。
For some of the metrics, such as fairness, there is not a clear agreement in the network community about the desired goals. In these cases, the document attempts to present the range of approaches.
对于一些指标，例如公平性，网络社区对于期望的目标没有明确的一致意见。在这些情况下，本文件试图介绍各种方法。
Because of the clear trade-offs between throughput, delay, and loss rates, it can be useful to consider these three metrics together. The trade-offs are most clear in terms of queue management at the router; is the queue configured to maximize aggregate throughput, to minimize delay and loss rates, or some compromise between the two? An alternative would be to consider a separate metric such as power, defined in this context as throughput over delay, that combines throughput and delay. However, we do not propose in this document a clear target in terms of the trade-offs between throughput and delay; we are simply proposing that the evaluation of transport protocols include an exploration of the competing metrics.
由于吞吐量、延迟和丢包率之间的明确权衡，因此可以将这三个度量考虑在一起。在路由器的队列管理方面，权衡最为明显；队列是否配置为最大化聚合吞吐量、最小化延迟和丢失率，或者两者之间存在某种折衷？另一种选择是考虑一个单独的度量，如功率，在此上下文中定义为吞吐量超过延迟，结合吞吐量和延迟。然而，我们在本文件中并未就吞吐量和延迟之间的权衡提出明确的目标；我们只是建议对传输协议的评估包括对竞争指标的探索。
Using flow-based metrics instead of router-based metrics, the relationship between per-flow throughput, delay, and loss rates can often be given by the transport protocol itself. For example, in TCP, the sending rate s in packets per second is given as:
使用基于流的度量而不是基于路由器的度量，每流吞吐量、延迟和丢失率之间的关系通常可以由传输协议本身给出。例如，在TCP中，发送速率s（以每秒数据包为单位）如下所示：
s = 1.2/(RTT*sqrt(p)),
s=1.2/（RTT*sqrt（p）），
for the round-trip time RTT and loss rate p [FF99].
对于往返时间RTT和损失率p[FF99]。
Throughput can be measured as a router-based metric of aggregate link utilization, as a flow-based metric of per-connection transfer times, and as user-based metrics of utility functions or user wait times. It is a clear goal of most congestion control mechanisms to maximize throughput, subject to application demand and to the constraints of the other metrics.
吞吐量可以作为聚合链路利用率的基于路由器的度量、每连接传输时间的基于流的度量以及效用函数或用户等待时间的基于用户的度量来度量。大多数拥塞控制机制的明确目标是最大化吞吐量，这取决于应用程序需求和其他指标的约束。
Throughput is sometimes distinguished from goodput, where throughput is the link utilization or flow rate in bytes per second; goodput, also measured in bytes per second, is the subset of throughput consisting of useful traffic. That is, 'goodput' excludes duplicate packets, packets that will be dropped downstream, packet fragments or ATM cells that are dropped at the receiver because they can't be re-assembled into complete packets, and the like. In general, this document doesn't distinguish between throughput and goodput, and uses the general term "throughput".
吞吐量有时与goodput不同，goodput是指链路利用率或以字节/秒为单位的流量；goodput（也以每秒字节数为单位）是由有用流量组成的吞吐量子集。也就是说，“goodput”不包括重复数据包、将在下游丢弃的数据包、由于无法重新组装成完整数据包而在接收方丢弃的数据包片段或ATM信元等。一般来说，本文档不区分吞吐量和吞吐量，而是使用通用术语“吞吐量”。
We note that maximizing throughput is of concern in a wide range of environments, from highly-congested networks to under-utilized ones, and from long-lived flows to very short ones. As an example, throughput has been used as one of the metrics for evaluating Quick-Start, a proposal to allow flows to start up faster than slow-start, where throughput has been evaluated in terms of the transfer times for connections with a range of transfer sizes [RFC4782] [SAF06].
我们注意到，从高度拥挤的网络到未充分利用的网络，从长寿命的流量到极短的流量，在各种环境中，最大化吞吐量都是值得关注的。例如，吞吐量已被用作评估快速启动的指标之一，这是一项允许流启动快于慢速启动的建议，其中吞吐量已根据具有一系列传输大小的连接的传输时间进行评估[RFC4782][SAF06]。
In some contexts, it might be sufficient to consider the aggregate throughput or the mean per-flow throughput [DM06], while in other contexts it might be necessary to consider the distribution of per-flow throughput. Some researchers evaluate transport protocols in terms of maximizing the aggregate user utility, where a user's utility is generally defined as a function of the user's throughput [KMT98].
在某些上下文中，考虑总吞吐量或平均每流量吞吐量[DM06 ]可能是足够的，而在其他上下文中，可能需要考虑每流吞吐量的分布。一些研究人员从最大化聚合用户效用的角度评估传输协议，其中用户效用通常定义为用户吞吐量的函数[KMT98]。
Individual applications can have application-specific needs in terms of throughput. For example, real-time video traffic can have highly variable bandwidth demands; Voice over IP (VoIP) traffic is sensitive to the amount of bandwidth received immediately after idle periods. Thus, user metrics for throughput can be more complex than simply the per-connection transfer time.
单个应用程序在吞吐量方面可能有特定于应用程序的需求。例如，实时视频流量可能具有高度可变的带宽需求；IP语音（VoIP）流量对空闲期后立即接收的带宽量很敏感。因此，用户吞吐量指标可能比单连接传输时间更复杂。
Like throughput, delay can be measured as a router-based metric of queueing delay over time, or as a flow-based metric in terms of per-packet transfer times. Per-packet delay can also include delay at the sender waiting for the transport protocol to send the packet. For reliable transfer, the per-packet transfer time seen by the application includes the possible delay of retransmitting a lost packet.
与吞吐量一样，延迟可以作为基于路由器的排队延迟随时间变化的度量，也可以作为基于流的每包传输时间度量。每个分组的延迟还可以包括发送方等待传输协议发送分组的延迟。对于可靠传输，应用程序看到的每个数据包传输时间包括重新传输丢失数据包的可能延迟。
Users of bulk data transfer applications might care about per-packet transfer times only in so far as they affect the per-connection transfer time. On the other end of the spectrum, for users of streaming media, per-packet delay can be a significant concern. Note that in some cases the average delay might not capture the metric of interest to the users; for example, some users might care about the worst-case delay, or about the tail of the delay distribution.
批量数据传输应用程序的用户可能只关心每个数据包的传输时间，只要它们影响每个连接的传输时间。另一方面，对于流媒体用户来说，每包延迟可能是一个重要的问题。注意，在某些情况下，平均延迟可能无法捕获用户感兴趣的度量；例如，一些用户可能关心最坏情况下的延迟，或者延迟分布的尾部。
Note that queueing delay at a router is shared by all flows at a FIFO (First-In First-Out) queue. Thus, the router-based queueing delay induced by bulk data transfers can be important even if the bulk data transfers themselves are not concerned with per-packet transfer times.
请注意，路由器的排队延迟由FIFO（先进先出）队列中的所有流共享。因此，即使批量数据传输本身与每包传输时间无关，由批量数据传输引起的基于路由器的排队延迟也很重要。
Packet loss rates can be measured as a network-based or as a flow-based metric.
分组丢失率可以作为基于网络或基于流的度量来测量。
When evaluating the effect of packet losses or ECN marks (Explicit Congestion Notification) [RFC3168] on the performance of a congestion control mechanism for an individual flow, researchers often use both the packet loss/mark rate for that connection and the congestion event rate (also called the loss event rate), where a congestion event or loss event consists of one or more lost or marked packets in one round-trip time [RFC3448].
在评估分组丢失或ECN标记（显式拥塞通知）[RFC3168]对单个流的拥塞控制机制性能的影响时，研究人员通常使用该连接的分组丢失/标记率和拥塞事件率（也称为丢失事件率），其中，拥塞事件或丢失事件由一个或多个在往返时间内丢失或标记的数据包组成[RFC3448]。
Some users might care about the packet loss rate only in so far as it affects per-connection transfer times, while other users might care about packet loss rates directly. RFC 3611, RTP Control Protocol Extended Reports, describes a VoIP performance-reporting standard called RTP Control Protocol Extended Reports (RTCP XR), which includes a set of burst metrics. In RFC 3611, a burst is defined as the maximal sequence starting and ending with a lost packet, and not including a sequence of Gmin or more packets that are not lost [RFC3611]. The burst metrics in RFC 3611 consist of the burst density (the fraction of packets in bursts), gap density (the fraction of packets in the gaps between bursts), burst duration (the
一些用户可能只关心影响每连接传输时间的数据包丢失率，而其他用户可能直接关心数据包丢失率。RFC 3611，RTP控制协议扩展报告，描述了一种称为RTP控制协议扩展报告（RTCP XR）的VoIP性能报告标准，其中包括一组突发度量。在RFC 3611中，突发被定义为以丢失的分组开始和结束的最大序列，并且不包括未丢失的Gmin或更多分组的序列[RFC3611]。RFC 3611中的突发度量包括突发密度（突发中的分组分数）、间隙密度（突发之间的间隙中的分组分数）、突发持续时间（突发持续时间）
mean duration of bursts in seconds), and gap duration (the mean duration of gaps in seconds). RFC 3357 derives metrics for "loss distance" and "loss period", along with statistics that capture loss patterns experienced by packet streams on the Internet [RFC3357].
脉冲的平均持续时间（以秒为单位）和间隔持续时间（间隔的平均持续时间（以秒为单位）。RFC 3357导出“丢失距离”和“丢失周期”的度量，以及捕获互联网上数据包流所经历的丢失模式的统计数据[RFC3357]。
In some cases, it is useful to distinguish between packets dropped at routers due to congestion and packets lost in the network due to corruption.
在某些情况下，区分由于拥塞而在路由器上丢弃的数据包和由于损坏而在网络中丢失的数据包是很有用的。
One network-related reason to avoid high steady-state packet loss rates is to avoid congestion collapse in environments containing paths with multiple congested links. In such environments, high packet loss rates could result in congested links wasting scarce bandwidth by carrying packets that will only be dropped downstream before being delivered to the receiver [RFC2914]. We also note that in some cases, the retransmit rate can be high, and the goodput correspondingly low, even with a low packet drop rate [AEO03].
避免高稳态丢包率的一个与网络相关的原因是避免在包含多个拥塞链路的路径的环境中出现拥塞崩溃。在这样的环境中，高丢包率可能会导致拥塞链路，通过携带在发送到接收器之前只会在下游丢弃的数据包而浪费稀缺的带宽[RFC2914]。我们还注意到，在某些情况下，即使分组丢弃率较低，重传率也可能较高，而goodput也相应较低[AEO03]。
In this section, we consider response times and oscillations together, as there are well-known trade-offs between improving response times and minimizing oscillations. In addition, the scenarios that illustrate the dangers of poor response times are often quite different from the scenarios that illustrate the dangers of unnecessary oscillations.
在这一节中，我们考虑响应时间和振荡在一起，因为在改善响应时间和最小化振荡之间有众所周知的折衷。此外，说明响应时间差的危险的场景通常与说明不必要振荡的危险的场景大不相同。
One of the key concerns in the design of congestion control mechanisms has been the response times to sudden congestion in the network. On the one hand, congestion control mechanisms should respond reasonably promptly to sudden congestion from routing or bandwidth changes or from a burst of competing traffic. At the same time, congestion control mechanisms should not respond too severely to transient changes, e.g., to a sudden increase in delay that will dissipate in less than the connection's round-trip time.
拥塞控制机制设计中的一个关键问题是对网络中突发拥塞的响应时间。一方面，拥塞控制机制应对路由或带宽变化或竞争流量突发引起的突发拥塞做出合理及时的响应。同时，拥塞控制机制不应对瞬态变化做出过于严重的响应，例如，延迟的突然增加将在连接的往返时间内消失。
Congestion control mechanisms also have to contend with sudden changes in the bandwidth-delay product due to mobility. Such bandwidth-delay product changes are expected to become more frequent and to have greater impact than path changes today. As a result of both mobility and of the heterogeneity of wireless access types (802.11b,a,g, WIMAX, WCDMA, HS-WCDMA, E-GPRS, Bluetooth, etc.), both the bandwidth and the round-trip delay can change suddenly, sometimes by several orders of magnitude.
拥塞控制机制还必须应对由于移动性导致的带宽延迟乘积的突然变化。这种带宽延迟产品的变化预计将比今天的路径变化更频繁，影响更大。由于无线接入类型（802.11b、a、g、WIMAX、WCDMA、HS-WCDMA、E-GPRS、蓝牙等）的移动性和异构性，带宽和往返延迟都可能突然发生变化，有时会变化几个数量级。
Evaluating the response to sudden or transient changes can be of particular concern for slowly responding congestion control mechanisms such as equation-based congestion control [RFC3448] and AIMD (Additive Increase Multiplicative Decrease) or for related mechanisms using parameters that make them more slowly-responding than TCP [BB01] [BBFS01].
对于缓慢响应的拥塞控制机制（如基于等式的拥塞控制[RFC3448]和AIMD（加法-增加-乘法-减少））或使用使其响应比TCP[BB01][BBFS01]更慢的参数的相关机制，评估对突然或瞬态变化的响应可能特别令人关注。
In addition to the responsiveness and smoothness of aggregate traffic, one can consider the trade-offs between responsiveness, smoothness, and aggressiveness for an individual connection [FHP00] [YKL01]. In this case, smoothness can be defined by the largest reduction in the sending rate in one round-trip time, in a deterministic environment with a packet drop exactly every 1/p packets. The responsiveness is defined as the number of round-trip times of sustained congestion required for the sender to halve the sending rate; aggressiveness is defined as the maximum increase in the sending rate in one round-trip time, in packets per second, in the absence of congestion. This aggressiveness can be a function of the mode of the transport protocol; for TCP, the aggressiveness of slow-start is quite different from the aggressiveness of congestion avoidance mode.
除了总流量的响应性和平滑性之外，还可以考虑个体连接[FHP0] [YKL01]之间的响应性、平滑性和攻击性之间的权衡。在这种情况下，平滑度可以通过在一个往返时间内发送速率的最大降低来定义，在确定性环境中，每1/p个数据包恰好丢弃一个数据包。响应性定义为发送方将发送速率减半所需的持续拥塞的往返次数；攻击性被定义为在没有拥塞的情况下，在一个往返时间内发送速率的最大增加，以每秒数据包为单位。这种攻击性可能是传输协议模式的函数；对于TCP，慢启动的攻击性与拥塞避免模式的攻击性大不相同。
One goal is that of stability, in terms of minimizing oscillations of queueing delay or of throughput. In practice, stability is frequently associated with rate fluctuations or variance. Rate variations can result in fluctuations in router queue size and therefore of queue overflows. These queue overflows can cause loss synchronizations across coexisting flows and periodic under-utilization of link capacity, both of which are considered to be general signs of network instability. Thus, measuring the rate variations of flows is often used to measure the stability of transport protocols. To measure rate variations, [JWL04], [RX05], and [FHPW00] use the coefficient of variation (CoV) of per-flow transmission rates, and [WCL05] suggests the use of standard deviations of per-flow rates. Since rate variations are a function of time scales, it makes sense to measure these rate variations over various time scales.
一个目标是稳定性，即最小化排队延迟或吞吐量的振荡。在实践中，稳定性经常与利率波动或差异相关联。速率变化会导致路由器队列大小的波动，从而导致队列溢出。这些队列溢出会导致共存流之间的同步丢失和链路容量的周期性利用不足，这两种情况都被认为是网络不稳定的一般迹象。因此，测量流量的速率变化通常用于测量传输协议的稳定性。为了测量速率变化，[JWL04]、[RX05]和[FHPW00]使用每流量传输速率的变化系数（CoV），并且[WCL05]建议使用每流量的标准偏差。由于速率变化是时间尺度的函数，因此在不同的时间尺度上测量这些速率变化是有意义的。
Measuring per-flow rate variations, however, is only one aspect of transport protocol stability. A realistic experimental setting always involves multiple flows of the transport protocol being observed, along with a significant amount of cross traffic, with rates varying over time on both the forward and reverse paths. As a congestion control protocol must adapt its rate to the varying rates of competing traffic, just measuring the per-flow statistics of a subset of the traffic could be misleading because it measures the
然而，测量每流量变化只是传输协议稳定性的一个方面。一个现实的实验设置总是涉及到观察到的传输协议的多个流，以及大量的交叉流量，在正向和反向路径上的速率随时间而变化。由于拥塞控制协议必须使其速率适应竞争流量的变化速率，因此仅测量流量子集的每流统计数据可能会产生误导，因为它测量的是
rate fluctuations due in part to the adaptation to competing traffic on the path. Thus, per-flow statistics are most meaningful if they are accompanied by the statistics measured at the network level. As a complementary metric to the per-flow statistics, [HKLRX06] uses measurements of the rate variations of the aggregate flows observed in bottleneck routers over various time scales.
部分由于适应道路上的竞争流量而导致的速率波动。因此，如果每个流量的统计数据与在网络级别测量的统计数据同时出现，则它们是最有意义的。作为每流量统计的补充指标，[HKLRX06]使用瓶颈路由器在不同时间尺度上观察到的聚合流量的速率变化测量值。
Minimizing oscillations in queueing delay or throughput has related per-flow metrics of minimizing jitter in round-trip times and loss rates.
最小化排队延迟或吞吐量中的振荡与最小化往返时间和丢失率中的抖动的每流度量相关。
An orthogonal goal for some congestion control mechanisms, e.g., for equation-based congestion control, is to minimize the oscillations in the sending rate for an individual connection, given an environment with a fixed, steady-state packet drop rate. (As is well known, TCP congestion control is characterized by a pronounced oscillation in the sending rate, with the sender halving the sending rate in response to congestion.) One metric for the level of oscillations is the smoothness metric given in Section 2.2.1 above.
某些拥塞控制机制（例如，基于方程的拥塞控制）的正交目标是，在具有固定、稳定的分组丢弃率的环境中，最小化单个连接的发送速率的振荡。（众所周知，TCP拥塞控制的特点是发送速率出现明显的振荡，发送方响应拥塞将发送速率减半。）振荡程度的一个度量是上文第2.2.1节给出的平滑度度量。
As discussed in [FK07], the synchronization of loss events can also affect convergence times, throughput, and delay.
如[FK07]所述，丢失事件的同步也会影响收敛时间、吞吐量和延迟。
Another set of metrics is that of fairness and convergence times. Fairness can be considered between flows of the same protocol and between flows using different protocols (e.g., TCP-friendliness, referring to fairness between TCP and a new transport protocol). Fairness can also be considered between sessions, between users, or between other entities.
另一组指标是公平性和收敛时间。可以考虑相同协议的流之间以及使用不同协议的流之间的公平性（例如，TCP友好性，指TCP和新传输协议之间的公平性）。还可以考虑会话之间、用户之间或其他实体之间的公平性。
There are a number of different fairness measures. These include max-min fairness [HG86], proportional fairness [KMT98] [K01], the fairness index proposed in [JCH84], and the product measure, a variant of network power [BJ81].
有许多不同的公平措施。其中包括最大最小公平性[HG86]、比例公平性[KMT98][K01]、[JCH84]中提出的公平性指数以及网络功率的一种变体产品度量[BJ81]。
This section discusses fairness metrics that consider the fairness between flows, but that don't take into account different characteristics of flows (e.g., the number of links in the path or the round-trip time). For the discussion of fairness metrics, let x_i be the throughput for the i-th connection.
本节讨论考虑流量之间的公平性的公平性度量，但不考虑流的不同特性（例如，路径中的链路数量或往返时间）。为了讨论公平性度量，假设x_i是第i个连接的吞吐量。
Jain's fairness index: The fairness index in [JCH84] is:
Jain的公平性指数[JCH84]中的公平性指数为：
(( sum_i x_i )^2) / (n * sum_i ( (x_i)^2 )),
（（sum_i x_i）^2）/（n*sum i（（x_i）^2）），
where there are n users. This fairness index ranges from 0 to 1, and it is maximum when all users receive the same allocation. This index is k/n when k users equally share the resource, and the other n-k users receive zero allocation.
其中有n个用户。该公平性指数的范围为0到1，当所有用户收到相同的分配时，该指数最大。当k个用户平均共享资源，而其他n-k个用户得到零分配时，该索引为k/n。
The product measure: The product measure:
产品规格：产品规格：
product_i x_i ,
产品(i)x(i),，
the product of the throughput of the individual connections, is also used as a measure of fairness. (In some contexts x_i is taken as the power of the i-th connection, and the product measure is referred to as network power.) The product measure is particularly sensitive to segregation; the product measure is zero if any connection receives zero throughput. In [MS91], it is shown that for a network with many connections and one shared gateway, the product measure is maximized when all connections receive the same throughput.
单个连接的吞吐量的乘积也用作公平性的度量。（在某些情况下，x_i被视为第i个连接的功率，产品度量被称为网络功率。）产品度量对分离特别敏感；如果任何连接的吞吐量为零，则乘积度量值为零。[MS91]中指出，对于具有多个连接和一个共享网关的网络，当所有连接接收到相同的吞吐量时，乘积度量最大化。
Epsilon-fairness: A rate allocation is defined as epsilon-fair if
ε公平性：如果
(min_i x_i) / (max_i x_i) >= 1 - epsilon.
（min_i x_i）/（max_i x_i）>=1-ε。
Epsilon-fairness measures the worst-case ratio between any two throughput rates [ZKL04]. Epsilon-fairness is related to max-min fairness, defined later in this document.
Epsilon公平性度量任意两个吞吐量率之间的最坏情况比率[ZKL04]。Epsilon公平性与本文后面定义的max-min公平性相关。
2.3.2. Metrics for Fairness between Flows with Different Resource Requirements
2.3.2. 具有不同资源需求的流之间的公平性度量
This section discusses metrics for fairness between flows with different resource requirements, that is, with different utility functions, round-trip times, or number of links on the path. Many of these metrics can be described as solutions to utility maximization problems [K01]; the total utility quantifies both the fairness and the throughput.
本节讨论具有不同资源需求的流之间的公平性度量，即具有不同的效用函数、往返时间或路径上的链接数。其中许多指标可以被描述为效用最大化问题的解决方案[K01]；总效用量化了公平性和吞吐量。
Max-min fairness: In order to satisfy the max-min fairness criteria, the smallest throughput rate must be as large as possible. Given this condition, the next-smallest throughput rate must be as large as possible, and so on. Thus, the max-min fairness gives absolute priority to the smallest flows. (Max-min fairness can be explained by the progressive filling algorithm, where all flow rates start at zero, and the rates all grow at the same pace. Each flow rate stops growing only when one or more links on the path reach link capacity.)
最大最小公平性：为了满足最大最小公平性标准，最小吞吐量必须尽可能大。在这种情况下，下一个最小的吞吐量必须尽可能大，以此类推。因此，max-min公平性将绝对优先级给予最小流。（最大-最小公平性可以用渐进填充算法来解释，其中所有流量都从零开始，并且以相同的速度增长。只有当路径上的一个或多个链路达到链路容量时，每个流量才会停止增长。）
Proportional fairness: In contrast, a feasible allocation, x, is defined as proportionally fair if, for any other feasible allocation x*, the aggregate of proportional changes is zero or negative:
比例公平：相反，如果对于任何其他可行分配x*，比例变化的总和为零或负，则可行分配x被定义为比例公平：
sum_i ( (x*_i - x_i)/x_i ) <= 0.
总和i（（x*\u i-x\u i）/x\u i）<=0。
"This criterion favours smaller flows, but less emphatically than max-min fairness" [K01]. (Using the language of utility functions, proportional fairness can be achieved by using logarithmic utility functions, and maximizing the sum of the per-flow utility functions; see [KMT98] for a fuller explanation.)
“该标准有利于较小的流量，但不如最大最小公平性”[K01]。（使用效用函数的语言，可以通过使用对数效用函数和最大化每流效用函数的总和来实现比例公平；有关更全面的解释，请参见[KMT98]）
Minimum potential delay fairness: Minimum potential delay fairness has been shown to model TCP [KS03], and is a compromise between max-min fairness and proportional fairness. An allocation, x, is defined as having minimum potential delay fairness if:
最小潜在延迟公平性：最小潜在延迟公平性已被证明适用于TCP[KS03]模型，是最大-最小公平性和比例公平性之间的折衷。分配x被定义为具有最小潜在延迟公平性，如果：
sum_i (1/x_i)
总和i（1/x i）
is smaller than for any other feasible allocation. That is, it would minimize the average download time if each flow was an equal-sized file.
小于任何其他可行的分配。也就是说，如果每个流是一个大小相等的文件，它将最小化平均下载时间。
In [CRM05], Colussi, et al. propose a new definition of TCP fairness, that "a set of TCP fair flows do not cause more congestion than a set of TCP flows would cause", where congestion is defined in terms of queueing delay, queueing delay variation, the congestion event rate [e.g., loss event rate], and the packet loss rate.
在[CRM05]中，Colussi等人提出了TCP公平性的新定义，即“一组TCP公平流不会造成比一组TCP流更大的拥塞”，其中拥塞是根据排队延迟、排队延迟变化、拥塞事件率[例如，丢失事件率]和数据包丢失率来定义的。
Chiu and Tan in [CT06] argue for redefining the notion of fairness when studying traffic controls for inelastic traffic, proposing that inelastic flows adopt other traffic controls such as admission control.
Chiu和Tan在[CT06]中主张在研究非弹性交通的交通控制时重新定义公平的概念，提出非弹性交通采用其他交通控制，如准入控制。
The usefulness of flow-rate fairness has been challenged in [B07] by Briscoe, and defended in [FA08] by Floyd and Allman. In [B07], Briscoe argues that flow-rate fairness should not be a desired goal, and that instead "we should judge fairness mechanisms on how they share out the 'cost' of each user's actions on others". Floyd and
布里斯科在[B07]中对流量公平性提出了质疑，弗洛伊德和奥尔曼在[FA08]中为流量公平性进行了辩护。在[B07]中，布里斯科认为流量公平性不应该是一个理想的目标，相反，“我们应该根据公平机制如何分担每个用户对其他用户的行为的‘成本’来判断公平机制”。弗洛伊德和
Allman in [FA08] argue that the current system based on TCP congestion control and flow-rate fairness has been useful in the real world, posing minimal demands on network and economic infrastructure and enabling users to get a share of the network resources.
Allman在[FA08]中指出，当前基于TCP拥塞控制和流量公平性的系统在现实世界中非常有用，对网络和经济基础设施的需求最小，并允许用户共享网络资源。
Trade-offs between fairness and throughput: The fairness measures in the section above generally measure both fairness and throughput, giving different weights to each. Potential trade-offs between fairness and throughput are also discussed by Tang, et al. in [TWL06], for a framework where max-min fairness is defined as the most fair. In particular, [TWL06] shows that in some topologies, throughput is proportional to fairness, while in other topologies, throughput is inversely proportional to fairness.
公平性和吞吐量之间的权衡：上一节中的公平性度量通常同时度量公平性和吞吐量，并为每个度量赋予不同的权重。Tang等人在[TWL06]中还讨论了公平性和吞吐量之间的潜在权衡问题，该框架将最大最小公平性定义为最公平。特别是，[TWL06]表明，在某些拓扑中，吞吐量与公平性成正比，而在其他拓扑中，吞吐量与公平性成反比。
Fairness and the number of congested links: Some of these fairness metrics are discussed in more detail in [F91]. We note that there is not a clear consensus for the fairness goals, in particular for fairness between flows that traverse different numbers of congested links [F91]. Utility maximization provides one framework for describing this trade-off in fairness.
公平性和拥塞链路的数量：其中一些公平性指标在[F91]中有更详细的讨论。我们注意到，对于公平性目标，尤其是穿越不同数量拥塞链路的流之间的公平性，还没有达成明确的共识[F91]。效用最大化提供了一个框架来描述这种公平性权衡。
Fairness and round-trip times: One goal cited in a number of new transport protocols has been that of fairness between flows with different round-trip times [KHR02] [XHR04]. We note that there is not a consensus in the networking community about the desirability of this goal, or about the implications and interactions between this goal and other metrics [FJ92] (Section 3.3). One common argument against the goal of fairness between flows with different round-trip times has been that flows with long round-trip times consume more resources; this aspect is covered by the previous paragraph. Researchers have also noted the difference between the RTT-unfairness of standard TCP, and the greater RTT-unfairness of some proposed modifications to TCP [LLS05].
公平性和往返时间：在许多新的传输协议中引用的一个目标是不同往返时间的流之间的公平性[KHR02][XHR04]。我们注意到，对于该目标的可取性，或者该目标与其他指标[FJ92]（第3.3节）之间的含义和相互作用，网络社区没有达成共识。反对不同往返时间的流之间公平目标的一个常见论点是，长往返时间的流消耗更多的资源；上一段涉及这方面。研究人员还注意到标准TCP的RTT不公平性与TCP的某些拟议修改的更大RTT不公平性之间的差异[LLS05]。
Fairness and packet size: One fairness issue is that of the relative fairness for flows with different packet sizes. Many file transfer applications will use the maximum packet size possible; in contrast, low-bandwidth VoIP flows are likely to send small packets, sending a new packet every 10 to 40 ms., to limit delay. Should a small-packet VoIP connection receive the same sending rate in *bytes* per second as a large-packet TCP connection in the same environment, or should it receive the same sending rate in *packets* per second? This fairness issue has been discussed in more detail in [RFC3714], with [RFC4828] also describing the ways that packet size can affect the packet drop rate experienced by a flow.
公平性和数据包大小：一个公平性问题是具有不同数据包大小的流的相对公平性问题。许多文件传输应用程序将使用可能的最大数据包大小；相反，低带宽VoIP流可能发送小数据包，每10到40毫秒发送一个新数据包，以限制延迟。在同一环境中，小数据包VoIP连接应接收与大数据包TCP连接相同的发送速率（以*字节*秒为单位），还是应接收相同的发送速率（以*数据包*秒为单位）？[RFC3714]更详细地讨论了该公平性问题，[RFC4828]还描述了数据包大小影响流经历的数据包丢弃率的方式。
Convergence times: Convergence times concern the time for convergence to fairness between an existing flow and a newly starting one, and are a special concern for environments with high-bandwidth long-delay flows. Convergence times also concern the time for convergence to fairness after a sudden change such as a change in the network path, the competing cross-traffic, or the characteristics of a wireless link. As with fairness, convergence times can matter both between flows of the same protocol, and between flows using different protocols [SLFK03]. One metric used for convergence times is the delta-fair convergence time, defined as the time taken for two flows with the same round-trip time to go from shares of 100/101-th and 1/101-th of the link bandwidth, to having close to fair sharing with shares of (1+delta)/2 and (1-delta)/2 of the link bandwidth [BBFS01]. A similar metric for convergence times measures the convergence time as the number of round-trip times for two flows to reach epsilon-fairness, when starting from a maximally-unfair state [ZKL04].
收敛时间：收敛时间涉及现有流和新启动流之间收敛到公平性的时间，并且对于具有高带宽长延迟流的环境是一个特别关注的问题。收敛时间还涉及突然变化后收敛到公平性的时间，例如网络路径的变化、相互竞争的交叉流量或无线链路的特性。与公平性一样，同一协议的流之间以及使用不同协议的流之间的收敛时间都很重要[SLFK03]。用于收敛时间的一个度量是delta公平收敛时间，定义为具有相同往返时间的两个流从链路带宽的第100/101和第1/101的共享到具有接近公平共享的链路带宽的（1+delta）/2和（1-delta）/2的共享所用的时间[BBFS01]。收敛时间的类似度量将收敛时间度量为两个流在从最大不公平状态开始时达到ε公平的往返次数[ZKL04]。
While congestion control mechanisms are generally evaluated first over environments with static routing in a network of two-way point-to-point links, some environments bring up more challenging problems (e.g., corrupted packets, reordering, variable bandwidth, and mobility) as well as new metrics to be considered (e.g., energy consumption).
虽然拥塞控制机制通常首先在双向点到点链路网络中具有静态路由的环境中进行评估，但一些环境带来了更具挑战性的问题（例如，损坏的数据包、重新排序、可变带宽和移动性）以及需要考虑的新指标（例如，能耗）。
Robustness for challenging environments: Robustness needs to be explored for paths with reordering, corruption, variable bandwidth, asymmetric routing, router configuration changes, mobility, and the like [GF04]. In general, the Internet architecture has valued robustness over efficiency, e.g., when there are trade-offs between robustness and the throughput, delay, and fairness metrics described above.
挑战性环境的鲁棒性：需要探索具有重排序、损坏、可变带宽、不对称路由、路由器配置更改、移动性等的路径的鲁棒性[GF04]。一般来说，互联网架构将健壮性置于效率之上，例如，当健壮性与上述吞吐量、延迟和公平性度量之间存在权衡时。
Energy consumption: In mobile environments, the energy consumption for the mobile end-node can be a key metric that is affected by the transport protocol [TM02].
能耗：在移动环境中，移动终端节点的能耗可能是受传输协议影响的关键指标[TM02]。
The goodput ratio: For wireless networks, the goodput ratio can be a useful metric, where the goodput ratio can be defined as the useful data delivered to users as a fraction of the total amount of data transmitted on the network. A high goodput ratio indicates an efficient use of the radio spectrum and lower interference with other users.
goodput比率：对于无线网络，goodput比率可以是一个有用的指标，其中goodput比率可以定义为交付给用户的有用数据，作为在网络上传输的数据总量的一小部分。高输出比表明无线电频谱的有效利用和对其他用户的干扰较低。
One goal is for congestion control mechanisms to be robust to misbehaving users, such as receivers that 'lie' to data senders about the congestion experienced along the path or otherwise attempt to bypass the congestion control mechanisms of the sender [SCWA99]. Another goal is for congestion control mechanisms to be as robust as possible to failures, such as failures of routers in using explicit feedback to end-nodes or failures of end-nodes to follow the prescribed protocols.
一个目标是使拥塞控制机制对行为不端的用户具有鲁棒性，例如，接收器“向”数据发送者隐瞒沿路径经历的拥塞，或试图绕过发送者的拥塞控制机制[SCWA99]。另一个目标是使拥塞控制机制对故障尽可能具有鲁棒性，例如路由器无法使用显式反馈到终端节点，或者终端节点无法遵循规定的协议。
One metric for congestion control mechanisms is their deployability in the current Internet. Metrics related to deployability include the ease of failure diagnosis and the overhead in terms of packet header size or added complexity at end-nodes or routers.
拥塞控制机制的一个指标是它们在当前互联网中的部署能力。与可部署性相关的指标包括故障诊断的易用性和数据包头大小方面的开销，或终端节点或路由器增加的复杂性。
One key aspect of deployability concerns the range of deployment needed for a new congestion control mechanism. Consider the following possible deployment requirements:
可部署性的一个关键方面涉及新拥塞控制机制所需的部署范围。考虑以下可能的部署要求：
* Only at the sender (e.g., NewReno in TCP [RFC3782]);
* 仅在发送方（如TCP[RFC3782]中的NewReno）；
* Only at the receiver (e.g., delayed acknowledgements in TCP);
* 仅在接收器处（例如，TCP中的延迟确认）；
* Both the sender and receiver (e.g., Selective Acknowledgment (SACK) TCP [RFC2018]);
* 发送方和接收方（例如，选择性确认（SACK）TCP[RFC2018]）；
* At a single router (e.g., Random Early Detection (RED) [FJ93]);
* 在单个路由器上（例如，随机早期检测（RED）[FJ93]）；
* All of the routers along the end-to-end path;
* 沿端到端路径的所有路由器；
* Both end-nodes and all routers along the path (e.g., Explicit Control Protocol (XCP) [KHR02]).
* 终端节点和路径上的所有路由器（例如，显式控制协议（XCP）[KHR02]）。
Some congestion control mechanisms (e.g., XCP [KHR02], Quick-Start [RFC4782]) may also have deployment issues with IPsec, IP in IP, MPLS, other tunnels, or with non-router queues such as those in Ethernet switches.
某些拥塞控制机制（例如，XCP[KHR02]、快速启动[RFC4782]）也可能在IPsec、IP中的IP、MPLS、其他隧道或非路由器队列（如以太网交换机中的队列）方面存在部署问题。
Another deployability issue concerns the complexity of the code. How complex is the code required to implement the mechanism in software? Is floating point math required? How much new state must be kept to implement the new mechanism, and who holds that state, the routers or the end-nodes? We note that we don't suggest these questions as ways to reduce the deployability metric to a single number; we suggest them as issues that could be considered in evaluating the deployability of a proposed congestion control mechanism.
另一个可部署性问题涉及代码的复杂性。在软件中实现该机制所需的代码有多复杂？浮点数学是必需的吗？必须保持多少新状态才能实现新机制，谁持有该状态，路由器还是终端节点？我们注意到，我们不建议将这些问题作为将可部署性指标减少到单个数字的方法；我们建议在评估提议的拥塞控制机制的可部署性时考虑这些问题。
In some cases, modified metrics are needed for evaluating transport protocols intended for quality-of-service (QoS)-enabled environments or for below-best-effort traffic [VKD02] [KK03].
在某些情况下，需要修改度量来评估用于支持服务质量（QoS）的环境或低于最佳努力的流量的传输协议[VKD02][KK03]。
An alternate approach that has been proposed for the evaluation of congestion control mechanisms would be to evaluate in terms of user metrics, such as user satisfaction or in terms of application-specific utility functions. Such an approach would require the definition of a range of user metrics or of application-specific utility functions for the range of applications under consideration (e.g., FTP, HTTP, VoIP).
为评估拥塞控制机制而提出的另一种方法是根据用户指标（如用户满意度）或特定于应用程序的效用函数进行评估。这种方法需要为所考虑的应用程序范围（例如FTP、HTTP、VoIP）定义一系列用户指标或特定于应用程序的实用程序功能。
The IPPM Working Group [IPPM] was established to define performance
metrics to be used by network operators, end users, or independent
testing groups. The metrics include metrics for connectivity
[RFC2678], delay and loss [RFC2679], [RFC2680], and [RFC2681], delay
variation [RFC3393], loss patterns [RFC3357], packet reordering
[RFC4737], bulk transfer capacity [RFC3148], and link capacity
[RFC5136]. The IPPM documents give concrete, well-defined metrics,
along with a methodology for measuring the metric. The metrics
discussed in this document have a different purpose from the IPPM
metrics; in this document, we are discussing metrics as used in
analysis, simulations, and experiments for the evaluation of
congestion control mechanisms. Further, we are discussing these
metrics in a general sense, rather than looking for specific concrete
definitions for each metric. However, there are many cases where the
metric definitions from IPPM could be useful, for specific issues of
how to measure these metrics in simulations, or in testbeds, and for
providing common definitions for talking about these metrics.
The IPPM Working Group [IPPM] was established to define performance
metrics to be used by network operators, end users, or independent
testing groups. The metrics include metrics for connectivity
[RFC2678], delay and loss [RFC2679], [RFC2680], and [RFC2681], delay
variation [RFC3393], loss patterns [RFC3357], packet reordering
[RFC4737], bulk transfer capacity [RFC3148], and link capacity
[RFC5136]. The IPPM documents give concrete, well-defined metrics,
along with a methodology for measuring the metric. The metrics
discussed in this document have a different purpose from the IPPM
metrics; in this document, we are discussing metrics as used in
analysis, simulations, and experiments for the evaluation of
congestion control mechanisms. Further, we are discussing these
metrics in a general sense, rather than looking for specific concrete
definitions for each metric. However, there are many cases where the
metric definitions from IPPM could be useful, for specific issues of
how to measure these metrics in simulations, or in testbeds, and for
providing common definitions for talking about these metrics.
The types of scenarios that are used to test specific metrics, and the range of parameters that it is useful to consider, will be discussed in separate documents, e.g., along with specific scenarios for use in evaluating congestion control mechanisms.
用于测试特定度量的场景类型和其有用的参数范围将在单独的文档中讨论，例如，与用于评估拥塞控制机制的特定场景一起讨论。
We note that it can be important to evaluate metrics over a wide range of environments, with a range of link bandwidths, congestion levels, and levels of statistical multiplexing. It is also important to evaluate congestion control mechanisms in a range of scenarios, including typical ranges of connection sizes and round-trip times [FK02]. It is also useful to compare metrics for new or modified transport protocols with those of the current standards for TCP.
我们注意到，在一系列链路带宽、拥塞级别和统计多路复用级别的环境中评估指标非常重要。评估一系列场景中的拥塞控制机制也很重要，包括连接大小和往返时间的典型范围[FK02]。将新的或修改的传输协议的指标与TCP的当前标准进行比较也很有用。
As an example from the literature on evaluating transport protocols, Li, et al. in "Experimental Evaluation of TCP Protocols for High-Speed Networks" [LLS05] focus on the performance of TCP in high-speed networks, and consider metrics for aggregate throughput, loss rates, fairness (including fairness between flows with different round-trip times), response times (including convergence times), and incremental deployment. More general references on methodology include [J91]. Papers that discuss the range of metrics for evaluating congestion control include [MTZ04].
作为一个从评估传输协议的文献中的例子，李等人在“高速网络TCP协议的实验评估”[LLS05 ]中着重讨论了TCP在高速网络中的性能，并考虑了总吞吐量、丢包率、公平性（包括不同往返时间的流之间的公平性）的度量，响应时间（包括收敛时间）和增量部署。关于方法学的更一般参考文献包括[J91]。讨论拥塞控制评估指标范围的论文包括[MTZ04]。
Section 2.5 discusses the robustness of congestion control mechanisms to failures and to misbehaving users. Transport protocols also have other security concerns that are unrelated to congestion control mechanisms; these are not discussed in this document.
第2.5节讨论了拥塞控制机制对故障和行为不端用户的鲁棒性。传输协议还有其他与拥塞控制机制无关的安全问题；本文件不讨论这些问题。
Thanks to Lachlan Andrew, Mark Allman, Armando Caro, Dah Ming Chiu, Eric Coe, Dado Colussi, Wesley Eddy, Aaron Falk, Nelson Fonseca, Janardhan Iyengar, Doug Leith, Sara Landstrom, Tony Li, Saverio Mascolo, Sean Moore, Injong Rhee, David Ros, Juergen Schoenwaelder, Andras Veres, Michael Welzl, and Damon Wischik, and members of the Transport Modeling Research Group for feedback and contributions.
感谢拉克兰·安德鲁、马克·奥尔曼、阿曼多·卡洛、大明秋、埃里克·科、达多·科鲁西、卫斯理·艾迪、亚伦·福克、纳尔逊·丰塞卡、贾纳德·艾扬格、道格·莱思、萨拉·兰斯特罗姆、托尼·李、萨维里奥·马斯科洛、肖恩·摩尔、李英红、大卫·罗斯、于尔根·舍恩瓦埃尔德、安德拉斯·韦尔斯、迈克尔·韦尔茨和达蒙·维奇克，以及交通建模研究小组成员的反馈和贡献。
[AEO03] M. Allman, W. Eddy, and S. Ostermann, Estimating Loss Rates With TCP, ACM Performance Evaluation Review, 31(3), December 2003.
[AEO03]M.Allman，W.Eddy和S.Ostermann，用TCP估算损失率，ACM绩效评估评论，31（3），2003年12月。
[BB01] D. Bansal and H. Balakrishnan, Binomial Congestion Control Algorithms, IEEE Infocom, April 2001.
[BB01]D.Bansal和H.Balakrishnan，二项式拥塞控制算法，IEEE Infocom，2001年4月。
[BBFS01] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, Dynamic Behavior of Slowly-Responsive Congestion Control Algorithms, SIGCOMM 2001.
[BBFS01]D.Bansal，H.Balakrishnan，S.Floyd和S.Shenker，慢响应拥塞控制算法的动态行为，SIGCOMM 2001。
[BJ81] K. Bharath-Kumar and J. Jeffrey, A New Approach to Performance-Oriented Flow Control, IEEE Transactions on Communications, Vol.29 N.4, April 1981.
[BJ81]K.Bharath Kumar和J.Jeffrey，面向性能的流量控制的新方法，IEEE通信交易，第29卷N.4，1981年4月。
[B07] B. Briscoe, "Flow Rate Fairness: Dismantling a Religion", Computer Communications Review, V.37 N.2, April 2007.
[B07]B.Briscoe，“流量公平：摧毁宗教”，《计算机通信评论》，第37卷第2节，2007年4月。
[CRM05] D. Colussi, A New Approach to TCP-Fairness, Report C-2005- 49, University of Helsinki, Finland, 2005.
[CRM05] D. Colussi，TCP公平性的新方法，报告C-2005—49，赫尔辛基大学，芬兰，2005。
[CT06] D. Chiu and A. Tam, Redefining Fairness in the Study of TCP-friendly Traffic Controls, Technical Report, 2006.
[CT06]D.Chiu和A.Tam，重新定义TCP友好流量控制研究中的公平性，技术报告，2006年。
[DM06] N. Dukkipati and N. McKeown, Why Flow-Completion Time is the Right Metric for Congestion Control, ACM SIGCOMM, January 2006.
[DM06]N.Dukkipati和N.McKeown，《为什么流量完成时间是拥塞控制的正确指标》，ACM SIGCOMM，2006年1月。
[F91] S. Floyd, Connections with Multiple Congested Gateways in Packet-Switched Networks Part 1: One-way Traffic, Computer Communication Review, Vol.21 No.5, October 1991, p. 30-47.
[F91]S.Floyd，分组交换网络中多个拥塞网关的连接第1部分：单向通信，计算机通信评论，第21卷第5期，1991年10月，第。30-47.
[FA08] S. Floyd and M. Allman, Comments on the Usefulness of Simple Best-Effort Traffic, Work in Progress, January 2007.
[FA08]S.Floyd和M.Allman，关于简单尽力而为流量有用性的评论，正在进行的工作，2007年1月。
[FF99] Floyd, S., and Fall, K., "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF99]Floyd，S.，和Fall，K.，“促进互联网中端到端拥塞控制的使用”，IEEE/ACM网络交易，1999年8月。
[FHP00] S. Floyd, M. Handley, and J. Padhye, A Comparison of Equation-Based and AIMD Congestion Control, May 2000. URL http://www.icir.org/tfrc/.
[FHP00]S.Floyd，M.Handley和J.Padhye，《基于方程和AIMD拥塞控制的比较》，2000年5月。统一资源定位地址http://www.icir.org/tfrc/.
[FHPW00] S. Floyd, M. Handley, J. Padhye, and J. Widmer, Equation-Based Congestion Control for Unicast Applications, SIGCOMM 2000, August 2000.
[FHPW00]S.Floyd，M.Handley，J.Padhye和J.Widmer，单播应用中基于方程的拥塞控制，SIGCOMM 2000，2000年8月。
[FJ92] S. Floyd and V. Jacobson, On Traffic Phase Effects in Packet-Switched Gateways, Internetworking: Research and Experience, V.3 N.3, September 1992, p.115-156.
[FJ92]S.Floyd和V.Jacobson，《分组交换网关中的流量相位效应》，互联网：研究与经验，第3卷第3期，1992年9月，第115-156页。
[FJ93] S. Floyd and V. Jacobson, Random Early Detection gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993,
[FJ93]S.Floyd和V.Jacobson，《避免拥塞的随机早期检测网关》，IEEE/ACM网络事务，第1卷第4期，1993年8月，
[FK02] S. Floyd and E. Kohler, Internet Research Needs Better Models, Hotnets-I. October 2002.
[FK02]S.Floyd和E.Kohler，《互联网研究需要更好的模型》，Hotnets-I.2002年10月。
[FK07] S. Floyd and E. Kohler, "Tools for the Evaluation of Simulation and Testbed Scenarios", Work in Progress, February 2008.
[FK07]S.Floyd和E.Kohler，“模拟和试验台场景评估工具”，正在进行的工作，2008年2月。
[GF04] A. Gurtov and S. Floyd, Modeling Wireless Links for Transport Protocols, ACM CCR, 34(2):85-96, April 2004.
[GF04]A.Gurtov和S.Floyd，传输协议的无线链路建模，ACM CCR，34（2）：85-962004年4月。
[HKLRX06] S. Ha, Y. Kim, L. Le, I. Rhee, and L. Xu, A Step Toward Realistic Evaluation of High-speed TCP Protocols, technical report, North Carolina State University, January 2006.
[HKLRX06]S.Ha，Y.Kim，L.Le，I.Rhee和L.Xu，《迈向高速TCP协议现实评估的一步》，技术报告，北卡罗来纳州立大学，2006年1月。
[HG86] E. Hahne and R. Gallager, Round Robin Scheduling for Fair Flow Control in Data Communications Networks, IEEE International Conference on Communications, June 1986.
[HG86]E.Hahne和R.Gallager，数据通信网络中公平流控制的循环调度，IEEE国际通信会议，1986年6月。
[IPPM] IP Performance Metrics (IPPM) Working Group, URL http://www.ietf.org/html.charters/ippm-charter.html.
[IPPM]IP性能度量（IPPM）工作组，URLhttp://www.ietf.org/html.charters/ippm-charter.html.
[J91] R. Jain, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling, John Wiley & Sons, 1991.
[J91]R.Jain，《计算机系统性能分析的艺术：实验设计、测量、模拟和建模技术》，John Wiley&Sons，1991年。
[JCH84] R. Jain, D.M. Chiu, and W. Hawe, A Quantitative Measure of Fairness and Discrimination for Resource Allocation in Shared Systems, DEC TR-301, Littleton, MA: Digital Equipment Corporation, 1984.
[JCH84]R.Jain，D.M.Chiu和W.Hawe，《共享系统中资源分配的公平性和歧视性的定量度量》，DEC TR-301，马萨诸塞州利特尔顿：数字设备公司，1984年。
[JWL04] C. Jin, D. Wei, and S. Low, FAST TCP: Motivation, Architecture, Algorithms, Performance, IEEE INFOCOM, March 2004.
[JWL04]靳C.魏D.和S.低速、快速TCP：动机、体系结构、算法、性能，IEEE INFOCOM，2004年3月。
[K01] F. Kelly, Mathematical Modelling of the Internet, "Mathematics Unlimited - 2001 and Beyond" (Editors B. Engquist and W. Schmid), Springer-Verlag, Berlin, pp. 685-702, 2001.
[K01]F.Kelly，互联网的数学建模，“数学无限——2001年及以后”（编辑B.Engquist和W.Schmid），柏林斯普林格·维拉格，第685-7022001页。
[KHR02] D. Katabi, M. Handley, and C. Rohrs, Congestion Control for High Bandwidth-Delay Product Networks, ACM Sigcomm, 2002.
[KHR02]D.Katabi，M.Handley和C.Rohrs，高带宽延迟乘积网络的拥塞控制，ACM Sigcomm，2002。
[KK03] A. Kuzmanovic and E. W. Knightly, TCP-LP: A Distributed Algorithm for Low Priority Data Transfer, IEEE INFOCOM 2003, April 2003.
[KK03]A.Kuzmanovic和E.W.Knightly，TCP-LP：低优先级数据传输的分布式算法，IEEE INFOCOM 2003，2003年4月。
[KMT98] F. Kelly, A. Maulloo and D. Tan, Rate Control in Communication Networks: Shadow Prices, Proportional Fairness and Stability. Journal of the Operational Research Society 49, pp. 237-252, 1998.
[KMT98]F.Kelly，A.Malloo和D.Tan，《通信网络中的速率控制：影子价格、比例公平和稳定性》。运筹学学会杂志49，第237-252页，1998年。
[KS03] S. Kunniyur and R. Srikant, End-to-end Congestion Control Schemes: Utility Functions, Random Losses and ECN Marks, IEEE/ACM Transactions on Networking, 11(5):689-702, October 2003.
[KS03]S.Kunniyur和R.Srikant，端到端拥塞控制方案：效用函数、随机损耗和ECN标记，IEEE/ACM网络交易，11（5）：689-7022003年10月。
[LLS05] Y-T. Li, D. Leith, and R. Shorten, Experimental Evaluation of TCP Protocols for High-Speed Networks, Hamilton Institute, 2005. URL http://www.hamilton.ie/net/eval/results_HI2005.pdf.
[LLS05]Y-T.Li，D.Leith和R.Shorten，高速网络TCP协议的实验评估，汉密尔顿研究所，2005年。统一资源定位地址http://www.hamilton.ie/net/eval/results_HI2005.pdf.
[MS91] D. Mitra and J. Seery, Dynamic Adaptive Windows for High Speed Data Networks with Multiple Paths and Propagation Delays, INFOCOM '91, pp 39-48.
[MS91]D.Mitra和J.Seery，具有多路径和传播延迟的高速数据网络的动态自适应窗口，INFOCOM'91，第39-48页。
[MTZ04] L. Mamatas, V. Tsaoussidis, and C. Zhang, Approaches to Congestion Control in Packet Networks, 2004.
[MTZ04]L.Mamatas，V.Tsaoussidis和C.Zhang，分组网络中的拥塞控制方法，2004。
[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月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 2680，1999年9月。
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999.
[RFC2678]Mahdavi，J.和V.Paxson，“测量连接性的IPPM度量”，RFC 2678，1999年9月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向延迟度量”，RFC 2679，1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的往返延迟度量”，RFC 2681，1999年9月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月。
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001.
[RFC3148]Mathis，M.和M.Allman，“定义经验批量传输容量指标的框架”，RFC 3148，2001年7月。
[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月。
[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002.
[RFC3357]Koodli，R.和R.Ravikanth，“单向损失模式样本度量”，RFC 3357，2002年8月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]Demichelis，C.和P.Chimento，“IP性能度量的IP数据包延迟变化度量（IPPM）”，RFC 3393，2002年11月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Ed.，Caceres，R.，Ed.，和A.Clark，Ed.，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[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月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[RFC3782]Floyd，S.，Henderson，T.，和A.Gurtov，“TCP快速恢复算法的NewReno修改”，RFC 3782，2004年4月。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.
[RFC4737]Morton，A.，Ciavattone，L.，Ramachandran，G.，Shalunov，S.，和J.Perser，“数据包重新排序度量”，RFC 4737，2006年11月。
[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月。
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008.
[RFC5136]Chimento，P.和J.Ishac，“定义网络容量”，RFC 5136，2008年2月。
[RX05] I. Rhee and L. Xu, CUBIC: A New TCP-Friendly High-Speed TCP Variant, PFLDnet 2005.
[RX05]I.Rhee和L.Xu，CUBIC：一种新的TCP友好型高速TCP变体，PFLDnet 2005。
[SAF06] P. Sarolahti, M. Allman, and S. Floyd, Determining an Appropriate Sending Rate Over an Underutilized Network Path, Computer Networks, September 2006.
[SAF06]P.Sarolahti，M.Allman和S.Floyd，《在未充分利用的网络路径上确定适当的发送速率》，计算机网络，2006年9月。
[SLFK03] R.N. Shorten, D.J. Leith, J. Foy, and R. Kilduff, Analysis and Design of Congestion Control in Synchronised Communication Networks. Proc. 12th Yale Workshop on Adaptive & Learning Systems, May 2003.
[SLFK03]R.N.Shorten，D.J.Leith，J.Foy和R.Kilduff，同步通信网络中拥塞控制的分析和设计。过程。耶鲁大学第12届自适应与学习系统研讨会，2003年5月。
[SCWA99] S. Savage, N. Cardwell, D. Wetherall, and T. Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.
[SCWA99]S.Savage，N.Cardwell，D.Wetheral和T.Anderson，使用行为不当接收器的TCP拥塞控制，ACM计算机通信评论，1999年10月。
[TM02] V. Tsaoussidis and I. Matta, Open Issues of TCP for Mobile Computing, Journal of Wireless Communications and Mobile Computing: Special Issue on Reliable Transport Protocols for Mobile Computing, February 2002.
[TM02]V.Tsaoussidis和I.Matta，移动计算TCP的公开发行，无线通信和移动计算杂志：移动计算可靠传输协议专刊，2002年2月。
[TWL06] A. Tang, J. Wang and S. H. Low. Counter-Intuitive Throughput Behaviors in Networks Under End-to-End Control, IEEE/ACM Transactions on Networking, 14(2):355-368, April 2006.
[TWL06]A.Tang、J.Wang和S.H.Low。端到端控制下网络中的反直觉吞吐量行为，IEEE/ACM网络事务，14（2）：355-368，2006年4月。
[WCL05] D. X. Wei, P. Cao and S. H. Low, Time for a TCP Benchmark Suite?, Technical Report, Caltech CS, Stanford EAS, Caltech, 2005.
[WCL05]魏德X，曹P.和Low S.H.，《TCP基准测试套件的时间到了？》，技术报告，加州理工学院CS，斯坦福EAS，加州理工学院，2005年。
[VKD02] A. Venkataramani, R. Kokku, and M. Dahlin, TCP Nice: A Mechanism for Background Transfers, Fifth USENIX Symposium on Operating System Design and Implementation (OSDI), 2002.
[VKD02]A.Venkataramani，R.Kokku和M.Dahlin，TCP Nice：后台传输机制，第五届USENIX操作系统设计和实现研讨会（OSDI），2002年。
[XHR04] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion Control for Fast, Long Distance Networks, Infocom 2004.
[XHR04]L.Xu，K.Harfoush和I.Rhee，快速、长距离网络的二进制增量拥塞控制，Infocom 2004。
[YKL01] Y. Yang, M. Kim, and S. Lam, Transient Behaviors of TCP-friendly Congestion Control Protocols, Infocom 2001.
[YKL01]Yang，M.Kim和S.Lam，TCP友好拥塞控制协议的瞬态行为，Infocom 2001。
[ZKL04] Y. Zhang, S.-R. Kang, and D. Loguinov, Delayed Stability and Performance of Distributed Congestion Control, ACM SIGCOMM, August 2004.
[ZKL04]张胜荣，康胜瑞，D.洛吉诺夫，分布式拥塞控制的延迟稳定性和性能，ACM SIGCOMM，2004年8月。
Author's Address
作者地址
Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA
Sally Floyd ICSI互联网研究中心美国加利福尼亚州伯克利中心街1947号600室，邮编94704
EMail: floyd@icir.org
EMail: floyd@icir.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和http://www.rfc-editor.org/copyright.html，除本协议另有规定外，提交人保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.