[要約] RFC 6808は、RFC 2679の進行を支援するためのテスト計画と結果を提供するものです。その目的は、RFC 2679の標準化プロセスを進めるために必要なテストの実施と結果の文書化を行うことです。
Internet Engineering Task Force (IETF) L. Ciavattone
Request for Comments: 6808 AT&T Labs
Category: Informational R. Geib
ISSN: 2070-1721 Deutsche Telekom
A. Morton
AT&T Labs
M. Wieser
Technical University Darmstadt
December 2012
Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track
標準化過程におけるRFC 2679の進歩をサポートするテスト計画と結果
Abstract
概要
This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679.
このメモは、RFC 6576のプロセスに従って、Standards Trackに沿った一方向遅延メトリックでRFC 2679を進めるためのサポートするテスト計画と結果を提供します。メトリックの実装自体ではなく、メトリック定義自体が主な焦点であるべきであることに注意してください。メモは、特定のメトリック要件節を評価して、要件が意図したとおりに解釈および実装されているかどうかを判断するためのテスト手順を説明しています。 RFC 2679の主要な仕様に対して2つの完全に独立した実装がテストされています。このメモは、RFC 2679の改訂版の開発に直接入力することもできます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6808.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6808で入手できます。
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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. A Definition-Centric Metric Advancement Process .................5
3. Test Configuration ..............................................5
4. Error Calibration, RFC 2679 .....................................9
4.1. NetProbe Error and Type-P .................................10
4.2. Perfas+ Error and Type-P ..................................12
5. Predetermined Limits on Equivalence ............................12
6. Tests to Evaluate RFC 2679 Specifications ......................13
6.1. One-Way Delay, ADK Sample Comparison: Same- and Cross-
Implementation ............................................13
6.1.1. NetProbe Same-Implementation Results ...............15
6.1.2. Perfas+ Same-Implementation Results ................16
6.1.3. One-Way Delay, Cross-Implementation ADK
Comparison .........................................16
6.1.4. Conclusions on the ADK Results for One-Way Delay ...17
6.1.5. Additional Investigations ..........................17
6.2. One-Way Delay, Loss Threshold, RFC 2679 ...................20
6.2.1. NetProbe Results for Loss Threshold ................21
6.2.2. Perfas+ Results for Loss Threshold .................21
6.2.3. Conclusions for Loss Threshold .....................21
6.3. One-Way Delay, First Bit to Last Bit, RFC 2679 ............21
6.3.1. NetProbe and Perfas+ Results for Serialization .....22
6.3.2. Conclusions for Serialization ......................23
6.4. One-Way Delay, Difference Sample Metric ...................24
6.4.1. NetProbe Results for Differential Delay ............24
6.4.2. Perfas+ Results for Differential Delay .............25
6.4.3. Conclusions for Differential Delay .................25
6.5. Implementation of Statistics for One-Way Delay ............25
7. Conclusions and RFC 2679 Errata ................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................27
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................28
The IETF IP Performance Metrics (IPPM) working group has considered how to advance their metrics along the Standards Track since 2001, with the initial publication of Bradner/Paxson/Mankin's memo [METRICS-TEST]. The original proposal was to compare the performance of metric implementations. This was similar to the usual procedures for advancing protocols, which did not directly apply. It was found to be difficult to achieve consensus on exactly how to compare implementations, since there were many legitimate sources of variation that would emerge in the results despite the best attempts to keep the network paths equal, and because considerable variation was allowed in the parameters (and therefore implementation) of each metric. Flexibility in metric definitions, essential for customization and broad appeal, made the comparison task quite difficult.
IETF IP Performance Metrics（IPPM）ワーキンググループは、2001年以降、Bradner / Paxson / Mankinのメモ[METRICS-TEST]の最初の発行とともに、標準化トラックに沿ってメトリックを進める方法を検討しています。最初の提案は、メトリック実装のパフォーマンスを比較することでした。これは、直接適用されない、プロトコルを進めるための通常の手順に似ていました。ネットワークパスを同じに保つための最善の試みにもかかわらず、パラメータにかなりの変動が許可されているため、結果に現れる変動の正当な原因が多数あったため、実装を正確に比較する方法についてコンセンサスを得ることが難しいことがわかりました各メトリックの（したがって、実装）。カスタマイズと幅広いアピールに不可欠なメトリック定義の柔軟性により、比較作業が非常に困難になりました。
A renewed work effort investigated ways in which the measurement variability could be reduced and thereby simplify the problem of comparison for equivalence.
更新された作業では、測定のばらつきを減らし、それによって同等性の比較の問題を単純化できる方法を調査しました。
The consensus process documented in [RFC6576] is that metric definitions rather than the implementations of metrics should be the primary focus of evaluation. Equivalent test results are deemed to be evidence that the metric specifications are clear and unambiguous. This is now the metric specification equivalent of protocol interoperability. The [RFC6576] advancement process either produces confidence that the metric definitions and supporting material are clearly worded and unambiguous, or it identifies ways in which the metric definitions should be revised to achieve clarity.
[RFC6576]で文書化されているコンセンサスプロセスは、評価指標の実装ではなく評価指標の定義が評価の主な焦点であるべきであるということです。同等のテスト結果は、メトリックの仕様が明確で明確であることの証拠と見なされます。これは、プロトコルの相互運用性に相当するメトリック仕様になりました。 [RFC6576]進歩プロセスは、メトリック定義と補足資料が明確に記述され、明確であることを確信させるか、または明確にするためにメトリック定義を修正する方法を特定します。
The metric RFC advancement process requires documentation of the testing and results. [RFC6576] retains the testing requirement of the original Standards Track advancement process described in [RFC2026] and [RFC5657], because widespread deployment is insufficient to determine whether RFCs that define performance metrics result in consistent implementations.
メトリックRFCの進歩プロセスでは、テストと結果の文書化が必要です。 [RFC6576]は、[RFC2026]と[RFC5657]で説明されている元のスタンダードトラックアドバンスプロセスのテスト要件を保持しています。
The process also permits identification of options that were not implemented, so that they can be removed from the advancing specification (this is a similar aspect to protocol advancement along the Standards Track). All errata must also be considered.
このプロセスでは、実装されなかったオプションを識別できるため、それらを拡張仕様から削除できます（これは、標準トラックに沿ったプロトコル拡張と同様の側面です）。すべてのエラッタも考慮する必要があります。
This memo's purpose is to implement the advancement process of [RFC6576] for [RFC2679]. It supplies the documentation that accompanies the protocol action request submitted to the Area Director, including description of the test setup, results for each implementation, evaluation of each metric specification, and conclusions.
このメモの目的は、[RFC2679]の[RFC6576]の進歩プロセスを実装することです。テストセットアップの説明、各実装の結果、各メトリック仕様の評価、結論など、Area Directorに送信されたプロトコルアクションリクエストに付随するドキュメントを提供します。
In particular, this memo documents the consensus on the extent of tolerable errors when assessing equivalence in the results. The IPPM working group agreed that the test plan and procedures should include the threshold for determining equivalence, and that this aspect should be decided in advance of cross-implementation comparisons. This memo includes procedures for same-implementation comparisons that may influence the equivalence threshold.
特に、このメモは、結果の同等性を評価する際の許容可能なエラーの程度に関するコンセンサスを文書化しています。 IPPMワーキンググループは、テスト計画と手順に同等性を判断するためのしきい値を含める必要があること、およびこの側面は実装間の比較の前に決定する必要があることに同意しました。このメモには、同等のしきい値に影響を与える可能性のある同じ実装の比較の手順が含まれています。
Although the conclusion reached through testing is that [RFC2679] should be advanced on the Standards Track with modifications, the revised text of RFC 2679 is not yet ready for review. Therefore, this memo documents the information to support [RFC2679] advancement, and the approval of a revision of RFC 2769 is left for future action.
テストを通じて到達した結論は、[RFC2679]を変更して標準トラックで進める必要があるということですが、RFC 2679の改訂テキストはまだレビューの準備ができていません。したがって、このメモは[RFC2679]の進歩をサポートするための情報を文書化しており、RFC 2769の改訂の承認は将来の行動に委ねられています。
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]で説明されているように解釈されます。
As a first principle, the process described in Section 3.5 of [RFC6576] takes the fact that the metric definitions (embodied in the text of the RFCs) are the objects that require evaluation and possible revision in order to advance to the next step on the Standards Track. This memo follows that process.
最初の原則として、[RFC6576]のセクション3.5で説明されているプロセスは、メトリック定義（RFCのテキストで具体化）が、次のステップに進むために評価と修正が必要なオブジェクトであるという事実を取ります標準トラック。このメモはそのプロセスに従います。
One metric implementation used was NetProbe version 5.8.5 (an earlier version is used in AT&T's IP network performance measurement system and deployed worldwide [WIPM]). NetProbe uses UDP packets of variable size, and it can produce test streams with Periodic [RFC3432] or Poisson [RFC2330] sample distributions.
使用されたメトリック実装の1つはNetProbeバージョン5.8.5でした（以前のバージョンはAT＆TのIPネットワークパフォーマンス測定システムで使用され、世界中に展開されています[WIPM]）。 NetProbeは可変サイズのUDPパケットを使用し、定期[RFC3432]またはポアソン[RFC2330]サンプル分布を使用してテストストリームを生成できます。
The other metric implementation used was Perfas+ version 3.1, developed by Deutsche Telekom [Perfas]. Perfas+ uses UDP unicast packets of variable size (but also supports TCP and multicast). Test streams with Periodic, Poisson, or uniform sample distributions may be used.
使用されたもう1つのメトリック実装は、Deutsche Telekom [Perfas]によって開発されたPerfas +バージョン3.1でした。 Perfas +は、可変サイズのUDPユニキャストパケットを使用します（TCPとマルチキャストもサポートします）。定期的、ポアソン、または均一なサンプル分布のテストストリームを使用できます。
Figure 1 shows a view of the test path as each implementation's test flows pass through the Internet and the Layer 2 Tunneling Protocol, version 3 (L2TPv3) tunnel IDs (1 and 2), based on Figures 2 and 3 of [RFC6576].
図1は、[RFC6576]の図2および3に基づいて、各実装のテストフローがインターネットとレイヤ2トンネリングプロトコル、バージョン3（L2TPv3）トンネルID（1および2）を通過するときのテストパスのビューを示しています。
+----+ +----+ +----+ +----+
|Imp1| |Imp1| ,---. |Imp2| |Imp2|
+----+ +----+ / \ +-------+ +----+ +----+
| V100 | V200 / \ | Tunnel| | V300 | V400
| | ( ) | Head | | |
+--------+ +------+ | |__| Router| +----------+
|Ethernet| |Tunnel| |Internet | +---B---+ |Ethernet |
|Switch |--|Head |-| | | |Switch |
+-+--+---+ |Router| | | +---+---+--+--+--+----+
|__| +--A---+ ( ) |Network| |__|
\ / |Emulat.|
U-turn \ / |"netem"| U-turn
V300 to V400 `-+-' +-------+ V100 to V200
Implementations ,---. +--------+
+~~~~~~~~~~~/ \~~~~~~| Remote |
+------->-----F2->-| / \ |->---. |
| +---------+ | Tunnel ( ) | | |
| | transmit|-F1->-| ID 1 ( ) |->. | |
| | Imp 1 | +~~~~~~~~~| |~~~~| | | |
| | receive |-<--+ ( ) | F1 F2 |
| +---------+ | |Internet | | | | |
*-------<-----+ F1 | | | | | |
+---------+ | | +~~~~~~~~~| |~~~~| | | |
| transmit|-* *-| | | |<-* | |
| Imp 2 | | Tunnel ( ) | | |
| receive |-<-F2-| ID 2 \ / |<----* |
+---------+ +~~~~~~~~~~~\ /~~~~~~| Switch |
`-+-' +--------+
Illustrations of a test setup with a bidirectional tunnel. The upper diagram emphasizes the VLAN connectivity and geographical location. The lower diagram shows example flows traveling between two measurement implementations (for simplicity, only two flows are shown).
双方向トンネルを使用したテストセットアップの図。上の図は、VLAN接続と地理的な場所を強調しています。下の図は、2つの測定実装間を移動するフローの例を示しています（簡単にするために、2つのフローのみを示しています）。
Figure 1
図1
The testing employs the Layer 2 Tunneling Protocol, version 3 (L2TPv3) [RFC3931] tunnel between test sites on the Internet. The tunnel IP and L2TPv3 headers are intended to conceal the test equipment addresses and ports from hash functions that would tend to spread different test streams across parallel network resources, with likely variation in performance as a result.
このテストでは、インターネット上のテストサイト間で、レイヤー2トンネリングプロトコル、バージョン3（L2TPv3）[RFC3931]トンネルを使用します。トンネルIPおよびL2TPv3ヘッダーは、テスト機器のアドレスとポートをハッシュ関数から隠し、結果としてパフォーマンスにばらつきが生じる可能性がある並列ネットワークリソース全体に異なるテストストリームを分散する傾向があることを目的としています。
At each end of the tunnel, one pair of VLANs encapsulated in the tunnel are looped back so that test traffic is returned to each test site. Thus, test streams traverse the L2TP tunnel twice, but appear to be one-way tests from the test equipment point of view.
トンネルの両端で、トンネルにカプセル化された1組のVLANがループバックされ、テストトラフィックが各テストサイトに返されます。したがって、テストストリームはL2TPトンネルを2回通過しますが、テスト機器の観点からは一方向のテストのように見えます。
The network emulator is a host running Fedora 14 Linux [Fedora14] with IP forwarding enabled and the "netem" Network emulator [netem] loaded and operating as part of the Fedora Kernel 2.6.35.11. Connectivity across the netem/Fedora host was accomplished by bridging Ethernet VLAN interfaces together with "brctl" commands (e.g., eth1.100 <-> eth2.100). The netem emulator was activated on one interface (eth1) and only operates on test streams traveling in one direction. In some tests, independent netem instances operated separately on each VLAN.
ネットワークエミュレータは、Fedora 14 Linux [Fedora14]を実行するホストで、IP転送が有効で、「netem」ネットワークエミュレータ[netem]が読み込まれ、Fedoraカーネル2.6.35.11の一部として動作します。 netem / Fedoraホストを介した接続は、「brctl」コマンド（eth1.100 <-> eth2.100など）を使用してイーサネットVLANインターフェースをブリッジすることで実現されました。 netemエミュレーターは1つのインターフェース（eth1）でアクティブ化され、一方向に移動するテストストリームでのみ動作します。一部のテストでは、独立したnetemインスタンスが各VLANで個別に動作しました。
The links between the netem emulator host and router and switch were found to be 100baseTx-HD (100 Mbps half duplex) when the testing was complete. Use of half duplex was not intended, but probably added a small amount of delay variation that could have been avoided in full duplex mode.
テストが完了したとき、netemエミュレーターホストとルーターおよびスイッチ間のリンクは100baseTx-HD（100 Mbps半二重）であることがわかりました。半二重の使用は意図されていませんでしたが、全二重モードでは回避できたであろう少量の遅延変動が追加された可能性があります。
Each individual test was run with common packet rates (1 pps, 10 pps) Poisson/Periodic distributions, and IP packet sizes of 64, 340, and 500 Bytes. These sizes cover a reasonable range while avoiding fragmentation and the complexities it causes, thus complying with the notion of "standard formed packets" described in Section 15 of [RFC2330].
個々のテストは、共通のパケットレート（1 pps、10 pps）のポアソン/定期分布、および64、340、500バイトのIPパケットサイズで実行されました。これらのサイズは、断片化とそれが引き起こす複雑さを回避しながら、妥当な範囲をカバーし、[RFC2330]のセクション15で説明されている「標準形式のパケット」の概念に準拠しています。
For these tests, a stream of at least 300 packets were sent from Source to Destination in each implementation. Periodic streams (as per [RFC3432]) with 1 second spacing were used, except as noted.
これらのテストでは、各実装で少なくとも300パケットのストリームが送信元から宛先に送信されました。注記がある場合を除き、1秒間隔の定期的なストリーム（[RFC3432]による）が使用されました。
With the L2TPv3 tunnel in use, the metric name for the testing configured here (with respect to the IP header exposed to Internet processing) is:
L2TPv3トンネルが使用されている場合、ここで構成されたテストのメトリック名は（インターネット処理に公開されるIPヘッダーに関して）次のとおりです。
Type-IP-protocol-115-One-way-Delay-<StreamType>-Stream
Type-IP-protocol-115-One-way-Delay- <StreamType> -Stream
With (Section 4.2 of [RFC2679]) Metric Parameters:
（[RFC2679]のセクション4.2）メトリックパラメータ：
+ Src, the IP address of a host (12.3.167.16 or 193.159.144.8)
+ Src、ホストのIPアドレス（12.3.167.16または193.159.144.8）
+ Dst, the IP address of a host (193.159.144.8 or 12.3.167.16)
+ Dst、ホストのIPアドレス（193.159.144.8または12.3.167.16）
+ T0, a time
+ T0、時間
+ Tf, a time
+ Tf、時間
+ lambda, a rate in reciprocal seconds
+ ラムダ、秒単位のレート
+ Thresh, a maximum waiting time in seconds (see Section 3.8.2 of [RFC2679] and Section 4.3 of [RFC2679])
+ 秒単位の最大待機時間（[RFC2679]のセクション3.8.2および[RFC2679]のセクション4.3を参照）
Metric Units: A sequence of pairs; the elements of each pair are:
メートル法の単位：ペアのシーケンス。各ペアの要素は次のとおりです。
+ T, a time, and
+ T、時間、そして
+ dT, either a real number or an undefined number of seconds.
+ dT、実数または未定義の秒数。
The values of T in the sequence are monotonic increasing. Note that T would be a valid parameter to Type-P-One-way-Delay and that dT would be a valid value of Type-P-One-way-Delay.
シーケンスのTの値は単調増加です。 TはType-P-One-way-Delayの有効なパラメーターであり、dTはType-P-One-way-Delayの有効な値であることに注意してください。
Also, Section 3.8.4 of [RFC2679] recommends that the path SHOULD be reported. In this test setup, most of the path details will be concealed from the implementations by the L2TPv3 tunnels; thus, a more informative path trace route can be conducted by the routers at each location.
また、[RFC2679]のセクション3.8.4は、パスを報告する必要があることを推奨しています。このテストセットアップでは、パスの詳細のほとんどがL2TPv3トンネルによって実装から隠されます。したがって、各場所のルーターによって、より有益なパストレースルートを実行できます。
When NetProbe is used in production, a traceroute is conducted in parallel with, and at the outset of, measurements.
NetProbeを本番環境で使用する場合、tracerouteは測定と並行して、また測定の最初に行われます。
Perfas+ does not support traceroute.
Perfas +はtracerouteをサポートしていません。
IPLGW#traceroute 193.159.144.8
IPLGW＃traceroute 193.159.144.8
Type escape sequence to abort. Tracing the route to 193.159.144.8
エスケープシーケンスを入力して中止します。 193.159.144.8へのルートの追跡
1 12.126.218.245 [AS 7018] 0 msec 0 msec 4 msec 2 cr84.n54ny.ip.att.net (12.123.2.158) [AS 7018] 4 msec 4 msec cr83.n54ny.ip.att.net (12.123.2.26) [AS 7018] 4 msec 3 cr1.n54ny.ip.att.net (12.122.105.49) [AS 7018] 4 msec cr2.n54ny.ip.att.net (12.122.115.93) [AS 7018] 0 msec cr1.n54ny.ip.att.net (12.122.105.49) [AS 7018] 0 msec 4 n54ny02jt.ip.att.net (12.122.80.225) [AS 7018] 4 msec 0 msec n54ny02jt.ip.att.net (12.122.80.237) [AS 7018] 4 msec 5 192.205.34.182 [AS 7018] 0 msec 192.205.34.150 [AS 7018] 0 msec 192.205.34.182 [AS 7018] 4 msec 6 da-rg12-i.DA.DE.NET.DTAG.DE (62.154.1.30) [AS 3320] 88 msec 88 msec 88 msec 7 217.89.29.62 [AS 3320] 88 msec 88 msec 88 msec 8 217.89.29.55 [AS 3320] 88 msec 88 msec 88 msec 9 * * * It was only possible to conduct the traceroute for the measured path on one of the tunnel-head routers (the normal trace facilities of the measurement systems are confounded by the L2TPv3 tunnel encapsulation).
1 12.126.218.245 [AS 7018] 0ミリ秒0ミリ秒4ミリ秒2 cr84.n54ny.ip.att.net（12.123.2.158）[AS 7018] 4ミリ秒4ミリ秒cr83.n54ny.ip.att.net（12.123.2.26 ）[AS 7018] 4ミリ秒3 cr1.n54ny.ip.att.net（12.122.105.49）[AS 7018] 4ミリ秒cr2.n54ny.ip.att.net（12.122.115.93）[AS 7018] 0ミリ秒cr1。 n54ny.ip.att.net（12.122.105.49）[AS 7018] 0ミリ秒4 n54ny02jt.ip.att.net（12.122.80.225）[AS 7018] 4ミリ秒0ミリ秒n54ny02jt.ip.att.net（12.122.80.237 ）[AS 7018] 4ミリ秒5 192.205.34.182 [AS 7018] 0ミリ秒192.205.34.150 [AS 7018] 0ミリ秒192.205.34.182 [AS 7018] 4ミリ秒6 da-rg12-i.DA.DE.NET.DTAG。 DE（62.154.1.30）[AS 3320] 88ミリ秒88ミリ秒88ミリ秒7 217.89.29.62 [AS 3320] 88ミリ秒88ミリ秒88ミリ秒8 217.89.29.55 [AS 3320] 88ミリ秒88ミリ秒88ミリ秒9 * * *いずれかのトンネルヘッドルーターで測定パスのtracerouteを実行することのみが可能です（測定システムの通常のトレース機能は、L2TPv3トンネルカプセル化によって混乱します）。
An implementation is required to report on its error calibration in Section 3.8 of [RFC2679] (also required in Section 4.8 for sample metrics). Sections 3.6, 3.7, and 3.8 of [RFC2679] give the detailed formulation of the errors and uncertainties for calibration. In summary, Section 3.7.1 of [RFC2679] describes the total time-varying uncertainty as:
[RFC2679]のセクション3.8のエラーキャリブレーションについて報告するには、実装が必要です（サンプル指標についてはセクション4.8でも必要です）。 [RFC2679]のセクション3.6、3.7、および3.8は、キャリブレーションのエラーと不確実性の詳細な定式化を提供します。要約すると、[RFC2679]のセクション3.7.1は、時変の不確実性の合計を次のように説明しています。
Esynch(t)+ Rsource + Rdest
where:
ただし：
Esynch(t) denotes an upper bound on the magnitude of clock synchronization uncertainty.
Esynch（t）は、クロック同期の不確実性の大きさの上限を示します。
Rsource and Rdest denote the resolution of the source clock and the destination clock, respectively.
RsourceとRdestは、それぞれソースクロックとデスティネーションクロックの分解能を示します。
Further, Section 3.7.2 of [RFC2679] describes the total wire-time uncertainty as:
さらに、[RFC2679]のセクション3.7.2は、総ワイヤ時間の不確実性を次のように説明しています。
Hsource + Hdest
Hsource + Hdest
referring to the upper bounds on host-time to wire-time for source and destination, respectively.
発信元と宛先のホスト時間とワイヤ時間の上限をそれぞれ参照します。
Section 3.7.3 of [RFC2679] describes a test with small packets over an isolated minimal network where the results can be used to estimate systematic and random components of the sum of the above errors or uncertainties. In a test with hundreds of singletons, the median is the systematic error and when the median is subtracted from all singletons, the remaining variability is the random error.
[RFC2679]のセクション3.7.3は、孤立した最小ネットワーク上で小さなパケットを使用したテストについて説明しており、その結果を使用して、上記のエラーまたは不確実性の合計の系統的およびランダムなコンポーネントを推定できます。数百のシングルトンのテストでは、中央値は系統誤差であり、中央値をすべてのシングルトンから差し引くと、残りの変動性はランダムエラーになります。
The test context, or Type-P of the test packets, must also be reported, as required in Section 3.8 of [RFC2679] and all metrics defined there. Type-P is defined in Section 13 of [RFC2330] (as are many terms used below).
[RFC2679]のセクション3.8で要求されているように、テストコンテキスト、またはテストパケットのType-Pと、そこで定義されているすべてのメトリックも報告する必要があります。 Type-Pは[RFC2330]のセクション13で定義されています（以下で使用される多くの用語と同様）。
Type-P for this test was IP-UDP with Best Effort Differentiated Services Code Point (DSCP). These headers were encapsulated according to the L2TPv3 specifications [RFC3931]; thus, they may not influence the treatment received as the packets traversed the Internet.
このテストのType-Pは、Best-Effort Differentiated Services Code Point（DSCP）を使用したIP-UDPでした。これらのヘッダーは、L2TPv3仕様[RFC3931]に従ってカプセル化されました。したがって、パケットがインターネットを通過するときに受信される処理に影響を与えることはありません。
In general, NetProbe error is dependent on the specific version and installation details.
一般に、NetProbeエラーは、特定のバージョンとインストールの詳細によって異なります。
NetProbe operates using host-time above the UDP layer, which is different from the wire-time preferred in [RFC2330], but it can be identified as a source of error according to Section 3.7.2 of [RFC2679].
NetProbeは、[RFC2330]で推奨されている通信時間とは異なるUDPレイヤーより上のホスト時間を使用して動作しますが、[RFC2679]のセクション3.7.2に従ってエラーの原因として識別できます。
Accuracy of NetProbe measurements is usually limited by NTP synchronization performance (which is typically taken as ~+/-1 ms error or greater), although the installation used in this testing often exhibits errors much less than typical for NTP. The primary stratum 1 NTP server is closely located on a sparsely utilized network management LAN; thus, it avoids many concerns raised in Section 10 of [RFC2330] (in fact, smooth adjustment, long-term drift analysis and compensation, and infrequent adjustment all lead to stability during measurement intervals, the main concern).
NetProbe測定の精度は、通常、NTP同期パフォーマンス（通常、±+/- 1 msエラーまたはそれ以上と見なされます）によって制限されますが、このテストで使用されるインストールでは、NTPの通常よりもはるかに少ないエラーが表示されることがよくあります。プライマリストラタム1 NTPサーバーは、利用率の低いネットワーク管理LANの近くにあります。したがって、[RFC2330]のセクション10で提起された多くの懸念が回避されます（実際には、スムーズな調整、長期的なドリフト分析と補正、および頻繁でない調整はすべて、測定間隔中の安定性につながります）。
The resolution of the reported results is 1 us (us = microsecond) in the version of NetProbe tested here, which contributes to at least +/-1 us error.
レポートされた結果の解像度は、ここでテストされたNetProbeのバージョンで1 us（us =マイクロ秒）であり、少なくとも+/- 1 usエラーの原因となります。
NetProbe implements a timekeeping sanity check on sending and receiving time-stamping processes. When a significant process interruption takes place, individual test packets are flagged as possibly containing unusual time errors, and they are excluded from the sample used for all "time" metrics.
NetProbeは、送信と受信のタイムスタンププロセスの計時健全性チェックを実装します。重大なプロセスの中断が発生すると、個々のテストパケットに異常な時間エラーが含まれている可能性があるというフラグが付けられ、すべての「時間」メトリックに使用されるサンプルから除外されます。
We performed a NetProbe calibration of the type described in Section
3.7.3 of [RFC2679], using 64-Byte packets over a cross-connect cable.
The results estimate systematic and random components of the sum of
the Hsource + Hdest errors or uncertainties. In a test with 300
singletons conducted over 30 seconds (periodic sample with 100 ms
spacing), the median is the systematic error and the remaining
variability is the random error. One set of results is tabulated
below:
(Results from the "R" software environment for statistical computing
and graphics - http://www.r-project.org/ )
> summary(XD4CAL)
CAL1 CAL2 CAL3
Min. : 89.0 Min. : 68.00 Min. : 54.00
1st Qu.: 99.0 1st Qu.: 77.00 1st Qu.: 63.00
Median :110.0 Median : 79.00 Median : 65.00
Mean :116.8 Mean : 83.74 Mean : 69.65
3rd Qu.:127.0 3rd Qu.: 88.00 3rd Qu.: 74.00
Max. :205.0 Max. :177.00 Max. :163.00
>
NetProbe Calibration with Cross-Connect Cable, one-way delay values
in microseconds (us)
The median or systematic error can be as high as 110 us, and the range of the random error is also on the order of 116 us for all streams.
中央または系統的エラーは110 usに達する可能性があり、ランダムエラーの範囲もすべてのストリームで116 us程度です。
Also, anticipating the Anderson-Darling K-sample (ADK) [ADK] comparisons to follow, we corrected the CAL2 values for the difference between the means of CAL2 and CAL3 (as permitted in Section 3.2 of [RFC6576]), and found strong support (for the Null Hypothesis) that the samples are from the same distribution (resolution of 1 us and alpha equal 0.05 and 0.01)
また、Anderson-Darling K-sample（ADK）[ADK]の比較が続くことを予想して、CAL2とCAL3の平均値の差のCAL2値を修正しました（[RFC6576]のセクション3.2で許可されているように）。サンプルが同じ分布からのものである（帰無仮説の場合）のサポート（解像度1 us、アルファは0.05および0.01）
> XD4CVCAL2 <- XD4CAL$CAL2 - (mean(XD4CAL$CAL2)-mean(XD4CAL$CAL3)) > boxplot(XD4CVCAL2,XD4CAL$CAL3) > XD4CV2_ADK <- adk.test(XD4CVCAL2, XD4CAL$CAL3) > XD4CV2_ADK Anderson-Darling k-sample test.
> XD4CVCAL2 <-XD4CAL $ CAL2-（mean（XD4CAL $ CAL2）-mean（XD4CAL $ CAL3））> boxplot（XD4CVCAL2、XD4CAL $ CAL3）> XD4CV2_ADK <-adk.test（XD4CVCAL2、XD4CALDC-AND3>）ダーリンk標本検定。
Number of samples: 2 Sample sizes: 300 300 Total number of values: 600 Number of unique values: 97
サンプル数：2サンプルサイズ：300300値の総数：600一意の値の数：97
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.75896
アンダーソンダーリング基準の平均：1アンダーソンダーリング基準の標準偏差：0.75896
T = (Anderson-Darling Criterion - mean)/sigma
Null Hypothesis: All samples come from a common population.
帰無仮説：すべてのサンプルは共通の母集団からのものです。
t.obs P-value extrapolation not adj. for ties 0.71734 0.17042 0 adj. for ties -0.39553 0.44589 1 > using [Rtool] and [Radk].
t.obs P値の外挿は調整されていません。ネクタイ用0.71734 0.17042 0調整タイの場合-0.39553 0.44589 1> [Rtool]および[Radk]を使用します。
Perfas+ is configured to use GPS synchronization and uses NTP synchronization as a fall-back or default. GPS synchronization worked throughout this test with the exception of the calibration stated here (one implementation was NTP synchronized only). The time stamp accuracy typically is 0.1 ms.
Perfas +はGPS同期を使用するように構成され、フォールバックまたはデフォルトとしてNTP同期を使用します。ここで述べた調整を除いて、GPS同期はこのテスト全体を通じて機能しました（1つの実装はNTP同期のみでした）。タイムスタンプの精度は通常0.1 msです。
The resolution of the results reported by Perfas+ is 1 us (us = microsecond) in the version tested here, which contributes to at least +/-1 us error.
Perfas +によって報告された結果の解像度は、ここでテストされたバージョンでは1 us（us =マイクロ秒）であり、少なくとも+/- 1 usエラーの原因となっています。
Port 5001 5002 5003 Min. -227 -226 294 Median -169 -167 323 Mean -159 -157 335 Max. 6 -52 376 s 102 102 93 Perfas+ Calibration with Cross-Connect Cable, one-way delay values in microseconds (us)
ポート5001 5002 5003最小-227 -226 294中央値-169 -167 323平均-159 -157 335最大。 6 -52 376 s 102 102 93クロスコネクトケーブルを使用したPerfas +キャリブレーション、マイクロセカンド（us）単位の一方向遅延値
The median or systematic error can be as high as 323 us, and the range of the random error is also less than 232 us for all streams.
中央または系統的エラーは323 usに達する可能性があり、ランダムエラーの範囲もすべてのストリームで232 us未満です。
This section provides the numerical limits on comparisons between implementations, in order to declare that the results are equivalent and therefore, the tested specification is clear. These limits have their basis in Section 3.1 of [RFC6576] and the Appendix of [RFC2330], with additional limits representing IP Performance Metrics (IPPM) consensus prior to publication of results.
このセクションでは、結果が同等であり、したがってテストされた仕様が明確であることを宣言するために、実装間の比較に関する数値制限を提供します。これらの制限は、[RFC6576]のセクション3.1および[RFC2330]の付録に基づいており、追加の制限は、結果の公開前のIPパフォーマンスメトリック（IPPM）の合意を表します。
A key point is that the allowable errors, corrections, and confidence levels only need to be sufficient to detect misinterpretation of the tested specification resulting in diverging implementations.
重要な点は、許容されるエラー、修正、および信頼レベルは、テストされた仕様の誤った解釈を検出するために十分である必要があるだけであり、その結果、実装が発散することです。
Also, the allowable error must be sufficient to compensate for measured path differences. It was simply not possible to measure fully identical paths in the VLAN-loopback test configuration used, and this practical compromise must be taken into account.
また、許容誤差は、測定されたパスの差を補償するのに十分でなければなりません。使用されているVLANループバックテスト構成で完全に同一のパスを測定することは不可能であり、この実際的な妥協点を考慮する必要があります。
For Anderson-Darling K-sample (ADK) comparisons, the required confidence factor for the cross-implementation comparisons SHALL be the smallest of: o 0.95 confidence factor at 1 ms resolution, or
Anderson-Darling K-sample（ADK）比較の場合、クロス実装比較に必要な信頼係数は、以下の最小値でなければなりません。o 1 msの分解能での0.95信頼係数、または
o the smallest confidence factor (in combination with resolution) of the two same-implementation comparisons for the same test conditions.
o 同じテスト条件での2つの同じ実装の比較の最小の信頼係数（分解能との組み合わせ）。
A constant time accuracy error of as much as +/-0.5 ms MAY be removed from one implementation's distributions (all singletons) before the ADK comparison is conducted.
+/- 0.5 msの一定の時間精度エラーは、ADK比較が実行される前に、1つの実装の分布（すべてシングルトン）から削除される場合があります。
A constant propagation delay error (due to use of different sub-nets between the switch and measurement devices at each location) of as much as +2 ms MAY be removed from one implementation's distributions (all singletons) before the ADK comparison is conducted.
ADKの比較が行われる前に、1つの実装の分布（すべてのシングルトン）から+2 ms程度の一定の伝播遅延エラー（スイッチと各場所の測定デバイス間で異なるサブネットを使用しているため）が削除される場合があります。
For comparisons involving the mean of a sample or other central statistics, the limits on both the time accuracy error and the propagation delay error constants given above also apply.
サンプルの平均または他の中央統計を含む比較の場合、上記の時間精度エラーと伝搬遅延エラー定数の両方の制限も適用されます。
This section describes some results from real-world (cross-Internet) tests with measurement devices implementing IPPM metrics and a network emulator to create relevant conditions, to determine whether the metric definitions were interpreted consistently by implementors.
このセクションでは、IPPMメトリックを実装する測定デバイスと、関連する条件を作成してメトリック定義が一貫して解釈されたかどうかを判断するためのネットワークエミュレーターを使用した、実際の（クロスインターネット）テストの結果について説明します。
The procedures are slightly modified from the original procedures contained in Appendix A.1 of [RFC6576]. The modifications include the use of the mean statistic for comparisons.
手順は、[RFC6576]の付録A.1に含まれる元の手順からわずかに変更されています。変更には、比較のための平均統計量の使用が含まれます。
Note that there are only five instances of the requirement term "MUST" in [RFC2679] outside of the boilerplate and [RFC2119] reference.
[RFC2679]のボイラープレートと[RFC2119]参照の外には、要件用語「MUST」のインスタンスが5つしかないことに注意してください。
6.1. One-Way Delay, ADK Sample Comparison: Same- and Cross-Implementation
6.1. 一方向遅延、ADKサンプルの比較：同一実装と相互実装
This test determines if implementations produce results that appear to come from a common delay distribution, as an overall evaluation of Section 4 of [RFC2679], "A Definition for Samples of One-way Delay". Same-implementation comparison results help to set the threshold of equivalence that will be applied to cross-implementation comparisons.
このテストでは、[RFC2679]のセクション4、「一方向遅延のサンプルの定義」の全体的な評価として、実装が共通の遅延分布に由来すると思われる結果を生成するかどうかを決定します。同じ実装の比較結果は、実装間の比較に適用される同等性のしきい値の設定に役立ちます。
This test is intended to evaluate measurements in Sections 3 and 4 of [RFC2679].
このテストは、[RFC2679]のセクション3および4の測定を評価することを目的としています。
By testing the extent to which the distributions of one-way delay singletons from two implementations of [RFC2679] appear to be from the same distribution, we economize on comparisons, because comparing a set of individual summary statistics (as defined in Section 5 of [RFC2679]) would require another set of individual evaluations of equivalence. Instead, we can simply check which statistics were implemented, and report on those facts.
[RFC2679]の2つの実装からの一方向遅延シングルトンの分布が同じ分布からのものであるように見える範囲をテストすることにより、個々の要約統計のセット（[ RFC2679]）は、同等性の個別の評価の別のセットを必要とします。代わりに、実装された統計を確認し、それらの事実について報告することができます。
1. Configure an L2TPv3 path between test sites, and each pair of measurement devices to operate tests in their designated pair of VLANs.
1. テストサイトと測定デバイスの各ペア間のL2TPv3パスを構成して、指定されたVLANのペアでテストを実行します。
2. Measure a sample of one-way delay singletons with two or more implementations, using identical options and network emulator settings (if used).
2. 同じオプションとネットワークエミュレーター設定（使用している場合）を使用して、2つ以上の実装を持つ一方向遅延シングルトンのサンプルを測定します。
3. Measure a sample of one-way delay singletons with *four* instances of the *same* implementations, using identical options, noting that connectivity differences SHOULD be the same as for the cross-implementation testing.
3. 同じオプションを使用して、*同じ*実装の* 4 *インスタンスで一方向遅延シングルトンのサンプルを測定します。接続の違いは、実装間のテストと同じである必要があることに注意してください。
4. Apply the ADK comparison procedures (see Appendices A and B of [RFC6576]) and determine the resolution and confidence factor for distribution equivalence of each same-implementation comparison and each cross-implementation comparison.
4. ADK比較手順を適用し（[RFC6576]の付録AとBを参照）、同じ実装の比較と実装間の比較のそれぞれの分布の同等性に対する解像度と信頼係数を決定します。
5. Take the coarsest resolution and confidence factor for distribution equivalence from the same-implementation pairs, or the limit defined in Section 5 above, as a limit on the equivalence threshold for these experimental conditions.
5. これらの実験条件の等価しきい値の限界として、同じ実装のペアからの分布等価の最も粗い分解能と信頼係数、または上記のセクション5で定義された限界を使用します。
6. Apply constant correction factors to all singletons of the sample distributions, as described and limited in Section 5 above.
6. 上記のセクション5で説明および制限されているように、一定の補正係数をサンプル分布のすべてのシングルトンに適用します。
7. Compare the cross-implementation ADK performance with the equivalence threshold determined in step 5 to determine if equivalence can be declared.
7. クロス実装ADKのパフォーマンスを、手順5で決定された等価しきい値と比較して、等価を宣言できるかどうかを判断します。
The common parameters used for tests in this section are:
このセクションのテストに使用される一般的なパラメーターは次のとおりです。
o IP header + payload = 64 octets
o IPヘッダー+ペイロード= 64オクテット
o Periodic sampling at 1 packet per second
o 1パケット/秒での定期的なサンプリング
o Test duration = 300 seconds (March 29, 2011) The netem emulator was set for 100 ms average delay, with uniform delay variation of +/-50 ms. In this experiment, the netem emulator was configured to operate independently on each VLAN; thus, the emulator itself is a potential source of error when comparing streams that traverse the test path in different directions.
oテスト期間= 300秒（2011年3月29日）netemエミュレーターは、平均遅延100 msに設定され、均一な遅延変動は+/- 50 msです。この実験では、netemエミュレータは各VLANで独立して動作するように構成されました。したがって、エミュレータ自体が、テストパスをさまざまな方向に通過するストリームを比較するときに、潜在的なエラーの原因になります。
In the result analysis of this section:
このセクションの結果分析では、
o All comparisons used 1 microsecond resolution.
o すべての比較は1マイクロ秒の分解能を使用しました。
o No correction factors were applied.
o 補正係数は適用されませんでした。
o The 0.95 confidence factor (1.960 for paired stream comparison) was used.
o 0.95の信頼係数（ペアストリーム比較では1.960）が使用されました。
A single same-implementation comparison fails the ADK criterion (s1 <-> sB). We note that these streams traversed the test path in opposite directions, making the live network factors a possibility to explain the difference.
1つの同じ実装の比較がADK基準（s1 <-> sB）に失敗しました。これらのストリームはテストパスを逆方向に通過するため、ライブネットワークの要因が違いを説明する可能性があることに注意してください。
All other pair comparisons pass the ADK criterion.
他のすべてのペア比較は、ADK基準に合格します。
+------------------------------------------------------+
| | | | |
| ti.obs (P) | s1 | s2 | sA |
| | | | |
.............|.............|.............|.............|
| | | | |
| s2 | 0.25 (0.28) | | |
| | | | |
...........................|.............|.............|
| | | | |
| sA | 0.60 (0.19) |-0.80 (0.57) | |
| | | | |
...........................|.............|.............|
| | | | |
| sB | 2.64 (0.03) | 0.07 (0.31) |-0.52 (0.48) |
| | | | |
+------------+-------------+-------------+-------------+
NetProbe ADK results for same-implementation
同じ実装に対するNetProbe ADKの結果
All pair comparisons pass the ADK criterion.
すべてのペアの比較は、ADK基準に合格しています。
+------------------------------------------------------+
| | | | |
| ti.obs (P) | p1 | p2 | p3 |
| | | | |
.............|.............|.............|.............|
| | | | |
| p2 | 0.06 (0.32) | | |
| | | | |
.........................................|.............|
| | | | |
| p3 | 1.09 (0.12) | 0.37 (0.24) | |
| | | | |
...........................|.............|.............|
| | | | |
| p4 |-0.81 (0.57) |-0.13 (0.37) | 1.36 (0.09) |
| | | | |
+------------+-------------+-------------+-------------+
Perfas+ ADK results for same-implementation
同じ実装でのPerfas + ADKの結果
The cross-implementation results are compared using a combined ADK analysis [Radk], where all NetProbe results are compared with all Perfas+ results after testing that the combined same-implementation results pass the ADK criterion.
クロス実装の結果は、結合されたADK分析[Radk]を使用して比較されます。ここで、すべてのNetProbe結果は、結合された同じ実装の結果がADK基準に合格することをテストした後、すべてのPerfas +の結果と比較されます。
When 4 (same) samples are compared, the ADK criterion for 0.95 confidence is 1.915, and when all 8 (cross) samples are compared it is 1.85.
4つの（同じ）サンプルを比較すると、0.95信頼度のADK基準は1.915であり、8つの（クロス）サンプルすべてを比較すると、1.85です。
Combination of Anderson-Darling K-Sample Tests.
アンダーソンダーリングKサンプル検定の組み合わせ。
Sample sizes within each data set: Data set 1 : 299 297 298 300 (NetProbe) Data set 2 : 300 300 298 300 (Perfas+) Total sample size per data set: 1194 1198 Number of unique values per data set: 1188 1192 ... Null Hypothesis: All samples within a data set come from a common distribution. The common distribution may change between data sets.
各データセット内のサンプルサイズ：データセット1：299 297 298 300（NetProbe）データセット2：300 300 298 300（Perfas +）データセットあたりの合計サンプルサイズ：1194 1198データセットあたりの一意の値の数：1188 1192 .. 。帰無仮説：データセット内のすべてのサンプルは、共通の分布に由来します。一般的な分布は、データセット間で異なる場合があります。
NetProbe ti.obs P-value extrapolation not adj. for ties 0.64999 0.21355 0 adj. for ties 0.64833 0.21392 0 Perfas+ not adj. for ties 0.55968 0.23442 0 adj. for ties 0.55840 0.23473 0
NetProbe ti.obs P値外挿は調整されません。ネクタイ用0.64999 0.21355 0調整ネクタイ用0.64833 0.21392 0 Perfas +調整なしネクタイ用0.55968 0.23442 0調整タイ用0.55840 0.23473 0
Combined Anderson-Darling Criterion: tc.obs P-value extrapolation not adj. for ties 0.85537 0.17967 0 adj. for ties 0.85329 0.18010 0
結合されたアンダーソンダーリング基準：tc.obs P値の外挿は調整されていません。ネクタイ用0.85537 0.17967 0調整ネクタイ用0.85329 0.18010 0
The combined same-implementation samples and the combined cross-implementation comparison all pass the ADK criterion at P>=0.18 and support the Null Hypothesis (both data sets come from a common distribution).
同じ実装を組み合わせたサンプルと実装をまたがった組み合わせを組み合わせた比較はすべて、P> = 0.18でADK基準に合格し、帰無仮説をサポートします（両方のデータセットは共通の分布から得られます）。
We also see that the paired ADK comparisons are rather critical. Although the NetProbe s1-sB comparison failed, the combined data set from four streams passed the ADK criterion easily.
また、ADKのペアの比較がかなり重要であることもわかります。 NetProbe s1-sBの比較は失敗しましたが、4つのストリームからの結合データセットは、ADK基準を簡単に通過しました。
Similar testing was repeated many times in the months of March and April 2011. There were many experiments where a single test stream from NetProbe or Perfas+ proved to be different from the others in paired comparisons (even same-implementation comparisons). When the outlier stream was removed from the comparison, the remaining streams passed combined ADK criterion. Also, the application of correction factors resulted in higher comparison success.
同様のテストが2011年3月と4月に何度も繰り返されました。NetProbeまたはPerfas +からの単一のテストストリームがペアの比較（同じ実装の比較でさえ）で他のものと異なることが判明した多くの実験がありました。外れ値ストリームが比較から削除されたとき、残りのストリームは結合されたADK基準に合格しました。また、補正係数の適用により、比較の成功率が高くなりました。
We conclude that the two implementations are capable of producing equivalent one-way delay distributions based on their interpretation of [RFC2679].
[RFC2679]の解釈に基づいて、2つの実装は同等の一方向遅延分布を生成できると結論付けます。
On the final day of testing, we performed a series of measurements to evaluate the amount of emulated delay variation necessary to achieve successful ADK comparisons. The need for correction factors (as permitted by Section 5) and the size of the measurement sample (obtained as sub-sets of the complete measurement sample) were also evaluated.
テストの最終日に、一連の測定を実行して、ADKの比較を成功させるために必要なエミュレートされた遅延変動の量を評価しました。 （セクション5で許可されている）補正係数の必要性と測定サンプルのサイズ（完全な測定サンプルのサブセットとして取得）も評価されました。
The common parameters used for tests in this section are:
このセクションのテストに使用される一般的なパラメーターは次のとおりです。
o IP header + payload = 64 octets o Periodic sampling at 1 packet per second
o IPヘッダー+ペイロード= 64オクテットo 1パケット/秒での定期的なサンプリング
o Test duration = 300 seconds at each delay variation setting, for a total of 1200 seconds (May 2, 2011 at 1720 UTC)
o テスト期間=各遅延変動設定で300秒、合計1200秒（2011年5月2日1720 UTC）
The netem emulator was set for 100 ms average delay, with (emulated) uniform delay variation of:
netemエミュレーターは100 msの平均遅延に設定されており、（エミュレートされた）均一な遅延変動は次のとおりです。
o +/-7.5 ms
o +/- 7.5ミリ秒
o +/-5.0 ms
o +/- 5.0ミリ秒
o +/-2.5 ms
o +/- 2.5ミリ秒
o 0 ms
o 0ミリ秒
In this experiment, the netem emulator was configured to operate independently on each VLAN; thus, the emulator itself is a potential source of error when comparing streams that traverse the test path in different directions.
この実験では、netemエミュレータは各VLANで独立して動作するように構成されました。したがって、エミュレータ自体が、テストパスをさまざまな方向に通過するストリームを比較するときに、潜在的なエラーの原因になります。
In the result analysis of this section:
このセクションの結果分析では、
o All comparisons used 1 microsecond resolution.
o すべての比較は1マイクロ秒の分解能を使用しました。
o Correction factors *were* applied as noted (under column heading "mean adj"). The difference between each sample mean and the lowest mean of the NetProbe or Perfas+ stream samples was subtracted from all values in the sample. ("raw" indicates no correction factors were used.) All correction factors applied met the limits described in Section 5.
o 記載されているとおりに修正係数が適用されました（列見出し「mean adj」の下）。 NetProbeまたはPerfas +ストリームサンプルの各サンプル平均と最低平均の差は、サンプルのすべての値から差し引かれました。 （「生」は、補正係数が使用されなかったことを示します。）適用されたすべての補正係数は、セクション5で説明されている制限を満たしました。
o The 0.95 confidence factor (1.960 for paired stream comparison) was used.
o 0.95の信頼係数（ペアストリーム比較では1.960）が使用されました。
When 8 (cross) samples are compared, the ADK criterion for 0.95 confidence is 1.85. The Combined ADK test statistic ("TC observed") must be less than 1.85 to accept the Null Hypothesis (all samples in the data set are from a common distribution).
8つの（クロス）サンプルを比較すると、0.95の信頼度のADK基準は1.85です。 Null仮説を受け入れるには、結合されたADK検定統計量（「TC観測値」）が1.85未満である必要があります（データセット内のすべてのサンプルは共通の分布からのものです）。
Emulated Delay Sub-Sample size Variation 0ms adk.combined (all) 300 values 75 values Adj. for ties raw mean adj raw mean adj TC observed 226.6563 67.51559 54.01359 21.56513 P-value 0 0 0 0 Mean std dev (all),us 719 635 Mean diff of means,us 649 0 606 0
エミュレートされた遅延サブサンプルサイズバリエーション0ms adk.combined（all）300値75値調整。 tieの場合、生の平均adj生の平均adj TCが観測された226.6563 67.51559 54.01359 21.56513 P値0 0 0 0 Mean std dev（all）、us 719 635 Mean diff of mean、us 649 0 606 0
Variation +/- 2.5ms adk.combined (all) 300 values 75 values Adj. for ties raw mean adj raw mean adj TC observed 14.50436 -1.60196 3.15935 -1.72104 P-value 0 0.873 0.00799 0.89038 Mean std dev (all),us 1655 1702 Mean diff of means,us 471 0 513 0
変動+/- 2.5ms adk.combined（all）300値75値調整tieの場合、生の平均adj生の平均adj TC観測値14.50436 -1.60196 3.15935 -1.72104 P値0 0.873 0.00799 0.89038 Mean std dev（all）、us 1655 1702 Mean diff of mean、us 471 0 513 0
Variation +/- 5ms adk.combined (all) 300 values 75 values Adj. for ties raw mean adj raw mean adj TC observed 8.29921 -1.28927 0.37878 -1.81881 P-value 0 0.81601 0.29984 0.90305 Mean std dev (all),us 3023 2991 Mean diff of means,us 582 0 513 0
バリエーション+/- 5ms adk.combined（all）300値75値調整tieの場合、生の平均adj生の平均adj TC観測値8.29921 -1.28927 0.37878 -1.81881 P値0 0.81601 0.29984 0.90305平均std dev（すべて）、us 3023 2991平均の平均差、us 582 0 513 0
Variation +/- 7.5ms adk.combined (all) 300 values 75 values Adj. for ties raw mean adj raw mean adj TC observed 2.53759 -0.72985 0.29241 -1.15840 P-value 0.01950 0.66942 0.32585 0.78686 Mean std dev (all),us 4449 4506 Mean diff of means,us 426 0 856 0
バリエーション+/- 7.5ms adk.combined（all）300値75値調整tieの場合、生の平均adj生の平均adj TCが観測された2.53759 -0.72985 0.29241 -1.15840 P値0.01950 0.66942 0.32585 0.78686 Mean std dev（all）、us 4449 4506 Mean diff of mean、us 426 0 856 0
From the table above, we conclude the following:
上記の表から、以下を結論付けます。
1. None of the raw or mean adjusted results pass the ADK criterion with 0 ms emulated delay variation. Use of the 75 value sub-sample yielded the same conclusion. (We note the same results when comparing same-implementation samples for both NetProbe and Perfas+.)
1. 生の調整結果または平均調整結果のいずれも、遅延の変動が0ミリ秒のADK基準を満たしていません。 75値のサブサンプルを使用しても同じ結論が得られました。 （NetProbeとPerfas +の両方で同じ実装のサンプルを比較すると、同じ結果が得られます。）
2. When the smallest emulated delay variation was inserted (+/-2.5 ms), the mean adjusted samples pass the ADK criterion and the high P-value supports the result. The raw results do not pass.
2. 最小のエミュレートされた遅延変動が挿入されたとき（+/- 2.5 ms）、平均調整済みサンプルはADK基準を通過し、高いP値が結果をサポートします。生の結果は渡されません。
3. At higher values of emulated delay variation (+/-5.0 ms and +/-7.5 ms), again the mean adjusted values pass ADK. We also see that the 75-value sub-sample passed the ADK in both raw and mean adjusted cases. This indicates that sample size may have played a role in our results, as noted in the Appendix of [RFC2330] for Goodness-of-Fit testing.
3. エミュレートされた遅延変動のより高い値（+/- 5.0 msおよび+/- 7.5 ms）でも、平均調整値はADKを通過します。また、75値のサブサンプルが未加工の場合と平均調整済みの場合の両方でADKに合格したこともわかります。これは、適合度テストの[RFC2330]の付録に記載されているように、サンプルサイズが結果に影響を与えた可能性があることを示しています。
We note that 150 value sub-samples were also evaluated, with ADK conclusions that followed the results for 300 values. Also, same-implementation analysis was conducted with results similar to the above, except that more of the "raw" or uncorrected samples passed the ADK criterion.
150の値のサブサンプルも評価され、ADKの結論は300の値の結果に従いました。また、「実装されていない」サンプルまたは修正されていないサンプルの多くがADK基準に合格したことを除いて、上記と同様の結果で同じ実装分析が行われました。
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 the requirements of Section 3.5 of [RFC2679], third bullet point, and also Section 3.8.2 of [RFC2679].
[RFC2679]のセクション3.5、3番目の箇条書きの要件、および[RFC2679]のセクション3.8.2もご覧ください。
1. configure an L2TPv3 path between test sites, and each pair of measurement devices to operate tests in their designated pair of VLANs.
1. テストサイトと測定デバイスの各ペア間のL2TPv3パスを構成して、指定されたVLANペアでテストを実行します。
2. configure the network emulator to add 1.0 sec. one-way constant delay in one direction of transmission.
2. 1.0秒を追加するようにネットワークエミュレータを構成します。送信の一方向における一方向一定遅延。
3. measure (average) one-way delay with two or more implementations, using identical waiting time thresholds (Thresh) for loss set at 3 seconds.
3. 3秒に設定された損失に対して同じ待機時間しきい値（Thresh）を使用して、2つ以上の実装で一方向遅延を測定（平均）します。
4. configure the network emulator to add 3 sec. one-way constant delay in one direction of transmission equivalent to 2 seconds of additional one-way delay (or change the path delay while test is in progress, when there are sufficient packets at the first delay setting).
4. 3秒を追加するようにネットワークエミュレータを構成します。 2秒間の追加の一方向遅延に相当する、一方向の一定方向の伝送遅延（または、最初の遅延設定で十分なパケットがある場合は、テストの進行中にパス遅延を変更します）。
5. repeat/continue measurements.
5. 測定を繰り返します。
6. observe that the increase measured in step 5 caused all packets with 2 sec. additional delay to be declared lost, and that all packets that arrive successfully in step 3 are assigned a valid one-way delay.
6. 手順5で測定された増加が2秒のすべてのパケットを引き起こしたことに注意してください。失われたと宣言される追加の遅延、および手順3で正常に到着したすべてのパケットには、有効な一方向の遅延が割り当てられます。
The common parameters used for tests in this section are:
このセクションのテストに使用される一般的なパラメーターは次のとおりです。
o IP header + payload = 64 octets
o IPヘッダー+ペイロード= 64オクテット
o Poisson sampling at lambda = 1 packet per second
o ラムダでのポアソンサンプリング= 1パケット/秒
o Test duration = 900 seconds total (March 21, 2011)
o テスト期間=合計900秒（2011年3月21日）
The netem emulator was set to add constant delays as specified in the procedure above.
netemエミュレータは、上記の手順で指定された一定の遅延を追加するように設定されています。
In NetProbe, the Loss Threshold is implemented uniformly over all packets as a post-processing routine. With the Loss Threshold set at 3 seconds, all packets with one-way delay >3 seconds are marked "Lost" and included in the Lost Packet list with their transmission time (as required in Section 3.3 of [RFC2680]). This resulted in 342 packets designated as lost in one of the test streams (with average delay = 3.091 sec.).
NetProbeでは、損失しきい値は後処理ルーチンとしてすべてのパケットに均一に実装されます。損失しきい値が3秒に設定されている場合、一方向の遅延が3秒を超えるすべてのパケットは「損失」とマークされ、送信時間とともに[損失パケット]リストに含まれます（[RFC2680]のセクション3.3で必要）。これにより、いずれかのテストストリームで失われたと指定された342パケットが発生しました（平均遅延= 3.091秒）。
Perfas+ uses a fixed Loss Threshold that was not adjustable during this study. The Loss Threshold is approximately one minute, and emulation of a delay of this size was not attempted. However, it is possible to implement any delay threshold desired with a post-processing routine and subsequent analysis. Using this method, 195 packets would be declared lost (with average delay = 3.091 sec.).
Perfas +は、この調査では調整できなかった固定損失しきい値を使用します。損失しきい値は約1分で、このサイズの遅延のエミュレーションは試行されませんでした。ただし、後処理ルーチンとその後の分析で必要な遅延しきい値を実装することは可能です。この方法を使用すると、195パケットが失われたと宣言されます（平均遅延= 3.091秒）。
Both implementations assume that any constant delay value desired can be used as the Loss Threshold, since all delays are stored as a pair <Time, Delay> as required in [RFC2679]. This is a simple way to enforce the constant loss threshold envisioned in [RFC2679] (see specific section references above). We take the position that the assumption of post-processing is compliant and that the text of the RFC should be revised slightly to include this point.
すべての遅延は[RFC2679]で要求されるように<Time、Delay>のペアとして保存されるため、両方の実装は、必要な任意の一定の遅延値を損失しきい値として使用できると想定しています。これは、[RFC2679]で想定されている一定の損失しきい値を適用する簡単な方法です（上記の特定のセクションの参照を参照）。私たちは、後処理の前提が準拠していること、およびこの点を含むようにRFCのテキストを少し修正する必要があるという立場を取ります。
This test determines if implementations register the same relative change in delay from one packet size to another, indicating that the first-to-last time-stamping convention has been followed. This test tends to cancel the sources of error that may be present in an implementation.
このテストは、あるパケットサイズから別のパケットサイズへの遅延の同じ相対的な変化を実装が登録するかどうかを決定し、最初から最後までのタイムスタンプの規則に従っていることを示します。このテストは、実装に存在する可能性のあるエラーの原因をキャンセルする傾向があります。
See the requirements of Section 3.7.2 of [RFC2679], and Section 10.2 of [RFC2330].
[RFC2679]のセクション3.7.2と[RFC2330]のセクション10.2の要件をご覧ください。
1. configure an L2TPv3 path between test sites, and each pair of measurement devices to operate tests in their designated pair of VLANs, and ideally including a low-speed link (it was not possible to change the link configuration during testing, so the lowest speed link present was the basis for serialization time comparisons).
1. テストサイトと測定デバイスの各ペアの間のL2TPv3パスを構成し、指定されたVLANのペアでテストを実行し、理想的には低速リンクを含めます（テスト中にリンク構成を変更できなかったため、最低速度のリンク現在はシリアル化時間の比較の基礎でした）。
2. measure (average) one-way delay with two or more implementations, using identical options and equal size small packets (64-octet IP header and payload).
2. 同じオプションと同じサイズの小さいパケット（64オクテットのIPヘッダーとペイロード）を使用して、2つ以上の実装で一方向の遅延を測定します。
3. maintain the same path with additional emulated 100 ms one-way delay.
3. エミュレートされた100 msの一方向遅延を追加して、同じパスを維持します。
4. measure (average) one-way delay with two or more implementations, using identical options and equal size large packets (500 octet IP header and payload).
4. 同じオプションと同じサイズの大きなパケット（500オクテットのIPヘッダーとペイロード）を使用して、2つ以上の実装で一方向の遅延を測定します。
5. observe that the increase measured between 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の増加に相当することに注意してください。各システムの測定誤差のほとんどは、静止している場合はキャンセルする必要があります。
The common parameters used for tests in this section are:
このセクションのテストに使用される一般的なパラメーターは次のとおりです。
o IP header + payload = 64 octets
o IPヘッダー+ペイロード= 64オクテット
o Periodic sampling at l packet per second
o 1パケット/秒での定期的なサンプリング
o Test duration = 300 seconds total (April 12)
o テスト期間=合計300秒（4月12日）
The netem emulator was set to add constant 100 ms delay.
netemエミュレータは、100 msの一定の遅延を追加するように設定されていました。
When the IP header + payload size was increased from 64 octets to 500 octets, there was a delay increase observed.
IPヘッダー+ペイロードサイズが64オクテットから500オクテットに増加すると、遅延の増加が観察されました。
Mean Delays in us NetProbe Payload s1 s2 sA sB 500 190893 191179 190892 190971 64 189642 189785 189747 189467 Diff 1251 1394 1145 1505
米国内の平均遅延NetProbe Payload s1 s2 sA sB 500 190893 191179 190892 190971 64 189642 189785 189747 189467 Diff 1251 1394 1145 1505
Perfas Payload p1 p2 p3 p4 500 190908 190911 191126 190709 64 189706 189752 189763 190220 Diff 1202 1159 1363 489
ペイロード190908 190911 191126 190709クマP1 P2 P3 P4 64 189706 189752 189763 190220 DUT 500 1202 1159 1363 489
Serialization tests, all values in microseconds
シリアル化テスト、すべての値はマイクロ秒
The typical delay increase when the larger packets were used was 1.1 to 1.5 ms (with one outlier). The typical measurements indicate that a link with approximately 3 Mbit/s capacity is present on the path.
大きなパケットを使用した場合の一般的な遅延の増加は、1.1〜1.5 msでした（1つの異常値を含む）。一般的な測定では、パス上に約3 Mbit / sの容量のリンクが存在することが示されています。
Through investigation of the facilities involved, it was determined that the lowest speed link was approximately 45 Mbit/s, and therefore the estimated difference should be about 0.077 ms. The observed differences are much higher.
関係する施設を調査した結果、最低速度のリンクは約45メガビット/秒であることが判明したため、推定差は約0.077ミリ秒になるはずです。観察された違いははるかに大きいです。
The unexpected large delay difference was also the outcome when testing serialization times in a lab environment, using the NIST Net Emulator and NetProbe [ADV-METRICS].
NISTネットエミュレーターとNetProbe [ADV-METRICS]を使用して、ラボ環境でシリアル化時間をテストしたときに、予期しない大きな遅延の違いも結果でした。
Since it was not possible to confirm the estimated serialization time increases in field tests, we resort to examination of the implementations to determine compliance.
フィールドテストでは推定シリアル化時間の増加を確認できなかったため、実装を調査してコンプライアンスを判断します。
NetProbe performs all time stamping above the IP layer, accepting that some compromises must be made to achieve extreme portability and measurement scale. Therefore, the first-to-last bit convention is supported because the serialization time is included in the one-way delay measurement, enabling comparison with other implementations.
NetProbeは、IPレイヤーの上ですべてのタイムスタンプを実行し、極度の移植性と測定スケールを実現するためにいくつかの妥協が必要であることを受け入れます。したがって、シリアル化時間が一方向の遅延測定に含まれ、他の実装との比較が可能になるため、最初から最後までのビット規則がサポートされます。
Perfas+ is optimized for its purpose and performs all time stamping close to the interface hardware. The first-to-last bit convention is supported because the serialization time is included in the one-way delay measurement, enabling comparison with other implementations.
Perfas +はその目的に最適化されており、インターフェースハードウェアの近くですべてのタイムスタンプを実行します。シリアル化時間が一方向の遅延測定に含まれるため、最初から最後のビットの規則がサポートされ、他の実装との比較が可能になります。
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 an L2TPv3 path between test sites, and each pair of measurement devices to operate tests in their designated pair of VLANs.
1. テストサイトと測定デバイスの各ペア間のL2TPv3パスを構成して、指定されたVLANペアでテストを実行します。
2. measure (average) one-way delay with two 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 (average) 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であることに注意してください。各システムの測定誤差のほとんどは、静止している場合はキャンセルする必要があります。
In this test, X = 1000 ms and Y = 1000 ms.
このテストでは、X = 1000 msおよびY = 1000 msです。
The common parameters used for tests in this section are:
このセクションのテストに使用される一般的なパラメーターは次のとおりです。
o IP header + payload = 64 octets
o IPヘッダー+ペイロード= 64オクテット
o Poisson sampling at lambda = 1 packet per second
o ラムダでのポアソンサンプリング= 1パケット/秒
o Test duration = 900 seconds total (March 21, 2011)
o テスト期間=合計900秒（2011年3月21日）
The netem emulator was set to add constant delays as specified in the procedure above.
netemエミュレータは、上記の手順で指定された一定の遅延を追加するように設定されています。
Average pre-increase delay, microseconds 1089868.0 Average post 1 s additional, microseconds 2089686.0 Difference (should be ~= Y = 1 s) 999818.0
平均増加前遅延、マイクロ秒1089868.0平均ポスト1秒追加、マイクロ秒2089686.0差（〜= Y = 1秒である必要があります）999818.0
Average delays before/after 1 second increase
1秒増加の前後の平均遅延
The NetProbe implementation observed a 1 second increase with a 182 microsecond error (assuming that the netem emulated delay difference is exact).
NetProbeの実装では、182マイクロ秒のエラーで1秒の増加が観察されました（netemでエミュレートされた遅延の差が正確であると想定）。
We note that this differential delay test has been run under lab conditions and published in prior work [ADV-METRICS]. The error was 6 microseconds.
この差分遅延テストはラボ条件下で実行され、以前の研究[ADV-METRICS]で公開されていることに注意してください。エラーは6マイクロ秒でした。
Average pre-increase delay, microseconds 1089794.0 Average post 1 s additional, microseconds 2089801.0 Difference (should be ~= Y = 1 s) 1000007.0
平均増加前遅延、マイクロ秒1089794.0平均ポスト1秒追加、マイクロ秒2089801.0差（〜= Y = 1秒である必要があります）1000007.0
Average delays before/after 1 second increase
1秒増加の前後の平均遅延
The Perfas+ implementation observed a 1 second increase with a 7 microsecond error.
Perfas +実装では、7マイクロ秒のエラーで1秒の増加が観察されました。
Again, the live network conditions appear to have influenced the results, but both implementations measured the same delay increase within their calibration accuracy.
ここでも、ライブネットワークの状態が結果に影響を与えているように見えますが、どちらの実装でも、キャリブレーション精度内で同じ遅延の増加が測定されました。
The ADK tests the extent to which the sample distributions of one-way delay singletons from two implementations of [RFC2679] appear to be from the same overall distribution. By testing this way, we economize on the number of comparisons, because comparing a set of individual summary statistics (as defined in Section 5 of [RFC2679]) would require another set of individual evaluations of equivalence. Instead, we can simply check which statistics were implemented, and report on those facts, noting that Section 5 of [RFC2679] does not specify the calculations exactly, and gives only some illustrative examples.
ADKは、[RFC2679]の2つの実装からの一方向遅延シングルトンのサンプル分布が、同じ全体分布からどのように見えるかをテストします。この方法でテストすることで、比較の数を節約できます。これは、一連の個別の要約統計量（[RFC2679]のセクション5で定義）を比較するには、同等の個別の評価セットがさらに必要になるためです。代わりに、実装された統計を確認し、それらの事実について報告することができます。[RFC2679]のセクション5では計算が正確に指定されておらず、いくつかの例示的な例のみが示されています。
NetProbe Perfas+
NetProbeクマ+
5.1. Type-P-One-way-Delay-Percentile yes no
5.1. Type-P-One-way-Delay-Percentileはいいいえ
5.2. Type-P-One-way-Delay-Median yes no
5.2. Type-P-One-way-Delay-Medianはいいいえ
5.3. Type-P-One-way-Delay-Minimum yes yes
5.3. Type-P-One-way-Delay-Minimumはいはい
5.4. Type-P-One-way-Delay-Inverse-Percentile no no
5.4. Type-P-One-way-Delay-Inverse-Percentileいいえいいえ
Implementation of Section 5 Statistics
セクション5統計の実装
Only the Type-P-One-way-Delay-Inverse-Percentile has been ignored in both implementations, so it is a candidate for removal or deprecation in a revision of RFC 2679 (this small discrepancy does not affect candidacy for advancement).
Type-P-One-way-Delay-Inverse-Percentileのみが両方の実装で無視されているため、これはRFC 2679の改訂版での削除または非推奨の候補です（この小さな相違は、進歩の候補には影響しません）。
The conclusions throughout Section 6 support the advancement of [RFC2679] to the next step of the Standards Track, because its requirements are deemed to be clear and unambiguous based on evaluation of the test results for two implementations. The results indicate that these implementations produced statistically equivalent results under network conditions that were configured to be as close to identical as possible.
セクション6全体の結論は、[RFC2679]の標準トラックの次のステップへの進歩をサポートしています。これは、その要件が2つの実装のテスト結果の評価に基づいて明確で明確であると見なされるためです。結果は、これらの実装が、可能な限り同一に近くなるように構成されたネットワーク条件下で統計的に同等の結果を生成したことを示しています。
Sections 6.2.3 and 6.5 indicate areas where minor revisions are warranted in RFC 2679. The IETF has reached consensus on guidance for reporting metrics in [RFC6703], and this memo should be referenced in the revision to RFC 2679 to incorporate recent experience where appropriate.
セクション6.2.3および6.5は、RFC 2679で軽微な改訂が保証されている領域を示しています。IETFは、[RFC6703]のメトリックを報告するためのガイダンスについてコンセンサスに達しています。このメモは、RFC 2679の改訂で参照して、必要に応じて最近の経験を組み込む必要があります。
We note that there is currently one erratum with status "Held for Document Update" for [RFC2679], and it appears this minor revision and additional text should be incorporated in a revision of RFC 2679.
[RFC2679]のステータスが「Held for Document Update」になっているエラッタが現在1つあり、このマイナーリビジョンと追加のテキストはRFC 2679のリビジョンに組み込む必要があるようです。
The authors that revise [RFC2679] should review all errata filed at the time the document is being written. They should not rely upon this document to indicate all relevant errata updates.
[RFC2679]を改訂する執筆者は、ドキュメントの執筆時に提出されたすべての正誤表を確認する必要があります。関連するすべての正誤表の更新を示すために、このドキュメントに依存すべきではありません。
The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656] and [RFC5357].
ライブネットワークのアクティブな測定に適用されるセキュリティの考慮事項は、ここでも関係があります。 [RFC4656]と[RFC5357]を参照してください。
The authors thank Lars Eggert for his continued encouragement to advance the IPPM metrics during his tenure as AD Advisor.
著者は、AD Advisorとしての在職中にIPPMメトリックを前進させるための継続的な励ましに対してLars Eggertに感謝します。
Nicole Kowalski supplied the needed CPE router for the NetProbe side of the test setup, and graciously managed her testing in spite of issues caused by dual-use of the router. Thanks Nicole!
Nicole Kowalskiは、テストセットアップのNetProbe側に必要なCPEルーターを提供し、ルーターの二重使用による問題にもかかわらず、テストを丁寧に管理しました。ニコール、ありがとう！
The "NetProbe Team" also acknowledges many useful discussions with Ganga Maguluri.
「NetProbeチーム」は、Ganga Maguluriとの多くの有益な議論も認めています。
[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月。
[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月。
[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月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの片方向パケット損失メトリック」、RFC 2680、1999年9月。
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002.
[RFC3432] Raisanen、V.、Grotefeld、G。、およびA. Morton、「定期的なストリームによるネットワークパフォーマンス測定」、RFC 3432、2002年11月。
[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月。
[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月。
[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月。
[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, March 2012.
[RFC6576] Geib、R.、Morton、A.、Fardid、R。、およびA. Steinmitz、「IP Performance Metrics（IPPM）Standard Advancement Testing」、BCP 176、RFC 6576、2012年3月。
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, August 2012.
[RFC6703] Morton、A.、Ramachandran、G。、およびG. Maguluri、「Reporting IP Network Performance Metrics：Different Points of View」、RFC 6703、2012年8月。
[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-sample Anderson-Darling Tests of fit、for連続および離散ケース」、ワシントン大学、テクニカルレポートNo. 81、1986年5月。
[ADV-METRICS] Morton, A., "Lab Test Results for Advancing Metrics on the Standards Track", Work in Progress, October 2010.
[ADV-METRICS] Morton、A。、「Standards Trackのメトリクスを進めるためのラボテスト結果」、Work in Progress、2010年10月。
[Fedora14] Fedora Project, "Fedora Project Home Page", 2012, <http://fedoraproject.org/>.
[Fedora14] Fedora Project、「Fedora Project Home Page」、2012、<http://fedoraproject.org/>。
[METRICS-TEST] Bradner, S. and V. Paxson, "Advancement of metrics specifications on the IETF Standards Track", Work in Progress, August 2007.
[METRICS-TEST] Bradner、S.およびV. Paxson、「アドバンスメントのメトリック仕様のIETF標準トラック」、進行中の作業、2007年8月。
[Perfas] Heidemann, C., "Qualitaet in IP-Netzen Messverfahren", published by ITG Fachgruppe, 2nd meeting 5.2.3 (NGN), November 2001, <http://www.itg523.de/oeffentlich/01nov/ Heidemann_QOS_Messverfahren.pdf>.
[Perfas]ハイデマン、C。、「Qualitaet in IP-Netzen Messverfahren」、ITG Fachgruppeによる第2会議5.2.3（NGN）、2001年11月、<http://www.itg523.de/oeffnahm/01nov/ Heidemann_QOS_Messverfahren .pdf>。
[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月。
[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/>。
[WIPM] AT&T, "AT&T Global IP Network", 2012, <http://ipnetwork.bgtmo.ip.att.net/pws/index.html>.
[WIPM] AT＆T、「AT＆TグローバルIPネットワーク」、2012、<http://ipnetwork.bgtmo.ip.att.net/pws/index.html>。
[netem] The Linux Foundation, "netem", 2009, <http://www.linuxfoundation.org/collaborate/workgroups/ networking/netem>.
[netem] The Linux Foundation、 "netem"、2009、<http://www.linuxfoundation.org/collaborate/workgroups/ networking / netem>。
Authors' Addresses
著者のアドレス
Len Ciavattone AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
Len Ciavattone AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748 USA
Phone: +1 732 420 1239
EMail: lencia@att.com
Ruediger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt, 64295 Germany
Ruediger Geib Deutsche Telekom Heinrich Hertz Str。3-7 Darmstadt、64295 Germany
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/
Matthias Wieser Technical University Darmstadt Darmstadt, Germany
Matthias Wieser Technical University Darmstadtダルムシュタット、ドイツ
EMail: matthias_michael.wieser@stud.tu-darmstadt.de