[要約] RFC 6576は、IPパフォーマンスメトリクス（IPPM）の標準進化テストに関するものであり、IPネットワークのパフォーマンス測定に関する新しいテスト方法を提案しています。このRFCの目的は、IPPMの標準化と進化を促進し、ネットワークのパフォーマンス測定の信頼性と一貫性を向上させることです。
Internet Engineering Task Force (IETF) R. Geib, Ed.
Request for Comments: 6576 Deutsche Telekom
BCP: 176 A. Morton
Category: Best Current Practice AT&T Labs
ISSN: 2070-1721 R. Fardid
Cariden Technologies
A. Steinmitz
Deutsche Telekom
March 2012
IP Performance Metrics (IPPM) Standard Advancement Testing
IPパフォーマンスメトリック（IPPM）標準アドバンスメントテスト
Abstract
概要
This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is an Internet Best Current Practice.
このドキュメントでは、パフォーマンスメトリックRFCの複数の独立したインスタンス化が仕様を同じ方法で実装しているかどうかを判断するためのテストを指定しています。これは、相互運用性と同等のパフォーマンスメトリックであり、標準トラックに沿ってRFCを進めるために必要です。メトリックRFCの異なる実装からの結果は、同じ基本的なネットワーク条件下で収集され、統計的方法を使用して比較されます。目標は、RFCメトリック自体の評価であり、その定義が実装者にとって明確で明確であり、したがってIETF標準トラックでの進歩の候補であるかどうかを決定します。このドキュメントは、インターネットの現在のベストプラクティスです。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6576.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6576で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. Basic Idea ......................................................5
3. Verification of Conformance to a Metric Specification ...........7
3.1. Tests of an Individual Implementation against a Metric
Specification ..............................................8
3.2. Test Setup Resulting in Identical Live Network
Testing Conditions .........................................9
3.3. Tests of Two or More Different Implementations
against a Metric Specification ............................15
3.4. Clock Synchronization .....................................16
3.5. Recommended Metric Verification Measurement Process .......17
3.6. Proposal to Determine an Equivalence Threshold for
Each Metric Evaluated .....................................20
4. Acknowledgements ...............................................21
5. Contributors ...................................................21
6. Security Considerations ........................................21
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................23
Appendix A. An Example on a One-Way Delay Metric Validation ......24
A.1. Compliance to Metric Specification Requirements ...........24
A.2. Examples Related to Statistical Tests for One-Way Delay ...25
Appendix B. Anderson-Darling K-sample Reference and 2 Sample
C++ Code .............................................27
Appendix C. Glossary .............................................36
The Internet Standards Process as updated by RFC 6410 [RFC6410]
specifies that widespread deployment and use is sufficient to show
interoperability as a condition for advancement to Internet Standard.
The previous requirement of interoperability tests prior to advancing
an RFC to the Standard maturity level specified in RFC 2026 [RFC2026]
and RFC 5657 [RFC5657] has been removed. While the modified
requirement is applicable to protocols, wide deployment of different
measurement systems does not prove that the implementations measure
metrics in a standard way. Section 5.3 of RFC 5657 [RFC5657]
explicitly mentions the special case of Standards that are not "on-
the-wire" protocols. While this special case is not explicitly
mentioned by RFC 6410 [RFC6410], the four criteria in Section 2.2 of
RFC 6410 [RFC6410] are augmented by this document for RFCs that
specify performance metrics. This document takes the position that
flexible metric definitions can be proven to be clear and unambiguous
through tests that compare the results from independent
implementations. It describes tests that infer whether metric
specifications are sufficient using a definition of metric
"interoperability": measuring equivalent results (in a statistical
sense) under the same network conditions. The document expands on
this problem and its solution.
In the case of a protocol specification, the notion of "interoperability" is reasonably intuitive -- the implementations must successfully "talk to each other", while exercising all features and options. To achieve interoperability, two implementors need to interpret the protocol specifications in equivalent ways. In the case of IP Performance Metrics (IPPM), this definition of interoperability is only useful for test and control protocols like the One-Way Active Measurement Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) [RFC5357].
プロトコル仕様の場合、「相互運用性」の概念はかなり直感的です。実装はすべての機能とオプションを実行しながら、正常に「互いに対話」する必要があります。相互運用性を実現するには、2人の実装者がプロトコル仕様を同等の方法で解釈する必要があります。 IPパフォーマンスメトリック（IPPM）の場合、この相互運用性の定義は、一方向アクティブ測定プロトコル（OWAMP）[RFC4656]や双方向アクティブ測定プロトコル（TWAMP）[RFC5357]などのテストおよび制御プロトコルにのみ役立ちます。 ]。
A metric specification RFC describes one or more metric definitions, methods of measurement, and a way to report the results of measurement. One example would be a way to test and report the one-way delay that data packets incur while being sent from one network location to another, using the One-Way Delay Metric.
メトリック仕様RFCは、1つ以上のメトリック定義、測定方法、および測定結果を報告する方法を記述しています。 1つの例は、一方向の遅延メトリックを使用して、データパケットがあるネットワークの場所から別の場所に送信されている間に発生する一方向の遅延をテストして報告する方法です。
In the case of metric specifications, the conditions that satisfy the "interoperability" requirement are less obvious, and there is a need for IETF agreement on practices to judge metric specification "interoperability" in the context of the IETF Standards Process. This memo provides methods that should be suitable to evaluate metric specifications for Standards Track advancement. The methods proposed here MAY be generally applicable to metric specification RFCs beyond those developed under the IPPM Framework [RFC2330].
メトリック仕様の場合、「相互運用性」要件を満たす条件はそれほど明白ではなく、IETF標準プロセスのコンテキストでメトリック仕様の「相互運用性」を判断するための慣行に関するIETFの合意が必要です。このメモは、スタンダードトラックアドバンスのメトリック仕様を評価するのに適した方法を提供します。ここで提案される方法は、IPPMフレームワーク[RFC2330]の下で開発されたものを超えて、メトリック仕様RFCに一般的に適用できます。
Since many implementations of IP metrics are embedded in measurement systems that do not interact with one another (they were built before OWAMP and TWAMP), the interoperability evaluation called for in the IETF Standards Process cannot be determined by observing that independent implementations interact properly for various protocol exchanges. Instead, verifying that different implementations give statistically equivalent results under controlled measurement conditions takes the place of interoperability observations. Even when evaluating OWAMP and TWAMP RFCs for Standards Track advancement, the methods described here are useful to evaluate the measurement results because their validity would not be ascertained in protocol interoperability testing.
IPメトリックの多くの実装は、相互に作用しない測定システムに組み込まれているため（OWAMPとTWAMPの前に構築されたものです）、IETF標準プロセスで要求される相互運用性評価は、独立した実装がさまざまなものに対して適切に相互作用することを観察することによって決定できません。プロトコル交換。代わりに、制御された測定条件下で異なる実装が統計的に同等の結果を与えることを確認することは、相互運用性の観察に代わるものです。スタンダードトラックアドバンスのOWAMPおよびTWAMP RFCを評価する場合でも、プロトコルの相互運用性テストでは妥当性が確認されないため、ここで説明する方法は測定結果を評価するのに役立ちます。
The Standards advancement process aims at producing confidence that the metric definitions and supporting material are clearly worded and unambiguous, or reveals ways in which the metric definitions can be revised to achieve clarity. The process also permits identification of options that were not implemented, so that they can be removed from the advancing specification. Thus, the product of this process is information about the metric specification RFC itself: determination of the specifications or definitions that are clear and unambiguous and those that are not (as opposed to an evaluation of the implementations that assist in the process).
標準化プロセスは、メトリック定義と補足資料が明確に記述され、明確であること、またはメトリック定義を改訂して明確にする方法を明らかにするという信頼を生み出すことを目的としています。このプロセスでは、実装されなかったオプションを識別できるため、拡張仕様からそれらを削除できます。したがって、このプロセスの成果物は、メトリック仕様RFC自体に関する情報です。明確で明確な仕様または定義の決定と明確ではないもの（プロセスを支援する実装の評価とは対照的）。
This document defines a process to verify that implementations (or practically, measurement systems) have interpreted the metric specifications in equivalent ways and produce equivalent results.
このドキュメントでは、実装（または実際には測定システム）がメトリック仕様を同等の方法で解釈し、同等の結果を生成したことを確認するプロセスを定義します。
Testing for statistical equivalence requires ensuring identical test setups (or awareness of differences) to the best possible extent. Thus, producing identical test conditions is a core goal of this memo. Another important aspect of this process is to test individual implementations against specific requirements in the metric specifications using customized tests for each requirement. These tests can distinguish equivalent interpretations of each specific requirement.
統計的同等性のテストでは、可能な限り同じテスト設定（または違いの認識）を確保する必要があります。したがって、同一のテスト条件を作成することは、このメモの中心的な目標です。このプロセスのもう1つの重要な側面は、要件ごとにカスタマイズされたテストを使用して、メトリック仕様の特定の要件に対して個々の実装をテストすることです。これらのテストは、各特定の要件の同等の解釈を区別できます。
Conclusions on equivalence are reached by two measures.
同等性に関する結論は、2つの手段によって達成されます。
First, implementations are compared against individual metric specifications to make sure that differences in implementation are minimized or at least known.
最初に、実装が個々のメトリック仕様と比較され、実装の違いが最小限に抑えられているか、少なくともわかっていることが確認されます。
Second, a test setup is proposed ensuring identical networking conditions so that unknowns are minimized and comparisons are simplified. The resulting separate data sets may be seen as samples taken from the same underlying distribution. Using statistical methods, the equivalence of the results is verified. To illustrate application of the process and methods defined here, evaluation of the One-Way Delay Metric [RFC2679] is provided in Appendix A. While test setups will vary with the metrics to be validated, the general methodology of determining equivalent results will not. Documents defining test setups to evaluate other metrics should be developed once the process proposed here has been agreed and approved.
第2に、未知の要素が最小限に抑えられ、比較が簡略化されるように、同じネットワーク条件を保証するテストセットアップが提案されます。結果の個別のデータセットは、同じ基になる分布から取得されたサンプルとして表示される場合があります。統計的手法を使用して、結果の同等性が検証されます。ここで定義されているプロセスと方法の適用を説明するために、一方向遅延メトリック[RFC2679]の評価を付録Aに示します。テストのセットアップは検証するメトリックによって異なりますが、同等の結果を決定する一般的な方法論は異なります。ここで提案されたプロセスが合意および承認されたら、他のメトリックを評価するためのテストセットアップを定義するドキュメントを作成する必要があります。
The metric RFC advancement process begins with a request for protocol action accompanied by a memo that documents the supporting tests and results. The procedures of [RFC2026] are expanded in [RFC5657], including sample implementation and interoperability reports. [TESTPLAN] can serve as a template for a metric RFC report that accompanies the protocol action request to the Area Director, including a description of the test setup, procedures, results for each implementation, and conclusions.
メトリックRFCアドバンスプロセスは、プロトコルテストの要求から始まり、サポートするテストと結果を文書化したメモが添付されます。 [RFC2026]の手順は、[RFC5657]で拡張され、サンプルの実装と相互運用性レポートが含まれています。 [TESTPLAN]は、テストのセットアップ、手順、各実装の結果、および結論の説明を含む、エリアディレクターへのプロトコルアクション要求に付随するメトリックRFCレポートのテンプレートとして機能します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The implementation of a standard compliant metric is expected to meet the requirements of the related metric specification. So, before comparing two metric implementations, each metric implementation is individually compared against the metric specification.
標準に準拠したメトリックの実装は、関連するメトリック仕様の要件を満たすことが期待されています。そのため、2つのメトリック実装を比較する前に、各メトリック実装はメトリック仕様に対して個別に比較されます。
Most metric specifications leave freedom to implementors on non-fundamental aspects of an individual metric (or options). Comparing different measurement results using a statistical test with the assumption of identical test path and testing conditions requires knowledge of all differences in the overall test setup. Metric specification options chosen by implementors have to be documented. It is RECOMMENDED to use identical metric options for any test proposed here (an exception would be if a variable parameter of the metric definition is not configurable in one or more implementations). Calibrations specified by metric standards SHOULD be performed to further identify (and possibly reduce) potential sources of error in the test setup.
ほとんどのメトリックの仕様は、個々のメトリック（またはオプション）の非基本的な側面について、実装者に自由を与えます。同一のテストパスとテスト条件を想定した統計テストを使用してさまざまな測定結果を比較するには、テストセットアップ全体のすべての違いに関する知識が必要です。実装者が選択したメトリック仕様オプションは文書化する必要があります。ここで提案されているすべてのテストに同一のメトリックオプションを使用することをお勧めします（1つ以上の実装でメトリック定義の変数パラメーターを構成できない場合は例外です）。メトリック標準で指定されているキャリブレーションは、テストセットアップの潜在的なエラーの原因をさらに特定する（そして場合によっては減らす）ために実行する必要があります（SHOULD）。
The IPPM Framework [RFC2330] expects that a "methodology for a metric should have the property that it is repeatable: if the methodology is used multiple times under identical conditions, it should result in consistent measurements". This means an implementation is expected to repeatedly measure a metric with consistent results (repeatability with the same result). Small deviations in the test setup are expected to lead to small deviations in results only. To characterize statistical equivalence in the case of small deviations, [RFC2330] and [RFC2679] suggest to apply a 95% confidence interval. Quoting RFC 2679, "95 percent was chosen because ... a particular confidence level should be specified so that the results of independent implementations can be compared".
IPPMフレームワーク[RFC2330]は、「メトリックの方法論には、反復可能なプロパティが必要です。方法論が同じ条件下で複数回使用された場合、一貫した測定結果が得られるはずです」と想定しています。これは、実装が一貫した結果（同じ結果の再現性）でメトリックを繰り返し測定することが期待されることを意味します。テストセットアップの小さな偏差は、結果のみの小さな偏差につながると予想されます。偏差が小さい場合の統計的同等性を特徴付けるために、[RFC2330]と[RFC2679]は95％の信頼区間を適用することを提案しています。 RFC 2679を引用すると、「独立した実装の結果を比較できるように特定の信頼レベルを指定する必要があるため、95％が選択されました」。
Two different implementations are expected to produce statistically equivalent results if they both measure a metric under the same networking conditions. Formulating in statistical terms: separate metric implementations collect separate samples from the same underlying statistical process (the same network conditions). The statistical hypothesis to be tested is the expectation that both samples do not expose statistically different properties. This requires careful test design:
2つの異なる実装は、両方が同じネットワーク条件下でメトリックを測定する場合、統計的に同等の結果を生成すると予想されます。統計用語で定式化：個別のメトリック実装は、同じ基礎となる統計プロセス（同じネットワーク条件）から個別のサンプルを収集します。テストする統計的仮説は、両方のサンプルが統計的に異なるプロパティを公開しないという期待です。これには注意深いテスト設計が必要です：
o The measurement test setup must be self-consistent to the largest possible extent. To minimize the influence of the test and measurement setup on the result, network conditions and paths MUST be identical for the compared implementations to the largest possible degree. This includes both the stability and non-ambiguity of routes taken by the measurement packets. See [RFC2330] for a discussion on self-consistency.
o 測定テストのセットアップは、可能な限り自己矛盾のないものでなければなりません。テストと測定のセットアップが結果に与える影響を最小限に抑えるには、比較する実装のネットワーク条件とパスを可能な限り同じにする必要があります。これには、測定パケットがたどるルートの安定性と非あいまいさの両方が含まれます。自己矛盾のない議論については[RFC2330]を見てください。
o To minimize the influence of implementation options on the result, metric implementations SHOULD use identical options and parameters for the metric under evaluation.
o 結果に対する実装オプションの影響を最小限に抑えるために、メトリックの実装では、評価中のメトリックに同じオプションとパラメーターを使用する必要があります（SHOULD）。
o The sample size must be large enough to minimize its influence on the consistency of the test results. This consideration may be especially important if two implementations measure with different average packet transmission rates.
o サンプルサイズは、テスト結果の一貫性への影響を最小限に抑えるのに十分な大きさでなければなりません。 2つの実装が異なる平均パケット伝送速度で測定する場合、この考慮事項は特に重要です。
o The implementation with the lowest average packet transmission rate determines the smallest temporal interval for which samples can be compared.
o 最低の平均パケット伝送速度での実装は、サンプルを比較できる最小の時間間隔を決定します。
o Repeat comparisons with several independent metric samples to avoid random indications of compatibility (or the lack of it).
o 複数の独立したメトリックサンプルを使用して比較を繰り返し、互換性のランダムな兆候（またはそれがないこと）を回避します。
The metric specifications themselves are the primary focus of evaluation, rather than the implementations of metrics. The documentation produced by the advancement process should identify which metric definitions and supporting material were found to be clearly worded and unambiguous, OR it should identify ways in which the metric specification text should be revised to achieve clarity and unified interpretation.
メトリックの実装ではなく、メトリックの仕様自体が評価の主な焦点です。昇格プロセスによって作成されたドキュメントは、どのメトリック定義と裏付け資料が明確に記述され、明確であると判明したか、または明確で統一された解釈を実現するためにメトリック仕様テキストを修正する方法を特定する必要があります。
The process should also permit identification of options that were not implemented, so that they can be removed from the advancing specification (this is an aspect more typical of protocol advancement along the Standards Track).
このプロセスでは、実装されなかったオプションを識別できるようにする必要があります。そうすることで、それらのオプションを拡張仕様から削除できます（これは、標準トラックに沿ったプロトコル拡張のより一般的な側面です）。
Note that this document does not propose to base interoperability indications of performance-metric implementations on comparisons of individual singletons. Individual singletons may be impacted by many statistical effects while they are measured. Comparing two singletons of different implementations may result in failures with higher probability than comparing samples.
このドキュメントでは、個々のシングルトンの比較に基づいて、パフォーマンスメトリックの実装の相互運用性を示すことを提案していません。個々のシングルトンは、測定中に多くの統計的影響の影響を受ける可能性があります。異なる実装の2つのシングルトンを比較すると、サンプルを比較するよりも高い確率で失敗する可能性があります。
This section specifies how to verify compliance of two or more IPPM implementations against a metric specification. This document only proposes a general methodology. Compliance criteria to a specific metric implementation need to be defined for each individual metric specification. The only exception is the statistical test comparing two metric implementations that are simultaneously tested. This test is applicable without metric-specific decision criteria.
このセクションでは、メトリック仕様に対する2つ以上のIPPM実装のコンプライアンスを確認する方法を指定します。このドキュメントでは、一般的な方法論のみを提案しています。特定のメトリック実装への準拠基準は、個々のメトリック仕様ごとに定義する必要があります。唯一の例外は、同時にテストされる2つのメトリック実装を比較する統計テストです。このテストは、メトリック固有の決定基準なしで適用できます。
Several testing options exist to compare two or more implementations:
2つ以上の実装を比較するためのテストオプションがいくつかあります。
o Use a single test lab to compare the implementations and emulate the Internet with an impairment generator.
o 単一のテストラボを使用して実装を比較し、インターネットを減損ジェネレーターでエミュレートします。
o Use a single test lab to compare the implementations and measure across the Internet.
o 単一のテストラボを使用して、実装を比較し、インターネット全体で測定します。
o Use remotely separated test labs to compare the implementations and emulate the Internet with two "identically" configured impairment generators.
o リモートで分離されたテストラボを使用して、実装を比較し、「同一」に構成された2つの障害発生器でインターネットをエミュレートします。
o Use remotely separated test labs to compare the implementations and measure across the Internet.
o リモートで分離されたテストラボを使用して、実装を比較し、インターネット全体で測定します。
o Use remotely separated test labs to compare the implementations, measure across the Internet, and include a single impairment generator to impact all measurement flows in a non-discriminatory way.
o リモートで分離されたテストラボを使用して、実装を比較し、インターネット全体で測定し、単一の障害発生器を含めて、すべての測定フローに差別的な方法で影響を与えます。
The first two approaches work, but involve higher expenses than the others (due to travel and/or shipping plus installation). For the third option, ensuring two identically configured impairment generators requires well-defined test cases and possibly identical hardware and software.
最初の2つのアプローチは機能しますが、他のアプローチよりも費用が高くなります（旅行および/または配送と設置のため）。 3番目のオプションの場合、2つの同一構成の障害発生器を確実にするには、明確に定義されたテストケースと、場合によっては同一のハードウェアとソフトウェアが必要です。
As documented in a test report [TESTPLAN], the last option was required to prove compatibility of two delay metric implementations. An impairment generator is probably required when testing compatibility of most other metrics, and it is therefore RECOMMENDED to include an impairment generator in metric test setups.
テストレポート[TESTPLAN]に記載されているように、2つの遅延メトリック実装の互換性を証明するには、最後のオプションが必要でした。他のほとんどのメトリックの互換性をテストする場合、おそらく減損ジェネレータが必要であるため、メトリックテストのセットアップに減損ジェネレータを含めることをお勧めします。
3.1. Tests of an Individual Implementation against a Metric Specification
3.1. メトリック仕様に対する個々の実装のテスト
A metric implementation is compliant with a metric specification if it supports the requirements classified as "MUST" and "REQUIRED" in the related metric specification. An implementation that implements all requirements is fully compliant with the specification, and the degree of compliance SHOULD be noted in the conclusions of the report.
メトリック実装は、関連するメトリック仕様で「必須」および「必須」として分類された要件をサポートする場合、メトリック仕様に準拠しています。すべての要件を実装する実装は仕様に完全に準拠しており、準拠の程度はレポートの結論に記載する必要があります。
Further, supported options of a metric implementation SHOULD be documented in sufficient detail to evaluate whether the specification was correctly interpreted. The documentation of chosen options should minimize (and recognize) differences in the test setup if two metric implementations are compared. Further, this documentation is used to validate or clarify the wording of the metric specification option, to remove options that saw no implementation or that are badly specified from the metric specification. This documentation SHOULD be included for all implementation-relevant specifications of a metric picked for a comparison, even those that are not explicitly marked as "MUST" or "REQUIRED" in the RFC text. This applies for the following sections of all metric specifications:
さらに、メトリック実装のサポートされているオプションは、仕様が正しく解釈されたかどうかを評価するために十分詳細に文書化する必要があります（SHOULD）。 2つのメトリックの実装を比較する場合、選択したオプションのドキュメントは、テストセットアップの違いを最小限に抑える（および認識する）必要があります。さらに、このドキュメントは、メトリック仕様オプションの表現を検証または明確化し、実装が見られなかったオプションまたはメトリック仕様から不適切に指定されたオプションを削除するために使用されます。このドキュメントは、RFCテキストで「MUST」または「REQUIRED」として明示的にマークされていないものであっても、比較のために選択されたメトリックの実装関連のすべての仕様に含める必要があります。これは、すべてのメトリック仕様の次のセクションに適用されます。
o Singleton Definition of the Metric.
o メトリックのシングルトン定義。
o Sample Definition of the Metric.
o メトリックのサンプル定義。
o Statistics Definition of the Metric. As statistics are compared by the test specified here, this documentation is required even in the case that the metric specification does not contain a Statistics Definition.
o メトリックの統計定義。ここで指定されたテストによって統計が比較されるため、メトリック仕様に統計定義が含まれていない場合でも、このドキュメントは必要です。
o Timing- and Synchronization-related specification (if relevant for the Metric).
o タイミングおよび同期関連の仕様（メトリックに関連する場合）。
o Any other technical part present or missing in the metric specification, which is relevant for the implementation of the Metric.
o メトリックの実装に関連する、メトリック仕様に存在するか欠落しているその他の技術的な部分。
[RFC2330] and [RFC2679] emphasize precision as an aim of IPPM metric implementations. A single IPPM-conforming implementation should under otherwise identical network conditions produce precise results for repeated measurements of the same metric.
[RFC2330]および[RFC2679]は、IPPMメトリック実装の目的として精度を強調しています。単一のIPPM準拠の実装では、他の点では同一のネットワーク条件下で、同じメトリックの繰り返し測定に対して正確な結果が生成されるはずです。
RFC 2330 prefers the "empirical distribution function" (EDF) to describe collections of measurements. RFC 2330 determines, that "unless otherwise stated, IPPM goodness-of-fit tests are done using 5% significance". The goodness-of-fit test determines by which precision two or more samples of a metric implementation belong to the same underlying distribution (of measured network performance events). The goodness-of-fit test suggested for the metric test is the Anderson-Darling K sample test (ADK sample test, K stands for the number of samples to be compared) [ADK]. Please note that RFC 2330 and RFC 2679 apply an Anderson-Darling goodness-of-fit test, too.
RFC 2330は、測定のコレクションを記述するために「経験的分布関数」（EDF）を優先します。 RFC 2330は、「特に明記しない限り、IPPM適合度テストは5％の有意性を使用して行われる」と判断しています。適合度テストは、メトリック実装の2つ以上のサンプルが、（測定されたネットワークパフォーマンスイベントの）同じ基礎となる分布に属する精度を決定します。メトリックテストで推奨される適合度テストは、Anderson-Darling Kサンプルテストです（ADKサンプルテスト、Kは比較するサンプルの数を表します）[ADK]。 RFC 2330およびRFC 2679もアンダーソンダーリング適合度テストを適用することに注意してください。
The results of a repeated test with a single implementation MUST pass an ADK sample test with a confidence level of 95%. The conditions for which the ADK test has been passed with the specified confidence level MUST be documented. To formulate this differently, the requirement is to document the set of parameters with the smallest deviation at which the results of the tested metric implementation pass an ADK test with a confidence level of 95%. The minimum resolution available in the reported results from each implementation MUST be taken into account in the ADK test.
単一の実装で繰り返されたテストの結果は、95％の信頼レベルでADKサンプルテストに合格する必要があります。指定された信頼レベルでADKテストに合格した条件を文書化する必要があります。これを別の方法で定式化するための要件は、テストされたメトリック実装の結果が95％の信頼レベルでADKテストに合格する最小の偏差を持つパラメーターのセットを文書化することです。 ADKテストでは、各実装から報告された結果で利用可能な最小解像度を考慮する必要があります。
The test conditions to be documented for a passed metric test include:
合格したメトリックテストについて文書化されるテスト条件は次のとおりです。
o The metric resolution at which a test was passed (e.g., the resolution of timestamps).
o テストに合格したメトリックの解像度（タイムスタンプの解像度など）。
o The parameters modified by an impairment generator.
o 減損ジェネレーターによって変更されたパラメーター。
o The impairment generator parameter settings.
o 減損ジェネレーターのパラメーター設定。
Two major issues complicate tests for metric compliance across live networks under identical testing conditions. One is the general point that metric definition implementations cannot be conveniently examined in field measurement scenarios. The other one is more broadly described as "parallelism in devices and networks", including mechanisms like those that achieve load balancing (see [RFC4928]).
2つの主要な問題により、同一のテスト条件下でのライブネットワーク全体のメトリックコンプライアンスのテストが複雑になります。 1つは、フィールド定義シナリオでメトリック定義の実装を簡単に調べることができないという一般的な点です。もう1つは、「デバイスとネットワークの並列処理」としてより広く説明されており、ロードバランシングを実現するメカニズムなどが含まれます（[RFC4928]を参照）。
This section proposes two measures to deal with both issues. Tunneling mechanisms can be used to avoid parallel processing of different flows in the network. Measuring by separate parallel probe flows results in repeated collection of data. If both measures are combined, Wide Area Network (WAN) conditions are identical for a number of independent measurement flows, no matter what the network conditions are in detail.
このセクションでは、両方の問題に対処するための2つの対策を提案します。トンネリングメカニズムを使用すると、ネットワーク内の異なるフローの並列処理を回避できます。個別の並列プローブフローで測定すると、データが繰り返し収集されます。両方の測定を組み合わせると、ネットワークの状態がどのようなものであっても、Wide Area Network（WAN）の状態は、多くの独立した測定フローで同一になります。
Any measurement setup must be made to avoid the probing traffic itself to impede the metric measurement. The created measurement load must not result in congestion at the access link connecting the measurement implementation to the WAN. The created measurement load must not overload the measurement implementation itself, e.g., by causing a high CPU load or by causing timestamp imprecision due to unwanted queuing while transmitting or receiving test packets.
プローブ自体がメトリック測定を妨げないように、測定セットアップを行う必要があります。作成された測定負荷によって、測定実装をWANに接続するアクセスリンクで輻輳が発生しないようにする必要があります。作成された測定負荷は、たとえば高いCPU負荷を引き起こしたり、テストパケットの送受信中に不要なキューイングが原因でタイムスタンプが不正確になったりするなど、測定実装自体に過負荷をかけないようにする必要があります。
Tunneling multiple flows destined for a single physical port of a network element allows transmission of all packets via the same path. Applying tunnels to avoid undesired influence of standard routing for measurement purposes is a concept known from literature, see e.g., GRE-encapsulated multicast probing [GU-Duffield]. An existing IP-in-IP tunnel protocol can be applied to avoid Equal-Cost Multi-Path (ECMP) routing of different measurement streams if it meets the following criteria:
ネットワーク要素の単一の物理ポートを宛先とする複数のフローをトンネリングすると、同じパスを介してすべてのパケットを送信できます。測定目的での標準ルーティングの望ましくない影響を回避するためにトンネルを適用することは、文献から知られている概念です。たとえば、GREカプセル化マルチキャストプローブ[GU-Duffield]を参照してください。次の基準を満たす場合、既存のIP-in-IPトンネルプロトコルを適用して、異なる測定ストリームの等価コストマルチパス（ECMP）ルーティングを回避できます。
o Inner IP packets from different measurement implementations are mapped into a single tunnel with a single outer IP origin and destination address as well as origin and destination port numbers that are identical for all packets.
o 異なる測定実装からの内部IPパケットは、単一の外部IP起点と宛先アドレス、およびすべてのパケットで同一の起点と宛先ポート番号を持つ単一のトンネルにマッピングされます。
o An easily accessible tunneling protocol allows for carrying out a metric test from more test sites.
o 簡単にアクセスできるトンネリングプロトコルにより、より多くのテストサイトからメトリックテストを実行できます。
o A low operational overhead may enable a broader audience to set up a metric test with the desired properties.
o 運用上のオーバーヘッドが低いと、幅広い対象者が目的のプロパティでメトリックテストを設定できるようになります。
o The tunneling protocol should be reliable and stable in setup and operation to avoid disturbances or influence on the test results.
o トンネリングプロトコルは、セットアップや運用において信頼性と安定性があり、テスト結果への妨害や影響を回避する必要があります。
o The tunneling protocol should not incur any extra cost for those interested in setting up a metric test.
o トンネリングプロトコルは、メトリックテストの設定に関心のある人に追加のコストをかけるべきではありません。
An illustration of a test setup with two layer 2 tunnels and two flows between two linecards of one implementation is given in Figure 1.
1つの実装の2つのレイヤ2トンネルと2つのラインカード間の2つのフローを使用したテストセットアップの図を図1に示します。
Implementation ,---. +--------+
+~~~~~~~~~~~/ \~~~~~~| Remote |
+------->-----F2->-| / \ |->---+ |
| +---------+ | Tunnel 1( ) | | |
| | transmit|-F1->-| ( ) |->+ | |
| | LC1 | +~~~~~~~~~| |~~~~| | | |
| | receive |-<--+ ( ) | F1 F2 |
| +---------+ | |Internet | | | | |
*-------<-----+ F2 | | | | | |
+---------+ | | +~~~~~~~~~| |~~~~| | | |
| transmit|-* *-| | | |--+<-* |
| LC2 | | Tunnel 2( ) | | |
| receive |-<-F1-| \ / |<-* |
+---------+ +~~~~~~~~~~~\ /~~~~~~| Router |
`-+-' +--------+
For simplicity, only two linecards of one implementation and two flows F between them are shown.
簡単にするために、1つの実装の2つのラインカードとそれらの間の2つのフローFのみを示しています。
Figure 1: Illustration of a Test Setup with Two Layer 2 Tunnels
図1：2つのレイヤ2トンネルを備えたテストセットアップの図
Figure 2 shows the network elements required to set up layer 2 tunnels as shown by Figure 1.
図2は、図1に示すように、レイヤー2トンネルをセットアップするために必要なネットワーク要素を示しています。
Implementation
実装
+-----+ ,---.
| LC1 | / \
+-----+ / \ +------+
| +-------+ ( ) +-------+ |Remote|
+--------+ | | | | | | | |
|Ethernet| | Tunnel| |Internet | | Tunnel| | |
|Switch |--| Head |--| |--| Head |--| |
+--------+ | Router| | | | Router| | |
| | | ( ) | | |Router|
+-----+ +-------+ \ / +-------+ +------+
| LC2 | \ /
+-----+ `-+-'
Figure 2: Illustration of a Hardware Setup to Realize the Test Setup Illustrated by Figure 1 with Layer 2 Tunnels or Pseudowires
図2：レイヤー2トンネルまたは疑似配線を使用して図1に示されているテストセットアップを実現するためのハードウェアセットアップの図
The test setup successfully used during a delay metric test [TESTPLAN] is given as an example in Figure 3. Note that the shown setup allows a metric test between two remote sites.
遅延メトリックテスト[TESTPLAN]中に正常に使用されたテストセットアップを例として図3に示します。表示されているセットアップでは、2つのリモートサイト間のメトリックテストが可能です。
+----+ +----+ +----+ +----+
|LC10| |LC11| ,---. |LC20| |LC21|
+----+ +----+ / \ +-------+ +----+ +----+
| V10 | V11 / \ | Tunnel| | V20 | V21
| | ( ) | Head | | |
+--------+ +------+ | | | Router|__+----------+
|Ethernet| |Tunnel| |Internet | +---B---+ |Ethernet |
|Switch |--|Head |-| | | |Switch |
+-+--+---+ |Router| | | +---+---+ +--+--+----+
|__| +--A---+ ( )--|Option.| |__|
\ / |Impair.|
Bridge \ / |Gener. | Bridge
V20 to V21 `-+-? +-------+ V10 to V11
Figure 3: Example of Test Setup Successfully Used during a Delay Metic Test
図3：遅延メティックテスト中に正常に使用されたテストセットアップの例
In Figure 3, LC10 identifies measurement clients / linecards. V10 and the others denote VLANs. All VLANs are using the same tunnel from A to B and in the reverse direction. The remote site VLANs are U-bridged at the local site Ethernet switch. The measurement packets of site 1 travel tunnel A->B first, are U-bridged at site 2, and travel tunnel B->A second. Measurement packets of site 2 travel tunnel B->A first, are U-bridged at site 1, and travel tunnel A->B second. So, all measurement packets pass the same tunnel segments, but in different segment order.
図3で、LC10は測定クライアント/ラインカードを識別します。 V10などはVLANを示します。すべてのVLANは、AからBへと逆方向に同じトンネルを使用しています。リモートサイトのVLANは、ローカルサイトのイーサネットスイッチでUブリッジされています。最初にサイト1のトラベルトンネルの測定パケットは、A-> Bに移動し、サイト2でUブリッジされ、次にトンネルB-> Aに移動します。サイト2の測定パケットは、最初にトンネルB-> Aに移動し、サイト1でUブリッジされ、次にトンネルA-> Bに移動します。したがって、すべての測定パケットは同じトンネルセグメントを通過しますが、セグメントの順序は異なります。
If tunneling is applied, two tunnels MUST carry all test traffic in between the test site and the remote site. For example, if 802.1Q Virtual LANs (VLANs) are applied and the measurement streams are carried in different VLANs, the IP tunnel or pseudowires respectively are setup in physical port mode to avoid setup of pseudowires per VLAN (which may see different paths due to ECMP routing); see [RFC4448]. The remote router and the Ethernet switch shown in Figure 3 have to support 802.1Q in this setup.
トンネリングが適用される場合、2つのトンネルがすべてのテストトラフィックをテストサイトとリモートサイトの間で伝送する必要があります。たとえば、802.1Q仮想LAN（VLAN）が適用され、測定ストリームが異なるVLANで伝送される場合、IPトンネルまたは疑似配線はそれぞれ物理ポートモードで設定され、VLANごとの疑似配線の設定を回避します（ ECMPルーティング）; [RFC4448]を参照してください。図3に示すリモートルータとイーサネットスイッチは、この設定で802.1Qをサポートする必要があります。
The IP packet size of the metric implementation SHOULD be chosen small enough to avoid fragmentation due to the added Ethernet and tunnel headers. Otherwise, the impact of tunnel overhead on fragmentation and interface MTU size must be understood and taken into account (see [RFC4459]).
メトリック実装のIPパケットサイズは、追加されたイーサネットヘッダーとトンネルヘッダーによる断片化を回避するのに十分小さい値に選択する必要があります（SHOULD）。そうでない場合は、断片化とインターフェイスMTUサイズに対するトンネルオーバーヘッドの影響を理解し、考慮する必要があります（[RFC4459]を参照）。
An Ethernet port mode IP tunnel carrying several 802.1Q VLANs each containing measurement traffic of a single measurement system was successfully applied when testing compatibility of two metric implementations [TESTPLAN]. Ethernet over Layer 2 Tunneling Protocol Version 3 (L2TPv3) [RFC4719] was picked for this test.
2つのメトリック実装[TESTPLAN]の互換性をテストしたところ、それぞれが単一の測定システムの測定トラフィックを含む複数の802.1Q VLANを伝送するイーサネットポートモードIPトンネルが正常に適用されました。このテストでは、Ethernet over Layer 2 Tunneling Protocol Version 3（L2TPv3）[RFC4719]が選ばれました。
The following headers may have to be accounted for when calculating total packet length, if VLANs and Ethernet over L2TPv3 tunnels are applied:
VLANおよびEthernet over L2TPv3トンネルが適用されている場合、合計パケット長を計算するときに、次のヘッダーを考慮する必要がある場合があります。
o Ethernet 802.1Q: 22 bytes.
o イーサネット802.1Q：22バイト。
o L2TPv3 Header: 4-16 bytes for L2TPv3 data messages over IP; 16-28 bytes for L2TPv3 data messages over UDP.
o L2TPv3ヘッダー：IPを介したL2TPv3データメッセージの場合は4〜16バイト。 UDPを介したL2TPv3データメッセージの16〜28バイト。
o IPv4 Header (outer IP header): 20 bytes.
o IPv4ヘッダー（外部IPヘッダー）：20バイト。
o MPLS Labels may be added by a carrier. Each MPLS Label has a length of 4 bytes. At the time of this writing, between 1 and 4 Labels seems to be a fair guess of what's expected.
o MPLSラベルは、キャリアによって追加される場合があります。各MPLSラベルの長さは4バイトです。この記事の執筆時点では、1〜4のラベルが期待されるもののかなりの推測であるようです。
The applicability of one or more of the following tunneling protocols may be investigated by interested parties if Ethernet over L2TPv3 is felt to be unsuitable: IP in IP [RFC2003] or Generic Routing Encapsulation (GRE) [RFC2784]. RFC 4928 [RFC4928] proposes measures how to avoid ECMP treatment in MPLS networks.
Ethernet over L2TPv3が不適切であると思われる場合、利害関係者は次の1つ以上のトンネリングプロトコルの適用性を調査できます：IP in IP [RFC2003]またはGeneric Routing Encapsulation（GRE）[RFC2784]。 RFC 4928 [RFC4928]は、MPLSネットワークでECMP処理を回避する方法を提案しています。
L2TP is a commodity tunneling protocol [RFC2661]. At the time of this writing, L2TPv3 [RFC3931] is the latest version of L2TP. If L2TPv3 is applied, software-based implementations of this protocol are not suitable for the test setup, as such implementations may cause incalculable delay shifts.
L2TPは、商品トンネリングプロトコル[RFC2661]です。この記事の執筆時点では、L2TPv3 [RFC3931]がL2TPの最新バージョンです。 L2TPv3が適用されている場合、このプロトコルのソフトウェアベースの実装は、計算のできない遅延シフトを引き起こす可能性があるため、テスト設定には適していません。
Ethernet pseudowires may also be set up on MPLS networks [RFC4448]. While there is no technical issue with this solution, MPLS interfaces are mostly found in the network provider domain. Hence, not all of the above criteria for selecting a tunneling protocol are met.
イーサネット疑似配線は、MPLSネットワーク[RFC4448]でも設定できます。このソリューションには技術的な問題はありませんが、MPLSインターフェイスは主にネットワークプロバイダードメインにあります。したがって、トンネリングプロトコルを選択するための上記の基準のすべてが満たされるわけではありません。
Note that setting up a metric test environment is not a plug-and-play issue. Skilled networking engineers should be consulted and involved if a setup between remote sites is preferred.
メトリックテスト環境のセットアップはプラグアンドプレイの問題ではないことに注意してください。リモートサイト間のセットアップが望ましい場合は、熟練したネットワーキングエンジニアに相談し、関与する必要があります。
Passing or failing an ADK test with 2 samples could be a random result (note that [RFC2330] defines a sample as a set of singleton metric values produced by a measurement stream, and we continue to use this terminology here). The error margin of a statistical test is higher if the number of samples it is based on is low (the number of samples taken influences the so-called "degree of freedom" of a statistical test, and a higher degree of freedom produces more reliable results). To pass an ADK with higher probability, the number of samples collected per implementation under identical networking conditions SHOULD be greater than 2. Hardware and load constraints may enforce an upper limit on the number of simultaneous measurement streams. The ADK test allows one to combine different samples (see Section 9 of [ADK]) and then to run a 2-sample test between combined samples. At least 4 samples per implementation captured under identical networking conditions is RECOMMENDED when comparing different metric implementations by a statistical test.
2つのサンプルを使用したADKテストの合格または不合格はランダムな結果になる可能性があります（[RFC2330]は、サンプルを測定ストリームによって生成されるシングルトンメトリック値のセットとして定義します。ここではこの用語を引き続き使用します）。統計テストのエラーマージンは、それが基づいているサンプルの数が少ない場合に高くなります（取得されるサンプルの数は、統計テストのいわゆる「自由度」に影響し、自由度が高いほど信頼性が高くなります。結果）。より高い確率でADKを渡すには、同一のネットワーク条件下で実装ごとに収集されるサンプル数が2を超える必要があります。ハードウェアと負荷の制約により、同時測定ストリームの数に上限が適用される場合があります。 ADKテストでは、異なるサンプルを組み合わせ（[ADK]のセクション9を参照）、組み合わせたサンプル間で2サンプルテストを実行できます。統計テストによって異なるメトリック実装を比較する場合、同一のネットワーク条件下でキャプチャされた実装ごとに少なくとも4つのサンプルが推奨されます。
It is RECOMMENDED that tests be carried out by establishing N different parallel measurement flows. Two or three linecards per implementation serving to send or receive measurement flows should be sufficient to create 4 or more parallel measurement flows. Other options are to separate flows by DiffServ marks (without deploying any Quality of Service (QoS) in the inner or outer tunnel) or to use a single Constant Bitrate (CBR) flow and evaluate whether every n-th singleton belongs to a specific measurement flow. Note that a practical test indeed showed that ADK passed with 4 samples even if a 2-sample test failed [TESTPLAN].
N個の異なる並列測定フローを確立してテストを実行することをお勧めします。実装ごとに2つまたは3つのラインカードで測定フローを送受信することで、4つ以上の並列測定フローを作成できます。その他のオプションは、DiffServマークでフローを分離する（内部または外部トンネルにサービス品質（QoS）を展開せずに）、または単一の固定ビットレート（CBR）フローを使用して、n番目のシングルトンがすべて特定の測定に属しているかどうかを評価することですフロー。実際のテストでは、実際には、2サンプルのテストが失敗した場合でも、ADKは4つのサンプルで合格したことが示されています[TESTPLAN]。
Some additional guidelines to calculate and compare samples to perform a metric test are:
メトリックテストを実行するためにサンプルを計算および比較するための追加のガイドラインは次のとおりです。
o Comparing different probes of a common underlying distribution in terms of metrics characterizing a communication network requires respecting the temporal nature for which the assumption of a common underlying distribution may hold. Any singletons or samples to be compared must be captured within the same time interval.
o 通信ネットワークを特徴付けるメトリックの観点から、共通の基礎となる分布のさまざまなプローブを比較するには、共通の基礎となる分布の仮定が保持する可能性がある時間的性質を考慮する必要があります。比較するシングルトンまたはサンプルは、同じ時間間隔内でキャプチャする必要があります。
o If statistical events like rates are used to characterize measured metrics of a time interval, a minimum of 5 singletons of a relevant metric should be picked to ensure a minimum confidence into the reported value. The error margin of the determined rate depends on the number of singletons (refer to statistical textbooks on student's t-test). As an example, any packet loss measurement interval to be compared with the results of another implementation contains at least five lost packets to have some confidence that the observed loss rate wasn't caused by a small number of random packet drops.
o レートなどの統計イベントを使用して、時間間隔の測定されたメトリックを特徴付ける場合、関連するメトリックの最小5つのシングルトンを選択して、レポートされた値の信頼性を最小限に抑える必要があります。決定されたレートのエラーマージンは、シングルトンの数に依存します（学生のt検定に関する統計教科書を参照）。例として、別の実装の結果と比較されるパケット損失測定間隔には少なくとも5つの損失パケットが含まれ、観測された損失率が少数のランダムパケットドロップによって引き起こされたのではないことをある程度確信しています。
o The minimum number of singletons or samples to be compared by an Anderson-Darling test should be 100 per tested metric implementation. Note that the Anderson-Darling test detects small differences in distributions fairly well and will fail for a high number of compared results (RFC 2330 mentions an example with 8192 measurements where an Anderson-Darling test always failed).
o Anderson-Darlingテストで比較されるシングルトンまたはサンプルの最小数は、テストされたメトリック実装ごとに100でなければなりません。アンダーソンダーリングテストは分布の小さな違いをかなり良好に検出し、多数の比較結果で失敗することに注意してください（RFC 2330は、アンダーソンダーリングテストが常に失敗した8192測定の例を示しています）。
o Generally, the Anderson-Darling test is sensitive to differences in the accuracy or bias associated with varying implementations or test conditions. These dissimilarities may result in differing averages of samples to be compared. An example may be different packet sizes, resulting in a constant delay difference between compared samples. Therefore, samples to be compared by an Anderson-Darling test MAY be calibrated by the difference of the average values of the samples. Any calibration of this kind MUST be documented in the test result.
o 一般に、アンダーソンダーリングテストは、さまざまな実装やテスト条件に関連する精度やバイアスの違いに敏感です。これらの非類似性により、比較されるサンプルの平均が異なる場合があります。例としては、異なるパケットサイズがあり、比較したサンプル間に一定の遅延差が生じる場合があります。したがって、アンダーソン・ダーリング検定で比較されるサンプルは、サンプルの平均値の差によって較正される場合があります。この種の校正は、テスト結果に記録する必要があります。
3.3. Tests of Two or More Different Implementations against a Metric Specification
3.3. メトリック仕様に対する2つ以上の異なる実装のテスト
[RFC2330] expects that "a methodology for a given metric exhibits continuity if, for small variations in conditions, it results in small variations in the resulting measurements. Slightly more precisely, for every positive epsilon, there exists a positive delta, such that if two sets of conditions are within delta of each other, then the resulting measurements will be within epsilon of each other". A small variation in conditions in the context of the metric test proposed here can be seen as different implementations measuring the same metric along the same path.
[RFC2330]は、「条件の小さな変動により、結果の測定値に小さな変動が生じる場合、特定のメトリックの方法論は連続性を示すと考えています。少し正確に言えば、すべての正のイプシロンについて、正のデルタが存在し、 2つの条件セットが互いにデルタ以内にある場合、結果の測定値は互いにイプシロン内になります。」ここで提案するメトリックテストのコンテキストでの条件の小さな変動は、同じパスに沿って同じメトリックを測定するさまざまな実装と見なすことができます。
IPPM metric specifications, however, allow for implementor options to the largest possible degree. It cannot be expected that two implementors allow 100% identical options in their implementations. Testers SHOULD pick the same metric measurement configurations for their systems when comparing their implementations by a metric test.
ただし、IPPMメトリックの仕様では、実装者のオプションを最大限に活用できます。 2つの実装者が実装で100％同一のオプションを許可することは期待できません。テスターは、メトリックテストによって実装を比較するときに、システムに同じメトリック測定構成を選択する必要があります（SHOULD）。
In some cases, a goodness-of-fit test may not be possible or show disappointing results. To clarify the difficulties arising from different metric implementation options, the individual options picked for every compared metric implementation should be documented as specified in Section 3.5. If the cause of the failure is a lack of specification clarity or multiple legitimate interpretations of the definition text, the text should be modified and the resulting memo proposed for consensus and (possible) advancement to Internet Standard.
場合によっては、適合度テストが不可能な場合や、残念な結果になる場合があります。異なるメトリック実装オプションから生じる問題を明確にするために、比較されたすべてのメトリック実装に対して選択された個々のオプションは、セクション3.5で指定されているように文書化する必要があります。失敗の原因が定義テキストの仕様の明確さの欠如または複数の正当な解釈である場合、テキストを変更し、結果として得られるメモをコンセンサスおよびインターネット標準への（可能性のある）前進のために提案する必要があります。
The same statistical test as applicable to quantify precision of a single metric implementation must be used to compare metric result equivalence for different implementations. To document compatibility, the smallest measurement resolution at which the compared implementations passed the ADK sample test must be documented.
単一のメトリック実装の精度を定量化するために適用可能なものと同じ統計テストを使用して、異なる実装のメトリック結果の同等性を比較する必要があります。互換性を文書化するには、比較された実装がADKサンプルテストに合格した最小の測定分解能を文書化する必要があります。
For different implementations of the same metric, "variations in conditions" are reasonably expected. The ADK test comparing samples of the different implementations may result in a lower precision than the test for precision in the same-implementation comparison.
同じメトリックの異なる実装では、「条件の変動」が合理的に予想されます。異なる実装のサンプルを比較するADKテストは、同じ実装の比較での精度のテストよりも精度が低くなる可能性があります。
Clock synchronization effects require special attention. Accuracy of one-way active delay measurements for any metric implementation depends on clock synchronization between the source and destination of tests. Ideally, one-way active delay measurement [RFC2679] test endpoints either have direct access to independent GPS or CDMA-based time sources or indirect access to nearby NTP primary (stratum 1) time sources, equipped with GPS receivers. Access to these time sources may not be available at all test locations associated with different Internet paths, for a variety of reasons out of scope of this document.
クロック同期効果には特別な注意が必要です。メトリックの実装における一方向のアクティブ遅延測定の精度は、テストのソースと宛先の間のクロック同期に依存します。理想的には、一方向アクティブ遅延測定[RFC2679]テストエンドポイントは、独立したGPSまたはCDMAベースのタイムソースに直接アクセスするか、GPSレシーバーを備えた近くのNTPプライマリ（ストラタム1）タイムソースに間接的にアクセスします。このドキュメントの範囲外のさまざまな理由により、これらのタイムソースへのアクセスは、さまざまなインターネットパスに関連付けられたすべてのテスト場所で利用できるとは限りません。
When secondary (stratum 2 and above) time sources are used with NTP running across the same network, whose metrics are subject to comparative implementation tests, network impairments can affect clock synchronization and distort sample one-way values and their interval statistics. Discarding sample one-way delay values for any implementation is recommended when one of the following reliability conditions is met:
セカンダリ（ストラタム2以上）のタイムソースが、メトリックが比較実装テストの対象である同じネットワーク全体で実行されているNTPで使用されている場合、ネットワーク障害がクロック同期に影響を与え、サンプルの一方向の値とその間隔統計を歪める可能性があります。次の信頼性条件のいずれかが満たされた場合、実装のサンプル一方向遅延値を破棄することをお勧めします。
o Delay is measured and is finite in one direction but not the other.
o 遅延が測定され、一方向に有限ですが、他の方向にはありません。
o Absolute value of the difference between the sum of one-way measurements in both directions and the round-trip measurement is greater than X% of the latter value.
o 両方向の一方向測定値の合計と往復測定値の差の絶対値は、後者の値のX％より大きい。
Examination of the second condition requires round-trip time (RTT) measurement for reference, e.g., based on TWAMP [RFC5357] in conjunction with one-way delay measurement.
2番目の条件の検査では、たとえば、TWAMP [RFC5357]に基づく一方向遅延測定に基づいて、参照用の往復時間（RTT）測定が必要です。
Specification of X% to strike a balance between identification of unreliable one-way delay samples and misidentification of reliable samples under a wide range of Internet path RTTs requires further study.
信頼性の低い一方向の遅延サンプルの識別と、幅広いインターネットパスRTTでの信頼性のあるサンプルの誤識別との間のバランスをとるためのX％の指定には、さらに調査が必要です。
An IPPM-compliant metric implementation of an RFC that requires synchronized clocks is expected to provide precise measurement results.
同期されたクロックを必要とするRFCのIPPM準拠のメトリック実装は、正確な測定結果を提供することが期待されています。
IF an implementation publishes a specification of its precision, such as "a precision of 1 ms (+/- 500 us) with a confidence of 95%", then the specification should be met over a useful measurement duration. For example, if the metric is measured along an Internet path that is stable and not congested, then the precision specification should be met over durations of an hour or more.
「95％の信頼度で1 ms（+/- 500 us）の精度」など、実装がその精度の仕様を公開している場合、有効な測定期間にわたって仕様を満たす必要があります。たとえば、メトリックが安定していて輻輳していないインターネットパスに沿って測定される場合、精度仕様は1時間以上の期間にわたって満たされる必要があります。
In order to meet their obligations under the IETF Standards Process, the IESG must be convinced that each metric specification advanced to Internet Standard status is clearly written, that there are a sufficient number of verified equivalent implementations, and that options that have been implemented are documented.
IETF標準プロセスの下での義務を満たすために、IESGは、インターネット標準ステータスに進む各メトリック仕様が明確に記述されていること、十分な数の検証済みの同等の実装があること、および実装されているオプションが文書化されていることを確信する必要があります。 。
In the context of this document, metrics are designed to measure some characteristic of a data network. An aim of any metric definition should be that it is specified in a way that can reliably measure the specific characteristic in a repeatable way across multiple independent implementations.
このドキュメントのコンテキストでは、メトリックはデータネットワークのいくつかの特性を測定するように設計されています。メトリック定義の目的は、複数の独立した実装にわたって再現可能な方法で特定の特性を確実に測定できる方法で指定することです。
Each metric, statistic, or option of those to be validated MUST be compared against a reference measurement or another implementation as specified in this document.
検証されるそれらの各メトリック、統計、またはオプションは、このドキュメントで指定されているように、参照測定または別の実装と比較する必要があります。
Finally, the metric definitions, embodied in the text of the RFCs, are the objects that require evaluation and possible revision in order to advance to Internet Standard.
最後に、RFCのテキストで具現化されたメトリック定義は、インターネット標準に進むために評価と可能な改訂が必要なオブジェクトです。
IF two (or more) implementations do not measure an equivalent metric as specified by this document,
2つ（またはそれ以上）の実装が、このドキュメントで指定されている同等のメトリックを測定しない場合、
AND sources of measurement error do not adequately explain the lack of agreement,
AND測定誤差の原因は、合意の欠如を適切に説明していない、
THEN the details of each implementation should be audited along with the exact definition text to determine if there is a lack of clarity that has caused the implementations to vary in a way that affects the correspondence of the results.
次に、各実装の詳細を正確な定義テキストとともに監査して、実装が結果の対応に影響を与えるように変化する原因となった明確さの欠如がないかどうかを判断する必要があります。
IF there was a lack of clarity or multiple legitimate interpretations of the definition text, THEN the text should be modified and the resulting memo proposed for consensus and (possible) advancement along the Standards Track.
定義テキストが明確でなかったり、複数の正当な解釈がなかった場合は、テキストを修正し、結果として得られたメモを合意し、スタンダードトラックに沿って（可能であれば）前進させることを提案します。
Finally, all the findings MUST be documented in a report that can support advancement to Internet Standard, as described here (similar to the reports described in [RFC5657]). The list of measurement devices used in testing satisfies the implementation requirement, while the test results provide information on the quality of each specification in the metric RFC (the surrogate for feature interoperability).
最後に、すべての調査結果は、ここで説明するように、インターネット標準への進歩をサポートできるレポートに文書化する必要があります（[RFC5657]で説明されているレポートと同様）。テストで使用される測定デバイスのリストは実装要件を満たしますが、テスト結果は、メトリックRFC（機能の相互運用性の代理）の各仕様の品質に関する情報を提供します。
The complete process of advancing a metric specification to a Standard as defined by this document is illustrated in Figure 4.
このドキュメントで定義されているように、メトリック仕様を標準に進める完全なプロセスを図4に示します。
,---.
/ \
( Start )
\ / Implementations
`-+-' +-------+
| /| 1 `.
+---+----+ / +-------+ `.-----------+ ,-------.
| RFC | / |Check for | ,' was RFC `. YES
| | / |Equivalence.... clause x ------+
| |/ +-------+ |under | `. clear? ,' |
| Metric \.....| 2 ....relevant | `---+---' +----+-----+
| Metric |\ +-------+ |identical | No | |Report |
| Metric | \ |network | +--+----+ |results + |
| ... | \ |conditions | |Modify | |Advance |
| | \ +-------+ | | |Spec +--+RFC |
+--------+ \| n |.'+-----------+ +-------+ |request |
+-------+ +----------+
Figure 4: Illustration of the Metric Standardization Process
図4：メトリック標準化プロセスの図
Any recommendation for the advancement of a metric specification MUST be accompanied by an implementation report. The implementation report needs to include the tests performed, the applied test setup, the specific metrics in the RFC, and reports of the tests performed with two or more implementations. The test plan needs to specify the precision reached for each measured metric and thus define the meaning of "statistically equivalent" for the specific metrics being tested.
メトリック仕様の高度化に関する推奨事項には、実装レポートを添付する必要があります。実装レポートには、実行されたテスト、適用されたテストセットアップ、RFCの特定のメトリック、および2つ以上の実装で実行されたテストのレポートを含める必要があります。テスト計画では、測定されたメトリックごとに到達する精度を指定する必要があるため、テストされる特定のメトリックの「統計的に同等」の意味を定義する必要があります。
Ideally, the test plan would co-evolve with the development of the metric, since that's when participants have the clearest context in their minds regarding the different subtleties that can arise.
理想的には、テスト計画は指標の開発と共進化するでしょう。それは、参加者が発生する可能性のあるさまざまな微妙さについて、参加者の心に最も明確なコンテキストがあるときだからです。
In particular, the implementation report MUST include the following at minimum:
特に、実装レポートには、少なくとも以下を含める必要があります。
o The metric compared and the RFC specifying it. This includes statements as required by Section 3.1 ("Tests of an Individual Implementation against a Metric Specification") of this document.
o 比較されるメトリックとそれを指定するRFC。これには、このドキュメントのセクション3.1（「メトリック仕様に対する個々の実装のテスト」）で要求されているステートメントが含まれます。
o The measurement configuration and setup.
o 測定の構成とセットアップ。
o A complete specification of the measurement stream (mean rate, statistical distribution of packets, packet size or mean packet size, and their distribution), Differentiated Services Code Point (DSCP), and any other measurement stream properties that could result in deviating results. Deviations in results can also be caused if chosen IP addresses and ports of different implementations result in different layer 2 or layer 3 paths due to operation of Equal Cost Multi-Path routing in an operational network.
o 測定ストリームの完全な仕様（平均レート、パケットの統計的分布、パケットサイズまたは平均パケットサイズ、およびそれらの分布）、Differentiated Services Code Point（DSCP）、および結果が逸脱する可能性のあるその他の測定ストリームプロパティ。運用ネットワークでの等コストマルチパスルーティングの運用が原因で、異なる実装のIPアドレスとポートを選択した結果、レイヤー2またはレイヤー3のパスが異なる場合、結果に偏差が生じる可能性もあります。
o The duration of each measurement to be used for a metric validation, the number of measurement points collected for each metric during each measurement interval (i.e., the probe size), and the level of confidence derived from this probe size for each measurement interval.
o メトリックの検証に使用される各測定の期間、各測定間隔中に各メトリックに対して収集された測定ポイントの数（つまり、プローブサイズ）、および各測定間隔のこのプローブサイズから導出された信頼レベル。
o The result of the statistical tests performed for each metric validation as required by Section 3.3 ("Tests of Two or More Different Implementations against a Metric Specification") of this document.
o このドキュメントのセクション3.3（「メトリック仕様に対する2つ以上の異なる実装のテスト」）で必要とされる、各メトリック検証に対して実行された統計テストの結果。
o A parameterization of laboratory conditions and applied traffic and network conditions allowing reproduction of these laboratory conditions for readers of the implementation report.
o 実験室条件および適用されたトラフィックとネットワーク条件のパラメーター化により、実装レポートの読者がこれらの実験室条件を再現できるようにします。
o The documentation helping to improve metric specifications defined by this section.
o このセクションで定義されているメトリック仕様の改善に役立つドキュメント。
All of the tests for each set SHOULD be run in a test setup as specified in Section 3.2 ("Test Setup Resulting in Identical Live Network Testing Conditions".
各セットのすべてのテストは、セクション3.2（「同一のライブネットワークテスト条件になるテストセットアップ」）で指定されているテストセットアップで実行する必要があります（SHOULD）。
If a different test setup is chosen, it is recommended to avoid effects falsifying results of validation measurements caused by real data networks (like parallelism in devices and networks). Data networks may forward packets differently in the case of: o Different packet sizes chosen for different metric implementations. A proposed countermeasure is selecting the same packet size when validating results of two samples or a sample against an original distribution.
別のテストセットアップを選択する場合は、実際のデータネットワーク（デバイスやネットワークの並列処理など）によって引き起こされる検証測定の結果に影響を与える影響を回避することをお勧めします。データネットワークは、次の場合にパケットを異なる方法で転送する可能性があります。o異なるメトリック実装用に選択された異なるパケットサイズ。提案された対策は、2つのサンプルまたは元の分布に対するサンプルの結果を検証するときに同じパケットサイズを選択することです。
o Selection of differing IP addresses and ports used by different metric implementations during metric validation tests. If ECMP is applied on the IP or MPLS level, different paths can result (note that it may be impossible to detect an MPLS ECMP path from an IP endpoint). A proposed countermeasure is to connect the measurement equipment to be compared by a NAT device or establish a single tunnel to transport all measurement traffic. The aim is to have the same IP addresses and port for all measurement packets or to avoid ECMP-based local routing diversion by using a layer 2 tunnel.
o メトリック検証テスト中に、異なるメトリック実装によって使用される異なるIPアドレスとポートの選択。 ECMPがIPまたはMPLSレベルで適用される場合、異なるパスが生じる可能性があります（IPエンドポイントからMPLS ECMPパスを検出できない場合があることに注意してください）。提案された対策は、NATデバイスによって比較される測定機器を接続するか、すべての測定トラフィックを転送する単一のトンネルを確立することです。目的は、すべての測定パケットに同じIPアドレスとポートを使用するか、レイヤー2トンネルを使用してECMPベースのローカルルーティングの迂回を回避することです。
o Different IP options.
o さまざまなIPオプション。
o Different DSCP.
o 異なるDSCP。
o If the N measurements are captured using sequential measurements instead of simultaneous ones, then the following factors come into play: time varying paths and load conditions.
o 同時測定ではなく順次測定を使用してN測定が取得される場合、次の要因が関係します：時間変化するパスと負荷条件。
3.6. Proposal to Determine an Equivalence Threshold for Each Metric Evaluated
3.6. 評価された各メトリックの等価しきい値を決定するための提案
This section describes a proposal for maximum error of equivalence, based on performance comparison of identical implementations. This comparison may be useful for both ADK and non-ADK comparisons.
このセクションでは、同一の実装のパフォーマンス比較に基づいて、等価性の最大誤差の提案について説明します。この比較は、ADKと非ADKの両方の比較に役立ちます。
Each metric is tested by two or more implementations (cross-implementation testing).
各メトリックは、2つ以上の実装によってテストされます（実装間テスト）。
Each metric is also tested twice simultaneously by the *same* implementation, using different Src/Dst Address pairs and other differences such that the connectivity differences of the cross-implementation tests are also experienced and measured by the same implementation.
各メトリックは、同じ実装によって2回同時にテストされます。異なるSrc / Dstアドレスペアと他の違いを使用して、実装間テストの接続性の違いも同じ実装で経験および測定されます。
Comparative results for the same implementation represent a bound on cross-implementation equivalence. This should be particularly useful when the metric does *not* produce a continuous distribution of singleton values, such as with a loss metric or a duplication metric. Appendix A indicates how the ADK will work for one-way delay and should be likewise applicable to distributions of delay variation.
同じ実装の比較結果は、実装間の同等性の限界を表しています。これは、損失メトリックや重複メトリックなど、メトリックがシングルトン値の連続分布を生成しない場合に特に役立ちます。付録Aは、ADKが一方向の遅延に対してどのように機能するかを示しており、遅延変動の分布にも同様に適用できるはずです。
Appendix B discusses two possible ways to perform the ADK analysis: the R statistical language [Rtool] with ADK package [Radk] and C++ code.
付録Bでは、ADK分析を実行する2つの方法について説明します。R統計言語[Rtool]とADKパッケージ[Radk]およびC ++コードです。
Conclusion: the implementation with the largest difference in homogeneous comparison results is the lower bound on the equivalence threshold, noting that there may be other systematic errors to account for when comparing implementations.
結論：同種比較の結果に最大の違いがある実装は、同等性しきい値の下限です。実装を比較するときに考慮すべき他の系統誤差がある可能性があることに注意してください。
Thus, when evaluating equivalence in cross-implementation results:
したがって、クロス実装結果で同等性を評価する場合：
Maximum_Error = Same_Implementation_Error + Systematic_Error
Maximum_Error = Same_Implementation_Error + Systematic_Error
and only the systematic error need be decided beforehand.
また、系統誤差のみを事前に決定する必要があります。
In the case of ADK comparison, the largest same-implementation resolution of distribution equivalence can be used as a limit on cross-implementation resolutions (at the same confidence level).
ADK比較の場合、分布の同等性の最大の同じ実装解像度を、（同じ信頼レベルで）クロス実装解像度の制限として使用できます。
Gerhard Hasslinger commented a first draft version of this document; he suggested statistical tests and the evaluation of time series information. Matthias Wieser's thesis on a metric test resulted in new input for this document. Henk Uijterwaal and Lars Eggert have encouraged and helped to organize this work. Mike Hamilton, Scott Bradner, David Mcdysan, and Emile Stephan commented on this document. Carol Davids reviewed a version of the document before it became a WG item.
Gerhard Hasslingerがこのドキュメントの最初のドラフトバージョンにコメントしました。彼は統計的検定と時系列情報の評価を提案した。メトリックテストに関するMatthias Wieserの論文は、このドキュメントに新しい入力をもたらしました。 Henk UijterwaalとLars Eggertは、この作業の編成を奨励し、支援しました。 Mike Hamilton、Scott Bradner、David Mcdysan、およびEmile Stephanがこのドキュメントにコメントしました。 Carol Davidsは、WGアイテムになる前にドキュメントのバージョンをレビューしました。
Scott Bradner, Vern Paxson, and Allison Mankin drafted [METRICTEST], and major parts of it are included in this document.
Scott Bradner、Vern Paxson、Allison Mankinが[METRICTEST]を起草し、その主要部分がこのドキュメントに含まれています。
This memo does not raise any specific security issues.
このメモは特定のセキュリティ問題を引き起こしません。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、1998年5月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]タウンズリー、W。、バレンシア、A。、ルーベンス、A。、ポール、G。、ゾーン、G。、およびB.パルター、「レイヤー2トンネリングプロトコル "L2TP"」、RFC 2661、1999年8月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、2000年3月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「Layer Two Tunneling Protocol-Version 3（L2TPv3）」、RFC 3931、2005年3月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[RFC4448] Martini、L.、Rosen、E.、El-Aawar、N.、and G. Heron、 "Encapsulation Methods for Transport of Ethernet over MPLS Networks"、RFC 4448、April 2006。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、2006年9月。
[RFC4719] Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4719, November 2006.
[RFC4719] Aggarwal、R.、Townsley、M。、およびM. Dos Santos、「Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3（L2TPv3）」、RFC 4719、2006年11月。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.
[RFC4928] Swallow、G.、Bryant、S。、およびL. Andersson、「Avoiding Equal Cost Multipath Treatment in MPLS Networks」、BCP 128、RFC 4928、2007年6月。
[RFC5657] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
[RFC5657] Dusseault、L.およびR. Sparks、「相互運用に関するガイダンスおよびドラフト標準への移行に関する実装レポート」、BCP 9、RFC 5657、2009年9月。
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011.
[RFC6410] Housley、R.、Crocker、D。、およびE. Burger、「Reducing the Standards Track to Two Maturity Levels」、BCP 9、RFC 6410、2011年10月。
[ADK] Scholz, F. and M. Stephens, "K-sample Anderson-Darling Tests of Fit, for Continuous and Discrete Cases", University of Washington, Technical Report No. 81, May 1986.
[ADK] Scholz、F。およびM. Stephens、「K-サンプルAnderson-Darling Tests of Fit、for Continuous and Discrete Cases」、ワシントン大学、テクニカルレポートNo. 81、1986年5月。
[GU-Duffield] Gu, Y., Duffield, N., Breslau, L., and S. Sen, "GRE Encapsulated Multicast Probing: A Scalable Technique for Measuring One-Way Loss", SIGMETRICS'07 San Diego, California, USA, June 2007.
[GU-Duffield] Gu、Y.、Duffield、N.、Breslau、L。、およびS. Sen、「GREカプセル化マルチキャストプローブ：一方向損失を測定するためのスケーラブルな手法」、SIGMETRICS'07、カリフォルニア州サンディエゴ、米国、2007年6月。
[METRICTEST] Bradner, S. and V. Paxson, "Advancement of metrics specifications on the IETF Standards Track", Work in Progress, August 2007.
[METRICTEST] Bradner、S。およびV. Paxson、「IETF Standards Trackでのメトリック仕様の拡張」、2007年8月、Work in Progress、
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459] Savola、P。、「MTUおよびFragmentation Issues with In-the-Network Tunneling」、RFC 4459、2006年4月。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、2008年10月。
[Radk] Scholz, F., "adk: Anderson-Darling K-Sample Test and Combinations of Such Tests. R package version 1.0", 2008.
[Radk] Scholz、F。、「adk：Anderson-Darling K-Sample Test and Combinations of such Tests。R package version 1.0」、2008年。
[Rtool] R Development Core Team, "R: A language and environment for statistical computing. R Foundation for Statistical Computing, Vienna, Austria. ISBN 3-900051-07-0", 2011, <http://www.R-project.org/>.
[Rtool] R開発コアチーム、「R：統計計算のための言語と環境。RFoundation for Statistical Computing、ウィーン、オーストリア。ISBN3-900051-07-0 "、2011、<http：//www.R- project.org/>。
[TESTPLAN] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test Plan and Results for Advancing RFC 2679 on the Standards Track", Work in Progress, March 2012.
[テストプラン] Ciavattone、L.、Geib、R.、Morton、A。、およびM. Wieser、「Test Plan and Results for Advancing RFC 2679 on the Standards Track」、Work in Progress、2012年3月。
The text of this appendix is not binding. It is an example of what parts of a One-Way Delay Metric test could look like.
この付録の本文は拘束力を持ちません。これは、一方向遅延メトリックテストの一部の例です。
One-Way Delay, Loss Threshold, RFC 2679
一方向遅延、損失しきい値、RFC 2679
This test determines if implementations use the same configured maximum waiting time delay from one measurement to another under different delay conditions and correctly declare packets arriving in excess of the waiting time threshold as lost. See Sections 3.5 (3rd bullet point) and 3.8.2 of [RFC2679].
このテストは、実装が異なる遅延条件下である測定から別の測定まで同じ構成された最大待機時間遅延を使用するかどうかを判断し、待機時間のしきい値を超えて到着したパケットが失われたと正しく宣言します。 [RFC2679]のセクション3.5（3番目の箇条書き）および3.8.2を参照してください。
(1) Configure a path with 1-second one-way constant delay.
（1）1秒の一方向の一定の遅延でパスを構成します。
(2) Measure one-way delay with 2 or more implementations, using identical waiting time thresholds for loss set at 2 seconds.
（2）2秒に設定された損失の同一の待機時間しきい値を使用して、2つ以上の実装で一方向遅延を測定します。
(3) Configure the path with 3-second one-way delay.
（3）3秒の一方向遅延でパスを構成します。
(4) Repeat measurements.
（4）測定を繰り返します。
(5) Observe that the increase measured in step 4 caused all packets to be declared lost and that all packets that arrive successfully in step 2 are assigned a valid one-way delay.
（5）手順4で測定された増加によりすべてのパケットが失われたと宣言され、手順2で正常に到着したすべてのパケットに有効な一方向遅延が割り当てられていることを確認します。
One-Way Delay, First Bit to Last Bit, RFC 2679
一方向遅延、最初のビットから最後のビット、RFC 2679
This test determines if implementations register the same relative increase in delay from one measurement to another under different delay conditions. This test tends to cancel the sources of error that may be present in an implementation. See Section 3.7.2 of [RFC2679] and Section 10.2 of [RFC2330].
このテストは、実装が、異なる遅延条件下でのある測定から別の測定への同じ相対的遅延増加を登録するかどうかを決定します。このテストは、実装に存在する可能性のあるエラーの原因をキャンセルする傾向があります。 [RFC2679]のセクション3.7.2および[RFC2330]のセクション10.2を参照してください。
(1) Configure a path with X ms one-way constant delay and ideally include a low-speed link.
（1）X msの一方向一定遅延でパスを構成し、理想的には低速リンクを含める。
(2) Measure one-way delay with 2 or more implementations, using identical options and equal size small packets (e.g., 100 octet IP payload).
（2）同じオプションと同じサイズの小さなパケット（100オクテットのIPペイロードなど）を使用して、2つ以上の実装で一方向の遅延を測定します。
(3) Maintain the same path with X ms one-way delay.
（3）X ms一方向遅延で同じパスを維持します。
(4) Measure one-way delay with 2 or more implementations, using identical options and equal size large packets (e.g., 1500 octet IP payload).
（4）同じオプションと同じサイズの大きなパケット（1500オクテットのIPペイロードなど）を使用して、2つ以上の実装で一方向の遅延を測定します。
(5) Observe that the increase measured in steps 2 and 4 is equivalent to the increase in ms expected due to the larger serialization time for each implementation. Most of the measurement errors in each system should cancel, if they are stationary.
（5）ステップ2と4で測定された増加は、各実装のシリアル化時間が長いために予想されるmsの増加と同じであることを確認します。各システムの測定誤差のほとんどは、静止している場合はキャンセルする必要があります。
One-Way Delay, RFC 2679
一方向遅延、RFC 2679
This test determines if implementations register the same relative increase in delay from one measurement to another under different delay conditions. This test tends to cancel the sources of error that may be present in an implementation. This test is intended to evaluate measurements in Sections 3 and 4 of [RFC2679].
このテストは、実装が、異なる遅延条件下でのある測定から別の測定への同じ相対的遅延増加を登録するかどうかを決定します。このテストは、実装に存在する可能性のあるエラーの原因をキャンセルする傾向があります。このテストは、[RFC2679]のセクション3および4の測定を評価することを目的としています。
(1) Configure a path with X ms one-way constant delay.
（1）X msの一方向一定遅延でパスを構成します。
(2) Measure one-way delay with 2 or more implementations, using identical options.
（2）同じオプションを使用して、2つ以上の実装で一方向の遅延を測定します。
(3) Configure the path with X+Y ms one-way delay.
（3）X + Yミリ秒の一方向遅延でパスを構成します。
(4) Repeat measurements.
（4）測定を繰り返します。
(5) Observe that the increase measured in steps 2 and 4 is ~Y ms for each implementation. Most of the measurement errors in each system should cancel, if they are stationary.
（5）手順2と4で測定された増加が各実装で〜Y msであることを確認します。各システムの測定誤差のほとんどは、静止している場合はキャンセルする必要があります。
Error Calibration, RFC 2679
エラーキャリブレーション、RFC 2679
This is a simple check to determine if an implementation reports the error calibration as required in Section 4.8 of [RFC2679]. Note that the context (Type-P) must also be reported.
これは、[RFC2679]のセクション4.8で要求されているように、実装がエラー調整を報告しているかどうかを判断するための簡単なチェックです。コンテキスト（Type-P）も報告する必要があることに注意してください。
A one-way delay measurement may pass an ADK test with a timestamp result of 1 ms. The same test may fail if timestamps with a resolution of 100 microseconds are evaluated. The implementation is then conforming to the metric specification up to a timestamp resolution of 1 ms.
一方向遅延測定は、1ミリ秒のタイムスタンプ結果でADKテストに合格する場合があります。 100マイクロ秒の分解能を持つタイムスタンプが評価されると、同じテストが失敗する可能性があります。実装は、1 msのタイムスタンプ分解能までのメトリック仕様に準拠しています。
Let's assume another one-way delay measurement comparison between implementation 1 probing with a frequency of 2 probes per second and implementation 2 probing at a rate of 2 probes every 3 minutes. To ensure reasonable confidence in results, sample metrics are calculated from at least 5 singletons per compared time interval. This means that sample delay values are calculated for each system for identical 6-minute intervals for the duration of the whole test.
1秒あたり2プローブの頻度での実装1プローブと3分ごとに2プローブの速度での実装2プローブの間の別の一方向遅延測定比較を想定します。結果の妥当な信頼性を確保するために、サンプルメトリックは、比較された時間間隔ごとに少なくとも5つのシングルトンから計算されます。これは、サンプル全体の遅延値が、システム全体で、テスト全体にわたって同一の6分の間隔で計算されることを意味します。
Per 6-minute interval, the sample metric is calculated from 720 singletons for implementation 1 and from 6 singletons for implementation 2. Note that if outliers are not filtered, moving averages are an option for an evaluation too. The minimum move of an averaging interval is three minutes in this example.
6分の間隔ごとに、サンプルメトリックは実装1の720シングルトンと実装2の6シングルトンから計算されます。外れ値がフィルターされていない場合、移動平均も評価のオプションです。この例では、平均化間隔の最小移動は3分です。
The data in Table 1 may result from measuring one-way delay with implementation 1 (see column Implemnt_1) and implementation 2 (see column Implemnt_2). Each data point in the table represents a (rounded) average of the sampled delay values per interval. The resolution of the clock is one micro-second. The difference in the delay values may result, e.g., from different probe packet sizes.
表1のデータは、実装1（列Implemnt_1を参照）および実装2（列Implemnt_2を参照）を使用して一方向遅延を測定した結果である可能性があります。表の各データポイントは、間隔ごとにサンプリングされた遅延値の（丸められた）平均を表します。クロックの分解能は1マイクロ秒です。遅延値の違いは、たとえば、異なるプローブパケットサイズに起因する場合があります。
+------------+------------+-----------------------------+
| Implemnt_1 | Implemnt_2 | Implemnt_2 - Delta_Averages |
+------------+------------+-----------------------------+
| 5000 | 6549 | 4997 |
| 5008 | 6555 | 5003 |
| 5012 | 6564 | 5012 |
| 5015 | 6565 | 5013 |
| 5019 | 6568 | 5016 |
| 5022 | 6570 | 5018 |
| 5024 | 6573 | 5021 |
| 5026 | 6575 | 5023 |
| 5027 | 6577 | 5025 |
| 5029 | 6580 | 5028 |
| 5030 | 6585 | 5033 |
| 5032 | 6586 | 5034 |
| 5034 | 6587 | 5035 |
| 5036 | 6588 | 5036 |
| 5038 | 6589 | 5037 |
| 5039 | 6591 | 5039 |
| 5041 | 6592 | 5040 |
| 5043 | 6599 | 5047 |
| 5046 | 6606 | 5054 |
| 5054 | 6612 | 5060 |
+------------+------------+-----------------------------+
Table 1
表1
Average values of sample metrics captured during identical time intervals are compared. This excludes random differences caused by differing probing intervals or differing temporal distance of singletons resulting from their Poisson-distributed sending times.
同じ時間間隔で取得されたサンプルメトリックの平均値が比較されます。これは、プロービング間隔の違いや、ポアソン分布の送信時間に起因するシングルトンの時間的距離の違いによって生じるランダムな違いを除外します。
In the example, 20 values have been picked (note that at least 100 values are recommended for a single run of a real test). Data must be ordered by ascending rank. The data of Implemnt_1 and Implemnt_2 as shown in the first two columns of Table 1 clearly fails an ADK test with 95% confidence.
この例では、20個の値が選択されています（実際のテストの1回の実行には、少なくとも100個の値が推奨されることに注意してください）。データは昇順で並べる必要があります。表1の最初の2列に示されているImplemnt_1とImplemnt_2のデータは、95％の信頼度でADKテストに明らかに失敗しています。
The results of Implemnt_2 are now reduced by the difference of the averages of column 2 (rounded to 6581 us) and column 1 (rounded to 5029 us), which is 1552 us. The result may be found in column 3 of Table 1. Comparing column 1 and column 3 of the table by an ADK test shows that the data contained in these columns passes an ADK test with 95% confidence.
Implemnt_2の結果は、列2（6581 usに四捨五入）と列1（5029 usに四捨五入）の平均の差（1552 us）によって減少します。結果は表1の列3で確認できます。ADKテストで表の列1と列3を比較すると、これらの列に含まれるデータは95％の信頼度でADKテストに合格しています。
Comment: Extensive averaging was used in this example because of the vastly different sampling frequencies. As a result, the distributions compared do not exactly align with a metric in [RFC2679] but illustrate the ADK process adequately.
コメント：サンプリング周波数が大きく異なるため、この例では広範な平均化を使用しました。その結果、比較された分布は[RFC2679]のメトリックと正確に一致していませんが、ADKプロセスを適切に示しています。
Appendix B. Anderson-Darling K-sample Reference and 2 Sample C++ Code
付録B. Anderson-Darling K-sampleリファレンスおよび2つのサンプルC ++コード
There are many statistical tools available, and this appendix describes two that are familiar to the authors.
利用可能な多くの統計ツールがあり、この付録では、作成者がよく知っている2つの統計ツールについて説明します。
The "R tool" is a language and command-line environment for statistical computing and plotting [Rtool]. With the optional "adk" package installed [Radk], it can perform individual and combined sample ADK computations. The user must consult the package documentation and the original paper [ADK] to interpret the results, but this is as it should be.
「Rツール」は、統計計算とプロットのための言語とコマンドライン環境です[Rtool]。オプションの「adk」パッケージがインストールされている[Radk]を使用すると、個別のサンプルADKと組み合わせたサンプルADKの計算を実行できます。ユーザーは結果を解釈するために、パッケージのドキュメントと元のペーパー[ADK]を参照する必要がありますが、これは本来の状態です。
The C++ code below will perform an AD2-sample comparison when compiled and presented with two column vectors in a file (using white space as separation). This version contains modifications made by Wes Eddy in Sept 2011 to use the vectors and run as a stand-alone module. The status of the comparison can be checked on the command line with "$ echo $?" or the last line can be replaced with a printf statement for adk_result instead.
以下のC ++コードは、ファイル内に2つの列ベクトルを使用して（空白を分離として使用して）コンパイルおよび表示すると、AD2サンプル比較を実行します。このバージョンには、ベクターを使用してスタンドアロンモジュールとして実行するために2011年9月にウェスエディによって行われた変更が含まれています。比較のステータスは、コマンドラインで「$ echo $？」を使用して確認できます。または、最後の行を代わりにadk_resultのprintfステートメントで置き換えることができます。
/*
Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2012 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず、IETF文書に関連するIETFトラストの法的規定のセクション4.cに記載されているSimplified BSD Licenseに従い、それに含まれるライセンス条項に従って許可されます（ http://trustee.ietf.org/license-info）。
*/
＊／
/* Routines for computing the Anderson-Darling 2 sample
* test statistic.
*
* Implemented based on the description in
* "Anderson-Darling K Sample Test" Heckert, Alan and
* Filliben, James, editors, Dataplot Reference Manual,
* Chapter 15 Auxiliary, NIST, 2004.
* Official Reference by 2010
* Heckert, N. A. (2001). Dataplot website at the
* National Institute of Standards and Technology:
* http://www.itl.nist.gov/div898/software/dataplot.html/
* June 2001.
*/
#include <iostream>
#include <fstream>
#include <vector>
#include <sstream>
using namespace std;
名前空間stdを使用します。
int main() {
vector<double> vec1, vec2;
double adk_result;
static int k, val_st_z_samp1, val_st_z_samp2,
val_eq_z_samp1, val_eq_z_samp2,
j, n_total, n_sample1, n_sample2, L,
max_number_samples, line, maxnumber_z;
static int column_1, column_2;
static double adk, n_value, z, sum_adk_samp1,
sum_adk_samp2, z_aux;
static double H_j, F1j, hj, F2j, denom_1_aux, denom_2_aux;
static bool next_z_sample2, equal_z_both_samples;
static int stop_loop1, stop_loop2, stop_loop3,old_eq_line2,
old_eq_line1;
static double adk_criterium = 1.993;
静的な二重adk_criterium = 1.993;
/* vec1 and vec2 to be initialized with sample 1 and
* sample 2 values in ascending order */
while (!cin.eof()) {
double f1, f2;
cin >> f1;
cin >> f2;
vec1.push_back(f1);
vec2.push_back(f2);
}
｝
k = 2;
n_sample1 = vec1.size() - 1;
n_sample2 = vec2.size() - 1;
// -1 because vec[0] is a dummy value
n_total = n_sample1 + n_sample2;
/* value equal to the line with a value = zj in sample 1.
* Here j=1, so the line is 1.
*/
val_eq_z_samp1 = 1;
/* value equal to the line with a value = zj in sample 2.
* Here j=1, so the line is 1.
*/
val_eq_z_samp2 = 1;
/* value equal to the last line with a value < zj
* in sample 1. Here j=1, so the line is 0.
*/
val_st_z_samp1 = 0;
/* value equal to the last line with a value < zj
* in sample 1. Here j=1, so the line is 0.
*/
val_st_z_samp2 = 0;
sum_adk_samp1 = 0;
sum_adk_samp2 = 0;
j = 1;
// as mentioned above, j=1
equal_z_both_samples = false;
next_z_sample2 = false;
next_z_sample2 = false;
//assuming the next z to be of sample 1
stop_loop1 = n_sample1 + 1;
// + 1 because vec[0] is a dummy, see n_sample1 declaration
stop_loop2 = n_sample2 + 1;
stop_loop3 = n_total + 1;
/* The required z values are calculated until all values
* of both samples have been taken into account. See the
* lines above for the stoploop values. Construct required
* to avoid a mathematical operation in the while condition.
*/
while (((stop_loop1 > val_eq_z_samp1)
|| (stop_loop2 > val_eq_z_samp2)) && stop_loop3 > j)
{
if(val_eq_z_samp1 < n_sample1+1)
{
/* here, a preliminary zj value is set.
* See below how to calculate the actual zj.
*/
z = vec1[val_eq_z_samp1];
/* this while sequence calculates the number of values
* equal to z.
*/
while ((val_eq_z_samp1+1 < n_sample1)
&& z == vec1[val_eq_z_samp1+1] )
{
val_eq_z_samp1++;
}
}
else
{
val_eq_z_samp1 = 0;
val_st_z_samp1 = n_sample1;
// this should be val_eq_z_samp1 - 1 = n_sample1
}
if(val_eq_z_samp2 < n_sample2+1)
{
z_aux = vec2[val_eq_z_samp2];;
/* this while sequence calculates the number of values
* equal to z_aux
*/
while ((val_eq_z_samp2+1 < n_sample2)
&& z_aux == vec2[val_eq_z_samp2+1] )
{
val_eq_z_samp2++;
}
/* the smaller of the two actual data values is picked
* as the next zj.
*/
if(z > z_aux)
if（z> z_aux）
{
z = z_aux;
next_z_sample2 = true;
}
else
{
if (z == z_aux)
{
equal_z_both_samples = true;
}
/* This is the case if the last value of column1 is
* smaller than the remaining values of column2.
*/
if (val_eq_z_samp1 == 0)
{
z = z_aux;
next_z_sample2 = true;
}
}
}
else
{
val_eq_z_samp2 = 0;
val_st_z_samp2 = n_sample2;
// this should be val_eq_z_samp2 - 1 = n_sample2
}
｝
/* in the following, sum j = 1 to L is calculated for
* sample 1 and sample 2.
*/
if (equal_z_both_samples)
{
/* hj is the number of values in the combined sample
* equal to zj
*/
hj = val_eq_z_samp1 - val_st_z_samp1
+ val_eq_z_samp2 - val_st_z_samp2;
/* H_j is the number of values in the combined sample
* smaller than zj plus one half the number of
* values in the combined sample equal to zj
* (that's hj/2).
*/
H_j = val_st_z_samp1 + val_st_z_samp2
+ hj / 2;
+ hj / 2;
/* F1j is the number of values in the 1st sample
* that are less than zj plus one half the number
* of values in this sample that are equal to zj.
*/
F1j = val_st_z_samp1 + (double)
(val_eq_z_samp1 - val_st_z_samp1) / 2;
/* F2j is the number of values in the 1st sample
* that are less than zj plus one half the number
* of values in this sample that are equal to zj.
*/
F2j = val_st_z_samp2 + (double)
(val_eq_z_samp2 - val_st_z_samp2) / 2;
/* set the line of values equal to zj to the
* actual line of the last value picked for zj.
*/
val_st_z_samp1 = val_eq_z_samp1;
/* Set the line of values equal to zj to the actual
* line of the last value picked for zj of each
* sample. This is required as data smaller than zj
* is accounted differently than values equal to zj.
*/
val_st_z_samp2 = val_eq_z_samp2;
/* next the lines of the next values z, i.e., zj+1
* are addressed.
*/
val_eq_z_samp1++;
/* next the lines of the next values z, i.e.,
* zj+1 are addressed
*/
val_eq_z_samp2++;
}
else
{
/* the smaller z value was contained in sample 2;
* hence, this value is the zj to base the following
* calculations on.
*/
if (next_z_sample2)
{
/* hj is the number of values in the combined
* sample equal to zj; in this case, these are
* within sample 2 only.
*/
hj = val_eq_z_samp2 - val_st_z_samp2;
/* H_j is the number of values in the combined sample
* smaller than zj plus one half the number of
* values in the combined sample equal to zj
* (that's hj/2).
*/
H_j = val_st_z_samp1 + val_st_z_samp2
+ hj / 2;
/* F1j is the number of values in the 1st sample that
* are less than zj plus one half the number of values in
* this sample that are equal to zj.
* As val_eq_z_samp2 < val_eq_z_samp1, these are the
* val_st_z_samp1 only.
*/
F1j = val_st_z_samp1;
/* F2j is the number of values in the 1st sample that
* are less than zj plus one half the number of values in
* this sample that are equal to zj. The latter are from
* sample 2 only in this case.
*/
F2j = val_st_z_samp2 + (double)
(val_eq_z_samp2 - val_st_z_samp2) / 2;
/* Set the line of values equal to zj to the actual line
* of the last value picked for zj of sample 2 only in
* this case.
*/
val_st_z_samp2 = val_eq_z_samp2;
/* next the line of the next value z, i.e., zj+1 is
* addressed. Here, only sample 2 must be addressed.
*/
val_eq_z_samp2++;
if (val_eq_z_samp1 == 0)
{
val_eq_z_samp1 = stop_loop1;
}
}
/* the smaller z value was contained in sample 2;
* hence, this value is the zj to base the following
* calculations on.
*/
else {
そうしないと {
/* hj is the number of values in the combined
* sample equal to zj; in this case, these are
* within sample 1 only.
*/
hj = val_eq_z_samp1 - val_st_z_samp1;
/* H_j is the number of values in the combined
* sample smaller than zj plus one half the number
* of values in the combined sample equal to zj
* (that's hj/2).
*/
H_j = val_st_z_samp1 + val_st_z_samp2
+ hj / 2;
/* F1j is the number of values in the 1st sample that
* are less than zj plus; in this case, these are within
* sample 1 only one half the number of values in this
* sample that are equal to zj. The latter are from
* sample 1 only in this case.
*/
F1j = val_st_z_samp1 + (double)
(val_eq_z_samp1 - val_st_z_samp1) / 2;
/* F2j is the number of values in the 1st sample that
* are less than zj plus one half the number of values
* in this sample that are equal to zj. As
* val_eq_z_samp1 < val_eq_z_samp2, these are the
* val_st_z_samp2 only.
*/
F2j = val_st_z_samp2;
F2j = val_st_z_samp2;
/* Set the line of values equal to zj to the actual line
* of the last value picked for zj of sample 1 only in
* this case.
*/
val_st_z_samp1 = val_eq_z_samp1;
val_st_z_samp1 = val_eq_z_samp1;
/* next the line of the next value z, i.e., zj+1 is
* addressed. Here, only sample 1 must be addressed.
*/
val_eq_z_samp1++;
if (val_eq_z_samp2 == 0)
{
val_eq_z_samp2 = stop_loop2;
}
}
}
denom_1_aux = n_total * F1j - n_sample1 * H_j;
denom_2_aux = n_total * F2j - n_sample2 * H_j;
sum_adk_samp1 = sum_adk_samp1 + hj
* (denom_1_aux * denom_1_aux) /
(H_j * (n_total - H_j)
- n_total * hj / 4);
sum_adk_samp2 = sum_adk_samp2 + hj
* (denom_2_aux * denom_2_aux) /
(H_j * (n_total - H_j)
- n_total * hj / 4);
next_z_sample2 = false;
equal_z_both_samples = false;
/* index to count the z. It is only required to prevent
* the while slope to execute endless
*/
j++;
}
// calculating the adk value is the final step.
adk_result = (double) (n_total - 1) / (n_total
* n_total * (k - 1))
* (sum_adk_samp1 / n_sample1
+ sum_adk_samp2 / n_sample2);
/* if(adk_result <= adk_criterium)
* adk_2_sample test is passed
*/
return adk_result <= adk_criterium;
}
+-------------+-----------------------------------------------------+
| ADK | Anderson-Darling K-Sample test, a test used to |
| | check whether two samples have the same statistical |
| | distribution. |
| ECMP | Equal Cost Multipath, a load-balancing mechanism |
| | evaluating MPLS Labels stacks, IP addresses, and |
| | ports. |
| EDF | The "empirical distribution function" of a set of |
| | scalar measurements is a function F(x), which for |
| | any x gives the fractional proportion of the total |
| | measurements that were smaller than or equal to x. |
| Metric | A measured quantity related to the performance and |
| | reliability of the Internet, expressed by a value. |
| | This could be a singleton (single value), a sample |
| | of single values, or a statistic based on a sample |
| | of singletons. |
| OWAMP | One-Way Active Measurement Protocol, a protocol for |
| | communication between IPPM measurement systems |
| | specified by IPPM. |
| OWD | One-Way Delay, a performance metric specified by |
| | IPPM. |
| Sample | A sample metric is derived from a given singleton |
| metric | metric by evaluating a number of distinct instances |
| | together. |
| Singleton | A singleton metric is, in a sense, one atomic |
| metric | measurement of this metric. |
| Statistical | A 'statistical' metric is derived from a given |
| metric | sample metric by computing some statistic of the |
| | values defined by the singleton metric on the |
| | sample. |
| TWAMP | Two-way Active Measurement Protocol, a protocol for |
| | communication between IPPM measurement systems |
| | specified by IPPM. |
+-------------+-----------------------------------------------------+
Authors' Addresses
著者のアドレス
Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany
Ruediger Geib（編集者）Deutsche Telekom Heinrich Hertz Str。 3-7ダルムシュタット64295ドイツ
Phone: +49 6151 58 12747
EMail: Ruediger.Geib@telekom.de
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
Al Morton AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748 USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Reza Fardid Cariden Technologies 888 Villa Street, Suite 500 Mountain View, CA 94041 USA
Reza Fardid Cariden Technologies 888 Villa Street、Suite 500 Mountain View、CA 94041 USA
Phone: EMail: rfardid@cariden.com
電話：メール：rfardid@cariden.com
Alexander Steinmitz Deutsche Telekom Memmelsdorfer Str. 209b Bamberg 96052 Germany
Alexander Steinmitz Deutsche Telekom Memmelsdorfer Str。 209bバンベルク96052ドイツ
Phone: EMail: Alexander.Steinmitz@telekom.de
電話：メール：Alexander.Steinmitz@telekom.de