[要約] RFC 8239は、データセンターのベンチマーキング方法論に関するガイドラインです。その目的は、データセンターの性能評価と比較を容易にするための一貫した方法を提供することです。
Internet Engineering Task Force (IETF) L. Avramov
Request for Comments: 8239 Google
Category: Informational J. Rapp
ISSN: 2070-1721 VMware
August 2017
Data Center Benchmarking Methodology
データセンターのベンチマーク手法
Abstract
概要
The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.
この情報ドキュメントの目的は、データセンター内の物理ネットワーク機器のテストと評価の方法論と測定手法を確立することです。 RFC 8238は、規範と見なされる用語が含まれているため、このドキュメントの前提条件です。これらの用語と方法の多くは、データセンターで最初に適用されたテクノロジーが他の場所に展開されているため、このドキュメントの範囲を超えて適用できる場合があります。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc8239.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8239で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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. Requirements Language ......................................4
1.2. Methodology Format and Repeatability Recommendation ........4
2. Line-Rate Testing ...............................................4
2.1. Objective ..................................................4
2.2. Methodology ................................................4
2.3. Reporting Format ...........................................5
3. Buffering Testing ...............................................6
3.1. Objective ..................................................6
3.2. Methodology ................................................7
3.3. Reporting Format ...........................................9
4. Microburst Testing .............................................10
4.1. Objective .................................................10
4.2. Methodology ...............................................10
4.3. Reporting Format ..........................................11
5. Head-of-Line Blocking ..........................................12
5.1. Objective .................................................12
5.2. Methodology ...............................................12
5.3. Reporting Format ..........................................14
6. Incast Stateful and Stateless Traffic ..........................15
6.1. Objective .................................................15
6.2. Methodology ...............................................15
6.3. Reporting Format ..........................................17
7. Security Considerations ........................................17
8. IANA Considerations ............................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
Acknowledgments ...................................................19
Authors' Addresses ................................................19
Traffic patterns in the data center are not uniform and are constantly changing. They are dictated by the nature and variety of applications utilized in the data center. They can be largely east-west traffic flows (server to server inside the data center) in one data center and north-south (from the outside of the data center to the server) in another, while others may combine both. Traffic patterns can be bursty in nature and contain many-to-one, many-to-many, or one-to-many flows. Each flow may also be small and latency sensitive or large and throughput sensitive while containing a mix of UDP and TCP traffic. All of these can coexist in a single cluster and flow through a single network device simultaneously. Benchmarking tests for network devices have long used [RFC1242], [RFC2432], [RFC2544], [RFC2889], and [RFC3918], which have largely been focused around various latency attributes and throughput [RFC2889] of the Device Under Test (DUT) being benchmarked. These standards are good at measuring theoretical throughput, forwarding rates, and latency under testing conditions; however, they do not represent real traffic patterns that may affect these networking devices.
データセンターのトラフィックパターンは均一ではなく、常に変化しています。それらは、データセンターで利用されるアプリケーションの性質と多様性によって決まります。それらは、1つのデータセンターでは主に東西方向のトラフィックフロー（データセンター内のサーバーからサーバーへ）であり、別のデータセンターでは南北（データセンターの外側からサーバーへ）ですが、他のトラフィックフローは両方を組み合わせることができます。トラフィックパターンはバースト性があり、多対1、多対多、または1対多のフローを含む場合があります。各フローは、UDPトラフィックとTCPトラフィックの混合を含みながら、小さい遅延に影響されたり、大きいスループットに影響されたりする可能性もあります。これらはすべて、単一のクラスター内で共存でき、単一のネットワークデバイスを同時に通過します。ネットワークデバイスのベンチマークテストでは、長い間[RFC1242]、[RFC2432]、[RFC2544]、[RFC2889]、[RFC3918]が使用されてきました。これらは主に、テスト対象デバイス（DUT）のさまざまなレイテンシ属性とスループット[RFC2889]に焦点を当てています）ベンチマーク中。これらの標準は、テスト条件下での理論上のスループット、転送速度、および遅延の測定に適しています。ただし、これらは、これらのネットワーキングデバイスに影響を与える可能性のある実際のトラフィックパターンを表すものではありません。
Currently, typical data center networking devices are characterized by:
現在、一般的なデータセンターネットワーキングデバイスは、次の特徴があります。
- High port density (48 ports or more).
- ポート密度が高い（48ポート以上）。
- High speed (currently, up to 100 GB/s per port).
- 高速（現在、ポートあたり最大100 GB /秒）。
- High throughput (line rate on all ports for Layer 2 and/or Layer 3).
- 高スループット（レイヤー2および/またはレイヤー3のすべてのポートのラインレート）。
- Low latency (in the microsecond or nanosecond range).
- 低レイテンシ（マイクロ秒またはナノ秒の範囲）。
- Low amount of buffer (in the MB range per networking device).
- 少量のバッファー（ネットワークデバイスあたりのMB範囲）。
- Layer 2 and Layer 3 forwarding capability (Layer 3 not mandatory).
- レイヤー2およびレイヤー3の転送機能（レイヤー3は必須ではありません）。
This document provides a methodology for benchmarking data center physical network equipment DUTs, including congestion scenarios, switch buffer analysis, microburst, and head-of-line blocking, while also using a wide mix of traffic conditions. [RFC8238] is a prerequisite for this document, as it contains terminology that is considered normative.
このドキュメントでは、輻輳シナリオ、スイッチバッファー分析、マイクロバースト、ヘッドオブラインブロッキングなど、データセンターの物理ネットワーク機器のDUTをベンチマークする方法と、さまざまなトラフィック条件を使用する方法について説明します。 [RFC8238]には規範と見なされる用語が含まれているため、このドキュメントの前提条件です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following format is used in Sections 2 through 6 of this document:
次の形式は、このドキュメントのセクション2〜6で使用されています。
- Objective
- 目的
- Methodology
- 方法論
- Reporting Format
- レポート形式
For each test methodology described in this document, it is critical that repeatability of the results be obtained. The recommendation is to perform enough iterations of the given test and to make sure that the result is consistent. This is especially important in the context of the tests described in Section 3, as the buffering testing has historically been the least reliable. The number of iterations SHOULD be explicitly reported. The relative standard deviation SHOULD be below 10%.
このドキュメントで説明する各テスト方法では、結果の再現性を確保することが重要です。推奨されるのは、所定のテストを十分に繰り返し実行し、結果が一貫していることを確認することです。これは、これまでバッファリングテストの信頼性が最も低いため、セクション3で説明したテストのコンテキストで特に重要です。反復回数は明示的に報告する必要があります（SHOULD）。相対標準偏差は10％未満である必要があります。
The objective of this test is to provide a "maximum rate" test for the performance values for throughput, latency, and jitter. It is meant to provide (1) the tests to perform and (2) methodology for verifying that a DUT is capable of forwarding packets at line rate under non-congested conditions.
このテストの目的は、スループット、レイテンシ、ジッターのパフォーマンス値の「最大レート」テストを提供することです。これは、（1）実行するテスト、および（2）DUTが輻輳していない条件下でラインレートでパケットを転送できることを確認する方法を提供することを目的としています。
A traffic generator SHOULD be connected to all ports on the DUT. Two tests MUST be conducted: (1) a port-pair test [RFC2544] [RFC3918] and (2) a test using a full-mesh DUT [RFC2889] [RFC3918].
トラフィックジェネレータは、DUTのすべてのポートに接続する必要があります（SHOULD）。 2つのテストを実行する必要があります：（1）ポートペアテスト[RFC2544] [RFC3918]および（2）フルメッシュDUT [RFC2889] [RFC3918]を使用したテスト。
For all tests, the traffic generator's sending rate MUST be less than or equal to 99.98% of the nominal value of the line rate (with no further Parts Per Million (PPM) adjustment to account for interface clock tolerances), to ensure stressing of the DUT in reasonable worst-case conditions (see [RFC8238], Section 5 for more details). Test results at a lower rate MAY be provided for better understanding of performance increase in terms of latency and jitter when the rate is lower than 99.98%. The receiving rate of the traffic SHOULD be captured during this test as a percentage of line rate.
すべてのテストにおいて、トラフィックジェネレーターの送信レートは、ラインレートの公称値の99.98％以下でなければなりません（インターフェイスクロックの許容誤差を考慮するための100万分の1（PPM）調整はこれ以上ありません）。妥当な最悪の条件でDUT（詳細については[RFC8238]、セクション5を参照）。レートが99.98％未満の場合、レイテンシとジッターの観点からパフォーマンスの向上をよりよく理解するために、より低いレートでのテスト結果が提供される場合があります。トラフィックの受信レートは、このテスト中にラインレートのパーセンテージとしてキャプチャする必要があります（SHOULD）。
The test MUST provide the statistics of minimum, average, and maximum of the latency distribution, for the exact same iteration of the test.
テストは、テストのまったく同じ反復に対して、レイテンシ分布の最小、平均、および最大の統計を提供する必要があります。
The test MUST provide the statistics of minimum, average, and maximum of the jitter distribution, for the exact same iteration of the test.
テストは、テストのまったく同じ反復について、ジッター分布の最小、平均、および最大の統計を提供する必要があります。
Alternatively, when a traffic generator cannot be connected to all ports on the DUT, a snake test MUST be used for line-rate testing, excluding latency and jitter, as those would become irrelevant. The snake test is performed as follows:
または、トラフィックジェネレーターをDUTのすべてのポートに接続できない場合、ラインレートテストにはスネークテストを使用する必要があります（レイテンシとジッターは無関係になるため）。ヘビテストは次のように実行されます。
- Connect the first and last port of the DUT to a traffic generator.
- DUTの最初と最後のポートをトラフィックジェネレーターに接続します。
- Connect, back to back and sequentially, all the ports in between: port 2 to port 3, port 4 to port 5, etc., to port N-2 to port N-1, where N is the total number of ports of the DUT.
- ポート2からポート3、ポート4からポート5など、ポートN-2からポートN-1までの間のすべてのポートを順番に接続します。Nはポートの合計数です。 DUT。
- Configure port 1 and port 2 in the same VLAN X, port 3 and port 4 in the same VLAN Y, etc., and port N-1 and port N in the same VLAN Z.
- 同じVLAN Xにポート1とポート2、同じVLAN Yにポート3とポート4、さらに同じVLAN ZにポートN-1とポートNを構成します。
This snake test provides the capability to test line rate for Layer 2 and Layer 3 [RFC2544] [RFC3918] in instances where a traffic generator with only two ports is available. Latency and jitter are not to be considered for this test.
このスネークテストは、2つのポートしか持たないトラフィックジェネレーターが利用可能な場合に、レイヤー2およびレイヤー3 [RFC2544] [RFC3918]のラインレートをテストする機能を提供します。このテストでは、待ち時間とジッターは考慮されません。
The report MUST include the following:
レポートには以下を含める必要があります。
- Physical-layer calibration information, as defined in [RFC8238], Section 4.
- [RFC8238]、セクション4で定義されている物理層のキャリブレーション情報。
- Number of ports used.
- 使用されているポートの数。
- Reading for "throughput received as a percentage of bandwidth", while sending 99.98% of the nominal value of the line rate on each port, for each packet size from 64 bytes to 9216 bytes. As guidance, with a packet-size increment of 64 bytes between each iteration being ideal, 256-byte and 512-byte packets are also often used. The most common packet-size ordering for the report is 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes, 1518 bytes, 4096 bytes, 8000 bytes, and 9216 bytes.
-「帯域幅のパーセンテージとして受信したスループット」を読み取り、64バイトから9216バイトまでの各パケットサイズについて、各ポートのラインレートの公称値の99.98％を送信します。ガイダンスとして、各反復間のパケットサイズの増分が64バイトであることが理想的であり、256バイトおよび512バイトのパケットもよく使用されます。レポートの最も一般的なパケットサイズの順序は、64バイト、128バイト、256バイト、512バイト、1024バイト、1518バイト、4096バイト、8000バイト、および9216バイトです。
The pattern for testing can be expressed using [RFC6985].
テストのパターンは、[RFC6985]を使用して表現できます。
- Throughput needs to be expressed as a percentage of total transmitted frames.
- スループットは、送信されたフレーム全体のパーセンテージとして表す必要があります。
- Packet drops MUST be expressed as a count of packets and SHOULD be expressed as a percentage of line rate.
- パケットドロップはパケットの数として表現する必要があり、ラインレートのパーセンテージとして表現する必要があります（SHOULD）。
- For latency and jitter, values are expressed in units of time (usually microseconds or nanoseconds), reading across packet sizes from 64 bytes to 9216 bytes.
- レイテンシとジッターの場合、値は時間単位（通常はマイクロ秒またはナノ秒）で表され、64バイトから9216バイトまでのパケットサイズで読み取られます。
- For latency and jitter, provide minimum, average, and maximum values. If different iterations are done to gather the minimum, average, and maximum values, this SHOULD be specified in the report, along with a justification for why the information could not have been gathered in the same test iteration.
- 待ち時間とジッターについては、最小値、平均値、および最大値を指定します。最小値、平均値、最大値を収集するために異なる反復が行われる場合、同じテスト反復で情報を収集できなかった理由の正当化とともに、これをレポートで指定する必要があります（SHOULD）。
- For jitter, a histogram describing the population of packets measured per latency or latency buckets is RECOMMENDED.
- ジッタについては、レイテンシまたはレイテンシバケットごとに測定されたパケットの数を表すヒストグラムが推奨されます。
- The tests for throughput, latency, and jitter MAY be conducted as individual independent trials, with proper documentation provided in the report, but SHOULD be conducted at the same time.
- スループット、レイテンシ、ジッターのテストは、個別の独立した試験として実施され、レポートには適切な文書が提供されますが、同時に実施する必要があります（SHOULD）。
- The methodology assumes that the DUT has at least nine ports, as certain methodologies require nine or more ports.
- 特定の方法では9つ以上のポートが必要になるため、この方法では、DUTに少なくとも9つのポートがあることを前提としています。
The objective of this test is to measure the size of the buffer of a DUT under typical/many/multiple conditions. Buffer architectures between multiple DUTs can differ and include egress buffering, shared egress buffering SoC (Switch-on-Chip), ingress buffering, or a combination thereof. The test methodology covers the buffer measurement, regardless of buffer architecture used in the DUT.
このテストの目的は、典型的な/多くの/複数の条件下でDUTのバッファーのサイズを測定することです。複数のDUT間のバッファアーキテクチャは異なる場合があり、出力バッファリング、共有出力バッファリングSoC（スイッチオンチップ）、入力バッファリング、またはそれらの組み合わせが含まれます。テスト方法は、DUTで使用されるバッファアーキテクチャに関係なく、バッファ測定をカバーします。
A traffic generator MUST be connected to all ports on the DUT. The methodology for measuring buffering for a data center switch is based on using known congestion of known fixed packet size, along with maximum latency value measurements. The maximum latency will increase until the first packet drop occurs. At this point, the maximum latency value will remain constant. This is the point of inflection of this maximum latency change to a constant value. There MUST be multiple ingress ports receiving a known amount of frames at a known fixed size, destined for the same egress port in order to create a known congestion condition. The total amount of packets sent from the oversubscribed port minus one, multiplied by the packet size, represents the maximum port buffer size at the measured inflection point.
トラフィックジェネレーターは、DUTのすべてのポートに接続する必要があります。データセンタースイッチのバッファリングを測定する方法は、既知の固定パケットサイズの既知の輻輳と最大遅延値の測定に基づいています。最初のパケットドロップが発生するまで、最大遅延が増加します。この時点で、最大レイテンシ値は一定のままです。これは、この最大レイテンシの変化が一定値に変化するポイントです。既知の輻輳状態を作成するために、既知の固定サイズで既知の量のフレームを受信する、同じ出力ポート宛の複数の入力ポートが存在する必要があります。オーバーサブスクライブされたポートから送信されたパケットの合計から1を引いたものに、パケットサイズを掛けると、測定された変曲点での最大ポートバッファサイズを表します。
Note that the tests described in procedures 1), 2), 3), and 4) in this section have iterations called "first iteration", "second iteration", and "last iteration". The idea is to show the first two iterations so the reader understands the logic of how to keep incrementing the iterations. The last iteration shows the end state of the variables.
このセクションの手順1）、2）、3）、および4）で説明されているテストには、「最初の反復」、「2番目の反復」、および「最後の反復」と呼ばれる反復があることに注意してください。アイデアは、最初の2つの反復を表示して、反復を増分し続ける方法のロジックを読者が理解できるようにすることです。最後の反復は、変数の終了状態を示しています。
1) Measure the highest buffer efficiency.
1）最高のバッファー効率を測定します。
o First iteration: Ingress port 1 sending 64-byte packets at line rate to egress port 2, while port 3 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size of 64 bytes to egress port 2. Measure the buffer size value of the number of frames sent from the port sending the oversubscribed traffic up to the inflection point multiplied by the frame size.
o 最初の反復：入力ポート1が64バイトのパケットをラインレートで出力ポート2に送信し、ポート3は既知の少量のオーバーサブスクリプショントラフィック（1％推奨）を64バイトの同じパケットサイズで出力ポート2に送信しています。オーバーサブスクライブされたトラフィックを送信するポートから、変曲点までに送信されたフレーム数のフレームサイズを掛けたバッファーサイズ値。
o Second iteration: Ingress port 1 sending 65-byte packets at line rate to egress port 2, while port 3 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size of 65 bytes to egress port 2. Measure the buffer size value of the number of frames sent from the port sending the oversubscribed traffic up to the inflection point multiplied by the frame size.
o 2回目の反復：入力ポート1が65バイトのパケットをラインレートで出力ポート2に送信し、ポート3は65バイトの同じパケットサイズで既知の少量のオーバーサブスクリプショントラフィック（1％推奨）を出力ポート2に送信しています。オーバーサブスクライブされたトラフィックを送信するポートから、変曲点までに送信されたフレーム数のフレームサイズを掛けたバッファーサイズ値。
o Last iteration: Ingress port 1 sending packets of size B bytes at line rate to egress port 2, while port 3 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size of B bytes to egress port 2. Measure the buffer size value of the number of frames sent from the port sending the oversubscribed traffic up to the inflection point multiplied by the frame size.
o 最後の反復：入力ポート1はサイズBバイトのパケットをラインレートで出力ポート2に送信し、ポート3は同じサイズのBバイトの既知の少量のオーバーサブスクリプショントラフィック（1％推奨）を出力ポート2に送信します。オーバーサブスクライブされたトラフィックを送信するポートからフレームのサイズを乗じた変曲点までに送信されたフレームの数のバッファーサイズ値を測定します。
When the B value is found to provide the largest buffer size, then size B allows the highest buffer efficiency.
Bの値が最大のバッファーサイズを提供することがわかった場合、サイズBで最大のバッファー効率が得られます。
2) Measure maximum port buffer size.
2）最大ポートバッファーサイズを測定します。
At fixed packet size B as determined in procedure 1), for a fixed default Differentiated Services Code Point (DSCP) / Class of Service (CoS) value of 0 and for unicast traffic, proceed with the following:
手順1）で決定された固定パケットサイズBで、固定のデフォルトのDiffServコードポイント（DSCP）/サービスクラス（CoS）値が0の場合、およびユニキャストトラフィックの場合は、次の手順に進みます。
o First iteration: Ingress port 1 sending line rate to egress port 2, while port 3 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size to egress port 2. Measure the buffer size value by multiplying the number of extra frames sent by the frame size.
o 最初の反復：入力ポート1がラインレートを出力ポート2に送信し、ポート3は同じパケットサイズの既知の少量のオーバーサブスクリプショントラフィック（1％推奨）を出力ポート2に送信します。数値を掛けてバッファーサイズ値を測定しますフレームサイズで送信された追加フレームの数。
o Second iteration: Ingress port 2 sending line rate to egress port 3, while port 4 is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size to egress port 3. Measure the buffer size value by multiplying the number of extra frames sent by the frame size.
o 2回目の反復：入力ポート2がラインレートを出力ポート3に送信する一方で、ポート4は同じパケットサイズの既知の少量のオーバーサブスクリプショントラフィック（1％推奨）を出力ポート3に送信します。数値を掛けてバッファーサイズ値を測定しますフレームサイズで送信された追加フレームの数。
o Last iteration: Ingress port N-2 sending line rate to egress port N-1, while port N is sending a known low amount of oversubscription traffic (1% recommended) with the same packet size to egress port N. Measure the buffer size value by multiplying the number of extra frames sent by the frame size.
o 最後の反復：入力ポートN-2が出力ポートN-1にラインレートを送信しながら、ポートNが同じパケットサイズで既知の少量のオーバーサブスクリプショントラフィック（1％推奨）を出力ポートNに送信しています。バッファーサイズ値を測定します。送信された余分なフレームの数にフレームサイズを掛けます。
This test series MAY be repeated using all different DSCP/CoS values of traffic, and then using multicast traffic, in order to find out if there is any DSCP/CoS impact on the buffer size.
バッファサイズにDSCP / CoSの影響があるかどうかを確認するために、トラフィックのすべての異なるDSCP / CoS値を使用して、次にマルチキャストトラフィックを使用して、この一連のテストを繰り返すことができます。
3) Measure maximum port pair buffer sizes.
3）ポートペアの最大バッファーサイズを測定します。
o First iteration: Ingress port 1 sending line rate to egress port 2, ingress port 3 sending line rate to egress port 4, etc. Ingress port N-1 and port N will oversubscribe, at 1% of line rate, egress port 2 and port 3, respectively. Measure the buffer size value by multiplying the number of extra frames sent by the frame size for each egress port.
o 最初の反復：入力ポート1がラインレートを出力ポート2に送信し、入力ポート3がラインレートを出力ポート4に送信する、など。入力ポートN-1とポートNは、ラインレートの1％で、出力ポート2とポートをオーバーサブスクライブします。 3、それぞれ。送信された余分なフレームの数に、各出力ポートのフレームサイズを掛けて、バッファーサイズの値を測定します。
o Second iteration: Ingress port 1 sending line rate to egress port 2, ingress port 3 sending line rate to egress port 4, etc. Ingress port N-1 and port N will oversubscribe, at 1% of line rate, egress port 4 and port 5, respectively. Measure the buffer size value by multiplying the number of extra frames sent by the frame size for each egress port.
o 2回目の反復：入力ポート1がラインレートを出力ポート2に送信し、入力ポート3がラインレートを出力ポート4に送信する、など。入力ポートN-1とポートNは、ラインレートの1％で、出力ポート4とポートをオーバーサブスクライブします。 5、それぞれ。送信された余分なフレームの数に、各出力ポートのフレームサイズを掛けて、バッファーサイズの値を測定します。
o Last iteration: Ingress port 1 sending line rate to egress port 2, ingress port 3 sending line rate to egress port 4, etc. Ingress port N-1 and port N will oversubscribe, at 1% of line rate, egress port N-3 and port N-2, respectively. Measure the buffer size value by multiplying the number of extra frames sent by the frame size for each egress port.
o 最後の反復：入力ポート1がラインレートを出力ポート2に送信し、入力ポート3がラインレートを出力ポート4に送信するなど。入力ポートN-1およびポートNは、ラインレートの1％で出力ポートN-3をオーバーサブスクライブします。とポートN-2、それぞれ。送信された余分なフレームの数に、各出力ポートのフレームサイズを掛けて、バッファーサイズの値を測定します。
This test series MAY be repeated using all different DSCP/CoS values of traffic and then using multicast traffic.
この一連のテストは、トラフィックのすべての異なるDSCP / CoS値を使用して、次にマルチキャストトラフィックを使用して繰り返すことができます。
4) Measure maximum DUT buffer size with many-to-one ports.
4）多対1のポートで最大DUTバッファーサイズを測定します。
o First iteration: Ingress ports 1,2,... N-1 each sending [(1/[N-1])*99.98]+[1/[N-1]] % of line rate per port to egress port N.
o 最初の反復：入力ポート1、2、... N-1それぞれが[（1 / [N-1]）* 99.98] + [1 / [N-1]]％をポートあたりのラインレートの出力ポートNに送信。
o Second iteration: Ingress ports 2,... N each sending [(1/[N-1])*99.98]+[1/[N-1]] % of line rate per port to egress port 1.
o 2回目の反復：入力ポート2、... Nそれぞれが[（1 / [N-1]）* 99.98] + [1 / [N-1]]％をポートあたりのラインレートの％出力ポート1に送信します。
o Last iteration: Ingress ports N,1,2...N-2 each sending [(1/[N-1])*99.98]+[1/[N-1]] % of line rate per port to egress port N-1.
o 最後の反復：入力ポートN、1,2 ... N-2それぞれが[（1 / [N-1]）* 99.98] + [1 / [N-1]]％をポートあたりのラインレートの出力ポートに送信N-1。
This test series MAY be repeated using all different CoS values of traffic and then using multicast traffic.
この一連のテストは、トラフィックのすべての異なるCoS値を使用して、次にマルチキャストトラフィックを使用して繰り返すことができます。
Unicast traffic, and then multicast traffic, SHOULD be used in order to determine the proportion of buffer for the documented selection of tests. Also, the CoS value for the packets SHOULD be provided for each test iteration, as the buffer allocation size MAY differ per CoS value. It is RECOMMENDED that the ingress and egress ports be varied in a random but documented fashion in multiple tests in order to measure the buffer size for each port of the DUT.
文書化されたテストの選択に対するバッファの割合を決定するために、ユニキャストトラフィック、次にマルチキャストトラフィックを使用する必要があります（SHOULD）。また、バッファ割り当てサイズはCoS値ごとに異なる場合があるため、パケットのCoS値は、テストの反復ごとに提供する必要があります（SHOULD）。 DUTの各ポートのバッファサイズを測定するために、複数のテストで入力ポートと出力ポートをランダムに変化させることをお勧めしますが、文書化されています。
The report MUST include the following:
レポートには以下を含める必要があります。
- The packet size used for the most efficient buffer used, along with the DSCP/CoS value.
- 使用される最も効率的なバッファに使用されるパケットサイズとDSCP / CoS値。
- The maximum port buffer size for each port.
- 各ポートの最大ポートバッファサイズ。
- The maximum DUT buffer size.
- 最大DUTバッファサイズ。
- The packet size used in the test.
- テストで使用されるパケットサイズ。
- The amount of oversubscription, if different than 1%.
- オーバーサブスクリプションの量（1％と異なる場合）。
- The number of ingress and egress ports, along with their location on the DUT.
- 入力ポートと出力ポートの数、およびDUT上の位置。
- The repeatability of the test needs to be indicated: the number of iterations of the same test and the percentage of variation between results for each of the tests (min, max, avg).
- テストの再現性を示す必要があります。同じテストの反復回数と、各テストの結果（min、max、avg）間の変動の割合です。
The percentage of variation is a metric providing a sense of how big the difference is between the measured value and the previous values.
変動のパーセンテージは、測定値と以前の値の差がどれほど大きいかを示す指標です。
For example, for a latency test where the minimum latency is measured, the percentage of variation (PV) of the minimum latency will indicate by how much this value has varied between the current test executed and the previous one.
たとえば、最小レイテンシが測定されるレイテンシテストの場合、最小レイテンシの変動率（PV）は、この値が現在実行されているテストと前回のテストとの間でどれだけ変化したかを示します。
PV = ((x2-x1)/x1)*100, where x2 is the minimum latency value in the
current test and x1 is the minimum latency value obtained in the
previous test.
The same formula is used for maximum and average variations measured.
同じ式が測定された最大および平均変動に使用されます。
The objective of this test is to find the maximum amount of packet bursts that a DUT can sustain under various configurations.
このテストの目的は、DUTがさまざまな構成で維持できるパケットバーストの最大量を見つけることです。
This test provides additional methodology that supplements the tests described in [RFC1242], [RFC2432], [RFC2544], [RFC2889], and [RFC3918].
このテストは、[RFC1242]、[RFC2432]、[RFC2544]、[RFC2889]、および[RFC3918]で説明されているテストを補足する追加の方法を提供します。
- All bursts should be sent with 100% intensity. Note: "Intensity" is defined in [RFC8238], Section 6.1.1.
- すべてのバーストは100％の強度で送信する必要があります。注：「強度」は[RFC8238]のセクション6.1.1で定義されています。
- All ports of the DUT must be used for this test.
- このテストでは、DUTのすべてのポートを使用する必要があります。
- It is recommended that all ports be tested simultaneously.
- すべてのポートを同時にテストすることをお勧めします。
A traffic generator MUST be connected to all ports on the DUT. In order to cause congestion, two or more ingress ports MUST send bursts of packets destined for the same egress port. The simplest of the setups would be two ingress ports and one egress port (2 to 1).
トラフィックジェネレーターは、DUTのすべてのポートに接続する必要があります。輻輳を引き起こすために、2つ以上の入力ポートは同じ出力ポート宛てのパケットのバーストを送信する必要があります。最も簡単な設定は、2つの入力ポートと1つの出力ポート（2から1）です。
The burst MUST be sent with an intensity (as defined in [RFC8238], Section 6.1.1) of 100%, meaning that the burst of packets will be sent with a minimum interpacket gap. The amount of packets contained in the burst will be trial variable and increase until there is a non-zero packet loss measured. The aggregate amount of packets from all the senders will be used to calculate the maximum microburst amount that the DUT can sustain.
バーストは100％の強度（[RFC8238]、セクション6.1.1で定義）で送信する必要があります。つまり、パケットのバーストは最小のパケット間ギャップで送信されます。バーストに含まれるパケットの量は試用変数であり、測定されたゼロ以外のパケット損失が測定されるまで増加します。すべての送信者からのパケットの総量は、DUTが維持できる最大マイクロバースト量の計算に使用されます。
It is RECOMMENDED that the ingress and egress ports be varied in multiple tests in order to measure the maximum microburst capacity.
最大マイクロバースト容量を測定するために、複数のテストで入力ポートと出力ポートを変えることをお勧めします。
The intensity of a microburst (see [RFC8238], Section 6.1.1) MAY be varied in order to obtain the microburst capacity at various ingress rates.
マイクロバーストの強度（[RFC8238]、セクション6.1.1を参照）は、さまざまな進入レートでマイクロバースト容量を取得するために変化させることができます。
It is RECOMMENDED that all ports on the DUT be tested simultaneously, and in various configurations, in order to understand all the combinations of ingress ports, egress ports, and intensities.
入力ポート、出力ポート、および強度のすべての組み合わせを理解するために、DUTのすべてのポートを同時にさまざまな構成でテストすることをお勧めします。
An example would be:
例は次のとおりです。
o First iteration: N-1 ingress ports sending to one egress port.
o 最初の反復：1つの出力ポートに送信するN-1入力ポート。
o Second iteration: N-2 ingress ports sending to two egress ports.
o 2回目の反復：2つの出力ポートに送信するN-2入力ポート。
o Last iteration: Two ingress ports sending to N-2 egress ports.
o 最後の反復：N-2出力ポートに送信する2つの入力ポート。
The report MUST include the following:
レポートには以下を含める必要があります。
- The maximum number of packets received per ingress port with the maximum burst size obtained with zero packet loss.
- パケット損失なしで取得された最大バーストサイズでの、入力ポートごとに受信されたパケットの最大数。
- The packet size used in the test.
- テストで使用されるパケットサイズ。
- The number of ingress and egress ports, along with their location on the DUT.
- 入力ポートと出力ポートの数、およびDUT上の位置。
- The repeatability of the test needs to be indicated: the number of iterations of the same test and the percentage of variation between results (min, max, avg).
- テストの再現性を示す必要があります。同じテストの反復回数と結果間の変動のパーセンテージ（最小、最大、平均）。
Head-of-line blocking (HOLB) is a performance-limiting phenomenon that occurs when packets are held up by the first packet ahead waiting to be transmitted to a different output port. This is defined in RFC 2889, Section 5.5 ("Congestion Control"). This section expands on RFC 2889 in the context of data center benchmarking.
ヘッドオブラインブロッキング（HOLB）は、別の出力ポートへの送信を待機している最初のパケットによってパケットが保留されると発生するパフォーマンス制限現象です。これはRFC 2889のセクション5.5（「輻輳制御」）で定義されています。このセクションでは、データセンターのベンチマークのコンテキストでRFC 2889を拡張します。
The objective of this test is to understand the DUT's behavior in the HOLB scenario and measure the packet loss.
このテストの目的は、HOLBシナリオにおけるDUTの動作を理解し、パケット損失を測定することです。
The differences between this HOLB test and RFC 2889 are as follows:
このHOLBテストとRFC 2889の違いは次のとおりです。
- This HOLB test starts with eight ports in two groups of four ports each, instead of four ports (as compared with Section 5.5 of RFC 2889).
- このHOLBテストは、4つのポートではなく、4つのポートからなる2つのグループの8つのポートから始まります（RFC 2889のセクション5.5と比較）。
- This HOLB test shifts all the port numbers by one in a second iteration of the test; this is new, as compared to the HOLB test described in RFC 2889. The shifting port numbers continue until all ports are the first in the group; the purpose of this is to make sure that all permutations are tested in order to cover differences in behavior in the SoC of the DUT.
- このHOLBテストは、テストの2回目の反復ですべてのポート番号を1つずつシフトします。これは、RFC 2889で説明されているHOLBテストと比較すると新しいものです。ポート番号のシフトは、すべてのポートがグループの最初になるまで続きます。これの目的は、DUTのSoCでの動作の違いをカバーするために、すべての順列がテストされることを確認することです。
- Another test within this HOLB test expands the group of ports, such that traffic is divided among four ports instead of two (25% instead of 50% per port).
- このHOLBテスト内の別のテストでは、ポートのグループを拡張して、トラフィックを2つではなく4つのポートに分割します（ポートごとに50％ではなく25％）。
- Section 5.3 lists requirements that supplement the requirements listed in RFC 2889, Section 5.5.
- セクション5.3には、RFC 2889のセクション5.5にリストされている要件を補足する要件がリストされています。
In order to cause congestion in the form of HOLB, groups of four ports are used. A group has two ingress ports and two egress ports. The first ingress port MUST have two flows configured, each going to a different egress port. The second ingress port will congest the second egress port by sending line rate. The goal is to measure if there is loss on the flow for the first egress port, which is not oversubscribed.
HOLBの形で輻輳を引き起こすために、4つのポートのグループが使用されます。グループには2つの入力ポートと2つの出力ポートがあります。最初の入力ポートには、それぞれ異なる出力ポートに向かう2つのフローが設定されている必要があります。 2番目の入力ポートは、ラインレートを送信することによって2番目の出力ポートを輻輳させます。目標は、オーバーサブスクライブされていない最初の出力ポートのフローに損失があるかどうかを測定することです。
A traffic generator MUST be connected to at least eight ports on the DUT and SHOULD be connected using all the DUT ports.
トラフィックジェネレーターはDUTの少なくとも8つのポートに接続する必要があり、すべてのDUTポートを使用して接続する必要があります。
Note that the tests described in procedures 1) and 2) in this section have iterations called "first iteration", "second iteration", and "last iteration". The idea is to show the first two iterations so the reader understands the logic of how to keep incrementing the iterations. The last iteration shows the end state of the variables.
このセクションの手順1）および2）で説明されているテストには、「最初の反復」、「2番目の反復」、および「最後の反復」と呼ばれる反復があることに注意してください。アイデアは、最初の2つの反復を表示して、反復を増分し続ける方法のロジックを読者が理解できるようにすることです。最後の反復は、変数の終了状態を示しています。
1) Measure two groups with eight DUT ports.
1）8つのDUTポートで2つのグループを測定します。
o First iteration: Measure the packet loss for two groups with consecutive ports.
o 最初の反復：連続するポートを持つ2つのグループのパケット損失を測定します。
The composition of the first group is as follows:
最初のグループの構成は次のとおりです。
Ingress port 1 sending 50% of traffic to egress port 3 and ingress port 1 sending 50% of traffic to egress port 4. Ingress port 2 sending line rate to egress port 4. Measure the amount of traffic loss for the traffic from ingress port 1 to egress port 3.
入力ポート1がトラフィックの50％を出力ポート3に送信し、入力ポート1が50％のトラフィックを出力ポート4に送信します。入力ポート2がラインレートを出力ポート4に送信します。入力ポート1からのトラフィックのトラフィック損失量を測定します。出力ポート3。
The composition of the second group is as follows:
2番目のグループの構成は次のとおりです。
Ingress port 5 sending 50% of traffic to egress port 7 and ingress port 5 sending 50% of traffic to egress port 8. Ingress port 6 sending line rate to egress port 8. Measure the amount of traffic loss for the traffic from ingress port 5 to egress port 7.
入力ポート5がトラフィックの50％を出力ポート7に送信し、入力ポート5が50％のトラフィックを出力ポート8に送信します。入力ポート6がラインレートを出力ポート8に送信します。入力ポート5からのトラフィックのトラフィック損失量を測定します。出力ポート7。
o Second iteration: Repeat the first iteration by shifting all the ports from N to N+1.
o 2番目の反復：すべてのポートをNからN + 1にシフトして、最初の反復を繰り返します。
The composition of the first group is as follows:
最初のグループの構成は次のとおりです。
Ingress port 2 sending 50% of traffic to egress port 4 and ingress port 2 sending 50% of traffic to egress port 5. Ingress port 3 sending line rate to egress port 5. Measure the amount of traffic loss for the traffic from ingress port 2 to egress port 4.
入力ポート2がトラフィックの50％を出力ポート4に送信し、入力ポート2が50％のトラフィックを出力ポート5に送信します。入力ポート3がラインレートを出力ポート5に送信します。入力ポート2からのトラフィックのトラフィック損失量を測定します。出力ポート4。
The composition of the second group is as follows:
2番目のグループの構成は次のとおりです。
Ingress port 6 sending 50% of traffic to egress port 8 and ingress port 6 sending 50% of traffic to egress port 9. Ingress port 7 sending line rate to egress port 9. Measure the amount of traffic loss for the traffic from ingress port 6 to egress port 8.
入力ポート6がトラフィックの50％を出力ポート8に送信し、入力ポート6が50％のトラフィックを出力ポート9に送信します。入力ポート7がラインレートを出力ポート9に送信します。入力ポート6からのトラフィックのトラフィック損失量を測定します。出力ポート8。
o Last iteration: When the first port of the first group is connected to the last DUT port and the last port of the second group is connected to the seventh port of the DUT.
o 最後の反復：最初のグループの最初のポートが最後のDUTポートに接続され、2番目のグループの最後のポートがDUTの7番目のポートに接続されている場合。
Measure the amount of traffic loss for the traffic from ingress port N to egress port 2 and from ingress port 4 to egress port 6.
入力ポートNから出力ポート2へ、および入力ポート4から出力ポート6へのトラフィックのトラフィック損失量を測定します。
2) Measure with N/4 groups with N DUT ports.
2）N DUTポートを備えたN / 4グループで測定します。
The traffic from the ingress port is split across four egress ports (100/4 = 25%).
入力ポートからのトラフィックは4つの出力ポートに分割されます（100/4 = 25％）。
o First iteration: Expand to fully utilize all the DUT ports in increments of four. Repeat the methodology of procedure 1) with all the groups of ports possible to achieve on the device, and measure the amount of traffic loss for each port group.
o 最初の反復：拡大して、すべてのDUTポートを4つずつ完全に利用します。デバイスで実現可能なすべてのポートグループを使用して、手順1）の方法を繰り返し、各ポートグループのトラフィック損失量を測定します。
o Second iteration: Shift by +1 the start of each consecutive port of the port groups.
o 2回目の反復：ポートグループの連続する各ポートの開始を+1シフトします。
o Last iteration: Shift by N-1 the start of each consecutive port of the port groups, and measure the amount of traffic loss for each port group.
o 最後の反復：ポートグループの連続する各ポートの始点をN-1だけシフトし、各ポートグループのトラフィック損失量を測定します。
For each test, the report MUST include the following:
各テストについて、レポートには以下を含める必要があります。
- The port configuration, including the number and location of ingress and egress ports located on the DUT.
- DUTにある入力ポートと出力ポートの数と場所を含むポート構成。
- If HOLB was observed in accordance with the HOLB test described in Section 5.
- セクション5に記載されているHOLBテストに従ってHOLBが観察された場合
- Percent of traffic loss.
- トラフィック損失の割合。
- The repeatability of the test needs to be indicated: the number of iterations of the same test and the percentage of variation between results (min, max, avg).
- テストの再現性を示す必要があります。同じテストの反復回数と結果間の変動のパーセンテージ（最小、最大、平均）。
The objective of this test is to measure the values for TCP Goodput [TCP-INCAST] and latency with a mix of large and small flows. The test is designed to simulate a mixed environment of stateful flows that require high rates of goodput and stateless flows that require low latency. Stateful flows are created by generating TCP traffic, and stateless flows are created using UDP traffic.
このテストの目的は、大小のフローが混在するTCP Goodput [TCP-INCAST]とレイテンシの値を測定することです。このテストは、高レートのグッドプットが必要なステートフルフローと低レイテンシが必要なステートレスフローの混合環境をシミュレートするように設計されています。ステートフルフローはTCPトラフィックを生成することによって作成され、ステートレスフローはUDPトラフィックを使用して作成されます。
In order to simulate the effects of stateless and stateful traffic on the DUT, there MUST be multiple ingress ports receiving traffic destined for the same egress port. There also MAY be a mix of stateful and stateless traffic arriving on a single ingress port. The simplest setup would be two ingress ports receiving traffic destined to the same egress port.
DUTでのステートレスおよびステートフルトラフィックの影響をシミュレートするには、同じ出力ポート宛てのトラフィックを受信する複数の入力ポートが必要です。また、単一の入力ポートに到着するステートフルトラフィックとステートレストラフィックが混在する場合もあります。最も簡単な設定は、同じ出力ポート宛てのトラフィックを受信する2つの入力ポートです。
One ingress port MUST maintain a TCP connection through the ingress port to a receiver connected to an egress port. Traffic in the TCP stream MUST be sent at the maximum rate allowed by the traffic generator. At the same time, the TCP traffic is flowing through the DUT, and the stateless traffic is sent destined to a receiver on the same egress port. The stateless traffic MUST be a microburst of 100% intensity.
1つの入力ポートは、入力ポートを介して、出力ポートに接続されているレシーバーへのTCP接続を維持する必要があります。 TCPストリームのトラフィックは、トラフィックジェネレーターで許可されている最大レートで送信する必要があります。同時に、TCPトラフィックはDUTを流れており、ステートレストラフィックは同じ出力ポートのレシーバーに送信されます。ステートレストラフィックは、100％の強度のマイクロバーストでなければなりません。
It is RECOMMENDED that the ingress and egress ports be varied in multiple tests in order to measure the maximum microburst capacity.
最大マイクロバースト容量を測定するために、複数のテストで入力ポートと出力ポートを変えることをお勧めします。
The intensity of a microburst MAY be varied in order to obtain the microburst capacity at various ingress rates.
マイクロバーストの強度は、さまざまな進入速度でマイクロバースト容量を取得するために、変更される場合があります。
It is RECOMMENDED that all ports on the DUT be used in the test.
DUTのすべてのポートをテストで使用することをお勧めします。
The tests described below have iterations called "first iteration", "second iteration", and "last iteration". The idea is to show the first two iterations so the reader understands the logic of how to keep incrementing the iterations. The last iteration shows the end state of the variables.
以下で説明するテストには、「最初の反復」、「2番目の反復」、および「最後の反復」と呼ばれる反復があります。アイデアは、最初の2つの反復を表示して、反復を増分し続ける方法のロジックを読者が理解できるようにすることです。最後の反復は、変数の終了状態を示しています。
For example:
例えば：
Stateful traffic port variation (TCP traffic):
ステートフルトラフィックポートのバリエーション（TCPトラフィック）：
TCP traffic needs to be generated for this test. During the iterations, the number of egress ports MAY vary as well.
このテストでは、TCPトラフィックを生成する必要があります。反復中に、出力ポートの数も変わる場合があります。
o First iteration: One ingress port receiving stateful TCP traffic and one ingress port receiving stateless traffic destined to one egress port.
o 最初の反復：1つの入力ポートがステートフルTCPトラフィックを受信し、1つの入力ポートが1つの出力ポート宛てのステートレストラフィックを受信します。
o Second iteration: Two ingress ports receiving stateful TCP traffic and one ingress port receiving stateless traffic destined to one egress port.
o 2回目の反復：ステートフルTCPトラフィックを受信する2つの入力ポートと、1つの出力ポート宛てのステートレストラフィックを受信する1つの入力ポート。
o Last iteration: N-2 ingress ports receiving stateful TCP traffic and one ingress port receiving stateless traffic destined to one egress port.
o 最後の反復：ステートフルTCPトラフィックを受信するN-2入力ポート、および1つの出力ポート宛てのステートレストラフィックを受信する1つの入力ポート。
Stateless traffic port variation (UDP traffic):
ステートレストラフィックポートのバリエーション（UDPトラフィック）：
UDP traffic needs to be generated for this test. During the iterations, the number of egress ports MAY vary as well.
このテストでは、UDPトラフィックを生成する必要があります。反復中に、出力ポートの数も変わる場合があります。
o First iteration: One ingress port receiving stateful TCP traffic and one ingress port receiving stateless traffic destined to one egress port.
o 最初の反復：1つの入力ポートがステートフルTCPトラフィックを受信し、1つの入力ポートが1つの出力ポート宛てのステートレストラフィックを受信します。
o Second iteration: One ingress port receiving stateful TCP traffic and two ingress ports receiving stateless traffic destined to one egress port.
o 2回目の反復：1つの入力ポートがステートフルTCPトラフィックを受信し、2つの入力ポートが1つの出力ポート宛てのステートレストラフィックを受信します。
o Last iteration: One ingress port receiving stateful TCP traffic and N-2 ingress ports receiving stateless traffic destined to one egress port.
o 最後の反復：1つの入力ポートがステートフルTCPトラフィックを受信し、N-2入力ポートが1つの出力ポート宛てのステートレストラフィックを受信します。
The report MUST include the following:
レポートには以下を含める必要があります。
- Number of ingress and egress ports, along with designation of stateful or stateless flow assignment.
- 入力ポートと出力ポートの数、およびステートフルまたはステートレスのフロー割り当ての指定。
- Stateful flow goodput.
- ステートフルフローのグッドプット。
- Stateless flow latency.
- ステートレスフローレイテンシ。
- The repeatability of the test needs to be indicated: the number of iterations of the same test and the percentage of variation between results (min, max, avg).
- テストの再現性を示す必要があります。同じテストの反復回数と結果間の変動のパーセンテージ（最小、最大、平均）。
Benchmarking activities as described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
このメモに記載されているベンチマーク活動は、専用のアドレススペースと上記のセクションで指定された制約を使用して、実験環境で制御された刺激を使用した技術の特性評価に限定されます。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは独立したテストセットアップであり、テストトラフィックを実稼働ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤ってルーティングする可能性のあるデバイスに接続してはなりません。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT.
さらに、ベンチマークは「ブラックボックス」ベースで実行され、DUTの外部で観測可能な測定のみに依存します。
Special capabilities SHOULD NOT exist in the DUT specifically for benchmarking purposes. Any implications for network security arising from the DUT SHOULD be identical in the lab and in production networks.
特別な機能は、特にベンチマークの目的でDUTに存在すべきではありません。 DUTから生じるネットワークセキュリティへの影響は、ラボと実稼働ネットワークで同じである必要があります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.
[RFC1242] Bradner、S。、「ネットワーク相互接続デバイスのベンチマーク用語」、RFC 1242、DOI 10.17487 / RFC1242、1991年7月、<https://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, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://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, <https://www.rfc-editor.org/info/rfc2544>.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク手法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<https://www.rfc-editor.org/info/rfc2544>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8238] Avramov, L. and J. Rapp, "Data Center Benchmarking Terminology", RFC 8238, DOI 10.17487/RFC8238, August 2017, <https://www.rfc-editor.org/info/rfc8238>.
[RFC8238] Avramov、L。およびJ. Rapp、「Data Center Benchmarking Terminology」、RFC 8238、DOI 10.17487 / RFC8238、2017年8月、<https://www.rfc-editor.org/info/rfc8238>。
[RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, DOI 10.17487/RFC2432, October 1998, <https://www.rfc-editor.org/info/rfc2432>.
[RFC2432] Dubray、K。、「Terminalology for IP Multicast Benchmarking」、RFC 2432、DOI 10.17487 / RFC2432、1998年10月、<https://www.rfc-editor.org/info/rfc2432>。
[RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, DOI 10.17487/RFC2889, August 2000, <https://www.rfc-editor.org/info/rfc2889>.
[RFC2889] Mandeville、R。およびJ. Perser、「LANスイッチングデバイスのベンチマーク手法」、RFC 2889、DOI 10.17487 / RFC2889、2000年8月、<https://www.rfc-editor.org/info/rfc2889>。
[RFC3918] Stopp, D. and B. Hickman, "Methodology for IP Multicast Benchmarking", RFC 3918, DOI 10.17487/RFC3918, October 2004, <https://www.rfc-editor.org/info/rfc3918>.
[RFC3918] Stopp、D。およびB. Hickman、「Methodology for IP Multicast Benchmarking」、RFC 3918、DOI 10.17487 / RFC3918、2004年10月、<https://www.rfc-editor.org/info/rfc3918>。
[RFC6985] Morton, A., "IMIX Genome: Specification of Variable Packet Sizes for Additional Testing", RFC 6985, DOI 10.17487/RFC6985, July 2013, <https://www.rfc-editor.org/info/rfc6985>.
[RFC6985] Morton、A。、「IMIX Genome：Specification of Variable Packet Sizes for Additional Testing」、RFC 6985、DOI 10.17487 / RFC6985、2013年7月、<https://www.rfc-editor.org/info/rfc6985> 。
[TCP-INCAST] Chen, Y., Griffith, R., Zats, D., Joseph, A., and R. Katz, "Understanding TCP Incast and Its Implications for Big Data Workloads", April 2012, <http://yanpeichen.com/ professional/usenixLoginIncastReady.pdf>.
[TCP-INCAST] Chen、Y.、Griffith、R.、Zats、D.、Joseph、A。、およびR. Katz、「Understanding TCP Incast and its Impacts for Big Data Workloads」、2012年4月、<http：/ /yanpeichen.com/ professional / usenixLoginIncastReady.pdf>。
Acknowledgments
謝辞
The authors would like to thank Al Morton and Scott Bradner for their reviews and feedback.
著者は、レビューとフィードバックを提供してくれたAl MortonとScott Bradnerに感謝します。
Authors' Addresses
著者のアドレス
Lucien Avramov Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Lucien Avramov Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: lucien.avramov@gmail.com
Jacob Rapp VMware 3401 Hillview Ave. Palo Alto, CA 94304 United States of America
Jacob Rapp VMware 3401 Hillview Ave. Palo Alto、CA 94304アメリカ合衆国
Email: jhrapp@gmail.com