Internet Engineering Task Force (IETF) M. Konstantynowicz
Request for Comments: 9971 V. Polak
Category: Informational Cisco Systems
ISSN: 2070-1721 August 2026
This document describes an alternative to throughput in "Benchmarking Methodology for Network Interconnect Devices" (RFC 2544) by defining a new methodology called Multiple Loss Ratio Search (MLRsearch). MLRsearch aims to minimize Search Duration, support multiple loss ratio goals, and improve result repeatability and comparability.
この文書では、Multiple Loss Ratio Search (MLRsearch) と呼ばれる新しい方法論を定義することにより、「ネットワーク相互接続デバイスのベンチマーク方法」(RFC 2544) のスループットに代わる方法について説明します。MLRsearch は、検索期間を最小限に抑え、複数の損失率目標をサポートし、結果の再現性と比較可能性を向上させることを目的としています。
MLRsearch is motivated by the pressing need to address the challenges of evaluating and testing the various data plane solutions, especially in software-based networking systems based on Commercial Off-the-Shelf (COTS) CPU hardware vs. purpose-built Application-Specific Integrated Circuit (ASIC) / Network Processing Unit (NPU) / Field-Programmable Gate Array (FPGA) hardware.
MLRsearch は、さまざまなデータ プレーン ソリューション、特に商用オフザシェルフ (COTS) CPU ハードウェアと専用の特定用途向け集積回路 (ASIC) / ネットワーク プロセッシング ユニット (NPU) / フィールド プログラマブル ゲート アレイ (FPGA) ハードウェアに基づくソフトウェア ベースのネットワーキング システムにおける、さまざまなデータ プレーン ソリューションの評価とテストの課題に対処するという差し迫ったニーズに動機付けられています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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 https://www.rfc-editor.org/info/rfc9971.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9971 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Purpose
1.2. Positioning Within BMWG Methodologies
2. Overview of RFC 2544 Problems
2.1. Binary Search
2.2. Long Search Duration
2.3. DUT in SUT
2.4. Repeatability and Comparability
2.5. Throughput with Non-Zero Loss
2.6. Inconsistent Trial Results
3. Requirements Language
4. MLRsearch Specification
4.1. Scope
4.1.1. Relationship to RFC 2544
4.1.2. Applicability of Other Specifications
4.1.3. Out of Scope
4.2. Architecture Overview
4.2.1. Search
4.2.2. Search Duration
4.2.3. Test Report
4.2.4. Behavior Correctness
4.3. Quantities
4.3.1. Current and Final Values
4.4. Existing Terms
4.4.1. SUT
4.4.2. DUT
4.4.3. Trial
4.4.4. Load Quantities
4.4.5. Forwarding Rate Quantities
4.5. Trial Terms
4.5.1. Trial Duration
4.5.2. Trial Load
4.5.3. Trial Input
4.5.4. Traffic Profile
4.5.5. Trial Forwarding Ratio
4.5.6. Trial Loss Ratio
4.5.7. Trial Forwarding Rate
4.5.8. Trial Effective Duration
4.5.9. Trial Output
4.5.10. Trial Result
4.6. Goal Terms
4.6.1. Goal Final Trial Duration
4.6.2. Goal Duration Sum
4.6.3. Goal Loss Ratio
4.6.4. Goal Exceed Ratio
4.6.5. Goal Width
4.6.6. Goal Initial Trial Duration
4.6.7. Search Goal
4.6.8. Controller Input
4.7. Auxiliary Terms
4.7.1. Trial Classification
4.7.2. Load Classification
4.8. Result Terms
4.8.1. Relevant Upper Bound
4.8.2. Relevant Lower Bound
4.8.3. Conditional Throughput
4.8.4. Goal Results
4.8.5. Search Result
4.8.6. Controller Output
4.9. Architecture Terms
4.9.1. Measurer
4.9.2. Controller
4.9.3. Manager
4.10. Compliance
4.10.1. Test Procedure Compliant with MLRsearch
4.10.2. MLRsearch Compliant with RFC 2544
4.10.3. MLRsearch Compliant with TST009
5. Methodology Rationale and Design Considerations
5.1. Binary Search Commonalities
5.2. Stopping Conditions and Precision
5.3. Loss Ratios and Loss Inversion
5.3.1. Single Goal and Hard Bounds
5.3.2. Loss Inversion
5.3.3. Conservativeness and Relevant Bounds
5.3.4. Consequences
5.4. Exceed Ratio and Multiple Trials
5.5. Short Trials and Duration Selection
5.6. Generalized Throughput
5.6.1. Hard Performance Limit
5.6.2. Performance Variability
6. MLRsearch Logic
6.1. Load Classification Logic
6.2. Conditional Throughput Logic
6.2.1. Conditional Throughput and Load Classification
6.3. SUT Behaviors
6.3.1. Expert Predictions
6.3.2. Exceed Probability
6.3.3. Trial Duration Dependence
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Load Classification Code
Appendix B. Conditional Throughput Code
Appendix C. Example Search
C.1. Example Goals
C.2. Example Trial Results
C.3. Load Classification Computations
C.3.1. Point 1
C.3.2. Point 2
C.3.3. Point 3
C.3.4. Point 4
C.3.5. Point 5
C.3.6. Point 6
C.4. Conditional Throughput Computations
C.4.1. Goal 2
C.4.2. Goal 3
C.4.3. Goal 4
Acknowledgements
Authors' Addresses
This document describes the Multiple Loss Ratio Search (MLRsearch) methodology, optimized for determining data plane throughput in software-based networking functions running on commodity systems with generic CPUs (vs. purpose-built ASICs, NPUs, and FPGAs). Such network functions can be deployed on a dedicated physical appliance (e.g., a standalone hardware device) or as virtual appliance (e.g., a Virtual Network Function running on shared servers in the compute cloud).
このドキュメントでは、汎用 CPU (専用 ASIC、NPU、FPGA と比較) を備えた汎用システム上で実行されるソフトウェア ベースのネットワーキング機能におけるデータ プレーン スループットを決定するために最適化された、Multiple Loss Ratio Search (MLRsearch) 方法論について説明します。このようなネットワーク機能は、専用の物理アプライアンス (スタンドアロン ハードウェア デバイスなど) または仮想アプライアンス (コンピューティング クラウド内の共有サーバー上で実行される仮想ネットワーク機能など) として展開できます。
This document tightly couples terminology and methodology aspects. Instead of a separate terminology section, the subsections of "MLRsearch Specification" (Section 4) act as a list of newly defined terms. If a term appears with the first letter capitalized, it likely refers to a specific term defined in an eponymous subsection of MLRsearch Specification.
この文書は、用語と方法論の側面を密接に結び付けています。個別の用語セクションの代わりに、「MLRsearch 仕様」のサブセクション (セクション 4) は、新しく定義された用語のリストとして機能します。用語の最初の文字が大文字で表示されている場合は、MLRsearch 仕様の同名のサブセクションで定義されている特定の用語を指す可能性があります。
For first-time readers, the information in MLRsearch Specification might feel dense and lacking motivation. Subsequent sections provide explanations, making MLRsearch Specification more approachable on repeated reads.
初めて読む人にとって、MLRsearch 仕様の情報は分厚く、やる気がないと感じるかもしれません。後続のセクションでは説明を提供し、繰り返し読むことで MLRsearch 仕様をより理解しやすくしています。
The purpose of this document is to describe the Multiple Loss Ratio Search (MLRsearch) methodology, optimized for determining data plane throughput in software-based networking devices and functions.
このドキュメントの目的は、ソフトウェア ベースのネットワーキング デバイスおよび機能におけるデータ プレーンのスループットを決定するために最適化された Multiple Loss Ratio Search (MLRsearch) 方法論を説明することです。
Applying the "Binary Search" (Section 2.1) to software Devices Under Test (DUTs) results in several problems:
「二分探索」 (セクション 2.1) をソフトウェアのテスト対象デバイス (DUT) に適用すると、いくつかの問題が発生します。
* Binary Search takes a long time, as most Trials are done far from the eventually found Throughput.
* ほとんどのトライアルは最終的に見つかるスループットから遠く離れて行われるため、二分探索には長い時間がかかります。
* The required final Trial Duration and pauses between Trials prolong the overall Search Duration.
* 必要な最終トライアル期間とトライアル間の一時停止により、全体の検索期間が延長されます。
* Software DUTs show noisy Trial Results, leading to a big spread of Throughput values that could be discovered.
* ソフトウェア DUT はノイズの多い試行結果を示し、発見される可能性のあるスループット値に大きなばらつきが生じます。
* Throughput requires a loss of exactly zero frames, but the industry best practices frequently allow for tolerance of low but non-zero losses (see [Y.1564] and test-equipment manuals for more information).
* スループットには正確にゼロフレームの損失が必要ですが、業界のベストプラクティスでは、低損失でもゼロではない損失を許容することがよくあります (詳細については、[Y.1564] およびテスト機器のマニュアルを参照してください)。
* The definition of Throughput is not clear when Trial Results are inconsistent (e.g., when a successive Trial at a higher Load yields a smaller Trial Loss Ratio, Throughput can no longer be pinned to a single, unambiguous value.)
* トライアル結果が一貫していない場合、スループットの定義は明確ではありません (たとえば、より高い負荷での連続したトライアルでより小さなトライアル損失率が得られる場合、スループットを単一の明確な値に固定することはできなくなります)。
To address these problems, early MLRsearch implementations employed the following enhancements:
これらの問題に対処するために、初期の MLRsearch 実装では次の機能強化が採用されました。
1. Allow multiple Short Trials instead of one long Trial per Load.
1. ロードごとに 1 つの長いトライアルではなく、複数の短いトライアルを許可します。
* Optionally, tolerate a percentage of Trial Results with higher Trial Loss Ratios.
* オプションで、より高い試行損失率を持つ試行結果の割合を許容します。
2. Allow searching for multiple Search Goals, with differing Goal Loss Ratios.
2. 目標損失率が異なる複数の検索目標を検索できるようにします。
* Any Trial Result can affect each Search Goal in principle.
* 原則として、トライアル結果はそれぞれの検索目標に影響を与える可能性があります。
3. Insert multiple coarse targets for each Search Goal; earlier ones need to spend less time on Trials.
3. 検索目標ごとに複数の粗いターゲットを挿入します。それ以前のものは、トライアルに費やす時間が少なくて済みます。
* Earlier targets also aim for lesser precision.
* 初期のターゲットも、より低い精度を目指しています。
* Use Forwarding Rate at Maximum Offered Load (FRMOL), as defined in Section 3.6.2 of [RFC2285], to initialize bounds.
* [RFC2285] のセクション 3.6.2 で定義されている最大提供負荷時の転送速度 (FRMOL) を使用して、境界を初期化します。
4. Clarify handling of Inconsistent Trial Results.
4. 矛盾した試験結果の取り扱いを明確にする。
* Reported Throughput should be smaller than the smallest Load with high loss.
* 報告されるスループットは、損失が大きい最小負荷よりも小さい必要があります。
* Measure smaller Load candidates first.
* 最初に小さいロード候補を測定します。
5. Apply several time-saving Load selection heuristics that deliberately prevent the bounds from narrowing unnecessarily.
5. 境界が不必要に狭くなるのを意図的に防ぐ、時間を節約するロード選択ヒューリスティックをいくつか適用します。
Enhancements 1, 2, and partly 4 are formalized as the MLRsearch Specification within this document. The remaining enhancements are treated as implementation details and out of scope for this document. This achieves high comparability without limiting future improvements.
拡張 1、2、および一部の 4 は、この文書内で MLRsearch 仕様として正式に定められています。残りの機能強化は実装の詳細として扱われ、このドキュメントの範囲外となります。これにより、将来の改善を制限することなく、高い比較可能性が実現されます。
MLRsearch configuration supports both conservative settings and aggressive settings. Results unconditionally compliant with [RFC2544] are possible with conservative enough settings but without much improvement on Search Duration and repeatability, see "MLRsearch Compliant with RFC 2544" (Section 4.10.2). Conversely, aggressive settings lead to shorter Search Durations and better repeatability, but the results are not compliant with [RFC2544]. This document offers only soft recommendations for settings, but see the discussion in "Overview of RFC 2544 Problems" (Section 2) for the impact of different settings on result quality.
MLRsearch 構成は、保守的な設定と積極的な設定の両方をサポートします。[RFC2544] に無条件に準拠した結果は、十分に保守的な設定で可能ですが、検索期間と再現性はあまり改善されません。「RFC 2544 に準拠した MLRsearch」(セクション 4.10.2) を参照してください。逆に、積極的な設定は検索期間を短縮し、再現性を向上させますが、結果は [RFC2544] に準拠していません。この文書では、設定に関するソフトな推奨事項のみを提供しますが、さまざまな設定が結果の品質に与える影響については、「RFC 2544 問題の概要」(セクション 2) の説明を参照してください。
This document does not change or obsolete any part of [RFC2544].
この文書は、[RFC2544] のいかなる部分も変更または廃止するものではありません。
The Benchmarking Methodology Working Group (BMWG) produces recommendations (RFCs) that describe various benchmarking methodologies for use in a controlled laboratory environment. A large number of these benchmarks are based on the terminology from [RFC1242] and the foundational methodology from [RFC2544]. A common pattern has emerged where BMWG documents reference the methodology of [RFC2544] and augment it with specific requirements for testing particular network systems or protocols, without modifying the core benchmark definitions.
ベンチマーク方法ワーキング グループ (BMWG) は、管理された実験室環境で使用するためのさまざまなベンチマーク方法を説明する推奨事項 (RFC) を作成します。これらのベンチマークの多くは、[RFC1242] の用語と [RFC2544] の基本的な方法論に基づいています。BMWG 文書が [RFC2544] の方法論を参照し、コアのベンチマーク定義を変更せずに、特定のネットワーク システムまたはプロトコルをテストするための特定の要件で強化するという一般的なパターンが現れています。
While BMWG documents are formal recommendations, they are widely treated as industry norms to ensure the comparability of results between different labs. The set of benchmarks defined in [RFC2544], in particular, became a de facto standard for performance testing. In this context, the MLRsearch Specification formally defines a new class of benchmarks that fits within the wider framework of [RFC2544]; see "Scope" (Section 4.1).
BMWG 文書は正式な推奨事項ですが、異なるラボ間の結果の比較可能性を確保するための業界標準として広く扱われています。特に、[RFC2544] で定義された一連のベンチマークは、パフォーマンス テストの事実上の標準になりました。これに関連して、MLRsearch 仕様は、[RFC2544] のより広範なフレームワーク内に適合する新しいクラスのベンチマークを正式に定義します。「スコープ」(セクション 4.1) を参照してください。
A primary consideration in the design of MLRsearch is the trade-off between configurability and comparability. The methodology's flexibility, especially the ability to define various sets of Search Goals, in supporting both single-goal and multi-goal benchmarks in a unified way is powerful for detailed characterization and internal testing. However, this same flexibility is detrimental to inter-lab comparability unless a specific, common set of Search Goals is agreed upon.
MLRsearch の設計における主な考慮事項は、構成可能性と比較可能性の間のトレードオフです。この方法論の柔軟性、特に単一目標と複数目標の両方のベンチマークを統一した方法でサポートするさまざまな検索目標のセットを定義できる機能は、詳細な特性評価と内部テストに強力です。ただし、特定の共通の検索目標のセットが合意されていない限り、これと同じ柔軟性はラボ間の比較可能性に悪影響を及ぼします。
Therefore, MLRsearch should not be seen as a direct extension nor a replacement for the [RFC2544] Throughput benchmark. Instead, this document provides a foundational methodology that future BMWG documents can use to define new, specific, and comparable benchmarks by mandating particular Search Goal configurations. For operators of existing test procedures, it is worth noting that many test setups measuring [RFC2544] Throughput can be adapted to produce results compliant with the MLRsearch Specification, often without affecting Trials, merely by augmenting the content of the final Test Report.
したがって、MLRsearch は、[RFC2544] スループット ベンチマークの直接の拡張や代替として見なすべきではありません。代わりに、このドキュメントは、将来の BMWG ドキュメントで特定の検索目標設定を義務付けることで、新しい具体的な比較可能なベンチマークを定義するために使用できる基本的な方法論を提供します。既存のテスト手順のオペレータにとって、[RFC2544] スループットを測定する多くのテスト設定は、最終的なテスト レポートの内容を拡張するだけで、多くの場合トライアルに影響を与えることなく、MLRsearch 仕様に準拠した結果を生成するように適応できることは注目に値します。
This section describes the problems affecting usability of various performance testing methodologies, mainly the Binary Search for unconditionally compliant [RFC2544] Throughput.
このセクションでは、さまざまなパフォーマンス テスト手法、主に無条件に準拠した [RFC2544] スループットの二分探索法の使いやすさに影響を与える問題について説明します。
While [RFC2544] offers some flexibility when searching for Throughput, a particular algorithm is frequently used as a starting point, as it is the simplest one among those that offer reasonable effectivity.
[RFC2544] はスループットを検索する際にある程度の柔軟性を提供しますが、特定のアルゴリズムは妥当な有効性を提供するアルゴリズムの中で最も単純であるため、開始点としてよく使用されます。
This algorithm is based on (balanced) binary search over sorted arrays but does not have a specific name when searching for Throughput. "Trial duration" (Section 24 of [RFC2544]) mentions binary search only in quotes, without providing specifics. In this document, we call that algorithm the Binary Search, as that is the title of Section 12.3.2 of [TST009], which describes a variant of it.
このアルゴリズムは、ソートされた配列に対する (バランスのとれた) 二分探索に基づいていますが、スループットを検索する場合には特定の名前がありません。「試用期間」([RFC2544] のセクション 24) では、バイナリ検索については引用符で囲んでのみ言及されており、詳細は示されていません。この文書では、そのアルゴリズムをバイナリ検索と呼びます。これは、そのバリアントを説明する [TST009] のセクション 12.3.2 のタイトルです。
Here is a simplified description of the algorithm:
アルゴリズムの簡単な説明は次のとおりです。
* Initialize the lower-bound variable to a line-rate Load.
* 下限変数をラインレートロードに初期化します。
* Initialize the upper-bound variable to a loss-free Load.
* 上限変数を損失のないロードに初期化します。
* Compute a midpoint, the arithmetic mean of current bounds.
* 現在の境界の算術平均である中点を計算します。
* Run a single 60-second Trial at the midpoint (for [RFC2544] unconditional compliance).
* 中間点で 60 秒のトライアルを 1 回実行します ([RFC2544] 無条件準拠のため)。
* If loss is zero, set the lower-bound to the midpoint; else, set the upper bound to the midpoint.
* 損失がゼロの場合、下限を中間点に設定します。それ以外の場合は、上限を中点に設定します。
* Repeat (computing new midpoint) until the gap between the bounds meets the desired precision.
* 境界間のギャップが目的の精度を満たすまで、(新しい中点の計算) を繰り返します。
* Return the final lower-bound as the Throughput.
* 最終的な下限をスループットとして返します。
The description in [TST009] has two more requirements (stopping condition and rounding, both based on the Offered Load Step Size Parameter), but those are not required in this document.
[TST009] の説明にはさらに 2 つの要件 (停止条件と丸め、両方とも提供された負荷ステップ サイズ パラメーターに基づく) がありますが、これらはこの文書では必須ではありません。
Small modifications related to initial bounds are also allowed.
初期境界に関連する小さな変更も許可されます。
The Loads currently held in the two variables are called _tightest bounds_, especially when discussing older Trial Results (logically still bounds).
2 つの変数に現在保持されている荷重は、特に古い試行結果 (論理的にはまだ限界) について議論する場合に、「最も狭い限界」と呼ばれます。
The proliferation of software DUTs, with frequent software updates and a number of different frame processing modes and configurations, has increased both the number of performance tests required to verify the DUT update and the frequency of running those tests. This makes the overall test execution time even more important than before.
ソフトウェア DUT の急増により、頻繁なソフトウェア更新とさまざまなフレーム処理モードおよび構成が増加し、DUT 更新を検証するために必要なパフォーマンス テストの数と、それらのテストの実行頻度の両方が増加しました。これにより、テスト全体の実行時間が以前よりもさらに重要になります。
The definition of Throughput test methodology per [RFC2544] restricts the potential for time-efficiency improvements. The Binary Search, when used in a manner unconditionally compliant with [RFC2544] Throughput methodology, is excessively slow due to two main factors.
[RFC2544] によるスループット テスト方法の定義により、時間効率の向上の可能性が制限されます。[RFC2544] スループット方法論に無条件に準拠した方法でバイナリ サーチを使用すると、2 つの主な要因により過度に遅くなります。
First, a significant amount of time is spent on Trials with Loads that, in retrospect, are far from the final determined Throughput.
まず、負荷を伴うトライアルにかなりの時間が費やされており、後から考えると、最終的に決定されたスループットには程遠いものになります。
Second, [RFC2544] does not specify any stopping condition for Throughput search, so users of testing equipment implementing the procedure already have access to a limited trade-off between Search Duration and achieved precision, as each one of the full 60-second Trials halves the interval of possible results.
第二に、[RFC2544] はスループット検索の停止条件を指定していないため、60 秒のトライアルごとに可能な結果の間隔が半分になるため、この手順を実装するテスト機器のユーザーはすでに検索期間と達成される精度の間の限られたトレードオフにアクセスできます。
As such, not many Trials can be removed without a substantial loss of precision.
そのため、精度を大幅に損なうことなく削除できるトライアルは多くありません。
Section 19 of [RFC2544] specifies a test setup with an external tester stimulating the networking system, treating it either as a single Device Under Test (DUT) or as a system of devices, a System Under Test (SUT).
[RFC2544] のセクション 19 では、ネットワーク システムを刺激する外部テスターによるテスト設定を指定し、ネットワーク システムを単一のテスト対象デバイス (DUT) またはデバイスのシステムであるテスト対象システム (SUT) として扱います。
[RFC2285] defines these terms as follows.
[RFC2285] ではこれらの用語を次のように定義しています。
DUT:
試験対象:
The network frame forwarding device to which stimulus is offered and response measured (Section 3.1.1 of [RFC2285]).
スティミュラスが提供され、応答が測定されるネットワーク フレーム転送デバイス ([RFC2285] のセクション 3.1.1)。
SUT:
SUT:
The collective set of network devices to which stimulus is offered as a single entity and response measured (Section 3.1.2 of [RFC2285]).
刺激が単一のエンティティとして提供され、応答が測定されるネットワーク デバイスの集合セット ([RFC2285] のセクション 3.1.2)。
For software-based data plane forwarding running on commodity x86/ARM CPUs, the SUT comprises not only the forwarding application itself, the DUT, but also the entire execution environment: host hardware, firmware and kernel/hypervisor services, as well as any other software workloads that share the same CPUs, memory, and I/O resources.
汎用 x86/ARM CPU 上で実行されるソフトウェア ベースのデータ プレーン転送の場合、SUT は転送アプリケーション自体である DUT だけでなく、実行環境全体 (ホスト ハードウェア、ファームウェア、カーネル/ハイパーバイザー サービス、および同じ CPU、メモリ、および I/O リソースを共有するその他のソフトウェア ワークロード) も含みます。
Given that a SUT is a shared multi-tenant environment, the DUT might inadvertently experience interference from the operating system or from other software operating on the same server.
SUT が共有マルチテナント環境であることを考えると、DUT はオペレーティング システムまたは同じサーバー上で動作している他のソフトウェアからの干渉を誤って受ける可能性があります。
Some of this interference can be mitigated. For instance, in multi-core CPU systems, pinning DUT program threads to specific CPU cores and isolating those cores can prevent context switching.
この干渉の一部は軽減できます。たとえば、マルチコア CPU システムでは、DUT プログラム スレッドを特定の CPU コアに固定し、それらのコアを分離すると、コンテキストの切り替えを防ぐことができます。
Despite taking all feasible precautions, some adverse effects may still impact the DUT's network performance. In this document, these effects are collectively referred to as SUT noise, even if the effects are not as unpredictable as what other engineering disciplines call noise.
可能な限りの予防措置を講じたにもかかわらず、何らかの悪影響が DUT のネットワーク パフォーマンスに影響を与える可能性があります。この文書では、他の工学分野でノイズと呼ばれるような影響が予測不可能ではない場合でも、これらの影響を総称して SUT ノイズと呼びます。
A DUT can also exhibit fluctuating performance itself, for reasons not related to the rest of SUT. For example, this can be due to pauses in execution as needed for internal stateful processing. In many cases, this may be an expected per-design behavior, as it would be observable even in a hypothetical scenario where all sources of SUT noise are eliminated. Such behavior affects Trial Results in a way similar to SUT noise. As the two phenomena are hard to distinguish, in this document, the term _noise_ is used to encompass both the internal performance fluctuations of the DUT and the genuine noise of the SUT.
DUT は、SUT の他の部分とは関係のない理由で、それ自体のパフォーマンスの変動を示すこともあります。たとえば、内部ステートフル処理に必要な実行の一時停止が原因である可能性があります。多くの場合、これは設計ごとに予想される動作である可能性があります。これは、SUT ノイズの発生源がすべて除去されている仮想シナリオでも観察できるためです。このような動作は、SUT ノイズと同様にトライアル結果に影響を与えます。2 つの現象を区別するのは難しいため、このドキュメントでは、「ノイズ」という用語を、DUT の内部性能変動と SUT の真のノイズの両方を包含するために使用します。
A simple model of SUT performance consists of an idealized noiseless performance and additional noise effects. For a specific SUT, the noiseless performance is assumed to be constant, with all observed performance variations being attributed to noise. The impact of the noise can vary in time, sometimes wildly, even within a single Trial. The noise can sometimes be negligible, but it frequently lowers the observed SUT performance as observed in Trial Results.
SUT パフォーマンスの単純なモデルは、理想的なノイズレス パフォーマンスと追加のノイズ効果で構成されます。特定の SUT については、ノイズのない性能は一定であると想定され、観測されたすべての性能変動はノイズに起因すると考えられます。ノイズの影響は時間の経過とともに変化する可能性があり、たとえ 1 回のトライアル内であっても、場合によっては大幅に変化することがあります。ノイズは無視できる場合もありますが、トライアル結果で観察されたように、観察された SUT パフォーマンスが低下することがよくあります。
In this simple model, a SUT does not have a single performance value; it has a spectrum. One end of the spectrum is the idealized noiseless performance, and the other end can be called a noiseful performance. In practice, Trial Results close to the noiseful end of the spectrum happen only rarely. The worse a possible performance is, the more rarely it is seen in a Trial. Therefore, the extreme noiseful end of the SUT spectrum is not observable among Trial Results.
この単純なモデルでは、SUT には単一のパフォーマンス値がありません。それはスペクトルを持っています。スペクトルの一端は理想的なノイズのないパフォーマンスであり、もう一端はノイズの多いパフォーマンスと呼ぶことができます。実際には、スペクトルのノイズの多い端に近いトライアル結果が発生することはほとんどありません。考えられるパフォーマンスが悪ければ悪いほど、トライアルでそれが見られることは少なくなります。したがって、SUT スペクトルの極端にノイズの多い端は、トライアル結果では観察できません。
Furthermore, the extreme noiseless end of the SUT spectrum is unlikely to be observable, this time because minor noise events almost always occur during each Trial, nudging the measured performance slightly below the theoretical maximum.
さらに、SUT スペクトルの極端にノイズのない端が観察できる可能性は低いです。これは、各トライアル中にほぼ常に小さなノイズ イベントが発生し、測定されたパフォーマンスが理論上の最大値をわずかに下回るからです。
Unless specified otherwise, this document's focus is on the potentially observable ends of the SUT performance spectrum, as opposed to the extreme ones.
特に指定のない限り、この文書の焦点は、極端なものではなく、SUT パフォーマンス スペクトルの潜在的に観察可能な端にあります。
When focusing on the DUT, the benchmarking effort should ideally aim to eliminate only the SUT noise from SUT measurements. However, this is currently not feasible in practice, as there are no realistic enough models that would be capable to distinguish SUT noise from DUT fluctuations (based on the available literature at the time of writing).
DUT に焦点を当てる場合、ベンチマーク作業は理想的には SUT 測定から SUT ノイズのみを除去することを目指す必要があります。ただし、SUT のノイズと DUT の変動を区別できる十分に現実的なモデルがないため (執筆時点で入手可能な文献に基づく)、これは現時点では実際には実現不可能です。
If the SUT execution environments and any co-resident workloads place only negligible demands on SUT shared resources, so that the DUT remains the principal performance limiter, the DUT's ideal noiseless performance is defined as the noiseless end of the SUT performance spectrum.
SUT 実行環境および共存ワークロードが SUT 共有リソースに無視できるほどの要求しか課さない場合、DUT が主要なパフォーマンス リミッターのままである場合、DUT の理想的なノイズレス パフォーマンスは、SUT パフォーマンス スペクトルのノイズレス端として定義されます。
Note that by this definition, DUT noiseless performance also minimizes the impact of DUT fluctuations, as much as realistically possible for a given Trial Duration.
この定義により、DUT のノイズレス性能は、特定の試用期間で現実的に可能な限り DUT 変動の影響を最小限に抑えることにも注意してください。
The MLRsearch methodology aims to solve the DUT-in-SUT problem by estimating the noiseless end of the SUT performance spectrum using a limited number of Trial Results.
MLRsearch 方法論は、限られた数の試行結果を使用して SUT 性能スペクトルのノイズのない端を推定することにより、SUT 内 DUT 問題を解決することを目的としています。
Improvements to the Throughput search algorithm, aimed at better dealing with software networking SUT and DUT setups, should adopt methods that explicitly model SUT-generated noise, deriving surrogate metrics that approximate the (proxies for) DUT noiseless performance across a range of SUT noise-tolerance levels.
ソフトウェア ネットワーキング SUT および DUT セットアップをより適切に処理することを目的としたスループット検索アルゴリズムの改善では、SUT が生成するノイズを明示的にモデル化し、さまざまな SUT ノイズ耐性レベルにわたる DUT ノイズレス性能 (の代理) を近似する代理メトリクスを導出する方法を採用する必要があります。
[RFC2544] does not suggest repeating Throughput search. Also, note that from simply one discovered Throughput, it cannot be determined how repeatable that value is. Unsatisfactory repeatability then leads to unacceptable comparability, as different benchmarking teams may obtain varying Throughput values for the same SUT, exceeding the expected differences from search precision. Repeatability is also important when the test procedure is kept the same, but SUT is varied in small ways. For example, during development of software-based DUTs, repeatability is needed to detect small regressions.
[RFC2544] は、スループット検索を繰り返すことを推奨していません。また、発見された 1 つのスループットだけでは、その値がどの程度再現可能であるかを判断できないことにも注意してください。再現性が不十分だと、異なるベンチマーク チームが同じ SUT に対してさまざまなスループット値を取得し、検索精度から予想される差異を超える可能性があるため、許容できない比較可能性が生じます。テスト手順が同じであるにもかかわらず、SUT がわずかに変化する場合、再現性も重要です。たとえば、ソフトウェアベースの DUT の開発中に、小さな回帰を検出するには再現性が必要です。
[RFC2544] Throughput requirements (60-second Trial and no tolerance of a single frame loss) affect the Throughput result as follows.
[RFC2544] スループット要件 (60 秒のトライアルおよび単一フレーム損失の許容なし) は、スループットの結果に次のように影響します。
The SUT behavior close to the noiseful end of its performance spectrum consists of rare occasions of significantly low performance, but the long Trial Duration makes those occasions not so rare on the Trial level. Therefore, the Binary Search results tend to spread away from the noiseless end of SUT performance spectrum more frequently and more widely than shorter Trials would, thus causing unacceptable Throughput repeatability.
パフォーマンス スペクトルのノイズが多い端に近い SUT の動作では、まれにパフォーマンスが著しく低下することがありますが、トライアル期間が長いため、トライアル レベルではそのような状況はそれほど珍しいものではありません。したがって、バイナリ サーチの結果は、短いトライアルよりも頻繁かつ広範囲に SUT パフォーマンス スペクトルのノイズのない端から拡散する傾向があり、許容できないスループットの再現性が発生します。
The repeatability problem can be better addressed by defining a search procedure that identifies a consistent level of performance, even if it does not meet the strict definition of Throughput test methodology in [RFC2544].
再現性の問題は、[RFC2544] のスループット テスト方法の厳密な定義を満たしていない場合でも、一貫したパフォーマンス レベルを特定する検索手順を定義することでより適切に対処できます。
According to the SUT performance spectrum model, better repeatability will be at the noiseless end of the spectrum. Therefore, solutions to the DUT-in-SUT problem will also help with the repeatability problem.
SUT パフォーマンス スペクトル モデルによると、スペクトルのノイズのない端で再現性が向上します。したがって、DUT-in-SUT 問題の解決策は再現性の問題にも役立ちます。
Conversely, any alteration to [RFC2544] Throughput search that improves repeatability should be considered as less dependent on the SUT noise.
逆に、再現性を向上させる [RFC2544] スループット検索への変更は、SUT ノイズへの依存度が低いとみなされる必要があります。
An alternative option is to simply run a search multiple times and report some statistics (e.g., average and standard deviation and/or percentiles like p95).
別のオプションは、単純に検索を複数回実行し、いくつかの統計 (平均、標準偏差、および/または p95 のようなパーセンタイル) をレポートすることです。
This can be used for a subset of tests deemed more important, but it makes the Search Duration problem even more pronounced.
これは、より重要であると考えられるテストのサブセットに使用できますが、検索時間の問題がさらに顕著になります。
Section 3.17 of [RFC1242] defines Throughput as:
[RFC1242] のセクション 3.17 では、スループットを次のように定義しています。
The maximum rate at which none of the offered frames are dropped by the device.
提供されたフレームがデバイスによってドロップされない最大レート。
Then, it says:
そして、こう書かれています。
Since even the loss of one frame in a data stream can cause significant delays while waiting for the higher level protocols to time out, it is useful to know the actual maximum data rate that the device can support.
データ ストリーム内の 1 フレームの損失でも、上位レベルのプロトコルのタイムアウトを待機している間に大幅な遅延が発生する可能性があるため、デバイスがサポートできる実際の最大データ レートを知っておくと役立ちます。
However, many benchmarking teams accept a low, non-zero Goal Loss Ratio for their Load search.
ただし、多くのベンチマーク チームは、負荷検索でゼロではない低いゴール損失率を受け入れます。
There are many motivations:
動機はたくさんあります。
* Networking protocols tolerate frame loss better, compared to the time when [RFC1242] and [RFC2544] were specified.
* [RFC1242] や [RFC2544] が規定されていた時代と比べて、ネットワーキング プロトコルはフレーム損失に対する耐性が向上しています。
* Increased link speeds require Trials sending more frames within the same duration, increasing the chance of a small SUT performance fluctuation being enough to cause frame loss.
* リンク速度が増加すると、同じ期間内により多くのフレームを送信するトライアルが必要になり、SUT パフォーマンスのわずかな変動でフレーム損失が発生する可能性が高くなります。
* Because noise-related drops usually arrive in small bursts, their impact on the Trial Loss Ratio is diluted by the longer intervals in which the SUT operates close to its noiseless performance; consequently, the Trial Loss Ratio as an average over the Trial can still end up below the specified Goal Loss Ratio.
* ノイズ関連のドロップは通常、小さなバーストで発生するため、試行損失率に対する影響は、SUT がノイズのないパフォーマンスに近い状態で動作する間隔が長くなることによって弱められます。したがって、トライアル全体の平均としてのトライアル損失率は、指定された目標損失率を下回る可能性があります。
* If an approximation of the SUT noise impact on the Trial Loss Ratio is known, it can be set as the Goal Loss Ratio.
* トライアル損失率に対する SUT ノイズの影響の近似値がわかっている場合は、それを目標損失率として設定できます。
For more information, see Section 5 of [Lencze-Shima] (and the references there) for a few synthetic examples, confirming that each protocol and application can have different realistic Goal Loss Ratios.
詳細については、[Lencze-Shima] のセクション 5 (およびそこにある参考文献) でいくつかの合成例を参照し、各プロトコルとアプリケーションが異なる現実的な目標損失率を持つ可能性があることを確認します。
Regardless of the validity of all similar motivations, support for non-zero Goal Loss Ratios makes a search algorithm applicable for a wider range of use cases than the approach defined in [RFC2544].
同様の動機すべての有効性に関係なく、ゼロ以外の目標損失率のサポートにより、検索アルゴリズムは [RFC2544] で定義されたアプローチよりも幅広いユースケースに適用できるようになります。
Furthermore, allowing users to specify multiple Goal Loss Ratios, and enabling a single Search to find all relevant bounds, significantly enhances the usefulness of the search algorithm.
さらに、ユーザーが複数の目標損失率を指定できるようになり、1 回の検索で関連するすべての境界を見つけることができるようになり、検索アルゴリズムの有用性が大幅に向上します。
Searching for multiple Search Goals also helps to describe the SUT performance spectrum better than the result of a single Search Goal. For example, the repeated wide gap between zero and non-zero loss Loads indicates the noise has a large impact on the observed performance, which is not evident from the result of a single goal Load search procedure.
複数の検索目標を検索すると、単一の検索目標の結果よりも SUT のパフォーマンス スペクトルをより正確に説明できます。たとえば、ゼロ損失負荷とゼロ以外の損失負荷の間で繰り返される広いギャップは、ノイズが観察されたパフォーマンスに大きな影響を与えていることを示していますが、これは単一の目標負荷検索手順の結果からは明らかではありません。
It is easy to modify the Binary Search to find a Lower Bound for the Load that satisfies a single non-zero Goal Loss Ratio. But how to search for multiple goals at once is not that obvious; hence, the support for multiple Search Goals remains a problem.
二分探索を変更して、ゼロ以外の単一の目標損失率を満たす負荷の下限を見つけるのは簡単です。しかし、複数の目標を一度に検索する方法はそれほど明白ではありません。したがって、複数の検索目標のサポートには依然として問題があります。
At the time of writing, there does not seem to be a consensus in the industry on which Goal Loss Ratio is the best. For users, performance of higher protocol layers is important, for example, goodput of TCP connection (TCP throughput [RFC6349]), but the relationship between goodput and Trial Loss Ratio is not simple. Refer to [Lencze-Kovacs-Shima] for examples of various corner cases, Section 3 of [RFC6349] for Goal Loss Ratios acceptable for an accurate measurement of TCP throughput, and [Ott-Mathis-Semke-Mahdavi] for models and computations of TCP performance in presence of packet loss.
この記事の執筆時点では、どの失点率が最も優れているかについて業界でコンセンサスが取れていないようです。ユーザーにとって、TCP 接続のグッドプット (TCP スループット [RFC6349]) など、上位プロトコル層のパフォーマンスは重要ですが、グッドプットと試行損失率の関係は単純ではありません。さまざまな例外ケースの例については [Lencze-Kovacs-Shima] を、TCP スループットの正確な測定に許容される目標損失率については [RFC6349] のセクション 3 を、パケット損失が存在する場合の TCP パフォーマンスのモデルと計算については [Ott-Mathis-Semke-Mahdavi] を参照してください。
While performing Throughput search by executing a sequence of measurement Trials, there is a risk of encountering inconsistencies between Trial Results.
一連の測定トライアルを実行してスループット検索を実行すると、トライアル結果間に不一致が発生するリスクがあります。
Examples include but are not limited to:
例には以下が含まれますが、これらに限定されません。
* A Trial at the same Load (same or different Trial Duration) results in a different Trial Loss Ratio.
* 同じ負荷でのトライアル (同じまたは異なるトライアル期間) では、異なるトライアル損失率が生じます。
* A Trial at a larger Load (same or different Trial Duration) results in a lower Trial Loss Ratio.
* より大きな負荷でのトライアル (同じまたは異なるトライアル期間) では、トライアル損失率が低くなります。
The Binary Search never encounters inconsistent Trials. But [RFC2544] hints about the possibility of Inconsistent Trial Results in two places in its text. The first place is Section 24 of [RFC2544], where full Trial Durations are required, presumably because they can be inconsistent with the Trial Results from shorter Trial Durations. The second place is Section 26.3 of [RFC2544], where two successive zero-loss Trials are recommended, presumably because after one zero-loss Trial Result, there can be a subsequent inconsistent non-zero-loss Trial Result.
二分探索では、矛盾したトライアルが発生することはありません。しかし、[RFC2544] は本文中の 2 か所で一貫性のない試験結果の可能性について示唆しています。最初の場所は [RFC2544] のセクション 24 で、ここでは完全なトライアル期間が要求されています。これはおそらく、トライアル期間が短い場合のトライアル結果と矛盾する可能性があるためです。2 番目は [RFC2544] のセクション 26.3 で、ここでは 2 つの連続するゼロ損失トライアルが推奨されています。これはおそらく、1 つのゼロ損失トライアル結果の後に、その後に一貫性のない非ゼロ損失トライアル結果が存在する可能性があるためです。
A robust Throughput search algorithm needs to decide how to continue the search in the presence of such inconsistencies. Definitions of Throughput and its test methodology in [RFC1242] and [RFC2544] are not specific enough to imply a unique way of handling such inconsistencies.
堅牢なスループット検索アルゴリズムでは、このような不一致が存在する場合に検索を続行する方法を決定する必要があります。[RFC1242] および [RFC2544] におけるスループットの定義とそのテスト方法論は、そのような矛盾を処理する独自の方法を示唆するほど具体的ではありません。
Ideally, there will be a definition of a new metric that both generalizes Throughput for non-zero Goal Loss Ratio (and other possible repeatability enhancements) while being precise enough to force a specific way to resolve Trial Result inconsistencies. But until such a definition is agreed upon, the correct way to handle Inconsistent Trial Results remains an open problem.
理想的には、トライアル結果の不一致を解決するための特定の方法を強制するのに十分な精度を備えながら、ゼロ以外の目標損失率のスループット (およびその他の可能な再現性の強化) を一般化する新しい指標の定義が存在します。しかし、そのような定義が合意されるまでは、一貫性のない試験結果を適切に処理する方法は未解決の問題のままです。
_Relevant Lower Bound_ is the MLRsearch term that addresses this problem.
_関連下限_ は、この問題に対処する MLRsearch 用語です。
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] で説明されているように解釈されます。
This document is categorized as an Informational RFC. While it does not mandate the adoption of the MLRsearch methodology, it uses the normative language of BCP 14 [RFC2119] [RFC8174] to provide an unambiguous specification. This ensures that if a test procedure or Test Report claims compliance with the MLRsearch Specification, it MUST adhere to all the absolute requirements defined herein. The use of normative language is intended to promote repeatable and comparable results among those who choose to implement this methodology.
この文書は情報 RFC として分類されます。MLRsearch 方法論の採用を強制するものではありませんが、BCP 14 [RFC2119] [RFC8174] の規範的な言語を使用して、明確な仕様を提供します。これにより、テスト手順またはテストレポートが MLRsearch 仕様への準拠を主張する場合、ここで定義されているすべての絶対要件を遵守しなければなりません。規範的な表現の使用は、この方法論の実装を選択した人々の間で再現可能で比較可能な結果を促進することを目的としています。
This section provides all technical definitions needed for evaluating whether a particular test procedure complies with the MLRsearch Specification.
このセクションでは、特定のテスト手順が MLRsearch 仕様に準拠しているかどうかを評価するために必要なすべての技術的定義を提供します。
Some terms used in the specification are capitalized. This is a stylistic choice for this document, reminding the reader that the term is introduced, defined, or explained elsewhere in the document. Lowercase variants are equally valid; capitalization was already applied in earlier sections where required.
仕様内で使用される一部の用語は大文字で表記されています。これはこの文書の文体上の選択であり、この用語が文書内の他の場所で導入、定義、または説明されていることを読者に思い出させます。小文字のバリアントも同様に有効です。大文字の使用は、必要に応じて前のセクションですでに適用されています。
This document does not separate terminology from methodology. _Terms_ are fully specified and discussed in their own subsections, under sections with the word "Terms" in their titles. This way, the list of terms is visible in the table of contents.
この文書では、用語と方法論を区別しません。_用語_は、タイトルに「用語」という単語が含まれるセクションの下にある独自のサブセクションで完全に指定され、説明されています。このようにして、用語のリストが目次に表示されます。
Each term-defining subsection contains a short _Definition_ paragraph containing a minimal definition and all strict requirements, followed by _Discussion_ paragraphs focusing on important consequences and recommendations. Requirements about how other components can use the defined term are also included in the discussion.
用語を定義する各サブセクションには、最小限の定義とすべての厳格な要件を含む短い _Definition_ 段落が含まれており、その後に重要な結果と推奨事項に焦点を当てた _Discussion_ 段落が続きます。定義された用語を他のコンポーネントがどのように使用できるかに関する要件も議論に含まれます。
This document specifies the Multiple Loss Ratio Search (MLRsearch) methodology. The MLRsearch Specification details a new class of benchmarks by listing all terminology definitions and methodology requirements. The definitions support multi-goal benchmarks, with single-goal ones as a subset.
この文書では、Multiple Loss Ratio Search (MLRsearch) 方法論を指定します。MLRsearch 仕様では、すべての用語の定義と方法論の要件をリストすることにより、新しいクラスのベンチマークについて詳しく説明します。この定義では、単一目標のベンチマークをサブセットとして、複数目標のベンチマークがサポートされています。
The normative scope of this specification includes:
この仕様の規範的範囲には以下が含まれます。
* The terminology for all required quantities and their attributes.
* 必要なすべての数量とその属性の用語。
* An abstract architecture consisting of functional components (Manager, Controller, and Measurer) and the requirements for their inputs and outputs.
* 機能コンポーネント (マネージャー、コントローラー、測定者) とその入力と出力の要件で構成される抽象的なアーキテクチャ。
* The required structure and attributes of the Controller Input, including one or more Search Goals.
* 1 つ以上の検索目標を含む、コントローラー入力の必須の構造と属性。
* The required logic for Load Classification, which determines whether a given Load qualifies as a Lower Bound or an Upper Bound for a Search Goal.
* 負荷分類に必要なロジック。指定された負荷が検索目標の下限または上限として適格であるかどうかを決定します。
* The required structure and attributes of the Controller Output, including a Goal Result for each Search Goal.
* 各検索目標の目標結果を含む、コントローラー出力の必要な構造と属性。
The MLRsearch Specification is an independent methodology and does not change nor obsolete any part of [RFC2544].
MLRsearch 仕様は独立した方法論であり、[RFC2544] のどの部分も変更したり廃止したりするものではありません。
This specification permits deviations from the Trial procedure as described in [RFC2544]. Any deviation from the procedure in [RFC2544] must be documented explicitly in the Test Report, and such variations remain outside the scope of the original benchmarks in [RFC2544].
この仕様は、[RFC2544] に記載されているトライアル手順からの逸脱を許可します。[RFC2544] の手順からの逸脱はテストレポートに明示的に文書化する必要があり、そのような変動は [RFC2544] の元のベンチマークの範囲外のままです。
A specific single-goal MLRsearch benchmark can be configured to be compliant with [RFC2544] Throughput, and most procedures reporting [RFC2544] Throughput can be adapted to also satisfy MLRsearch requirements for a specific Search Goal.
特定の単一目標の MLRsearch ベンチマークは、[RFC2544] スループットに準拠するように構成でき、[RFC2544] スループットをレポートするほとんどの手順は、特定の検索目標の MLRsearch 要件を満たすように適合できます。
Methodology extensions from other BMWG documents that specify details for testing particular DUTs, configurations, or protocols (e.g., by defining a particular Traffic Profile) are considered orthogonal to MLRsearch and are applicable to a benchmark conducted using MLRsearch methodology.
特定の DUT、構成、またはプロトコルをテストするための詳細を指定する他の BMWG ドキュメントからの方法拡張 (特定のトラフィック プロファイルの定義など) は、MLRsearch と直交しているとみなされ、MLRsearch 方法を使用して実行されるベンチマークに適用できます。
The following aspects are explicitly out of the normative scope of this document:
次の側面は、明示的にこの文書の規範範囲外です。
* The internal heuristics or algorithms used by the Controller to select Trial Inputs are implementation specific.
* コントローラーがトライアル入力を選択するために使用する内部ヒューリスティックまたはアルゴリズムは、実装に固有です。
* Treatment of situations where Offered Load is found to differ noticeably from Intended Load is not prescribed, only the "use smaller Max Load" recommendation is mentioned.
* 提供された負荷が意図された負荷と著しく異なることが判明した状況の処理については規定されておらず、「より小さい最大負荷を使用する」という推奨事項のみが言及されています。
* The potential for, and the effects of, interference between different Search Goals within a multi-goal search are considered outside the normative scope of this specification.
* 複数の目標検索内の異なる検索目標間の干渉の可能性とその影響は、この仕様の規範範囲外と考えられます。
* This specification does not mandate any single, universal Search Goal configuration for all use cases. The selection of Search Goal parameters is left to the operator of the test procedure or may be recommended in future publications.
* この仕様は、すべてのユースケースに対して単一の普遍的な検索目標構成を義務付けるものではありません。検索目標パラメータの選択は、テスト手順のオペレータに任されるか、将来の出版物で推奨される可能性があります。
Several weak recommendations related to Search Goal possibilities are included, but they are conditional on specific intents (for example, compatibility with other methodologies) and are not considered universal enough yet.
検索目標の可能性に関連する弱い推奨事項がいくつか含まれていますが、それらは特定の目的 (他の方法論との互換性など) に条件があり、まだ十分に普遍的であるとは考えられていません。
Although the normative text only references terminology that has already been introduced, explanatory passages sometimes profit from terms that are defined later in the document. To keep the initial read-through clear, this informative section offers a concise, top-down sketch of the complete MLRsearch architecture.
規範文書ではすでに導入されている用語のみが参照されていますが、説明文では文書の後半で定義されている用語が活用されることがあります。最初の内容を明確にするために、この有益なセクションでは、完全な MLRsearch アーキテクチャの簡潔なトップダウン スケッチを提供します。
The architecture is modelled as a set of abstract, interacting components. Information exchange between components is expressed in an imperative-programming style: One component _calls_ another, supplying inputs (arguments) and receiving outputs (return values). This notation is purely conceptual, actual implementations need not exchange explicit messages. When the text contrasts alternative behaviors, it refers to the different implementations of the same component.
アーキテクチャは、抽象的な相互作用するコンポーネントのセットとしてモデル化されます。コンポーネント間の情報交換は、命令型プログラミング スタイルで表現されます。つまり、あるコンポーネントが別のコンポーネントを呼び出し、入力 (引数) を提供し、出力 (戻り値) を受け取ります。この表記は純粋に概念的なものであり、実際の実装では明示的なメッセージを交換する必要はありません。本文で代替動作を対比する場合、同じコンポーネントのさまざまな実装について言及しています。
A test procedure is considered _compliant_ with the MLRsearch Specification if it can be conceptually decomposed into the abstract components defined herein, and if each component satisfies the requirements defined for its corresponding MLRsearch Specification section.
テスト手順がここで定義された抽象コンポーネントに概念的に分解でき、各コンポーネントが対応する MLRsearch 仕様セクションに定義された要件を満たしている場合、テスト手順は MLRsearch 仕様に「準拠」しているとみなされます。
The _Measurer_ component is tasked to perform Trials, the _Controller_ component is tasked to select Trial Durations and Loads, and the _Manager_ component is tasked to preconfigure involved entities and to produce the _Test Report_. The Test Report explicitly states _Search Goals_ (as Controller Input) and corresponding _Goal Results_ (Controller Output).
_Measurer_ コンポーネントはトライアルを実行する役割を果たし、_Controller_ コンポーネントはトライアル期間と負荷を選択する役割を果たし、_Manager_ コンポーネントは関連エンティティを事前構成して _Test Report_ を作成する役割を果たします。テスト レポートには、_検索目標_ (コントローラー入力として) と、対応する_目標結果_ (コントローラー出力) が明示的に記載されています。
This constitutes one _benchmark_ (single-goal or multi-goal). Repeated or slightly differing benchmarks are realized by calling the Controller once for each benchmark.
これは 1 つのベンチマーク (単一目標または複数目標) を構成します。ベンチマークを繰り返すか、わずかに異なるベンチマークは、ベンチマークごとにコントローラーを 1 回呼び出すことで実現されます。
For one benchmark, the Manager calls a Controller once, and the Controller then invokes the Measurer repeatedly until the Controller decides it has enough information to return its outputs.
1 つのベンチマークについて、Manager はコントローラーを 1 回呼び出し、コントローラーは出力を返すのに十分な情報があるとコントローラーが判断するまで繰り返し Measurer を呼び出します。
The part during which the Controller invokes the Measurer is termed the _Search_. Any work the Manager performs, either before invoking the Controller or after Controller returns, falls outside the scope of the Search.
コントローラーが測定者を呼び出す部分は、_Search_ と呼ばれます。コントローラーを呼び出す前またはコントローラーが戻った後にマネージャーが実行する作業は、検索の範囲外になります。
The MLRsearch Specification prescribes Regular Goal Results and recommends corresponding Search completion conditions. Irregular Goal Results are also allowed, they have different requirements and their corresponding stopping conditions are out of scope. The Search Result is the combination of regular or irregular results, one for each Search Goal.
MLRsearch 仕様では、通常の目標結果を規定し、対応する検索完了条件を推奨します。不規則なゴール結果も許可されますが、それらには異なる要件があり、対応する停止条件は範囲外です。検索結果は、検索目標ごとに 1 つずつ、定期的または不規則な結果の組み合わせです。
Search Results are based on _Load Classification_. When measured enough, a chosen _Load_ can either achieve or fail each Search Goal (separately), thus becoming a Lower Bound or an Upper Bound for that Search Goal.
検索結果は_負荷分類_に基づいています。十分に測定されると、選択された _Load_ は各検索目標を (個別に) 達成または失敗するため、その検索目標の下限または上限になります。
When the _Relevant Lower Bound_ is close enough to the _Relevant Upper Bound_ according to _Goal Width_, the _Regular Goal Result_ is found. Search stops when all Regular Goal Results are found or when all remaining Search Goals are proven to have only _Irregular Goal Results_.
_目標幅_に従って_関連下限_が_関連上限_に十分近い場合、_通常の目標結果_が見つかります。すべての正規の目標結果が見つかった場合、または残りのすべての検索目標に_不規則な目標結果_しかないことが証明された場合、検索は停止します。
Even if the time it takes the Controller to compute _Trial Input_ attributes for next Trial is negligible; Trials themselves take some time to finish, and SUT behavior affects how quickly stopping conditions can be satisfied.
たとえ、コントローラーが次のトライアルの _Trial Input_ 属性を計算するのにかかる時間が無視できるほどである場合でも、トライアル自体は終了するまでに時間がかかり、SUT の動作は停止条件がどれだけ早く満たされるかに影響します。
For large scale tests where many SUT configurations and Traffic Profiles need benchmarking, it is important to optimize the overall duration of one Search, while the time cost of initial configuration tends to be constant. There are three considerations worth discussing for such _Search Duration_ optimization.
多くの SUT 構成とトラフィック プロファイルでベンチマークが必要な大規模テストの場合、初期構成の時間コストは一定になる傾向がある一方で、1 回の検索の全体的な期間を最適化することが重要です。このような_検索期間_の最適化については、議論する価値のある考慮事項が 3 つあります。
Firstly, as SUT behavior can be probabilistic, so can be the Search Duration of each benchmark. The quantity to optimize is the expected value of Search Duration, it should be as short as possible within the intended reliability.
まず、SUT の動作は確率的になる可能性があるため、各ベンチマークの検索期間も確率的になる可能性があります。最適化する量は検索期間の期待値であり、意図された信頼性の範囲内で可能な限り短くする必要があります。
Secondly, Search Duration probability distributions with smaller standard deviations are preferred, as it makes it easier to plan execution of multiple benchmarks one-by-one on the same SUT.
第 2 に、同じ SUT で複数のベンチマークを 1 つずつ実行する計画が容易になるため、標準偏差が小さい検索期間確率分布が推奨されます。
Thirdly, any prior knowledge about SUT behavior can be leveraged into average time gains if the Controller implementation supports corresponding heuristics. Without such knowledge, implementations should focus on worst possible results, as lowering Search Duration for those helps with standard deviation, if not also the expected value.
第三に、コントローラーの実装が対応するヒューリスティックをサポートしている場合、SUT の動作に関する事前の知識を平均時間の向上に活用できます。そのような知識がなければ、実装では考えられる最悪の結果に焦点を当てる必要があります。検索期間を短くすると、期待値ではないにしても標準偏差が向上するためです。
Most of optimization heuristics are outside of the scope of this document, but many design decisions were affected by generic optimizations found in practice so far.
最適化ヒューリスティックのほとんどはこのドキュメントの範囲外ですが、多くの設計上の決定は、これまでに実際に見られた一般的な最適化によって影響を受けました。
A primary responsibility of the Manager is to produce a Test Report, which serves as the final and formal output of the test procedure.
マネージャーの主な責任は、テスト手順の最終的かつ正式な出力として機能するテスト レポートを作成することです。
This document does not provide a single, complete, normative definition for the structure of the Test Report. For example, the Test Report may contain results for a single benchmark, or it could aggregate results of many benchmarks.
この文書は、テストレポートの構造に関する単一の完全な規範的な定義を提供するものではありません。たとえば、テスト レポートには、単一のベンチマークの結果が含まれる場合もあれば、多数のベンチマークの結果が集約される場合もあります。
Instead, normative requirements for the content of the Test Report are specified throughout this document in conjunction with the definitions of the quantities and procedures to which they apply. Readers should note that any clause requiring a quantity to be "reported" or "stated in the Test Report" constitutes a normative requirement on the content of this final artifact.
代わりに、試験報告書の内容に対する規範的要件が、適用される量および手順の定義と併せて、本書全体で指定されます。読者は、量を「報告」または「試験報告書に記載」することを要求する条項は、この最終成果物の内容に関する規範的要件を構成することに注意してください。
Even where not stated explicitly, the "Reporting format" paragraphs in [RFC2544] are still requirements on Test Reports if they apply to an MLRsearch benchmark.
明示的に記載されていない場合でも、MLRsearch ベンチマークに適用される場合、[RFC2544] の「レポート形式」の段落は依然としてテストレポートの要件です。
The MLRsearch Specification by itself does not guarantee that the Search ends in finite time, as the freedom the Controller has for Load selection also allows for clearly deficient choices.
MLRsearch 仕様自体は、コントローラーがロード選択に関して持つ自由により、明らかに不十分な選択肢も許容するため、検索が有限時間内に終了することを保証しません。
For deeper insights on these matters, refer to [FDio-CSIT-MLRsearch].
これらの事項に関するより深い洞察については、[FDio-CSIT-MLRsearch] を参照してください。
The primary MLRsearch implementation, used as the prototype for this specification, is [PyPI-MLRsearch].
この仕様のプロトタイプとして使用される主要な MLRsearch 実装は、[PyPI-MLRsearch] です。
The MLRsearch Specification relies on several specific _quantities_.
MLRsearch 仕様は、いくつかの特定の「量」に依存しています。
In physics, a single magnitude can be expressed in multiple ways as a product of a _unit_ and a _value_. This document uses the computer science vocabulary, where the term "quantity" can describe multiple variables or constants at once.
物理学では、単一の大きさは、_unit_ と _value_ の積として複数の方法で表現できます。このドキュメントではコンピューター サイエンスの用語を使用しており、「量」という用語は複数の変数または定数を一度に表すことができます。
One _instance_ of a scalar quantity is called a _value_, with the corresponding unit only mentioned when needed. Where the context allows, a shorter phrase is used, for example, "Load" instead of "value of the Load quantity".
スカラー量の 1 つの_インスタンス_は_値_と呼ばれ、対応する単位は必要な場合にのみ言及されます。文脈が許せば、「積載数量の値」の代わりに「積載」など、より短いフレーズが使用されます。
In general, the MLRsearch Specification does not prescribe particular units to be used, but it is REQUIRED for the Test Report to state all the units. For example, ratio quantities can be dimensionless numbers between zero and one but may be expressed as percentages instead.
一般に、MLRsearch 仕様では使用する特定の単位は規定されていませんが、テスト レポートにはすべての単位を記載することが必須です。たとえば、比率量は 0 から 1 までの無次元数にすることができますが、代わりにパーセンテージで表すこともできます。
In rare cases, a _primary unit_ is mentioned, usually when comparison across different Traffic Profiles would be otherwise ambiguous. Some units MAY be preferred by some implementations, for example, when they round the values to integers.
まれに、「プライマリ ユニット」が言及されることがありますが、これは通常、異なるトラフィック プロファイル間の比較があいまいになる場合に発生します。たとえば、値を整数に丸める場合など、実装によっては一部の単位が優先される場合があります。
For convenience, a group of quantities can be treated as a _composite_ quantity. One constituent of a composite quantity is called an _attribute_. A group of attribute values is called an _instance_ of that composite quantity.
便宜上、数量のグループを _composite_quantity として扱うことができます。複合量の 1 つの構成要素は、_属性_と呼ばれます。属性値のグループは、その複合量の_インスタンス_と呼ばれます。
Some attributes may depend on others and can be computed from other attributes. Such quantities are called _derived_ quantities.
一部の属性は他の属性に依存し、他の属性から計算できます。このような量は、_導出_量と呼ばれます。
Some quantities are defined in a way that makes it possible to compute their values in the middle of a Search. Other quantities are specified so that their values can be computed only after the Search ends. Some quantities are important only after a Search ends, but their values are also computable before a Search ends.
一部の数量は、検索の途中で値を計算できるように定義されています。他の数量は、検索の終了後にのみ値が計算できるように指定されます。一部の数量は検索終了後にのみ重要になりますが、その値は検索終了前に計算することもできます。
For a quantity that is computable before a Search ends, the adjective _current_ is used to mark a value of that quantity available before the Search ends. When such value is relevant for the Search Result, the adjective _final_ is used to denote the value of that quantity at the end of the Search.
検索が終了する前に計算可能な数量の場合、形容詞 _current_ を使用して、検索が終了する前に利用可能なその数量の値をマークします。このような値が検索結果に関連する場合、形容詞 _final_ を使用して、検索終了時の数量の値を示します。
If a time evolution of such a dynamic quantity is guided by configuration quantities, those adjectives can be used to distinguish such quantities. For example, if the current value of "duration" (a dynamic quantity) increases from "initial duration" to "final duration" (configuration quantities), all the quoted names denote separate but related quantities. As the naming suggests, the final value of the duration quantity is expected to be equal to the "final duration" value.
このような動的量の時間発展が構成量によって導かれる場合、それらの形容詞を使用してそのような量を区別できます。たとえば、「期間」(動的量) の現在の値が「初期期間」(構成量) から「最終期間」(構成量) に増加する場合、引用符で囲まれたすべての名前は、個別ではあるが関連する量を示します。名前が示すように、期間数量の最終値は「最終期間」値と等しいことが期待されます。
This specification relies on the following three documents that should be consulted before attempting to make use of this document:
この仕様は、このドキュメントを使用する前に参照する必要がある次の 3 つのドキュメントに依存しています。
* "Benchmarking Terminology for Network Interconnection Devices" [RFC1242] contains basic term definitions.
* 「ネットワーク相互接続デバイスのベンチマーク用語」[RFC1242] には、基本的な用語の定義が含まれています。
* "Benchmarking Terminology for LAN Switching Devices" [RFC2285] includes more terms and discussions, and it describes some known network benchmarking situations in a more precise way.
* 「LAN スイッチング デバイスのベンチマーク用語」[RFC2285] には、より多くの用語と議論が含まれており、既知のネットワーク ベンチマーク状況のいくつかがより正確に説明されています。
* "Benchmarking Methodology for Network Interconnect Devices" [RFC2544] contains discussions about terms and additional methodology requirements.
* 「ネットワーク相互接続デバイスのベンチマーク方法」[RFC2544] には、用語と追加の方法要件に関する議論が含まれています。
References to several central terms from the above documents are given in the following subsections. Some of those terms need no further discussion, but some require some elaboration to put into proper context.
上記の文書のいくつかの中心的な用語への参照を、次のサブセクションに示します。これらの用語の中には、これ以上説明する必要のないものもありますが、適切な文脈に入れるために多少の説明が必要なものもあります。
SUT is defined in Section 3.1.2 of [RFC2285] as follows.
SUT は、[RFC2285] のセクション 3.1.2 で次のように定義されています。
Definition:
意味：
The collective set of network devices to which stimulus is offered as a single entity and response measured.
単一のエンティティとして刺激が提供され、応答が測定されるネットワーク デバイスの集合セット。
Discussion:
議論：
A SUT consisting of a single network device is allowed by this definition.
この定義では、単一のネットワーク デバイスで構成される SUT が許可されます。
In software-based networking, SUT may comprise a multitude of networking applications and the entire host hardware and software execution environment.
ソフトウェアベースのネットワーキングでは、SUT は多数のネットワーキング アプリケーションとホスト ハードウェアおよびソフトウェア実行環境全体で構成されます。
SUT is the only entity that can be benchmarked directly, even though only the performance of some sub-components are of interest.
一部のサブコンポーネントのパフォーマンスのみが対象となる場合でも、SUT は直接ベンチマークできる唯一のエンティティです。
For example, Section 6.1 of [RFC2544] describes a single SUT consisting of DUT 1, DUT 2, and a WAN link between them.
たとえば、[RFC2544] のセクション 6.1 では、DUT 1、DUT 2、およびそれらの間の WAN リンクで構成される単一の SUT について説明しています。
DUT is defined in Section 3.1.1 of [RFC2285] as follows.
DUT は、[RFC2285] のセクション 3.1.1 で次のように定義されています。
Definition:
意味：
The network forwarding device to which stimulus is offered and response measured.
刺激が提供され、応答が測定されるネットワーク転送デバイス。
Discussion:
議論：
Contrary to SUT, the DUT stimulus and response are frequently initiated and observed only indirectly, on different parts of SUT.
SUT とは対照的に、DUT の刺激と応答は頻繁に開始され、SUT のさまざまな部分で間接的にのみ観察されます。
DUT, as a sub-component of SUT, is only indirectly mentioned in the MLRsearch Specification but is of key relevance for its motivation. The device can represent a software-based networking function running on commodity x86/ARM CPUs (vs. purpose-built ASICs, NPUs, and FPGAs).
SUT のサブコンポーネントとしての DUT は、MLRsearch 仕様では間接的にのみ言及されていますが、その動機付けには重要な関連性があります。このデバイスは、汎用の x86/ARM CPU (専用 ASIC、NPU、FPGA ではなく) 上で実行されるソフトウェア ベースのネットワーク機能を表すことができます。
When the MLRsearch Specification mentions SUT configuration, it implies adequate configuration of constituent DUTs, subjected to requirements from Section 7 of [RFC2544].
MLRsearch 仕様で SUT 構成について言及している場合、それは [RFC2544] のセクション 7 の要件に従って、構成要素となる DUT が適切に構成されていることを意味します。
A well-designed SUT SHOULD have the primary DUT as their performance bottleneck. The ways to achieve and verify that are outside the scope of the MLRsearch Specification. A typical exception to this rule is when DUT has a surprisingly good performance. For example, achieving the line rate does not make the SUT badly designed. This situation is quite common in practice, when the DUT is the bottleneck for a traffic consisting of small frames, but achieves the line rate with large frames.
適切に設計された SUT には、パフォーマンスのボトルネックとしてプライマリ DUT が存在する必要があります。それを達成および検証する方法は、MLRsearch 仕様の範囲外です。この規則の一般的な例外は、DUT のパフォーマンスが驚くほど優れている場合です。たとえば、ライン レートを達成しても、SUT の設計が不適切になるわけではありません。この状況は、実際には DUT が小さなフレームで構成されるトラフィックのボトルネックであるにもかかわらず、大きなフレームではライン レートを達成している場合に非常に一般的です。
A trial is the part of the test described in Section 23 of [RFC2544].
トライアルは、[RFC2544] のセクション 23 で説明されているテストの一部です。
Definition:
意味：
A particular test consists of multiple trials. Each trial returns one piece of information, for example, the loss rate at a particular input frame rate. Each trial consists of a number of phases:
特定のテストは複数のトライアルで構成されます。各トライアルは、特定の入力フレーム レートでの損失率など、1 つの情報を返します。各トライアルはいくつかのフェーズで構成されます。
a) If the DUT is a router, send the routing update to the "input" port and pause two seconds to be sure that the routing has settled.
a) DUT がルーターの場合は、ルーティングの更新を「入力」ポートに送信し、ルーティングが安定していることを確認するために 2 秒間停止します。
b) Send the "learning frames" to the "output" port and wait 2 seconds to be sure that the learning has settled. Bridge learning frames are frames with source addresses that are the same as the destination addresses used by the test frames. Learning frames for other protocols are used to prime the address resolution tables in the DUT. The formats of the learning frame that should be used are shown in the Test Frame Formats document.
b) 「学習フレーム」を「出力」ポートに送信し、学習が完了したことを確認するまで 2 秒待ちます。ブリッジ学習フレームは、テスト フレームで使用される宛先アドレスと同じ送信元アドレスを持つフレームです。他のプロトコルの学習フレームは、DUT 内のアドレス解決テーブルを準備するために使用されます。使用する必要がある学習フレームの形式は、「テスト フレーム形式」ドキュメントに示されています。
c) Run the test trial.
c) テストトライアルを実行します。
d) Wait for two seconds for any residual frames to be received.
d) 残りのフレームが受信されるまで 2 秒待ちます。
e) Wait for at least five seconds for the DUT to restabilize.
e) DUT が再安定するまで少なくとも 5 秒待ちます。
Discussion:
議論：
The traffic is sent only in phase c) and received in phases c) and d).
トラフィックはフェーズ c) でのみ送信され、フェーズ c) と d) で受信されます。
Trials are the only stimuli the SUT is expected to experience during the Search.
トライアルは、SUT が探索中に経験すると予想される唯一の刺激です。
It is useful to consider the traffic as sent and received by a tester, as implicitly defined in Section 6 of [RFC2544].
[RFC2544] のセクション 6 で暗黙的に定義されているように、トラフィックをテスターによって送受信されるものと考えると便利です。
The definition above describes some traits but does not use key words as defined in BCP 14 [RFC2119] [RFC8174] to signify the strength of the requirements. For the purposes of the MLRsearch Specification, the test procedure MAY deviate from the description in [RFC2544], but any such deviation MUST be described explicitly in the Test Report. It is still RECOMMENDED to not deviate from the description, as any deviation weakens comparability.
上記の定義はいくつかの特性を説明していますが、要件の強度を示すために BCP 14 [RFC2119] [RFC8174] で定義されているようなキーワードは使用していません。MLRsearch仕様の目的上、テスト手順は[RFC2544]の記述から逸脱してもよい(MAY)が、そのような逸脱はテストレポートに明示的に記述しなければならない(MUST)。逸脱すると比較可能性が弱まるため、説明から逸脱しないことが依然として推奨されます。
An example of deviation from [RFC2544] is using shorter wait times, compared to those described in phases a), b), d), and e).
[RFC2544] からの逸脱の例としては、フェーズ a)、b)、d)、および e) で説明されている待ち時間と比較して、より短い待ち時間を使用することが挙げられます。
[RFC2544] seems to treat phase b) as any type of configuration that cannot be configured only once (by the Manager, before the Search starts), as some crucial SUT state could time out during the Search. It is RECOMMENDED to interpret the "learning frames" to mean any such time-sensitive per-Trial configuration method, with bridge Media Access Control (MAC) address learning being only one possible example. Appendix C.2.4.1 of [RFC2544] lists another example: ARP with a wait time of 5 seconds.
[RFC2544] は、一部の重要な SUT 状態が検索中にタイムアウトする可能性があるため、フェーズ b) を 1 回だけ (検索開始前にマネージャーによって) 設定できない任意のタイプの設定として扱うようです。「学習フレーム」を、そのような時間に敏感なトライアルごとの設定方法を意味すると解釈することが推奨されます。ブリッジ メディア アクセス コントロール (MAC) アドレス学習は、考えられる一例にすぎません。[RFC2544] の付録 C.2.4.1 には、待機時間が 5 秒の ARP という別の例がリストされています。
Some methodologies describe recurring tests. If those are based on Trials, they are treated as multiple independent Trials. That means there are no "recurring trials" treated as a single measurement in MLRsearch, but the Controller MAY repeat the same Trial Inputs to get multiple independent Trial Outputs.
一部の方法論では、繰り返しのテストについて説明します。それらがトライアルに基づいている場合、それらは複数の独立したトライアルとして扱われます。つまり、MLRsearch では単一の測定値として扱われる「反復トライアル」はありませんが、コントローラーは同じトライアル入力を繰り返して複数の独立したトライアル出力を取得してもよい(MAY)。
Several existing quantities describe the intensity of the traffic entering a SUT. MLRsearch needs a quantity useful not only as an input for a Trial, but also as a basis for several related quantities not tied to a single Trial.
いくつかの既存の量は、SUT に入るトラフィックの強度を表します。MLRsearch には、トライアルの入力としてだけでなく、単一のトライアルに関連付けられていない複数の関連数量の基礎としても役立つ数量が必要です。
The following subsections refer to existing terms before introducing their combination used as such a base quantity in this document.
以下のサブセクションでは、この文書で基本数量として使用される組み合わせを紹介する前に、既存の用語について言及します。
Defined in "Intended load (Iload)" (Section 3.5.1 of [RFC2285]).
「意図された負荷 (Iload)」([RFC2285] のセクション 3.5.1) で定義されています。
Defined in "Offered load (Oload)" (Section 3.5.2 of [RFC2285]).
「提供負荷 (Oload)」([RFC2285] のセクション 3.5.2) で定義されています。
Defined in "Constant Load" (Section 3.4 of [RFC1242]).
「定負荷」([RFC1242] のセクション 3.4) で定義されています。
Definition:
意味：
Load is a global per-interface Intended Load usable for a Trial.
ロードは、トライアルに使用できるグローバルなインターフェイスごとの意図されたロードです。
Discussion:
議論：
For specification purposes, Load is also assumed to be Constant Load.
仕様の目的上、Load も Constant Load であると想定されます。
Similarly to existing definitions, this quantity is related to one (input or output) SUT interface.
既存の定義と同様に、この量は 1 つの (入力または出力) SUT インターフェイスに関連付けられます。
In the common case of bidirectional traffic, as described in "Bidirectional traffic" (Section 14 of [RFC2544]), Load is the "data rate" per each direction, half of the "sum of data rates".
「双方向トラフィック」([RFC2544] のセクション 14) で説明されているように、双方向トラフィックの一般的なケースでは、負荷は各方向ごとの「データ レート」であり、「データ レートの合計」の半分です。
The Test Report MAY present the _aggregate Load_ across multiple interfaces, treating it as the same magnitude expressed using different units. Each reported Load MUST unambiguously state whether it refers to (i) a single interface, (ii) a specified subset of interfaces (such as all logical interfaces mapped to one physical port), or (iii) the total across every interface. For any aggregate Load value, the report MUST also give the fixed conversion factor that links the per-interface and multi-interface Load values.
テスト レポートは、複数のインターフェイスにわたる_集計負荷_を、異なる単位を使用して表現された同じ大きさとして扱って提示してもよい(MAY)。報告される各負荷は、それが (i) 単一のインターフェースを指すのか、(ii) インターフェースの指定されたサブセット (1 つの物理ポートにマッピングされたすべての論理インターフェースなど) を指すのか、(iii) すべてのインターフェースにわたる合計を指すのかを明確に述べなければなりません (MUST)。集計負荷値について、レポートには、インターフェイスごとの負荷値と複数インターフェイスの負荷値をリンクする固定変換係数も提供しなければなりません。
The per-interface Load remains the primary unit, consistent with the prevailing practice described in [RFC1242], [RFC2544], and [RFC2285].
[RFC1242]、[RFC2544]、および [RFC2285] で説明されている一般的な慣行と一致して、インターフェイスごとの負荷は依然として主要な単位です。
The previous paragraph also applies to other terms related to Load. For example, tests with symmetric bidirectional traffic MAY report Load-related values as "bidirectional load" (double of "unidirectional load" if that is distinguished in the same Test Report).
前の段落は、ロードに関連する他の条件にも適用されます。たとえば、対称双方向トラフィックを使用するテストでは、負荷関連の値を「双方向負荷」(同じテスト レポート内で区別されている場合は「単方向負荷」の 2 倍)として報告してもよい(MAY)。
Besides Trial Load, the Relevant Lower Bound will be another example of a newly defined quantity based on Load.
試行負荷の他に、関連下限も負荷に基づいて新しく定義された数量の例になります。
Similar to Load as a main quantity acting as an input for a Trial, Forwarding Rate is an existing quantity describing an output from a Trial.
トライアルの入力として機能する主要な量としてのロードと同様に、転送レートはトライアルからの出力を記述する既存の量です。
Besides Trial Forwarding Rate, the Conditional Throughput will be another example of a newly defined quantity based on Forwarding Rate.
トライアル転送レートの他に、条件付きスループットも、転送レートに基づいて新たに定義された数量の例になります。
Defined in "Forwarding rate (FR)" (Section 3.6.1 of [RFC2285]).
「転送レート (FR)」([RFC2285] のセクション 3.6.1) で定義されています。
Defined in "Throughput" (Section 3.17 of [RFC1242]).
「スループット」([RFC1242] のセクション 3.17) で定義されています。
The methodology of measuring Throughput is codified in "Throughput" (Section 26.1 of [RFC2544]).
スループットの測定方法は、「スループット」([RFC2544] のセクション 26.1) で成文化されています。
This document frequently uses the phrase _[RFC2544] Throughput_ when referring not only to the Throughput quantity itself, but also to the methodology requirements for benchmarking it.
この文書では、スループット量そのものだけでなく、それをベンチマークする方法論の要件についても言及するときに、「[RFC2544] スループット」というフレーズを頻繁に使用します。
This section defines new terms and redefines existing terms for quantities relevant as inputs or outputs of a Trial, as handled by the Measurer component. This also includes any derived quantities related to results of one Trial.
このセクションでは、Measurer コンポーネントによって処理される、トライアルの入力または出力として関連する数量に関する新しい用語を定義し、既存の用語を再定義します。これには、1 つの試験の結果に関連する派生数量も含まれます。
Definition:
意味：
Trial Duration is the intended duration of phase c) of a Trial.
トライアル期間は、トライアルのフェーズ c) の予定期間です。
Discussion:
議論：
The value MUST be positive.
値は正の値でなければなりません。
While any positive real value may be provided, some Measurer implementations MAY limit possible values, e.g., by rounding down to the nearest integer in seconds. In that case, it is RECOMMENDED to give such inputs to the Controller so that the Controller implementation only generates the accepted values.
任意の正の実数値を指定できますが、一部の Measurer 実装では、秒単位で最も近い整数に切り捨てるなど、可能な値を制限してもよい(MAY)。その場合、コントローラの実装が受け入れられた値のみを生成するように、そのような入力をコントローラに与えることが推奨されます。
Definition:
意味：
Trial Load is the Load used in a specific Trial.
トライアルロードは、特定のトライアルで使用されるロードです。
Discussion:
議論：
This is a Load-related quantity that is tied to a single Trial, to distinguish it from later derived quantities that are not tied that way.
これは、単一のトライアルに関連付けられた負荷関連の数量であり、そのように関連付けられていない後から導出される数量と区別されます。
For specification purposes, it is assumed that this is a Constant Load by default. Informally, Trial Load is a single number that can "scale" any traffic pattern as long as the intuition of a load intended against a single interface can be applied.
仕様の目的上、これはデフォルトで定荷重であると想定されます。非公式には、トライアル ロードは、単一のインターフェイスに対する負荷の直感が適用できる限り、あらゆるトラフィック パターンを「スケール」できる単一の数値です。
It MAY be possible to use a Trial Load to describe non-constant traffic (using average load when the traffic consists of repeated bursts of frames, e.g., as suggested in Section 21 of [RFC2544]). In the case of a non-constant load, the Test Report MUST explicitly mention exactly how non-constant the traffic is and how it reacts to the Trial Load value. But the rest of the MLRsearch Specification assumes that is not the case, to avoid discussing corner cases (e.g., which values are possible within medium limitations).
非定常トラフィックを記述するためにトライアルロードを使用することは可能であってもよい(MAY) (例えば、[RFC2544] のセクション 21 で提案されているように、トラフィックがフレームの繰り返しバーストで構成されている場合は平均負荷を使用)。非定常負荷の場合、テストレポートは、トラフィックがどの程度非定常であるか、および試行負荷値にどのように反応するかを正確に明示的に言及しなければなりません。しかし、MLRsearch 仕様の残りの部分では、例外的なケース (たとえば、中程度の制限内でどの値が可能か) についての議論を避けるために、そうではないことを前提としています。
Similarly, traffic patterns where different interfaces are subject to different loads MAY be described by a single Trial Load value (e.g., using the largest Intended Load among interfaces), but again, the Test Report MUST explicitly describe how the traffic pattern reacts to the Trial Load value, and this specification does not discuss all the implications of that approach.
同様に、異なるインターフェースが異なる負荷にさらされるトラフィック パターンは、単一の試行負荷値で記述されてもよい (例、インターフェース間で最大の意図負荷を使用するなど)。しかし、やはり、テスト レポートは、トラフィック パターンが試行負荷値にどのように反応するかを明示的に記述しなければならず、この仕様は、そのアプローチのすべての影響について議論しているわけではありません。
Traffic patterns where a single Trial Load does not describe their scaling cannot be used for MLRsearch benchmarks.
単一のトライアル ロードでスケーリングが説明されないトラフィック パターンは、MLRsearch ベンチマークに使用できません。
Similarly to Trial Duration, some Measurers MAY limit the possible values of Trial Load. Contrary to Trial Duration, documenting such behavior in the Test Report is OPTIONAL. This is because the load differences are negligible (and frequently undocumented) in practice.
トライアル期間と同様に、一部の測定者はトライアル ロードの可能な値を制限してもよい(MAY)。試用期間とは対照的に、そのような動作をテストレポートに文書化することはオプションです。これは、実際には負荷の違いが無視できる（そして文書化されていないことが多い）ためです。
The Controller MAY select the Trial Load and Trial Duration values in a way that would not be possible to achieve using any integer number of data frames.
コントローラーは、任意の整数のデータ フレームを使用しては達成できない方法で、トライアル ロードとトライアル期間の値を選択してもよい(MAY)。
Given that the Trial Load is a quantity based on Load, Test Report MAY express this quantity using multi-interface values, as the sum of Intended Loads over input interfaces.
試行負荷が負荷に基づいた量であることを考慮すると、テスト レポートは、入力インターフェイス上の意図された負荷の合計として、マルチインターフェイス値を使用してこの量を表現してもよい(MAY)。
Definition:
意味：
Trial Input is a composite quantity, consisting of exactly two attributes: Trial Duration and Trial Load.
トライアル入力は複合量であり、トライアル期間とトライアル ロードという 2 つの属性で構成されます。
Discussion:
議論：
When talking about a set of Trials, it is common to say _Trial Inputs_ to denote all corresponding Trial Input instances.
一連のトライアルについて話すときは、対応するすべてのトライアル入力インスタンスを表すために「トライアル入力」と言うのが一般的です。
One Trial Input instance acts as the input for one call of the Measurer component.
1 つの Trial Input インスタンスは、Measurer コンポーネントの 1 回の呼び出しの入力として機能します。
Contrary to other composite quantities, MLRsearch implementations MUST NOT add optional attributes into Trial Input. This improves interoperability between various implementations of a Controller and a Measurer.
他の複合量とは異なり、MLRsearch 実装ではトライアル入力にオプションの属性を追加してはなりません (MUST NOT)。これにより、コントローラーと測定器のさまざまな実装間の相互運用性が向上します。
Note that both attributes are _intended_ quantities, as only those can be fully controlled by the Controller. The actual _offered_ quantities, as realized by the Measurer, can be different (and must be different if not multiplying into an integer number of frames), but questions around those offered quantities are generally outside of the scope of this document.
コントローラーによって完全に制御できるのはこれらの属性のみであるため、両方の属性は_intended_数量であることに注意してください。測定者によって実現される実際の提供量は異なる場合があります (整数のフレームに乗算しない場合は異なる必要があります) が、これらの提供量に関する質問は通常、このドキュメントの範囲外です。
Definition:
意味：
Traffic Profile is a composite quantity containing all attributes other than Trial Load and Trial Duration that are needed for the unique determination of the Trial to be performed.
トラフィック プロファイルは、実行されるトライアルを一意に決定するために必要な、トライアル ロードとトライアル期間以外のすべての属性を含む複合量です。
Discussion:
議論：
All the attributes MUST be constant during the Search, and the composite is conceptually configured on the Measurer by the Manager before the Search starts. This is why the Traffic Profile is not part of the Trial Input.
すべての属性は検索中に一定である必要があり、コンポジットは概念的には検索の開始前にマネージャーによって測定者上に設定されます。これが、トラフィック プロファイルがトライアル入力の一部ではない理由です。
Specification of traffic properties included in the Traffic Profile is the responsibility of the Manager, but the specific configuration mechanisms are outside of the scope of this document. Implementations are allowed to include this data in Controller calls to the Measurer, as long as its impact is functionally constant.
トラフィック プロファイルに含まれるトラフィック プロパティの仕様はマネージャーの責任ですが、特定の構成メカニズムはこのドキュメントの範囲外です。実装では、その影響が機能的に一定である限り、コントローラーの Measurer 呼び出しにこのデータを含めることができます。
Implementations of the Manager and the Measurer should be aware of their common set of capabilities well enough to ensure that the Traffic Profile instance uniquely defines the traffic during the Search. Typically, Manager and Measurer implementations are tightly integrated.
Manager と Measurer の実装は、トラフィック プロファイル インスタンスが検索中にトラフィックを一意に定義できるように、共通の機能セットを十分に認識している必要があります。通常、Manager と Measurer の実装は緊密に統合されています。
Integration efforts between independent Manager and Measurer implementations are outside of the scope of this document. An example standardization effort is described in [Vassilev].
独立した Manager 実装と Measurer 実装間の統合作業については、このドキュメントの範囲外です。標準化の取り組みの例は、[Vassilev] で説明されています。
Examples of common traffic properties include:
一般的なトラフィック プロパティの例は次のとおりです。
* Data link frame size:
* データリンクフレームサイズ：
- Fixed sizes as listed in Section 3.5 of [RFC1242] and in Section 9 of [RFC2544]
- [RFC1242] のセクション 3.5 および [RFC2544] のセクション 9 にリストされている固定サイズ
- "Internet Mix" (IMIX) mixed frame sizes as defined in [RFC6985]
- [RFC6985] で定義されている「Internet Mix」(IMIX) 混合フレーム サイズ
* Frame formats and protocol addresses:
* フレームフォーマットとプロトコルアドレス:
- Sections 8 and 12 of [RFC2544] and Appendix C of [RFC2544]
- [RFC2544] のセクション 8 および 12、および [RFC2544] の付録 C
Other traffic properties that need to somehow be specified in Traffic Profile, and MUST be mentioned in Test Report if they apply to the benchmark, include:
トラフィック プロファイルで何らかの方法で指定する必要があり、ベンチマークに適用される場合はテスト レポートで言及する必要があるその他のトラフィック プロパティには、次のものがあります。
* symmetric bidirectional traffic from Section 14 of [RFC2544],
* [RFC2544] のセクション 14 による対称双方向トラフィック、
* fully meshed traffic from Section 3.3.3 of [RFC2285],
* [RFC2285] のセクション 3.3.3 の完全メッシュトラフィック、
* modifiers from Section 11 of [RFC2544], and
* [RFC2544] のセクション 11 の修飾子、および
* IP version mixing from Section 5.3 of [RFC8219].
* [RFC8219] のセクション 5.3 からの IP バージョン混合。
Definition:
意味：
The Trial Forwarding Ratio is a dimensionless floating point quantity. Its value MUST range between 0.0 and 1.0, both inclusive. It is computed by dividing the number of frames successfully forwarded by the SUT by the total number of frames expected to be forwarded during the Trial.
トライアル転送率は、無次元の浮動小数点数値です。その値は 0.0 ～ 1.0 の範囲でなければなりません (両方の値を含む)。これは、SUT によって正常に転送されたフレーム数を、トライアル中に転送されると予想されるフレームの総数で割ることによって計算されます。
Discussion:
議論：
For most Traffic Profiles, "expected to be forwarded" means "intended to get received by a SUT from the tester". This SHOULD be the default interpretation. However, if this is not the case, the Test Report MUST describe the Traffic Profile in sufficient enough detail to imply how the Trial Forwarding Ratio should be computed.
ほとんどのトラフィック プロファイルでは、「転送されることが期待される」とは、「テスターから SUT によって受信されることが意図される」ことを意味します。これがデフォルトの解釈であるべきです。ただし、これに当てはまらない場合、テスト レポートには、トライアル転送率の計算方法を示唆するのに十分なほど詳細にトラフィック プロファイルを記述しなければなりません。
The Trial Forwarding Ratio MAY be expressed in other units (e.g., as a percentage) in the Test Report.
トライアル転送率は、テストレポート内で他の単位（パーセントなど）で表現されてもよい（MAY）。
Note that, contrary to Load terms, frame counts used to compute the Trial Forwarding Ratio are generally aggregates over all SUT output interfaces, as most test procedures verify all outgoing frames. The procedure for [RFC2544] Throughput counts received frames, so it implies bidirectional counts for bidirectional traffic, even though the final value is the "rate" that is still per-interface. For example, in a test with symmetric bidirectional traffic, if one direction is forwarded without any losses, but the opposite direction does not forward at all, the Trial Forwarding Ratio would be 0.5 (50%).
ロード条件とは反対に、ほとんどのテスト手順ではすべての送信フレームが検証されるため、トライアル転送率の計算に使用されるフレーム カウントは通常、すべての SUT 出力インターフェイスの合計であることに注意してください。[RFC2544] スループットの手順では受信フレームをカウントするため、最終的な値はインターフェイスごとの「レート」であっても、双方向トラフィックの双方向カウントを意味します。たとえば、対称双方向トラフィックのテストで、一方の方向は損失なく転送されるが、反対方向はまったく転送されない場合、トライアル転送率は 0.5 (50%) になります。
In future extensions, more general ways to compute the Trial Forwarding Ratio may be allowed, but the current MLRsearch Specification relies on this specific averaged counters approach.
将来の拡張では、トライアル転送率を計算するためのより一般的な方法が許可される可能性がありますが、現在の MLRsearch 仕様は、この特定の平均カウンタ アプローチに依存しています。
Definition:
意味：
The Trial Loss Ratio is equal to one minus the Trial Forwarding Ratio.
トライアル損失率は、1 からトライアル転送率を引いたものと等しくなります。
Discussion:
議論：
When expressing ratio values as percentages, the Trial Loss Ratio is equal to 100% minus the Trial Forwarding Ratio.
比率値をパーセンテージで表す場合、トライアル損失率は 100% からトライアル転送率を引いたものとなります。
This is almost identical to Frame Loss Rate in Section 3.6 of [RFC1242]. The only minor differences are that Trial Loss Ratio does not need to be expressed as a percentage, and Trial Loss Ratio is explicitly based on averaged frame counts when more than one traffic direction is present.
これは、[RFC1242] のセクション 3.6 のフレーム損失率とほぼ同じです。唯一の小さな違いは、トライアル ロス率をパーセンテージで表す必要がないことと、複数のトラフィック方向が存在する場合、トライアル ロス率は平均フレーム カウントに明示的に基づくことです。
Definition:
意味：
The Trial Forwarding Rate is a derived quantity, computed by multiplying the Trial Load by the Trial Forwarding Ratio.
トライアル転送率は、トライアル負荷にトライアル転送率を乗算して計算される導出数量です。
Discussion:
議論：
Despite the similar name, this quantity differs substantially from Forwarding Rate.
名前は似ていますが、この量は転送レートとは大きく異なります。
Under the method described in [RFC2285], each output interface is measured separately, so every interface may report a different Forwarding Rate. The Trial Forwarding Rate, by contrast, uses a single set of frame counts and therefore yields one value that represents the whole system while still preserving the direct relation to the per-interface Load.
[RFC2285] で説明されている方法では、各出力インターフェイスが個別に測定されるため、すべてのインターフェイスが異なる転送レートを報告する可能性があります。対照的に、トライアル転送レートは単一セットのフレーム カウントを使用するため、インターフェイスごとの負荷との直接の関係を維持しながら、システム全体を表す 1 つの値が得られます。
When the Traffic Profile is symmetric and bidirectional, as defined in Section 14 of [RFC2544], the Trial Forwarding Rate is numerically equal to the arithmetic average of the individual per-interface Forwarding Rates.
[RFC2544] のセクション 14 で定義されているように、トラフィック プロファイルが対称かつ双方向である場合、トライアル転送レートは、数値的にはインターフェイスごとの個別の転送レートの算術平均に等しくなります。
For more complex traffic patterns, such as many-to-one, as mentioned in "Partially meshed traffic" (Section 3.3.2 of [RFC2285]), the meaning of Trial Forwarding Rate is less straightforward. For example, if two input interfaces receive one million frames per second (fps) each, and a single interface outputs 1.4 million fps, the Trial Load is 1 million fps, the Trial Loss Ratio is 30%, and the Trial Forwarding Rate is 0.7 million fps.
「部分的にメッシュ化されたトラフィック」([RFC2285] のセクション 3.3.2) で説明されているように、多対 1 などのより複雑なトラフィック パターンの場合、トライアル転送レートの意味はそれほど単純ではありません。たとえば、2 つの入力インターフェイスがそれぞれ 100 万 fps (フレーム/秒) を受信し、1 つのインターフェイスが 140 万 fps を出力する場合、試行ロードは 100 万 fps、試行損失率は 30%、試行転送レートは 070 万 fps になります。
Because Trial Forwarding Rate is anchored to the Load defined for one interface, a Test Report MAY show it either as the single averaged figure just described or as the sum of the separate per-interface Forwarding Rates. For the example above, the _aggregate_ Trial Forwarding Rate is 1.4 million fps.
トライアル転送レートは 1 つのインターフェイスに対して定義された負荷に固定されているため、テスト レポートでは、先ほど説明した単一の平均値として、またはインターフェイスごとの個別の転送レートの合計として表示できます (MAY)。上の例では、_aggregate_ Trial Forwarding Rate は 140 万 fps です。
Definition:
意味：
The Trial Effective Duration is a time quantity related to a Trial. By default, it is equal to the Trial Duration.
トライアルの有効期間は、トライアルに関連する時間量です。デフォルトでは、これは試用期間と同じです。
Discussion:
議論：
This is an OPTIONAL feature. If the Measurer does not return any Trial Effective Duration value, the Controller MUST use the Trial Duration value from its Trial Input instead.
これはオプションの機能です。測定者が試用有効期間値を返さない場合、コントローラーは代わりに試用入力からの試用期間値を使用しなければなりません(MUST)。
The Trial Effective Duration MAY be any positive time quantity chosen by the Measurer to be used for time-based decisions in the Controller.
トライアルの有効期間は、コントローラーでの時間ベースの決定に使用するために測定者によって選択された任意の正の時間量であってもよい (MAY)。
The Test Report MUST explain how the Measurer computes the returned Trial Effective Duration values if they are not always equal to the Trial Duration.
テストレポートでは、返されたトライアル有効期間の値が必ずしもトライアル期間と等しくない場合に、測定者がその値をどのように計算するかを説明しなければなりません。
This feature can be beneficial for time-critical benchmarks designed to manage the overall Search Duration, rather than solely the traffic portion of it. An approach is to measure the duration of the whole Trial (including all wait times) and use that as the Trial Effective Duration.
この機能は、検索期間のトラフィック部分だけではなく、検索期間全体を管理するように設計されたタイムクリティカルなベンチマークにとって有益です。アプローチとしては、トライアル全体の期間 (すべての待機時間を含む) を測定し、それをトライアルの有効期間として使用することです。
This is also a way for the Measurer to inform the Controller about its surprising behavior, for example, when rounding the Trial Duration value.
これは、測定者が、たとえば試用期間の値を四捨五入するときなど、その予期せぬ動作についてコントローラーに通知する方法でもあります。
Definition:
意味：
Trial Output is a composite quantity consisting of several attributes. The REQUIRED attributes are Trial Loss Ratio, Trial Effective Duration, and Trial Forwarding Rate.
トライアル出力は、いくつかの属性で構成される複合量です。必須の属性は、トライアル損失率、トライアルの有効期間、およびトライアル転送率です。
Discussion:
議論：
When referring to more than one Trial, the plural term _Trial Outputs_ is used to collectively describe multiple Trial Output instances.
複数のトライアルを指す場合、複数のトライアル出力インスタンスを総称して「トライアル出力」という複数の用語が使用されます。
Measurer implementations MAY provide additional attributes. The Controller implementations SHOULD ignore any such optional attribute they are not familiar with. If a Controller implementation passes selected Trial Outputs to the Manager, the instances SHOULD contain all such additional attributes.
メジャーの実装は追加の属性を提供してもよい(MAY)。コントローラの実装は、馴染みのないオプションの属性を無視する必要があります (SHOULD)。コントローラー実装が選択されたトライアル出力をマネージャーに渡す場合、インスタンスにはそのような追加属性がすべて含まれている必要があります (SHOULD)。
An example of an optional attribute is the aggregate count of frames expected to be forwarded during the Trial, especially if it is not (a rounded-down value) implied by Trial Load and Trial Duration.
オプションの属性の例は、トライアル中に転送されると予想されるフレームの総数です。特に、トライアル ロードおよびトライアル期間によって暗示されていない (切り捨てられた値) 場合に当てはまります。
While Section 3.5.2 of [RFC2285] requires the Offered Load to be reported for Forwarding Rate measurements, it is not required in the MLRsearch Specification, as Search Results do not depend on it, and technically the Measurer is not performing a direct Forwarding Rate measurement.
[RFC2285] のセクション 3.5.2 では、転送レート測定のために提供負荷を報告する必要がありますが、検索結果はそれに依存せず、技術的には測定者が直接転送レート測定を実行しないため、MLRsearch 仕様では必須ではありません。
Definition:
意味：
Trial Result is a composite quantity, consisting of the Trial Input and the Trial Output as REQUIRED attributes.
試行結果は複合数量であり、必須属性として試行入力と試行出力で構成されます。
Discussion:
議論：
When referring to more than one Trial, the plural term _Trial Results_ is used to collectively describe multiple Trial Result instances.
複数のトライアルを指す場合、複数のトライアル結果インスタンスを総称して「トライアル結果」という複数の用語が使用されます。
This section defines new terms for quantities relevant (directly or indirectly) for inputs and outputs of the Controller component.
このセクションでは、コントローラー コンポーネントの入力と出力に (直接的または間接的に) 関連する量に関する新しい用語を定義します。
Several goal attributes are defined before introducing the main composite quantity: the _Search Goal_.
主要な複合量である _Search Goal_ を導入する前に、いくつかの目標属性が定義されます。
Contrary to other sections, definitions in subsections of this section are necessarily vague, as their fundamental meaning is to act as coefficients in formulas for Controller Output attributes, which are not defined yet.
他のセクションとは対照的に、このセクションのサブセクションの定義は必然的にあいまいになります。その基本的な意味は、まだ定義されていないコントローラー出力属性の式の係数として機能することであるためです。
The discussions in this section relate the attributes to concepts mentioned in "Overview of RFC 2544 Problems" (Section 2), but these discussion paragraphs are short and informal, and they mostly reference later sections, where the impact on Search Results is discussed after introducing the complete set of Auxiliary Terms.
このセクションの議論は、属性を「RFC 2544 問題の概要」(セクション 2) で言及されている概念に関連付けますが、これらの議論の段落は短く非公式であり、ほとんどは後のセクションを参照しており、補助用語の完全なセットを紹介した後で検索結果への影響が議論されています。
Definition:
意味：
This is the minimal value for Trial Duration that should be reached. The value MUST be positive.
これは、到達すべき試用期間の最小値です。値は正の値でなければなりません。
Discussion:
議論：
Certain Trials must reach this minimum Trial Duration before a Load can be classified as a Lower Bound.
ロードを下限として分類するには、特定のトライアルがこの最小トライアル期間に達する必要があります。
The Controller MAY choose shorter Trial Durations, and those Trial Results can be enough for classification as an Upper Bound.
管理者はより短いトライアル期間を選択してもよく、それらのトライアル結果は上限として分類するのに十分である可能性があります。
If such shorter Trials prove no Lower Bound exists, this Trial Duration value may never be reached, thus shortening Search Duration.
このような短いトライアルで下限が存在しないことが判明した場合、このトライアル期間の値に決して到達しない可能性があるため、検索期間が短縮されます。
It is RECOMMENDED for all Search Goals to share the same Goal Final Trial Duration value. Otherwise, Trial Durations larger than the Goal Final Trial Duration may occur, weakening the assumptions the "Load Classification Logic" (Section 6.1) is based on.
すべての検索目標で同じ目標の最終トライアル期間の値を共有することが推奨されます。そうしないと、目標の最終トライアル期間を超えるトライアル期間が発生し、「負荷分類ロジック」(セクション 6.1) の基礎となる前提が弱くなる可能性があります。
Note that this is a soft limitation for the Trial Duration values selected by the Controller. The Measurer may keep returning different Effective Trial Durations in Trial Results, so Controller implementations MUST be ready to handle such situations.
これは、コントローラーによって選択された試用期間の値に対するソフト制限であることに注意してください。測定者はトライアル結果で異なる有効トライアル期間を返し続ける可能性があるため、コントローラーの実装はそのような状況に対応できるようにしておく必要があります。
Definition:
意味：
This is a threshold value for a particular sum of Trial Effective Duration values. The value MUST be positive.
これは、トライアルの有効期間値の特定の合計に対するしきい値です。値は正の値でなければなりません。
Discussion:
議論：
Informally, this prescribes the sufficient number of Trials performed at a specific Trial Load and Goal Final Trial Duration during the Search.
非公式には、これは、検索中に特定のトライアル ロードおよび目標の最終トライアル期間で実行される十分なトライアル数を規定します。
If the Goal Duration Sum is larger than the Goal Final Trial Duration, multiple Trials may be needed to be performed at the same Load.
目標期間の合計が目標の最終トライアル期間より大きい場合、同じ負荷で複数のトライアルを実行する必要がある場合があります。
Refer to "MLRsearch Compliant with TST009" (Section 4.10.3) for an example where the possibility of multiple Trials at the same Load is intended.
同じ負荷での複数のトライアルの可能性が意図されている例については、「TST009 に準拠した MLRsearch」(セクション 4.10.3) を参照してください。
A Goal Duration Sum shorter than the Goal Final Trial Duration (of the same Search Goal) could reduce Search time but is NOT RECOMMENDED, as the time savings come at the cost of decreased repeatability.
(同じ検索目標の) 目標の最終トライアル期間よりも短い目標期間の合計は検索時間を短縮できますが、時間の節約には再現性の低下が伴うため、推奨されません。
In practice, the Search can spend less than the Goal Duration Sum measuring a Load when the Trial Results are particularly one-sided, but also, the Search can spend more than the Goal Duration Sum measuring a Load when the Trial Results are balanced and include Trials shorter than the Goal Final Trial Duration.
実際には、トライアル結果が特に一方的である場合、検索は負荷の測定に目標期間の合計よりも少ない時間を費やすことができますが、トライアル結果のバランスが取れており、目標の最終トライアル期間よりも短いトライアルが含まれている場合、検索は負荷の測定に目標期間の合計より多く費やすこともあります。
Definition:
意味：
This is a threshold value for Trial Loss Ratio values. The value MUST be non-negative and smaller than one.
これは試行損失率値のしきい値です。値は負ではなく、1 より小さくなければなりません。
Discussion:
議論：
A Trial with the Trial Loss Ratio larger than this value signals the SUT may be unable to process this Load well enough.
トライアル損失率がこの値より大きいトライアルは、SUT がこのロードを十分に処理できない可能性があることを示します。
See "Throughput with Non-Zero Loss" (Section 2.5) for reasons why users may want to set this value above zero.
ユーザーがこの値をゼロより大きく設定する理由については、「損失がゼロでないスループット」 (セクション 2.5) を参照してください。
Since multiple Trials might be needed for one Load, the Load Classification might be more complicated than the mere comparison of one Trial Loss Ratio to the Goal Loss Ratio.
1 つの負荷に対して複数のトライアルが必要になる場合があるため、負荷の分類は、1 つのトライアル損失率と目標損失率の単なる比較よりも複雑になる可能性があります。
Definition:
意味：
This is a threshold value for a particular ratio of sums of Trial Effective Durations. The value MUST be non-negative and smaller than one.
これは、トライアルの有効期間の合計の特定の比率のしきい値です。値は負ではなく、1 より小さくなければなりません。
Discussion:
議論：
Informally, this controls the ratio of Trial Results exceeding Goal Loss Ratio. More specifically, up to this proportion of the Trial Results with the Trial Loss Ratio above the Goal Loss Ratio is tolerated at a Lower Bound. This is the full impact if every Trial is measured at Goal Final Trial Duration. The actual full logic is more complicated, as shorter Trials are allowed.
非公式には、これは目標損失率を超えるトライアル結果の比率を制御します。より具体的には、目標損失率を超える試行損失率を伴う試行結果のこの割合までは、下限で許容されます。これは、すべてのトライアルが目標の最終トライアル期間で測定された場合の最大の影響です。短いトライアルが許可されるため、実際の完全なロジックはより複雑になります。
For explainability reasons, the RECOMMENDED value for the Goal Exceed Ratio is 0.5 (50%), and in practice that also leads to the smallest variation in overall Search Duration.
説明しやすくするため、目標超過率の推奨値は 0.5 (50%) であり、実際にはこれが全体の検索期間の変動を最小にすることにもつながります。
Refer to "Exceed Ratio and Multiple Trials" (Section 5.4) for more details.
詳細については、「超過率と複数の試行」 (セクション 5.4) を参照してください。
Definition:
意味：
This is a threshold value for deciding whether two Load values are close enough. This is an OPTIONAL attribute. If present, the value MUST be positive.
これは、2 つの Load 値が十分に近いかどうかを判断するためのしきい値です。これはオプションの属性です。存在する場合、値は正の値でなければなりません。
Discussion:
議論：
Informally, this acts as a stopping condition, controlling the precision of the Goal Result. The Search stops if every Search Goal has reached its precision.
非公式には、これは停止条件として機能し、目標結果の精度を制御します。すべての検索目標がその精度に達すると、検索は停止します。
Implementations without this attribute MUST provide the Controller with other means to control the Search _stopping conditions_.
この属性を持たない実装では、検索の_停止条件_を制御するための他の手段をコントローラーに提供しなければなりません(MUST)。
_Absolute Load difference_ (in fps) and _relative Load difference_ (in percents) are two popular choices, but implementations MAY choose different ways to specify Goal Width.
_絶対負荷差_ (fps 単位) と _相対負荷差_ (パーセント単位) の 2 つは一般的な選択肢ですが、実装ではゴール幅を指定するために異なる方法を選択してもよい(MAY)。
The Test Report MUST make it clear what specific quantity is used as the Goal Width.
テストレポートでは、目標幅としてどのような特定の量が使用されるかを明確にしなければなりません。
It is RECOMMENDED to express the Goal Width as a relative difference and set it to a value not lower than the Goal Loss Ratio. Refer to "Performance Variability" (Section 5.6.2) for more elaboration on the reasoning.
ゴール幅を相対的な差として表現し、ゴール損失率以上の値に設定することが推奨されます。推論の詳細については、「パフォーマンスの変動」(セクション 5.6.2) を参照してください。
Definition:
意味：
This is the minimal value for the Trial Duration suggested to be used for this goal. This is an OPTIONAL attribute. If present, this value MUST be positive.
これは、この目標に使用することが提案されている試用期間の最小値です。これはオプションの属性です。存在する場合、この値は正の値でなければなりません。
Discussion:
議論：
This is an example of an optional Search Goal attribute.
これは、オプションの検索目標属性の例です。
A typical default value is equal to the Goal Final Trial Duration value.
一般的なデフォルト値は、目標の最終トライアル期間の値と同じです。
Informally, this is the shortest Trial Duration the Controller should select when focusing on this Search Goal.
非公式には、これは、この検索目標に焦点を当てるときにコントローラーが選択する必要がある最短のトライアル期間です。
Note that shorter Trial Durations might still be selected by the Controller, for example, when focusing on a different Search Goal.
たとえば、別の検索目標に焦点を当てている場合など、コントローラーによってより短いトライアル期間が選択される可能性があることに注意してください。
The Goal Initial Trial Duration is a mechanism for a user to discourage Trials with Trial Durations deemed as too small to be reliable for a particular SUT and a given Search Goal.
目標の初期トライアル期間は、特定の SUT および特定の検索目標に対して信頼するには短すぎるとみなされるトライアル期間でのトライアルをユーザーが阻止するためのメカニズムです。
As with Goal Final Trial Duration, the Controller implementation MUST be able to handle possibly lower Effective Trial Duration values returned by the Measurer.
目標の最終試用期間と同様に、コントローラーの実装は、測定者によって返される可能性のあるより低い有効試用期間の値を処理できなければなりません。
Definition:
意味：
The Search Goal is a composite quantity consisting of several attributes, some of which are required.
検索目標は、いくつかの属性で構成される複合量であり、その一部は必須です。
The REQUIRED attributes are Goal Final Trial Duration, Goal Duration Sum, Goal Loss Ratio, and Goal Exceed Ratio.
必須の属性は、目標最終トライアル期間、目標期間合計、目標損失率、および目標超過率です。
Discussion:
議論：
Typical optional attributes are Goal Initial Trial Duration and Goal Width.
一般的なオプション属性は、「目標の初期トライアル期間」と「目標の幅」です。
Implementations MAY add their own attributes. Those additional attributes may be required by an implementation even if they are not required by the MLRsearch Specification. However, it is RECOMMENDED for those implementations to support missing attributes by providing typical default values.
実装は独自の属性を追加してもよい(MAY)。これらの追加属性は、MLRsearch 仕様で必須ではない場合でも、実装で必要になる場合があります。ただし、これらの実装では、典型的なデフォルト値を提供することで欠落している属性をサポートすることが推奨されます。
For example, implementations with Goal Initial Trial Durations might also require users to specify "how quickly" Trial Durations should increase.
たとえば、目標の初期試用期間を設定した実装では、ユーザーが試用期間を「どのくらいの速さで」増加させるかを指定する必要がある場合もあります。
Refer to "Compliance" (Section 4.10) for important Search Goals.
重要な検索目標については、「コンプライアンス」(セクション 4.10) を参照してください。
Definition:
意味：
Controller Input is a composite quantity required as an input for the Controller. The only REQUIRED attribute is a list of Search Goals.
コントローラー入力は、コントローラーの入力として必要な複合量です。唯一の必須属性は、検索目標のリストです。
Discussion:
議論：
MLRsearch implementations MAY use additional attributes. Those additional attributes may be required by an implementation even if they are not required by the MLRsearch Specification.
MLRsearch 実装は追加の属性を使用してもよい (MAY)。これらの追加属性は、MLRsearch 仕様で必須ではない場合でも、実装で必要になる場合があります。
Formally, the Manager does not apply any Controller configuration apart from one Controller Input instance.
正式には、マネージャーは 1 つのコントローラー入力インスタンスを除いてコントローラー構成を適用しません。
For example, Traffic Profile is conceptually configured on the Measurer by the Manager, without explicit assistance of the Controller.
たとえば、トラフィック プロファイルは、概念的には、コントローラの明示的な支援なしに、マネージャによって測定器上に構成されます。
The order of Search Goals in a list SHOULD NOT have a big impact on Controller Output, but MLRsearch implementations MAY base their behavior on the order of Search Goals in a list.
リスト内の検索目標の順序はコントローラーの出力に大きな影響を与えるべきではありませんが、MLRsearch 実装はリスト内の検索目標の順序に基づいて動作を行ってもよい(MAY)。
Definition:
意味：
Max Load is an OPTIONAL attribute of Controller Input. It is the maximal value the Controller is allowed to select for Trial Loads.
最大負荷は、コントローラー入力のオプションの属性です。これは、コントローラが試行ロード用に選択できる最大値です。
Discussion:
議論：
Max Load is an example of an optional attribute (outside the list of Search Goals) required by some implementations of MLRsearch.
Max Load は、MLRsearch の一部の実装で必要なオプションの属性 (検索目標のリスト外) の例です。
If the Max Load is provided, the Controller MUST NOT select Trial Loads larger than that value.
最大負荷が指定されている場合、コントローラはその値を超える試行負荷を選択してはなりません。
In theory, each Search Goal could have its own Max Load, but as all Trial Results are possibly affecting all Search Goals, it makes more sense for a single Max Load to apply to all Search Goals.
理論的には、各検索目標に独自の最大負荷を設定できますが、すべてのトライアル結果がすべての検索目標に影響を与える可能性があるため、単一の最大負荷をすべての検索目標に適用する方が合理的です。
While Max Load is a frequently used configuration parameter, already governed (as Maximum Frame Rate) by Section 20 of [RFC2544] and (as Maximum Offered Load) by Section 3.5.3 of [RFC2285], some implementations MAY detect or discover it, instead of requiring a user-supplied value.
Max Load は頻繁に使用される設定パラメータであり、(最大フレーム レートとして) [RFC2544] のセクション 20 によって、(最大提供負荷として) [RFC2285] のセクション 3.5.3 によってすでに規定されていますが、一部の実装では、ユーザー指定の値を要求する代わりに、それを検出または検出してもよい(MAY)。
In the MLRsearch Specification, one reason for listing the Relevant Upper Bound as a required attribute is that it makes the Search Result independent of the Max Load value.
MLRsearch 仕様で、関連上限を必須属性としてリストする理由の 1 つは、検索結果が最大負荷値に依存しないようにするためです。
Given that Max Load is a quantity based on Load, Test Report MAY express this quantity using multi-interface values, as the sum of per-interface maximal Loads.
最大負荷が負荷に基づく量であることを考慮すると、テスト レポートは、複数のインターフェイスの値を使用して、インターフェイスごとの最大負荷の合計としてこの量を表すことができます (MAY)。
Definition:
意味：
Min Load is an OPTIONAL attribute of Controller Input. It is the minimal value the Controller is allowed to use for Trial Loads.
最小負荷は、コントローラー入力のオプションの属性です。これは、コントローラが試行ロードに使用できる最小値です。
Discussion:
議論：
Min Load is another example of an optional attribute required by some implementations of MLRsearch. Similarly to Max Load, it makes more sense to prescribe one common value, as opposed to using a different value for each Search Goal.
Min Load は、MLRsearch の一部の実装で必要なオプションの属性のもう 1 つの例です。最大負荷と同様に、検索目標ごとに異なる値を使用するのではなく、1 つの共通の値を規定する方が合理的です。
If the Min Load is provided, the Controller MUST NOT select Trial Loads smaller than that value.
最小負荷が指定されている場合、コントローラーはその値より小さい試行負荷を選択してはなりません。
Min Load is mainly useful for saving time by failing early, arriving at an Irregular Goal Result when Min Load gets classified as an Upper Bound.
最小負荷は主に、早期に失敗して、最小負荷が上限として分類されたときに不規則な目標結果に到達することで時間を節約するのに役立ちます。
For implementations, it is RECOMMENDED to require Min Load to be non-zero and large enough to allow at least one frame to be forwarded even at the shortest allowed Trial Duration, so that the Trial Loss Ratio is always well-defined and the implementation can apply a relative Goal Width safely.
実装では、試行損失率が常に適切に定義され、実装が相対的な目標幅を安全に適用できるように、最小負荷がゼロではなく、許容される最短の試行期間でも少なくとも 1 つのフレームが転送されるのに十分な大きさであることを要求することが推奨されます。
Given that Min Load is a quantity based on Load, Test Report MAY express this quantity using multi-interface values, as the sum of per-interface minimal Loads.
最小負荷が負荷に基づく量であることを考慮すると、テスト レポートは、複数のインターフェイスの値を使用して、インターフェイスごとの最小負荷の合計としてこの量を表すことができます (MAY)。
While the terms defined in this section are not strictly needed when formulating MLRsearch requirements, they simplify the language used in discussion paragraphs and explanation sections.
このセクションで定義されている用語は、MLRsearch の要件を策定するときに厳密に必要というわけではありませんが、議論の段落や説明セクションで使用される用語を簡素化します。
When one Trial Result instance is compared to one Search Goal instance, several relations can be named using short adjectives.
1 つの試行結果インスタンスを 1 つの検索目標インスタンスと比較すると、短い形容詞を使用して複数の関係に名前を付けることができます。
As Trial Results do not affect each other, this Trial Classification does not change during a Search.
トライアル結果は互いに影響を与えないため、このトライアル分類は検索中に変更されません。
A Trial with a Trial Loss Ratio larger than a Goal Loss Ratio is called a _High-Loss Trial_, with respect to the given Search Goal (or _lossy Trial_, if the Goal Loss Ratio is zero).
トライアル損失率がゴール損失率よりも大きいトライアルは、指定された検索目標に関して、_高損失トライアル_ (または、ゴール損失率がゼロの場合は_損失トライアル_) と呼ばれます。
If a Trial is not a High-Loss Trial, it is called a _Low-Loss Trial_ (or _zero-loss Trial_, if the Goal Loss Ratio is zero).
トライアルが高損失トライアルではない場合は、_低損失トライアル_ (または、目標損失率がゼロの場合は _ゼロ損失トライアル_) と呼ばれます。
A Trial with a Trial Duration shorter than the Goal Final Trial Duration is called a _Short Trial_ with respect to the given Search Goal.
トライアル期間が目標の最終トライアル期間よりも短いトライアルは、指定された検索目標に関して「短いトライアル」と呼ばれます。
A Trial that is not a Short Trial is called a _Full-Length Trial_.
短期トライアルではないトライアルは、_全長トライアル_と呼ばれます。
Note that this includes Trial Durations larger than the Goal Final Trial Duration.
これには、目標の最終トライアル期間を超えるトライアル期間が含まれることに注意してください。
A Trial with a Trial Duration longer than the Goal Final Trial Duration is called a _Long Trial_.
トライアル期間が目標の最終トライアル期間よりも長いトライアルは、_長いトライアル_と呼ばれます。
When a set of all Trial Result instances, performed so far at one Load, is compared to one Search Goal instance, their relation can be named using the concept of a _bound_.
1 回のロードでこれまでに実行されたすべての Trial Result インスタンスのセットを 1 つの Search Goal インスタンスと比較する場合、それらの関係は、_bound_ の概念を使用して名前を付けることができます。
In general, such bounds are a current quantity, even though cases of a Load changing its classification more than once during the Search is rare in practice.
実際には、検索中に荷重の分類が複数回変更されるケースはまれですが、一般に、そのような境界は現在の数量です。
Definition:
意味：
A Load is called an Upper Bound if and only if it is classified as such by a "Load Classification Code" (Appendix A) algorithm for the given Search Goal at the current moment of the Search.
荷重は、検索の現時点で指定された検索目標の「荷重分類コード」(付録 A) アルゴリズムによってそのように分類される場合に限り、上限と呼ばれます。
Discussion:
議論：
In more detail, the set of all Trial Results performed so far at the Load (and any Trial Duration) is certain to fail to uphold all the requirements of the given Search Goal, mainly the Goal Loss Ratio in combination with the Goal Exceed Ratio. In this context, "certain to fail" relates to any possible Trial Results within the time remaining till the Goal Duration Sum is reached.
より詳細には、ロード (および任意のトライアル期間) でこれまでに実行されたすべてのトライアル結果のセットは、特定の検索目標のすべての要件 (主に、目標損失率と目標超過率の組み合わせ) を確実に満たすことができません。この文脈において、「確実に失敗する」とは、目標期間合計に達するまでの残り時間内に起こり得るトライアル結果を指します。
One Search Goal can have multiple different Loads classified as its Upper Bounds. While Search progresses and more Trials are measured, any Load can become an Upper Bound in principle.
1 つの検索目標には、その上限として分類される複数の異なる負荷を含めることができます。検索が進行し、より多くのトライアルが測定される間、原理的には任意の負荷が上限になる可能性があります。
Moreover, a Load can stop being an Upper Bound, but that can only happen when more than a Goal Duration Sum of Trials are measured (e.g., because another Search Goal needs more Trials at this Load). Informally, the previous Upper Bound got _invalidated_. In practice, the Load frequently becomes a Lower Bound instead.
さらに、ロードは上限でなくなる可能性がありますが、それはトライアルの目標期間合計を超えて測定された場合にのみ発生します (たとえば、このロードでは別の検索目標がより多くのトライアルを必要とするため)。非公式に、以前の上限は_無効化_されました。実際には、負荷は代わりに下限になることがよくあります。
Definition:
意味：
A Load is called a Lower Bound if and only if it is classified as such by a "Load Classification Code" (Appendix A) algorithm for the given Search Goal at the current moment of the Search.
検索の現時点で、指定された検索目標の「負荷分類コード」(付録 A) アルゴリズムによって負荷が下限として分類されている場合に限り、負荷は下限と呼ばれます。
Discussion:
議論：
In more detail, the set of all Trial Results performed so far at the Load (and any Trial Duration) is certain to uphold all the requirements of the given Search Goal, mainly the Goal Loss Ratio in combination with the Goal Exceed Ratio. Here, "certain to uphold" relates to any possible Trial Results within the time remaining till the Goal Duration Sum is reached.
より詳細には、ロード時にこれまでに実行されたすべてのトライアル結果のセット (および任意のトライアル期間) は、特定の検索目標のすべての要件 (主に、目標超過率と組み合わせた目標損失率) を確実に満たします。ここで、「確実に支持される」とは、目標期間合計に達するまでの残り時間内に起こり得るあらゆるトライアル結果に関連します。
One Search Goal can have multiple different Loads classified as its Lower Bounds. As Search progresses and more Trials are measured, any Load value can become a Lower Bound in principle.
1 つの検索目標には、その下限として分類される複数の異なる負荷を含めることができます。検索が進行し、より多くのトライアルが測定されると、原則として、任意の負荷値が下限になる可能性があります。
No Load can be both an Upper Bound and a Lower Bound for the same Search Goal at the same time, but it is possible for a larger Load to be a Lower Bound while a smaller Load is an Upper Bound at the same time.
負荷なしは、同時に同じ検索目標の上限と下限の両方になることができますが、より大きな負荷が下限になると同時に、より小さな負荷が上限になる可能性があります。
Moreover, a Load can stop being a Lower Bound, but that can only happen when more than a Goal Duration Sum of Trials are measured (e.g., because another Search Goal needs more Trials at this Load). Informally, the previous Lower Bound got invalidated. In practice, the Load frequently becomes an Upper Bound instead.
さらに、ロードは下限境界でなくなる可能性がありますが、それはトライアルの目標期間合計を超える値が測定された場合にのみ発生します (たとえば、このロードでは別の検索目標がより多くのトライアルを必要とするため)。非公式ですが、以前の下限は無効になりました。実際には、荷重は多くの場合、代わりに上限になります。
Definition:
意味：
A Load is called Undecided if it is currently neither an Upper Bound nor a Lower Bound for the give Search Goal.
現在、指定された検索目標の上限でも下限でもない場合、ロードは「未決定」と呼ばれます。
Discussion:
議論：
Any Load that has not been measured so far is Undecided.
これまで測定されていない荷重は未定です。
It is possible for a Load to transition from an Upper Bound to Undecided by adding Short Low-Loss Trials. That is yet another reason for users to avoid using Search Goals with different Goal Final Trial Durations.
短い低損失トライアルを追加することで、ロードを上限から未決定に移行することが可能です。これが、ユーザーが最終トライアル期間の異なる目標の検索目標の使用を避けるもう 1 つの理由です。
Before defining the full structure of a Controller Output, it is useful to define the composite quantity, called _Goal Result_. The following subsections define its attribute first, before describing the Goal Result quantity.
コントローラー出力の完全な構造を定義する前に、_Goal Result_ と呼ばれる複合量を定義すると便利です。次のサブセクションでは、目標結果の数量を説明する前に、最初にその属性を定義します。
There is a correspondence between Search Goals and Goal Results. Most of the following subsections refer to a given Search Goal when defining their terms. Conversely, at the end of the Search, each Search Goal instance has its corresponding Goal Result instance.
検索目標と目標結果の間には対応関係があります。以下のサブセクションのほとんどは、用語を定義するときに特定の検索目標を参照しています。逆に、検索の最後には、各検索目標インスタンスに対応する目標結果インスタンスが存在します。
Definition:
意味：
The Relevant Upper Bound is the smallest Load classified as an Upper Bound for a given Search Goal at the end of the Search.
関連する上限は、検索の終了時に特定の検索目標の上限として分類される最小の負荷です。
Discussion:
議論：
If no measured Load had enough High-Loss Trials, the Relevant Upper Bound MAY be non-existent, for example, when Max Load is classified as a Lower Bound.
測定された負荷に十分な高損失トライアルがなかった場合、たとえば最大負荷が下限として分類されている場合、関連する上限は存在しない可能性があります。
Conversely, when the Relevant Upper Bound does exist, it is not affected by the Max Load value.
逆に、関連する上限が存在する場合、それは最大荷重値の影響を受けません。
Given that the Relevant Upper Bound is a quantity based on Load, Test Report MAY express this quantity using multi-interface values, as the sum of Intended Loads over input interfaces.
関連する上限が負荷に基づく量であることを考慮すると、テスト レポートは、入力インターフェイス上の意図された負荷の合計として、マルチインターフェイス値を使用してこの量を表現してもよい(MAY)。
Definition:
意味：
The Relevant Lower Bound is the largest Load among those smaller than the Relevant Upper Bound that got classified as a Lower Bound for a given Search Goal at the end of the Search.
関連下限は、検索の終了時に特定の検索目標の下限として分類された、関連上限より小さいロードの中で最大のロードです。
Discussion:
議論：
If no Load had enough Low-Loss Full-Length Trials, the Relevant Lower Bound MAY be non-existent.
十分な低損失全長トライアルを備えたロードがない場合、関連する下限は存在しない可能性があります。
Strictly speaking, if the Relevant Upper Bound does not exist, the Relevant Lower Bound also does not exist. In a typical case, Max Load is classified as a Lower Bound, making it impossible to increase the Load to continue the Search for an actual Upper Bound. Thus, it is not clear whether a larger value would be found for a Relevant Lower Bound if larger Loads were available for selection.
厳密に言えば、関連する上限が存在しない場合、関連する下限も存在しません。一般的なケースでは、最大負荷は下限として分類されるため、実際の上限の検索を続行するために負荷を増やすことはできません。したがって、より大きな負荷を選択できる場合に、関連下限としてより大きな値が見つかるかどうかは明らかではありません。
Given that the Relevant Lower Bound is a quantity based on Load, Test Report MAY express this quantity using multi-interface values, as the sum of Intended Loads over input interfaces.
関連する下限が負荷に基づく量であることを考慮すると、テスト レポートは、複数のインタフェースの値を使用して、入力インターフェイス上の意図された負荷の合計としてこの量を表現してもよい(MAY)。
Definition:
意味：
Conditional Throughput is a value computed at the Relevant Lower Bound according to the algorithm defined in "Conditional Throughput Code" (Appendix B).
条件付きスループットは、「条件付きスループット コード」(付録 B) で定義されたアルゴリズムに従って、関連する下限で計算された値です。
Discussion:
議論：
The Relevant Lower Bound is defined only at the end of the Search, and so is the Conditional Throughput. But the algorithm can be applied at any time on any current Lower Bound, so the final Conditional Throughput value may appear sooner than at the end of a Search.
関連する下限は検索の終了時にのみ定義され、条件付きスループットも同様です。ただし、アルゴリズムはいつでも現在の下限に適用できるため、最終的な条件付きスループット値は検索の終了時よりも早く表示される可能性があります。
Informally, the Conditional Throughput should be a typical Trial Forwarding Rate, expected to be seen at the Relevant Lower Bound of a given Search Goal.
非公式には、条件付きスループットは、特定の検索目標の関連下限で見られることが期待される典型的なトライアル転送レートである必要があります。
But frequently, it is only a conservative estimate thereof, as MLRsearch implementations tend to stop measuring more Trials as soon as they confirm the value cannot get worse than this estimate within the Goal Duration Sum.
ただし、MLRsearch の実装では、目標期間の合計内で値がこの推定値よりも悪くならないことが確認されるとすぐに、それ以上のトライアルの測定を停止する傾向があるため、これは保守的な推定値にすぎないことがよくあります。
This quantity is RECOMMENDED to be used when evaluating repeatability and comparability of different MLRsearch implementations. Refer to "Generalized Throughput" (Section 5.6) for more details.
この量は、さまざまな MLRsearch 実装の再現性と比較可能性を評価するときに使用することが推奨されます。詳細については、「一般化されたスループット」(セクション 5.6) を参照してください。
Given that Conditional Throughput is a quantity based on Load, Test Report MAY express this quantity using multi-interface values, as the sum of per-interface Forwarding Rates.
条件付きスループットが負荷に基づく量であることを考慮すると、テスト レポートは、複数のインターフェイスの値を使用して、インターフェイスごとの転送レートの合計としてこの量を表現してもよい(MAY)。
The MLRsearch Specification is based on a set of requirements for a _regular_ result. But in practice, it is not always possible for such a result instance to exist, so _irregular_ results also need to be supported.
MLRsearch 仕様は、「正規」の結果に対する一連の要件に基づいています。しかし実際には、そのような結果インスタンスが常に存在できるとは限らないため、「不規則な」結果もサポートする必要があります。
Definition:
意味：
Regular Goal Result is a composite quantity consisting of several attributes. Relevant Upper Bound and Relevant Lower Bound are REQUIRED attributes. Conditional Throughput is a RECOMMENDED attribute.
通常の目標結果は、いくつかの属性で構成される複合量です。関連する上限と関連する下限は必須の属性です。条件付きスループットは推奨属性です。
Discussion:
議論：
Implementations MAY add their own attributes.
実装は独自の属性を追加してもよい(MAY)。
Test Report MUST display the Relevant Lower Bound. Displaying the Relevant Upper Bound is RECOMMENDED, especially if the implementation does not use Goal Width.
テストレポートには、関連する下限を表示しなければなりません。特に実装でゴール幅を使用しない場合は、関連する上限を表示することが推奨されます。
In general, stopping conditions for the corresponding Search Goal MUST be satisfied to produce a Regular Goal Result. Specifically, if an implementation offers Goal Width as a Search Goal attribute, the distance between the Relevant Lower Bound and the Relevant Upper Bound MUST NOT be larger than the Goal Width.
一般に、通常の目標結果を生成するには、対応する検索目標の停止条件が満たされなければなりません。具体的には、実装が検索ゴール属性としてゴール幅を提供する場合、関連する下限と関連する上限の間の距離はゴール幅より大きくてはなりません。
For stopping conditions, refer to "Goal Width" (Section 4.6.5) and "Stopping Conditions and Precision" (Section 5.2).
停止条件については、「ゴール幅」（4.6.5 節）および「停止条件と精度」（5.2 節）を参照してください。
Definition:
意味：
Irregular Goal Result is a composite quantity. All attributes are OPTIONAL.
不規則な目標結果は複合量です。すべての属性はオプションです。
Discussion:
議論：
It is RECOMMENDED to report any useful quantity even if it does not satisfy all the requirements. For example, if Max Load is classified as a Lower Bound, it is fine to report it as an "effective" Relevant Lower Bound (although not a real one, as that requires a Relevant Upper Bound, which does not exist in this case) and compute Conditional Throughput for it. In this case, only the missing Relevant Upper Bound signals this instance is irregular.
すべての要件を満たしていない場合でも、有用な数量を報告することが推奨されます。たとえば、最大負荷が下限として分類されている場合、それを「有効な」関連下限としてレポートしても問題ありません (ただし、この場合は存在しない関連上限が必要なので、実際のものではありません)。また、その条件付きスループットを計算します。この場合、欠落している関連上限のみが、このインスタンスが不規則であることを示します。
Similarly, if both Relevant Bounds exist, it is RECOMMENDED to include them as Irregular Goal Result attributes and let the Manager decide if they are too far apart for Test Report purposes.
同様に、両方の関連境界が存在する場合は、それらを不規則な目標結果属性として含め、テスト レポートの目的でそれらが離れすぎているかどうかをマネージャーに判断させることが推奨されます。
If Test Report displays some Irregular Goal Result attribute values, they MUST be clearly marked as coming from irregular results.
テストレポートに不規則な目標結果属性値が表示される場合、それらは不規則な結果からのものとして明確にマークされなければなりません。
The implementation MAY define additional attributes, for example, explicit flags for expected situations, so the Manager logic can be simpler.
実装では、マネージャのロジックをより単純にするために、追加の属性 (たとえば、予期される状況に対する明示的なフラグ) を定義してもよい(MAY)。
Definition:
意味：
Goal Result is a composite quantity. Each instance is either a Regular Goal Result or an Irregular Goal Result.
目標結果は複合量です。各インスタンスは、通常のゴール結果または不規則なゴール結果のいずれかです。
Discussion:
議論：
The Manager MUST be able of distinguishing whether the instance is regular or not, without accessing data outside the instance.
マネージャーは、インスタンスの外部のデータにアクセスすることなく、インスタンスが正規かどうかを区別できなければなりません。
Definition:
意味：
The Search Result is a single composite object that maps each Search Goal instance to a corresponding Goal Result instance.
検索結果は、各検索目標インスタンスを対応する目標結果インスタンスにマップする単一の複合オブジェクトです。
Discussion:
議論：
As an alternative to mapping, the Search Result MAY be represented as an ordered list of Goal Results that in that case MUST appear in the exact same order as the list of their corresponding Search Goals as specified in the Controller Input instance.
マッピングの代替として、検索結果は、目標結果の順序付きリストとして表されてもよく、その場合、コントローラー入力インスタンスで指定されている、対応する検索目標のリストとまったく同じ順序で表示されなければなりません。
When the Search Result is expressed as a mapping, it MUST contain an entry for every Search Goal supplied in the Controller Input.
検索結果がマッピングとして表現される場合、コントローラー入力で指定されたすべての検索目標のエントリが含まれていなければなりません (MUST)。
Identical Goal Result instances MAY be listed for different Search Goals, but their status as regular or irregular MAY be different, for example, if two Search Goals differ only in the Goal Width, and the Relevant Lower Bound is close enough to the Relevant Upper Bound according to only one of them.
同一の目標結果インスタンスが異なる検索目標に対してリストされてもよい（MAY）が、定期的または不定期としてのステータスは異なっていてもよい（MAY）。たとえば、2つの検索目標が目標幅のみが異なり、そのうちの1つだけによると、関連する下限が関連する上限に十分近い場合などである。
Definition:
意味：
The Controller Output is a composite quantity returned from the Controller to the Manager at the end of the Search. The Search Result instance is its only REQUIRED attribute.
コントローラー出力は、検索の終了時にコントローラーからマネージャーに返される複合量です。Search Result インスタンスは唯一の必須属性です。
Discussion:
議論：
The MLRsearch implementation MAY return additional data in the Controller Output, for example, the number of Trials performed and the total Search Duration.
MLRsearch 実装は、コントローラ出力で追加データ (実行されたトライアルの数や合計検索期間など) を返すことができます (MAY)。
The _MLRsearch architecture_ consists of three main system components: the Manager, the Controller, and the Measurer. The components were introduced in "Architecture Overview" (Section 4.2), and the following sections finalize their definitions using terms from previous sections.
_MLRsearch アーキテクチャ_は、Manager、Controller、Measurer という 3 つの主要なシステム コンポーネントで構成されます。コンポーネントは「アーキテクチャの概要」(セクション 4.2) で紹介されており、次のセクションでは、前のセクションの用語を使用してコンポーネントの定義を最終的にまとめます。
Note that the architecture also implies the presence of other components, such as the SUT and the tester (as a sub-component of the Measurer).
このアーキテクチャは、SUT や (Measurer のサブコンポーネントとしての) テスターなどの他のコンポーネントの存在も暗示していることに注意してください。
Communication protocols and interfaces between components are left unspecified. For example, when the MLRsearch Specification uses the verb "to call" when describing how the Controller interacts with the Measurer, it is possible that the Controller notifies the Manager to call the Measurer indirectly instead. In doing so, the Measurer implementations can be fully independent from the Controller implementations, for example, developed in different programming languages.
コンポーネント間の通信プロトコルとインターフェイスは未指定のままです。たとえば、MLRsearch 仕様で、コントローラーが測定者と対話する方法を説明するときに「呼び出す」という動詞が使用されている場合、コントローラーは、代わりに間接的に測定者を呼び出すようにマネージャーに通知する可能性があります。そうすることで、たとえば、さまざまなプログラミング言語で開発された場合など、Measurer の実装を Controller の実装から完全に独立させることができます。
Definition:
意味：
The Measurer is a functional element that, when called with a Trial Input instance, performs one Trial and returns a Trial Output instance.
Measurer は、Trial Input インスタンスで呼び出されたときに 1 つの Trial を実行し、Trial Output インスタンスを返す機能要素です。
Discussion:
議論：
This definition assumes the Measurer is already initialized. In practice, there may be additional steps before the Search, e.g., when the Manager configures the Traffic Profile (either on the Measurer or on its tester sub-component directly) and performs a warm-up (if the tester or the test procedure requires one).
この定義は、Measurer がすでに初期化されていることを前提としています。実際には、検索の前に追加の手順がある場合があります。たとえば、マネージャーがトラフィック プロファイルを (測定者またはそのテスター サブコンポーネントで直接) 設定し、ウォームアップを実行するとき (テスターまたはテスト手順で必要な場合)。
It is the responsibility of the Measurer implementation to uphold any requirements and assumptions present in the MLRsearch Specification, e.g., the Trial Forwarding Ratio not being larger than one.
MLRsearch 仕様に存在する要件と仮定 (トライアル転送率が 1 を超えないなど) を維持するのは、Measurer 実装の責任です。
Implementers have some freedom. For example, Section 10 of [RFC2544] gives some suggestions (but not requirements) related to duplicated or reordered frames. Implementations are RECOMMENDED to document their behavior related to such freedoms in as detailed a way as possible.
実装者にはある程度の自由があります。たとえば、[RFC2544] のセクション 10 では、フレームの重複または並べ替えに関するいくつかの提案 (要件ではなく) が示されています。実装では、そのような自由に関連する動作をできるだけ詳細に文書化することが推奨されます。
It is RECOMMENDED to benchmark the test equipment first, e.g., connect the sender and receiver directly (without any SUT in the path), find a Load that guarantees the Offered Load is not too far from the Intended Load, and use that value as the Max Load. When measuring the real SUT, it is RECOMMENDED to turn any severe deviation between the Intended Load and the Offered Load into the increased Trial Loss Ratio.
最初にテスト機器のベンチマークを行うことをお勧めします。たとえば、送信側と受信側を（パスに SUT を使用せずに）直接接続し、提供された負荷が意図された負荷から離れすぎないことを保証する負荷を見つけ、その値を最大負荷として使用します。実際の SUT を測定するときは、意図された負荷と提供された負荷の間の重大な偏差を増加した試行損失率に変換することが推奨されます。
Neither of these two recommendations are made into mandatory requirements, because it is not easy to provide guidance about when the difference is severe enough in a way that would be disentangled from other Measurer freedoms.
これら 2 つの推奨事項はいずれも必須要件にはされていません。なぜなら、他の測定者の自由から切り離して、差異が十分に深刻な場合についてのガイダンスを提供するのは容易ではないからです。
For a sample situation where the Offered Load cannot keep up with the Intended Load, and the consequences on the Search Result, refer to "Hard Performance Limit" (Section 5.6.1).
提供された負荷が意図された負荷に追いつかないサンプル状況と、検索結果への影響については、「ハード パフォーマンス制限」(セクション 5.6.1) を参照してください。
Definition:
意味：
The Controller is a functional element that, upon receiving a Controller Input instance, repeatedly generates Trial Input instances for the Measurer and collects the corresponding Trial Output instances. This cycle continues until the stopping conditions are met, at which point, the Controller produces a final Controller Output instance and terminates.
コントローラは、コントローラ入力インスタンスを受信すると、測定者用の試行入力インスタンスを繰り返し生成し、対応する試行出力インスタンスを収集する機能要素です。このサイクルは、停止条件が満たされるまで続き、その時点で、コントローラーは最終的なコントローラー出力インスタンスを生成して終了します。
Discussion:
議論：
Informally, the Controller has considerable freedom in selection of Trial Inputs, and the implementations want to achieve all the Search Goals in the shortest average Search Duration.
非公式には、コントローラーにはトライアル入力の選択においてかなりの自由があり、実装では最短の平均検索期間ですべての検索目標を達成したいと考えています。
The Controller's role in optimizing the overall Search Duration distinguishes MLRsearch algorithms from simpler search procedures.
全体的な検索期間を最適化するコントローラーの役割により、MLRsearch アルゴリズムとより単純な検索手順が区別されます。
Informally, each implementation can have different stopping conditions. Goal Width is only one example. In practice, implementation details do not affect comparability that much, as long as the Goal Result instances compared are regular.
非公式には、各実装には異なる停止条件を設定できます。ゴール幅は一例にすぎません。実際には、比較される目標結果インスタンスが規則的である限り、実装の詳細は比較可能性にそれほど影響しません。
Definition:
意味：
The Manager is a functional element that is responsible for provisioning other components, calling a Controller component once, and for creating the Test Report following the reporting format as defined in Section 26 of [RFC2544].
マネージャーは、他のコンポーネントをプロビジョニングし、コントローラー コンポーネントを 1 回呼び出し、[RFC2544] のセクション 26 で定義されているレポート形式に従ってテスト レポートを作成する機能要素です。
Discussion:
議論：
The Manager MUST initialize the SUT (including constituent DUTs) and the Measurer (and the tester if independent from Measurer) with their intended configurations before calling the Controller.
Manager は、Controller を呼び出す前に、SUT (構成要素である DUT を含む) と Measurer (および Measurer から独立している場合はテスター) を、意図した構成で初期化する必要があります。
Note that Section 7 of [RFC2544] already puts requirements on DUT setups:
[RFC2544] のセクション 7 では、すでに DUT セットアップに関する要件が規定されていることに注意してください。
It is expected that all of the tests will be run without changing the configuration or setup of the DUT in any way other than that required to do the specific test. For example, it is not acceptable to change the size of frame handling buffers between tests of frame handling rates or to disable all but one transport protocol when testing the throughput of that protocol.
特定のテストの実行に必要な以外の方法で DUT の構成やセットアップを変更することなく、すべてのテストが実行されることが期待されます。たとえば、フレーム処理レートのテスト間でフレーム処理バッファのサイズを変更したり、プロトコルのスループットをテストするときに 1 つを除くすべてのトランスポート プロトコルを無効にしたりすることは許容されません。
It is REQUIRED for the Test Report to encompass all the SUT configuration details, including the description of a _default_ DUT configuration common for most tests and configuration changes if required by a specific test.
テストレポートには、ほとんどのテストに共通する _default_ DUT 構成の説明や、特定のテストで必要な場合の構成変更など、すべての SUT 構成の詳細が含まれることが必須です。
For example, Section 5.1.1 of [RFC5180] recommends testing jumbo frames if SUT can forward them, even though they are outside the scope of the 802.3 IEEE standard [IEEE.802.3df]. In this case, it is acceptable for the SUT default configuration to not support jumbo frames and only enable this support when testing jumbo Traffic Profiles, as the handling of jumbo frames typically has different packet buffer requirements and potentially higher processing overhead. Non-jumbo frame sizes should also be tested on the jumbo-enabled setup.
たとえば、[RFC5180] のセクション 5.1.1 では、802.3 IEEE 標準 [IEEE.802.3df] の範囲外であっても、SUT がジャンボ フレームを転送できるかどうかをテストすることを推奨しています。この場合、ジャンボ フレームの処理には通常、異なるパケット バッファ要件があり、処理オーバーヘッドが高くなる可能性があるため、SUT のデフォルト設定でジャンボ フレームをサポートせず、ジャンボ トラフィック プロファイルのテスト時にのみこのサポートを有効にすることが許容されます。ジャンボ以外のフレーム サイズもジャンボ対応セットアップでテストする必要があります。
The Manager does not need to be able to tweak any Search Goal attributes, but it MUST report all applied attributes even if not tweaked.
マネージャーは検索目標の属性を調整できる必要はありませんが、たとえ調整されていない場合でも、適用されたすべての属性を報告する必要があります。
A human or automated _user_ invokes the Manager once to launch a single Search and receive its Test Report. Every new invocation is treated as a fresh, independent Search; how the system behaves across multiple calls (for example, combining or comparing their Search Results) is explicitly out of scope for this document.
人間または自動化された「ユーザー」は、マネージャーを 1 回呼び出して単一の検索を開始し、そのテスト レポートを受け取ります。新しい呼び出しはすべて、新鮮な独立した検索として扱われます。複数の呼び出し間でシステムがどのように動作するか (検索結果の結合や比較など) は、明示的にこのドキュメントの範囲外です。
This section discusses compliance relations between MLRsearch and other test procedures.
このセクションでは、MLRsearch と他のテスト手順の間の準拠関係について説明します。
Any networking measurement setup that could be understood as consisting of functional elements satisfying all requirements for the Measurer, the Controller, and the Manager is compliant with the MLRsearch Specification.
測定者、コントローラ、およびマネージャのすべての要件を満たす機能要素で構成されると理解できるネットワーク測定セットアップは、MLRsearch 仕様に準拠しています。
These components can be seen as abstractions present in any testing procedure. For example, there may be a single component acting as both the Manager and the Controller, but if values of all required attributes of Search Goals and Goal Results are visible in the Test Report, the Controller Input and Controller Output instances are implied.
これらのコンポーネントは、あらゆるテスト手順に存在する抽象化として見ることができます。たとえば、マネージャーとコントローラーの両方として機能する単一のコンポーネントが存在する場合がありますが、検索目標と目標結果のすべての必須属性の値がテスト レポートに表示されている場合、コントローラー入力インスタンスとコントローラー出力インスタンスが暗黙的に示されます。
For example, any setup for conditionally (or unconditionally) compliant [RFC2544] Throughput testing can be understood as an MLRsearch architecture if there is enough data to reconstruct the Relevant Upper Bound.
たとえば、条件付き (または無条件) [RFC2544] に準拠したスループット テストのセットアップは、関連する上限を再構築するのに十分なデータがある場合、MLRsearch アーキテクチャとして理解できます。
Refer to "MLRsearch Compliant with RFC 2544" (Section 4.10.2) for an equivalent Search Goal.
同等の検索目標については、「RFC 2544 に準拠した MLRsearch」(セクション 4.10.2) を参照してください。
Any test procedure that can be understood as one call to the Manager of the MLRsearch architecture is said to be compliant with the MLRsearch Specification.
MLRsearch アーキテクチャの Manager への 1 回の呼び出しとして理解できるテスト手順は、MLRsearch 仕様に準拠していると言われます。
Compliance with RFC 2544 is governed by [RFC2544]; rules of MLRsearch Specification cannot change that, but they can give recommendations to improve comparability.
RFC 2544 への準拠は [RFC2544] によって管理されます。MLRsearch 仕様のルールはそれを変更することはできませんが、比較可能性を向上させるための推奨事項を与えることはできます。
The following Search Goal instance is RECOMMENDED to make the corresponding Search Result unconditionally compliant with Section 24 of [RFC2544].
次の検索目標インスタンスは、対応する検索結果を [RFC2544] のセクション 24 に無条件に準拠させるために推奨されます (RECOMMENDED)。
* Goal Final Trial Duration = 60 seconds
* 目標の最終トライアル期間 = 60 秒
* Goal Duration Sum = 60 seconds
* 目標期間の合計 = 60 秒
* Goal Loss Ratio = 0%
* ゴールロス率 = 0%
* Goal Exceed Ratio = 0%
* 目標超過率 = 0%
The presence of other Search Goals does not affect the compliance of this Goal Result. In this case, the Relevant Lower Bound and the Conditional Throughput are equal to each other, and the value is the Throughput.
他の検索目標の存在は、この目標結果の準拠には影響しません。この場合、関連下限と条件付きスループットは等しく、その値がスループットになります。
Goal Duration Sum smaller than Goal Final Trial Duration should have no effect on the results. A non-zero Goal Exceed Ratio would needlessly prolong the Search when Short Trials of both loss types are present.
目標期間の合計が目標最終トライアル期間よりも小さい場合は、結果に影響を与えません。両方の損失タイプのショート トライアルが存在する場合、ゴール超過率がゼロ以外の場合、検索が不必要に長くなる可能性があります。
The Goal Loss Ratio and Goal Exceed Ratio are enough to make the Search Goal conditionally compliant. Adding Goal Final Trial Duration makes the Search Goal unconditionally compliant.
目標損失率と目標超過率は、検索目標を条件付きで準拠させるのに十分です。目標の最終トライアル期間を追加すると、検索目標が無条件に準拠します。
Small enough Goal Duration Sum prevents MLRsearch from repeating zero-loss Full-Length Trials. Allowing those would make it less clear whether the result is compliant with Section 24 of [RFC2544] or whether it is a new, stricter methodology.
目標期間合計が十分に小さいと、MLRsearch が損失ゼロの全長トライアルを繰り返すことができなくなります。これらを許可すると、結果が [RFC2544] のセクション 24 に準拠しているのか、それとも新しいより厳密な方法論であるのかが不明確になります。
One of the alternatives to [RFC2544] is Binary Search With Loss Verification, as described in Section 12.3.3 of [TST009].
[RFC2544] の代替手段の 1 つは、[TST009] のセクション 12.3.3 で説明されている、損失検証を伴う二分探索です。
The rationale of such a Search is to repeat High-Loss Trials, hoping for zero loss on the second try, so the Goal Results are closer to the noiseless end of the performance spectrum, thus more repeatable and comparable.
このような検索の理論的根拠は、2 回目の試行で損失がゼロであることを期待して高損失トライアルを繰り返すことであり、その結果、目標結果はパフォーマンス スペクトルのノイズのない端に近くなり、したがって再現性と比較性が高まります。
Only the variant with "z = infinity" is achievable with MLRsearch.
MLRsearch では、「z = 無限大」のバリアントのみが実現可能です。
For example, for the "max(r) = 2" variant, the following Search Goal instance is RECOMMENDED (for comparability reasons) to get a compatible Search Result:
たとえば、「max(r) = 2」バリアントの場合、互換性のある検索結果を取得するには、次の検索目標インスタンスが推奨されます（比較の理由から）。
* Goal Final Trial Duration = 60 seconds
* 目標の最終トライアル期間 = 60 秒
* Goal Duration Sum = 120 seconds
* 目標期間の合計 = 120 秒
* Goal Loss Ratio = 0%
* ゴールロス率 = 0%
* Goal Exceed Ratio = 50%
* 目標超過率 = 50%
If the first 60-second Trial has zero loss, it is enough for MLRsearch to stop measuring at that Load, as even a second High-Loss Trial would still fit within the Goal Exceed Ratio of 50%.
最初の 60 秒トライアルの損失がゼロであれば、2 番目の高損失トライアルでも 50% の目標超過率内に収まるため、MLRsearch がその負荷での測定を停止するだけで十分です。
But if the first Trial is High-Loss, MLRsearch also needs to perform the second Trial to classify that Load. The Goal Duration Sum is twice as long as the Goal Final Trial Duration, so a third Full-Length Trial is never needed.
ただし、最初のトライアルが高損失の場合、MLRsearch はその負荷を分類するために 2 番目のトライアルも実行する必要があります。目標期間の合計は目標の最終トライアル期間の 2 倍であるため、3 回目のフルレングス トライアルは必要ありません。
This section explains the "why" behind MLRsearch. Building on the normative specification in MLRsearch Specification, it contrasts MLRsearch with the classic single-ratio Binary Search in [RFC2544] and walks through the key design choices: search mechanics, stopping-rule precision, Loss Inversion for multiple goals, Goal Exceed Ratio handling, Short Trial strategies, and the generalized throughput concept. Together, these considerations show how the methodology reduces test time, supports multiple Goal Loss Ratios, and improves repeatability.
このセクションでは、MLRsearch の背後にある「理由」について説明します。MLRsearch 仕様の規範的な仕様に基づいて、MLRsearch と [RFC2544] の古典的な単一比率の二分探索を対比し、主要な設計上の選択事項、つまり検索の仕組み、停止ルールの精度、複数の目標の損失反転、目標超過比率の処理、ショート トライアル戦略、および一般化されたスループットの概念について説明します。これらの考慮事項を総合すると、この方法論がどのようにテスト時間を短縮し、複数の目標損失率をサポートし、再現性を向上させるかを示します。
A typical search implementation for [RFC2544], such as Binary Search, tracks only the two tightest bounds (in variables _lower-bound_ and _upper-bound_). To start, the search needs both Max Load and Min Load values. Then, one Trial is used to confirm Max Load is an Upper Bound, and one Trial is used to confirm Min Load is a Lower Bound.
二分探索などの [RFC2544] の一般的な検索実装は、2 つの最も厳しい境界 (変数 _ lower-bound_ および _upper-bound_ 内) のみを追跡します。検索を開始するには、最大負荷値と最小負荷値の両方が必要です。次に、最大負荷が上限であることを確認するために 1 つのトライアルが使用され、最小負荷が下限であることを確認するために 1 つのトライアルが使用されます。
Then, Trial Load is chosen as the mean of the current tightest upper bound and the current tightest lower bound and becomes a new tightest bound depending on the Trial Loss Ratio.
次に、試行負荷は現在の最も厳しい上限と現在の最も厳しい下限の平均として選択され、試行損失率に応じて新しい最も厳しい限界になります。
After some number of Trials, the tightest lower bound becomes the Throughput, but [RFC2544] does not specify when, if ever, the search should stop. In practice, the search stops either at some distance between the tightest upper bound and the tightest lower bound or after some number of Trials.
ある程度の試行回数を経た後、最も厳しい下限がスループットになりますが、[RFC2544] では検索をいつ停止すべきかについては指定していません。実際には、検索は最も厳しい上限と最も厳しい下限の間の距離、またはある程度の試行回数の後に停止します。
For a given pair of Max Load and Min Load values, there is a one-to-one correspondence between the number of Trials and the final distance between the tightest bounds. Thus, the search always takes the same time, assuming initial bounds are confirmed.
最大負荷値と最小負荷値の特定のペアについて、試行回数と最も厳しい境界間の最終距離との間には 1 対 1 の対応関係があります。したがって、初期境界が確認されたと仮定すると、検索には常に同じ時間がかかります。
The MLRsearch Specification requires listing both Relevant Upper Bound and Relevant Lower Bound for each Search Goal, and the difference between the bounds implies whether the precision needed for Regular Goal Result is achieved. Therefore, it is not necessary to report the specific stopping condition used.
MLRsearch 仕様では、検索目標ごとに関連する上限と関連する下限の両方をリストする必要があり、境界間の違いは、通常の目標結果に必要な精度が達成されるかどうかを暗示します。したがって、使用された特定の停止条件を報告する必要はありません。
MLRsearch implementations may use Goal Width to allow direct control of Regular Goal Result precision and indirect control of the Search Duration.
MLRsearch 実装では、目標幅を使用して、通常の目標結果の精度を直接制御し、検索期間を間接的に制御できます。
Other MLRsearch implementations may use different stopping conditions, for example, based on the Search Duration, trading off precision control for Search Duration control.
他の MLRsearch 実装では、たとえば、検索期間に基づいて、精度制御と検索期間制御をトレードオフして、異なる停止条件を使用する場合があります。
Due to various possible time optimizations, there is no strict correspondence between the Search Duration and Goal Width values. In practice, noisy SUT performance increases both average Search Duration and its variance.
時間の最適化にはさまざまな可能性があるため、検索期間と目標幅の値の間には厳密な対応関係はありません。実際には、SUT のパフォーマンスにノイズが多いと、平均検索期間とその分散の両方が増加します。
The biggest difference between MLRsearch and Binary Search is in the goals of the search. [RFC2544] has a single goal, based on classifying a single Full-Length Trial as either zero loss or non-zero loss. MLRsearch supports searching for multiple Search Goals at once, usually differing in their Goal Loss Ratios.
MLRsearch と Binary Search の最大の違いは、検索の目的にあります。[RFC2544] には、単一の全長トライアルをゼロ損失または非ゼロ損失として分類することに基づいた単一の目標があります。MLRsearch は、通常はゴール損失率が異なる複数の検索ゴールの一度の検索をサポートします。
Each bound in Binary Search is "hard", in the sense that all further Trial Loads are smaller than any current upper bound and larger than any current lower bound.
二分探索の各境界は、それ以降のすべての試行ロードが現在の上限よりも小さく、現在の下限よりも大きいという意味で「ハード」です。
This is also possible for MLRsearch implementations when the Search is started with only one Search Goal.
これは、検索が 1 つの検索目標のみで開始される場合の MLRsearch 実装でも可能です。
The MLRsearch Specification supports multiple Search Goals, making the Search procedure more complicated compared to Binary Search with a single goal, but most of the complications do not affect the final Search Results much, except for one phenomenon: Loss Inversion.
MLRsearch 仕様は複数の検索目標をサポートしているため、単一の目標による二分探索と比較して検索手順がより複雑になりますが、損失反転という 1 つの現象を除いて、ほとんどの複雑さは最終的な検索結果に大きな影響を与えません。
Depending on Search Goal attributes, Load Classification results may be resistant to small amounts of Inconsistent Trial Results. However, for larger amounts, a Load that is classified as an Upper Bound for one Search Goal may still be a Lower Bound for another Search Goal. Due to this other Search Goal, MLRsearch will probably perform subsequent Trials at Loads even larger than the original value.
検索目標の属性によっては、負荷分類の結果が少量の一貫性のないトライアル結果に耐えられる場合があります。ただし、量が大きい場合、1 つの検索目標の上限として分類された負荷が、別の検索目標の下限となる場合があります。この他の検索目標により、MLRsearch はおそらく、元の値よりもさらに大きな負荷で後続のトライアルを実行することになります。
This introduces questions any multi-goal search algorithm has to address, such as: What to do when all such Trials at larger Loads happen to have zero loss? Does it mean the earlier Upper Bound was not real? Does it mean the later Low-Loss Trials do not count toward a Lower Bound?
これにより、複数目標の検索アルゴリズムが対処しなければならない次のような問題が生じます。たとえば、より大きな負荷でのそのようなすべてのトライアルで損失がゼロになった場合はどうすればよいか?それは、以前の上限は現実ではなかったということですか?それ以降の低損失トライアルは下限にカウントされないということですか?
The situation where a smaller Load is classified as an Upper Bound, while a larger Load is classified as a Lower Bound (for the same Search Goal), is called Loss Inversion.
(同じ検索目標に対して) 小さい負荷が上限として分類され、大きい負荷が下限として分類される状況は、損失反転と呼ばれます。
Conversely, only single-goal search algorithms can have hard bounds that shield them from Loss Inversion.
逆に、損失反転から保護するハード境界を持つことができるのは、単一目標の検索アルゴリズムのみです。
MLRsearch is conservative when dealing with Loss Inversion: The Upper Bound is considered real, and the Lower Bound is considered to be a fluke, at least when computing the Goal Result.
MLRsearch は、ロス インバージョンを扱うときは保守的です。少なくとも目標結果を計算する場合、上限は実際のものとみなされ、下限はまぐれであるとみなされます。
This is formalized using the definitions of "Relevant Upper Bound" (Section 4.8.1) and "Relevant Lower Bound" (Section 4.8.2).
これは、「関連する上限」(セクション 4.8.1) および「関連する下限」(セクション 4.8.2) の定義を使用して形式化されます。
The Relevant Upper Bound (for a specific Search Goal) is the smallest Load classified as an Upper Bound. But the Relevant Lower Bound is not simply the largest among Lower Bounds. It is the largest Load among Loads that are Lower Bounds while also being smaller than the Relevant Upper Bound.
関連する上限 (特定の検索目標の) は、上限として分類される最小の負荷です。しかし、関連する下限は単に下限の中で最大というわけではありません。これは、下限である負荷の中で最大の負荷ですが、関連する上限よりも小さい負荷です。
With these definitions, the Relevant Lower Bound is always smaller than the Relevant Upper Bound (if both exist), and the two Relevant Bounds are used analogously as the two tightest bounds in the Binary Search. When they meet the stopping conditions, the Relevant Upper Bound and the Relevant Lower Bound are used in the Goal Result.
これらの定義では、関連する下限は常に関連する上限よりも小さく (両方が存在する場合)、2 つの関連する境界は二分探索における 2 つの最も厳しい境界として同様に使用されます。停止条件が満たされると、関連する上限と関連する下限が目標結果に使用されます。
The consequence of the way the Relevant Upper Bound and Relevant Lower Bound are defined is that every Trial Result can have an impact on any current Relevant Upper Bound or Relevant Lower Bound larger than that Trial Load, namely by becoming a new Relevant Upper Bound.
関連する上限と関連する下限の定義方法の結果として、すべての試行結果は、その試行負荷よりも大きい現在の関連する上限または関連する下限に影響を与える可能性があります。つまり、新しい関連する上限となることです。
This also applies when that Load is measured before another Load gets enough measurements to become a current Relevant Lower Bound or Relevant Upper Bound.
これは、別の負荷が現在の関連下限または関連上限になるのに十分な測定値を取得する前に、その負荷が測定される場合にも当てはまります。
This also implies that if the SUT tested (or the Traffic Generator used) needs a warm-up, it should be warmed up before starting the Search; otherwise, the first few measurements could become unjustly limiting.
これは、テストされる SUT (または使用されるトラフィック ジェネレーター) がウォームアップを必要とする場合、検索を開始する前にウォームアップする必要があることも意味します。そうしないと、最初の数回の測定が不当に制限される可能性があります。
For MLRsearch implementations, this means that it is better to measure at smaller Loads first, so any Lower Bounds found earlier are less likely to get invalidated later.
MLRsearch 実装の場合、これは、最初に小さい負荷で測定する方が良いことを意味するため、以前に見つかった下限は後で無効になる可能性が低くなります。
The idea of performing multiple Trials at the same Trial Load comes from a model where some Trial Results (those with a high Trial Loss Ratio) are affected by infrequent effects, causing unsatisfactory repeatability of [RFC2544] Throughput results. Refer to "DUT in SUT" (Section 2.3) for a discussion about noiseful and noiseless ends of the SUT performance spectrum. Stable results are closer to the noiseless end of the SUT performance spectrum, so MLRsearch may need to allow some frequency of High-Loss Trials to ignore the rare but big effects near the noiseful end.
同じトライアルロードで複数のトライアルを実行するというアイデアは、一部のトライアル結果 (トライアル損失率が高いもの) がまれな影響によって影響を受け、[RFC2544] スループット結果の再現性が不十分になるというモデルに由来しています。SUT の性能スペクトルのノイズの多い端とノイズのない端についての説明は、「SUT 内の DUT」(セクション 2.3) を参照してください。安定した結果は、SUT パフォーマンス スペクトルのノイズのない端に近いため、MLRsearch では、ノイズの多い端に近いまれではあるが大きな影響を無視できるように、高損失トライアルをある程度の頻度で許可する必要がある場合があります。
For MLRsearch to perform such Trial Result filtering, it needs a configuration option to tell how frequent the "infrequent" big Trial Loss Ratio can be. This option is called the Goal Exceed Ratio. It tells MLRsearch what ratio of Trials (more specifically, what ratio of Trial Effective Duration seconds) can have a Trial Loss Ratio larger than the Goal Loss Ratio and still be classified as a Lower Bound.
MLRsearch がこのような試行結果フィルタリングを実行するには、「まれな」大きな試行損失率がどの程度の頻度で発生するかを示す構成オプションが必要です。このオプションは、目標超過率と呼ばれます。これは、トライアルのどの比率 (より具体的には、トライアルの有効期間の秒数の比率) が目標損失率より大きくても、下限として分類できるかを MLRsearch に指示します。
A zero Goal Exceed Ratio means all Trials must have a Trial Loss Ratio equal to or lower than the Goal Loss Ratio.
ゼロの目標超過率は、すべてのトライアルのトライアル損失率が目標損失率以下でなければならないことを意味します。
When more than one Trial is intended to classify a Load, MLRsearch also needs something that controls the number of Trials needed. Therefore, each Search Goal also has an attribute called Goal Duration Sum.
ロードを分類するために複数のトライアルを行う場合、MLRsearch には必要なトライアルの数を制御する機能も必要です。したがって、各検索目標には、目標期間合計と呼ばれる属性もあります。
The meaning of a Goal Duration Sum is that when a Load has Full-Length Trials whose Trial Effective Durations when summed up give a value at least as big as the Goal Duration Sum, the Load is guaranteed to be classified as either an Upper Bound or a Lower Bound for that Search Goal.
目標期間の合計の意味は、ロードに全長トライアルがあり、そのトライアルの有効期間を合計すると少なくとも目標期間の合計と同じ値になる場合、ロードはその検索目標の上限または下限のいずれかに分類されることが保証されるということです。
MLRsearch requires each Search Goal to specify its Goal Final Trial Duration.
MLRsearch では、各検索目標に目標の最終トライアル期間を指定する必要があります。
Section 24 of [RFC2544] already anticipates possible time savings when Short Trials are used.
[RFC2544] のセクション 24 では、ショート トライアルを使用した場合の時間節約の可能性をすでに予測しています。
An MLRsearch implementation MAY expose configuration parameters that decide whether, when, and how Short Trials are used. The exact heuristics and controls are left to the discretion of the implementer.
MLRsearch 実装は、ショート トライアルを使用するかどうか、いつ、どのように使用するかを決定する構成パラメータを公開してもよい(MAY)。正確なヒューリスティックと制御は実装者の裁量に任されています。
While MLRsearch implementations are free to use any logic to select Trial Inputs, comparability between MLRsearch implementations is only assured when the Load Classification Logic handles any possible set of Trial Results in the same way.
MLRsearch 実装はトライアル入力を選択するために任意のロジックを自由に使用できますが、MLRsearch 実装間の比較可能性は、負荷分類ロジックがトライアル結果の考えられるセットを同じ方法で処理する場合にのみ保証されます。
The presence of Short Trial Results complicates the Load Classification Logic; see more details in "Load Classification Logic" (Section 6.1).
短いトライアル結果が存在すると、負荷分類ロジックが複雑になります。詳細については、「負荷分類ロジック」(セクション 6.1) を参照してください。
While the Load Classification algorithm is designed to avoid any unneeded Trials, for explainability reasons, it is recommended for users to use such Controller Inputs that lead to all Trial Durations selected by the Controller to be the same, e.g., by setting any Goal Initial Trial Duration to be a single value also used for all Goal Final Trial Durations.
負荷分類アルゴリズムは不要なトライアルを回避するように設計されていますが、説明可能性の理由から、たとえば、目標の初期トライアル期間をすべての目標の最終トライアル期間にも使用される単一の値に設定するなど、コントローラーによって選択されたすべてのトライアル期間が同じになるようなコントローラー入力を使用することをお勧めします。
Because testing equipment takes the Intended Load as an input parameter for a Trial measurement, any load search algorithm needs to deal with Intended Load values internally.
試験装置は試行測定の入力パラメータとして意図された荷重を受け取るため、荷重検索アルゴリズムは内部で意図された荷重の値を処理する必要があります。
But in the presence of Search Goals with a non-zero Goal Loss Ratio, the Load usually does not match the user's intuition of what a throughput is. The Trial Forwarding Rate is better, but it is not obvious how to generalize it for Loads with multiple Trials and a non-zero Goal Loss Ratio.
しかし、ゼロ以外の目標損失率を持つ検索目標が存在する場合、負荷は通常、スループットが何であるかについてのユーザーの直感と一致しません。トライアル転送率は優れていますが、複数のトライアルとゼロ以外の目標損失率を持つロードに対してそれを一般化する方法は明らかではありません。
The clearest illustration for adopting a generalized throughput definition is the presence of a hard performance limit.
一般化されたスループット定義を採用するための最も明確な例は、厳しいパフォーマンス制限の存在です。
Even if the bandwidth of a medium allows higher traffic forwarding performance, the SUT interfaces may have their own additional limitations, e.g., a specific frames-per-second limit on the Network Interface Card (NIC), a common occurrence.
メディアの帯域幅によってより高いトラフィック転送パフォーマンスが可能であっても、SUT インターフェイスには、ネットワーク インターフェイス カード (NIC) 上の特定のフレーム/秒制限など、独自の追加の制限がある場合があります。これはよくあることです。
Those limitations should be known and provided as Max Load.
これらの制限を認識し、最大負荷として提供する必要があります。
But if Max Load is set larger than what the interface can receive or transmit, there will be a _hard limit_ behavior observed in Trial Results.
ただし、最大負荷がインターフェイスが受信または送信できるものよりも大きく設定されている場合、トライアル結果で「ハード リミット」の動作が観察されます。
Consider that the hard limit is at one hundred million frames per second (100 Mfps), Max Load is larger, and the Goal Loss Ratio is 0.5%. If DUT introduces no additional losses, 0.5% Trial Loss Ratio will be achieved at the Relevant Lower Bound of 100.5025 Mfps.
ハード リミットが 1 億フレーム/秒 (100 Mfps) で、最大負荷が大きく、目標損失率が 0.5% であることを考慮してください。DUT が追加の損失を導入しない場合、100.5025 Mfps の関連下限で 0.5% の試行損失率が達成されます。
Reporting a throughput that exceeds the SUT's verified hard limit would be counterintuitive. Therefore, the Throughput metric should be generalized to reflect realistic, limit-aware performance.
SUT の検証済みのハードリミットを超えるスループットを報告することは、直感に反します。したがって、スループット メトリックは、限界を意識した現実的なパフォーマンスを反映するように一般化する必要があります。
MLRsearch defines one such generalization, the "Conditional Throughput" (Section 4.8.3). It is the Trial Forwarding Rate from one of the Full-Length Trials performed at the Relevant Lower Bound. For the algorithm to determine exactly which Trial, see "Conditional Throughput Code" (Appendix B).
MLRsearch は、そのような一般化の 1 つである「条件付きスループット」(セクション 4.8.3) を定義します。これは、関連する下限で実行された全長トライアルの 1 つからのトライアル転送率です。どのトライアルを正確に決定するアルゴリズムについては、「条件付きスループット コード」(付録 B) を参照してください。
In the hard limit example, a 100.5025 Mfps Load will still have only a 100.0 Mfps Trial Forwarding Rate, nicely confirming the known limitation.
ハード リミットの例では、100.5025 Mfps のロードでも 100.0 Mfps のトライアル転送レートしかなく、既知の制限がうまく裏付けられています。
With a non-zero Goal Loss Ratio, and without hard performance limits, Low-Loss Trials at the same Load may achieve different Trial Forwarding Rate values simply due to DUT performance variability.
目標損失率がゼロではなく、厳しいパフォーマンス制限がない場合、同じ負荷での低損失トライアルでは、単純に DUT パフォーマンスのばらつきにより、異なるトライアル転送レート値が達成される可能性があります。
By comparing the best case (all Relevant Lower Bound Trials have zero loss) and the worst case (all Trial Loss Ratios at the Relevant Lower Bound are equal to the Goal Loss Ratio), one can prove that Conditional Throughput values may have a relative difference up to the Goal Loss Ratio.
最良のケース (関連するすべての下限トライアルで損失がゼロである) と最悪のケース (関連する下限でのすべてのトライアル損失率が目標損失率に等しい) を比較することにより、条件付きスループット値には目標損失率までの相対的な差がある可能性があることを証明できます。
Setting the Goal Width below the Goal Loss Ratio may cause the Conditional Throughput for a larger Goal Loss Ratio to become smaller than a Conditional Throughput for a Search Goal with a lower Goal Loss Ratio, which is counterintuitive, considering they come from the same Search. Therefore, it is RECOMMENDED to set the Goal Width to a value no lower than the Goal Loss Ratio of the next higher loss Search Goal.
ゴール幅をゴール損失率よりも低く設定すると、より大きなゴール損失率の条件付きスループットが、より低いゴール損失率の検索ゴールの条件付きスループットよりも小さくなる可能性があります。これは、同じ検索からのものであることを考えると直感に反します。したがって、目標幅を次に高い損失検索目標の目標損失率以上の値に設定することが推奨されます。
Although Conditional Throughput can fluctuate from one run to the next, it still offers a more nuanced basis for comparison than the Relevant Lower Bound, particularly when deterministic Load selection yields the same Relevant Lower Bound value across multiple runs.
条件付きスループットは実行ごとに変動する可能性がありますが、特に決定的な負荷選択により複数の実行にわたって同じ関連下限値が得られる場合、関連下限よりも微妙な比較基準を提供します。
This section uses informal language to describe two aspects of MLRsearch logic: Load Classification and Conditional Throughput, reflecting formal pseudocode representation provided in "Load Classification Code" (Appendix A) and "Conditional Throughput Code" (Appendix B).
このセクションでは、非形式的な表現を使用して、MLRsearch ロジックの 2 つの側面、つまり負荷分類と条件付きスループットについて説明します。これは、「負荷分類コード」(付録 A) および「条件付きスループット コード」(付録 B) で提供される正式な擬似コード表現を反映しています。
The logic is equivalent but not identical to the pseudocode in the appendices. The pseudocode is designed to be short and frequently combines multiple operations into one expression. The logic, as described in this section, lists each operation separately and uses more intuitive names for the intermediate values.
ロジックは付録の疑似コードと同等ですが、同一ではありません。擬似コードは短く設計されており、複数の演算を 1 つの式に組み合わせることがよくあります。このセクションで説明するロジックでは、各操作を個別にリストし、中間値により直感的な名前を使用します。
A detailed description of an example Search is in "Example Search" (Appendix C).
検索例の詳細については、「検索例」(付録 C) を参照してください。
For clarity of explanation, variables are tagged as (I)nput, (T)emporary, and (O)utput.
説明を明確にするために、変数には (Input、(Temporary、および (Output.
* Collect Trial Results:
* トライアル結果を収集する:
- Take all Trial Results (I) measured at a given Load.
- 特定の負荷で測定されたすべての試行結果 (I) を取得します。
* Aggregate Trial Durations:
* 試用期間の合計:
- Full-Length High-Loss sum (T) is the sum of Trial Effective Duration values of all Full-Length High-Loss Trials (I).
- 全長高損失の合計 (T) は、すべての全長高損失トライアル (I) のトライアル有効期間値の合計です。
- Full-Length Low-Loss sum (T) is the sum of Trial Effective Duration values of all Full-Length Low-Loss Trials (I).
- 全長低損失の合計 (T) は、すべての全長低損失トライアル (I) のトライアル有効期間値の合計です。
- Short High-Loss sum is the sum (T) of Trial Effective Duration values of all Short High-Loss Trials (I).
- 短期高損失合計は、すべての短期高損失トライアル (I) のトライアル有効期間値の合計 (T) です。
- Short Low-Loss sum is the sum (T) of Trial Effective Duration values of all Short Low-Loss Trials (I).
- 短期低損失合計は、すべての短期低損失トライアル (I) のトライアル有効期間値の合計 (T) です。
* Derive goal-based ratios:
* 目標に基づいた比率を導き出す:
- Subceed ratio (T) is one minus the Goal Exceed Ratio (I).
- サブシード率 (T) は、1 から目標超過率 (I) を引いたものです。
- Exceed coefficient (T) is the Goal Exceed Ratio divided by the subceed ratio.
- 超過係数 (T) は、目標超過率をサブシード率で割ったものです。
* Balance Short Trial effects:
* ショートトライアル効果のバランスをとる:
- Balancing sum (T) is the Short Low-Loss sum multiplied by the exceed coefficient.
- バランス合計 (T) は、ショート低損失合計に超過係数を乗算したものです。
- Excess sum (T) is the Short High-Loss sum minus the balancing sum.
- 超過合計 (T) は、ショート高損失合計からバランス合計を差し引いたものです。
- Positive excess sum (T) is the maximum of zero and the excess sum.
- 正の超過合計 (T) は、ゼロと超過合計の最大値です。
* Compute effective duration totals:
* 有効期間の合計を計算します。
- Effective High-Loss sum (T) is the Full-Length High-Loss sum plus the positive excess sum.
- 実効高損失合計 (T) は、全長高損失合計に正の超過合計を加算したものです。
- Effective full sum (T) is the effective High-Loss sum plus the Full-Length Low-Loss sum.
- 実効全合計 (T) は、実効高損失合計と全長低損失合計を加算したものです。
- Effective whole sum (T) is the larger of the effective full sum and the Goal Duration Sum.
- 有効全体合計 (T) は、有効合計と目標期間合計の大きい方です。
- Missing sum (T) is the effective whole sum minus the effective full sum.
- 欠損合計 (T) は、有効全体合計から有効全体合計を引いたものです。
* Estimate exceed ratios:
* 超過率の推定:
- Pessimistic High-Loss sum (T) is the effective High-Loss sum plus the missing sum.
- 悲観的高損失合計 (T) は、有効な高損失合計と欠損合計を加算したものです。
- Optimistic exceed ratio (T) is the effective High-Loss sum divided by the effective whole sum.
- 楽観的超過率 (T) は、実効高損失合計を実効全体合計で割ったものです。
- Pessimistic exceed ratio (T) is the pessimistic High-Loss sum divided by the effective whole sum.
- 悲観的超過比率 (T) は、悲観的高損失合計を実効全体合計で割ったものです。
* Classify the Load:
* 負荷を分類します。
- The Load is classified as an Upper Bound (O) if the optimistic exceed ratio is larger than the Goal Exceed Ratio.
- 楽観的超過率が目標超過率よりも大きい場合、負荷は上限 (O) として分類されます。
- The Load is classified as a Lower Bound (O) if the pessimistic exceed ratio is not larger than the Goal Exceed Ratio.
- 悲観的な超過率が目標超過率を超えない場合、負荷は下限 (O) として分類されます。
- The Load is classified as Undecided (O) otherwise.
- それ以外の場合、ロードは未決定 (O) として分類されます。
* Collect Trial Results:
* トライアル結果を収集する:
- Take all Trial Results (I) measured at a given Load.
- 特定の負荷で測定されたすべての試行結果 (I) を取得します。
* Sum of Full-Length Durations:
* 全長の合計時間:
- Full-Length High-Loss sum (T) is the sum of Trial Effective Duration values of all Full-Length High-Loss Trials (I).
- 全長高損失の合計 (T) は、すべての全長高損失トライアル (I) のトライアル有効期間値の合計です。
- Full-Length Low-Loss sum (T) is the sum of Trial Effective Duration values of all Full-Length Low-Loss Trials (I).
- 全長低損失の合計 (T) は、すべての全長低損失トライアル (I) のトライアル有効期間値の合計です。
- Full-Length sum (T) is the Full-Length High-Loss sum (I) plus the Full-Length Low-Loss sum (I).
- 全長合計 (T) は、全長高損失合計 (I) に全長低損失合計 (I) を加えたものです。
* Derive initial thresholds:
* 初期閾値を導出する：
- Subceed ratio (T) is one minus the Goal Exceed Ratio (I).
- サブシード率 (T) は、1 から目標超過率 (I) を引いたものです。
- Remaining sum (T) is initially the Full-Length sum multiplied by the subceed ratio.
- 残りの合計 (T) は、最初は全長合計にサブシード率を乗算したものです。
- Current loss ratio (T) is initially 100%.
- 電流損失率 (T) は最初は 100% です。
* Iterate through ordered Trials:
* 順序付けられたトライアルを反復処理します。
- For each Full-Length Trial Result, sorted in increasing order by Trial Loss Ratio:
- 各全長トライアル結果について、トライアル損失率の昇順に並べ替えたものは次のとおりです。
o If the remaining sum is not larger than zero, exit the loop.
o 残りの合計がゼロ以下の場合、ループを終了します。
o Set the current loss ratio to this Trial's Trial Loss Ratio (I).
o 現在の損失率をこのトライアルのトライアル損失率 (I) に設定します。
o Decrease the remaining sum by this Trial's Trial Effective Duration (I).
o 残りの合計をこのトライアルのトライアル有効期間 (I) だけ減算します。
* Compute Conditional Throughput:
* 条件付きスループットを計算する:
- Current forwarding ratio (T) is one minus the current loss ratio.
- 現在の転送率 (T) は、1 から現在の損失率を引いたものです。
- Conditional Throughput (T) is the current forwarding ratio multiplied by the Load value.
- 条件付きスループット (T) は、現在の転送率に負荷値を乗算したものです。
Conditional Throughput and results of Load Classification overlap but are not identical.
条件付きスループットと負荷分類の結果は重複していますが、同一ではありません。
* When a Load is marked as a Relevant Lower Bound, its Conditional Throughput is taken from a Trial whose Trial Loss Ratio is not larger than the Goal Loss Ratio.
* ロードが関連下限としてマークされている場合、その条件付きスループットは、トライアル損失率が目標損失率以下であるトライアルから取得されます。
* The reverse is not guaranteed: If the Goal Width is narrower than the Goal Loss Ratio, Conditional Throughput can still end up higher than the Relevant Upper Bound.
* 逆は保証されません。目標幅が目標損失率よりも狭い場合でも、条件付きスループットが関連する上限よりも高くなる可能性があります。
In "DUT in SUT" (Section 2.3), the notion of noise is introduced. This section uses new terms to describe possible SUT behaviors more precisely.
「SUT 内の DUT」(セクション 2.3) では、ノイズの概念が導入されています。このセクションでは、考えられる SUT の動作をより正確に説明するために新しい用語を使用します。
From a measurement point of view, noise is visible as Inconsistent Trial Results. See "Inconsistent Trial Results" (Section 2.6) for general points and "Loss Inversion" (Section 5.3.2) for specifics when comparing different Load values.
測定の観点からは、ノイズは一貫性のない試行結果として認識されます。異なる負荷値を比較する場合の一般的な点については「一貫性のない試行結果」(セクション 2.6) を、詳細については「損失の反転」(セクション 5.3.2) を参照してください。
Load Classification and Conditional Throughput apply to a single Load value, but even the set of Trial Results measured at that Trial Load value may appear inconsistent.
負荷分類と条件付きスループットは単一の負荷値に適用されますが、その試行負荷値で測定された一連の試行結果であっても一貫性がないように見える場合があります。
As MLRsearch aims to save time, it executes only a small number of Trials, getting only a limited amount of information about SUT behavior. It is useful to introduce a _SUT expert_ point of view to contrast with that limited information.
MLRsearch は時間を節約することを目的としているため、少数のトライアルのみを実行し、SUT の動作に関する限られた量の情報のみを取得します。その限られた情報と対比するために、_SUT の専門家_ の視点を導入すると便利です。
Imagine that before the Search starts, a human expert had unlimited time to measure SUT and obtain all reliable information about it. The information is not perfect, as there is still random noise influencing SUT. But the expert is familiar with possible noise events, even the rare ones, and thus, the expert can do probabilistic predictions about future Trial Outputs.
検索が開始される前に、人間の専門家が SUT を測定し、それに関するすべての信頼できる情報を取得するために無制限の時間を持っていたと想像してください。SUT に影響を与えるランダム ノイズがまだ存在するため、この情報は完全ではありません。しかし、専門家は、まれなノイズイベントであっても、起こり得るノイズイベントに精通しているため、将来の試行出力について確率的予測を行うことができます。
When several outcomes are possible, the expert can assess the probability of each outcome.
複数の結果が考えられる場合、専門家は各結果の確率を評価できます。
When the Controller selects a new Trial Duration and Trial Load, and just before the Measurer starts performing the Trial, the SUT expert can envision possible Trial Results.
コントローラーが新しいトライアル期間とトライアル ロードを選択し、測定者がトライアルの実行を開始する直前に、SUT 専門家は考えられるトライアル結果を想定できます。
With respect to a particular Search Goal, the possibilities can be summarized into a single number: Exceed Probability. It is the probability (according to the expert) that the measured Trial Loss Ratio will be higher than the Goal Loss Ratio.
特定の検索目標に関して、可能性は単一の数値「超過確率」に要約できます。これは、（専門家によれば）測定された試行損失率が目標損失率よりも高くなる確率です。
When comparing Exceed Probability values for the same Trial Load value but different Trial Duration values, there are several patterns that commonly occur in practice.
同じ試行負荷値で異なる試行期間値の超過確率値を比較する場合、実際には一般的に発生するパターンがいくつかあります。
Exceed Probability is very low for Short Trials but very high for Full-Length Trials. This SUT behavior is undesirable and may hint at a faulty SUT, e.g., SUT leaks resources and is unable to sustain the desired performance.
超過確率は、短いトライアルでは非常に低くなりますが、全長のトライアルでは非常に高くなります。この SUT の動作は望ましくなく、SUT がリソースをリークして望ましいパフォーマンスを維持できないなど、SUT に欠陥があることを示唆する可能性があります。
But this behavior is also seen when SUT uses large amount of buffers. This is the main reason users may want to set a large Goal Final Trial Duration.
ただし、この動作は、SUT が大量のバッファを使用する場合にも見られます。これが、ユーザーが最終トライアル期間の目標を長く設定する主な理由です。
Short Trials are slightly less likely to become High-Loss according to the Goal Loss Ratio, but the slope is modest. This mild increase is typical when noise is dominated by rare, large loss spikes: During a Full-Length Trial, the good-performing periods cannot fully offset the heavy frame loss that occurs in the brief low-performing bursts.
ゴール損失率に応じて、ショートトライアルは高損失になる可能性がわずかに低くなりますが、傾きは緩やかです。この緩やかな増加は、ノイズがまれに発生する大きな損失スパイクによって支配されている場合に一般的です。フルレングス トライアル中、パフォーマンスの良い期間では、短期間の低パフォーマンスのバーストで発生する大きなフレーム損失を完全に相殺できません。
Short Trials have basically the same Exceed Probability as Full-Length Trials. This is possible only if loss spikes are small (so other parts can compensate) and if the Goal Loss Ratio is more than zero (otherwise, other parts cannot compensate at all).
ショート トライアルの超過確率は、基本的にフルレングスのトライアルと同じです。これは、損失スパイクが小さい場合 (他のパーツで補償できる場合)、および目標損失率がゼロより大きい場合 (そうでない場合は他のパーツでまったく補償できない場合) にのみ可能です。
Short Trials have a larger Exceed Probability than Full-Length Trials. This can only be possible for a non-zero Goal Loss Ratio, for example, if the SUT needs to "warm up" to the best performance within each Trial, which is not commonly seen in practice.
短いトライアルでは、全長のトライアルよりも超過確率が高くなります。これは、たとえば、SUT が各トライアル内で最高のパフォーマンスに「ウォームアップ」する必要がある場合など、目標損失率がゼロでない場合にのみ可能ですが、これは実際にはあまり見られません。
This document has no IANA actions.
この文書には IANA のアクションはありません。
Benchmarking activities as described in this document are limited to the technology characterization of a DUT/SUT using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
このドキュメントで説明されているベンチマーク活動は、専用のアドレス空間と上記のセクションで指定された制約を備えた、実験室環境で制御された刺激を使用した DUT/SUT の技術特性評価に限定されます。
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 an "opaque" basis, relying solely on measurements observable external to the DUT/SUT.
さらに、ベンチマークは「不透明な」ベースで実行され、DUT/SUT の外部で観察可能な測定値のみに依存します。
The DUT/SUT SHOULD NOT include features that serve only to boost benchmark scores, such as a dedicated "fast-track" test mode that is never used in normal operation.
DUT/SUT には、通常の動作では決して使用されない専用の「ファストトラック」テスト モードなど、ベンチマーク スコアを上げるためだけに役立つ機能を含めるべきではありません。
Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
DUT/SUT から生じるネットワーク セキュリティへの影響は、ラボと実稼働ネットワークで同一である必要があります。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242,
July 1991, <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>.
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, DOI 10.17487/RFC2285,
February 1998, <https://www.rfc-editor.org/info/rfc2285>.
[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>.
[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>.
[FDio-CSIT-MLRsearch]
"FD.io CSIT Test Methodology - MLRsearch", October 2023,
<https://csit.fd.io/cdocs/methodology/measurements/
data_plane_throughput/mlr_search/>.
[IEEE.802.3df]
IEEE, "IEEE Standard for Ethernet Amendment 9: Media
Access Control Parameters for 800 Gb/s and Physical Layers
and Management Parameters for 400 Gb/s and 800 Gb/s
Operation", March 2024,
<https://standards.ieee.org/ieee/802.3df/11107/>.
[Lencze-Kovacs-Shima]
Lencse, G., Kovács, Á., and K. Shima, "Gaming with the
Throughput and the Latency Benchmarking Measurement
Procedures of RFC 2544", International Journal of Advances
in Telecommunications, Electrotechnics, Signals and
Systems, vol. 9, no. 2, pp. 10-17,
DOI 10.11601/ijates.v9i2.288, June 2020,
<https://doi.org/10.11601/ijates.v9i2.288>.
[Lencze-Shima]
Lencse, G. and K. Shima, "An Upgrade to Benchmarking
Methodology for Network Interconnect Devices", Work in
Progress, Internet-Draft, draft-lencse-bmwg-rfc2544-bis-
00, 20 May 2020, <https://datatracker.ietf.org/doc/html/
draft-lencse-bmwg-rfc2544-bis-00>.
[Ott-Mathis-Semke-Mahdavi]
Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The
Macroscopic Behavior of the TCP Congestion Avoidance
Algorithm", ACM SIGCOMM Computer Communication Review,
vol. 27, no. 3, pp. 67-82, July 1997,
<https://www.cs.cornell.edu/people/egs/cornellonly/
syslunch/fall02/ott.pdf>.
[PyPI-MLRsearch]
Python Package Index, "MLRsearch 1.2.1", October 2023,
<https://pypi.org/project/MLRsearch/1.2.1/>.
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
Dugatkin, "IPv6 Benchmarking Methodology for Network
Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May
2008, <https://www.rfc-editor.org/info/rfc5180>.
[RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage,
"Framework for TCP Throughput Testing", RFC 6349,
DOI 10.17487/RFC6349, August 2011,
<https://www.rfc-editor.org/info/rfc6349>.
[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>.
[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking
Methodology for IPv6 Transition Technologies", RFC 8219,
DOI 10.17487/RFC8219, August 2017,
<https://www.rfc-editor.org/info/rfc8219>.
[TST009] ETSI, "Network Functions Virtualisation (NFV) Release 3;
Testing; Specification of Networking Benchmarks and
Measurement Methods for NFVI", ETSI GS NFV-TST 009 V3.4.1,
December 2020, <https://www.etsi.org/deliver/etsi_gs/NFV-
TST/001_099/009/03.04.01_60/gs_NFV-TST009v030401p.pdf>.
[Vassilev] Vassilev, V., "A YANG Data Model for Network Tester
Management", Work in Progress, Internet-Draft, draft-ietf-
bmwg-network-tester-cfg-17, 3 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-
network-tester-cfg-17>.
[Y.1564] ITU-T, "Ethernet service activation test methodology",
ITU-T Recommendation Y.1564, February 2016,
<https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-
Y.1564-201602-I!!PDF-E&type=items>.
This appendix specifies how to perform the Load Classification.
この付録では、負荷分類を実行する方法を説明します。
Any Load value can be classified, according to a given Search Goal.
特定の検索目標に従って、任意の負荷値を分類できます。
The algorithm uses (some subsets of) the set of all available Trial Results from Trials measured at a given Load at the end of the Search.
このアルゴリズムは、検索の最後に特定の負荷で測定されたトライアルからの利用可能なすべてのトライアル結果のセット (の一部) を使用します。
The block at the end of this appendix holds pseudocode that computes two values, stored in variables named optimistic_is_lower and pessimistic_is_lower.
この付録の最後のブロックには、2 つの値を計算する疑似コードが含まれており、optimistic_is_ lower および pessimistic_is_ lower という名前の変数に格納されます。
Although presented as pseudocode, the listing is syntactically valid Python and can be executed without modification.
疑似コードとして示されていますが、リストは構文的に有効な Python であり、変更せずに実行できます。
If values of both variables are computed to be true, the Load in question is classified as a Lower Bound according to the given Search Goal. If values of both variables are false, the Load is classified as an Upper Bound. Otherwise, the Load is classified as Undecided.
If values of both variables are computed to be true, the Load in question is classified as a Lower Bound according to the given Search Goal.If values of both variables are false, the Load is classified as an Upper Bound.それ以外の場合、ロードは未決定として分類されます。
Some variable names are shortened to fit expressions in one line. Namely, variables holding sum quantities end in "_s" instead of "_sum", and variables holding effective quantities start with "effect_" instead of "effective_".
一部の変数名は、式を 1 行に収めるために短縮されています。つまり、合計量を保持する変数は "_sum" ではなく "_s" で終わり、有効量を保持する変数は "Effective_" ではなく "effect_" で始まります。
The pseudocode expects the following variables to hold the following values:
疑似コードは、次の変数が次の値を保持することを想定しています。
* goal_duration_s: The Goal Duration Sum value of the given Search Goal.
* goal_duration_s: 指定された検索目標の目標期間の合計値。
* goal_exceed_ratio: The Goal Exceed Ratio value of the given Search Goal.
* goal_exceed_ratio: 指定された検索目標の目標超過率の値。
* full_length_low_loss_s: Sum of Trial Effective Durations across Trials with the Trial Duration at least equal to the Goal Final Trial Duration and with the Trial Loss Ratio not higher than the Goal Loss Ratio (across Full-Length Low-Loss Trials).
* full_length_low_loss_s: トライアル期間が目標最終トライアル期間以上であり、トライアル損失率が目標損失率以下であるトライアル全体のトライアル有効期間の合計 (全長低損失トライアル全体)。
* full_length_high_loss_s: Sum of Trial Effective Durations across Trials with the Trial Duration at least equal to the Goal Final Trial Duration and with the Trial Loss Ratio higher than the Goal Loss Ratio (across Full-Length High-Loss Trials).
* full_length_high_loss_s: トライアル期間が目標最終トライアル期間以上で、トライアル損失率が目標損失率より高いトライアル全体のトライアル有効期間の合計 (全長の高損失トライアル全体)。
* short_low_loss_s: Sum of Trial Effective Durations across Trials with the Trial Duration shorter than the Goal Final Trial Duration and with the Trial Loss Ratio not higher than the Goal Loss Ratio (across Short Low-Loss Trials).
* short_low_loss_s: トライアル期間が目標最終トライアル期間より短く、トライアル損失率が目標損失率以下であるトライアル全体のトライアル有効期間の合計 (短期低損失トライアル全体)。
* short_high_loss_s: Sum of Trial Effective Durations across Trials with the Trial Duration shorter than the Goal Final Trial Duration and with the Trial Loss Ratio higher than the Goal Loss Ratio (across Short High-Loss Trials).
* short_high_loss_s: トライアル期間が目標最終トライアル期間より短く、トライアル損失率が目標損失率より高いトライアル全体のトライアル有効期間の合計 (短期高損失トライアル全体)。
The code also works correctly when there are no Trial Results at the given Load.
このコードは、指定されたロードでトライアル結果がない場合にも正しく動作します。
exceed_coefficient = goal_exceed_ratio / (1.0 - goal_exceed_ratio)
balancing_s = short_low_loss_s * exceed_coefficient
positive_excess_s = max(0.0, short_high_loss_s - balancing_s)
effect_high_loss_s = full_length_high_loss_s + positive_excess_s
effect_full_length_s = full_length_low_loss_s + effect_high_loss_s
effect_whole_s = max(effect_full_length_s, goal_duration_s)
quantile_duration_s = effect_whole_s * goal_exceed_ratio
pessimistic_high_loss_s = effect_whole_s - full_length_low_loss_s
pessimistic_is_lower = pessimistic_high_loss_s <= quantile_duration_s
optimistic_is_lower = effect_high_loss_s <= quantile_duration_s
This section specifies an example of how to compute Conditional Throughput.
このセクションでは、条件付きスループットを計算する方法の例を説明します。
Any Load value can be used as the basis for the following computation, but only the Relevant Lower Bound (at the end of the Search) leads to the value called the Conditional Throughput for a given Search Goal.
任意の負荷値を次の計算の基礎として使用できますが、特定の検索目標の条件付きスループットと呼ばれる値につながるのは、関連する下限 (検索の最後) だけです。
The algorithm uses (some subsets of) the set of all available Trial Results from Trials measured at a given Load at the end of the Search.
このアルゴリズムは、検索の最後に特定の負荷で測定されたトライアルからの利用可能なすべてのトライアル結果のセット (の一部) を使用します。
The block at the end of this appendix holds pseudocode that computes a value stored as the conditional_throughput variable.
この付録の最後のブロックには、conditional_throughput 変数として格納される値を計算する疑似コードが含まれています。
Although presented as pseudocode, the listing is syntactically valid Python and can be executed without modification.
疑似コードとして示されていますが、リストは構文的に有効な Python であり、変更せずに実行できます。
Some variable names are shortened in order to fit expressions in one line. Namely, variables holding sum quantities end in "_s" instead of "_sum", and variables holding effective quantities start with "effect_" instead of "effective_".
一部の変数名は、式を 1 行に収めるために短縮されています。つまり、合計量を保持する変数は "_sum" ではなく "_s" で終わり、有効量を保持する変数は "Effective_" ではなく "effect_" で始まります。
The pseudocode expects the following variables to hold the following values:
疑似コードは、次の変数が次の値を保持することを想定しています。
* goal_duration_s: The Goal Duration Sum value of the given Search Goal.
* goal_duration_s: 指定された検索目標の目標期間の合計値。
* goal_exceed_ratio: The Goal Exceed Ratio value of the given Search Goal.
* goal_exceed_ratio: 指定された検索目標の目標超過率の値。
* full_length_low_loss_s: Sum of Trial Effective Durations across Trials with the Trial Duration at least equal to the Goal Final Trial Duration and with the Trial Loss Ratio not higher than the Goal Loss Ratio (across Full-Length Low-Loss Trials).
* full_length_low_loss_s: トライアル期間が目標最終トライアル期間以上であり、トライアル損失率が目標損失率以下であるトライアル全体のトライアル有効期間の合計 (全長低損失トライアル全体)。
* full_length_high_loss_s: Sum of Trial Effective Durations across Trials with the Trial Duration at least equal to the Goal Final Trial Duration and with the Trial Loss Ratio higher than the Goal Loss Ratio (across Full-Length High-Loss Trials).
* full_length_high_loss_s: トライアル期間が目標最終トライアル期間以上で、トライアル損失率が目標損失率より高いトライアル全体のトライアル有効期間の合計 (全長の高損失トライアル全体)。
* full_length_trials: An iterable of all Trial Results from Trials with the Trial Duration at least equal to the Goal Final Trial Duration (all Full-Length Trials), sorted by increasing the Trial Loss Ratio. One item trial is a composite with the following two attributes available:
* full_length_trials: トライアル期間が目標の最終トライアル期間と少なくとも等しいトライアル (すべての全長トライアル) からのすべてのトライアル結果の反復可能であり、トライアル損失率を増加させることによって並べ替えられます。1 つのアイテムのトライアルは、次の 2 つの属性を使用できる複合物です。
- trial.loss_ratio: The Trial Loss Ratio as measured for this Trial.
- Trial.loss_ratio: このトライアルで測定されたトライアル損失率。
- trial.effect_duration: The Trial Effective Duration of this Trial.
- Trial.effect_duration: このトライアルのトライアル有効期間。
The code works correctly only when there is at least one Trial Result measured at a given Load.
コードは、特定の負荷で測定された試行結果が少なくとも 1 つある場合にのみ正しく機能します。
full_length_s = full_length_low_loss_s + full_length_high_loss_s
whole_s = max(goal_duration_s, full_length_s)
remaining = whole_s * (1.0 - goal_exceed_ratio)
quantile_loss_ratio = None
for trial in full_length_trials:
if quantile_loss_ratio is None or remaining > 0.0:
quantile_loss_ratio = trial.loss_ratio
remaining -= trial.effect_duration
else:
break
else:
if remaining > 0.0:
quantile_loss_ratio = 1.0
conditional_throughput = intended_load * (1.0 - quantile_loss_ratio)
The following example Search is related to one hypothetical run of the Search part of the MLRsearch test procedure that has been started with multiple Search Goals. Several points in time are chosen, to show how the logic works, with specific sets of Trial Results available. The Trial Results themselves are not very realistic, as the intention is to show several corner cases of the logic.
次の検索例は、複数の検索目標で開始された MLRsearch テスト プロシージャの検索部分の 1 つの仮想実行に関連しています。ロジックがどのように機能するかを示すために、いくつかの時点が選択され、特定のトライアル結果セットが利用可能になります。ロジックのコーナーケースをいくつか示すことが目的であるため、トライアル結果自体はあまり現実的ではありません。
In all Trials, the Trial Effective Duration is equal to the Trial Duration.
すべてのトライアルで、トライアルの有効期間はトライアル期間と同じです。
Only one Load is in focus, its value is one million frames per second (1 Mfps). Trial Results at other Loads are not mentioned, as the parts of logic present here do not depend on those. In practice, Trial Results at other Load values would be present, e.g., MLRsearch will look for a Lower Bound smaller than any Upper Bound found.
1 つのロードのみがフォーカスされており、その値は 100 万フレーム/秒 (1 Mfps) です。他のロードでの試行結果については、ここに存在するロジックの部分がそれらに依存しないため、言及されていません。実際には、他の負荷値での試行結果も存在します。たとえば、MLRsearch は、見つかった上限よりも小さい下限を探します。
At any given moment, exactly one Search Goal is designated as in focus. This designation affects only the Trial Duration chosen for new Trials; it does not alter the rest of the decision logic.
常に 1 つの検索目標がフォーカスされるように指定されます。この指定は、新しいトライアルに対して選択されたトライアル期間にのみ影響します。残りの決定ロジックは変更されません。
An MLRsearch implementation is free to evaluate several Search Goals simultaneously, the _focus_ mechanism is optional and appears here only to show that a Load can still be classified against Search Goals that are not currently in focus.
MLRsearch 実装では、複数の検索目標を同時に評価できます。_focus_ メカニズムはオプションであり、現在フォーカスされていない検索目標に対してロードを分類できることを示すためにのみここに表示されます。
The following four Search Goal instances are selected for the example Search. Each Search Goal has a readable name and dense code; the code is useful to show Search Goal attribute values.
検索例では、次の 4 つの検索目標インスタンスが選択されています。各検索目標には読みやすい名前と緻密なコードが付いています。このコードは、検索目標の属性値を表示するのに役立ちます。
As the variable _exceed coefficient_ does not depend on Trial Results, it is also precomputed here.
変数 _exceed 係数_ は試行結果に依存しないため、ここでも事前に計算されます。
Goal 1:
目標 1:
name:
名前：
RFC2544
RFC2544
Goal Final Trial Duration:
目標の最終トライアル期間:
60s
60年代
Goal Duration Sum:
目標期間の合計:
60s
60年代
Goal Loss Ratio:
失点率:
0%
0%
Goal Exceed Ratio:
目標超過率:
0%
0%
exceed coefficient:
超過係数:
0% / (100% / 0%) = 0.0
0% / (100% / 0%) = 0.0
code:
コード：
60f60d0l0e
60f60d0l0e
Goal 2:
目標 2:
name:
名前：
TST009
TST009
Goal Final Trial Duration:
目標の最終トライアル期間:
60s
60年代
Goal Duration Sum:
目標期間の合計:
120s
120秒
Goal Loss Ratio:
失点率:
0%
0%
Goal Exceed Ratio:
目標超過率:
50%
50%
exceed coefficient:
超過係数:
50% / (100% - 50%) = 1.0
50% / (100% - 50%) = 1.0
code:
コード：
60f120d0l50e
60f120d0l50e
Goal 3:
目標 3:
name:
名前：
1s final
決勝1秒
Goal Final Trial Duration:
目標の最終トライアル期間:
1s
1秒
Goal Duration Sum:
目標期間の合計:
120s
120秒
Goal Loss Ratio:
失点率:
0.5%
0.5%
Goal Exceed Ratio:
目標超過率:
50%
50%
exceed coefficient:
超過係数:
50% / (100% - 50%) = 1.0
50% / (100% - 50%) = 1.0
code:
コード：
1f120d.5l50e
1f120d.5l50e
Goal 4:
目標 4:
name:
名前：
20% exceed
20%超過
Goal Final Trial Duration:
目標の最終トライアル期間:
60s
60年代
Goal Duration Sum:
目標期間の合計:
60s
60年代
Goal Loss Ratio:
失点率:
0.5%
0.5%
Goal Exceed Ratio:
目標超過率:
20%
20%
exceed coefficient:
超過係数:
20% / (100% - 20%) = 0.25
20% / (100% - 20%) = 0.25
code:
コード：
60f60d0.5l20e
60f60d0.5l20e
The first two goals are important for compliance reasons; the other two cover less frequent cases.
最初の 2 つの目標は、コンプライアンス上の理由から重要です。他の 2 つは、頻度の低いケースをカバーしています。
The following six sets of Trial Results are selected for the example Search. The sets are defined as points in time, describing which Trial Results were added since the previous point.
検索例では、次の 6 つのトライアル結果セットが選択されています。セットは時点として定義され、前の時点以降にどのトライアル結果が追加されたかを記述します。
Each point has a readable name and dense code; the code is useful to show Trial Output attribute values and the number of times identical Trial Results were added.
各ポイントには読みやすい名前と緻密なコードが付いています。このコードは、トライアル出力の属性値と、同一のトライアル結果が追加された回数を表示するのに役立ちます。
Point 1:
ポイント1:
name:
名前：
first short good
最初の短い良い
goal in focus:
注目の目標:
1s final (1f120d.5l50e)
決勝 1 秒 (1f120d.5l50e)
added Trial Results:
トライアル結果を追加:
59 Trials, each 1 second and 0% loss
59 回の試行、各 1 秒、損失 0%
code:
コード：
59x1s0l
59x1秒0l
Point 2:
ポイント2:
name:
名前：
first short bad
最初の短い悪い
goal in focus:
注目の目標:
1s final (1f120d.5l50e)
決勝 1 秒 (1f120d.5l50e)
added Trial Result:
トライアル結果を追加:
one Trial, 1 second, 1% loss
1 回のトライアル、1 秒、1% の損失
code:
コード：
59x1s0l+1x1s1l
59x1秒0l+1x1秒1l
Point 3:
ポイント3:
name:
名前：
last short bad
最後の短い悪い
goal in focus:
注目の目標:
1s final (1f120d.5l50e)
決勝 1 秒 (1f120d.5l50e)
added Trial Results:
トライアル結果を追加:
59 Trials, 1 second each, 1% loss each
59 回の試行、各 1 秒、各 1% の損失
code:
コード：
59x1s0l+60x1s1l
59x1秒0l+60x1秒1l
Point 4:
ポイント4:
name:
名前：
last short good
ラストショート良かった
goal in focus:
注目の目標:
1s final (1f120d.5l50e)
決勝 1 秒 (1f120d.5l50e)
added Trial Results:
トライアル結果を追加:
one Trial, 1 second, 0% loss
1 回のトライアル、1 秒、損失 0%
code:
コード：
60x1s0l+60x1s1l
60x1秒0l+60x1秒1l
Point 5:
ポイント5:
name:
名前：
first long bad
最初は長い間悪い
goal in focus:
注目の目標:
TST009 (60f120d0l50e)
TST009 (60f120d0l50e)
added Trial Results:
トライアル結果を追加:
one Trial, 60 seconds, 0.1% loss
1 回のトライアル、60 秒、0.1% の損失
code:
コード：
60x1s0l+60x1s1l+1x60s.1l
60x1s0l+60x1s1l+1x60s.1l
Point 6:
ポイント6:
name:
名前：
first long good
最初は長い間良かった
goal in focus:
注目の目標:
TST009 (60f120d0l50e)
TST009 (60f120d0l50e)
added Trial Results:
トライアル結果を追加:
one Trial, 60 seconds, 0% loss
1 回のトライアル、60 秒、損失 0%
code:
コード：
60x1s0l+60x1s1l+1x60s.1l+1x60s0l
60x1秒0l+60x1秒1l+1x60秒.1l+1x60秒0l
Comments on point in time naming:
特定時点の命名に関するコメント:
* When a name contains "short", it means the added Trial had a Trial Duration of 1 second, which is a Short Trial for 3 of the Search Goals, but it is a Full-Length Trial for the "1s final" goal.
* 名前に「短い」が含まれている場合、追加されたトライアルのトライアル期間が 1 秒であり、検索目標のうち 3 つについては短いトライアルですが、「最終 1 秒」のゴールについては全長トライアルであることを意味します。
* Similarly, when a name contains "long", it means the added Trial had a Trial Duration of 60 seconds, which is a Full-Length Trial for 3 Search Goals but a Long Trial for the "1s final" goal.
* 同様に、名前に「long」が含まれている場合、追加されたトライアルのトライアル期間が 60 秒であることを意味します。これは、3 つの検索ゴールについては全長トライアルですが、「最終 1 秒」ゴールについてはロング トライアルです。
* When a name contains "good", it means the added Trial is a Low-Loss Trial for all the Search Goals.
* 名前に「good」が含まれている場合、追加されたトライアルがすべての検索目標に対して低損失トライアルであることを意味します。
* When a name contains "short bad", it means the added Trial is a High-Loss Trial for all the Search Goals.
* 名前に「short bad」が含まれている場合、追加されたトライアルがすべての検索目標に対して高損失トライアルであることを意味します。
* When a name contains "long bad", it means the added Trial is a High-Loss Trial for goals "RFC2544" and "TST009", but it is a Low-Loss Trial for the two other Search Goals.
* 名前に「long bad」が含まれている場合、追加されたトライアルは、目標「RFC2544」および「TST009」については高損失トライアルであるが、他の 2 つの検索目標については低損失トライアルであることを意味します。
This section shows how Load Classification Logic is applied by listing all temporary values at the specific time point.
このセクションでは、特定の時点でのすべての一時値をリストすることによって、負荷分類ロジックがどのように適用されるかを示します。
This is the "first short good" point. The code for available Trial Results is: 59x1s0l.
これが「最初のショートグッド」のポイントです。利用可能なトライアル結果のコードは 59x1s0l です。
+==============+==========+============+============+=============+
|Goal name |RFC2544 |TST009 |1s final |20% exceed |
+==============+==========+============+============+=============+
|Goal code |60f60d0l0e|60f120d0l50e|1f120d.5l50e|60f60d0.5l20e|
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |0s |0s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |59s |0s |
|Low-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short High- |0s |0s |0s |0s |
|Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short Low-Loss|59s |59s |0s |59s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Balancing sum |0s |59s |0s |14.75s |
+--------------+----------+------------+------------+-------------+
|Excess sum |0s |-59s |0s |-14.75s |
+--------------+----------+------------+------------+-------------+
|Positive |0s |0s |0s |0s |
|excess sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |0s |0s |0s |0s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective full|0s |0s |59s |0s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |60s |120s |120s |60s |
|whole sum | | | | |
+--------------+----------+------------+------------+-------------+
|Missing sum |60s |120s |61s |60s |
+--------------+----------+------------+------------+-------------+
|Pessimistic |60s |120s |61s |60s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Optimistic |0% |0% |0% |0% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Pessimistic |100% |100% |50.833% |100% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Classification|Undecided |Undecided |Undecided |Undecided |
|result | | | | |
+--------------+----------+------------+------------+-------------+
Table 1
This is the last point in time where all Search Goals have this Load as Undecided.
これは、すべての検索目標でこのロードが「未決定」になっている最後の時点です。
This is the "first short bad" point. The code for available Trial Results is: 59x1s0l+1x1s1l.
これが「最初のショートダメ」ポイントです。利用可能なトライアル結果のコードは 59x1s0l+1x1s1l です。
+==============+==========+============+============+=============+
|Goal name |RFC2544 |TST009 |1s final |20% exceed |
+==============+==========+============+============+=============+
|Goal code |60f60d0l0e|60f120d0l50e|1f120d.5l50e|60f60d0.5l20e|
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |1s |0s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |59s |0s |
|Low-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short High- |1s |1s |0s |1s |
|Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short Low-Loss|59s |59s |0s |59s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Balancing sum |0s |59s |0s |14.75s |
+--------------+----------+------------+------------+-------------+
|Excess sum |1s |-58s |0s |-13.75s |
+--------------+----------+------------+------------+-------------+
|Positive |1s |0s |0s |0s |
|excess sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |1s |0s |1s |0s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective full|1s |0s |60s |0s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |60s |120s |120s |60s |
|whole sum | | | | |
+--------------+----------+------------+------------+-------------+
|Missing sum |59s |120s |60s |60s |
+--------------+----------+------------+------------+-------------+
|Pessimistic |60s |120s |61s |60s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Optimistic |1.667% |0% |0.833% |0% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Pessimistic |100% |100% |50.833% |100% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Classification|Upper |Undecided |Undecided |Undecided |
|result |Bound | | | |
+--------------+----------+------------+------------+-------------+
Table 2
Due to zero Goal Loss Ratio, the "RFC2544" goal must have a mild or strong increase of Exceed Probability, so the one lossy Trial would be lossy even if measured at a 60-second Trial Duration. Due to zero Goal Exceed Ratio, one High-Loss Trial is enough to preclude this Load from becoming a Lower Bound for the "RFC2544" goal. That is why this Load is classified as an Upper Bound for the "RFC2544" goal this early.
目標損失率がゼロであるため、「RFC2544」の目標では超過確率が軽度または大幅に増加する必要があるため、1 つの損失のあるトライアルは、60 秒のトライアル期間で測定した場合でも損失が大きくなります。目標超過率がゼロであるため、このロードが「RFC2544」目標の下限になるのを防ぐには、1 回の高損失トライアルで十分です。このため、このロードは早い段階で「RFC2544」目標の上限として分類されています。
This is an example of how significant time can be saved, compared to 60-second Trials.
これは、60 秒のトライアルと比較して、時間を大幅に節約できる例です。
This is the "last short bad" point. The code for available Trial Results is: 59x1s0l+60x1s1l.
ここが「最後の短所」ポイントです。利用可能なトライアル結果のコードは 59x1s0l+60x1s1l です。
+==============+==========+============+============+=============+
|Goal name |RFC2544 |TST009 |1s final |20% exceed |
+==============+==========+============+============+=============+
|Goal code |60f60d0l0e|60f120d0l50e|1f120d.5l50e|60f60d0.5l20e|
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |60s |0s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |59s |0s |
|Low-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short High- |60s |60s |0s |60s |
|Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short Low-Loss|59s |59s |0s |59s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Balancing sum |0s |59s |0s |14.75s |
+--------------+----------+------------+------------+-------------+
|Excess sum |60s |1s |0s |45.25s |
+--------------+----------+------------+------------+-------------+
|Positive |60s |1s |0s |45.25s |
|excess sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |60s |1s |60s |45.25s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective full|60s |1s |119s |45.25s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |60s |120s |120s |60s |
|whole sum | | | | |
+--------------+----------+------------+------------+-------------+
|Missing sum |0s |119s |1s |14.75s |
+--------------+----------+------------+------------+-------------+
|Pessimistic |60s |120s |61s |60s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Optimistic |100% |0.833% |50% |75.417% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Pessimistic |100% |100% |50.833% |100% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Classification|Upper |Undecided |Undecided |Upper Bound |
|result |Bound | | | |
+--------------+----------+------------+------------+-------------+
Table 3
This is the last point for the "1s final" goal to have this Load still Undecided. Only one 1-second Trial is missing within the 120-second Goal Duration Sum, but its Trial Result will decide the classification result.
これは、このロードがまだ未定である「1 秒決勝」の目標の最後のポイントです。120 秒の目標期間合計内で 1 秒のトライアルが 1 つだけ欠落していますが、そのトライアル結果によって分類結果が決まります。
The "20% exceed" goal started to classify this Load as an Upper Bound somewhere between points 2 and 3.
「20% を超える」目標は、この負荷をポイント 2 とポイント 3 の間の上限として分類し始めました。
This is the "last short good" point. The code for available Trial Results is: 60x1s0l+60x1s1l.
ここが「最後のショートグッド」ポイントです。利用可能なトライアル結果のコードは 60x1s0l+60x1s1l です。
+==============+==========+============+============+=============+
|Goal name |RFC2544 |TST009 |1s final |20% exceed |
+==============+==========+============+============+=============+
|Goal code |60f60d0l0e|60f120d0l50e|1f120d.5l50e|60f60d0.5l20e|
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |60s |0s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |60s |0s |
|Low-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short High- |60s |60s |0s |60s |
|Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short Low-Loss|60s |60s |0s |60s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Balancing sum |0s |60s |0s |15s |
+--------------+----------+------------+------------+-------------+
|Excess sum |60s |0s |0s |45s |
+--------------+----------+------------+------------+-------------+
|Positive |60s |0s |0s |45s |
|excess sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |60s |0s |60s |45s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective full|60s |0s |120s |45s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |60s |120s |120s |60s |
|whole sum | | | | |
+--------------+----------+------------+------------+-------------+
|Missing sum |0s |120s |0s |15s |
+--------------+----------+------------+------------+-------------+
|Pessimistic |60s |120s |60s |60s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Optimistic |100% |0% |50% |75% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Pessimistic |100% |100% |50% |100% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Classification|Upper |Undecided |Lower Bound |Upper Bound |
|result |Bound | | | |
+--------------+----------+------------+------------+-------------+
Table 4
The one missing Trial for "1s final" was Low-Loss; half of Trial Results are Low-Loss, which exactly matches the 50% Goal Exceed Ratio. This shows time savings are not guaranteed.
「1秒決勝」のトライアルで欠けていたのは低損失でした。トライアル結果の半分は低損失であり、50% の目標超過率に正確に一致します。これは、時間の節約が保証されていないことを示しています。
This is the "first long bad" point. The code for available Trial Results is: 60x1s0l+60x1s1l+1x60s.1l.
これが「最初の長い悪い」ポイントです。利用可能なトライアル結果のコードは、60x1s0l+60x1s1l+1x60s.1l です。
+==============+==========+============+============+=============+
|Goal name |RFC2544 |TST009 |1s final |20% exceed |
+==============+==========+============+============+=============+
|Goal code |60f60d0l0e|60f120d0l50e|1f120d.5l50e|60f60d0.5l20e|
+--------------+----------+------------+------------+-------------+
|Full-Length |60s |60s |60s |0s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Full-Length |0s |0s |120s |60s |
|Low-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short High- |60s |60s |0s |60s |
|Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short Low-Loss|60s |60s |0s |60s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Balancing sum |0s |60s |0s |15s |
+--------------+----------+------------+------------+-------------+
|Excess sum |60s |0s |0s |45s |
+--------------+----------+------------+------------+-------------+
|Positive |60s |0s |0s |45s |
|excess sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |120s |60s |60s |45s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective full|120s |60s |180s |105s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |120s |120s |180s |105s |
|whole sum | | | | |
+--------------+----------+------------+------------+-------------+
|Missing sum |0s |60s |0s |0s |
+--------------+----------+------------+------------+-------------+
|Pessimistic |120s |120s |60s |45s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Optimistic |100% |50% |33.333% |42.857% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Pessimistic |100% |100% |33.333% |42.857% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Classification|Upper |Undecided |Lower Bound |Lower Bound |
|result |Bound | | | |
+--------------+----------+------------+------------+-------------+
Table 5
As designed for the "TST009" goal, one Full-Length High-Loss Trial can be tolerated. 120s worth of 1-second Trials is not useful, as this is allowed when Exceed Probability does not depend on Trial Duration. As the Goal Loss Ratio is zero, it is not possible for 60-second Trials to compensate for losses seen in 1-second Trial Results. But Load Classification Logic does not have that knowledge hardcoded, so the optimistic exceed ratio is still only 50%.
「TST009」目標に合わせて設計されているため、1 回の全長高損失トライアルが許容されます。120 秒相当の 1 秒トライアルは、超過確率がトライアル期間に依存しない場合に許可されるため、役に立ちません。ゴール損失率はゼロであるため、60 秒トライアルでは 1 秒トライアル結果で見られる損失を補うことはできません。ただし、負荷分類ロジックにはその知識がハードコードされていないため、楽観的な超過率は依然として 50% にすぎません。
But the 0.1% Trial Loss Ratio is lower than the "20% exceed" Goal Loss Ratio, so this unexpected Full-Length Low-Loss Trial changed the classification result of this Load to Lower Bound.
しかし、0.1% のトライアル損失率は「20% を超える」目標損失率よりも低いため、この予期せぬ全長低損失トライアルにより、この負荷の分類結果が下限に変更されました。
This is the "first long good" point. The code for available Trial Results is: 60x1s0l+60x1s1l+1x60s.1l+1x60s0l.
これが「最初のロンググッド」ポイントです。利用可能なトライアル結果のコードは、60x1s0l+60x1s1l+1x60s.1l+1x60s0l です。
+==============+==========+============+============+=============+
|Goal name |RFC2544 |TST009 |1s final |20% exceed |
+==============+==========+============+============+=============+
|Goal code |60f60d0l0e|60f120d0l50e|1f120d.5l50e|60f60d0.5l20e|
+--------------+----------+------------+------------+-------------+
|Full-Length |60s |60s |60s |0s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Full-Length |60s |60s |180s |120s |
|Low-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short High- |60s |60s |0s |60s |
|Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Short Low-Loss|60s |60s |0s |60s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Balancing sum |0s |60s |0s |15s |
+--------------+----------+------------+------------+-------------+
|Excess sum |60s |0s |0s |45s |
+--------------+----------+------------+------------+-------------+
|Positive |60s |0s |0s |45s |
|excess sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |120s |60s |60s |45s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective full|180s |120s |240s |165s |
|sum | | | | |
+--------------+----------+------------+------------+-------------+
|Effective |180s |120s |240s |165s |
|whole sum | | | | |
+--------------+----------+------------+------------+-------------+
|Missing sum |0s |0s |0s |0s |
+--------------+----------+------------+------------+-------------+
|Pessimistic |120s |60s |60s |45s |
|High-Loss sum | | | | |
+--------------+----------+------------+------------+-------------+
|Optimistic |66.667% |50% |25% |27.273% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Pessimistic |66.667% |50% |25% |27.273% |
|exceed ratio | | | | |
+--------------+----------+------------+------------+-------------+
|Classification|Upper |Lower Bound |Lower Bound |Lower Bound |
|result |Bound | | | |
+--------------+----------+------------+------------+-------------+
Table 6
This is the Low-Loss Trial the "TST009" goal was waiting for. This Load is now classified for all Search Goals; the Search may end. Or more realistically, it can focus on larger Loads only, as the three Search Goals will want an Upper Bound (unless this Load is Max Load).
これは「TST009」の目標が待っていた低損失トライアルです。このロードはすべての検索目標に対して分類されるようになりました。検索が終了する場合があります。または、より現実的には、3 つの検索目標には上限が必要となるため (この負荷が最大負荷でない限り)、より大きな負荷のみに焦点を当てることができます。
At the end of this hypothetical Search, the "RFC2544" goal labels the Load as an Upper Bound, making it ineligible for Conditional Throughput computation. By contrast, the other three Search Goals treat the same Load as a Lower Bound; if it is also accepted as their Relevant Lower Bound, Conditional Throughput values can be computed for each of them.
この仮説的な検索の最後に、「RFC2544」目標によって負荷が上限としてラベル付けされ、条件付きスループットの計算の対象外になります。対照的に、他の 3 つの検索目標は同じ負荷を下限として扱います。関連する下限としても受け入れられる場合、条件付きスループット値をそれぞれの条件付きスループット値として計算できます。
(The Load under discussion is one million frames per second.)
(議論中の負荷は 1 秒あたり 100 万フレームです。)
The Conditional Throughput is computed from a sorted list of Full-Length Trial Results. As the "TST009" Goal Final Trial Duration is 60 seconds, only two of 122 Trials are considered Full-Length Trials. One has a Trial Loss Ratio of 0%, the other of 0.1%.
条件付きスループットは、全長トライアル結果のソートされたリストから計算されます。「TST009」の目標の最終トライアル期間は 60 秒であるため、122 トライアルのうち 2 つだけが全長トライアルとみなされます。1 つは試行損失率が 0% で、もう 1 つは 0.1% です。
* Full-Length High-Loss sum is 60 seconds.
* 全長の高損失の合計は 60 秒です。
* Full-Length Low-Loss sum is 60 seconds.
* フルレングスの低損失合計は 60 秒です。
* Full-Length sum is 120 seconds.
* 全長合計は 120 秒です。
* Subceed ratio is 50%.
* サブシード率は50％です。
* Remaining sum is initially 0.5x12s = 60 seconds.
* 残りの合計は最初は 0.5x12s = 60 秒です。
* Current loss ratio is initially 100%.
* 現在の損失率は最初は 100% です。
* For first Trial Result (duration 60s, loss 0%):
* 最初のトライアル結果 (期間 60 秒、損失 0%):
- Remaining sum is larger than zero, not exiting the loop.
- 残りの合計がゼロより大きく、ループを抜けていません。
- Set current loss ratio to this Trial's Trial Loss Ratio, which is 0%.
- 現在の損失率をこのトライアルのトライアル損失率 (0%) に設定します。
- Decrease the remaining sum by this Trial's Trial Effective Duration.
- 残りの合計をこのトライアルのトライアル有効期間だけ減算します。
- New remaining sum is 60s - 60s = 0s.
- 新しい残りの合計は 60 秒 - 60 秒 = 0 秒です。
* For second Trial Result (duration 60s, loss 0.1%):
* 2 回目のトライアル結果 (期間 60 秒、損失 0.1%):
- Remaining sum is not larger than zero, exiting the loop.
- 残りの合計はゼロ以下なので、ループを終了します。
* Current loss ratio was most recently set to 0%.
* 現在の損失率は直近で 0% に設定されました。
* Current forwarding ratio is one minus the current loss ratio, so 100%.
* 現在の転送率は 1 から現在の損失率を引いたものなので 100% になります。
* Conditional Throughput is the current forwarding ratio multiplied by the Load value.
* 条件付きスループットは、現在の転送率に負荷値を乗算したものです。
* Conditional Throughput is one million frames per second.
* 条件付きスループットは 1 秒あたり 100 万フレームです。
The "1s final" has a Goal Final Trial Duration of 1 second, so all 122 Trial Results are considered Full-Length Trials. They are ordered like this:
「1 秒決勝」のゴール最終トライアル期間は 1 秒であるため、122 のトライアル結果すべてが全長トライアルとみなされます。それらは次のように順序付けされます。
* 60 1-second 0% loss Trials,
* 1秒0%損失トライアル60回、
* 1 60-second 0% loss Trial,
* 1 60 秒 0% 損失トライアル、
* 1 60-second 0.1% loss Trial, and
* 1 60 秒 0.1% 損失トライアル、および
* 60 1-second 1% loss Trials.
* 1秒1%損失のトライアルを60回。
The Conditional Throughput value does not depend on the order of 0% loss Trials.
条件付きスループットの値は、損失 0% のトライアルの順序には依存しません。
* Full-Length High-Loss sum is 60 seconds.
* 全長の高損失の合計は 60 秒です。
* Full-Length Low-Loss sum is 180 seconds.
* 全長の低損失合計は 180 秒です。
* Full-Length sum is 240 seconds.
* 全長合計は 240 秒です。
* Subceed ratio is 50%.
* サブシード率は50％です。
* Remaining sum is initially 0.5x240s = 120 seconds.
* 残りの合計は最初は 0.5x240s = 120 秒です。
* Current loss ratio is initially 100%.
* 現在の損失率は最初は 100% です。
* For first 61 Trial Results (duration varies, loss 0%):
* 最初の 61 件のトライアル結果 (期間はさまざま、損失 0%):
- Remaining sum is larger than zero, not exiting the loop.
- 残りの合計がゼロより大きく、ループを抜けていません。
- Set current loss ratio to this Trial's Trial Loss Ratio, which is 0%.
- 現在の損失率をこのトライアルのトライアル損失率 (0%) に設定します。
- Decrease the remaining sum by this Trial's Trial Effective Duration.
- 残りの合計をこのトライアルのトライアル有効期間だけ減算します。
- New remaining sum varies.
- 新しい残額は異なります。
* After 61 Trials, duration of 60x1s + 1x60s has been subtracted from 120s, leaving 0s.
* 61 回のトライアルの後、60x1 秒 + 1x60 秒の期間が 120 秒から減算され、0 秒が残ります。
* For 62nd Trial Result (duration 60s, loss 0.1%):
* 62 回目のトライアル結果 (期間 60 秒、損失 0.1%):
- Remaining sum is not larger than zero, exiting the loop.
- 残りの合計はゼロ以下なので、ループを終了します。
* Current loss ratio was most recently set to 0%.
* 現在の損失率は直近で 0% に設定されました。
* Current forwarding ratio is one minus the current loss ratio, so 100%.
* 現在の転送率は 1 から現在の損失率を引いたものなので 100% になります。
* Conditional Throughput is the current forwarding ratio multiplied by the Load value.
* 条件付きスループットは、現在の転送率に負荷値を乗算したものです。
* Conditional Throughput is one million frames per second.
* 条件付きスループットは 1 秒あたり 100 万フレームです。
The Conditional Throughput is computed from a sorted list of Full-Length Trial Results. As "20% exceed" Goal Final Trial Duration is 60 seconds, only two of 122 Trials are considered Full-Length Trials. One has a Trial Loss Ratio of 0%, the other of 0.1%.
条件付きスループットは、全長トライアル結果のソートされたリストから計算されます。「20% を超える」目標の最終トライアル期間は 60 秒であるため、122 トライアルのうち 2 つだけが全長トライアルとみなされます。1 つは試行損失率が 0% で、もう 1 つは 0.1% です。
* Full-Length High-Loss sum is 60 seconds.
* 全長の高損失の合計は 60 秒です。
* Full-Length Low-Loss sum is 60 seconds.
* フルレングスの低損失合計は 60 秒です。
* Full-Length sum is 120 seconds.
* 全長合計は 120 秒です。
* Subceed ratio is 80%.
* サブシード率は80％。
* Remaining sum is initially 0.8x120s = 96 seconds.
* 残りの合計は最初は 0.8x120s = 96 秒です。
* Current loss ratio is initially 100%.
* 現在の損失率は最初は 100% です。
* For first Trial Result (duration 60s, loss 0%):
* 最初のトライアル結果 (期間 60 秒、損失 0%):
- Remaining sum is larger than zero, not exiting the loop.
- 残りの合計がゼロより大きく、ループを抜けていません。
- Set current loss ratio to this Trial's Trial Loss Ratio, which is 0%.
- 現在の損失率をこのトライアルのトライアル損失率 (0%) に設定します。
- Decrease the remaining sum by this Trial's Trial Effective Duration.
- 残りの合計をこのトライアルのトライアル有効期間だけ減算します。
- New remaining sum is 96s - 60s = 36s.
- 新しい残りの合計は 96 秒 - 60 秒 = 36 秒です。
* For second Trial Result (duration 60s, loss 0.1%):
* 2 回目のトライアル結果 (期間 60 秒、損失 0.1%):
- Remaining sum is larger than zero, not exiting the loop.
- 残りの合計がゼロより大きく、ループを抜けていません。
- Set current loss ratio to this Trial's Trial Loss Ratio, which is 0.1%.
- 現在の損失率をこのトライアルのトライアル損失率 (0.1%) に設定します。
- Decrease the remaining sum by this Trial's Trial Effective Duration.
- 残りの合計をこのトライアルのトライアル有効期間だけ減算します。
- New remaining sum is 36s - 60s = -24s.
- 新しい残りの合計は 36 秒 - 60 秒 = -24 秒です。
* No more Trials (and remaining sum is not larger than zero), exiting loop.
* これ以上トライアルは行わず (残りの合計はゼロ以下)、ループを終了します。
* Current loss ratio was most recently set to 0.1%.
* 現在の損失率は直近では 0.1% に設定されました。
* Current forwarding ratio is one minus the current loss ratio, so 99.9%.
* 現在の転送率は、1 から現在の損失率を引いたものですので、99.9% になります。
* Conditional Throughput is the current forwarding ratio multiplied by the Load value.
* 条件付きスループットは、現在の転送率に負荷値を乗算したものです。
* Conditional Throughput is 999 thousand frames per second.
* 条件付きスループットは 999,000 フレーム/秒です。
Due to a stricter Goal Exceed Ratio, this Conditional Throughput is smaller than Conditional Throughput of the other two Search Goals.
より厳格な目標超過率のため、この条件付きスループットは他の 2 つの検索目標の条件付きスループットよりも小さくなります。
Special wholehearted gratitude and thanks to the late Al Morton for his thorough reviews filled with very specific feedback and constructive guidelines. Thank you Al for the close collaboration over the years, your mentorship, and your continuous unwavering encouragement full of empathy and an energizing positive attitude. Al, you are dearly missed.
非常に具体的なフィードバックと建設的なガイドラインに満ちた徹底的なレビューをしてくれた故アル・モートン氏に心からの感謝を捧げます。アル、長年にわたる緊密な協力、指導、そして共感と活力に満ちた前向きな姿勢に満ちた絶え間ない励ましに感謝します。アル、あなたがいなくて寂しいです。
Thanks to Gábor Lencse, Giuseppe Fioccola, Carsten Rossenhövel, and BMWG contributors for good discussions and thorough reviews, guiding and helping us to improve the clarity and formality of this document.
Gábor Lencse 氏、Giuseppe Fioccola 氏、Carsten Rossenhövel 氏、および BMWG の寄稿者に感謝します。このドキュメントの明確さと形式性を向上させるために、優れた議論と徹底的なレビューを導き、支援していただきました。
Many thanks to the Linux Foundation FastData I/O (FD.io) project, specifically committers and contributors to the two core projects of FD.io: VPP and CSIT. It was there where the need for MLRsearch originally came up, and it was in FD.io CSIT labs where the first MLRsearch open-source code got prototyped and then over the years productized. Thanks also goes to Alec Hothan of the OPNFV NFVbench project for a thorough review and numerous useful comments and suggestions in the earlier draft versions of this document.
Linux Foundation FastData I/O (FD.io) プロジェクト、特に FD.io の 2 つのコア プロジェクトである VPP と CSIT のコミッターおよびコントリビューターに多大な感謝を申し上げます。MLRsearch の必要性が最初に浮上したのはそこであり、最初の MLRsearch オープンソース コードのプロトタイプが作成され、その後何年にもわたって製品化されたのは FD.io CSIT ラボでした。また、このドキュメントの初期の草案バージョンで徹底的なレビューと多数の有益なコメントと提案を提供してくれた OPNFV NFVbench プロジェクトの Alec Hothan にも感謝します。
We are equally indebted to Mohamed Boucadair for a very thorough and detailed AD review, for providing many good comments and suggestions, for helping us make this document complete.
私たちは、Mohamed Boucadair 氏にも同様に、非常に徹底的かつ詳細な AD レビューを行っていただき、多くの優れたコメントや提案を提供していただき、この文書を完成させるのに協力していただきました。
Our appreciation is also extended to Shawn Emery, Yoshifumi Nishida, David Dong, Nabeel Cocker, Lars Eggert, Jen Linkova, Mike Bishop, and Éric Vyncke for their reviews and valuable comments.
また、レビューと貴重なコメントを寄せてくださった Shawn Emery、西田佳史、David Dong、Nabeel Cocker、Lars Eggert、Jen Linkova、Mike Bishop、および Éric Vyncke にも感謝の意を表します。
Maciek Konstantynowicz
Cisco Systems
Email: mkonstan@cisco.com
Vratko Polak
Cisco Systems
Email: vrpolak@cisco.com