[要約] RFC 7640は、トラフィック管理のベンチマークを定義するためのガイドラインです。その目的は、ネットワークのパフォーマンスを評価し、改善するための基準を提供することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）、Differentiated Services Code Point（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.
- Active Queue Management（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アルゴリズム（「バッファブロート」を軽減することを目的とした）をテストするのに役立つ可能性があることに注意してください。これらのアルゴリズムの例には、Controlled Delay [CoDel]とProportional Integral Controller Enhanced [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) | | |
|----------| |----------------| |--------------| |----------|
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]は、それぞれシングルレート3カラーマーカーとツーレート3カラーマーカーを定義しています。
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].
メトロイーサネットフォーラム（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 | | |
| |<----| |<----| |<---| |
| | | | | | | |
+--------------+ +-------+ +----------+ +-----------+
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が制御ループでかなりのサイズのTCPウィンドウを利用できるようにするには、TCPステートフルテストにNetwork Delay Emulator（NDE）が必要です。
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は本質的にパッシブである必要があることにも注意してください（たとえば、ファイバースプール）。これは、アクティブな遅延要素（つまり、テスト障害発生器）がテストフローに及ぼす潜在的な影響を排除するために推奨されます。必要なレイテンシのためにファイバースプールが実用的でない場合、アクティブな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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following acronyms are used:
次の頭字語が使用されています。
AQM: Active Queue Management
AQM：アクティブキュー管理
BB: Bottleneck Bandwidth
BB：ボトルネック帯域幅
BDP: Bandwidth-Delay Product
BDP：帯域幅遅延製品
BSA: Burst Size Achieved
BSA：バーストサイズの達成
CBS: Committed Burst Size CIR: Committed Information Rate
CBS：認定バーストサイズCIR：認定情報レート
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
SSB：ソケットバッファーの送信
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.) Essentially, any network device that performs traffic management as defined in Section 1.1 can be benchmarked or tested with this framework.
-一般的なレイヤ4〜7アプライアンス（プロキシ、WANアクセラレータなど）基本的に、セクション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またはアプリケーションレイヤー）を導出します。ネットワークデバイスが本質的にステートフルである場合（ファイアウォールなど）、ステートフルテストパターントラフィックは、特定のテストシナリオ（TCPトランスポートやUDP VoIPを使用するアプリケーションなど）のステートレスUDPトラフィックとともにテストすることが重要です。 ）。
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、Signaling System 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）テストパターンに対応していませんが、メトリックはTCP再送信およびRTT測定に基づいているため（ペイロードとは対照的に）、セクション4.2で定義されたメトリックを引き続き使用できます。 ）。したがって、tcpcryptが一般的になった場合、ベンチマーカーが暗号化された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のバーストのみがパケット損失なしで達成できます。次に、63 KBがBSAです。また、BSAバーストサイズで送信されたパケットが経験した平均パケット遅延変動（PDV）（下記参照）も記録する必要があります。このメトリックは、バイト、KB、またはMBの単位で報告される必要があります（SHALL）。
- 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]ごとにカウントされます。このメトリックは、負にできない整数として報告する必要があります（SHALL）。
- 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などを使用して実現）。このメトリックは実際の秒数として報告される必要があります（SHALL）。負の測定値は通常、テストデバイス間の時間同期の問題を示します。
- 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）：トラフィックシェーパーは、異なるサイズの「トレイン」でパケットを送信します。これらのフレームは、必須のフレーム間ギャップに関して「連続して」送信されます。このメトリックは、シェーパーがトラフィックを放出する方法を特徴付けます。一部のシェーパーは間隔ごとにより大きなバーストを送信し、1つのパケットのバーストは、シェーパーが単一パケットの一定ビットレートストリームを送信する、あまり一般的でないケースに適用されます。このメトリックは、バイト、KB、またはMBの単位で報告される必要があります（SHALL）。 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出力ポートで測定されます。このメトリックは、実際の秒数として報告される必要があります（SHALL）。 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）の1回の実行にかかる時間の目安になります。平均時間、最小時間、最大時間は測定または計算され、実際の秒数として表されます。
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.
例として、0.5ミリ秒のレイテンシのGigEネットワークで5秒かかるインタラクティブなHTTP TTPセッションがあります。この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" 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.
「Transmitted Bytes」は、送信される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は、1秒ごとにサンプリングされた実際のテスト中に測定されたすべてのRTTの合計を、秒単位のテスト期間で割った値から得られます。
Total RTTs during transfer
Average RTT during transfer = ------------------------------
Transfer duration in seconds
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).
ポリス機能の場合、バーストサイズパスのうち、バーストが1 KBずつ増加して、ポリスが本当に正しく構成されている（またはまったく有効になっている）ことを確認する必要があります。
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テストトラフィックを使用するテストでは、意味のあるBDPを提供するために、ネットワーク遅延エミュレーター（セクション1.2のラボのセットアップ図に示されているNDE機能）を使用する必要があります。セクション1.2で説明したように、すべてのステートフルテストに対してNDEのみを使用して、ターゲットトラフィックレートと構成済みRTTを個別に検証する必要があります（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テストホストは、送信と受信の両方のソケットバッファーサイズの調整を許可する必要があります。ソケットバッファは、TCPテストアプリケーショントラフィックのバルク転送用のBDPを満たすのに十分な大きさである必要があります。
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と再送信の測定には、通常、専用の通信テスト機器が必要です。専用のハードウェアベースのテストツールがない場合、これらの測定はパケットキャプチャツールで行う必要がある場合があります。つまり、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]のように、テスト結果は特定の輻輳制御アルゴリズムの詳細を提供するものとします（SHALL）。
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-wrapperツールは、複数の同時netperfインスタンスを実行して結果を集計するPythonスクリプトです。付録Aでは、netperf / netperf-wrapperおよび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テストトラフィックを使用する必要があるもう1つの理由です。
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
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サーバーがWebページコンテンツをクライアントに配信します（サーバーの遅延が100ミリ秒後）。この非同期の「要求/応答」動作は、電子メール（SMTP）、ファイル転送（FTPおよびサーバーメッセージブロック（SMB））、データベース（SQL）、Webアプリケーション（SOAP）、Representationalなど、ほとんどのTCPベースのアプリケーションに固有のものです。状態転送（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、FTP、およびワイヤレスアプリケーションプロトコル（WAP）アプリケーションの動作をTCPレイヤーでモデル化する例を提供します。モデルは、要求/応答バイトと要求間のギャップ時間のさまざまな数学的分布で定義されています。 [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ベンチマーク]で指定されているものを反映しています。これは、さまざまな代表的なアプリケーションプロファイルのトラフィックミックスを示唆しています。他の例は、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で定義された測定メトリックと比較する必要があります（SHOULD）。これにより、個々のテスト条件および容量テスト条件での内部トラフィック管理カウンターの精度が次のように評価されます。セクション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
ポリサーは、ポリシー機能を実行するエンティティとして定義されます。ポリシングテストの目的は、ポリサーのパフォーマンス（つまり、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つのセクションに分かれています。個別のポリサーテストと、全容量のポリシングテストです。個々のポリサーの基本機能をベンチマークし、デバイスの完全な定格容量に進むことが重要です。この容量には、デバイスごとのポリシングポリシーの数と、すべてのポートで同時にアクティブなポリサーの数が含まれる場合があります。
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]で定義されたポリサーをテストします。ポリサーが指定されたCBSおよびEBSバーストの通過を許可していることを確認することに加えて、ポリサーテストでは、ポリサーが余分なパケットを再マーキングまたはドロップし、指定された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トラフィックを使用できますが、ステートレストラフィックでポリサーをベンチマークする方がより正確です。
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.
[RFC4115]で定義されているポリサーの例として、1 GigE物理リンク（カラーブラインドモード）での64 KBのCBS / EBSおよび100 MbpsのCIR / EIRを検討してください。 64 KBのステートレストラフィックバーストは、GigEレートでポリサーに送信されます。これは、約0.512ミリ秒のバースト時間（1 GigEで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）は、出力ポートで測定され、記録されるものとします（SHALL）。
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. 準拠トラフィックテスト：CBS + EBSトラフィックのバーストをポリサー入力ポートに生成し、セクション4.1（BSA、LP、OOS、PD、およびPDV）で定義されたメトリックを出力ポートおよびTd全体（デフォルト60- 2番目の期間）。
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. 超過トラフィックテスト：CBS + EBSバイトを超えるバーストをポリサー入力ポートに生成し、ポリサーが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:
レポート形式：ポリサーの個別レポートには、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):
結果テーブルには、次のように各テスト実行のエントリが含まれている必要があります（テスト＃1からテスト#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個の物理ポートのそれぞれをポリシングできるように指定できます。デバイスは、各物理ポートで単一の顧客のトラフィックを運ぶことができ、単一のポリサーが物理ポートごとにインスタンス化されます。もう1つの可能性は、単一の物理ポートが複数のカスタマーを運ぶ可能性があることです。その場合、多くのカスタマーフローが個々の物理ポートで同時にポリシングされます（個々のポートのカスタマーごとに個別のポリサー）。
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）は、出力ポートで測定され、記録されるものとします（SHALL）。
The following sections provide the specific test scenarios, procedures, and reporting formats for each policer capacity test.
次のセクションでは、特定のテストシナリオ、手順、および各ポリサーキャパシティテストのレポート形式について説明します。
Test Summary: The first policer capacity test will benchmark a single physical port, with maximum policers on that physical port.
テストの要約：最初のポリサーキャパシティテストでは、単一の物理ポートをベンチマークし、その物理ポートで最大のポリサーを使用します。
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の複数のカテゴリの入力ポリサーを想定します。 1つの物理ポートに複数の顧客がいます。各顧客は、単一タグ付き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 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.
-Ynカスタマー、ポリサーレートrn物理ポートの一部の帯域幅は、他のトラフィック（つまり、カスタマートラフィック以外）専用です。これには、ネットワーク制御プロトコルトラフィックが含まれます。他のトラフィックには別のポリサーがあります。一般的な展開には、ポリサーの3つのカテゴリがあります。入力ポリサーのカテゴリが3つより多いまたは少ない展開がある場合があります。
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. CBSに等しいステートレストラフィックバーストと、各カスタマーストリーム（Y1〜Yn）に対してTi（CBSビット/ CIR）に等しい間隔を生成するようにテスターを構成します。各顧客のカプセル化も、テストされたサービス（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. 準拠トラフィックテスト：CBS + EBSトラフィックのバーストを各カスタマートラフィックストリームのポリサー入力ポートに生成し、各ストリームの出力ポートでセクション4.1で定義されたメトリック（BSA、LP、OOS、PD、およびPDV）を測定します。 Td全体（デフォルトは30秒間）。
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. 過剰トラフィックテスト：CBS + EBSバイトを超えるバーストを各顧客トラフィックストリームのポリサー入力ポートに生成し、ポリサーが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:
レポート形式：ポリサーの個別レポートには、顧客のトラフィックストリームごとに、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 The results table should contain entries for each test run, as follows (Test #1 to Test #Tr):
カスタマートラフィックストリームごとのDUT構成の概要：CIR、EIR、CBS、EBS結果テーブルには、次のように各テスト実行のエントリが含まれている必要があります（テスト＃1からテスト#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.
テストの要約：2番目のポリサーキャパシティテストには、物理ポートごとに1つのポリサー機能が含まれ、すべての物理ポートがアクティブになります。このテストでは、物理ポートごとに1つのポリサーがあります。ポリサーは、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.
3番目のポリサーキャパシティテストは、1番目と2番目のキャパシティテストを組み合わせたものです。つまり、物理ポートごとにアクティブな最大ポリサーと、アクティブなすべての物理ポートです。
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.
ポリシングテストと同様に、これらのテストは2つのセクションに分かれています。個別のキュー/スケジューラー機能テストと、全容量テストです。
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、Strict Priority（SP）キューイング、Weighted Fair Queuing（WFQ）、その他のバリエーションが含まれます。このテストフレームワークでは、最低3つの手法を使用したテストを推奨していますが、他のデバイススケジューリングアルゴリズムのベンチマークはテスターの裁量に任されています。
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
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.
この式は、ポリサーへの送信に必要な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キューイングを含む2つのレベルの優先度があります。出力ポートの速度よりも大きいフロー負荷では、優先度の高いパケットはドロップせずに送信され（低レイテンシも維持）、優先度の低い（またはベストエフォート）キューはドロップされる可能性があります。
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）は、出力ポートで測定され、記録されるものとします（SHALL）。
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（ビット/ BB単位のQL）に等しい間隔を生成するようにテスターを構成します。
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. QLトラフィックのバーストをDUTに生成し、セクション4.1で定義されたメトリック（LP、OOS、PD、およびPDV）を出力ポートで、Td全体（デフォルトでは30秒の期間）にわたって測定します。
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 The results table should contain entries for each test run, as follows (Test #1 to Test #Tr):
DUT構成の概要：スケジューリング手法（つまり、FIFO、SP、WFQなど）、BB、QL結果テーブルには、次のように各テスト実行のエントリが含まれている必要があります（テスト＃1からテスト#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のネットワークセットアップ構成のNetwork Delay Emulator（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は、BDPがQLより大きくなるのに十分な大きさのRTT値に設定する必要があります。テストシナリオの例を以下に定義します。
- 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)
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.
この例では、32 KBのQLをテストするには、ウィンドウサイズ/ SSBが32 KBのTCP接続が1つ必要です。この一括転送テストは、付録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.
付録Bに記載されているように、バルク転送テストとマイクロバーストテストパターンの2種類のTCPテストを実行する必要があります。バルク転送テストは、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).
その他のタイプのテストには、以下を含める必要があります：単純なWebサイト、複雑なWebサイト、ビジネスアプリケーション、電子メール、およびSMB / CIFS（Common Internet File System）ファイルコピー（すべて付録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テストパターンを生成できなければなりません（MUST）。
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の入力（クライアント側）ポートと出力（サーバー側）ポートの間でアプリケーショントラフィックを生成し、アプリケーションストリームごと、および（Td全体の）入力ポートと出力ポートでメトリック（TTPET、TCP効率、およびバッファー遅延）を測定します。 、デフォルトは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効率メトリックは、各テスト中に「グッドプット」の測定値を提供するため、テスト中に測定する必要があります。
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):
結果テーブルには、次のように、アプリケーションセッションごとの最小、最大、平均の各テスト実行のエントリが含まれている必要があります（テスト＃1からテスト#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）は、出力ポートで測定され、記録されるものとします（SHALL）。
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.
最初のキュー/スケジューラー容量テストでは、ポートごとに複数のキューが単一の物理ポートでテストされます。この場合、すべてのキュー（通常は8つ）が単一の物理ポートでアクティブになります。複数の入力物理ポートからのトラフィックは、同じ出力物理ポートに送られます。これにより、出力物理ポートでオーバーサブスクリプションが発生します。
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.
繰り返しになりますが、テストは2つのセクションに分かれています。個別のシェーパーベンチマークテストと、全容量のシェーパーベンチマークテストです。
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パラメータに従って出力ポートからのトラフィックを測定します。シェーパーは通常、ポリサーに送信するため、放出されたトラフィックがポリサーの制限に準拠するようになっています。
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.
この例では、シェーパーの入力ポートと出力ポートはどちらも全二重ギガビットイーサネットです。入力キューは512,000バイト、SR = 50 Mbpsに設定され、BCとBeの両方が32,000バイトに設定されています。シングルバーストテストの場合、送信テストデバイスは最大512,000バイトを入力ポートにバーストし、送信を停止します。
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:
マルチバーストテストを実行する場合、バーストバイトを512,000バイトのバースト間の送信間隔で割った値がSRを超えてはなりません。送信間隔（Ti）は、キューのセクション6.2.1.1で説明されている式に類似した式に準拠する必要があります。
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ミリ秒（512,000バイト* 8 / 50,000,000 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）は、出力ポートで測定され、記録されるものとします（SHALL）。
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（ビット/ BB単位のQL）に等しい間隔を生成するようにテスターを構成します。
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. QLトラフィックのバーストをDUTに生成し、セクション4.1で定義されたメトリック（LP、OOS、PDV、SR、SBB、およびSBI）を出口ポートで、Td全体（デフォルトでは30秒の期間）にわたって測定します。
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 Stateless Traffic個別レポートには、各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):
結果テーブルには、次のように各テスト実行のエントリが含まれている必要があります（テスト＃1からテスト#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デバイスでキューをテストするために、シェーパーテストではステートフルトラフィックテストも推奨されます。ステートフルトラフィックテストでは、セクション1.2のネットワークセットアップ構成のNetwork Delay Emulator（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の接続サイズが使用されている場合、BDPを埋めるために4つの接続と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.
付録Bに記載されているように、バルク転送テストとマイクロバーストテストパターンの2種類のTCPテストを実行する必要があります。バルク転送テストは、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).
その他のタイプのテストには、シンプルなWebサイト、複雑なWebサイト、ビジネスアプリケーション、電子メール、および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テストパターンを生成できなければなりません（MUST）。
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の入力（クライアント側）ポートと出力（サーバー側）ポートの間のアプリケーショントラフィックを生成し、アプリケーションストリームごと、および（Td全体の）入力ポートと出力ポートでメトリック（TTPET、TCP効率、およびバッファー遅延）を測定します。 、デフォルトは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:
レポート形式：シェーパーステートフルトラフィックの個別レポートには、各トラフィックスケジューラとQL / SRテスト実行のすべての結果を含める必要があります。推奨される形式は次のとおりです。
******************************************************************
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):
結果テーブルには、次のように、アプリケーションセッションごとの最小、最大、平均の各テスト実行のエントリが含まれている必要があります（テスト＃1からテスト#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 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.
テストの要約：2番目のシェーパーキャパシティテストは、すべてのキューが単一の物理ポートでアクティブにシェーピングされて実行されます。ポートごとのシェーピングテスト（セクション6.3.2.1）で説明されているベンチマークの方法論は、これの基盤として機能します。さらに、出力物理ポートの各SPキューは、シェーパーで構成されます。最も優先度の高いキューの場合、使用可能な帯域幅の最大量は、シェーパーの帯域幅によって制限されます。優先度の低いキューの場合、使用可能な帯域幅の最大量は、優先度の高いキューのシェーパーとトラフィックの帯域幅によって制限されます。
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.
テストの概要：3番目のシェーパーキャパシティテスト（セクション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)
- 入力のポリサーと出力のシェーパー（フローをポリシングしてシェーピングすることを意図したものではありません。これらは同時にテストされる2つの異なるフローです）
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] 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>。
[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.、Kalidindi、S.、M。Zekauskas、「A IP-way Packet Loss Metric for 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、「プロファイル内トラフィックの効率的な処理を備えた差別化サービス2レート、3色マーカー」、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、「Packet Reordering Metrics」、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、「Packet Delay Variation Applicability Statement」、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、「Reporting IP Network Performance Metrics：Different Points of View」、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] Standard Performance Evaluation Corporation（SPEC）、「SPECweb2009 Release 1.20 Benchmark Design Document」、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ベンチマーク]ハミルトン、M.、S。バンクス、「コンテンツ認識ネットワークデバイスのベンチマーク手法」、進行中の作業、draft-ietf-bmwg-ca-bench-meth-04、2013年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、「Controlled Delay Active Queue Management」、Work in Progress、draft-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] Metroイーサネットフォーラム、「イーサネットサービス属性フェーズ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] Metro Ethernet Forum、「Abstract Test Suite for Traffic Management Phase 1」、MEF 14、2005年11月、<https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_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] Metro Ethernet Forum、「Abstract Test Suite for UNI Type 1」、MEF 19、2007年4月、<https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_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]メトロイーサネットフォーラム、「External Network Network Interface（ENNI）-Phase 2」、MEF 26.1、2012年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] Metro Ethernet Forum、「Abstract Test Suite for ENNI」、MEF 37、2012年1月、<https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_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]パン、R、ナタラジャン、P、ベイカー、F、ホワイト、G、VerSteeg、B、プラブ、M、ピグリオーネ、C、およびV.サブラマニアン、「PIE：A Lightweight Control Scheme Bufferbloatの問題に対処するには」、作業中、draft-ietf-aqm-pie-02、2015年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、「A Single Rate Three Color Marker」、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、「A Two Rate Three Color Marker」、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]ベイカー、F。、エド、およびG.フェアハースト、エド、「アクティブキュー管理に関する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-wrapper付き）、「uperf」ツール、Tmix、TCP-incast-generator、およびD-ITG（分散インターネット）です。トラフィックジェネレーター）。
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-incast-generator、および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は、ネットワーク上の2つのホスト間のネットワーク帯域幅テストを提供するソフトウェアアプリケーションです。 BSDソケットを介してUNIXドメインソケット、TCP、SCTP、およびUDPをサポートします。 netperfは、多数の事前定義されたテストを提供します。たとえば、バルク（単方向）データ転送または要求/応答パフォーマンスを測定します（http://en.wikipedia.org/wiki/Netperf）。 netperf-wrapperは、複数の同時netperfインスタンスを実行して結果を集約するPythonスクリプトです。
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:
- Webサイトパターン：[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:
Webサイトのテストパターンを次の例で示します。
- Simple web site: Mimic the request/response and object download behavior of a basic web site (small company).
- シンプルなWebサイト：基本的なWebサイト（小規模な会社）の要求/応答とオブジェクトのダウンロード動作を模倣します。
- Complex web site: Mimic the request/response and object download behavior of a complex web site (eCommerce site).
- 複雑なWebサイト：複雑なWebサイト（eコマースサイト）の要求/応答とオブジェクトのダウンロード動作を模倣します。
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トラフィックモデルパラメータを参照して、単純なWebサイトと複雑なWebサイトのTCPテストパターンについて（分析と実験により）導き出されたものです。
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
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
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)
- サーバーメッセージの数（N）
- 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:
再び特性化する手段としてパケットキャプチャを使用して、次の表は単純なビジネスアプリケーション、複雑なビジネスアプリケーション、eコマース、および電子メールの送受信のガイドラインを反映しています。
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
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
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
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
* eCommerce used a combination of packet capture techniques and reference traffic flows as described in [SPECweb2009].
* eコマースでは、[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ファイルコピー：読み取りと書き込みの両方のネットワークファイルコピーを模倣します。バルク転送であり、TCPを介してのみフロー制御されるFTPとは対照的に、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)
- サーバーメッセージの数（N）
- 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
Number of client Ave. = 10 messages (Nc) Min. = 5 Max. = 25
Number of client Ave. = 10 messages (Nc) Min. = 5 Max. = 25
Client processing Ave. = 1ms time (Tcp) Min. = 0.5ms Max. = 2
Client processing Ave. = 1ms time (Tcp) Min. = 0.5ms Max. = 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。 = 2ミリ秒
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 Vengainathanに感謝します。
Authors' Addresses
著者のアドレス
Barry Constantine JDSU, Test and Measurement Division Germantown, MD 20876-7100 United States
バリーコンスタンティンJDSU、テストおよび測定部門ジャーマンタウン、MD 20876-7100米国
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. Santa Clara、CA 95054 United States
Phone: +1-408-406-7890
Email: ramkri123@gmail.com