Internet Engineering Task Force (IETF) B. Constantine
Request for Comments: 7640 JDSU
Category: Informational R. Krishnan
ISSN: 2070-1721 Dell Inc.
September 2015
Internet Engineering Task Force (IETF) B. Constantine
Request for Comments: 7640 JDSU
Category: Informational R. Krishnan
ISSN: 2070-1721 Dell Inc.
September 2015
Traffic Management Benchmarking
交通管理基准
Abstract
摘要
This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e., policing, shaping, etc.). The goals are to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic.
该框架描述了一种实用的方法，用于对网络设备的流量管理能力进行基准测试（即，管理、塑造等）。目标是提供一种可重复的测试方法，客观地比较设备流量管理功能的性能，并指定使用代表性应用程序流量对流量管理进行基准测试的方法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7640.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7640.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Traffic Management Overview ................................3
1.2. Lab Configuration and Testing Overview .....................5
2. Conventions Used in This Document ...............................6
3. Scope and Goals .................................................7
4. Traffic Benchmarking Metrics ...................................10
4.1. Metrics for Stateless Traffic Tests .......................10
4.2. Metrics for Stateful Traffic Tests ........................12
5. Tester Capabilities ............................................13
5.1. Stateless Test Traffic Generation .........................13
5.1.1. Burst Hunt with Stateless Traffic ..................14
5.2. Stateful Test Pattern Generation ..........................14
5.2.1. TCP Test Pattern Definitions .......................15
6. Traffic Benchmarking Methodology ...............................17
6.1. Policing Tests ............................................17
6.1.1. Policer Individual Tests ...........................18
6.1.2. Policer Capacity Tests .............................19
6.1.2.1. Maximum Policers on Single Physical Port ..20
6.1.2.2. Single Policer on All Physical Ports ......22
6.1.2.3. Maximum Policers on All Physical Ports ....22
6.2. Queue/Scheduler Tests .....................................23
6.2.1. Queue/Scheduler Individual Tests ...................23
6.2.1.1. Testing Queue/Scheduler with
Stateless Traffic .........................23
6.2.1.2. Testing Queue/Scheduler with
Stateful Traffic ..........................25
6.2.2. Queue/Scheduler Capacity Tests .....................28
6.2.2.1. Multiple Queues, Single Port Active .......28
6.2.2.1.1. Strict Priority on
Egress Port ....................28
6.2.2.1.2. Strict Priority + WFQ on
Egress Port ....................29
6.2.2.2. Single Queue per Port, All Ports Active ...30
6.2.2.3. Multiple Queues per Port, All
Ports Active ..............................31
6.3. Shaper Tests ..............................................32
6.3.1. Shaper Individual Tests ............................32
6.3.1.1. Testing Shaper with Stateless Traffic .....33
6.3.1.2. Testing Shaper with Stateful Traffic ......34
6.3.2. Shaper Capacity Tests ..............................36
6.3.2.1. Single Queue Shaped, All Physical
Ports Active ..............................37
6.3.2.2. All Queues Shaped, Single Port Active .....37
6.3.2.3. All Queues Shaped, All Ports Active .......39
1. Introduction ....................................................3
1.1. Traffic Management Overview ................................3
1.2. Lab Configuration and Testing Overview .....................5
2. Conventions Used in This Document ...............................6
3. Scope and Goals .................................................7
4. Traffic Benchmarking Metrics ...................................10
4.1. Metrics for Stateless Traffic Tests .......................10
4.2. Metrics for Stateful Traffic Tests ........................12
5. Tester Capabilities ............................................13
5.1. Stateless Test Traffic Generation .........................13
5.1.1. Burst Hunt with Stateless Traffic ..................14
5.2. Stateful Test Pattern Generation ..........................14
5.2.1. TCP Test Pattern Definitions .......................15
6. Traffic Benchmarking Methodology ...............................17
6.1. Policing Tests ............................................17
6.1.1. Policer Individual Tests ...........................18
6.1.2. Policer Capacity Tests .............................19
6.1.2.1. Maximum Policers on Single Physical Port ..20
6.1.2.2. Single Policer on All Physical Ports ......22
6.1.2.3. Maximum Policers on All Physical Ports ....22
6.2. Queue/Scheduler Tests .....................................23
6.2.1. Queue/Scheduler Individual Tests ...................23
6.2.1.1. Testing Queue/Scheduler with
Stateless Traffic .........................23
6.2.1.2. Testing Queue/Scheduler with
Stateful Traffic ..........................25
6.2.2. Queue/Scheduler Capacity Tests .....................28
6.2.2.1. Multiple Queues, Single Port Active .......28
6.2.2.1.1. Strict Priority on
Egress Port ....................28
6.2.2.1.2. Strict Priority + WFQ on
Egress Port ....................29
6.2.2.2. Single Queue per Port, All Ports Active ...30
6.2.2.3. Multiple Queues per Port, All
Ports Active ..............................31
6.3. Shaper Tests ..............................................32
6.3.1. Shaper Individual Tests ............................32
6.3.1.1. Testing Shaper with Stateless Traffic .....33
6.3.1.2. Testing Shaper with Stateful Traffic ......34
6.3.2. Shaper Capacity Tests ..............................36
6.3.2.1. Single Queue Shaped, All Physical
Ports Active ..............................37
6.3.2.2. All Queues Shaped, Single Port Active .....37
6.3.2.3. All Queues Shaped, All Ports Active .......39
6.4. Concurrent Capacity Load Tests ............................40
7. Security Considerations ........................................40
8. References .....................................................41
8.1. Normative References ......................................41
8.2. Informative References ....................................42
Appendix A. Open Source Tools for Traffic Management Testing ......44
Appendix B. Stateful TCP Test Patterns ............................45
Acknowledgments ...................................................51
Authors' Addresses ................................................51
6.4. Concurrent Capacity Load Tests ............................40
7. Security Considerations ........................................40
8. References .....................................................41
8.1. Normative References ......................................41
8.2. Informative References ....................................42
Appendix A. Open Source Tools for Traffic Management Testing ......44
Appendix B. Stateful TCP Test Patterns ............................45
Acknowledgments ...................................................51
Authors' Addresses ................................................51
Traffic management (i.e., policing, shaping, etc.) is an increasingly important component when implementing network Quality of Service (QoS).
在实现网络服务质量（QoS）时，流量管理（即，管理、塑造等）是一个越来越重要的组成部分。
There is currently no framework to benchmark these features, although some standards address specific areas as described in Section 1.1.
目前还没有对这些特性进行基准测试的框架，尽管有些标准涉及第1.1节所述的特定领域。
This document provides a framework to conduct repeatable traffic management benchmarks for devices and systems in a lab environment.
本文档提供了一个框架，用于在实验室环境中为设备和系统执行可重复的流量管理基准测试。
Specifically, this framework defines the methods to characterize the capacity of the following traffic management features in network devices: classification, policing, queuing/scheduling, and traffic shaping.
具体而言，该框架定义了描述网络设备中以下流量管理功能的容量的方法：分类、策略、排队/调度和流量整形。
This benchmarking framework can also be used as a test procedure to assist in the tuning of traffic management parameters before service activation. In addition to Layer 2/3 (Ethernet/IP) benchmarking, Layer 4 (TCP) test patterns are proposed by this document in order to more realistically benchmark end-user traffic.
此基准测试框架还可用作测试程序，以帮助在服务激活之前调整交通管理参数。除了第2/3层（以太网/IP）基准测试外，本文还提出了第4层（TCP）测试模式，以便更真实地基准测试最终用户流量。
In general, a device with traffic management capabilities performs the following functions:
通常，具有流量管理功能的设备执行以下功能：
- Traffic classification: identifies traffic according to various configuration rules (for example, IEEE 802.1Q Virtual LAN (VLAN), Differentiated Services Code Point (DSCP)) and marks this traffic internally to the network device. Multiple external priorities (DSCP, 802.1p, etc.) can map to the same priority in the device.
- 流量分类：根据各种配置规则（例如，IEEE 802.1Q虚拟LAN（VLAN）、区分服务代码点（DSCP））识别流量，并在网络设备内部标记此流量。多个外部优先级（DSCP、802.1p等）可以映射到设备中的同一优先级。
- Traffic policing: limits the rate of traffic that enters a network device according to the traffic classification. If the traffic exceeds the provisioned limits, the traffic is either dropped or remarked and forwarded onto the next network device.
- 流量管理：根据流量分类限制进入网络设备的流量速率。如果流量超过规定的限制，则会丢弃或标记流量，并将其转发到下一个网络设备。
- Traffic scheduling: provides traffic classification within the network device by directing packets to various types of queues and applies a dispatching algorithm to assign the forwarding sequence of packets.
- 流量调度：通过将数据包定向到各种类型的队列来提供网络设备内的流量分类，并应用调度算法来分配数据包的转发顺序。
- Traffic shaping: controls traffic by actively buffering and smoothing the output rate in an attempt to adapt bursty traffic to the configured limits.
- 流量整形：通过主动缓冲和平滑输出速率来控制流量，以使突发流量适应配置的限制。
- Active Queue Management (AQM): involves monitoring the status of internal queues and proactively dropping (or remarking) packets, which causes hosts using congestion-aware protocols to "back off" and in turn alleviate queue congestion [RFC7567]. On the other hand, classic traffic management techniques reactively drop (or remark) packets based on queue-full conditions. The benchmarking scenarios for AQM are different and are outside the scope of this testing framework.
- 主动队列管理（AQM）：涉及监控内部队列的状态并主动丢弃（或重新标记）数据包，这会导致使用拥塞感知协议的主机“后退”，进而缓解队列拥塞[RFC7567]。另一方面，经典的流量管理技术根据队列满的情况反应性地丢弃（或评论）数据包。AQM的基准测试场景不同，不在本测试框架的范围内。
Even though AQM is outside the scope of this framework, it should be noted that the TCP metrics and TCP test patterns (defined in Sections 4.2 and 5.2, respectively) could be useful to test new AQM algorithms (targeted to alleviate "bufferbloat"). Examples of these algorithms include Controlled Delay [CoDel] and Proportional Integral controller Enhanced [PIE].
尽管AQM不在本框架的范围内，但应注意的是，TCP度量和TCP测试模式（分别在第4.2节和第5.2节中定义）可用于测试新的AQM算法（旨在缓解“缓冲区膨胀”）。这些算法的示例包括受控延迟[CoDel]和比例积分控制器增强[PIE]。
The following diagram is a generic model of the traffic management capabilities within a network device. It is not intended to represent all variations of manufacturer traffic management capabilities, but it provides context for this test framework.
下图是网络设备内流量管理功能的通用模型。它并不表示制造商流量管理功能的所有变体，但它为该测试框架提供了上下文。
|----------| |----------------| |--------------| |----------|
| | | | | | | |
|Interface | |Ingress Actions | |Egress Actions| |Interface |
|Ingress | |(classification,| |(scheduling, | |Egress |
|Queues | | marking, | | shaping, | |Queues |
| |-->| policing, or |-->| active queue |-->| |
| | | shaping) | | management, | | |
| | | | | remarking) | | |
|----------| |----------------| |--------------| |----------|
|----------| |----------------| |--------------| |----------|
| | | | | | | |
|Interface | |Ingress Actions | |Egress Actions| |Interface |
|Ingress | |(classification,| |(scheduling, | |Egress |
|Queues | | marking, | | shaping, | |Queues |
| |-->| policing, or |-->| active queue |-->| |
| | | shaping) | | management, | | |
| | | | | remarking) | | |
|----------| |----------------| |--------------| |----------|
Figure 1: Generic Traffic Management Capabilities of a Network Device
图1：网络设备的通用流量管理功能
Ingress actions such as classification are defined in [RFC4689] and include IP addresses, port numbers, and DSCP. In terms of marking, [RFC2697] and [RFC2698] define a Single Rate Three Color Marker and a Two Rate Three Color Marker, respectively.
[RFC4689]中定义了诸如分类之类的进入操作，包括IP地址、端口号和DSCP。在标记方面，[RFC2697]和[RFC2698]分别定义了单速率三色标记和双速率三色标记。
The Metro Ethernet Forum (MEF) specifies policing and shaping in terms of ingress and egress subscriber/provider conditioning functions as described in MEF 12.2 [MEF-12.2], as well as ingress and bandwidth profile attributes as described in MEF 10.3 [MEF-10.3] and MEF 26.1 [MEF-26.1].
Metro Ethernet Forum（MEF）根据MEF 12.2[MEF-12.2]中所述的入口和出口用户/提供商调节功能，以及MEF 10.3[MEF-10.3]和MEF 26.1[MEF-26.1]中所述的入口和带宽配置文件属性，规定了监管和塑造。
The following diagram shows the lab setup for the traffic management tests:
下图显示了流量管理测试的实验室设置：
+--------------+ +-------+ +----------+ +-----------+
| Transmitting | | | | | | Receiving |
| Test Host | | | | | | Test Host |
| |-----| Device|---->| Network |--->| |
| | | Under | | Delay | | |
| | | Test | | Emulator | | |
| |<----| |<----| |<---| |
| | | | | | | |
+--------------+ +-------+ +----------+ +-----------+
+--------------+ +-------+ +----------+ +-----------+
| Transmitting | | | | | | Receiving |
| Test Host | | | | | | Test Host |
| |-----| Device|---->| Network |--->| |
| | | Under | | Delay | | |
| | | Test | | Emulator | | |
| |<----| |<----| |<---| |
| | | | | | | |
+--------------+ +-------+ +----------+ +-----------+
Figure 2: Lab Setup for Traffic Management Tests
图2：流量管理测试的实验室设置
As shown in the test diagram, the framework supports unidirectional and bidirectional traffic management tests (where the transmitting and receiving roles would be reversed on the return path).
如测试图所示，该框架支持单向和双向流量管理测试（其中发送和接收角色将在返回路径上颠倒）。
This testing framework describes the tests and metrics for each of the following traffic management functions:
该测试框架描述了以下每个流量管理功能的测试和指标：
- Classification
- 分类
- Policing
- 维持治安
- Queuing/scheduling
- 排队/排程
- Shaping
- 塑造
The tests are divided into individual and rated capacity tests. The individual tests are intended to benchmark the traffic management functions according to the metrics defined in Section 4. The capacity tests verify traffic management functions under the load of many simultaneous individual tests and their flows.
试验分为单独试验和额定容量试验。单独测试旨在根据第4节中定义的指标对交通管理功能进行基准测试。容量测试验证了多个同时进行的单独测试及其流量负载下的流量管理功能。
This involves concurrent testing of multiple interfaces with the specific traffic management function enabled, and increasing the load to the capacity limit of each interface.
这涉及在启用特定流量管理功能的情况下对多个接口进行并发测试，并将负载增加到每个接口的容量限制。
For example, a device is specified to be capable of shaping on all of its egress ports. The individual test would first be conducted to benchmark the specified shaping function against the metrics defined in Section 4. Then, the capacity test would be executed to test the shaping function concurrently on all interfaces and with maximum traffic load.
例如，设备被指定能够在其所有出口端口上成形。首先进行单独测试，以根据第4节中定义的指标对指定的成形功能进行基准测试。然后，将执行容量测试，以在所有接口上以最大流量负载同时测试成形功能。
The Network Delay Emulator (NDE) is required for TCP stateful tests in order to allow TCP to utilize a TCP window of significant size in its control loop.
TCP状态测试需要网络延迟模拟器（NDE），以便允许TCP在其控制回路中利用较大的TCP窗口。
Note also that the NDE SHOULD be passive in nature (e.g., a fiber spool). This is recommended to eliminate the potential effects that an active delay element (i.e., test impairment generator) may have on the test flows. In the case where a fiber spool is not practical due to the desired latency, an active NDE MUST be independently verified to be capable of adding the configured delay without loss. In other words, the Device Under Test (DUT) would be removed and the NDE performance benchmarked independently.
还要注意，无损检测本质上应该是被动的（例如，光纤线轴）。建议这样做是为了消除活动延迟元件（即测试损害发生器）可能对测试流产生的潜在影响。如果由于期望的延迟，光纤假脱机不实用，则必须独立验证活动NDE是否能够添加配置的延迟而不丢失。换句话说，被测设备（DUT）将被移除，NDE性能将独立进行基准测试。
Note that the NDE SHOULD be used only as emulated delay. Most NDEs allow for per-flow delay actions, emulating QoS prioritization. For this framework, the NDE's sole purpose is simply to add delay to all packets (emulate network latency). So, to benchmark the performance of the NDE, the maximum offered load should be tested against the following frame sizes: 128, 256, 512, 768, 1024, 1500, and 9600 bytes. The delay accuracy at each of these packet sizes can then be used to calibrate the range of expected Bandwidth-Delay Product (BDP) for the TCP stateful tests.
注意，NDE应仅用作模拟延迟。大多数NDE允许每流延迟操作，模拟QoS优先级。对于这个框架，NDE的唯一目的只是向所有数据包添加延迟（模拟网络延迟）。因此，为了测试NDE的性能，应针对以下帧大小测试提供的最大负载：128、256、512、768、1024、1500和9600字节。然后，每个数据包大小的延迟精度可用于校准TCP有状态测试的预期带宽延迟乘积（BDP）范围。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following acronyms are used:
使用以下首字母缩略词：
AQM: Active Queue Management
主动队列管理
BB: Bottleneck Bandwidth
瓶颈带宽
BDP: Bandwidth-Delay Product
带宽延迟积
BSA: Burst Size Achieved
BSA：达到突发大小
CBS: Committed Burst Size
CBS：提交的突发大小
CIR: Committed Information Rate
提交信息速率
DUT: Device Under Test
DUT：被测设备
EBS: Excess Burst Size
EBS：超出突发大小
EIR: Excess Information Rate
EIR：超额信息率
NDE: Network Delay Emulator
网络延迟仿真器
QL: Queue Length
QL：队列长度
QoS: Quality of Service
QoS：服务质量
RTT: Round-Trip Time
RTT：往返时间
SBB: Shaper Burst Bytes
SBB：整形器突发字节
SBI: Shaper Burst Interval
SBI：整形器突发间隔
SP: Strict Priority
SP：严格优先级
SR: Shaper Rate
SR：成型率
SSB: Send Socket Buffer
发送套接字缓冲区
SUT: System Under Test
SUT：测试中的系统
Ti: Transmission Interval
Ti：传输间隔
TTP: TCP Test Pattern
TTP:TCP测试模式
TTPET: TCP Test Pattern Execution Time
TTPET:TCP测试模式执行时间
The scope of this work is to develop a framework for benchmarking and testing the traffic management capabilities of network devices in the lab environment. These network devices may include but are not limited to:
这项工作的范围是开发一个框架，用于在实验室环境中对网络设备的流量管理功能进行基准测试和测试。这些网络设备可包括但不限于：
- Switches (including Layer 2/3 devices)
- 交换机（包括第2/3层设备）
- Routers
- 路由器
- Firewalls
- 防火墙
- General Layer 4-7 appliances (Proxies, WAN Accelerators, etc.)
- 通用第4-7层设备（代理、广域网加速器等）
Essentially, any network device that performs traffic management as defined in Section 1.1 can be benchmarked or tested with this framework.
本质上，任何执行第1.1节中定义的流量管理的网络设备都可以使用该框架进行基准测试或测试。
The primary goal is to assess the maximum forwarding performance deemed to be within the provisioned traffic limits that a network device can sustain without dropping or impairing packets, and without compromising the accuracy of multiple instances of traffic management functions. This is the benchmark for comparison between devices.
主要目标是评估被视为在网络设备能够维持而不丢弃或损害分组，并且不损害流量管理功能的多个实例的准确性的规定流量限制内的最大转发性能。这是设备之间比较的基准。
Within this framework, the metrics are defined for each traffic management test but do not include pass/fail criteria, which are not within the charter of the BMWG. This framework provides the test methods and metrics to conduct repeatable testing, which will provide the means to compare measured performance between DUTs.
在此框架内，为每个流量管理测试定义了指标，但不包括通过/失败标准，这不在BMWG章程内。该框架提供了进行可重复测试的测试方法和指标，这将提供比较DUT之间测量性能的方法。
As mentioned in Section 1.2, these methods describe the individual tests and metrics for several management functions. It is also within scope that this framework will benchmark each function in terms of overall rated capacity. This involves concurrent testing of multiple interfaces with the specific traffic management function enabled, up to the capacity limit of each interface.
如第1.2节所述，这些方法描述了几个管理功能的单独测试和指标。该框架还将根据总体额定容量对每个功能进行基准测试。这涉及在启用特定流量管理功能的情况下对多个接口进行并发测试，直至每个接口的容量限制。
It is not within the scope of this framework to specify the procedure for testing multiple configurations of traffic management functions concurrently. The multitudes of possible combinations are almost unbounded, and the ability to identify functional "break points" would be almost impossible.
同时测试多个交通管理功能配置的程序不在本框架的范围内。大量可能的组合几乎是无界的，识别功能“断点”的能力几乎是不可能的。
However, Section 6.4 provides suggestions for some profiles of concurrent functions that would be useful to benchmark. The key requirement for any concurrent test function is that tests MUST produce reliable and repeatable results.
然而，第6.4节提供了一些对基准测试有用的并发函数配置文件的建议。任何并发测试功能的关键要求是测试必须产生可靠和可重复的结果。
Also, it is not within scope to perform conformance testing. Tests defined in this framework benchmark the traffic management functions according to the metrics defined in Section 4 and do not address any conformance to standards related to traffic management.
此外，执行一致性测试也不在范围之内。本框架中定义的测试根据第4节中定义的指标对流量管理功能进行基准测试，不涉及任何与流量管理相关的标准一致性。
The current specifications don't specify exact behavior or implementation, and the specifications that do exist (cited in Section 1.1) allow implementations to vary with regard to short-term rate accuracy and other factors. This is a primary driver for this framework: to provide an objective means to compare vendor traffic management functions.
目前的规范没有规定确切的行为或实施，现有的规范（在第1.1节中引用）允许实施在短期利率准确性和其他因素方面有所不同。这是该框架的主要驱动因素：提供一种比较供应商流量管理功能的客观方法。
Another goal is to devise methods that utilize flows with congestion-aware transport (TCP) as part of the traffic load and still produce repeatable results in the isolated test environment. This framework will derive stateful test patterns (TCP or application layer) that can also be used to further benchmark the performance of applicable traffic management techniques such as queuing/scheduling and traffic shaping. In cases where the network device is stateful in nature (i.e., firewall, etc.), stateful test pattern traffic is important to test, along with stateless UDP traffic in specific test scenarios (i.e., applications using TCP transport and UDP VoIP, etc.).
另一个目标是设计方法，利用具有拥塞感知传输（TCP）的流作为流量负载的一部分，并在隔离的测试环境中仍然产生可重复的结果。该框架将派生有状态测试模式（TCP或应用层），也可用于进一步基准测试适用流量管理技术（如排队/调度和流量整形）的性能。在网络设备本质上是有状态的情况下（如防火墙等），有状态测试模式流量与特定测试场景中的无状态UDP流量（如使用TCP传输和UDP VoIP等的应用程序）一起测试非常重要。
As mentioned earlier in this document, repeatability of test results is critical, especially considering the nature of stateful TCP traffic. To this end, the stateful tests will use TCP test patterns to emulate applications. This framework also provides guidelines for application modeling and open source tools to achieve the repeatable stimulus. Finally, TCP metrics from [RFC6349] MUST be measured for each stateful test and provide the means to compare each repeated test.
正如本文档前面提到的，测试结果的可重复性是至关重要的，特别是考虑到有状态TCP流量的性质。为此，有状态测试将使用TCP测试模式来模拟应用程序。该框架还为应用程序建模和开源工具提供指导，以实现可重复的刺激。最后，必须为每个有状态测试测量[RFC6349]中的TCP指标，并提供比较每个重复测试的方法。
Even though this framework targets the testing of TCP applications (i.e., web, email, database, etc.), it could also be applied to the Stream Control Transmission Protocol (SCTP) in terms of test patterns. WebRTC, Signaling System 7 (SS7) signaling, and 3GPP are SCTP-based applications that could be modeled with this framework to benchmark SCTP's effect on traffic management performance.
尽管该框架的目标是测试TCP应用程序（即web、电子邮件、数据库等），但它也可以应用于流控制传输协议（SCTP）的测试模式。WebRTC、信令系统7（SS7）信令和3GPP是基于SCTP的应用程序，可以使用此框架对其进行建模，以测试SCTP对流量管理性能的影响。
Note that at the time of this writing, this framework does not address tcpcrypt (encrypted TCP) test patterns, although the metrics defined in Section 4.2 can still be used because the metrics are based on TCP retransmission and RTT measurements (versus any of the payload). Thus, if tcpcrypt becomes popular, it would be natural for benchmarkers to consider encrypted TCP patterns and include them in test cases.
请注意，在撰写本文时，该框架并未涉及tcpcrypt（加密TCP）测试模式，尽管第4.2节中定义的指标仍然可以使用，因为这些指标基于TCP重传和RTT测量（相对于任何有效负载）。因此，如果TCPLIPT变得流行，基准测试人员会考虑加密的TCP模式并将其包含在测试用例中。
The metrics to be measured during the benchmarks are divided into two (2) sections: packet-layer metrics used for the stateless traffic testing and TCP-layer metrics used for the stateful traffic testing.
基准测试期间要测量的指标分为两（2）部分：用于无状态流量测试的数据包层指标和用于有状态流量测试的TCP层指标。
Stateless traffic measurements require that a sequence number and timestamp be inserted into the payload for lost-packet analysis. Delay analysis may be achieved by insertion of timestamps directly into the packets or timestamps stored elsewhere (packet captures). This framework does not specify the packet format to carry sequence number or timing information.
无状态流量测量要求在负载中插入序列号和时间戳，以进行丢失数据包分析。延迟分析可以通过将时间戳直接插入包或存储在别处的时间戳（包捕获）来实现。该框架不指定用于携带序列号或定时信息的数据包格式。
However, [RFC4737] and [RFC4689] provide recommendations for sequence tracking, along with definitions of in-sequence and out-of-order packets.
然而，[RFC4737]和[RFC4689]提供了序列跟踪的建议，以及顺序内和顺序外数据包的定义。
The following metrics MUST be measured during the stateless traffic benchmarking components of the tests:
在测试的无状态流量基准组件期间，必须测量以下指标：
- Burst Size Achieved (BSA): For the traffic policing and network queue tests, the tester will be configured to send bursts to test either the Committed Burst Size (CBS) or Excess Burst Size (EBS) of a policer or the queue/buffer size configured in the DUT. The BSA metric is a measure of the actual burst size received at the egress port of the DUT with no lost packets. For example, the configured CBS of a DUT is 64 KB, and after the burst test, only a 63 KB burst can be achieved without packet loss. Then, 63 KB is the BSA. Also, the average Packet Delay Variation (PDV) (see below) as experienced by the packets sent at the BSA burst size should be recorded. This metric SHALL be reported in units of bytes, KB, or MB.
- 达到的突发大小（BSA）：对于流量管理和网络队列测试，测试仪将配置为发送突发，以测试策略的提交突发大小（CBS）或过剩突发大小（EBS）或DUT中配置的队列/缓冲区大小。BSA度量是在没有丢失分组的情况下在DUT的出口端口处接收的实际突发大小的度量。例如，DUT的配置CBS为64 KB，在突发测试之后，只有63 KB的突发可以在不丢失数据包的情况下实现。那么，63KB是BSA。此外，应记录以BSA突发大小发送的分组所经历的平均分组延迟变化（PDV）（见下文）。该度量应以字节、KB或MB为单位报告。
- Lost Packets (LP): For all traffic management tests, the tester will transmit the test packets into the DUT ingress port, and the number of packets received at the egress port will be measured. The difference between packets transmitted into the ingress port and received at the egress port is the number of lost packets as measured at the egress port. These packets must have unique identifiers such that only the test packets are measured. For cases where multiple flows are transmitted from the ingress port to the egress port (e.g., IP conversations), each flow must have sequence numbers within the stream of test packets.
- 丢失数据包（LP）：对于所有流量管理测试，测试仪将测试数据包传输到DUT入口端口，并测量在出口端口接收的数据包数量。发送到入口端口和在出口端口接收的数据包之间的差异是在出口端口测量的丢失数据包的数量。这些数据包必须具有唯一标识符，以便仅测量测试数据包。对于多个流从入口端口传输到出口端口的情况（例如，IP对话），每个流必须在测试数据包流中具有序列号。
[RFC6703] and [RFC2680] describe the need to establish the time threshold to wait before a packet is declared as lost. This threshold MUST be reported, with the results reported as an integer number that cannot be negative.
[RFC6703]和[RFC2680]描述了在宣布数据包丢失之前建立等待时间阈值的需要。必须报告此阈值，并将结果报告为不能为负数的整数。
- Out-of-Sequence (OOS): In addition to the LP metric, the test packets must be monitored for sequence. [RFC4689] defines the general function of sequence tracking, as well as definitions for in-sequence and out-of-order packets. Out-of-order packets will be counted per [RFC4737]. This metric SHALL be reported as an integer number that cannot be negative.
- 无序（OOS）：除了LP指标外，还必须监控测试数据包的顺序。[RFC4689]定义了序列跟踪的一般功能，以及序列内和无序数据包的定义。无序数据包将按照[RFC4737]进行计数。该指标应报告为整数，不能为负数。
- Packet Delay (PD): The PD metric is the difference between the timestamp of the received egress port packets and the packets transmitted into the ingress port, as specified in [RFC1242]. The transmitting host and receiving host time must be in time sync (achieved by using NTP, GPS, etc.). This metric SHALL be reported as a real number of seconds, where a negative measurement usually indicates a time synchronization problem between test devices.
- 数据包延迟（PD）：PD度量是接收到的出口端口数据包的时间戳与传输到入口端口的数据包之间的差异，如[RFC1242]中所述。发送主机和接收主机的时间必须同步（通过使用NTP、GPS等实现）。该度量应报告为实际秒数，其中负测量值通常表示试验装置之间存在时间同步问题。
- Packet Delay Variation (PDV): The PDV metric is the variation between the timestamp of the received egress port packets, as specified in [RFC5481]. Note that per [RFC5481], this PDV is the variation of one-way delay across many packets in the traffic flow. Per the measurement formula in [RFC5481], select the high percentile of 99%, and units of measure will be a real number of seconds (a negative value is not possible for the PDV and would indicate a measurement error).
- 数据包延迟变化（PDV）：PDV度量是[RFC5481]中规定的接收出口端口数据包的时间戳之间的变化。请注意，根据[RFC5481]，此PDV是交通流中许多数据包的单向延迟变化。根据[RFC5481]中的测量公式，选择99%的高百分位，测量单位为秒的实数（PDV不可能出现负值，这表示测量错误）。
- Shaper Rate (SR): The SR represents the average DUT output rate (bps) over the test interval. The SR is only applicable to the traffic-shaping tests.
- 整形器速率（SR）：SR表示整个测试间隔内的平均DUT输出速率（bps）。SR仅适用于流量整形测试。
- Shaper Burst Bytes (SBB): A traffic shaper will emit packets in "trains" of different sizes; these frames are emitted "back-to-back" with respect to the mandatory interframe gap. This metric characterizes the method by which the shaper emits traffic. Some shapers transmit larger bursts per interval, and a burst of one packet would apply to the less common case of a shaper sending a constant-bitrate stream of single packets. This metric SHALL be reported in units of bytes, KB, or MB. The SBB metric is only applicable to the traffic-shaping tests.
- 整形器突发字节（SBB）：流量整形器将以不同大小的“序列”发射数据包；这些帧相对于强制帧间间隙“背靠背”发射。此度量表示整形器发出流量的方法。一些整形器每间隔发送较大的突发，一个数据包的突发将适用于整形器发送单个数据包的恒定比特率流的不太常见的情况。该度量应以字节、KB或MB为单位报告。SBB指标仅适用于流量整形测试。
- Shaper Burst Interval (SBI): The SBI is the time between bursts emitted by the shaper and is measured at the DUT egress port. This metric SHALL be reported as a real number of seconds. The SBI is only applicable to the traffic-shaping tests.
- 整形器脉冲间隔（SBI）：SBI是整形器发射脉冲之间的时间间隔，在DUT出口端口测量。该度量应以实际秒数报告。SBI仅适用于流量整形测试。
The stateful metrics will be based on [RFC6349] TCP metrics and MUST include:
有状态度量将基于[RFC6349]TCP度量，并且必须包括：
- TCP Test Pattern Execution Time (TTPET): [RFC6349] defined the TCP Transfer Time for bulk transfers, which is simply the measured time to transfer bytes across single or concurrent TCP connections. The TCP test patterns used in traffic management tests will include bulk transfer and interactive applications. The interactive patterns include instances such as HTTP business applications and database applications. The TTPET will be the measure of the time for a single execution of a TCP Test Pattern (TTP). Average, minimum, and maximum times will be measured or calculated and expressed as a real number of seconds.
- TCP测试模式执行时间（TTPET）：[RFC6349]定义了批量传输的TCP传输时间，它只是跨单个或并发TCP连接传输字节的测量时间。流量管理测试中使用的TCP测试模式将包括批量传输和交互式应用程序。交互模式包括HTTP业务应用程序和数据库应用程序等实例。TTPET将是TCP测试模式（TTP）单次执行时间的度量。将测量或计算平均、最小和最大时间，并以实际秒数表示。
An example would be an interactive HTTP TTP session that should take 5 seconds on a GigE network with 0.5-millisecond latency. During ten (10) executions of this TTP, the TTPET results might be an average of 6.5 seconds, a minimum of 5.0 seconds, and a maximum of 7.9 seconds.
例如，交互式HTTP TTP会话在GigE网络上需要5秒，延迟为0.5毫秒。在该TTP的十（10）次执行期间，TTPET结果可能平均为6.5秒，最小为5.0秒，最大为7.9秒。
- TCP Efficiency: After the execution of the TTP, TCP Efficiency represents the percentage of bytes that were not retransmitted.
- TCP效率：执行TTP后，TCP效率表示未重新传输的字节百分比。
Transmitted Bytes - Retransmitted Bytes
TCP Efficiency % = --------------------------------------- X 100
Transmitted Bytes
Transmitted Bytes - Retransmitted Bytes
TCP Efficiency % = --------------------------------------- X 100
Transmitted Bytes
"Transmitted Bytes" is the total number of TCP bytes to be transmitted, including the original bytes and the retransmitted bytes. To avoid any misinterpretation that a reordered packet is a retransmitted packet (as may be the case with packet decode interpretation), these retransmitted bytes should be recorded from the perspective of the sender's TCP/IP stack.
“已传输字节”是要传输的TCP字节总数，包括原始字节和重新传输的字节。为了避免对重新排序的数据包是重新传输的数据包的任何误解（如数据包解码解释的情况），应从发送方的TCP/IP堆栈的角度记录这些重新传输的字节。
- Buffer Delay: Buffer Delay represents the increase in RTT during a TCP test versus the baseline DUT RTT (non-congested, inherent latency). RTT and the technique to measure RTT (average versus baseline) are defined in [RFC6349]. Referencing [RFC6349], the average RTT is derived from the total of all measured RTTs during the actual test sampled at every second divided by the test duration in seconds.
- 缓冲区延迟：缓冲区延迟表示TCP测试期间RTT相对于基线DUT RTT（非拥塞、固有延迟）的增加。RTT和测量RTT（平均值与基线值）的技术在[RFC6349]中有定义。参考[RFC6349]，平均RTT由实际测试期间每秒取样的所有测量RTT的总和除以以秒为单位的测试持续时间得出。
Total RTTs during transfer
Average RTT during transfer = ------------------------------
Transfer duration in seconds
Total RTTs during transfer
Average RTT during transfer = ------------------------------
Transfer duration in seconds
Average RTT during transfer - Baseline RTT
Buffer Delay % = ------------------------------------------ X 100
Baseline RTT
Average RTT during transfer - Baseline RTT
Buffer Delay % = ------------------------------------------ X 100
Baseline RTT
Note that even though this was not explicitly stated in [RFC6349], retransmitted packets should not be used in RTT measurements.
请注意，尽管[RFC6349]中没有明确说明这一点，但RTT测量中不应使用重新传输的数据包。
Also, the test results should record the average RTT in milliseconds across the entire test duration, as well as the number of samples.
此外，测试结果应记录整个测试期间的平均RTT（以毫秒为单位），以及样本数。
The testing capabilities of the traffic management test environment are divided into two (2) sections: stateless traffic testing and stateful traffic testing.
流量管理测试环境的测试功能分为两（2）部分：无状态流量测试和有状态流量测试。
The test device MUST be capable of generating traffic at up to the link speed of the DUT. The test device must be calibrated to verify that it will not drop any packets. The test device's inherent PD and PDV must also be calibrated and subtracted from the PD and PDV metrics. The test device must support the encapsulation to be tested, e.g., IEEE 802.1Q VLAN, IEEE 802.1ad Q-in-Q, Multiprotocol Label Switching (MPLS). Also, the test device must allow control of the classification techniques defined in [RFC4689] (e.g., IP address, DSCP, classification of Type of Service).
测试设备必须能够以DUT的链路速度产生流量。必须校准测试设备，以验证其不会丢弃任何数据包。还必须校准测试设备的固有PD和PDV，并从PD和PDV指标中减去。测试设备必须支持待测试的封装，例如IEEE 802.1Q VLAN、IEEE 802.1ad Q-in-Q、多协议标签交换（MPLS）。此外，测试设备必须允许控制[RFC4689]中定义的分类技术（例如，IP地址、DSCP、服务类型分类）。
The open source tool "iperf" can be used to generate stateless UDP traffic and is discussed in Appendix A. Since iperf is a software-based tool, there will be performance limitations at higher link speeds (e.g., 1 GigE, 10 GigE). Careful calibration of any test environment using iperf is important. At higher link speeds, using hardware-based packet test equipment is recommended.
开源工具“iperf”可用于生成无状态UDP流量，并在附录A中进行了讨论。由于iperf是一种基于软件的工具，因此在更高的链路速度下（例如，1 GigE、10 GigE）会有性能限制。使用iperf仔细校准任何测试环境都很重要。在较高的链路速度下，建议使用基于硬件的数据包测试设备。
A central theme for the traffic management tests is to benchmark the specified burst parameter of a traffic management function, since burst parameters listed in Service Level Agreements (SLAs) are specified in bytes. For testing efficiency, including a burst hunt feature is recommended, as this feature automates the manual process of determining the maximum burst size that can be supported by a traffic management function.
流量管理测试的中心主题是对流量管理功能的指定突发参数进行基准测试，因为服务级别协议（SLA）中列出的突发参数是以字节为单位指定的。为了测试效率，建议使用突发搜索功能，因为此功能可自动手动确定流量管理功能支持的最大突发大小。
The burst hunt algorithm should start at the target burst size (maximum burst size supported by the traffic management function) and will send single bursts until it can determine the largest burst that can pass without loss. If the target burst size passes, then the test is complete. The "hunt" aspect occurs when the target burst size is not achieved; the algorithm will drop down to a configured minimum burst size and incrementally increase the burst until the maximum burst supported by the DUT is discovered. The recommended granularity of the incremental burst size increase is 1 KB.
突发搜索算法应以目标突发大小（流量管理功能支持的最大突发大小）开始，并将发送单个突发，直到它能够确定可以无损失通过的最大突发。如果目标突发大小通过，则测试完成。当未达到目标突发大小时，出现“狩猎”现象；该算法将下降到配置的最小突发大小，并逐渐增加突发，直到发现DUT支持的最大突发。增量突发大小增加的建议粒度为1 KB。
For a policer function, if the burst size passes, the burst should be increased by increments of 1 KB to verify that the policer is truly configured properly (or enabled at all).
对于policr函数，如果突发大小通过，则突发应以1 KB的增量增加，以验证policr是否真正正确配置（或完全启用）。
The TCP test host will have many of the same attributes as the TCP test host defined in [RFC6349]. The TCP test device may be a standard computer or a dedicated communications test instrument. In both cases, it must be capable of emulating both a client and a server.
TCP测试主机将具有许多与[RFC6349]中定义的TCP测试主机相同的属性。TCP测试设备可以是标准计算机或专用通信测试仪器。在这两种情况下，它必须能够同时模拟客户端和服务器。
For any test using stateful TCP test traffic, the Network Delay Emulator (the NDE function as shown in the lab setup diagram in Section 1.2) must be used in order to provide a meaningful BDP. As discussed in Section 1.2, the target traffic rate and configured RTT MUST be verified independently, using just the NDE for all stateful tests (to ensure that the NDE can add delay without inducing any packet loss).
对于使用有状态TCP测试流量的任何测试，必须使用网络延迟仿真器（NDE功能，如第1.2节实验室设置图所示），以提供有意义的BDP。如第1.2节所述，必须单独验证目标通信速率和配置的RTT，仅使用NDE进行所有有状态测试（以确保NDE可以在不导致任何数据包丢失的情况下增加延迟）。
The TCP test host MUST be capable of generating and receiving stateful TCP test traffic at the full link speed of the DUT. As a general rule of thumb, testing TCP throughput at rates greater than 500 Mbps may require high-performance server hardware or dedicated hardware-based test tools.
TCP测试主机必须能够以DUT的全链路速度生成和接收有状态TCP测试流量。一般来说，以大于500 Mbps的速率测试TCP吞吐量可能需要高性能服务器硬件或专用的基于硬件的测试工具。
The TCP test host MUST allow the adjustment of both Send and Receive Socket Buffer sizes. The Socket Buffers must be large enough to fill the BDP for bulk transfer of TCP test application traffic.
TCP测试主机必须允许调整发送和接收套接字缓冲区大小。套接字缓冲区必须足够大，以填充BDP，以便批量传输TCP测试应用程序流量。
Measuring RTT and retransmissions per connection will generally require a dedicated communications test instrument. In the absence of dedicated hardware-based test tools, these measurements may need to be conducted with packet capture tools; i.e., conduct TCP throughput tests, and analyze RTT and retransmissions in packet captures.
测量每个连接的RTT和重传通常需要专用的通信测试仪器。如果没有专用的基于硬件的测试工具，这些测量可能需要使用数据包捕获工具进行；i、 例如，进行TCP吞吐量测试，分析数据包捕获中的RTT和重传。
The TCP implementation used by the test host MUST be specified in the test results (e.g., TCP New Reno, TCP options supported). Additionally, the test results SHALL provide specific congestion control algorithm details, as per [RFC3148].
测试主机使用的TCP实现必须在测试结果中指定（例如，TCP New Reno、支持的TCP选项）。此外，根据[RFC3148]，测试结果应提供具体的拥塞控制算法细节。
While [RFC6349] defined the means to conduct throughput tests of TCP bulk transfers, the traffic management framework will extend TCP test execution into interactive TCP application traffic. Examples include email, HTTP, and business applications. This interactive traffic is bidirectional and can be chatty, meaning many turns in traffic communication during the course of a transaction (versus the relatively unidirectional flow of bulk transfer applications).
[RFC6349]定义了对TCP批量传输进行吞吐量测试的方法，而流量管理框架将TCP测试执行扩展到交互式TCP应用程序流量。示例包括电子邮件、HTTP和业务应用程序。这种交互流量是双向的，可以是聊天的，这意味着在事务处理过程中流量通信会发生很多变化（与批量传输应用程序相对单向的流量相比）。
The test device must not only support bulk TCP transfer application traffic but MUST also support chatty traffic. A valid stress test SHOULD include both traffic types. This is due to the non-uniform, bursty nature of chatty applications versus the relatively uniform nature of bulk transfers (the bulk transfer smoothly stabilizes to equilibrium state under lossless conditions).
测试设备不仅必须支持批量TCP传输应用程序流量，还必须支持聊天流量。有效的压力测试应包括两种流量类型。这是由于闲聊应用程序的非均匀性、突发性和批量传输的相对一致性（批量传输在无损条件下平稳稳定到平衡状态）。
While iperf is an excellent choice for TCP bulk transfer testing, the "netperf" open source tool provides the ability to control client and server request/response behavior. The netperf-wrapper tool is a Python script that runs multiple simultaneous netperf instances and aggregates the results. Appendix A provides an overview of netperf/netperf-wrapper, as well as iperf. As with any software-based tool, the performance must be qualified to the link speed to be tested. Hardware-based test equipment should be considered for reliable results at higher link speeds (e.g., 1 GigE, 10 GigE).
iperf是TCP批量传输测试的最佳选择，“netperf”开源工具提供了控制客户端和服务器请求/响应行为的能力。netperf包装工具是一个Python脚本，它同时运行多个netperf实例并聚合结果。附录A提供了netperf/netperf包装器以及iperf的概述。与任何基于软件的工具一样，性能必须符合要测试的链路速度。应考虑使用基于硬件的测试设备，以便在更高的链路速度下（例如，1 GigE、10 GigE）获得可靠的结果。
As mentioned in the goals of this framework, techniques are defined to specify TCP traffic test patterns to benchmark traffic management technique(s) and produce repeatable results. Some network devices, such as firewalls, will not process stateless test traffic; this is another reason why stateful TCP test traffic must be used.
如本框架的目标所述，定义了用于指定TCP流量测试模式以基准流量管理技术并产生可重复结果的技术。一些网络设备，如防火墙，将不会处理无状态测试流量；这是必须使用有状态TCP测试流量的另一个原因。
An application could be fully emulated up to Layer 7; however, this framework proposes that stateful TCP test patterns be used in order to provide granular and repeatable control for the benchmarks. The following diagram illustrates a simple web-browsing application (HTTP).
应用程序可以完全模拟到第7层；然而，该框架建议使用有状态TCP测试模式，以便为基准测试提供粒度和可重复的控制。下图演示了一个简单的web浏览应用程序（HTTP）。
GET URL
获取URL
Client -------------------------> Web
|
Web 200 OK 100 ms |
|
Browser <------------------------- Server
Client -------------------------> Web
|
Web 200 OK 100 ms |
|
Browser <------------------------- Server
Figure 3: Simple Flow Diagram for a Web Application
图3：Web应用程序的简单流程图
In this example, the Client Web Browser (client) requests a URL, and then the Web Server delivers the web page content to the client (after a server delay of 100 milliseconds). This asynchronous "request/response" behavior is intrinsic to most TCP-based applications, such as email (SMTP), file transfers (FTP and Server Message Block (SMB)), database (SQL), web applications (SOAP), and Representational State Transfer (REST). The impact on the network elements is due to the multitudes of clients and the variety of bursty traffic, which stress traffic management functions. The actual emulation of the specific application protocols is not required, and TCP test patterns can be defined to mimic the application network traffic flows and produce repeatable results.
在本例中，客户端Web浏览器（客户端）请求URL，然后Web服务器将网页内容交付给客户端（在服务器延迟100毫秒后）。这种异步“请求/响应”行为是大多数基于TCP的应用程序固有的，例如电子邮件（SMTP）、文件传输（FTP和服务器消息块（SMB））、数据库（SQL）、web应用程序（SOAP）和表示性状态传输（REST）。对网元的影响是由于客户端的数量众多和突发流量的多样性，这给流量管理功能带来了压力。不需要对特定应用程序协议进行实际仿真，可以定义TCP测试模式来模拟应用程序网络流量并产生可重复的结果。
Application modeling techniques have been proposed in [3GPP2-C_R1002-A], which provides examples to model the behavior of HTTP, FTP, and Wireless Application Protocol (WAP) applications at the TCP layer. The models have been defined with various mathematical distributions for the request/response bytes and inter-request gap times. The model definition formats described in [3GPP2-C_R1002-A] are the basis for the guidelines provided in Appendix B and are also similar to formats used by network modeling tools. Packet captures can also be used to characterize application traffic and specify some of the test patterns listed in Appendix B.
[3GPP2-C_R1002-A]中提出了应用程序建模技术，该技术提供了在TCP层对HTTP、FTP和无线应用程序协议（WAP）应用程序行为建模的示例。这些模型已定义为请求/响应字节和请求间隔时间的各种数学分布。[3GPP2-C_R1002-A]中描述的模型定义格式是附录B中提供的指南的基础，并且与网络建模工具使用的格式类似。数据包捕获还可用于描述应用程序流量，并指定附录B中列出的一些测试模式。
This framework does not specify a fixed set of TCP test patterns but does provide test cases that SHOULD be performed; see Appendix B. Some of these examples reflect those specified in [CA-Benchmark], which suggests traffic mixes for a variety of representative application profiles. Other examples are simply well-known application traffic types such as HTTP.
该框架没有指定一组固定的TCP测试模式，但提供了应该执行的测试用例；参见附录B。其中一些示例反映了[CA Benchmark]中规定的示例，该示例建议了各种代表性应用程序配置文件的流量混合。其他示例只是众所周知的应用程序流量类型，如HTTP。
The traffic benchmarking methodology uses the test setup from Section 1.2 and metrics defined in Section 4.
流量基准测试方法使用第1.2节中的测试设置和第4节中定义的指标。
Each test SHOULD compare the network device's internal statistics (available via command line management interface, SNMP, etc.) to the measured metrics defined in Section 4. This evaluates the accuracy of the internal traffic management counters under individual test conditions and capacity test conditions as defined in Sections 4.1 and 4.2. This comparison is not intended to compare real-time statistics, but rather the cumulative statistics reported after the test has completed and device counters have updated (it is common for device counters to update after an interval of 10 seconds or more).
每个测试都应将网络设备的内部统计数据（通过命令行管理界面、SNMP等提供）与第4节中定义的测量指标进行比较。这评估了内部交通管理计数器在第4.1节和第4.2节规定的单独测试条件和容量测试条件下的准确性。此比较不是为了比较实时统计数据，而是在测试完成且设备计数器更新后报告的累积统计数据（设备计数器通常在10秒或更长时间间隔后更新）。
From a device configuration standpoint, scheduling and shaping functionality can be applied to logical ports (e.g., Link Aggregation (LAG)). This would result in the same scheduling and shaping configuration applied to all of the member physical ports. The focus of this document is only on tests at a physical-port level.
从设备配置的角度来看，调度和成形功能可应用于逻辑端口（例如，链路聚合（LAG））。这将导致应用于所有成员物理端口的相同调度和成形配置。本文档的重点仅在于物理端口级别的测试。
The following sections provide the objective, procedure, metrics, and reporting format for each test. For all test steps, the following global parameters must be specified:
以下各节提供了每个测试的目标、程序、指标和报告格式。对于所有测试步骤，必须指定以下全局参数：
Test Runs (Tr): The number of times the test needs to be run to ensure accurate and repeatable results. The recommended value is a minimum of 10.
测试运行（Tr）：为确保结果准确且可重复，需要运行测试的次数。建议值至少为10。
Test Duration (Td): The duration of a test iteration, expressed in seconds. The recommended minimum value is 60 seconds.
测试持续时间（Td）：测试迭代的持续时间，以秒为单位。建议的最小值为60秒。
The variability in the test results MUST be measured between test runs, and if the variation is characterized as a significant portion of the measured values, the next step may be to revise the methods to achieve better consistency.
测试结果的可变性必须在测试运行之间进行测量，如果变化被描述为测量值的重要部分，则下一步可能是修改方法以实现更好的一致性。
A policer is defined as the entity performing the policy function. The intent of the policing tests is to verify the policer performance (i.e., CIR/CBS and EIR/EBS parameters). The tests will verify that the network device can handle the CIR with CBS and the EIR with EBS, and will use back-to-back packet-testing concepts as described in [RFC2544] (but adapted to burst size algorithms and terminology). Also, [MEF-14], [MEF-19], and [MEF-37] provide some bases for
policer被定义为执行策略功能的实体。策略测试的目的是验证策略性能（即CIR/CBS和EIR/EBS参数）。测试将验证网络设备可以使用CBS处理CIR，使用EBS处理EIR，并将使用[RFC2544]中描述的背对背数据包测试概念（但适用于突发大小算法和术语）。此外，[MEF-14]、[MEF-19]和[MEF-37]也提供了一些基础
specific components of this test. The burst hunt algorithm defined in Section 5.1.1 can also be used to automate the measurement of the CBS value.
本测试的特定组件。第5.1.1节中定义的突发搜索算法也可用于自动测量CBS值。
The tests are divided into two (2) sections: individual policer tests and then full-capacity policing tests. It is important to benchmark the basic functionality of the individual policer and then proceed into the fully rated capacity of the device. This capacity may include the number of policing policies per device and the number of policers simultaneously active across all ports.
这些测试分为两（2）个部分：单个警察测试，然后是全容量警察测试。重要的是对单个policer的基本功能进行基准测试，然后进入设备的完全额定容量。此容量可能包括每个设备的策略数量和所有端口上同时活动的策略数量。
Objective: Test a policer as defined by [RFC4115] or [MEF-10.3], depending upon the equipment's specification. In addition to verifying that the policer allows the specified CBS and EBS bursts to pass, the policer test MUST verify that the policer will remark or drop excess packets, and pass traffic at the specified CBS/EBS values.
目标：根据设备规格，测试[RFC4115]或[MEF-10.3]定义的警察。除了验证policr是否允许指定的CBS和EBS突发通过外，policr测试还必须验证policr是否会标记或丢弃多余的数据包，并以指定的CBS/EBS值通过流量。
Test Summary: Policing tests should use stateless traffic. Stateful TCP test traffic will generally be adversely affected by a policer in the absence of traffic shaping. So, while TCP traffic could be used, it is more accurate to benchmark a policer with stateless traffic.
测试摘要：监控测试应该使用无状态流量。在没有流量整形的情况下，有状态TCP测试流量通常会受到策略的不利影响。因此，虽然可以使用TCP流量，但使用无状态流量对policer进行基准测试更为准确。
As an example of a policer as defined by [RFC4115], consider a CBS/EBS of 64 KB and CIR/EIR of 100 Mbps on a 1 GigE physical link (in color-blind mode). A stateless traffic burst of 64 KB would be sent into the policer at the GigE rate. This equates to an approximately 0.512-millisecond burst time (64 KB at 1 GigE). The traffic generator must space these bursts to ensure that the aggregate throughput does not exceed the CIR. The Ti between the bursts would equal CBS * 8 / CIR = 5.12 milliseconds in this example.
作为由[RCF4115]定义的警官的示例，考虑在1千兆物理链路（色盲模式）上的64 kb的CBS/EBS和100 Mbps的CIR／EIR。64 KB的无状态流量突发将以GigE速率发送到policr。这相当于大约0.512毫秒的突发时间（1千兆字节时为64 KB）。流量生成器必须对这些突发进行间隔，以确保聚合吞吐量不超过CIR。在本例中，突发之间的Ti将等于CBS*8/CIR=5.12毫秒。
Test Metrics: The metrics defined in Section 4.1 (BSA, LP, OOS, PD, and PDV) SHALL be measured at the egress port and recorded.
测试指标：第4.1节（BSA、LP、OOS、PD和PDV）中定义的指标应在出口处测量并记录。
Procedure: 1. Configure the DUT policing parameters for the desired CIR/EIR and CBS/EBS values to be tested.
程序：1。为要测试的所需CIR/EIR和CBS/EBS值配置DUT监控参数。
2. Configure the tester to generate a stateless traffic burst equal to CBS and an interval equal to Ti (CBS in bits/CIR).
2. 配置测试仪以生成等于CBS的无状态流量突发，间隔等于Ti（以位/CIR表示的CBS）。
3. Compliant Traffic Test: Generate bursts of CBS + EBS traffic into the policer ingress port, and measure the metrics defined in Section 4.1 (BSA, LP, OOS, PD, and PDV) at the egress port and across the entire Td (default 60-second duration).
3. 合规流量测试：生成进入policr入口端口的CBS+EBS流量突发，并在出口端口和整个Td（默认60秒持续时间）测量第4.1节中定义的指标（BSA、LP、OOS、PD和PDV）。
4. Excess Traffic Test: Generate bursts of greater than CBS + EBS bytes into the policer ingress port, and verify that the policer only allowed the BSA bytes to exit the egress. The excess burst MUST be recorded; the recommended value is 1000 bytes. Additional tests beyond the simple color-blind example might include color-aware mode, configurations where EIR is greater than CIR, etc.
4. 过量流量测试：向policr入口端口生成大于CBS+EBS字节的突发，并验证policr仅允许BSA字节退出出口。必须记录过多的脉冲串；建议的值为1000字节。除了简单的色盲示例之外的其他测试可能包括颜色感知模式、EIR大于CIR的配置等。
Reporting Format: The policer individual report MUST contain all results for each CIR/EIR/CBS/EBS test run. A recommended format is as follows:
报告格式：policr单个报告必须包含每个CIR/EIR/CBS/EBS测试运行的所有结果。建议的格式如下：
***********************************************************
***********************************************************
Test Configuration Summary: Tr, Td
测试配置概要：Tr，Td
DUT Configuration Summary: CIR, EIR, CBS, EBS
DUT配置概要：CIR、EIR、CBS、EBS
The results table should contain entries for each test run, as follows (Test #1 to Test #Tr):
结果表应包含每个测试运行的条目，如下所示（test#1到test#Tr）：
- Compliant Traffic Test: BSA, LP, OOS, PD, and PDV
- 符合要求的流量测试：BSA、LP、OOS、PD和PDV
- Excess Traffic Test: BSA
- 超额流量测试：BSA
***********************************************************
***********************************************************
Objective: The intent of the capacity tests is to verify the policer performance in a scaled environment with multiple ingress customer policers on multiple physical ports. This test will benchmark the maximum number of active policers as specified by the device manufacturer.
目标：容量测试的目的是验证在多个物理端口上具有多个入口客户策略的扩展环境中的策略性能。此测试将根据设备制造商的规定，对最大数量的活动策略进行基准测试。
Test Summary: The specified policing function capacity is generally expressed in terms of the number of policers active on each individual physical port as well as the number of unique policer rates that are utilized. For all of the capacity tests, the benchmarking test
测试摘要：指定的策略功能容量通常表示为每个物理端口上活动的策略数以及使用的唯一策略速率数。对于所有容量测试，基准测试
procedure and reporting format described in Section 6.1.1 for a single policer MUST be applied to each of the physical-port policers.
第6.1.1节中描述的单个策略的程序和报告格式必须应用于每个物理端口策略。
For example, a Layer 2 switching device may specify that each of the 32 physical ports can be policed using a pool of policing service policies. The device may carry a single customer's traffic on each physical port, and a single policer is instantiated per physical port. Another possibility is that a single physical port may carry multiple customers, in which case many customer flows would be policed concurrently on an individual physical port (separate policers per customer on an individual port).
例如，第2层交换设备可以指定32个物理端口中的每一个都可以使用一组策略服务策略进行策略。设备可以在每个物理端口上承载单个客户的流量，并且每个物理端口实例化一个policer。另一种可能性是单个物理端口可能承载多个客户，在这种情况下，多个客户流将在单个物理端口上同时受到监控（单个端口上每个客户有单独的监控）。
Test Metrics: The metrics defined in Section 4.1 (BSA, LP, OOS, PD, and PDV) SHALL be measured at the egress port and recorded.
测试指标：第4.1节（BSA、LP、OOS、PD和PDV）中定义的指标应在出口处测量并记录。
The following sections provide the specific test scenarios, procedures, and reporting formats for each policer capacity test.
以下各节提供了每个policer容量测试的特定测试场景、程序和报告格式。
Test Summary: The first policer capacity test will benchmark a single physical port, with maximum policers on that physical port.
测试摘要：第一个policr容量测试将对单个物理端口进行基准测试，该物理端口上有最大policr。
Assume multiple categories of ingress policers at rates r1, r2, ..., rn. There are multiple customers on a single physical port. Each customer could be represented by a single-tagged VLAN, a double-tagged VLAN, a Virtual Private LAN Service (VPLS) instance, etc. Each customer is mapped to a different policer. Each of the policers can be of rates r1, r2, ..., rn.
假设多类入口策略的速率为r1、r2、…、rn。一个物理端口上有多个客户。每个客户可以由单个标记的VLAN、双标记的VLAN、虚拟专用LAN服务（VPLS）实例等表示。每个客户都映射到不同的策略。每个策略的速率可以是r1、r2、…、rn。
An example configuration would be
一个示例配置是
- Y1 customers, policer rate r1
- Y1客户，警察费率r1
- Y2 customers, policer rate r2
- Y2客户，警察费率r2
- Y3 customers, policer rate r3
- Y3客户，警察费率r3
...
...
- Yn customers, policer rate rn
- Yn客户、警察费率rn
Some bandwidth on the physical port is dedicated for other traffic (i.e., other than customer traffic); this includes network control protocol traffic. There is a separate policer for the other traffic. Typical deployments have three categories of policers; there may be some deployments with more or less than three categories of ingress policers.
物理端口上的某些带宽专用于其他流量（即，客户流量除外）；这包括网络控制协议流量。对于其他流量，有一个单独的警察。典型部署有三类警察；有些部署可能具有多于或少于三种类型的入口策略。
Procedure: 1. Configure the DUT policing parameters for the desired CIR/EIR and CBS/EBS values for each policer rate (r1-rn) to be tested.
程序：1。为要测试的每个策略速率（r1 rn）的所需CIR/EIR和CBS/EBS值配置DUT策略参数。
2. Configure the tester to generate a stateless traffic burst equal to CBS and an interval equal to Ti (CBS in bits/CIR) for each customer stream (Y1-Yn). The encapsulation for each customer must also be configured according to the service tested (VLAN, VPLS, IP mapping, etc.).
2. 配置测试仪，以便为每个客户流（Y1 Yn）生成等于CBS的无状态流量突发，以及等于Ti（以位/CIR表示的CBS）的间隔。还必须根据测试的服务（VLAN、VPLS、IP映射等）配置每个客户的封装。
3. Compliant Traffic Test: Generate bursts of CBS + EBS traffic into the policer ingress port for each customer traffic stream, and measure the metrics defined in Section 4.1 (BSA, LP, OOS, PD, and PDV) at the egress port for each stream and across the entire Td (default 30-second duration).
3. 合规流量测试：为每个客户流量流生成进入policr入口端口的CBS+EBS流量突发，并在每个流的出口端口和整个Td（默认30秒持续时间）测量第4.1节中定义的指标（BSA、LP、OOS、PD和PDV）。
4. Excess Traffic Test: Generate bursts of greater than CBS + EBS bytes into the policer ingress port for each customer traffic stream, and verify that the policer only allowed the BSA bytes to exit the egress for each stream. The excess burst MUST be recorded; the recommended value is 1000 bytes.
4. 过量流量测试：为每个客户流量流向policr入口端口生成大于CBS+EBS字节的突发，并验证policr仅允许每个流的BSA字节退出出口。必须记录过多的脉冲串；建议的值为1000字节。
Reporting Format: The policer individual report MUST contain all results for each CIR/EIR/CBS/EBS test run, per customer traffic stream. A recommended format is as follows:
报告格式：policr单独报告必须包含每个客户流量流的每个CIR/EIR/CBS/EBS测试运行的所有结果。建议的格式如下：
*****************************************************************
*****************************************************************
Test Configuration Summary: Tr, Td
测试配置概要：Tr，Td
Customer Traffic Stream Encapsulation: Map each stream to VLAN, VPLS, IP address
客户流量流封装：将每个流映射到VLAN、VPLS、IP地址
DUT Configuration Summary per Customer Traffic Stream: CIR, EIR, CBS, EBS
每个客户流量流的DUT配置摘要：CIR、EIR、CBS、EBS
The results table should contain entries for each test run, as follows (Test #1 to Test #Tr):
结果表应包含每个测试运行的条目，如下所示（test#1到test#Tr）：
- Customer Stream Y1-Yn (see note) Compliant Traffic Test: BSA, LP, OOS, PD, and PDV
- 客户流Y1 Yn（见注释）符合流量测试：BSA、LP、OOS、PD和PDV
- Customer Stream Y1-Yn (see note) Excess Traffic Test: BSA
- 客户流Y1 Yn（见注释）超额流量测试：BSA
*****************************************************************
*****************************************************************
Note: For each test run, there will be two (2) rows for each customer stream: the Compliant Traffic Test result and the Excess Traffic Test result.
注意：对于每个测试运行，每个客户流将有两（2）行：符合流量测试结果和超额流量测试结果。
Test Summary: The second policer capacity test involves a single policer function per physical port with all physical ports active. In this test, there is a single policer per physical port. The policer can have one of the rates r1, r2, ..., rn. All of the physical ports in the networking device are active.
测试摘要：第二个policer容量测试涉及每个物理端口一个policer函数，所有物理端口都处于活动状态。在这个测试中，每个物理端口只有一个policer。policer可以有一个速率r1、r2、…、rn。网络设备中的所有物理端口都处于活动状态。
Procedure: The procedure for this test is identical to the procedure listed in Section 6.1.1. The configured parameters must be reported per port, and the test report must include results per measured egress port.
程序：本试验程序与第6.1.1节所列程序相同。每个端口必须报告配置参数，测试报告必须包括每个测量出口端口的结果。
The third policer capacity test is a combination of the first and second capacity tests, i.e., maximum policers active per physical port and all physical ports active.
第三个policer容量测试是第一个和第二个容量测试的组合，即每个物理端口的最大活动policer和所有物理端口的活动policer。
Procedure: The procedure for this test is identical to the procedure listed in Section 6.1.2.1. The configured parameters must be reported per port, and the test report must include per-stream results per measured egress port.
程序：本试验程序与第6.1.2.1节所列程序相同。每个端口必须报告配置的参数，测试报告必须包括每个测量出口端口的每个流结果。
Queues and traffic scheduling are closely related in that a queue's priority dictates the manner in which the traffic scheduler transmits packets out of the egress port.
队列和流量调度密切相关，因为队列的优先级决定了流量调度器从出口端口发送数据包的方式。
Since device queues/buffers are generally an egress function, this test framework will discuss testing at the egress (although the technique can be applied to ingress-side queues).
由于设备队列/缓冲区通常是出口功能，因此该测试框架将讨论出口处的测试（尽管该技术可应用于入口侧队列）。
Similar to the policing tests, these tests are divided into two sections: individual queue/scheduler function tests and then full-capacity tests.
与策略测试类似，这些测试分为两个部分：单个队列/调度程序功能测试，然后是全容量测试。
The various types of scheduling techniques include FIFO, Strict Priority (SP) queuing, and Weighted Fair Queuing (WFQ), along with other variations. This test framework recommends testing with a minimum of three techniques, although benchmarking other device-scheduling algorithms is left to the discretion of the tester.
各种类型的调度技术包括FIFO、严格优先级（SP）队列和加权公平队列（WFQ）以及其他变体。该测试框架建议至少使用三种技术进行测试，尽管其他设备调度算法的基准测试由测试人员自行决定。
Objective: Verify that the configured queue and scheduling technique can handle stateless traffic bursts up to the queue depth.
目标：验证配置的队列和调度技术是否可以处理队列深度内的无状态流量突发。
Test Summary: A network device queue is memory based, unlike a policing function, which is token or credit based. However, the same concepts from Section 6.1 can be applied to testing network device queues.
测试摘要：网络设备队列是基于内存的，与基于令牌或信用的策略功能不同。但是，第6.1节中的相同概念可以应用于测试网络设备队列。
The device's network queue should be configured to the desired size in KB (i.e., Queue Length (QL)), and then stateless traffic should be transmitted to test this QL.
应将设备的网络队列配置为所需大小（KB）（即队列长度（QL）），然后应传输无状态流量以测试此QL。
A queue should be able to handle repetitive bursts with the transmission gaps proportional to the Bottleneck Bandwidth (BB). The transmission gap is referred to here as the transmission interval (Ti). The Ti can be defined for the traffic bursts and is based on the QL and BB of the egress interface.
队列应该能够处理传输间隔与瓶颈带宽（BB）成比例的重复突发。变速箱间隙在这里称为变速箱间隔（Ti）。Ti可针对流量突发进行定义，并基于出口接口的QL和BB。
Ti = QL * 8 / BB
Ti = QL * 8 / BB
Note that this equation is similar to the Ti required for transmission into a policer (QL = CBS, BB = CIR). Note also that the burst hunt algorithm defined in Section 5.1.1 can also be used to automate the measurement of the queue value.
注意，该等式类似于传输到policer所需的Ti（QL=CBS，BB=CIR）。还请注意，第5.1.1节中定义的突发搜索算法也可用于自动测量队列值。
The stateless traffic burst SHALL be transmitted at the link speed and spaced within the transmission interval (Ti). The metrics defined in Section 4.1 SHALL be measured at the egress port and recorded; the primary intent is to verify the BSA and verify that no packets are dropped.
无状态流量突发应以链路速度传输，并在传输间隔（Ti）内隔开。应在出口处测量并记录第4.1节中规定的指标；主要目的是验证BSA，并验证没有丢包。
The scheduling function must also be characterized to benchmark the device's ability to schedule the queues according to the priority. An example would be two levels of priority that include SP and FIFO queuing. Under a flow load greater than the egress port speed, the higher-priority packets should be transmitted without drops (and also maintain low latency), while the lower-priority (or best-effort) queue may be dropped.
调度功能还必须具有一定的特征，以测试设备根据优先级调度队列的能力。例如，包括SP和FIFO队列的两级优先级。在流量负载大于出口端口速度的情况下，应在不丢弃的情况下传输较高优先级的数据包（并保持较低的延迟），而可丢弃较低优先级（或尽力而为）的队列。
Test Metrics: The metrics defined in Section 4.1 (BSA, LP, OOS, PD, and PDV) SHALL be measured at the egress port and recorded.
测试指标：第4.1节（BSA、LP、OOS、PD和PDV）中定义的指标应在出口处测量并记录。
Procedure: 1. Configure the DUT QL and scheduling technique parameters (FIFO, SP, etc.).
程序：1。配置DUT QL和调度技术参数（FIFO、SP等）。
2. Configure the tester to generate a stateless traffic burst equal to QL and an interval equal to Ti (QL in bits/BB).
2. 配置测试仪以生成等于QL的无状态流量突发，间隔等于Ti（QL以位/BB表示）。
3. Generate bursts of QL traffic into the DUT, and measure the metrics defined in Section 4.1 (LP, OOS, PD, and PDV) at the egress port and across the entire Td (default 30-second duration).
3. 生成进入DUT的QL流量突发，并在出口端口和整个Td（默认30秒持续时间）测量第4.1节中定义的度量（LP、OOS、PD和PDV）。
Reporting Format: The Queue/Scheduler Stateless Traffic individual report MUST contain all results for each QL/BB test run. A recommended format is as follows:
报告格式：队列/计划程序无状态流量单独报告必须包含每个QL/BB测试运行的所有结果。建议的格式如下：
****************************************************************
****************************************************************
Test Configuration Summary: Tr, Td
测试配置概要：Tr，Td
DUT Configuration Summary: Scheduling technique (i.e., FIFO, SP, WFQ, etc.), BB, and QL
DUT配置概要：调度技术（即FIFO、SP、WFQ等）、BB和QL
The results table should contain entries for each test run, as follows (Test #1 to Test #Tr):
结果表应包含每个测试运行的条目，如下所示（test#1到test#Tr）：
- LP, OOS, PD, and PDV
- LP、OOS、PD和PDV
****************************************************************
****************************************************************
Objective: Verify that the configured queue and scheduling technique can handle stateful traffic bursts up to the queue depth.
目标：验证配置的队列和调度技术是否能够处理高达队列深度的有状态流量突发。
Test Background and Summary: To provide a more realistic benchmark and to test queues in Layer 4 devices such as firewalls, stateful traffic testing is recommended for the queue tests. Stateful traffic tests will also utilize the Network Delay Emulator (NDE) from the network setup configuration in Section 1.2.
测试背景和总结：为了提供更现实的基准测试，并测试第4层设备（如防火墙）中的队列，建议对队列测试进行有状态流量测试。有状态流量测试还将利用第1.2节网络设置配置中的网络延迟模拟器（NDE）。
The BDP of the TCP test traffic must be calibrated to the QL of the device queue. Referencing [RFC6349], the BDP is equal to:
TCP测试流量的BDP必须校准为设备队列的QL。参考[RFC6349]，BDP等于：
BB * RTT / 8 (in bytes)
BB*RTT/8（字节）
The NDE must be configured to an RTT value that is large enough to allow the BDP to be greater than QL. An example test scenario is defined below:
NDE必须配置为RTT值，该RTT值足够大，以允许BDP大于QL。下面定义了一个示例测试场景：
- Ingress link = GigE
- 入口链路=GigE
- Egress link = 100 Mbps (BB)
- 出口链路=100 Mbps（BB）
- QL = 32 KB
- QL=32 KB
RTT(min) = QL * 8 / BB and would equal 2.56 ms
(and the BDP = 32 KB)
RTT(min) = QL * 8 / BB and would equal 2.56 ms
(and the BDP = 32 KB)
In this example, one (1) TCP connection with window size / SSB of 32 KB would be required to test the QL of 32 KB. This Bulk Transfer Test can be accomplished using iperf, as described in Appendix A.
在本例中，需要一（1）个窗口大小/SSB为32KB的TCP连接来测试32KB的QL。如附录A所述，可使用iperf完成批量转移试验。
Two types of TCP tests MUST be performed: the Bulk Transfer Test and the Micro Burst Test Pattern, as documented in Appendix B. The Bulk Transfer Test only bursts during the TCP Slow Start (or Congestion Avoidance) state, while the Micro Burst Test Pattern emulates application-layer bursting, which may occur any time during the TCP connection.
必须执行两种类型的TCP测试：批量传输测试和微突发测试模式，如附录B中所述。批量传输测试仅在TCP慢速启动（或拥塞避免）状态下突发，而微突发测试模式模拟应用层突发，这可能在TCP连接期间随时发生。
Other types of tests SHOULD include the following: simple web sites, complex web sites, business applications, email, and SMB/CIFS (Common Internet File System) file copy (all of which are also documented in Appendix B).
其他类型的测试应包括以下内容：简单网站、复杂网站、业务应用程序、电子邮件和SMB/CIFS（通用Internet文件系统）文件副本（所有这些内容也记录在附录B中）。
Test Metrics: The test results will be recorded per the stateful metrics defined in Section 4.2 -- primarily the TCP Test Pattern Execution Time (TTPET), TCP Efficiency, and Buffer Delay.
测试指标：将根据第4.2节中定义的有状态指标记录测试结果——主要是TCP测试模式执行时间（TTPET）、TCP效率和缓冲区延迟。
Procedure: 1. Configure the DUT QL and scheduling technique parameters (FIFO, SP, etc.).
程序：1。配置DUT QL和调度技术参数（FIFO、SP等）。
2. Configure the test generator* with a profile of an emulated application traffic mixture.
2. 使用模拟应用程序流量混合的配置文件配置测试生成器*。
- The application mixture MUST be defined in terms of percentage of the total bandwidth to be tested.
- 必须根据待测试总带宽的百分比定义应用程序混合。
- The rate of transmission for each application within the mixture MUST also be configurable.
- 混合物中每个应用的传输速率也必须是可配置的。
* To ensure repeatable results, the test generator MUST be capable of generating precise TCP test patterns for each application specified.
* 为了确保可重复的结果，测试生成器必须能够为每个指定的应用程序生成精确的TCP测试模式。
3. Generate application traffic between the ingress (client side) and egress (server side) ports of the DUT, and measure the metrics (TTPET, TCP Efficiency, and Buffer Delay) per application stream and at the ingress and egress ports (across the entire Td, default 60-second duration).
3. 在DUT的入口（客户端）和出口（服务器端）端口之间生成应用程序通信量，并测量每个应用程序流以及入口和出口端口处的度量（TTPET、TCP效率和缓冲区延迟）（在整个Td中，默认持续时间为60秒）。
A couple of items require clarification concerning application measurements: an application session may be comprised of a single TCP connection or multiple TCP connections.
关于应用程序度量，有两项需要澄清：应用程序会话可能由单个TCP连接或多个TCP连接组成。
If an application session utilizes a single TCP connection, the application throughput/metrics have a 1-1 relationship to the TCP connection measurements.
如果应用程序会话使用单个TCP连接，则应用程序吞吐量/度量值与TCP连接度量值具有1-1关系。
If an application session (e.g., an HTTP-based application) utilizes multiple TCP connections, then all of the TCP connections are aggregated in the application throughput measurement/metrics for that application.
如果应用程序会话（例如，基于HTTP的应用程序）使用多个TCP连接，则所有TCP连接都将聚合到该应用程序的应用程序吞吐量度量/指标中。
Then, there is the case of multiple instances of an application session (i.e., multiple FTPs emulating multiple clients). In this situation, the test should measure/record each FTP application session independently, tabulating the minimum, maximum, and average for all FTP sessions.
然后，存在应用程序会话的多个实例的情况（即，多个FTP模拟多个客户端）。在这种情况下，测试应该独立地测量/记录每个FTP应用程序会话，将所有FTP会话的最小值、最大值和平均值制成表格。
Finally, application throughput measurements are based on Layer 4 TCP throughput and do not include bytes retransmitted. The TCP Efficiency metric MUST be measured during the test, because it provides a measure of "goodput" during each test.
最后，应用程序吞吐量测量基于第4层TCP吞吐量，不包括重新传输的字节。TCP效率度量必须在测试期间进行测量，因为它在每个测试期间提供了“goodput”的度量。
Reporting Format: The Queue/Scheduler Stateful Traffic individual report MUST contain all results for each traffic scheduler and QL/BB test run. A recommended format is as follows:
报告格式：队列/调度器有状态流量单独报告必须包含每个流量调度器和QL/BB测试运行的所有结果。建议的格式如下：
******************************************************************
******************************************************************
Test Configuration Summary: Tr, Td
测试配置概要：Tr，Td
DUT Configuration Summary: Scheduling technique (i.e., FIFO, SP, WFQ, etc.), BB, and QL
DUT配置概要：调度技术（即FIFO、SP、WFQ等）、BB和QL
Application Mixture and Intensities: These are the percentages configured for each application type.
应用混合和强度：这些是为每种应用类型配置的百分比。
The results table should contain entries for each test run, with minimum, maximum, and average per application session, as follows (Test #1 to Test #Tr):
结果表应包含每个测试运行的条目，以及每个应用程序会话的最小值、最大值和平均值，如下所示（test#1到test#Tr）：
- Throughput (bps) and TTPET for each application session
- 每个应用程序会话的吞吐量（bps）和TTPET
- Bytes In and Bytes Out for each application session
- 每个应用程序会话的字节输入和字节输出
- TCP Efficiency and Buffer Delay for each application session
- 每个应用程序会话的TCP效率和缓冲区延迟
******************************************************************
******************************************************************
Objective: The intent of these capacity tests is to benchmark queue/scheduler performance in a scaled environment with multiple queues/schedulers active on multiple egress physical ports. These tests will benchmark the maximum number of queues and schedulers as specified by the device manufacturer. Each priority in the system will map to a separate queue.
目标：这些容量测试的目的是在多个出口物理端口上有多个活动队列/调度器的扩展环境中对队列/调度器的性能进行基准测试。这些测试将根据设备制造商的规定，对队列和调度程序的最大数量进行基准测试。系统中的每个优先级将映射到一个单独的队列。
Test Metrics: The metrics defined in Section 4.1 (BSA, LP, OOS, PD, and PDV) SHALL be measured at the egress port and recorded.
测试指标：第4.1节（BSA、LP、OOS、PD和PDV）中定义的指标应在出口处测量并记录。
The following sections provide the specific test scenarios, procedures, and reporting formats for each queue/scheduler capacity test.
以下各节提供了每个队列/调度器容量测试的特定测试场景、过程和报告格式。
For the first queue/scheduler capacity test, multiple queues per port will be tested on a single physical port. In this case, all of the queues (typically eight) are active on a single physical port. Traffic from multiple ingress physical ports is directed to the same egress physical port. This will cause oversubscription on the egress physical port.
对于第一个队列/调度程序容量测试，将在单个物理端口上测试每个端口的多个队列。在这种情况下，所有队列（通常为八个）都在单个物理端口上处于活动状态。来自多个入口物理端口的流量被定向到同一个出口物理端口。这将导致出口物理端口上的超额订阅。
There are many types of priority schemes and combinations of priorities that are managed by the scheduler. The following sections specify the priority schemes that should be tested.
调度程序管理许多类型的优先级方案和优先级组合。以下各节规定了应测试的优先级方案。
Test Summary: For this test, SP scheduling on the egress physical port should be tested, and the benchmarking methodologies specified in Sections 6.2.1.1 (stateless) and 6.2.1.2 (stateful) (procedure, metrics, and reporting format) should be applied here. For a given priority, each ingress physical port should get a fair share of the egress physical-port bandwidth.
测试摘要：对于该测试，应测试出口物理端口上的SP调度，并应在此应用第6.2.1.1节（无状态）和第6.2.1.2节（有状态）（程序、度量和报告格式）中规定的基准测试方法。对于给定的优先级，每个入口物理端口应获得出口物理端口带宽的公平份额。
Since this is a capacity test, the configuration and report results format (see Sections 6.2.1.1 and 6.2.1.2) MUST also include:
由于这是一项容量测试，配置和报告结果格式（见第6.2.1.1和6.2.1.2节）还必须包括：
Configuration:
配置：
- The number of physical ingress ports active during the test
- 测试期间活动的物理入口端口数
- The classification marking (DSCP, VLAN, etc.) for each physical ingress port
- 每个物理入口端口的分类标记（DSCP、VLAN等）
- The traffic rate for stateful traffic and the traffic rate/mixture for stateful traffic for each physical ingress port
- 每个物理入口端口的有状态流量的流量率和有状态流量的流量率/混合
Report Results:
报告结果：
- For each ingress port traffic stream, the achieved throughput rate and metrics at the egress port
- 对于每个入口端口业务流，在出口端口实现的吞吐量和度量
Test Summary: For this test, SP and WFQ should be enabled simultaneously in the scheduler, but on a single egress port. The benchmarking methodologies specified in Sections 6.2.1.1 (stateless) and 6.2.1.2 (stateful) (procedure, metrics, and reporting format) should be applied here. Additionally, the egress port bandwidth-sharing among weighted queues should be proportional to the assigned weights. For a given priority, each ingress physical port should get a fair share of the egress physical-port bandwidth.
测试摘要：对于此测试，SP和WFQ应在调度程序中同时启用，但在单个出口端口上启用。此处应采用第6.2.1.1节（无状态）和第6.2.1.2节（有状态）（程序、指标和报告格式）中规定的基准方法。此外，加权队列之间的出口端口带宽共享应与分配的权重成比例。对于给定的优先级，每个入口物理端口应获得出口物理端口带宽的公平份额。
Since this is a capacity test, the configuration and report results format (see Sections 6.2.1.1 and 6.2.1.2) MUST also include:
由于这是一项容量测试，配置和报告结果格式（见第6.2.1.1和6.2.1.2节）还必须包括：
Configuration:
配置：
- The number of physical ingress ports active during the test
- 测试期间活动的物理入口端口数
- The classification marking (DSCP, VLAN, etc.) for each physical ingress port
- 每个物理入口端口的分类标记（DSCP、VLAN等）
- The traffic rate for stateful traffic and the traffic rate/mixture for stateful traffic for each physical ingress port
- 每个物理入口端口的有状态流量的流量率和有状态流量的流量率/混合
Report Results:
报告结果：
- For each ingress port traffic stream, the achieved throughput rate and metrics at each queue of the egress port queue (both the SP and WFQ)
- 对于每个入口端口业务流，在出口端口队列（SP和WFQ）的每个队列上实现的吞吐量和度量
Example:
例子：
- Egress Port SP Queue: throughput and metrics for ingress streams 1-n
- 出口端口SP队列：入口流的吞吐量和度量1-n
- Egress Port WFQ: throughput and metrics for ingress streams 1-n
- 出口端口WFQ：入口流1-n的吞吐量和指标
Test Summary: Traffic from multiple ingress physical ports is directed to the same egress physical port. This will cause oversubscription on the egress physical port. Also, the same amount of traffic is directed to each egress physical port.
测试摘要：来自多个入口物理端口的流量被定向到同一个出口物理端口。这将导致出口物理端口上的超额订阅。此外，相同数量的流量被定向到每个出口物理端口。
The benchmarking methodologies specified in Sections 6.2.1.1 (stateless) and 6.2.1.2 (stateful) (procedure, metrics, and reporting format) should be applied here. Each ingress physical port should get a fair share of the egress physical-port bandwidth. Additionally, each egress physical port should receive the same amount of traffic.
此处应采用第6.2.1.1节（无状态）和第6.2.1.2节（有状态）（程序、指标和报告格式）中规定的基准方法。每个入口物理端口应获得出口物理端口带宽的公平份额。此外，每个出口物理端口应接收相同数量的流量。
Since this is a capacity test, the configuration and report results format (see Sections 6.2.1.1 and 6.2.1.2) MUST also include:
由于这是一项容量测试，配置和报告结果格式（见第6.2.1.1和6.2.1.2节）还必须包括：
Configuration:
配置：
- The number of ingress ports active during the test
- 测试期间活动的入口端口数
- The number of egress ports active during the test
- 测试期间活动的出口端口数
- The classification marking (DSCP, VLAN, etc.) for each physical ingress port
- 每个物理入口端口的分类标记（DSCP、VLAN等）
- The traffic rate for stateful traffic and the traffic rate/mixture for stateful traffic for each physical ingress port
- 每个物理入口端口的有状态流量的流量率和有状态流量的流量率/混合
Report Results:
报告结果：
- For each egress port, the achieved throughput rate and metrics at the egress port queue for each ingress port stream
- 对于每个出口端口，每个入口端口流在出口端口队列处实现的吞吐量和度量
Example:
例子：
- Egress Port 1: throughput and metrics for ingress streams 1-n
- 出口端口1：入口流1-n的吞吐量和指标
- Egress Port n: throughput and metrics for ingress streams 1-n
- 出口端口n：入口流1-n的吞吐量和度量
Test Summary: Traffic from multiple ingress physical ports is directed to all queues of each egress physical port. This will cause oversubscription on the egress physical ports. Also, the same amount of traffic is directed to each egress physical port.
测试摘要：来自多个入口物理端口的流量被定向到每个出口物理端口的所有队列。这将导致出口物理端口的超额订阅。此外，相同数量的流量被定向到每个出口物理端口。
The benchmarking methodologies specified in Sections 6.2.1.1 (stateless) and 6.2.1.2 (stateful) (procedure, metrics, and reporting format) should be applied here. For a given priority, each ingress physical port should get a fair share of the egress physical-port bandwidth. Additionally, each egress physical port should receive the same amount of traffic.
此处应采用第6.2.1.1节（无状态）和第6.2.1.2节（有状态）（程序、指标和报告格式）中规定的基准方法。对于给定的优先级，每个入口物理端口应获得出口物理端口带宽的公平份额。此外，每个出口物理端口应接收相同数量的流量。
Since this is a capacity test, the configuration and report results format (see Sections 6.2.1.1 and 6.2.1.2) MUST also include:
由于这是一项容量测试，配置和报告结果格式（见第6.2.1.1和6.2.1.2节）还必须包括：
Configuration:
配置：
- The number of physical ingress ports active during the test
- 测试期间活动的物理入口端口数
- The classification marking (DSCP, VLAN, etc.) for each physical ingress port
- 每个物理入口端口的分类标记（DSCP、VLAN等）
- The traffic rate for stateful traffic and the traffic rate/mixture for stateful traffic for each physical ingress port
- 每个物理入口端口的有状态流量的流量率和有状态流量的流量率/混合
Report Results:
报告结果：
- For each egress port, the achieved throughput rate and metrics at each egress port queue for each ingress port stream
- 对于每个出口端口，每个入口端口流的每个出口端口队列处的实现吞吐量和度量
Example:
例子：
- Egress Port 1, SP Queue: throughput and metrics for ingress streams 1-n
- 出口端口1，SP队列：入口流1-n的吞吐量和指标
- Egress Port 2, WFQ: throughput and metrics for ingress streams 1-n
- 出口端口2，WFQ：入口流1-n的吞吐量和指标
...
...
- Egress Port n, SP Queue: throughput and metrics for ingress streams 1-n
- 出口端口n，SP队列：入口流1-n的吞吐量和指标
- Egress Port n, WFQ: throughput and metrics for ingress streams 1-n
- 出口端口n，WFQ：入口流1-n的吞吐量和指标
Like a queue, a traffic shaper is memory based, but with the added intelligence of an active traffic scheduler. The same concepts as those described in Section 6.2 (queue testing) can be applied to testing a network device shaper.
与队列一样，流量整形器是基于内存的，但具有主动流量调度器的附加智能。第6.2节（队列测试）中描述的相同概念可用于测试网络设备整形器。
Again, the tests are divided into two sections: individual shaper benchmark tests and then full-capacity shaper benchmark tests.
同样，测试分为两个部分：单独的成型器基准测试，然后是全容量成型器基准测试。
A traffic shaper generally has three (3) components that can be configured:
流量整形器通常有三（3）个可配置的组件：
- Ingress Queue bytes
- 入口队列字节
- Shaper Rate (SR), bps
- 成型率（SR），bps
- Burst Committed (Bc) and Burst Excess (Be), bytes
- 突发提交（Bc）和突发过量（Be），字节
The Ingress Queue holds burst traffic, and the shaper then meters traffic out of the egress port according to the SR and Bc/Be parameters. Shapers generally transmit into policers, so the idea is for the emitted traffic to conform to the policer's limits.
入口队列持有突发流量，然后整形器根据SR和Bc/Be参数计量出出口端口的流量。整形器通常会传输到policer中，因此，我们的想法是让发出的流量符合policer的限制。
Objective: Test a shaper by transmitting stateless traffic bursts into the shaper ingress port and verifying that the egress traffic is shaped according to the shaper traffic profile.
目标：通过将无状态流量突发传输到整形器入口端口并验证出口流量是否根据整形器流量配置文件整形来测试整形器。
Test Summary: The stateless traffic must be burst into the DUT ingress port and not exceed the Ingress Queue. The burst can be a single burst or multiple bursts. If multiple bursts are transmitted, then the transmission interval (Ti) must be large enough so that the SR is not exceeded. An example will clarify single-burst and multiple-burst test cases.
测试摘要：无状态流量必须突发到DUT入口端口，并且不得超过入口队列。突发可以是单个突发或多个突发。如果传输多个突发，则传输间隔（Ti）必须足够大，以便不超过SR。一个示例将阐明单个突发和多个突发测试用例。
In this example, the shaper's ingress and egress ports are both full-duplex Gigabit Ethernet. The Ingress Queue is configured to be 512,000 bytes, the SR = 50 Mbps, and both Bc and Be are configured to be 32,000 bytes. For a single-burst test, the transmitting test device would burst 512,000 bytes maximum into the ingress port and then stop transmitting.
在此示例中，整形器的入口和出口端口都是全双工千兆以太网。入口队列配置为512000字节，SR=50 Mbps，Bc和be都配置为32000字节。对于单个突发测试，传输测试设备将向入口端口突发最大512000字节，然后停止传输。
If a multiple-burst test is to be conducted, then the burst bytes divided by the transmission interval between the 512,000-byte bursts must not exceed the SR. The transmission interval (Ti) must adhere to a formula similar to the formula described in Section 6.2.1.1 for queues, namely:
如果要进行多重突发测试，则突发字节除以512000字节突发之间的传输间隔不得超过SR。传输间隔（Ti）必须遵循与第6.2.1.1节中描述的队列公式类似的公式，即：
Ti = Ingress Queue * 8 / SR
Ti = Ingress Queue * 8 / SR
For the example from the previous paragraph, the Ti between bursts must be greater than 82 milliseconds (512,000 bytes * 8 / 50,000,000 bps). This yields an average rate of 50 Mbps so that an Ingress Queue would not overflow.
对于上一段中的示例，突发之间的Ti必须大于82毫秒（512000字节*8/50000000 bps）。这将产生50 Mbps的平均速率，以便入口队列不会溢出。
Test Metrics: The metrics defined in Section 4.1 (LP, OOS, PDV, SR, SBB, and SBI) SHALL be measured at the egress port and recorded.
测试指标：第4.1节（LP、OOS、PDV、SR、SBB和SBI）中定义的指标应在出口处测量并记录。
Procedure: 1. Configure the DUT shaper ingress QL and shaper egress rate parameters (SR, Bc, Be).
程序：1。配置DUT成形器入口QL和成形器出口速率参数（SR、Bc、Be）。
2. Configure the tester to generate a stateless traffic burst equal to QL and an interval equal to Ti (QL in bits/BB).
2. 配置测试仪以生成等于QL的无状态流量突发，间隔等于Ti（QL以位/BB表示）。
3. Generate bursts of QL traffic into the DUT, and measure the metrics defined in Section 4.1 (LP, OOS, PDV, SR, SBB, and SBI) at the egress port and across the entire Td (default 30-second duration).
3. 生成进入DUT的QL流量突发，并在出口端口和整个Td（默认30秒持续时间）测量第4.1节中定义的度量（LP、OOS、PDV、SR、SBB和SBI）。
Reporting Format: The Shaper Stateless Traffic individual report MUST contain all results for each QL/SR test run. A recommended format is as follows:
报告格式：Shaper无状态流量单独报告必须包含每个QL/SR测试运行的所有结果。建议的格式如下：
***********************************************************
***********************************************************
Test Configuration Summary: Tr, Td
测试配置概要：Tr，Td
DUT Configuration Summary: Ingress Burst Rate, QL, SR
DUT配置概要：入口突发速率、QL、SR
The results table should contain entries for each test run, as follows (Test #1 to Test #Tr):
结果表应包含每个测试运行的条目，如下所示（test#1到test#Tr）：
- LP, OOS, PDV, SR, SBB, and SBI
- LP、OOS、PDV、SR、SBB和SBI
***********************************************************
***********************************************************
Objective: Test a shaper by transmitting stateful traffic bursts into the shaper ingress port and verifying that the egress traffic is shaped according to the shaper traffic profile.
目标：通过将有状态流量突发传输到整形器入口端口并验证出口流量是否根据整形器流量配置文件整形，来测试整形器。
Test Summary: To provide a more realistic benchmark and to test queues in Layer 4 devices such as firewalls, stateful traffic testing is also recommended for the shaper tests. Stateful traffic tests will also utilize the Network Delay Emulator (NDE) from the network setup configuration in Section 1.2.
测试摘要：为了提供更真实的基准测试并测试第4层设备（如防火墙）中的队列，还建议对shaper测试进行有状态流量测试。有状态流量测试还将利用第1.2节网络设置配置中的网络延迟模拟器（NDE）。
The BDP of the TCP test traffic must be calculated as described in Section 6.2.1.2. To properly stress network buffers and the traffic-shaping function, the TCP window size (which is the minimum of the TCP RWND and sender socket) should be greater than the BDP, which will stress the shaper. BDP factors of 1.1 to 1.5 are recommended, but the values are left to the discretion of the tester and should be documented.
TCP测试流量的BDP必须按照第6.2.1.2节所述进行计算。要正确强调网络缓冲区和流量整形功能，TCP窗口大小（TCP RWND和发送方套接字的最小值）应大于BDP，这将强调整形器。建议BDP系数为1.1至1.5，但数值由测试人员自行决定，并应记录在案。
The cumulative TCP window sizes* (RWND at the receiving end and CWND at the transmitting end) equates to the TCP window size* for each connection, multiplied by the number of connections.
累积TCP窗口大小*（接收端的RWND和发送端的CWND）等于每个连接的TCP窗口大小*乘以连接数。
* As described in Section 3 of [RFC6349], the SSB MUST be large enough to fill the BDP.
* 如[RFC6349]第3节所述，SSB必须足够大，以填充BDP。
For example, if the BDP is equal to 256 KB and a connection size of 64 KB is used for each connection, then it would require four (4) connections to fill the BDP and 5-6 connections (oversubscribe the BDP) to stress-test the traffic-shaping function.
例如，如果BDP等于256 KB，并且每个连接使用64 KB的连接大小，则需要四（4）个连接来填充BDP，需要5-6个连接（过度订阅BDP）来对流量整形功能进行压力测试。
Two types of TCP tests MUST be performed: the Bulk Transfer Test and the Micro Burst Test Pattern, as documented in Appendix B. The Bulk Transfer Test only bursts during the TCP Slow Start (or Congestion Avoidance) state, while the Micro Burst Test Pattern emulates application-layer bursting, which may occur any time during the TCP connection.
必须执行两种类型的TCP测试：批量传输测试和微突发测试模式，如附录B中所述。批量传输测试仅在TCP慢速启动（或拥塞避免）状态下突发，而微突发测试模式模拟应用层突发，这可能在TCP连接期间随时发生。
Other types of tests SHOULD include the following: simple web sites, complex web sites, business applications, email, and SMB/CIFS file copy (all of which are also documented in Appendix B).
其他类型的测试应包括以下内容：简单网站、复杂网站、业务应用程序、电子邮件和SMB/CIFS文件副本（所有这些内容也记录在附录B中）。
Test Metrics: The test results will be recorded per the stateful metrics defined in Section 4.2 -- primarily the TCP Test Pattern Execution Time (TTPET), TCP Efficiency, and Buffer Delay.
测试指标：将根据第4.2节中定义的有状态指标记录测试结果——主要是TCP测试模式执行时间（TTPET）、TCP效率和缓冲区延迟。
Procedure: 1. Configure the DUT shaper ingress QL and shaper egress rate parameters (SR, Bc, Be).
程序：1。配置DUT成形器入口QL和成形器出口速率参数（SR、Bc、Be）。
2. Configure the test generator* with a profile of an emulated application traffic mixture.
2. 使用模拟应用程序流量混合的配置文件配置测试生成器*。
- The application mixture MUST be defined in terms of percentage of the total bandwidth to be tested.
- 必须根据待测试总带宽的百分比定义应用程序混合。
- The rate of transmission for each application within the mixture MUST also be configurable.
- 混合物中每个应用的传输速率也必须是可配置的。
* To ensure repeatable results, the test generator MUST be capable of generating precise TCP test patterns for each application specified.
* 为了确保可重复的结果，测试生成器必须能够为每个指定的应用程序生成精确的TCP测试模式。
3. Generate application traffic between the ingress (client side) and egress (server side) ports of the DUT, and measure the metrics (TTPET, TCP Efficiency, and Buffer Delay) per application stream and at the ingress and egress ports (across the entire Td, default 30-second duration).
3. 在DUT的入口（客户端）和出口（服务器端）端口之间生成应用程序通信量，并测量每个应用程序流以及入口和出口端口处的度量（TTPET、TCP效率和缓冲区延迟）（在整个Td中，默认持续30秒）。
Reporting Format: The Shaper Stateful Traffic individual report MUST contain all results for each traffic scheduler and QL/SR test run. A recommended format is as follows:
Reporting Format: The Shaper Stateful Traffic individual report MUST contain all results for each traffic scheduler and QL/SR test run. A recommended format is as follows:translate error, please retry
******************************************************************
******************************************************************
Test Configuration Summary: Tr, Td
测试配置概要：Tr，Td
DUT Configuration Summary: Ingress Burst Rate, QL, SR
DUT配置概要：入口突发速率、QL、SR
Application Mixture and Intensities: These are the percentages configured for each application type.
应用混合和强度：这些是为每种应用类型配置的百分比。
The results table should contain entries for each test run, with minimum, maximum, and average per application session, as follows (Test #1 to Test #Tr):
结果表应包含每个测试运行的条目，以及每个应用程序会话的最小值、最大值和平均值，如下所示（test#1到test#Tr）：
- Throughput (bps) and TTPET for each application session
- 每个应用程序会话的吞吐量（bps）和TTPET
- Bytes In and Bytes Out for each application session
- 每个应用程序会话的字节输入和字节输出
- TCP Efficiency and Buffer Delay for each application session
- 每个应用程序会话的TCP效率和缓冲区延迟
******************************************************************
******************************************************************
Objective: The intent of these scalability tests is to verify shaper performance in a scaled environment with shapers active on multiple queues on multiple egress physical ports. These tests will benchmark the maximum number of shapers as specified by the device manufacturer.
目标：这些可伸缩性测试的目的是在多个出口物理端口上的多个队列上的整形器处于活动状态的可伸缩环境中验证整形器的性能。这些测试将以设备制造商规定的最大整形器数量为基准。
The following sections provide the specific test scenarios, procedures, and reporting formats for each shaper capacity test.
以下各节提供了每个成型器容量测试的特定测试场景、程序和报告格式。
Test Summary: The first shaper capacity test involves per-port shaping with all physical ports active. Traffic from multiple ingress physical ports is directed to the same egress physical port. This will cause oversubscription on the egress physical port. Also, the same amount of traffic is directed to each egress physical port.
测试摘要：第一个整形器容量测试涉及所有物理端口都处于活动状态的每个端口整形。来自多个入口物理端口的流量被定向到同一个出口物理端口。这将导致出口物理端口上的超额订阅。此外，相同数量的流量被定向到每个出口物理端口。
The benchmarking methodologies specified in Sections 6.3.1.1 (stateless) and 6.3.1.2 (stateful) (procedure, metrics, and reporting format) should be applied here. Since this is a capacity test, the configuration and report results format (see Section 6.3.1) MUST also include:
此处应采用第6.3.1.1节（无状态）和第6.3.1.2节（有状态）（程序、指标和报告格式）中规定的基准方法。由于这是一项容量测试，配置和报告结果格式（见第6.3.1节）还必须包括：
Configuration:
配置：
- The number of physical ingress ports active during the test
- 测试期间活动的物理入口端口数
- The classification marking (DSCP, VLAN, etc.) for each physical ingress port
- 每个物理入口端口的分类标记（DSCP、VLAN等）
- The traffic rate for stateful traffic and the traffic rate/mixture for stateful traffic for each physical ingress port
- 每个物理入口端口的有状态流量的流量率和有状态流量的流量率/混合
- The shaped egress port shaper parameters (QL, SR, Bc, Be)
- 成形出口端口成形器参数（QL、SR、Bc、Be）
Report Results:
报告结果：
- For each active egress port, the achieved throughput rate and shaper metrics for each ingress port traffic stream
- 对于每个活动出口端口，每个入口端口流量流的实现吞吐量和整形器度量
Example:
例子：
- Egress Port 1: throughput and metrics for ingress streams 1-n
- 出口端口1：入口流1-n的吞吐量和指标
- Egress Port n: throughput and metrics for ingress streams 1-n
- 出口端口n：入口流1-n的吞吐量和度量
Test Summary: The second shaper capacity test is conducted with all queues actively shaping on a single physical port. The benchmarking methodology described in the per-port shaping test (Section 6.3.2.1) serves as the foundation for this. Additionally, each of the SP queues on the egress physical port is configured with a shaper. For the highest-priority queue, the
测试摘要：第二个整形器容量测试是在所有队列在单个物理端口上积极整形的情况下进行的。在每个端口成形测试（第3.3.2.1节）中描述的基准测试方法是这一点的基础。此外，出口物理端口上的每个SP队列都配置有整形器。对于最高优先级队列
maximum amount of bandwidth available is limited by the bandwidth of the shaper. For the lower-priority queues, the maximum amount of bandwidth available is limited by the bandwidth of the shaper and traffic in higher-priority queues.
可用的最大带宽量受整形器带宽的限制。对于低优先级队列，可用带宽的最大数量受到整形器带宽和高优先级队列中流量的限制。
The benchmarking methodologies specified in Sections 6.3.1.1 (stateless) and 6.3.1.2 (stateful) (procedure, metrics, and reporting format) should be applied here. Since this is a capacity test, the configuration and report results format (see Section 6.3.1) MUST also include:
此处应采用第6.3.1.1节（无状态）和第6.3.1.2节（有状态）（程序、指标和报告格式）中规定的基准方法。由于这是一项容量测试，配置和报告结果格式（见第6.3.1节）还必须包括：
Configuration:
配置：
- The number of physical ingress ports active during the test
- 测试期间活动的物理入口端口数
- The classification marking (DSCP, VLAN, etc.) for each physical ingress port
- 每个物理入口端口的分类标记（DSCP、VLAN等）
- The traffic rate for stateful traffic and the traffic rate/mixture for stateful traffic for each physical ingress port
- 每个物理入口端口的有状态流量的流量率和有状态流量的流量率/混合
- For the active egress port, each of the following shaper queue parameters: QL, SR, Bc, Be
- 对于活动出口端口，以下每个整形器队列参数：QL、SR、Bc、Be
Report Results:
报告结果：
- For each queue of the active egress port, the achieved throughput rate and shaper metrics for each ingress port traffic stream
- 对于活动出口端口的每个队列，每个入口端口流量流的实现吞吐量和整形器度量
Example:
例子：
- Egress Port High-Priority Queue: throughput and metrics for ingress streams 1-n
- 出口端口高优先级队列：入口流1-n的吞吐量和度量
- Egress Port Lower-Priority Queue: throughput and metrics for ingress streams 1-n
- 出口端口低优先级队列：入口流的吞吐量和度量1-n
Test Summary: For the third shaper capacity test (which is a combination of the tests listed in Sections 6.3.2.1 and 6.3.2.2), all queues will be actively shaping and all physical ports active.
测试摘要：对于第三个整形器容量测试（这是第6.3.2.1节和第6.3.2.2节中列出的测试的组合），所有队列都将积极整形，所有物理端口都将积极活动。
The benchmarking methodologies specified in Sections 6.3.1.1 (stateless) and 6.3.1.2 (stateful) (procedure, metrics, and reporting format) should be applied here. Since this is a capacity test, the configuration and report results format (see Section 6.3.1) MUST also include:
此处应采用第6.3.1.1节（无状态）和第6.3.1.2节（有状态）（程序、指标和报告格式）中规定的基准方法。由于这是一项容量测试，配置和报告结果格式（见第6.3.1节）还必须包括：
Configuration:
配置：
- The number of physical ingress ports active during the test
- 测试期间活动的物理入口端口数
- The classification marking (DSCP, VLAN, etc.) for each physical ingress port
- 每个物理入口端口的分类标记（DSCP、VLAN等）
- The traffic rate for stateful traffic and the traffic rate/mixture for stateful traffic for each physical ingress port
- 每个物理入口端口的有状态流量的流量率和有状态流量的流量率/混合
- For each of the active egress ports: shaper port parameters and per-queue parameters (QL, SR, Bc, Be)
- 对于每个活动出口端口：整形器端口参数和每队列参数（QL、SR、Bc、Be）
Report Results:
报告结果：
- For each queue of each active egress port, the achieved throughput rate and shaper metrics for each ingress port traffic stream
- 对于每个活动出口端口的每个队列，每个入口端口流量流的实现吞吐量和整形器度量
Example:
例子：
- Egress Port 1, High-Priority Queue: throughput and metrics for ingress streams 1-n
- 出口端口1，高优先级队列：入口流1-n的吞吐量和指标
- Egress Port 1, Lower-Priority Queue: throughput and metrics for ingress streams 1-n
- 出口端口1，低优先级队列：入口流1-n的吞吐量和指标
...
...
- Egress Port n, High-Priority Queue: throughput and metrics for ingress streams 1-n
- 出口端口n，高优先级队列：入口流1-n的吞吐量和指标
- Egress Port n, Lower-Priority Queue: throughput and metrics for ingress streams 1-n
- 出口端口n，低优先级队列：入口流1-n的吞吐量和指标
As mentioned in Section 3 of this document, it is impossible to specify the various permutations of concurrent traffic management functions that should be tested in a device for capacity testing. However, some profiles are listed below that may be useful for testing multiple configurations of traffic management functions:
如本文件第3节所述，不可能指定应在容量测试设备中测试的并发流量管理功能的各种排列。但是，下面列出了一些可能有助于测试多种交通管理功能配置的配置文件：
- Policers on ingress and queuing on egress
- 进入时的警察和出口时的排队
- Policers on ingress and shapers on egress (not intended for a flow to be policed and then shaped; these would be two different flows tested at the same time)
- 入口上的policer和出口上的shapper（不适用于对流进行policed和整形；这将是同时测试的两个不同流）
The test procedures and reporting formats from Sections 6.1, 6.2, and 6.3 may be modified to accommodate the capacity test profile.
第6.1节、第6.2节和第6.3节中的试验程序和报告格式可以修改，以适应容量试验剖面。
Documents of this type do not directly affect the security of the Internet or of corporate networks as long as benchmarking is not performed on devices or systems connected to production networks.
只要不在连接到生产网络的设备或系统上执行基准测试，此类文档不会直接影响互联网或公司网络的安全性。
Further, benchmarking is performed on a "black box" basis, relying solely on measurements observable external to the DUT/SUT.
此外，基准测试是在“黑盒”的基础上进行的，仅依赖于DUT/SUT外部可观察到的测量。
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
DUT/SUT中不应存在专门用于基准测试的特殊能力。DUT/SUT对网络安全的任何影响应在实验室和生产网络中相同。
[3GPP2-C_R1002-A] 3rd Generation Partnership Project 2, "cdma2000 Evaluation Methodology", Version 1.0, Revision A, May 2009, <http://www.3gpp2.org/public_html/specs/ C.R1002-A_v1.0_Evaluation_Methodology.pdf>.
[3GPP2-C_R1002-A]第三代合作伙伴项目2，“cdma2000评估方法”，版本1.0，修订版A，2009年5月<http://www.3gpp2.org/public_html/specs/ C.R1002-A_v1.0_评估方法。pdf>。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <http://www.rfc-editor.org/info/rfc1242>.
[RFC1242]Bradner，S.，“网络互连设备的基准术语”，RFC 1242，DOI 10.17487/RFC1242，1991年7月<http://www.rfc-editor.org/info/rfc1242>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <http://www.rfc-editor.org/info/rfc2544>.
[RFC2544]Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 2544，DOI 10.17487/RFC2544，1999年3月<http://www.rfc-editor.org/info/rfc2544>.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, DOI 10.17487/RFC2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>.
[RFC2680]Almes，G.，Kalidini，S.，和M.Zekauskas，“IPPM的单向数据包丢失度量”，RFC 2680，DOI 10.17487/RFC2680，1999年9月<http://www.rfc-editor.org/info/rfc2680>.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, DOI 10.17487/RFC3148, July 2001, <http://www.rfc-editor.org/info/rfc3148>.
[RFC3148]Mathis，M.和M.Allman，“定义经验批量输送能力指标的框架”，RFC 3148，DOI 10.17487/RFC3148，2001年7月<http://www.rfc-editor.org/info/rfc3148>.
[RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2005, <http://www.rfc-editor.org/info/rfc4115>.
[RFC4115]Aboul Magd，O.和S.Rabie，“有效处理配置文件内流量的区分服务双速率三色标记”，RFC 4115，DOI 10.17487/RFC4115，2005年7月<http://www.rfc-editor.org/info/rfc4115>.
[RFC4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689, DOI 10.17487/RFC4689, October 2006, <http://www.rfc-editor.org/info/rfc4689>.
[RFC4689]Poretsky，S.，Perser，J.，Erramilli，S.，和S.Khurana，“基准网络层流量控制机制的术语”，RFC 4689，DOI 10.17487/RFC4689，2006年10月<http://www.rfc-editor.org/info/rfc4689>.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <http://www.rfc-editor.org/info/rfc4737>.
[RFC4737]Morton，A.，Ciavattone，L.，Ramachandran，G.，Shalunov，S.，和J.Perser，“数据包重新排序度量”，RFC 4737，DOI 10.17487/RFC4737，2006年11月<http://www.rfc-editor.org/info/rfc4737>.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <http://www.rfc-editor.org/info/rfc5481>.
[RFC5481]Morton，A.和B.Claise，“数据包延迟变化适用性声明”，RFC 5481，DOI 10.17487/RFC5481，2009年3月<http://www.rfc-editor.org/info/rfc5481>.
[RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, "Framework for TCP Throughput Testing", RFC 6349, DOI 10.17487/RFC6349, August 2011, <http://www.rfc-editor.org/info/rfc6349>.
[RFC6349]Constantine，B.，Forget，G.，Geib，R.和R.Schrage，“TCP吞吐量测试框架”，RFC 6349，DOI 10.17487/RFC6349，2011年8月<http://www.rfc-editor.org/info/rfc6349>.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, DOI 10.17487/RFC6703, August 2012, <http://www.rfc-editor.org/info/rfc6703>.
[RFC6703]Morton，A.，Ramachandran，G.，和G.Maguluri，“报告IP网络性能指标：不同观点”，RFC 6703，DOI 10.17487/RFC6703，2012年8月<http://www.rfc-editor.org/info/rfc6703>.
[SPECweb2009] Standard Performance Evaluation Corporation (SPEC), "SPECweb2009 Release 1.20 Benchmark Design Document", April 2010, <https://www.spec.org/web2009/docs/design/ SPECweb2009_Design.html>.
[SPECweb2009]标准性能评估公司（SPEC），“SPECweb2009版本1.20基准设计文件”，2010年4月<https://www.spec.org/web2009/docs/design/ SPECweb2009_Design.html>。
[CA-Benchmark] Hamilton, M. and S. Banks, "Benchmarking Methodology for Content-Aware Network Devices", Work in Progress, draft-ietf-bmwg-ca-bench-meth-04, February 2013.
[CA Benchmark]Hamilton，M.和S.Banks，“内容感知网络设备的基准测试方法”，正在进行的工作，草稿-ietf-bmwg-CA-bench-meth-042013年2月。
[CoDel] Nichols, K., Jacobson, V., McGregor, A., and J. Iyengar, "Controlled Delay Active Queue Management", Work in Progress, draft-ietf-aqm-codel-01, April 2015.
[CoDel]Nichols，K.，Jacobson，V.，McGregor，A.，和J.Iyengar，“受控延迟主动队列管理”，在建工程，草案-ietf-aqm-CoDel-01，2015年4月。
[MEF-10.3] Metro Ethernet Forum, "Ethernet Services Attributes Phase 3", MEF 10.3, October 2013, <https://www.mef.net/Assets/Technical_Specifications/ PDF/MEF_10.3.pdf>.
[MEF-10.3]城域以太网论坛，“以太网服务属性第3阶段”，MEF 10.3，2013年10月<https://www.mef.net/Assets/Technical_Specifications/ PDF/MEF_10.3.PDF>。
[MEF-12.2] Metro Ethernet Forum, "Carrier Ethernet Network Architecture Framework -- Part 2: Ethernet Services Layer", MEF 12.2, May 2014, <https://www.mef.net/Assets/Technical_Specifications/ PDF/MEF_12.2.pdf>.
[MEF-12.2]城域以太网论坛，“运营商以太网网络架构框架——第2部分：以太网服务层”，MEF 12.2，2014年5月<https://www.mef.net/Assets/Technical_Specifications/ PDF/MEF_12.2.PDF>。
[MEF-14] Metro Ethernet Forum, "Abstract Test Suite for Traffic Management Phase 1", MEF 14, November 2005, <https://www.mef.net/Assets/ Technical_Specifications/PDF/MEF_14.pdf>.
[MEF-14]城域以太网论坛，“交通管理阶段1的抽象测试套件”，MEF 14，2005年11月<https://www.mef.net/Assets/ 技术规范/PDF/MEF\U 14.PDF>。
[MEF-19] Metro Ethernet Forum, "Abstract Test Suite for UNI Type 1", MEF 19, April 2007, <https://www.mef.net/Assets/ Technical_Specifications/PDF/MEF_19.pdf>.
[MEF-19]城域以太网论坛，“UNI类型1的抽象测试套件”，MEF 19，2007年4月<https://www.mef.net/Assets/ 技术规范/PDF/MEF\U 19.PDF>。
[MEF-26.1] Metro Ethernet Forum, "External Network Network Interface (ENNI) - Phase 2", MEF 26.1, January 2012, <http://www.mef.net/Assets/Technical_Specifications/ PDF/MEF_26.1.pdf>.
[MEF-26.1]城域以太网论坛，“外部网络接口（ENNI）-第2阶段”，MEF 26.12012年1月<http://www.mef.net/Assets/Technical_Specifications/ PDF/MEF_26.1.PDF>。
[MEF-37] Metro Ethernet Forum, "Abstract Test Suite for ENNI", MEF 37, January 2012, <https://www.mef.net/Assets/ Technical_Specifications/PDF/MEF_37.pdf>.
[MEF-37]城域以太网论坛，“ENNI抽象测试套件”，MEF 37，2012年1月<https://www.mef.net/Assets/ 技术规范/PDF/MEF\U 37.PDF>。
[PIE] Pan, R., Natarajan, P., Baker, F., White, G., VerSteeg, B., Prabhu, M., Piglione, C., and V. Subramanian, "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem", Work in Progress, draft-ietf-aqm-pie-02, August 2015.
[PIE]Pan，R.，Natarajan，P.，Baker，F.，White，G.，VerSteeg，B.，Prabhu，M.，Piglione，C.，和V.Subramanian，“PIE：解决缓冲区膨胀问题的轻量控制方案”，正在进行的工作，草案-ietf-aqm-PIE-022015年8月。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, <http://www.rfc-editor.org/info/rfc2697>.
[RFC2697]Heinanen，J.和R.Guerin，“单速率三色标记”，RFC 2697，DOI 10.17487/RFC2697，1999年9月<http://www.rfc-editor.org/info/rfc2697>.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, <http://www.rfc-editor.org/info/rfc2698>.
[RFC2698]Heinanen，J.和R.Guerin，“双速率三色标记”，RFC 2698，DOI 10.17487/RFC2698，1999年9月<http://www.rfc-editor.org/info/rfc2698>.
[RFC7567] Baker, F., Ed., and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://www.rfc-editor.org/info/rfc7567>.
[RFC7567]Baker，F.，Ed.，和G.Fairhurst，Ed.，“IETF关于主动队列管理的建议”，BCP 197，RFC 7567，DOI 10.17487/RFC7567，2015年7月<http://www.rfc-editor.org/info/rfc7567>.
This framework specifies that stateless and stateful behaviors SHOULD both be tested. Some open source tools that can be used to accomplish many of the tests proposed in this framework are iperf, netperf (with netperf-wrapper), the "uperf" tool, Tmix, TCP-incast-generator, and D-ITG (Distributed Internet Traffic Generator).
此框架指定应同时测试无状态和有状态行为。可以用来完成本框架中提出的许多测试的一些开源工具是iperf、netperf（带有netperf包装器）、“uperf”工具、Tmix、TCP incast生成器和D-ITG（分布式Internet流量生成器）。
iperf can generate UDP-based or TCP-based traffic; a client and server must both run the iperf software in the same traffic mode. The server is set up to listen, and then the test traffic is controlled from the client. Both unidirectional and bidirectional concurrent testing are supported.
iperf可以生成基于UDP或TCP的流量；客户端和服务器必须以相同的通信模式运行iperf软件。服务器设置为侦听，然后从客户端控制测试流量。支持单向和双向并发测试。
The UDP mode can be used for the stateless traffic testing. The target bandwidth, packet size, UDP port, and test duration can be controlled. A report of bytes transmitted, packets lost, and delay variation is provided by the iperf receiver.
UDP模式可用于无状态流量测试。可以控制目标带宽、数据包大小、UDP端口和测试持续时间。iperf接收器提供传输字节、数据包丢失和延迟变化的报告。
iperf (TCP mode), TCP-incast-generator, and D-ITG can be used for stateful traffic testing to test bulk transfer traffic. The TCP window size (which is actually the SSB), number of connections, packet size, TCP port, and test duration can be controlled. A report of bytes transmitted and throughput achieved is provided by the iperf sender, while TCP-incast-generator and D-ITG provide even more statistics.
iperf（TCP模式）、TCP增量生成器和D-ITG可用于状态流量测试，以测试批量传输流量。可以控制TCP窗口大小（实际上是SSB）、连接数、数据包大小、TCP端口和测试持续时间。iperf发送方提供了传输字节数和吞吐量的报告，而TCP incast generator和D-ITG提供了更多的统计数据。
netperf is a software application that provides network bandwidth testing between two hosts on a network. It supports UNIX domain sockets, TCP, SCTP, and UDP via BSD Sockets. netperf provides a number of predefined tests, e.g., to measure bulk (unidirectional) data transfer or request/response performance (http://en.wikipedia.org/wiki/Netperf). netperf-wrapper is a Python script that runs multiple simultaneous netperf instances and aggregates the results.
netperf是一种软件应用程序，可在网络上的两台主机之间提供网络带宽测试。它通过BSD套接字支持UNIX域套接字、TCP、SCTP和UDP。netperf提供了许多预定义的测试，例如测量批量（单向）数据传输或请求/响应性能(http://en.wikipedia.org/wiki/Netperf). netperf包装器是一个Python脚本，它同时运行多个netperf实例并聚合结果。
uperf uses a description (or model) of an application mixture. It generates the load according to the model descriptor. uperf is more flexible than netperf in its ability to generate request/response application behavior within a single TCP connection. The application model descriptor can be based on empirical data, but at the time of this writing, the import of packet captures is not directly supported.
uperf使用应用程序混合的描述（或模型）。它根据模型描述符生成负载。uperf在单个TCP连接中生成请求/响应应用程序行为的能力方面比netperf更灵活。应用程序模型描述符可以基于经验数据，但在撰写本文时，并不直接支持导入数据包捕获。
Tmix is another application traffic emulation tool. It uses packet captures directly to create the traffic profile. The packet trace is "reverse compiled" into a source-level characterization, called a "connection vector", of each TCP connection present in the trace. While most widely used in ns2 simulation environments, Tmix also runs on Linux hosts.
Tmix是另一个应用程序流量仿真工具。它直接使用数据包捕获来创建流量配置文件。数据包跟踪被“反向编译”为跟踪中存在的每个TCP连接的源级特征，称为“连接向量”。虽然Tmix在ns2模拟环境中使用最广泛，但它也在Linux主机上运行。
The traffic generation capabilities of these open source tools facilitate the emulation of the TCP test patterns discussed in Appendix B.
这些开源工具的流量生成功能有助于模拟附录B中讨论的TCP测试模式。
This framework recommends at a minimum the following TCP test patterns, since they are representative of real-world application traffic (Section 5.2.1 describes some methods to derive other application-based TCP test patterns).
该框架至少推荐以下TCP测试模式，因为它们代表了真实世界的应用程序流量（第5.2.1节描述了派生其他基于应用程序的TCP测试模式的一些方法）。
- Bulk Transfer: Generate concurrent TCP connections whose aggregate number of in-flight data bytes would fill the BDP. Guidelines from [RFC6349] are used to create this TCP traffic pattern.
- 批量传输：生成并发TCP连接，其飞行中数据字节的总数将填充BDP。[RFC6349]中的指南用于创建此TCP流量模式。
- Micro Burst: Generate precise burst patterns within a single TCP connection or multiple TCP connections. The idea is for TCP to establish equilibrium and then burst application bytes at defined sizes. The test tool must allow the burst size and burst time interval to be configurable.
- 微突发：在单个TCP连接或多个TCP连接中生成精确的突发模式。其思想是让TCP建立平衡，然后以定义的大小突发应用程序字节。测试工具必须允许配置突发大小和突发时间间隔。
- Web Site Patterns: The HTTP traffic model shown in Table 4.1.3-1 of [3GPP2-C_R1002-A] demonstrates a way to develop these TCP test patterns. In summary, the HTTP traffic model consists of the following parameters:
- 网站模式：[3GPP2-C_R1002-A]表4.1.3-1中所示的HTTP流量模型演示了开发这些TCP测试模式的方法。总之，HTTP流量模型由以下参数组成：
- Main object size (Sm)
- 主对象大小（Sm）
- Embedded object size (Se)
- 嵌入对象大小（Se）
- Number of embedded objects per page (Nd)
- 每页嵌入对象的数量（Nd）
- Client processing time (Tcp)
- 客户端处理时间（Tcp）
- Server processing time (Tsp)
- 服务器处理时间（Tsp）
Web site test patterns are illustrated with the following examples:
网站测试模式用以下示例说明：
- Simple web site: Mimic the request/response and object download behavior of a basic web site (small company).
- 简单网站：模仿基本网站（小公司）的请求/响应和对象下载行为。
- Complex web site: Mimic the request/response and object download behavior of a complex web site (eCommerce site).
- 复杂网站：模拟复杂网站（电子商务网站）的请求/响应和对象下载行为。
Referencing the HTTP traffic model parameters, the following table was derived (by analysis and experimentation) for simple web site and complex web site TCP test patterns:
参考HTTP流量模型参数，针对简单网站和复杂网站TCP测试模式（通过分析和实验）得出下表：
Simple Complex
Parameter Web Site Web Site
-----------------------------------------------------
Main object Ave. = 10KB Ave. = 300KB
size (Sm) Min. = 100B Min. = 50KB
Max. = 500KB Max. = 2MB
Simple Complex
Parameter Web Site Web Site
-----------------------------------------------------
Main object Ave. = 10KB Ave. = 300KB
size (Sm) Min. = 100B Min. = 50KB
Max. = 500KB Max. = 2MB
Embedded object Ave. = 7KB Ave. = 10KB
size (Se) Min. = 50B Min. = 100B
Max. = 350KB Max. = 1MB
Embedded object Ave. = 7KB Ave. = 10KB
size (Se) Min. = 50B Min. = 100B
Max. = 350KB Max. = 1MB
Number of embedded Ave. = 5 Ave. = 25
objects per page (Nd) Min. = 2 Min. = 10
Max. = 10 Max. = 50
Number of embedded Ave. = 5 Ave. = 25
objects per page (Nd) Min. = 2 Min. = 10
Max. = 10 Max. = 50
Client processing Ave. = 3s Ave. = 10s
time (Tcp)* Min. = 1s Min. = 3s
Max. = 10s Max. = 30s
Client processing Ave. = 3s Ave. = 10s
time (Tcp)* Min. = 1s Min. = 3s
Max. = 10s Max. = 30s
Server processing Ave. = 5s Ave. = 8s
time (Tsp)* Min. = 1s Min. = 2s
Max. = 15s Max. = 30s
Server processing Ave. = 5s Ave. = 8s
time (Tsp)* Min. = 1s Min. = 2s
Max. = 15s Max. = 30s
* The client and server processing time is distributed across the transmission/receipt of all of the main and embedded objects.
* 客户机和服务器处理时间分布在所有主对象和嵌入对象的传输/接收过程中。
To be clear, the parameters in this table are reasonable guidelines for the TCP test pattern traffic generation. The test tool can use fixed parameters for simpler tests and mathematical distributions for more complex tests. However, the test pattern must be repeatable to ensure that the benchmark results can be reliably compared.
需要明确的是，此表中的参数是TCP测试模式流量生成的合理指南。测试工具可以使用固定参数进行更简单的测试，使用数学分布进行更复杂的测试。但是，测试模式必须是可重复的，以确保可以可靠地比较基准测试结果。
- Interactive Patterns: While web site patterns are interactive to a degree, they mainly emulate the downloading of web sites of varying complexity. Interactive patterns are more chatty in nature, since there is a lot of user interaction with the servers. Examples include business applications such as PeopleSoft and Oracle, and consumer applications such as Facebook and IM. For the interactive patterns, the packet capture technique was used to characterize some business applications and also the email application.
- 交互模式：虽然web站点模式在一定程度上是交互的，但它们主要模拟不同复杂性的web站点的下载。交互模式本质上更健谈，因为有很多用户与服务器交互。例如，PeopleSoft和Oracle等商业应用程序，以及Facebook和IM等消费者应用程序。对于交互模式，数据包捕获技术用于描述一些业务应用程序以及电子邮件应用程序。
In summary, an interactive application can be described by the following parameters:
总之，交互式应用程序可以通过以下参数来描述：
- Client message size (Scm)
- 客户端消息大小（Scm）
- Number of client messages (Nc)
- 客户端消息数（Nc）
- Server response size (Srs)
- 服务器响应大小（Srs）
- Number of server messages (Ns)
- 服务器消息数（Ns）
- Client processing time (Tcp)
- 客户端处理时间（Tcp）
- Server processing time (Tsp)
- 服务器处理时间（Tsp）
- File size upload (Su)*
- 文件大小上载（Su）*
- File size download (Sd)*
- 文件大小下载（Sd）*
* The file size parameters account for attachments uploaded or downloaded and may not be present in all interactive applications.
* 文件大小参数用于上载或下载的附件，可能不存在于所有交互式应用程序中。
Again using packet capture as a means to characterize, the following table reflects the guidelines for simple business applications, complex business applications, eCommerce, and email Send/Receive:
下表再次使用数据包捕获作为表征手段，反映了简单业务应用程序、复杂业务应用程序、电子商务和电子邮件发送/接收的指导原则：
Simple Complex
Business Business
Parameter Application Application eCommerce* Email
--------------------------------------------------------------------
Client message Ave. = 450B Ave. = 2KB Ave. = 1KB Ave. = 200B
size (Scm) Min. = 100B Min. = 500B Min. = 100B Min. = 100B
Max. = 1.5KB Max. = 100KB Max. = 50KB Max. = 1KB
Simple Complex
Business Business
Parameter Application Application eCommerce* Email
--------------------------------------------------------------------
Client message Ave. = 450B Ave. = 2KB Ave. = 1KB Ave. = 200B
size (Scm) Min. = 100B Min. = 500B Min. = 100B Min. = 100B
Max. = 1.5KB Max. = 100KB Max. = 50KB Max. = 1KB
Number of client Ave. = 10 Ave. = 100 Ave. = 20 Ave. = 10
messages (Nc) Min. = 5 Min. = 50 Min. = 10 Min. = 5
Max. = 25 Max. = 250 Max. = 100 Max. = 25
Number of client Ave. = 10 Ave. = 100 Ave. = 20 Ave. = 10
messages (Nc) Min. = 5 Min. = 50 Min. = 10 Min. = 5
Max. = 25 Max. = 250 Max. = 100 Max. = 25
Client processing Ave. = 10s Ave. = 30s Ave. = 15s Ave. = 5s
time (Tcp)** Min. = 3s Min. = 3s Min. = 5s Min. = 3s
Max. = 30s Max. = 60s Max. = 120s Max. = 45s
Client processing Ave. = 10s Ave. = 30s Ave. = 15s Ave. = 5s
time (Tcp)** Min. = 3s Min. = 3s Min. = 5s Min. = 3s
Max. = 30s Max. = 60s Max. = 120s Max. = 45s
Server response Ave. = 2KB Ave. = 5KB Ave. = 8KB Ave. = 200B
size (Srs) Min. = 500B Min. = 1KB Min. = 100B Min. = 150B
Max. = 100KB Max. = 1MB Max. = 50KB Max. = 750B
Server response Ave. = 2KB Ave. = 5KB Ave. = 8KB Ave. = 200B
size (Srs) Min. = 500B Min. = 1KB Min. = 100B Min. = 150B
Max. = 100KB Max. = 1MB Max. = 50KB Max. = 750B
Number of server Ave. = 50 Ave. = 200 Ave. = 100 Ave. = 15
messages (Ns) Min. = 10 Min. = 25 Min. = 15 Min. = 5
Max. = 200 Max. = 1000 Max. = 500 Max. = 40
Number of server Ave. = 50 Ave. = 200 Ave. = 100 Ave. = 15
messages (Ns) Min. = 10 Min. = 25 Min. = 15 Min. = 5
Max. = 200 Max. = 1000 Max. = 500 Max. = 40
Server processing Ave. = 0.5s Ave. = 1s Ave. = 2s Ave. = 4s
time (Tsp)** Min. = 0.1s Min. = 0.5s Min. = 1s Min. = 0.5s
Max. = 5s Max. = 20s Max. = 10s Max. = 15s
Server processing Ave. = 0.5s Ave. = 1s Ave. = 2s Ave. = 4s
time (Tsp)** Min. = 0.1s Min. = 0.5s Min. = 1s Min. = 0.5s
Max. = 5s Max. = 20s Max. = 10s Max. = 15s
File size Ave. = 50KB Ave. = 100KB Ave. = N/A Ave. = 100KB
upload (Su) Min. = 2KB Min. = 10KB Min. = N/A Min. = 20KB
Max. = 200KB Max. = 2MB Max. = N/A Max. = 10MB
File size Ave. = 50KB Ave. = 100KB Ave. = N/A Ave. = 100KB
upload (Su) Min. = 2KB Min. = 10KB Min. = N/A Min. = 20KB
Max. = 200KB Max. = 2MB Max. = N/A Max. = 10MB
File size Ave. = 50KB Ave. = 100KB Ave. = N/A Ave. = 100KB
download (Sd) Min. = 2KB Min. = 10KB Min. = N/A Min. = 20KB
Max. = 200KB Max. = 2MB Max. = N/A Max. = 10MB
File size Ave. = 50KB Ave. = 100KB Ave. = N/A Ave. = 100KB
download (Sd) Min. = 2KB Min. = 10KB Min. = N/A Min. = 20KB
Max. = 200KB Max. = 2MB Max. = N/A Max. = 10MB
* eCommerce used a combination of packet capture techniques and reference traffic flows as described in [SPECweb2009].
* 电子商务结合了数据包捕获技术和参考流量，如[SPECweb2009]所述。
** The client and server processing time is distributed across the transmission/receipt of all of the messages. The client processing time consists mainly of the delay between user interactions (not machine processing).
**客户端和服务器处理时间分布在所有消息的传输/接收过程中。客户端处理时间主要包括用户交互之间的延迟（而不是机器处理）。
Again, the parameters in this table are the guidelines for the TCP test pattern traffic generation. The test tool can use fixed parameters for simpler tests and mathematical distributions for more complex tests. However, the test pattern must be repeatable to ensure that the benchmark results can be reliably compared.
同样，此表中的参数是TCP测试模式流量生成的指南。测试工具可以使用固定参数进行更简单的测试，使用数学分布进行更复杂的测试。但是，测试模式必须是可重复的，以确保可以可靠地比较基准测试结果。
- SMB/CIFS file copy: Mimic a network file copy, both read and write. As opposed to FTP, which is a bulk transfer and is only flow-controlled via TCP, SMB/CIFS divides a file into application blocks and utilizes application-level handshaking in addition to TCP flow control.
- SMB/CIFS文件拷贝：模拟网络文件拷贝，包括读和写。与FTP相反，FTP是一种大容量传输，仅通过TCP控制流量，SMB/CIFS将文件划分为应用程序块，除TCP流量控制外，还利用应用程序级握手。
In summary, an SMB/CIFS file copy can be described by the following parameters:
总之，SMB/CIFS文件副本可以通过以下参数来描述：
- Client message size (Scm)
- 客户端消息大小（Scm）
- Number of client messages (Nc)
- 客户端消息数（Nc）
- Server response size (Srs)
- 服务器响应大小（Srs）
- Number of server messages (Ns)
- 服务器消息数（Ns）
- Client processing time (Tcp)
- 客户端处理时间（Tcp）
- Server processing time (Tsp)
- 服务器处理时间（Tsp）
- Block size (Sb)
- 块大小（Sb）
The client and server messages are SMB control messages. The block size is the data portion of the file transfer.
客户端和服务器消息是SMB控制消息。块大小是文件传输的数据部分。
Again using packet capture as a means to characterize, the following table reflects the guidelines for SMB/CIFS file copy:
下表再次使用数据包捕获作为表征手段，反映了SMB/CIFS文件拷贝的指导原则：
SMB/CIFS
Parameter File Copy
--------------------------------
Client message Ave. = 450B
size (Scm) Min. = 100B
Max. = 1.5KB
SMB/CIFS
Parameter File Copy
--------------------------------
Client message Ave. = 450B
size (Scm) Min. = 100B
Max. = 1.5KB
Number of client Ave. = 10 messages (Nc) Min. = 5 Max. = 25
客户端平均数=10条消息（Nc）最小值=5最大值=25
Client processing Ave. = 1ms time (Tcp) Min. = 0.5ms Max. = 2
客户端处理平均时间=1ms时间（Tcp）最小值=0.5ms最大值=2
Server response Ave. = 2KB size (Srs) Min. = 500B Max. = 100KB
服务器响应平均值=2KB大小（Srs）最小值=500B最大值=100KB
Number of server Ave. = 10 messages (Ns) Min. = 10 Max. = 200
服务器平均数=10条消息（Ns）最小值=10最大值=200
Server processing Ave. = 1ms time (Tsp) Min. = 0.5ms Max. = 2ms
服务器处理平均时间=1ms时间（Tsp）最小值=0.5ms最大值=2ms
Block Ave. = N/A
size (Sb)* Min. = 16KB
Max. = 128KB
Block Ave. = N/A
size (Sb)* Min. = 16KB
Max. = 128KB
* Depending upon the tested file size, the block size will be transferred "n" number of times to complete the example. An example would be a 10 MB file test and 64 KB block size. In this case, 160 blocks would be transferred after the control channel is opened between the client and server.
* 根据测试的文件大小，块大小将被传输“n”次以完成示例。例如，10 MB的文件测试和64 KB的块大小。在这种情况下，在客户端和服务器之间打开控制通道后，将传输160个块。
Acknowledgments
致谢
We would like to thank Al Morton for his continuous review and invaluable input to this document. We would also like to thank Scott Bradner for providing guidance early in this document's conception, in the area of the benchmarking scope of traffic management functions. Additionally, we would like to thank Tim Copley for his original input, as well as David Taht, Gory Erg, and Toke Hoiland-Jorgensen for their review and input for the AQM group. Also, for the formal reviews of this document, we would like to thank Gilles Forget, Vijay Gurbani, Reinhard Schrage, and Bhuvaneswaran Vengainathan.
我们要感谢Al Morton对本文件的持续审查和宝贵投入。我们还要感谢Scott Bradner在本文件构思初期就交通管理功能的基准范围提供了指导。此外，我们要感谢Tim Copley的原始投入，以及David Taht、Gory Erg和Toke Hoiland Jorgensen对AQM小组的审查和投入。此外，对于本文件的正式审查，我们要感谢Gilles Forget、Vijay Gurbani、Reinhard Schrage和Bhuvaneswaran Vengianathan。
Authors' Addresses
作者地址
Barry Constantine JDSU, Test and Measurement Division Germantown, MD 20876-7100 United States
Barry Constantine JDSU，测试和测量部门，美国马里兰州日尔曼镇20876-7100
Phone: +1-240-404-2227
Email: barry.constantine@jdsu.com
Phone: +1-240-404-2227
Email: barry.constantine@jdsu.com
Ram (Ramki) Krishnan Dell Inc. Santa Clara, CA 95054 United States
Ram（Ramki）Krishnan Dell Inc.美国加利福尼亚州圣克拉拉市，邮编95054
Phone: +1-408-406-7890
Email: ramkri123@gmail.com
Phone: +1-408-406-7890
Email: ramkri123@gmail.com