[要約] RFC 8238は、データセンターのベンチマーク用語に関する要約です。その目的は、データセンターの性能評価や比較を容易にするための共通の用語を提供することです。
Internet Engineering Task Force (IETF) L. Avramov
Request for Comments: 8238 Google
Category: Informational J. Rapp
ISSN: 2070-1721 VMware
August 2017
Data Center Benchmarking Terminology
データセンターのベンチマーク用語
Abstract
概要
The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239). Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.
この情報ドキュメントの目的は、データセンターのベンチマークの定義を確立し、測定手法を説明すること、およびデータセンターのネットワーク機器のパフォーマンス評価に適用可能な新しい用語を紹介することです。このドキュメントは、データセンターのネットワークスイッチとルーターのベンチマークに関する重要な概念を確立し、テスト方法論ドキュメント（RFC 8239）の前提条件です。これらの用語と方法の多くは、元々データセンターで適用されていたテクノロジーが別の場所に導入されているため、このドキュメントの範囲を超えてネットワーク機器に適用できる場合があります。
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/rfc8238.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8238で入手できます。
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 ....................................................4
1.1. Requirements Language ......................................5
1.2. Definition Format ..........................................5
2. Latency .........................................................5
2.1. Definition .................................................5
2.2. Discussion .................................................7
2.3. Measurement Units ..........................................7
3. Jitter ..........................................................8
3.1. Definition .................................................8
3.2. Discussion .................................................8
3.3. Measurement Units ..........................................8
4. Calibration of the Physical Layer ...............................9
4.1. Definition .................................................9
4.2. Discussion .................................................9
4.3. Measurement Units ..........................................9
5. Line Rate ......................................................10
5.1. Definition ................................................10
5.2. Discussion ................................................10
5.3. Measurement Units .........................................11
6. Buffering ......................................................12
6.1. Buffer ....................................................12
6.1.1. Definition .........................................12
6.1.2. Discussion .........................................14
6.1.3. Measurement Units ..................................14
6.2. Incast ....................................................15
6.2.1. Definition .........................................15
6.2.2. Discussion .........................................15
6.2.3. Measurement Units ..................................16
7. Application Throughput: Data Center Goodput ....................16
7.1. Definition ................................................16
7.2. Discussion ................................................16
7.3. Measurement Units .........................................16
8. Security Considerations ........................................17
9. IANA Considerations ............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Acknowledgments ...................................................20
Authors' Addresses ................................................20
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 some 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 may 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]. These benchmarks have largely been focused around various latency attributes and max throughput of the Device Under Test (DUT) being benchmarked. These standards are good at measuring theoretical max throughput, forwarding rates, and latency under testing conditions, but they do not represent real traffic patterns that may affect these networking devices. The data center networking devices covered are switches and routers.
データセンターのトラフィックパターンは均一ではなく、常に変化しています。それらは、データセンターで利用されるアプリケーションの性質と多様性によって決まります。あるデータセンターでは主に東西のトラフィックフロー（データセンター内のサーバーからサーバーへ）、別のデータセンターでは南北（データセンターの外側からサーバーへ）のトラフィックフローが可能ですが、両方を組み合わせることもあります。トラフィックパターンはバースト性があり、多対1、多対多、または1対多のフローを含む場合があります。各フローは、UDPトラフィックとTCPトラフィックの混合を含みながら、小さい遅延に影響されたり、大きいスループットに影響されたりする可能性もあります。これらのすべてが単一のクラスターに共存し、単一のネットワークデバイスを同時に通過する場合があります。ネットワークデバイスのベンチマークテストでは、[RFC1242]、[RFC2432]、[RFC2544]、[RFC2889]、および[RFC3918]が長く使用されています。これらのベンチマークは、主にさまざまなレイテンシ属性とベンチマーク対象のテスト対象デバイス（DUT）の最大スループットに焦点を当てています。これらの標準は、テスト条件下での理論的な最大スループット、転送速度、および遅延の測定には適していますが、これらのネットワーキングデバイスに影響を与える可能性のある実際のトラフィックパターンを表すものではありません。対象となるデータセンターネットワーキングデバイスは、スイッチとルーターです。
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 defines a set of definitions, metrics, and new terminology, including congestion scenarios and switch buffer analysis, and redefines basic definitions in order to represent a wide mix of traffic conditions. The test methodologies are defined in [RFC8239].
このドキュメントでは、輻輳シナリオやスイッチバッファ分析など、一連の定義、メトリック、新しい用語を定義し、さまざまなトラフィック状態を表すために基本的な定義を再定義しています。テスト方法は[RFC8239]で定義されています。
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]で説明されているように解釈されます。
- Term to be defined (e.g., "latency").
- 定義する用語（「待機時間」など）。
- Definition: The specific definition for the term.
- 定義：用語の具体的な定義。
- Discussion: A brief discussion about the term, its application, and any restrictions on measurement procedures.
- ディスカッション：用語、その適用、および測定手順の制限に関する簡単なディスカッション。
- Measurement Units: Methodology for measurements and units used to report measurements of the term in question, if applicable.
- 測定単位：測定の方法論、および該当する場合、問題の用語の測定値を報告するために使用される単位。
Latency is the amount of time it takes a frame to transit the DUT. Latency is measured in units of time (seconds, milliseconds, microseconds, and so on). The purpose of measuring latency is to understand the impact of adding a device in the communication path.
レイテンシは、フレームがDUTを通過するのにかかる時間です。レイテンシは時間の単位（秒、ミリ秒、マイクロ秒など）で測定されます。レイテンシを測定する目的は、通信パスにデバイスを追加した場合の影響を理解することです。
The latency interval can be assessed between different combinations of events, regardless of the type of switching device (bit forwarding, aka cut-through; or a store-and-forward device). [RFC1242] defined latency differently for each of these types of devices.
レイテンシ間隔は、スイッチングデバイスのタイプ（ビット転送、別名カットスルー、またはストアアンドフォワードデバイス）に関係なく、イベントのさまざまな組み合わせの間で評価できます。 [RFC1242]は、これらのタイプのデバイスごとに異なる遅延を定義しました。
Traditionally, the latency measurement definitions are:
従来、レイテンシ測定の定義は次のとおりです。
- FILO (First In Last Out):
- FILO（先入れ先出し）：
The time interval starting when the end of the first bit of the input frame reaches the input port and ending when the last bit of the output frame is seen on the output port.
入力フレームの最初のビットの終わりが入力ポートに到達したときから始まり、出力フレームの最後のビットが出力ポートで確認されたときに終わる時間間隔。
- FIFO (First In First Out):
- FIFO（先入れ先出し）：
The time interval starting when the end of the first bit of the input frame reaches the input port and ending when the start of the first bit of the output frame is seen on the output port. Latency (as defined in [RFC1242]) for bit-forwarding devices uses these events.
入力フレームの最初のビットの終わりが入力ポートに到達したときから始まり、出力フレームの最初のビットの始まりが出力ポートで確認されたときに終わる時間間隔。ビット転送デバイスのレイテンシ（[RFC1242]で定義）は、これらのイベントを使用します。
- LILO (Last In Last Out):
- LILO（最後の最後）：
The time interval starting when the last bit of the input frame reaches the input port and the last bit of the output frame is seen on the output port.
入力フレームの最後のビットが入力ポートに到達し、出力フレームの最後のビットが出力ポートに表示されるときに始まる時間間隔。
- LIFO (Last In First Out):
- LIFO（後入れ先出し）：
The time interval starting when the last bit of the input frame reaches the input port and ending when the first bit of the output frame is seen on the output port. Latency (as defined in [RFC1242]) for store-and-forward devices uses these events.
入力フレームの最後のビットが入力ポートに到達したときから始まり、出力フレームの最初のビットが出力ポートで確認されたときに終わる時間間隔。ストアアンドフォワードデバイスのレイテンシ（[RFC1242]で定義）は、これらのイベントを使用します。
Another possible way to summarize the four definitions above is to refer to the bit positions as they normally occur: input to output.
上記の4つの定義を要約する別の可能な方法は、通常発生するビット位置を参照することです：入力から出力。
- FILO is FL (First bit Last bit).
- FILOはFL（最初のビット最後のビット）です。
- FIFO is FF (First bit First bit).
- FIFOはFF（最初のビット最初のビット）です。
- LILO is LL (Last bit Last bit).
- LILOはLL（最後のビット最後のビット）です。
- LIFO is LF (Last bit First bit).
- LIFOはLF（最後のビット最初のビット）です。
This definition, as explained in this section in the context of data center switch benchmarking, is in lieu of the previous definition of "latency" as provided in RFC 1242, Section 3.8 and quoted here:
この定義は、データセンタースイッチのベンチマークのコンテキストでこのセクションで説明されているように、RFC 1242のセクション3.8で提供され、ここで引用されている「レイテンシ」の以前の定義の代わりです。
For store and forward devices: The time interval starting when the last bit of the input frame reaches the input port and ending when the first bit of the output frame is seen on the output port.
ストアアンドフォワードデバイスの場合：入力フレームの最後のビットが入力ポートに到達したときから始まり、出力フレームの最初のビットが出力ポートに表示されたときに終わる時間間隔。
For bit forwarding devices: The time interval starting when the end of the first bit of the input frame reaches the input port and ending when the start of the first bit of the output frame is seen on the output port.
ビット転送デバイスの場合：入力フレームの最初のビットの終わりが入力ポートに到達したときから始まり、出力フレームの最初のビットの始まりが出力ポートで検出されたときに終わる時間間隔。
To accommodate both types of network devices and hybrids of the two types that have emerged, switch latency measurements made according to this document MUST be measured with the FILO events. FILO will include the latency of the switch and the latency of the frame as well as the serialization delay. It is a picture of the "whole" latency going through the DUT. For applications that are latency sensitive and can function with initial bytes of the frame, FIFO (or, for bit-forwarding devices, latency per RFC 1242) MAY be used. In all cases, the event combinations used in latency measurements MUST be reported.
両方のタイプのネットワークデバイスと出現した2つのタイプのハイブリッドに対応するには、このドキュメントに従って行われたスイッチレイテンシ測定をFILOイベントで測定する必要があります。 FILOには、スイッチのレイテンシ、フレームのレイテンシ、およびシリアル化遅延が含まれます。これは、DUTを通過する「全体」のレイテンシの図です。レイテンシの影響を受けやすく、フレームの最初のバイトで機能するアプリケーションでは、FIFO（または、ビット転送デバイスの場合、RFC 1242によるレイテンシ）を使用できます。すべての場合において、レイテンシ測定で使用されるイベントの組み合わせを報告する必要があります。
As mentioned in Section 2.1, FILO is the most important measuring definition.
セクション2.1で述べたように、FILOは最も重要な測定定義です。
Not all DUTs are exclusively cut-through or store-and-forward. Data center DUTs are frequently store-and-forward for smaller packet sizes and then change to cut-through behavior at specific larger packet sizes. The value of the packet size at which the behavior changes MAY be configurable, depending on the DUT manufacturer. FILO covers both scenarios: store-and-forward and cut-through. The threshold for the change in behavior does not matter for benchmarking, since FILO covers both possible scenarios.
すべてのDUTが排他的にカットスルーまたはストアアンドフォワードであるわけではありません。データセンターのDUTは、小さいパケットサイズでは頻繁にストアアンドフォワードされ、特定の大きいパケットサイズでカットスルー動作に変更されます。動作が変化するパケットサイズの値は、DUTの製造元に応じて設定可能になる場合があります。 FILOは、ストアアンドフォワードとカットスルーの両方のシナリオをカバーしています。 FILOは両方の可能なシナリオをカバーするため、動作の変化のしきい値はベンチマークにとって重要ではありません。
The LIFO mechanism can be used with store-and-forward switches but not with cut-through switches, as it will provide negative latency values for larger packet sizes because LIFO removes the serialization delay. Therefore, this mechanism MUST NOT be used when comparing the latencies of two different DUTs.
LIFOはシリアル化遅延を排除するため、LIFOメカニズムはストアアンドフォワードスイッチで使用できますが、カットスルースイッチでは使用できません。大きなパケットサイズに対して負のレイテンシ値を提供するためです。したがって、このメカニズムは、2つの異なるDUTのレイテンシを比較するときに使用してはなりません（MUST NOT）。
The measuring methods to use for benchmarking purposes are as follows:
ベンチマークの目的で使用する測定方法は次のとおりです。
1) FILO MUST be used as a measuring method, as this will include the latency of the packet; today, the application commonly needs to read the whole packet to process the information and take an action.
1）パケットのレイテンシが含まれるため、測定方法としてFILOを使用する必要があります。今日、アプリケーションは通常、パケット全体を読み取って情報を処理し、アクションを実行する必要があります。
2) FIFO MAY be used for certain applications able to process the data as the first bits arrive -- for example, with a Field-Programmable Gate Array (FPGA).
2）FIFOは、最初のビットが到着したときにデータを処理できる特定のアプリケーションに使用できます-たとえば、フィールドプログラマブルゲートアレイ（FPGA）。
3) LIFO MUST NOT be used because, unlike all the other methods, it subtracts the latency of the packet.
3）LIFOは、他のすべての方法とは異なり、パケットの遅延を差し引くため、使用してはなりません（MUST NOT）。
In the context of the data center, jitter is synonymous with the common term "delay variation". It is derived from multiple measurements of one-way delay, as described in RFC 3393. The mandatory definition of "delay variation" is the Packet Delay Variation (PDV) as defined in Section 4.2 of [RFC5481]. When considering a stream of packets, the delays of all packets are subtracted from the minimum delay over all packets in the stream. This facilitates the assessment of the range of delay variation (Max - Min) or a high percentile of PDV (99th percentile, for robustness against outliers).
データセンターのコンテキストでは、ジッターは一般的な用語「遅延変動」と同義です。これは、RFC 3393で説明されているように、一方向の遅延の複数の測定から導出されます。「遅延変動」の必須の定義は、[RFC5481]のセクション4.2で定義されているパケット遅延変動（PDV）です。パケットのストリームを検討する場合、ストリーム内のすべてのパケットの最小遅延からすべてのパケットの遅延が差し引かれます。これにより、遅延変動の範囲（最大-最小）またはPDVの高いパーセンタイル（99パーセンタイル、外れ値に対する堅牢性）の評価が容易になります。
When First-bit to Last-bit timestamps are used for delay measurement, then delay variation MUST be measured using packets or frames of the same size, since the definition of latency includes the serialization time for each packet. Otherwise, if using First-bit to First-bit, the size restriction does not apply.
最初のビットから最後のビットのタイムスタンプが遅延測定に使用される場合、遅延の定義には各パケットのシリアル化時間が含まれるため、同じサイズのパケットまたはフレームを使用して遅延変動を測定する必要があります。それ以外の場合、First-bitからFirst-bitを使用する場合、サイズ制限は適用されません。
In addition to a PDV range and/or a high percentile of PDV, Inter-Packet Delay Variation (IPDV) as defined in Section 4.1 of [RFC5481] (differences between two consecutive packets) MAY be used for the purpose of determining how packet spacing has changed during transfer -- for example, to see if a packet stream has become closely spaced or "bursty". However, the absolute value of IPDV SHOULD NOT be used, as this "collapses" the "bursty" and "dispersed" sides of the IPDV distribution together.
PDV範囲および/またはPDVの高いパーセンタイルに加えて、[RFC5481]のセクション4.1で定義されているパケット間遅延変動（IPDV）（2つの連続するパケット間の差異）は、パケット間隔を決定する目的で使用できます（MAY）転送中に変更された-たとえば、パケットストリームが間隔が狭くなった、または「バースト」になったかどうかを確認するため。ただし、IPDVの絶対値は使用しないでください。これは、IPDV分布の「バースト」側と「分散」側を一緒に「崩壊」させるためです。
The measurement of delay variation is expressed in units of seconds. A PDV histogram MAY be provided for the population of packets measured.
遅延変動の測定値は秒単位で表されます。測定されたパケットの母集団に対してPDVヒストグラムが提供される場合があります。
Calibration of the physical layer consists of defining and measuring the latency of the physical devices used to perform tests on the DUT.
物理層のキャリブレーションは、DUTでテストを実行するために使用される物理デバイスのレイテンシを定義および測定することから成ります。
It includes the list of all physical-layer components used, as specified here:
ここには、使用されているすべての物理層コンポーネントのリストが含まれています。
- Type of device used to generate traffic / measure traffic.
- トラフィックの生成/トラフィックの測定に使用されるデバイスのタイプ。
- Type of line cards used on the traffic generator.
- トラフィックジェネレータで使用されるラインカードのタイプ。
- Type of transceivers on the traffic generator.
- トラフィックジェネレーターのトランシーバーのタイプ。
- Type of transceivers on the DUT.
- DUT上のトランシーバーのタイプ。
- Type of cables.
- ケーブルのタイプ。
- Length of cables.
- ケーブルの長さ。
- Software name and version of the traffic generator and DUT.
- トラフィックジェネレーターとDUTのソフトウェア名とバージョン。
- A list of enabled features on the DUT MAY be provided and is recommended (especially in the case of control-plane protocols, such as the Link Layer Discovery Protocol and Spanning Tree). A comprehensive configuration file MAY be provided to this effect.
- DUTで有効になっている機能のリストが提供される場合があり、推奨されます（特に、リンク層検出プロトコルやスパニングツリーなどのコントロールプレーンプロトコルの場合）。この効果のために、包括的な構成ファイルが提供される場合があります。
Calibration of the physical layer contributes to end-to-end latency and should be taken into account when evaluating the DUT. Small variations in the physical components of the test may impact the latency being measured; therefore, they MUST be described when presenting results.
物理層のキャリブレーションは、エンドツーエンドのレイテンシに影響するため、DUTを評価するときに考慮する必要があります。テストの物理コンポーネントの小さな変動は、測定される待ち時間に影響を与える可能性があります。したがって、結果を提示するときにそれらを説明する必要があります。
It is RECOMMENDED that all cables used for testing (1) be of the same type and length and (2) come from the same vendor whenever possible. It is a MUST to document the cable specifications listed in Section 4.1, along with the test results. The test report MUST specify whether or not the cable latency has been subtracted from the test measurements. The accuracy of the traffic-generator measurements MUST be provided (for current test equipment, this is usually a value within a range of 20 ns).
テストに使用するすべてのケーブルは、（1）タイプと長さが同じで、（2）可能な限り同じベンダーのものを使用することをお勧めします。セクション4.1に記載されているケーブル仕様とテスト結果を文書化する必要があります。テストレポートは、ケーブルの遅延がテスト測定値から差し引かれたかどうかを指定しなければなりません。トラフィックジェネレーター測定の精度を提供する必要があります（現在のテスト機器の場合、これは通常20 nsの範囲内の値です）。
The transmit timing, or maximum transmitted data rate, is controlled by the "transmit clock" in the DUT. The receive timing (maximum ingress data rate) is derived from the transmit clock of the connected interface.
送信タイミング、または最大送信データレートは、DUTの「送信クロック」によって制御されます。受信タイミング（最大入力データレート）は、接続されたインターフェイスの送信クロックから取得されます。
The line rate or physical-layer frame rate is the maximum capacity to send frames of a specific size at the transmit clock frequency of the DUT.
ラインレートまたは物理層フレームレートは、DUTの送信クロック周波数で特定のサイズのフレームを送信する最大容量です。
The term "nominal value of line rate" defines the maximum speed capability for the given port -- for example (expressed as Gigabit Ethernet), 1 GE, 10 GE, 40 GE, 100 GE.
「ラインレートの公称値」という用語は、特定のポートの最大速度能力を定義します-たとえば（ギガビットイーサネットとして表されます）、1 GE、10 GE、40 GE、100 GE。
The frequency ("clock rate") of the transmit clock in any two connected interfaces will never be precisely the same; therefore, a tolerance is needed. This will be expressed by a Parts Per Million (PPM) value. The IEEE standards allow a specific +/- variance in the transmit clock rate, and Ethernet is designed to allow for small, normal variations between the two clock rates. This results in a tolerance of the line-rate value when traffic is generated from test equipment to a DUT.
接続されている2つのインターフェイスの送信クロックの周波数（「クロックレート」）が正確に同じになることはありません。したがって、許容誤差が必要です。これは、100万分の1（PPM）値で表されます。 IEEE標準では、送信クロックレートに特定の+/-の変動が許容されており、イーサネットは、2つのクロックレート間の小さな通常の変動を許容するように設計されています。これにより、テスト機器からDUTへのトラフィックが生成されるときに、ラインレート値の許容誤差が生じます。
Line rate SHOULD be measured in frames per second (FPS).
ラインレートは、1秒あたりのフレーム数（FPS）で測定する必要があります（SHOULD）。
For a transmit clock source, most Ethernet switches use "clock modules" (also called "oscillator modules") that are sealed, internally temperature-compensated, and very accurate. The output frequency of these modules is not adjustable because it is not necessary. Many test sets, however, offer a software-controlled adjustment of the transmit clock rate. These adjustments SHOULD be used to "compensate" the test equipment in order to not send more than the line rate of the DUT.
送信クロックソースの場合、ほとんどのイーサネットスイッチは、密閉され、内部で温度補償され、非常に正確な「クロックモジュール」（「発振器モジュール」とも呼ばれます）を使用します。これらのモジュールの出力周波数は、必要がないため調整できません。ただし、多くのテストセットは、送信クロックレートのソフトウェア制御による調整を提供します。これらの調整は、DUTのラインレートを超えて送信しないように、テスト機器を「補正」するために使用する必要があります（SHOULD）。
To allow for the minor variations typically found in the clock rate of commercially available clock modules and other crystal-based oscillators, Ethernet standards specify the maximum transmit clock-rate variation to be not more than +/- 100 PPM from a calculated center frequency. Therefore, a DUT must be able to accept frames at a rate within +/- 100 PPM to comply with the standards.
市販のクロックモジュールやその他の水晶ベースの発振器のクロックレートに通常見られる小さな変動を許容するために、イーサネット標準では、計算された中心周波数から+/- 100 PPM以下の最大送信クロックレート変動を指定しています。したがって、DUTは、規格に準拠するために+/- 100 PPM以内のレートでフレームを受け入れることができる必要があります。
Very few clock circuits are precisely +/- 0.0 PPM because:
以下の理由により、正確に+/- 0.0 PPMであるクロック回路はほとんどありません。
1. The Ethernet standards allow a maximum variance of +/- 100 PPM over time. Therefore, it is normal for the frequency of the oscillator circuits to experience variation over time and over a wide temperature range, among other external factors.
1. イーサネット標準では、時間の経過とともに+/- 100 PPMの最大変動が許容されます。したがって、発振回路の周波数は、他の外部要因の中でも、時間の経過や広い温度範囲で変動するのが普通です。
2. The crystals, or clock modules, usually have a specific +/- PPM variance that is significantly better than +/- 100 PPM. Oftentimes, this is +/- 30 PPM or better in order to be considered a "certification instrument".
2. 水晶またはクロックモジュールは、通常、+ /-100 PPMよりも大幅に優れた特定の+/- PPM変動があります。多くの場合、これは「認証手段」と見なされるために+/- 30 PPM以上です。
When testing an Ethernet switch throughput at "line rate", any specific switch will have a clock-rate variance. If a test set is running +1 PPM faster than a switch under test and a sustained line-rate test is performed, a gradual increase in latency and, eventually, packet drops as buffers fill and overflow in the switch, can be observed. Depending on how much clock variance there is between the two connected systems, the effect may be seen after the traffic stream has been running for a few hundred microseconds, a few milliseconds, or seconds. The same low latency, and no packet loss, can be demonstrated by setting the test set's link occupancy to slightly less than 100 percent link occupancy. Typically, 99 percent link occupancy produces excellent low latency and no packet loss. No Ethernet switch or router will have a transmit clock rate of exactly +/- 0.0 PPM. Very few (if any) test sets have a clock rate that is precisely +/- 0.0 PPM.
イーサネットスイッチのスループットを「ラインレート」でテストする場合、特定のスイッチにはクロックレートの変動があります。テストセットがテスト中のスイッチよりも+1 PPM速く実行され、持続的なラインレートテストが実行される場合、レイテンシが徐々に増加し、最終的にはスイッチでバッファが満杯になりオーバーフローするにつれてパケットがドロップします。接続された2つのシステム間でのクロック変動の大きさによっては、トラフィックストリームが数百マイクロ秒、数ミリ秒、または数秒間実行された後に、影響が見られる場合があります。テストセットのリンク占有率を100％未満のリンク占有率に設定することで、同じ低遅延でパケット損失がないことを実証できます。通常、99％のリンク占有率により、優れた低遅延が実現され、パケット損失は発生しません。イーサネットスイッチまたはルーターでは、送信クロックレートが正確に+/- 0.0 PPMになることはありません。クロックレートが正確に+/- 0.0 PPMのテストセット（ある場合）はほとんどありません。
Test-set equipment manufacturers are well aware of the standards and allow a software-controlled +/- 100 PPM "offset" (clock-rate adjustment) to compensate for normal variations in the clock speed of DUTs. This offset adjustment allows engineers to determine the approximate speed at which the connected device is operating and verify that it is within parameters allowed by standards.
テストセット機器の製造元は標準を十分に理解しており、DUTのクロック速度の通常の変動を補正するために、ソフトウェア制御の+/- 100 PPM "オフセット"（クロックレート調整）を可能にします。このオフセット調整により、エンジニアは接続されたデバイスが動作しているおおよその速度を決定し、それが規格で許可されているパラメーター内であることを確認できます。
"Line rate" can be measured in terms of "frame rate":
「ラインレート」は「フレームレート」で測定できます。
Frame Rate = Transmit-Clock-Frequency /
(Frame-Length*8 + Minimum_Gap + Preamble + Start-Frame Delimiter)
Minimum_Gap represents the interframe gap. This formula "scales up" or "scales down" to represent 1 GB Ethernet, 10 GB Ethernet, and so on.
Minimum_Gapはフレーム間ギャップを表します。この式は、1 GBイーサネット、10 GBイーサネットなどを表す「スケールアップ」または「スケールダウン」します。
Example for 1 GB Ethernet speed with 64-byte frames:
64バイトフレームの1 GBイーサネット速度の例：
Frame Rate = 1,000,000,000 / (64*8 + 96 + 56 + 8)
= 1,000,000,000 / 672
＝ １、０００、０００、０００ ／ ６７２
= 1,488,095.2 FPS
= 1,488,095.2 FPS
Considering the allowance of +/- 100 PPM, a switch may "legally" transmit traffic at a frame rate between 1,487,946.4 FPS and 1,488,244 FPS. Each 1 PPM variation in clock rate will translate to a frame-rate increase or decrease of 1.488 FPS.
+/- 100 PPMの許容範囲を考慮すると、スイッチは1,487,946.4 FPSから1,488,244 FPSのフレームレートで「合法」にトラフィックを送信できます。クロックレートの1 PPM変動ごとに、フレームレートが1.488 FPS増加または減少します。
In a production network, it is very unlikely that one would see precise line rate over a very brief period. There is no observable difference between dropping packets at 99% of line rate and 100% of line rate.
実稼働ネットワークでは、非常に短い期間に正確なラインレートが見られる可能性はほとんどありません。ラインレートの99％とラインレートの100％でパケットをドロップする間に、目に見える違いはありません。
Line rate can be measured at 100% of line rate with a -100 PPM adjustment.
ラインレートは、-100 PPMの調整により、ラインレートの100％で測定できます。
Line rate SHOULD be measured at 99.98% with a 0 PPM adjustment.
ラインレートは、0 PPM調整で99.98％と測定する必要があります。
The PPM adjustment SHOULD only be used for a line-rate measurement.
PPM調整は、ラインレート測定にのみ使用してください。
Buffer Size: The term "buffer size" represents the total amount of frame-buffering memory available on a DUT. This size is expressed in B (bytes), KB (kilobytes), MB (megabytes), or GB (gigabytes). When the buffer size is expressed, an indication of the frame MTU (Maximum Transmission Unit) used for that measurement is also necessary, as well as the CoS (Class of Service) or DSCP (Differentiated Services Code Point) value set, as oftentimes the buffers are carved by a quality-of-service implementation. Please refer to Section 3 of [RFC8239] for further details.
バッファサイズ：「バッファサイズ」という用語は、DUTで利用可能なフレームバッファリングメモリの総量を表します。このサイズは、B（バイト）、KB（キロバイト）、MB（メガバイト）、またはGB（ギガバイト）で表されます。バッファサイズを表す場合、その測定に使用されるフレームMTU（最大伝送ユニット）の表示、およびCoS（サービスクラス）またはDSCP（Differentiated Services Code Point）値セットも必要です。バッファは、サービス品質の実装によって分割されます。詳細については、[RFC8239]のセクション3を参照してください。
Example: The Buffer Size of the DUT when sending 1518-byte frames is 18 MB.
例：1518バイトのフレームを送信するときのDUTのバッファーサイズは18 MBです。
Port Buffer Size: The port buffer size is the amount of buffer for a single ingress port, a single egress port, or a combination of ingress and egress buffering locations for a single port. We mention the three locations for the port buffer because the DUT's buffering scheme can be unknown or untested, so knowing the buffer location helps clarify the buffer architecture and, consequently, the total buffer size. The Port Buffer Size is an informational value that MAY be provided by the DUT vendor. It is not a value that is tested by benchmarking. Benchmarking will be done using the Maximum Port Buffer Size or Maximum Buffer Size methodology.
ポートバッファサイズ：ポートバッファサイズは、単一の入力ポート、単一の出力ポート、または単一のポートの入力と出力のバッファリングロケーションの組み合わせのバッファ量です。 DUTのバッファリングスキームは不明またはテストされていない可能性があるため、ポートバッファの3つの場所について説明します。したがって、バッファの場所を知ることで、バッファアーキテクチャを明確にし、結果として合計バッファサイズを明確にすることができます。ポートバッファサイズは、DUTベンダーから提供される情報の値です。ベンチマークでテストされた値ではありません。ベンチマークは、最大ポートバッファーサイズまたは最大バッファーサイズの方法を使用して行われます。
Maximum Port Buffer Size: In most cases, this is the same as the Port Buffer Size. In a certain type of switch architecture called "SoC" (switch on chip), there is a port buffer and a shared buffer pool available for all ports. The Maximum Port Buffer Size, in terms of an SoC buffer, represents the sum of the port buffer and the maximum value of shared buffer allowed for this port, defined in terms of B (bytes), KB (kilobytes), MB (megabytes), or GB (gigabytes). The Maximum Port Buffer Size needs to be expressed along with the frame MTU used for the measurement and the CoS or DSCP bit value set for the test.
最大ポートバッファサイズ：ほとんどの場合、これはポートバッファサイズと同じです。 「SoC」（スイッチオンチップ）と呼ばれる特定のタイプのスイッチアーキテクチャでは、すべてのポートで使用できるポートバッファと共有バッファプールがあります。 SoCバッファーの観点から見た最大ポートバッファーサイズは、ポートバッファーの合計と、このポートに許可される共有バッファーの最大値を表し、B（バイト）、KB（キロバイト）、MB（メガバイト）で定義されます。 、またはGB（ギガバイト）。最大ポートバッファサイズは、測定に使用されるフレームMTUおよびテストに設定されたCoSまたはDSCPビット値とともに表現する必要があります。
Example: A DUT has been measured to have 3 KB of port buffer for 1518-byte frames, and a total of 4.7 MB of maximum port buffer for 1518-byte frames and a CoS of 0.
例：DUTは、1518バイトのフレームに対して3 KBのポートバッファー、1518バイトのフレームに対して合計4.7 MBの最大ポートバッファー、CoSが0であると測定されています。
Maximum DUT Buffer Size: This is the total buffer size that a DUT can be measured to have. It is most likely different than the Maximum Port Buffer Size. It can also be different from the sum of Maximum Port Buffer Size. The Maximum Buffer Size needs to be expressed along with the frame MTU used for the measurement and along with the CoS or DSCP value set during the test.
最大DUTバッファーサイズ：これは、DUTが測定できる合計バッファーサイズです。ほとんどの場合、最大ポートバッファサイズとは異なります。最大ポートバッファサイズの合計とは異なる場合もあります。最大バッファサイズは、測定に使用されるフレームMTUとともに、テスト中に設定されたCoSまたはDSCP値とともに表現する必要があります。
Example: A DUT has been measured to have 3 KB of port buffer for 1518-byte frames and a total of 4.7 MB of maximum port buffer for 1518-byte frames. The DUT has a Maximum Buffer Size of 18 MB at 1500 B and a CoS of 0.
例：DUTは、1518バイトのフレームに対して3 KBのポートバッファーがあり、1518バイトのフレームに対して合計4.7 MBの最大ポートバッファーがあると測定されています。 DUTの最大バッファサイズは1500 Bで18 MB、CoSは0です。
Burst: A burst is a fixed number of packets sent over a percentage of line rate for a defined port speed. The amount of frames sent is evenly distributed across the interval T. A constant, C, can be defined to provide the average time between two evenly spaced consecutive packets.
バースト：バーストは、定義されたポート速度に対して、一定の割合のラインレートで送信される固定数のパケットです。送信されるフレームの量は、間隔Tに均等に分散されます。定数Cは、2つの等間隔の連続するパケット間の平均時間を提供するように定義できます。
Microburst: A microburst is a type of burst where packet drops occur when there is not sustained or noticeable congestion on a link or device. One characteristic of a microburst is when the burst is not evenly distributed over T and is less than the constant C (C = the average time between two evenly spaced consecutive packets).
マイクロバースト：マイクロバーストはバーストの一種であり、リンクまたはデバイスに持続的または顕著な輻輳がない場合にパケットのドロップが発生します。マイクロバーストの特徴の1つは、バーストがTに均等に分散されておらず、定数C未満である場合です（C = 2つの等間隔の連続するパケット間の平均時間）。
Intensity of Microburst: This is a percentage and represents the level, between 1 and 100%, of the microburst. The higher the number, the higher the microburst is.
マイクロバーストの強度：これはパーセントであり、マイクロバーストの1〜100％のレベルを表します。数値が大きいほど、マイクロバーストが高くなります。
I=[1-[ (Tp2-Tp1)+(Tp3-Tp2)+....(TpN-Tp(n-1) ] / Sum(packets)]]*100
The above definitions are not meant to comment on the ideal sizing of a buffer but rather on how to measure it. A larger buffer is not necessarily better and can cause issues with bufferbloat.
上記の定義は、バッファーの理想的なサイジングについてコメントするものではなく、それを測定する方法についてのものです。大きなバッファは必ずしも良いとは限らず、バッファブロートの問題を引き起こす可能性があります。
When measuring buffering on a DUT, it is important to understand the behavior of each and every port. This provides data for the total amount of buffering available on the switch. The terms of buffer efficiency help one understand the optimum packet size for the buffer or the real volume of the buffer available for a specific packet size. This section does not discuss how to conduct the test methodology; instead, it explains the buffer definitions and what metrics should be provided for comprehensive data center device-buffering benchmarking.
DUTのバッファリングを測定する場合、すべてのポートの動作を理解することが重要です。これにより、スイッチで使用可能なバッファリングの総量のデータが提供されます。バッファ効率の用語は、バッファの最適なパケットサイズ、または特定のパケットサイズで使用可能なバッファの実際のボリュームを理解するのに役立ちます。このセクションでは、テスト方法の実施方法については説明しません。代わりに、バッファ定義と、包括的なデータセンターのデバイスバッファリングベンチマークに提供する必要があるメトリックについて説明します。
When the DUT buffer is measured:
DUTバッファが測定されたとき：
- The buffer size MUST be measured.
- バッファサイズを測定する必要があります。
- The port buffer size MAY be provided for each port.
- ポートバッファサイズは、各ポートに提供される場合があります。
- The maximum port buffer size MUST be measured.
- 最大ポートバッファサイズを測定する必要があります。
- The maximum DUT buffer size MUST be measured.
- 最大DUTバッファサイズを測定する必要があります。
- The intensity of the microburst MAY be mentioned when a microburst test is performed.
- マイクロバーストの強度は、マイクロバーストテストが実行されるときに言及される場合があります。
- The CoS or DSCP value set during the test SHOULD be provided.
- テスト中に設定されたCoSまたはDSCP値を提供する必要があります。
The term "Incast", very commonly utilized in the data center, refers to the many-to-one or many-to-many traffic patterns. As defined in this section, it measures the number of ingress and egress ports and the percentage of synchronization attributed to them. Typically, in the data center, it would refer to many different ingress server ports (many), sending traffic to a common uplink (many-to-one), or multiple uplinks (many-to-many). This pattern is generalized for any network as many incoming ports sending traffic to one or a few uplinks.
データセンターで非常に一般的に使用されている「インキャスト」という用語は、多対1または多対多のトラフィックパターンを指します。このセクションで定義されているように、入力ポートと出力ポートの数、およびそれらに起因する同期の割合を測定します。通常、データセンターでは、トラフィックを共通のアップリンク（多対1）または複数のアップリンク（多対多）に送信する、さまざまな入力サーバーポート（多）を参照します。このパターンは、1つまたはいくつかのアップリンクにトラフィックを送信する多くの着信ポートと同様に、あらゆるネットワークに対して一般化されています。
Synchronous arrival time: When two or more frames of sizes L1 and L2 arrive at their respective ingress port or multiple ingress ports and there is an overlap of arrival times for any of the bits on the DUT, then the L1 and L2 frames have synchronous arrival times. This is called "Incast", regardless of whether the pattern is many-to-one (simpler) or many-to-many.
同期到着時間：サイズL1およびL2の2つ以上のフレームがそれぞれの入力ポートまたは複数の入力ポートに到着し、DUTのいずれかのビットの到着時間が重複している場合、L1およびL2フレームは同期到着します。回。パターンが多対1（より単純）であるか多対多であるかに関係なく、これは「インキャスト」と呼ばれます。
Asynchronous arrival time: This is any condition not defined by "synchronous arrival time".
非同期到着時間：これは、「同期到着時間」で定義されていない条件です。
Percentage of synchronization: This defines the level of overlap (amount of bits) between frames of sizes L1,L2..Ln.
同期の割合：これは、サイズがL1、L2..Lnのフレーム間のオーバーラップのレベル（ビット数）を定義します。
Example: Two 64-byte frames of length L1 and L2 arrive at ingress port 1 and port 2 of the DUT. There is an overlap of 6.4 bytes between the two, where the L1 and L2 frames were on their respective ingress ports at the same time. Therefore, the percentage of synchronization is 10%.
例：長さL1およびL2の2つの64バイトフレームが、DUTの入力ポート1およびポート2に到着します。 2つの間に6.4バイトのオーバーラップがあり、L1フレームとL2フレームがそれぞれの入力ポートに同時に存在していました。したがって、同期の割合は10％です。
Stateful traffic: Stateful traffic is packets exchanged with a stateful protocol, such as TCP.
ステートフルトラフィック：ステートフルトラフィックは、TCPなどのステートフルプロトコルで交換されるパケットです。
Stateless traffic: Stateless traffic is packets exchanged with a stateless protocol, such as UDP.
ステートレストラフィック：ステートレストラフィックは、UDPなどのステートレスプロトコルで交換されるパケットです。
In this scenario, buffers are used on the DUT. In an ingress buffering mechanism, the ingress port buffers would be used along with virtual output queues, when available, whereas in an egress buffering mechanism, the egress buffer of the one outgoing port would be used.
このシナリオでは、DUTでバッファーが使用されます。入力バッファリングメカニズムでは、入力ポートバッファが使用可能な場合は仮想出力キューとともに使用されますが、出力バッファリングメカニズムでは、1つの出力ポートの出力バッファが使用されます。
In either case, regardless of where the buffer memory is located in the switch architecture, the Incast creates buffer utilization.
どちらの場合も、スイッチアーキテクチャのどこにバッファメモリが配置されているかに関係なく、インキャストはバッファ使用率を作成します。
When one or more frames have synchronous arrival times at the DUT, they are considered to be forming an Incast.
1つ以上のフレームがDUTで同期到着時間を持つ場合、それらはインキャストを形成していると見なされます。
It is a MUST to measure the number of ingress and egress ports.
入力ポートと出力ポートの数を測定する必要があります。
It is a MUST to have a non-null percentage of synchronization, which MUST be specified.
指定する必要がある同期のnull以外のパーセンテージを持つことは必須です。
In data center networking, a balanced network is a function of maximal throughput and minimal loss at any given time. This is captured by the Goodput [TCP-INCAST]. Goodput is the application-level throughput. For standard TCP applications, a very small loss can have a dramatic effect on application throughput. [RFC2647] provides a definition of Goodput; the definition in this document is a variant of that definition.
データセンターネットワーキングでは、バランスの取れたネットワークは、常に最大のスループットと最小の損失の関数です。これはグッドプット[TCP-INCAST]によってキャプチャされます。 Goodputは、アプリケーションレベルのスループットです。標準TCPアプリケーションの場合、非常に小さな損失がアプリケーションのスループットに劇的な影響を与える可能性があります。 [RFC2647]はグッドプットの定義を提供します。このドキュメントの定義は、その定義の変形です。
Goodput is the number of bits per unit of time forwarded to the correct destination interface of the DUT, minus any bits retransmitted.
グッドプットは、DUTの正しい宛先インターフェイスに転送される単位時間あたりのビット数から、再送信されたビットを差し引いたものです。
In data center benchmarking, the goodput is a value that SHOULD be measured. It provides a realistic idea of the usage of the available bandwidth. A goal in data center environments is to maximize the goodput while minimizing loss.
データセンターのベンチマークでは、グッドプットは測定すべき値です。利用可能な帯域幅の使用法の現実的なアイデアを提供します。データセンター環境の目標は、損失を最小限に抑えながらグッドプットを最大化することです。
The Goodput, G, is then measured by the following formula:
次に、グッドプットGは次の式で測定されます。
G = (S/F) x V bytes per second
- S represents the payload bytes, not including packet or TCP headers.
- Sはペイロードバイトを表し、パケットやTCPヘッダーは含まれません。
- F is the frame size.
- Fはフレームサイズです。
- V is the speed of the media in bytes per second.
- Vは、メディアの速度（1秒あたりのバイト数）です。
Example: A TCP file transfer over HTTP on 10 GB/s media.
例：10 GB /秒のメディア上のHTTPを介したTCPファイル転送。
The file cannot be transferred over Ethernet as a single continuous stream. It must be broken down into individual frames of 1500 B when the standard MTU is used. Each packet requires 20 B of IP header information and 20 B of TCP header information; therefore, 1460 B are available per packet for the file transfer. Linux-based systems are further limited to 1448 B, as they also carry a 12 B timestamp. Finally, in this example the date is transmitted over Ethernet, which adds 26 B of overhead per packet to 1500 B, increasing it to 1526 B.
ファイルを単一の連続ストリームとしてイーサネット経由で転送することはできません。標準のMTUを使用する場合は、1500 Bの個々のフレームに分割する必要があります。各パケットには、20 BのIPヘッダー情報と20 BのTCPヘッダー情報が必要です。したがって、パケット転送ごとに1460 Bがパケットごとに使用可能です。 Linuxベースのシステムは12Bタイムスタンプも伝送するため、さらに1448 Bに制限されます。最後に、この例では、日付がイーサネット経由で送信され、パケットあたり26 Bのオーバーヘッドが1500 Bに追加され、1526 Bに増加します。
G = 1460/1526 x 10 Gbit/s, which is 9.567 Gbit/s or 1.196 GB/s.
G = 1460/1526 x 10ギガビット/秒、つまり9.567ギガビット/秒または1.196 GB /秒。
Please note: This example does not take into consideration the additional Ethernet overhead, such as the interframe gap (a minimum of 96 bit times), nor does it account for collisions (which have a variable impact, depending on the network load).
注：この例では、フレーム間ギャップ（最低96ビット時間）などの追加のイーサネットオーバーヘッドは考慮されておらず、衝突（ネットワーク負荷に応じてさまざまな影響があります）も考慮されていません。
When conducting Goodput measurements, please document, in addition to the items listed in Section 4.1, the following information:
グッドプット測定を実施する場合は、セクション4.1にリストされている項目に加えて、以下の情報を文書化してください。
- The TCP stack used.
- 使用されるTCPスタック。
- OS versions.
- OSバージョン。
- Network Interface Card (NIC) firmware version and model.
- ネットワークインターフェイスカード（NIC）ファームウェアのバージョンとモデル。
For example, Windows TCP stacks and different Linux versions can influence TCP-based test results.
たとえば、Windows TCPスタックとさまざまなLinuxバージョンは、TCPベースのテスト結果に影響を与える可能性があります。
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>。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC5481] Morton、A。およびB. Claise、「Packet Delay Variation Applicability Statement」、RFC 5481、DOI 10.17487 / RFC5481、2009年3月、<https://www.rfc-editor.org/info/rfc5481>。
[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>。
[RFC8239] Avramov, L. and J. Rapp, "Data Center Benchmarking Methodology", RFC 8239, DOI 10.17487/RFC8239, August 2017, <https://www.rfc-editor.org/info/rfc8239>.
[RFC8239] Avramov、L。およびJ. Rapp、「Data Center Benchmarking Methodology」、RFC 8239、DOI 10.17487 / RFC8239、2017年8月、<https://www.rfc-editor.org/info/rfc8239>。
[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>。
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999, <https://www.rfc-editor.org/info/rfc2647>.
[RFC2647]ニューマン、D。、「ファイアウォールパフォーマンスのベンチマーク用語」、RFC 2647、DOI 10.17487 / RFC2647、1999年8月、<https://www.rfc-editor.org/info/rfc2647>。
[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>。
[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, Scott Bradner, Ian Cox, and Tim Stevenson for their reviews and feedback.
著者は、レビューとフィードバックを提供してくれたAl Morton、Scott Bradner、Ian Cox、およびTim Stevensonに感謝します。
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