Network Working Group M. Mathis
Request for Comments: 3148 Pittsburgh Supercomputing Center
Category: Informational M. Allman
BBN/NASA Glenn
July 2001
Network Working Group M. Mathis
Request for Comments: 3148 Pittsburgh Supercomputing Center
Category: Informational M. Allman
BBN/NASA Glenn
July 2001
A Framework for Defining Empirical Bulk Transfer Capacity Metrics
定义经验批量传输容量指标的框架
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity.
本文档定义了一个标准化多个BTC（批量传输容量）指标的框架，这些指标与允许的传输分集并行。
1 Introduction
1导言
Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g., TCP). The intuitive definition of BTC is the expected long term average data rate (bits per second) of a single ideal TCP implementation over the path in question. However, there are many congestion control algorithms (and hence transport implementations) permitted by IETF standards. This diversity in transport algorithms creates a difficulty for standardizing BTC metrics because the allowed diversity is sufficient to lead to situations where different implementations will yield non-comparable measures -- and potentially fail the formal tests for being a metric.
批量传输容量（BTC）是衡量网络通过单个拥塞感知传输连接（如TCP）传输大量数据的能力的一种指标。BTC的直观定义是所讨论路径上单个理想TCP实现的预期长期平均数据速率（比特/秒）。然而，IETF标准允许使用许多拥塞控制算法（以及传输实现）。传输算法的这种多样性给标准化BTC度量带来了困难，因为允许的多样性足以导致不同的实现产生不可比较的度量，并可能导致作为度量的正式测试失败。
Two approaches are used. First, each BTC metric must be much more tightly specified than the typical IETF protocol. Second, each BTC methodology is expected to collect some ancillary metrics which are potentially useful to support analytical models of BTC.
使用了两种方法。首先，必须比典型的IETF协议更严格地指定每个BTC指标。其次，每种BTC方法都需要收集一些辅助指标，这些指标可能有助于支持BTC的分析模型。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Although
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。虽然
[RFC2119] was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure that each BTC methodology defined contains specific pieces of information.
[RFC2119]是在考虑协议的情况下编写的，出于类似的原因，本文档中使用了关键词。它们用于确保定义的每个BTC方法都包含特定的信息。
Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g., TCP). For many applications the BTC of the underlying network dominates the overall elapsed time for the application to run and thus dominates the performance as perceived by a user. Examples of such applications include FTP, and the world wide web when delivering large images or documents. The intuitive definition of BTC is the expected long term average data rate (bits per second) of a single ideal TCP implementation over the path in question. The specific definition of the bulk transfer capacity that MUST be reported by a BTC tool is:
批量传输容量（BTC）是衡量网络通过单个拥塞感知传输连接（如TCP）传输大量数据的能力的一种指标。对于许多应用程序，底层网络的BTC控制着应用程序运行的总时间，从而控制着用户感知的性能。此类应用程序的示例包括FTP，以及在传送大型图像或文档时使用万维网。BTC的直观定义是所讨论路径上单个理想TCP实现的预期长期平均数据速率（比特/秒）。BTC工具必须报告的批量传输容量的具体定义如下：
BTC = data_sent / elapsed_time
BTC = data_sent / elapsed_time
where "data_sent" represents the unique "data" bits transfered (i.e., not including header bits or emulated header bits). Also note that the amount of data sent should only include the unique number of bits transmitted (i.e., if a particular packet is retransmitted the data it contains should be counted only once).
其中，“data_sent”表示传输的唯一“data”位（即，不包括报头位或模拟报头位）。还应注意，发送的数据量应仅包括发送的唯一位数（即，如果重新传输特定分组，则其包含的数据应仅计数一次）。
Central to the notion of bulk transport capacity is the idea that all transport protocols should have similar responses to congestion in the Internet. Indeed the only form of equity significantly deployed in the Internet today is that the vast majority of all traffic is carried by TCP implementations sharing common congestion control algorithms largely due to a shared developmental heritage.
批量传输容量概念的核心思想是，所有传输协议都应该对互联网上的拥塞做出类似的响应。事实上，目前在互联网上显著部署的唯一公平形式是，绝大多数流量都是由共享公共拥塞控制算法的TCP实现承载的，这主要是由于共享的发展遗产。
[RFC2581] specifies the standard congestion control algorithms used by TCP implementations. Even though this document is a (proposed) standard, it permits considerable latitude in implementation. This latitude is by design, to encourage ongoing evolution in congestion control algorithms.
[RFC2581]指定TCP实现使用的标准拥塞控制算法。尽管本文件是一个（建议的）标准，但它允许在实施中有相当大的自由度。这种自由度是为了鼓励拥塞控制算法的不断发展而设计的。
This legal diversity in congestion control algorithms creates a difficulty for standardizing BTC metrics because the allowed diversity is sufficient to lead to situations where different implementations will yield non-comparable measures -- and potentially fail the formal tests for being a metric.
拥塞控制算法中的这种法律多样性给标准化BTC度量带来了困难，因为允许的多样性足以导致不同的实现产生不可比较的度量，并可能导致作为度量的正式测试失败。
There is also evidence that most TCP implementations exhibit non-linear performance over some portion of their operating region. It is possible to construct simple simulation examples where incremental improvements to a path (such as raising the link data rate) results in lower overall TCP throughput (or BTC) [Mat98].
还有证据表明，大多数TCP实现在其工作区域的某些部分表现出非线性性能。可以构造简单的模拟示例，其中路径的增量改进（如提高链路数据速率）会导致总体TCP吞吐量（或BTC）降低[Mat98]。
We believe that such non-linearity reflects weakness in our current understanding of congestion control and is present to some extent in all TCP implementations and BTC metrics. Note that such non-linearity (in either TCP or a BTC metric) is potentially problematic in the market because investment in capacity might actually reduce the perceived quality of the network. Ongoing research in congestion dynamics has some hope of mitigating or modeling the these non-linearities.
我们认为，这种非线性反映了我们目前对拥塞控制理解的不足，并且在一定程度上存在于所有TCP实现和BTC度量中。请注意，这种非线性（在TCP或BTC度量中）在市场上可能存在问题，因为容量投资实际上可能会降低感知的网络质量。正在进行的拥塞动力学研究有望缓解或模拟这些非线性。
Related areas, including integrated services [RFC1633,RFC2216], differentiated services [RFC2475] and Internet traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently receiving significant attention from the research community. It is likely that we will see new experimental congestion control algorithms in the near future. In addition, Explicit Congestion Notification (ECN) [RFC2481] is being tested for Internet deployment. We do not yet know how any of these developments might affect BTC metrics, and thus the BTC framework and metrics may need to be revisited in the future.
相关领域，包括综合服务[RFC1633、RFC2216]、差异化服务[RFC2475]和互联网流量分析[MSMO97、PFTK98、Pax97b、LM97]目前都受到研究界的高度重视。在不久的将来，我们可能会看到新的实验性拥塞控制算法。此外，显式拥塞通知（ECN）[RFC2481]正在针对Internet部署进行测试。我们还不知道这些发展如何影响BTC指标，因此未来可能需要重新审视BTC框架和指标。
This document defines a framework for standardizing multiple BTC metrics that parallel the permitted transport diversity. Two approaches are used. First, each BTC metric must be much more tightly specified than the typical IETF transport protocol. Second, each BTC methodology is expected to collect some ancillary metrics which are potentially useful to support analytical models of BTC. If a BTC methodology does not collect these ancillary metrics, it should collect enough information such that these metrics can be derived (for instance a segment trace file).
本文档定义了一个标准化多个BTC指标的框架，这些指标与允许的传输分集并行。使用了两种方法。首先，必须比典型的IETF传输协议更严格地指定每个BTC指标。其次，每种BTC方法都需要收集一些辅助指标，这些指标可能有助于支持BTC的分析模型。如果BTC方法没有收集这些辅助指标，它应该收集足够的信息，以便可以导出这些指标（例如，段跟踪文件）。
As an example, the models in [PFTK98, MSMO97, OKM96a, Lak94] all predict bulk transfer performance based on path properties such as loss rate and round trip time. A BTC methodology that also provides ancillary measures of these properties is stronger because agreement with the analytical models can be used to corroborate the direct BTC measurement results.
例如，[PFTK98、MSMO97、OKM96a、Lak94]中的模型均基于路径特性（如损耗率和往返时间）预测批量传输性能。由于与分析模型的一致性可用于证实直接BTC测量结果，因此还提供这些特性辅助测量的BTC方法更为强大。
More importantly the ancillary metrics are expected to be useful for resolving disparity between different BTC methodologies. For example, a path that predominantly experiences clustered packet losses is likely to exhibit vastly different measures from BTC metrics that mimic Tahoe, Reno, NewReno, and SACK TCP algorithms [FF96]. The differences in the BTC metrics over such a path might be diagnosed by an ancillary measure of loss clustering.
更重要的是，辅助指标有望有助于解决不同BTC方法之间的差异。例如，主要经历集群数据包丢失的路径可能表现出与模拟Tahoe、Reno、NewReno和SACK TCP算法的BTC度量截然不同的度量[FF96]。这种路径上BTC度量的差异可以通过损失聚类的辅助度量进行诊断。
There are some path properties which are best measured as ancillary metrics to a transport protocol. Examples of such properties include bottleneck queue limits or the tendency to reorder packets. These are difficult or impossible to measure at low rates and unsafe to measure at rates higher than the bulk transport capacity of the path.
有一些路径属性最好作为传输协议的辅助度量来度量。此类属性的示例包括瓶颈队列限制或重新排序数据包的趋势。在低速率下很难或不可能测量，而在高于道路散装运输能力的速率下测量则不安全。
It is expected that at some point in the future there will exist an A-frame [RFC2330] which will unify all simple path metrics (e.g., segment loss rates, round trip time) and BTC ancillary metrics (e.g., queue size and packet reordering) with different versions of BTC metrics (e.g., that parallel Reno or SACK TCP).
预计在未来的某个时刻，将存在一个A帧[RFC2330]，它将把所有简单路径度量（例如，段丢失率、往返时间）和BTC辅助度量（例如，队列大小和数据包重新排序）与不同版本的BTC度量（例如，并行Reno或SACK TCP）统一起来。
2 Congestion Control Algorithms
2.拥塞控制算法
Nearly all TCP implementations in use today utilize the congestion control algorithms published in [Jac88] and further refined in [RFC2581]. In addition to using the basic notion of using an ACK clock, TCP (and therefore BTC) implements five standard congestion control algorithms: Congestion Avoidance, Retransmission timeouts, Slow-start, Fast Retransmit and Fast Recovery. All BTC implementations MUST implement slow start and congestion avoidance, as specified in [RFC2581] (with extra details also specified, as outlined below). All BTC methodologies SHOULD implement fast retransmit and fast recovery as outlined in [RFC2581]. Finally, all BTC methodologies MUST implement a retransmission timeout.
目前使用的几乎所有TCP实现都使用[Jac88]中发布的拥塞控制算法，并在[RFC2581]中进一步完善。除了使用ACK时钟的基本概念外，TCP（因此BTC）还实现了五种标准拥塞控制算法：拥塞避免、重传超时、慢启动、快速重传和快速恢复。所有BTC实施必须按照[RFC2581]中的规定实施慢启动和拥塞避免（还规定了额外细节，如下所述）。所有BTC方法应实现[RFC2581]中概述的快速重传和快速恢复。最后，所有BTC方法都必须实现重传超时。
The algorithms specified in [RFC2581] give implementers some choices in the details of the implementation. The following is a list of details about the congestion control algorithms that are either underspecified in [RFC2581] or very important to define when constructing a BTC methodology. These details MUST be specifically defined in each BTC methodology.
[RFC2581]中指定的算法为实现者在实现细节中提供了一些选择。下面列出了[RFC2581]中未详细说明或在构建BTC方法时需要定义的非常重要的拥塞控制算法的详细信息。这些细节必须在每个BTC方法中明确定义。
* [RFC2581] does not standardize a specific algorithm for increasing cwnd during congestion avoidance. Several candidate algorithms are given in [RFC2581]. The algorithm used in a particular BTC methodology MUST be defined.
* [RFC2581]未对拥塞避免期间增加cwnd的特定算法进行标准化。[RFC2581]中给出了几种候选算法。必须定义特定BTC方法中使用的算法。
* [RFC2581] does not specify which cwnd increase algorithm (slow start or congestion avoidance) should be used when cwnd equals ssthresh. This MUST be specified for each BTC methodology.
* [RFC2581]未指定当cwnd等于ssthresh时应使用哪种cwnd增加算法（慢启动或拥塞避免）。必须为每个BTC方法指定此项。
* [RFC2581] allows TCPs to use advanced loss recovery mechanism such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms [FF96,MM96a,MM96b]. If used in a BTC implementation, such an algorithm MUST be fully defined.
* [RFC2581]允许TCP使用高级损失恢复机制，如NewReno[RFC2582，FF96，Hoe96]和基于SACK的算法[FF96，MM96a，MM96b]。如果在BTC实现中使用，则必须完全定义此类算法。
* The actual segment size, or method of choosing a segment size (e.g., path MTU discovery [RFC1191]) and the number of header bytes assumed to be prepended to each segment MUST be specified. In addition, if the segment size is artificially limited to less than the path MTU this MUST be indicated.
* 必须指定实际的段大小或选择段大小的方法（例如，路径MTU发现[RFC1191]）以及假定在每个段前面的头字节数。此外，如果人为地将段大小限制为小于路径MTU，则必须指出这一点。
* TCP includes a retransmission timeout (RTO) to trigger retransmissions of segments that have not been acknowledged within an appropriate amount of time and have not been retransmitted via some more advanced loss recovery algorithm. A BTC implementation MUST include a retransmission timer. Calculating the RTO is subject to a number of details that MUST be defined for each BTC metric. In addition, a BTC metric MUST define when the clock is set and the granularity of the clock.
* TCP包括重传超时（RTO），用于触发在适当时间内未确认且未通过某种更高级的丢失恢复算法重传的段的重传。BTC实现必须包括重传计时器。RTO的计算取决于必须为每个BTC指标定义的许多细节。此外，BTC度量必须定义设置时钟的时间和时钟的粒度。
[RFC2988] specifies the behavior of the retransmission timer. However, there are several details left to the implementer which MUST be specified for each BTC metric defined.
[RFC2988]指定重传计时器的行为。然而，还有一些细节留给实现者，必须为定义的每个BTC度量指定这些细节。
Note that as new congestion control algorithms are placed on the standards track they may be incorporated into BTC metrics (e.g., the Limited Transmit algorithm [ABF00]). However, any implementation decisions provided by the relevant RFCs SHOULD be fully specified in the particular BTC metric.
注意，当新的拥塞控制算法被放置在标准轨道上时，它们可能被合并到BTC度量中（例如，有限传输算法[ABF00]）。但是，相关RFC提供的任何实施决策都应在特定BTC指标中充分规定。
3 Ancillary Metrics
3辅助指标
The following ancillary metrics can provide additional information about the network and the behavior of the implemented congestion control algorithms in response to the behavior of the network path. It is RECOMMENDED that these metrics be built into each BTC methodology. Alternatively, it is RECOMMENDED that the BTC implementation provide enough information such that the ancillary metrics can be derived via post-processing (e.g., by providing a segment trace of the connection).
以下辅助度量可以提供有关网络的附加信息，以及响应于网络路径行为而实现的拥塞控制算法的行为。建议将这些指标构建到每个BTC方法中。或者，建议BTC实现提供足够的信息，以便可以通过后处理（例如，通过提供连接的段跟踪）导出辅助度量。
The "Congestion Avoidance Capacity" (CAC) metric is the data rate (bits per second) of a fully specified implementation of the Congestion Avoidance algorithm, subject to the restriction that the Retransmission Timeout and Slow-Start algorithms are not invoked. The CAC metric is defined to have no meaning across Retransmission Timeouts or Slow-Start periods (except the single segment Slow-Start that is permitted to follow recovery, as discussed in section 2).
“拥塞避免容量”（CAC）度量是完全指定的拥塞避免算法实现的数据速率（比特/秒），受不调用重传超时和慢启动算法的限制。CAC度量被定义为在重传超时或慢启动期间没有意义（如第2节所述，允许在恢复之后进行的单段慢启动除外）。
In principle a CAC metric would be an ideal BTC metric, as it captures what should be TCP's steady state behavior. But, there is a rather substantial difficulty with using it as such. The Self-Clocking of the Congestion Avoidance algorithm can be very fragile, depending on the specific details of the Fast Retransmit, Fast Recovery or advanced recovery algorithms chosen. It has been found that timeouts and periods of slow start loss recovery are prevalent in traffic on the Internet [LK98,BPS+97] and therefore these should be captured by the BTC metric.
原则上，CAC度量是理想的BTC度量，因为它捕获了TCP的稳态行为。但是，这样使用它有相当大的困难。拥塞避免算法的自时钟可能非常脆弱，这取决于所选择的快速重传、快速恢复或高级恢复算法的具体细节。已经发现，互联网流量中普遍存在超时和缓慢启动丢失恢复期[LK98，BPS+97]，因此，BTC指标应能捕捉到这些情况。
When TCP loses Self-Clock it is re-established through a retransmission timeout and Slow-Start. These algorithms nearly always require more time than Congestion Avoidance would have taken. It is easily observed that unless the network loses an entire window of data (which would clearly require a retransmit timeout) TCP likely missed some opportunity to safely transmit data. That is, if TCP experiences a timeout after losing a partial window of data, it must have received at least one ACK that was generated after some of the partial data was delivered, but did not trigger the transmission of new data. Recent research in congestion control (e.g., FACK [MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) can be characterized as making TCP's Self-Clock more tenacious, while preserving fairness under adverse conditions. This work is motivated by how poorly current TCP implementations perform under some conditions, often due to repeated clock loss. Since this is an active research area, different TCP implementations have rather considerable differences in their ability to preserve Self-Clock.
当TCP失去自时钟时，它将通过重新传输超时和缓慢启动重新建立。这些算法几乎总是需要比避免拥塞所需的时间更多的时间。很容易观察到，除非网络丢失整个数据窗口（这显然需要重新传输超时），否则TCP可能会错过一些安全传输数据的机会。也就是说，如果TCP在丢失部分数据窗口后遇到超时，则它必须至少收到一个在部分数据交付后生成的ACK，但没有触发新数据的传输。最近在拥塞控制方面的研究（例如，FACK[MM96a]、NewReno[FF96、RFC2582]、速率减半[MSML99]）可以被描述为使TCP的自时钟更加坚韧，同时在不利条件下保持公平性。这项工作的动机是当前的TCP实现在某些条件下的性能差，通常是由于重复的时钟丢失。由于这是一个活跃的研究领域，不同的TCP实现在保持自时钟的能力上有相当大的差异。
Losing the ACK clock can have a large effect on the overall BTC, and the clock is itself fragile in ways that are dependent on the loss recovery algorithm. Therefore, the transition between timer driven and Self-Clocked operation SHOULD be instrumented.
丢失ACK时钟可能会对整个BTC产生很大影响，并且时钟本身非常脆弱，这取决于丢失恢复算法。因此，应检测定时器驱动和自时钟操作之间的转换。
If the last event before a timeout was the receipt of an ACK that did not trigger a transmission, the possibility exists that an alternate congestion control algorithm would have successfully preserved the Self-Clock. A BTC SHOULD instrument key items in the BTC state (such as the congestion window) in the hopes that this may lead to further improvements in congestion control algorithms.
如果超时之前的最后一个事件是接收到未触发传输的ACK，则存在一种可能性，即备用拥塞控制算法将成功保留自时钟。BTC应在BTC状态（如拥塞窗口）中检测关键项目，以期进一步改进拥塞控制算法。
Note that in the absence of knowledge about the future, it is not possible to design an algorithm that never misses transmission opportunities. However, there are ever more subtle ways to gauge network state, and to estimate if a given ACK is likely to be the last.
请注意，在缺乏关于未来的知识的情况下，不可能设计一种永不错过传输机会的算法。然而，还有更微妙的方法来衡量网络状态，并估计给定的ACK是否可能是最后一个ACK。
If an entire window of data (or ACKs) is lost, there will be no returning ACKs to clock out additional data. This condition can be detected if the last event before a timeout was a data transmission triggered by an ACK. The loss of an entire window of data/ACKs forces recovery to be via a Retransmission Timeout and Slow-Start.
如果整个数据窗口（或ACK）丢失，则不会返回ACK来记录其他数据。如果超时之前的最后一个事件是由ACK触发的数据传输，则可以检测到这种情况。整个数据/确认窗口的丢失迫使恢复通过重新传输超时和缓慢启动进行。
Losing an entire window of data implies an outage with a duration at least as long as a round trip time. Such an outage can not be diagnosed with low rate metrics and is unsafe to diagnose at higher rates than the BTC. Therefore all BTC metrics SHOULD instrument and report losses of an entire window of data.
丢失整个数据窗口意味着中断的持续时间至少与往返时间一样长。这种停机不能用低速率指标进行诊断，并且以高于BTC的速率进行诊断是不安全的。因此，所有BTC指标都应测量并报告整个数据窗口的损失。
Note that there are some conditions, such as when operating with a very small window, in which there is a significant probability that an entire window can be lost through individual random losses (again highlighting the importance of instrumenting cwnd).
请注意，在某些情况下，例如在使用非常小的窗口操作时，整个窗口很有可能因单个随机损失而丢失（再次强调仪表化cwnd的重要性）。
All algorithms that permit a given BTC to sustain Self-Clock when other algorithms might not, SHOULD be instrumented. Furthermore, the details of the algorithms used MUST be fully documented (as discussed in section 2).
所有允许给定BTC在其他算法可能不支持的情况下维持自时钟的算法都应该被检测。此外，所用算法的详细信息必须完整记录（如第2节所述）。
BTC metrics that can sustain Self-Clock in the presence of multiple losses within one round trip SHOULD instrument the loss distribution, such that the performance of alternate congestion control algorithms may be estimated (e.g., Reno style).
在一个往返行程中出现多个损耗时，能够维持自时钟的BTC度量应测量损耗分布，以便可以估计备用拥塞控制算法的性能（例如，雷诺式）。
All false timeouts, (where the retransmission timer expires before the ACK for some previously transmitted data arrives) SHOULD be instrumented when possible. Note that depending upon how the BTC metric implements sequence numbers, this may be difficult to detect.
如果可能，应检测所有错误超时（在某些先前传输数据的ACK到达之前，重传计时器过期）。注意，根据BTC度量如何实现序列号，这可能很难检测到。
All BTC metrics provide unique vantage points for observing certain path properties relating to closely spaced packets. As in the case of RTT duration outages, these can be impossible to diagnose at low rates (less than 1 packet per RTT) and inappropriate to test at rates above the BTC of the network path.
所有BTC指标都提供了独特的优势，用于观察与密集数据包相关的某些路径属性。与RTT持续时间中断的情况一样，在低速率（每个RTT少于1个数据包）下无法诊断这些故障，并且不适合在高于网络路径BTC的速率下进行测试。
All BTC metrics SHOULD instrument packet reordering. The frequency and distance out-of-sequence SHOULD be instrumented for all out-of-order packets. The severity of the reordering can be classified as one of three different cases, each of which SHOULD be reported.
所有BTC指标都应指示数据包重新排序。应为所有无序数据包检测无序频率和距离。重新排序的严重程度可分为三种不同情况之一，每种情况都应报告。
Segments that are only slightly out-of-order should not trigger the fast retransmit algorithm, but they may affect the window calculation. BTC metrics SHOULD document how slightly out-of-order segments affect the congestion window calculation.
顺序稍有偏差的段不应触发快速重传算法，但它们可能会影响窗口计算。BTC指标应记录稍微无序的段如何影响拥塞窗口计算。
If segments are sufficiently out-of-order, the Fast Retransmit algorithm will be invoked in advance of the delayed packet's late arrival. These events SHOULD be instrumented. Even though the the late arriving packet will complete recovery, the the window will still be reduced by half.
如果数据段完全无序，则将在延迟数据包延迟到达之前调用快速重传算法。应该检测这些事件。即使延迟到达的数据包将完成恢复，窗口仍将减少一半。
Under some rare conditions segments have been observed that are far out of order - sometimes many seconds late [Pax97b]. These SHOULD always be instrumented.
在一些罕见的情况下，观察到的片段远远无序——有时会延迟几秒钟[Pax97b]。应始终对其进行检测。
BTC implementations SHOULD instrument the maximum cwnd observed during congestion avoidance and slow start. A TCP running over the same path as the BTC metric must have sufficient sender buffer space and receiver window (and window shift [RFC1323]) to cover this cwnd in order to expect the same performance.
BTC实施应在拥塞避免和慢速启动期间测量观察到的最大cwnd。在与BTC指标相同的路径上运行的TCP必须有足够的发送方缓冲区空间和接收方窗口（以及窗口移位[RFC1323]）来覆盖此cwnd，以便获得相同的性能。
There are several other path properties that one might measure within a BTC metric. For example, with an embedded one-way delay metric it may be possible to measure how queuing delay and and (RED) drop probabilities are correlated to window size. These are open research questions.
在BTC度量中还可以度量其他几个路径属性。例如，通过嵌入单向延迟度量，可以测量排队延迟和（红色）丢弃概率与窗口大小的相关性。这些是开放的研究问题。
Unlike low rate metrics, BTC SHOULD include explicit checks that the test platform is not the bottleneck.
与低速率指标不同，BTC应包括明确的检查，以确保测试平台不是瓶颈。
Any detected dropped packets within the sending host MUST be reported. Unless the sending interface is the path bottleneck, any dropped packets probably indicates a measurement failure.
必须报告发送主机内检测到的任何丢弃的数据包。除非发送接口是路径瓶颈，否则任何丢弃的数据包都可能表示测量失败。
The maximum queue lengths within the sending host SHOULD be instrumented. Any significant queue may indicate that the sending host has insufficient burst data rate, and is smoothing the data being transmitted into the network.
应检测发送主机内的最大队列长度。任何有效队列都可能指示发送主机的突发数据速率不足，并且正在平滑传输到网络中的数据。
If TCP would require advanced TCP extensions to match BTC performance (such as RFC 1323 or RFC 2018 features), it SHOULD be reported.
如果TCP需要高级TCP扩展以匹配BTC性能（如RFC 1323或RFC 2018功能），则应报告。
To the extent possible, the BTC metric SHOULD distinguish between the properties of the forward and reverse paths.
尽可能地，BTC度量应区分正向路径和反向路径的属性。
BTC methodologies which rely on non-cooperating receivers may only be able to measure round trip path properties and may not be able to independently differentiate between the properties of the forward and reverse paths. In this case the load on the reverse path contributed by the BTC metric SHOULD be instrumented (or computed) to permit other means of gauge the proportion of the round trip path properties attributed to the the forward and reverse paths.
依赖于非合作接收机的BTC方法可能只能测量往返路径属性，并且可能无法独立区分正向和反向路径的属性。在这种情况下，应测量（或计算）由BTC指标产生的反向路径上的负载，以允许使用其他方法测量归因于正向和反向路径的往返路径属性的比例。
To the extent possible, BTC methodologies that rely on cooperating receivers SHOULD support separate ancillary metrics for the forward and reverse paths.
在可能的范围内，依赖于协作接收机的BTC方法应支持前向和反向路径的单独辅助度量。
4 Security Considerations
4安全考虑
Conducting Internet measurements raises security concerns. This memo does not specify a particular implementation of a metric, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, metrics produced within this framework, and in particular implementations of the metrics may create security issues.
进行互联网测量会引起安全问题。此备忘录未指定度量的特定实现，因此它不会直接影响Internet或Internet上运行的应用程序的安全性。然而，在此框架内生成的度量，尤其是度量的实现可能会产生安全问题。
Bulk Transport Capacity metrics, as defined in this document, naturally attempt to fill a bottleneck link. The BTC metrics based on this specification will be as "network friendly" as current well-tuned TCP connections. However, since the "connection" may not be using TCP packets, a BTC test may appear to network operators as a denial of service attack.
本文件中定义的批量运输能力指标自然会试图填补瓶颈环节。基于此规范的BTC指标将与当前经过良好调优的TCP连接一样“网络友好”。但是，由于“连接”可能不使用TCP数据包，因此BTC测试在网络运营商看来可能是拒绝服务攻击。
Administrators of the source host of a test, the destination host of a test, and the intervening network(s) may wish to establish bilateral or multi-lateral agreements regarding the timing, size, and frequency of collection of BTC metrics.
测试源主机、测试目标主机和介入网络的管理员可能希望就BTC度量的收集时间、大小和频率建立双边或多边协议。
Metrics within this framework generate packets for a sample, rather than taking samples based on user data. Thus, a BTC metric does not threaten user data confidentiality.
此框架中的度量为样本生成数据包，而不是基于用户数据采集样本。因此，BTC度量不会威胁用户数据的机密性。
It may be possible to identify that a certain packet or stream of packets are part of a BTC metric. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g., increasing or decreasing delay, introducing or heroically preventing loss) that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of a BTC metric. These additional packets are likely to perturb the results of the sample measurement.
可以识别特定分组或分组流是BTC度量的一部分。利用在目的地和/或介入网络处的该知识，可以改变分组的处理（例如，增加或减少延迟，引入或英勇地防止丢失），这可能扭曲所测量的性能。还可以生成似乎是BTC度量的一部分的附加分组。这些额外的数据包可能会干扰样本测量的结果。
To discourage the kind of interference mentioned above, packet interference checks, such as cryptographic hash, may be used.
为了阻止上述类型的干扰，可以使用分组干扰检查，例如加密散列。
5 IANA Considerations
5 IANA考虑因素
Since this metric framework does not define a specific protocol, nor does it define any well-known values, there are no IANA considerations for this document. However, a bulk transport capacity metric within this framework, and in particular protocols that implement a metric may have IANA considerations that need to be addressed.
由于此度量框架未定义特定协议，也未定义任何已知值，因此本文档不考虑IANA。然而，该框架内的批量传输容量指标，尤其是实现该指标的协议，可能需要考虑IANA因素。
6 Acknowledgments
6致谢
Thanks to Wil Leland, Jeff Semke, Matt Zekauskas and the IPPM working group for numerous clarifications.
感谢Wil Leland、Jeff Semke、Matt Zekauskas和IPPM工作组的多次澄清。
Matt Mathis's work was supported by the National Science Foundation under Grant Numbers 9415552 and 9870758.
Matt Mathis的工作得到了国家科学基金资助9415552和9870758号的支持。
7 References
7参考文献
[BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server: Analysis and Improvements. Technical Report UCB/CSD-97-966, August 1997. Available from http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps. (Also in Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998.)
[BPS+97]哈里·巴拉克里希南、文卡塔·帕德马纳班、斯里尼瓦桑·塞尚、马克·斯特姆和兰迪·卡茨。繁忙Web服务器的TCP行为：分析和改进。技术报告UCB/CSD-97-966，1997年8月。可从http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps。（也在PRE.IEEE信息公开，旧金山，CA，1998年3月）。
[FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of Tahoe, Reno and SACK TCP". Computer Communication Review, July 1996. ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
[FF96]法尔，K.，弗洛伊德，S。。“基于模拟的Tahoe、Reno和SACK TCP比较”。《计算机通信评论》，1996年7月。ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
[Flo95] Floyd, S., "TCP and successive fast retransmits", March 1995, Obtain via ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[Flo95]Floyd，S.，“TCP和连续快速重传”，1995年3月，通过获取ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[Hoe96] Hoe, J., "Improving the start-up behavior of a congestion control scheme for TCP, Proceedings of ACM SIGCOMM '96, August 1996.
[Hoe96]Hoe，J.，“改进TCP拥塞控制方案的启动行为”，ACM SIGCOMM'96会议录，1996年8月。
[Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control and avoidance schemes". Master's thesis, Massachusetts Institute of Technology, June 1995.
[Hoe95]Hoe，J.，“TCP拥塞控制和避免方案的启动动力学”。硕士论文，麻省理工学院，1995年6月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of SIGCOMM '88, Stanford, CA., August 1988.
[Jac88]Jacobson，V.，“拥塞避免和控制”，1988年8月于加利福尼亚州斯坦福市举行的SIGCOMM'88会议记录。
[Lak94] V. T. Lakshman and U. Madhow. The Performance of TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss. IFIP Transactions C-26, High Performance Networking, pages 135--150, 1994.
[Lak94]V.T.拉克什曼和U.马道。TCP/IP在具有高带宽延迟乘积和随机丢失的网络中的性能。IFIP交易C-26，高性能网络，第135-150页，1994年。
[LK98] Lin, D. and Kung, H.T., "TCP Fast Recovery Strategies: Analysis and Improvements", Proceedings of InfoCom, March 1998.
[LK98]Lin，D.和Kung，H.T.，“TCP快速恢复策略：分析和改进”，InfoCom学报，1998年3月。
[LM97] T.V.Lakshman and U.Madhow. "The Performance of TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss". IEEE/ACM Transactions on Networking, Vol. 5, No. 3, June 1997, pp.336-350.
[LM97]T.V.Lakshman和U.Madhow。“具有高带宽延迟乘积和随机损耗的网络的TCP/IP性能”。IEEE/ACM网络交易，第5卷，第3期，1997年6月，第336-350页。
[Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP Performance Metrics Working Group report in Proceedings of the Forty Third Internet Engineering Task Force, Orlando, FL, December 1988. Available from http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-122.html and http://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf.
[Mat98]Mathis，M.，“经验批量传输容量”，IP性能度量工作组报告，第四十三届互联网工程特别工作组会议记录，佛罗里达州奥兰多，1988年12月。可从http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-122.html 和http://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf.
[MM96a] Mathis, M. and Mahdavi, J. "Forward acknowledgment: Refining TCP congestion control", Proceedings of ACM SIGCOMM '96, Stanford, CA., August 1996.
[MM96a]Mathis，M.和Mahdavi，J.“前向确认：改进TCP拥塞控制”，ACM SIGCOMM'96会议记录，加利福尼亚州斯坦福，1996年8月。
[MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding Parameters". Available from http://www.psc.edu/networking/papers/FACKnotes/current.
[MM96b]M.Mathis，J.Mahdavi，“带边界参数的TCP速率减半”。可从http://www.psc.edu/networking/papers/FACKnotes/current.
[MSML99] Mathis, M., Semke, J., Mahdavi, J., Lahey, K., "The Rate-Halving Algorithm for TCP Congestion Control", June 1999, Work in Progress.
[MSML99]Mathis，M.，Semke，J.，Mahdavi，J.，Lahey，K.，“TCP拥塞控制的速率减半算法”，1999年6月，正在进行中。
[MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communications Review, 27(3), July 1997.
[MSMO97]Mathis，M.，Semke，J.，Mahdavi，J.，Ott，T.，“TCP拥塞避免算法的宏观行为”，计算机通信评论，27（3），1997年7月。
[OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary Behavior of Ideal TCP Congestion Avoidance", In progress, August 1996. Obtain via pub/tjo/TCPwindow.ps using anonymous ftp to ftp.bellcore.com
[OKM96a]，Ott，T.，Kemperman，J.，Mathis，M.，“理想TCP拥塞避免的平稳行为”，正在进行中，1996年8月。使用匿名ftp通过pub/tjo/TCPwindow.ps获取ftp.bellcore.com
[OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size Behavior in TCP/IP with Constant Loss Probability", DIMACS Special Year on Networks, Workshop on Performance of Real-Time Applications on the Internet, Nov 1996.
[OKM96b]，Ott，T.，Kemperman，J.，Mathis，M.，“具有恒定丢失概率的TCP/IP中的窗口大小行为”，DIMACS网络特别年，互联网实时应用程序性能研讨会，1996年11月。
[Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP Implementations", Proceedings of ACM SIGCOMM '97, August 1997.
[Pax97a]Paxson，V.，“TCP实现的自动数据包跟踪分析”，ACM SIGCOMM'97会议录，1997年8月。
[Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics," Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997.
[Pax97b]Paxson，V.，“端到端互联网数据包动力学”，1997年9月于法国戛纳举行的SIGCOMM'97会议录。
[PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., "TCP Throughput: A Simple Model and its Empirical Validation", Proceedings of ACM SIGCOMM '98, August 1998.
[PFTK98]Padhye，J.，Firoiu。V.，Towsley，D.和Kurose，J.，“TCP吞吐量：一个简单的模型及其经验验证”，《ACM SIGCOMM'981998年学报》，1998年8月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. Obtain via: http://www.rfc-
editor.org/rfc/rfc793.txt
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. Obtain via: http://www.rfc-
editor.org/rfc/rfc793.txt
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990. Obtain via: http://www.rfc-
editor.org/rfc/rfc1191.txt
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990. Obtain via: http://www.rfc-
editor.org/rfc/rfc1191.txt
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance", May 1992. Obtain via:
http://www.rfc-editor.org/rfc/rfc1323.txt
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance", May 1992. Obtain via:
http://www.rfc-editor.org/rfc/rfc1323.txt
[RFC1633] Braden R., Clark D. and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633,
June 1994. Obtain via: http://www.rfc-
editor.org/rfc/rfc1633.txt
[RFC1633] Braden R., Clark D. and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633,
June 1994. Obtain via: http://www.rfc-
editor.org/rfc/rfc1633.txt
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997. Obtain via: http://www.rfc-
editor.org/rfc/rfc2001.txt
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997. Obtain via: http://www.rfc-
editor.org/rfc/rfc2001.txt
[RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP
Selective Acknowledgment Options", RFC 2018, October
1996. Obtain via: http://www.rfc-
editor.org/rfc/rfc2018.txt
[RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP
Selective Acknowledgment Options", RFC 2018, October
1996. Obtain via: http://www.rfc-
editor.org/rfc/rfc2018.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt
[RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", RFC 2216, September 1997.
Obtain via: http://www.rfc-editor.org/rfc/rfc2216.txt
[RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", RFC 2216, September 1997.
Obtain via: http://www.rfc-editor.org/rfc/rfc2216.txt
[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, April
1998. Obtain via: http://www.rfc-
editor.org/rfc/rfc2330.txt
[RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, April
1998. Obtain via: http://www.rfc-
editor.org/rfc/rfc2330.txt
[RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z. and
W. Weiss, "An Architecture for Differentiated Services",
RFC 2475, December 1998. Obtain via: http://www.rfc-
editor.org/rfc/rfc2475.txt
[RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z. and
W. Weiss, "An Architecture for Differentiated Services",
RFC 2475, December 1998. Obtain via: http://www.rfc-
editor.org/rfc/rfc2475.txt
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add
Explicit Congestion Notification (ECN) to IP", RFC 2481,
January 1999. Obtain via: http://www.rfc-
editor.org/rfc/rfc2481.txt
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add
Explicit Congestion Notification (ECN) to IP", RFC 2481,
January 1999. Obtain via: http://www.rfc-
editor.org/rfc/rfc2481.txt
[RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999. Obtain via: http://www.rfc-editor.org/rfc/rfc2525.txt
[RFC2525]Paxson，V.，Allman，M.，Dawson，S.，Fenner，W.，Griner，J.，Skys，I.，Lahey，K.，Semke，J.和B.Volz，“已知的TCP实施问题”，RFC 25251999年3月。通过以下途径获得：http://www.rfc-editor.org/rfc/rfc2525.txt
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Obtain via:
http://www.rfc-editor.org/rfc/rfc2581.txt
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Obtain via:
http://www.rfc-editor.org/rfc/rfc2581.txt
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
Obtain via: http://www.rfc-editor.org/rfc/rfc2582.txt
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
Obtain via: http://www.rfc-editor.org/rfc/rfc2582.txt
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000. Obtain
via: http://www.rfc-editor.org/rfc/rfc2988.txt
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000. Obtain
via: http://www.rfc-editor.org/rfc/rfc2988.txt
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001. Obtain via: http://www.rfc-
editor.org/rfc/rfc3042.txt
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001. Obtain via: http://www.rfc-
editor.org/rfc/rfc3042.txt
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94]Stevens，W.“TCP/IP图解，第1卷：协议”，Addison-Wesley，1994年。
[WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The Implementation", Addison-Wesley, 1995.
[WS95]Wright，G.，Stevens，W.，“TCP/IP图解第二卷：实现”，Addison-Wesley，1995年。
Author's Addresses
作者地址
Matt Mathis Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh PA 15213
宾夕法尼亚州匹兹堡第五大道4400号马特·马蒂斯匹兹堡超级计算中心15213
EMail: mathis@psc.edu
http://www.psc.edu/~mathis
EMail: mathis@psc.edu
http://www.psc.edu/~mathis
Mark Allman BBN Technologies/NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
马克·奥尔曼BBN技术公司/美国宇航局格伦研究中心刘易斯菲尔德21000布鲁克公园路，俄亥俄州克利夫兰市54-2号，邮编：44135
Phone: 216-433-6586
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Phone: 216-433-6586
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。