Network Working Group P. Chimento
Request for Comments: 5136 JHU Applied Physics Lab
Category: Informational J. Ishac
NASA Glenn Research Center
February 2008
Network Working Group P. Chimento
Request for Comments: 5136 JHU Applied Physics Lab
Category: Informational J. Ishac
NASA Glenn Research Center
February 2008
Defining Network Capacity
定义网络容量
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques.
测量能力听起来很简单，但实际上可能相当复杂。此外，由于该主题缺乏统一的术语，因此越来越难以正确构建、测试和使用围绕这些结构构建的技术和工具。本文档提供了与IP网络中源和目标之间的IP流量相关的术语“容量”和“可用容量”的定义。通过这样做，我们希望为讨论和分析当前和未来的各种评估技术提供一个共同的框架。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Links and Paths . . . . . . . . . . . . . . . . . . . . . 4
2.2. Definition: Nominal Physical Link Capacity . . . . . . . . 4
2.3. Capacity at the IP Layer . . . . . . . . . . . . . . . . . 5
2.3.1. Definition: IP-layer Bits . . . . . . . . . . . . . . 5
2.3.1.1. Standard or Correctly Formed Packets . . . . . . . 5
2.3.1.2. Type P Packets . . . . . . . . . . . . . . . . . . 6
2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7
2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7
2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7
2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8
2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8
2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Time and Sampling . . . . . . . . . . . . . . . . . . . . 9
3.2. Hardware Duplicates . . . . . . . . . . . . . . . . . . . 9
3.3. Other Potential Factors . . . . . . . . . . . . . . . . . 9
3.4. Common Terminology in Literature . . . . . . . . . . . . . 10
3.5. Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Links and Paths . . . . . . . . . . . . . . . . . . . . . 4
2.2. Definition: Nominal Physical Link Capacity . . . . . . . . 4
2.3. Capacity at the IP Layer . . . . . . . . . . . . . . . . . 5
2.3.1. Definition: IP-layer Bits . . . . . . . . . . . . . . 5
2.3.1.1. Standard or Correctly Formed Packets . . . . . . . 5
2.3.1.2. Type P Packets . . . . . . . . . . . . . . . . . . 6
2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7
2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7
2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7
2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8
2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8
2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Time and Sampling . . . . . . . . . . . . . . . . . . . . 9
3.2. Hardware Duplicates . . . . . . . . . . . . . . . . . . . 9
3.3. Other Potential Factors . . . . . . . . . . . . . . . . . 9
3.4. Common Terminology in Literature . . . . . . . . . . . . . 10
3.5. Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Measuring the capacity of a link or network path is a task that sounds simple, but in reality can be quite complex. Any physical medium requires that information be encoded and, depending on the medium, there are various schemes to convert information into a sequence of signals that are transmitted physically from one location to another.
测量链路或网络路径的容量听起来很简单，但实际上可能相当复杂。任何物理介质都要求对信息进行编码，并且根据介质的不同，存在各种方案将信息转换为从一个位置物理传输到另一个位置的信号序列。
While on some media, the maximum frequency of these signals can be thought of as "capacity", on other media, the signal transmission frequency and the information capacity of the medium (channel) may be quite different. For example, a satellite channel may have a carrier frequency of a few gigahertz, but an information-carrying capacity of only a few hundred kilobits per second. Often similar or identical terms are used to refer to these different applications of capacity, adding to the ambiguity and confusion, and the lack of a unified nomenclature makes it difficult to properly build, test, and use various techniques and tools.
而在某些媒体上，这些信号的最大频率可以被认为是“容量”，而在其他媒体上，信号传输频率和媒体（信道）的信息容量可能有很大的不同。例如，一个卫星信道的载波频率可能为几千赫兹，但信息承载能力仅为每秒几百千比特。通常使用相似或相同的术语来指代这些不同的容量应用，增加了歧义和混乱，并且缺乏统一的术语使得很难正确构建、测试和使用各种技术和工具。
We are interested in information-carrying capacity, but even this is not straightforward. Each of the layers, depending on the medium, adds overhead to the task of carrying information. The wired Ethernet uses Manchester coding or 4/5 coding, which cuts down considerably on the "theoretical" capacity. Similarly, RF (radio frequency) communications will often add redundancy to the coding scheme to implement forward error correction because the physical medium (air) is lossy. This can further decrease the information capacity.
我们对信息承载能力感兴趣，但即便如此，这也不简单。根据介质的不同，每一层都会增加承载信息任务的开销。有线以太网使用曼彻斯特编码或4/5编码，这大大降低了“理论”容量。类似地，由于物理介质（空气）有损，RF（射频）通信通常会向编码方案添加冗余以实现前向纠错。这会进一步降低信息容量。
In addition to coding schemes, usually the physical layer and the link layer add framing bits for multiplexing and control purposes. For example, on SONET there is physical-layer framing and typically also some layer-2 framing such as High-Level Data Link Control (HDLC), PPP, or ATM.
除了编码方案外，通常物理层和链路层添加帧位用于多路复用和控制目的。例如，在SONET上有物理层帧，通常还有一些第二层帧，如高级数据链路控制（HDLC）、PPP或ATM。
Aside from questions of coding efficiency, there are issues of how access to the channel is controlled, which also may affect the capacity. For example, a multiple-access medium with collision detection, avoidance, and recovery mechanisms has a varying capacity from the point of view of the users. This varying capacity depends upon the total number of users contending for the medium, how busy the users are, and bounds resulting from the mechanisms themselves. RF channels may also vary in capacity, depending on range, environmental conditions, mobility, shadowing, etc.
除了编码效率的问题外，还有如何控制信道访问的问题，这也可能影响容量。例如，从用户的角度来看，具有冲突检测、避免和恢复机制的多址介质具有不同的容量。这种不同的容量取决于争夺介质的用户总数、用户的繁忙程度以及机制本身产生的边界。射频信道的容量也可能有所不同，这取决于范围、环境条件、移动性、阴影等。
The important points to derive from this discussion are these: First, capacity is only meaningful when defined relative to a given protocol layer in the network. It is meaningless to speak of "link" capacity without qualifying exactly what is meant. Second, capacity is not necessarily fixed, and consequently, a single measure of capacity at any layer may in fact provide a skewed picture (either optimistic or pessimistic) of what is actually available.
从讨论中得出的要点如下：首先，容量只有在相对于网络中给定的协议层定义时才有意义。如果不确切说明“链路”容量的含义，那么谈论“链路”容量是毫无意义的。第二，容量不一定是固定的，因此，任何一层的容量的单一度量实际上可能会提供实际可用容量的扭曲图片（乐观或悲观）。
In this section, we specify definitions for capacity. We begin by first defining "link" and "path" clearly, and then we define a baseline capacity that is simply tied to the physical properties of the link.
在本节中，我们将指定容量的定义。我们首先明确定义“链路”和“路径”，然后定义一个简单地与链路物理属性相关的基线容量。
To define capacity, we need to broaden the notions of link and path found in the IP Performance Metrics (IPPM) framework document [RFC2330] to include network devices that can impact IP capacity without being IP aware. For example, consider an Ethernet switch that can operate ports at different speeds.
为了定义容量，我们需要扩展IP性能度量（IPPM）框架文档[RFC2330]中的链路和路径概念，以包括在不了解IP的情况下影响IP容量的网络设备。例如，考虑一个可以以不同速度操作端口的以太网交换机。
We define nodes as hosts, routers, Ethernet switches, or any other device where the input and output links can have different characteristics. A link is a connection between two of these network devices or nodes. We then define a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and destination D reside at N1 and Nn+1, respectively. Furthermore, we define a link L as a special case where the path length is one.
我们将节点定义为主机、路由器、以太网交换机或输入和输出链路具有不同特征的任何其他设备。链路是两个网络设备或节点之间的连接。然后，我们将长度为n的路径P定义为连接一系列节点（N1，N2，…，Nn+1）的一系列链路（L1，L2，…，Ln）。源S和目的地D分别位于N1和Nn+1处。此外，我们将链路L定义为路径长度为1的特殊情况。
Nominal Physical Link Capacity, NomCap(L), is the theoretical maximum amount of data that the link L can support. For example, an OC-3 link would be capable of 155.520 Mbit/s. We stress that this is a measurement at the physical layer and not the network IP layer, which we will define separately. While NomCap(L) is typically constant over time, there are links whose characteristics may allow otherwise, such as the dynamic activation of additional transponders for a satellite link.
标称物理链路容量NomCap（L）是链路L能够支持的理论最大数据量。例如，OC-3链路将能够达到155.520 Mbit/s。我们强调，这是在物理层而不是网络IP层进行的测量，我们将单独定义网络IP层。虽然NomCap（L）通常随时间保持恒定，但也有一些链路的特性可能允许其他情况，例如卫星链路的附加转发器的动态激活。
The nominal physical link capacity is provided as a means to help distinguish between the commonly used link-layer capacities and the remaining definitions for IP-layer capacity. As a result, the value of NomCap(L) does not influence the other definitions presented in this document. Instead, it provides an upper bound on those values.
提供标称物理链路容量是为了帮助区分常用链路层容量和IP层容量的其余定义。因此，NomCap（L）的值不影响本文件中给出的其他定义。相反，它提供了这些值的上限。
There are many factors that can reduce the IP information carrying capacity of the link, some of which have already been discussed in the introduction. However, the goal of this document is not to become an exhaustive list of such factors. Rather, we outline some of the major examples in the following section, thus providing food for thought to those implementing the algorithms or tools that attempt to measure capacity accurately.
有许多因素会降低链路的IP信息承载能力，其中一些因素已在导言中讨论过。然而，本文件的目的并不是详尽列出这些因素。相反，我们将在下一节中概述一些主要示例，从而为那些实现算法或工具以准确测量容量的人提供思路。
The remaining definitions are all given in terms of "IP-layer bits" in order to distinguish these definitions from the nominal physical capacity of the link.
其余定义均以“IP层位”的形式给出，以便将这些定义与链路的标称物理容量区分开来。
IP-layer bits are defined as eight (8) times the number of octets in all IP packets received, from the first octet of the IP header to the last octet of the IP packet payload, inclusive.
IP层位定义为从IP报头的第一个八位字节到IP数据包有效载荷的最后一个八位字节（包括）接收的所有IP数据包中八位字节数的八（8）倍。
IP-layer bits are recorded at the destination D beginning at time T and ending at a time T+I. Since the definitions are based on averages, the two time parameters, T and I, must accompany any report or estimate of the following values in order for them to remain meaningful. It is not required that the interval boundary points fall between packet arrivals at D. However, boundaries that fall within a packet will invalidate the packets on which they fall. Specifically, the data from the partial packet that is contained within the interval will not be counted. This may artificially bias some of the values, depending on the length of the interval and the amount of data received during that interval. We elaborate on what constitutes correctly received data in the next section.
IP层位记录在目的地D，从时间T开始，到时间T+I结束。由于定义基于平均值，因此两个时间参数T和I必须随以下值的任何报告或估计一起提供，以便它们保持有意义。不要求间隔边界点落在数据包到达D点之间。但是，落在数据包内的边界将使落在其上的数据包无效。具体地说，来自包含在间隔内的部分分组的数据将不被计数。这可能会根据间隔的长度和在该间隔期间接收的数据量，人为地偏移一些值。我们将在下一节详细说明什么构成正确接收的数据。
The definitions in this document specify that IP packets must be received correctly. The IPPM framework recommends a set of criteria for such standard-formed packets in Section 15 of [RFC2330]. However, it is inadequate for use with this document. Thus, we outline our own criteria below while pointing out any variations or similarities to [RFC2330].
本文档中的定义规定必须正确接收IP数据包。IPPM框架在[RFC2330]第15节中为此类标准形成的数据包推荐了一套标准。但是，它不适合与本文件一起使用。因此，我们在下面概述了我们自己的标准，同时指出了[RFC2330]的任何变化或相似之处。
First, data that is in error at layers below IP and cannot be properly passed to the IP layer must not be counted. For example, wireless media often have a considerably larger error rate than wired media, resulting in a reduction in IP link capacity. In accordance with the IPPM framework, packets that fail validation of the IP
首先，IP以下层出错且无法正确传递到IP层的数据不得计算在内。例如，无线媒体的错误率通常比有线媒体大得多，从而导致IP链路容量的降低。根据IPPM框架，IP验证失败的数据包
header must be discarded. Specifically, the requirements in [RFC1812], Section 5.2.2, on IP header validation must be checked, which includes a valid length, checksum, and version field.
必须丢弃标题。具体而言，必须检查[RFC1812]第5.2.2节中关于IP头验证的要求，其中包括有效长度、校验和和版本字段。
The IPPM framework specifies further restrictions, requiring that any transport header be checked for correctness and that any packets with IP options be ignored. However, the definitions in this document are concerned with the traversal of IP-layer bits. As a result, data from the higher layers is not required to be valid or understood as that data is simply regarded as part of the IP packet. The same holds true for IP options. Valid IP fragments must also be counted as they expend the resources of a link even though assembly of the full packet may not be possible. The IPPM framework differs in this area, discarding IP fragments.
IPPM框架规定了进一步的限制，要求检查任何传输头的正确性，并忽略任何具有IP选项的数据包。然而，本文档中的定义涉及IP层位的遍历。结果，来自更高层的数据不需要有效或被理解，因为该数据仅仅被视为IP分组的一部分。IP选项也是如此。即使无法组装完整的数据包，也必须计算有效的IP片段，因为它们消耗了链路的资源。IPPM框架在这方面有所不同，丢弃了IP片段。
For a discussion of duplicates, please see Section 3.2.
有关副本的讨论，请参见第3.2节。
In summary, any IP packet that can be properly processed must be included in these calculations.
总之，任何可以正确处理的IP数据包都必须包含在这些计算中。
The definitions in this document refer to "Type P" packets to designate a particular type of flow or sets of flows. As defined in RFC 2330, Section 13, "Type P" is a placeholder for what may be an explicit specification of the packet flows referenced by the metric, or it may be a very loose specification encompassing aggregates. We use the "Type P" designation in these definitions in order to emphasize two things: First, that the value of the capacity measurement depends on the types of flows referenced in the definition. This is because networks may treat packets differently (in terms of queuing and scheduling) based on their markings and classification. Networks may also arbitrarily decide to flow-balance based on the packet type or flow type and thereby affect capacity measurements. Second, the measurement of capacity depends not only on the type of the reference packets, but also on the types of the packets in the "population" with which the flows of interest share the links in the path.
本文档中的定义参考“P型”数据包，以指定特定类型的流或流集。如RFC 2330第13节所定义，“类型P”是一个占位符，可以是该度量引用的分组流的显式规范，也可以是包含聚合的非常松散的规范。我们在这些定义中使用“P型”名称是为了强调两件事：第一，容量测量值取决于定义中引用的流量类型。这是因为网络可能根据其标记和分类对数据包进行不同的处理（在排队和调度方面）。网络还可以根据分组类型或流类型任意决定流平衡，从而影响容量测量。其次，容量的测量不仅取决于参考分组的类型，而且还取决于感兴趣的流与之共享路径中链路的“总体”中分组的类型。
All of this indicates two different approaches to measuring: One is to measure capacity using a broad spectrum of packet types, suggesting that "Type P" should be set as generic as possible. The second is to focus narrowly on the types of flows of particular interest, which suggests that "Type P" should be very specific and narrowly defined. The first approach is likely to be of interest to providers, the second to application users.
所有这些都表明了两种不同的测量方法：一种是使用广泛的数据包类型来测量容量，这表明“类型P”应尽可能设置为通用。第二种是狭义地关注特定利益流的类型，这意味着“P型”应该非常具体，定义也应该很狭义。第一种方法可能是提供商感兴趣的，第二种方法是应用程序用户感兴趣的。
As a practical matter, it should be noted that some providers may treat packets with certain characteristics differently than other packets. For example, access control lists, routing policies, and other mechanisms may be used to filter ICMP packets or forward packets with certain IP options through different routes. If a capacity-measurement tool uses these special packets and they are included in the "Type P" designation, the tool may not be measuring the path that it was intended to measure. Tool authors, as well as users, may wish to check this point with their service providers.
作为一个实际问题，应当注意，一些提供者可能会以不同于其他分组的方式对待具有某些特征的分组。例如，访问控制列表、路由策略和其他机制可用于过滤ICMP分组或通过不同路由转发具有特定IP选项的分组。如果容量测量工具使用这些特殊数据包，并且这些数据包包含在“P型”名称中，则该工具可能无法测量其预期测量的路径。工具作者和用户可能希望与其服务提供商核实这一点。
We define the IP-layer link capacity, C(L,T,I), to be the maximum number of IP-layer bits that can be transmitted from the source S and correctly received by the destination D over the link L during the interval [T, T+I], divided by I.
我们将IP层链路容量C（L，T，I）定义为在间隔[T，T+I]期间可从源S传输并由目的地D通过链路L正确接收的最大IP层比特数除以I。
As mentioned earlier, this definition is affected by many factors that may change over time. For example, a device's ability to process and forward IP packets for a particular link may have varying effect on capacity, depending on the amount or type of traffic being processed.
如前所述，这一定义受到许多可能随时间变化的因素的影响。例如，设备处理和转发特定链路的IP分组的能力可能对容量有不同的影响，这取决于正在处理的流量的数量或类型。
Using our definition for IP-layer link capacity, we can then extend this notion to an entire path, such that the IP-layer path capacity simply becomes that of the link with the smallest capacity along that path.
使用我们对IP层链路容量的定义，我们可以将这个概念扩展到整个路径，这样IP层路径容量就变成了沿着该路径具有最小容量的链路的容量。
C(P,T,I) = min {1..n} {C(Ln,T,I)}
C(P,T,I) = min {1..n} {C(Ln,T,I)}
The previous definitions specify the number of IP-layer bits that can be transmitted across a link or path should the resource be free of any congestion. It represents the full capacity available for traffic between the source and destination. Determining how much capacity is available for use on a congested link is potentially much more useful. However, in order to define the available capacity, we must first specify how much is being used.
前面的定义指定了如果资源没有任何拥塞，可以通过链路或路径传输的IP层比特数。它表示源和目标之间的可用流量的全部容量。确定拥挤链路上可用的容量可能更有用。但是，为了定义可用容量，我们必须首先指定正在使用的容量。
The average usage of a link L, Used(L,T,I), is the actual number of IP-layer bits from any source, correctly received over link L during the interval [T, T+I], divided by I.
链路L的平均使用率（L，T，I）是在间隔[T，T+I]期间通过链路L正确接收的来自任何源的IP层比特的实际数目除以I。
An important distinction between usage and capacity is that Used(L,T,I) is not the maximum number, but rather, the actual number of IP bits sent that are correctly received. The information transmitted across the link can be generated by any source, including those sources that may not be directly attached to either side of the link. In addition, each information flow from these sources may share any number (from one to n) of links in the overall path between S and D.
使用率和容量之间的一个重要区别是，使用的（L、T、I）不是最大数量，而是正确接收发送的IP位的实际数量。通过链路传输的信息可以由任何源生成，包括那些可能不直接连接到链路任一侧的源。此外，来自这些源的每个信息流可以在S和D之间的总路径中共享任意数量（从1到n）的链路。
We express usage as a fraction of the overall IP-layer link capacity.
我们将使用率表示为整个IP层链路容量的一部分。
Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) )
Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) )
Thus, the utilization now represents the fraction of the capacity that is being used and is a value between zero (meaning nothing is used) and one (meaning the link is fully saturated). Multiplying the utilization by 100 yields the percent utilization of the link. By using the above, we can now define the capacity available over the link as well as the path between S and D. Note that this is essentially the definition in [PDM].
因此，利用率现在表示正在使用的容量的分数，是介于0（表示未使用任何内容）和1（表示链路完全饱和）之间的值。将利用率乘以100得到链路的利用率百分比。通过使用上述内容，我们现在可以定义链路上的可用容量以及S和D之间的路径。请注意，这基本上是[PDM]中的定义。
We can now determine the amount of available capacity on a congested link by multiplying the IP-layer link capacity with the complement of the IP-layer link utilization. Thus, the IP-layer available link capacity becomes:
现在，我们可以通过将IP层链路容量乘以IP层链路利用率的补码来确定拥塞链路上的可用容量。因此，IP层可用链路容量变为：
AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )
AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )
Using our definition for IP-layer available link capacity, we can then extend this notion to an entire path, such that the IP-layer available path capacity simply becomes that of the link with the smallest available capacity along that path.
使用我们对IP层可用链路容量的定义，我们可以将这个概念扩展到整个路径，这样IP层可用路径容量就变成了该路径上可用容量最小的链路的容量。
AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)}
AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)}
Since measurements of available capacity are more volatile than that of link capacity, we stress the importance that both the time and interval be specified as their values have a great deal of influence on the results. In addition, a sequence of measurements may be beneficial in offsetting the volatility when attempting to characterize available capacity.
由于可用容量的测量值比链路容量的测量值更不稳定，因此我们强调必须指定时间和间隔，因为它们的值对结果有很大的影响。此外，当试图描述可用容量时，一系列测量可能有助于抵消波动性。
We must emphasize the importance of time in the basic definitions of these quantities. We know that traffic on the Internet is highly variable across all time scales. This argues that the time and length of measurements are critical variables in reporting available capacity measurements and must be reported when using these definitions.
在这些量的基本定义中，我们必须强调时间的重要性。我们知道，互联网上的流量在所有时间尺度上都是高度可变的。这表明，测量的时间和长度是报告可用容量测量的关键变量，在使用这些定义时必须报告。
The closer to "instantaneous" a metric is, the more important it is to have a plan for sampling the metric over a time period that is sufficiently large. By doing so, we allow valid statistical inferences to be made from the measurements. An obvious pitfall here is sampling in a way that causes bias. For example, a situation where the sampling frequency is a multiple of the frequency of an underlying condition.
指标越接近“瞬时”，就越重要的是制定在足够大的时间段内对指标进行采样的计划。通过这样做，我们可以从测量中做出有效的统计推断。这里一个明显的陷阱是取样方式会导致偏差。例如，采样频率是基础条件频率的倍数的情况。
We briefly consider the effects of paths where hardware duplication of packets may occur. In such an environment, a node in the network path may duplicate packets, and the destination may receive multiple, identical copies of these packets. Both the original packet and the duplicates can be properly received and appear to be originating from the sender. Thus, in the most generic form, duplicate IP packets are counted in these definitions. However, hardware duplication can affect these definitions depending on the use of "Type P" to add additional restrictions on packet reception. For instance, a restriction only to count uniquely-sent packets may be more useful to users concerned with capacity for meaningful data. In contrast, the more general, unrestricted metric may be suitable for a user who is concerned with raw capacity. Thus, it is up to the user to properly scope and interpret results in situations where hardware duplicates may be prevalent.
我们简要地考虑路径的影响，其中可能发生硬件重复数据包。在这样的环境中，网络路径中的节点可以复制分组，并且目的地可以接收这些分组的多个相同副本。原始数据包和副本都可以被正确接收，并且看起来是来自发送方的。因此，在最通用的形式中，重复的IP数据包在这些定义中被计数。然而，硬件复制可能会影响这些定义，这取决于使用“类型P”来增加对数据包接收的附加限制。例如，仅对唯一发送的数据包计数的限制对于关心有意义数据的容量的用户可能更有用。相比之下，更一般、不受限制的度量可能适用于关心原始容量的用户。因此，在可能普遍存在硬件重复的情况下，由用户适当地确定范围并解释结果。
IP encapsulation does not affect the definitions as all IP header and payload bits must be counted regardless of content. However, IP packets of different sizes can lead to a variation in the amount of overhead needed at the lower layers to transmit the data, thus altering the overall IP link-layer capacity.
IP封装不会影响定义，因为无论内容如何，所有IP头和有效负载位都必须计数。然而，不同大小的IP分组可导致较低层传输数据所需的开销量的变化，从而改变IP链路层的总体容量。
Should the link happen to employ a compression scheme such as RObust Header Compression (ROHC) [RFC3095] or V.44 [V44], some of the original bits are not transmitted across the link. However, the inflated (not compressed) number of IP-layer bits should be counted.
如果链路碰巧采用了诸如鲁棒报头压缩（ROHC）[RFC3095]或V.44[V44]之类的压缩方案，则一些原始比特不会在链路上传输。但是，应计算IP层比特的膨胀（未压缩）数。
Certain terms are often used to characterize specific aspects of the presented definitions. The link with the smallest capacity is commonly referred to as the "narrow link" of a path. Also, the link with the smallest available capacity is often referred to as the "tight link" within a path. So, while a given link may have a very large capacity, the overall congestion level on the link makes it the likely bottleneck of a connection. Conversely, a link that has the smallest capacity may not be the bottleneck should it be lightly loaded in relation to the rest of the path.
某些术语通常用于描述所提出定义的特定方面。容量最小的链路通常被称为路径的“窄链路”。此外，具有最小可用容量的链路通常被称为路径内的“紧密链路”。因此，虽然给定的链路可能具有非常大的容量，但链路上的总体拥塞水平使其成为连接的可能瓶颈。相反，容量最小的链路可能不是瓶颈，如果它相对于路径的其余部分负载较轻。
Also, literature often overloads the term "bandwidth" to refer to what we have described as capacity in this document. For example, when inquiring about the bandwidth of a 802.11b link, a network engineer will likely answer with 11 Mbit/s. However, an electrical engineer may answer with 25 MHz, and an end user may tell you that his observed bandwidth is 8 Mbit/s. In contrast, the term "capacity" is not quite as overloaded and is an appropriate term that better reflects what is actually being measured.
此外，文献中经常对术语“带宽”进行过多的描述，以指代我们在本文档中描述的容量。例如，当询问802.11b链路的带宽时，网络工程师的回答可能是11 Mbit/s。然而，电气工程师可能会回答25 MHz，最终用户可能会告诉您，他观察到的带宽为8 Mbit/s。相比之下，“容量”一词并没有那么多，它是一个恰当的术语，可以更好地反映实际测量的内容。
Bulk Transfer Capacity (BTC) [RFC3148] provides a distinct perspective on path capacity that differs from the definitions in this document in several fundamental ways. First, BTC operates at the transport layer, gauging the amount of capacity available to an application that wishes to send data. Only unique data is measured, meaning header and retransmitted data are not included in the calculation. In contrast, IP-layer link capacity includes the IP header and is indifferent to the uniqueness of the data contained within the packet payload. (Hardware duplication of packets is an anomaly addressed in a previous section.) Second, BTC utilizes a single congestion-aware transport connection, such as TCP, to obtain measurements. As a result, BTC implementations react strongly to different path characteristics, topologies, and distances. Since these differences can affect the control loop (propagation delays, segment reordering, etc.), the reaction is further dependent on the algorithms being employed for the measurements. For example, consider a single event where a link suffers a large duration of bit errors. The event could cause IP-layer packets to be discarded, and the lost packets would reduce the IP-layer link capacity. However, the same event and subsequent losses would trigger loss recovery for
大容量传输容量（BTC）[RFC3148]提供了路径容量的独特视角，在几个基本方面与本文中的定义不同。首先，BTC在传输层运行，测量希望发送数据的应用程序的可用容量。仅测量唯一数据，这意味着计算中不包括报头和重新传输的数据。相反，IP层链路容量包括IP报头，并且与包有效载荷中包含的数据的唯一性无关。（数据包的硬件复制是前一节中提到的一种异常现象。）其次，BTC利用单个拥塞感知传输连接（如TCP）来获取测量值。因此，BTC实现对不同的路径特征、拓扑和距离有强烈的反应。由于这些差异会影响控制回路（传播延迟、段重新排序等），因此反应进一步取决于测量所采用的算法。例如，考虑单个事件，其中链路遭受较大的位错误持续时间。该事件可能导致丢弃IP层数据包，丢失的数据包将降低IP层链路容量。然而，同一事件和随后的损失将触发以下方面的损失恢复：
a BTC measurement resulting in the retransmission of data and a potentially reduced sending rate. Thus, a measurement of BTC does not correspond to any of the definitions in this document. Both techniques are useful in exploring the characteristics of a network path, but from different perspectives.
一种BTC测量，导致数据的重新传输和可能降低的发送速率。因此，BTC的测量不符合本文件中的任何定义。这两种技术都有助于探索网络路径的特征，但视角不同。
This document specifies definitions regarding IP traffic traveling between a source and destination in an IP network. These definitions do not raise any security issues and do not have a direct impact on the networking protocol suite.
本文档指定了有关IP网络中源和目标之间的IP流量的定义。这些定义不会引起任何安全问题，也不会对网络协议套件产生直接影响。
Tools that attempt to implement these definitions may introduce security issues specific to each implementation. Both active and passive measurement techniques can be abused, impacting the security, privacy, and performance of the network. Any measurement techniques based upon these definitions must include a discussion of the techniques needed to protect the network on which the measurements are being performed.
尝试实现这些定义的工具可能会引入特定于每个实现的安全问题。主动和被动测量技术都可能被滥用，影响网络的安全性、隐私性和性能。基于这些定义的任何测量技术必须包括对保护进行测量的网络所需的技术的讨论。
In this document, we have defined a set of quantities related to the capacity of links and paths in an IP network. In these definitions, we have tried to be as clear as possible and take into account various characteristics that links and paths can have. The goal of these definitions is to enable researchers who propose capacity metrics to relate those metrics to these definitions and to evaluate those metrics with respect to how well they approximate these quantities.
在本文档中，我们定义了一组与IP网络中的链路和路径容量相关的量。在这些定义中，我们试图尽可能清晰，并考虑到链接和路径可能具有的各种特征。这些定义的目标是使提出能力指标的研究人员能够将这些指标与这些定义联系起来，并评估这些指标与这些数量的近似程度。
In addition, we have pointed out some key auxiliary parameters and opened a discussion of issues related to valid inferences from available capacity metrics.
此外，我们还指出了一些关键的辅助参数，并开始讨论与可用容量指标有效推断相关的问题。
The authors would like to acknowledge Mark Allman, Patrik Arlos, Matt Mathis, Al Morton, Stanislav Shalunov, and Matt Zekauskas for their suggestions, comments, and reviews. We also thank members of the IETF IPPM Mailing List for their discussions and feedback on this document.
作者感谢Mark Allman、Patrik Arlos、Matt Mathis、Al Morton、Stanislav Shalunov和Matt Zekauskas的建议、评论和评论。我们还感谢IETF IPPM邮件列表的成员对本文件的讨论和反馈。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，1998年5月。
[PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet Dispersion Techniques and a Capacity Estimation Methodology", IEEE/ACM Transactions on Networking 12(6): 963-977, December 2004.
[PDM]Dovrolis，C.，Ramanathan，P.，和D.Moore，“数据包分散技术和容量估计方法”，IEEE/ACM网络事务12（6）：963-977，2004年12月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，2001年7月。
[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月。
[V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44, "Data Compression Procedures", November 2000.
[V44]国际电联电信标准化部门（ITU-T）建议V.44，“数据压缩程序”，2000年11月。
Authors' Addresses
作者地址
Phil Chimento JHU Applied Physics Lab 11100 Johns Hopkins Road Laurel, Maryland 20723-6099 USA
Phil Chimento JHU应用物理实验室11100美国马里兰州劳雷尔市约翰霍普金斯路20723-6099号
Phone: +1-240-228-1743
Fax: +1-240-228-0789
EMail: Philip.Chimento@jhuapl.edu
Phone: +1-240-228-1743
Fax: +1-240-228-0789
EMail: Philip.Chimento@jhuapl.edu
Joseph Ishac NASA Glenn Research Center 21000 Brookpark Road, MS 54-5 Cleveland, Ohio 44135 USA
美国俄亥俄州克利夫兰市布鲁克帕克路21000号美国宇航局格伦研究中心
Phone: +1-216-433-6587
Fax: +1-216-433-8705
EMail: jishac@nasa.gov
Phone: +1-216-433-6587
Fax: +1-216-433-8705
EMail: jishac@nasa.gov
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 except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.