[要約] RFC 7290は、RFC 2680の標準化を進めるためのテスト計画と結果を提供しています。このRFCの目的は、RFC 2680の実装の信頼性と互換性を確保するためのテスト手順を提供することです。
Internet Engineering Task Force (IETF) L. Ciavattone
Request for Comments: 7290 AT&T Labs
Category: Informational R. Geib
ISSN: 2070-1721 Deutsche Telekom
A. Morton
AT&T Labs
M. Wieser
Technical University Darmstadt
July 2014
Test Plan and Results for Advancing RFC 2680 on the Standards Track
標準トラックでRFC 2680を進めるためのテスト計画と結果
Abstract
概要
This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. 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 2680.
このメモは、標準トラックに沿って一方向のパケット損失メトリックを定義するパフォーマンスメトリックRFCであるRFC 2680を進めるためのサポートテスト計画と結果を提供します。このメモは、メトリックの実装ではなく、メトリックの定義自体が主な焦点であるべきであることに注目して、要件が意図どおりに解釈および実装されているかどうかを判断するために、特定のメトリック要件の句を評価するテスト手順について説明します。 RFC 2680の主要な仕様に対して、2つの完全に独立した実装がテストされています。
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/rfc7290.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7290で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
このドキュメントは、BCP 78およびIETFドキュメントに関連するIETFトラストの法的規定の対象です。
(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.
（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標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. RFC 2680 Coverage ..........................................5
2. A Definition-Centric Metric Advancement Process .................5
3. Test Configuration ..............................................5
4. Error Calibration and RFC 2680 ..................................9
4.1. Clock Synchronization Calibration ..........................9
4.2. Packet Loss Determination Error ...........................10
5. Predetermined Limits on Equivalence ............................10
6. Tests to Evaluate RFC 2680 Specifications ......................11
6.1. One-Way Loss: ADK Sample Comparison .......................11
6.1.1. 340B/Periodic Cross-Implementation Results .........12
6.1.2. 64B/Periodic Cross-Implementation Results ..........14
6.1.3. 64B/Poisson Cross-Implementation Results ...........15
6.1.4. Conclusions on the ADK Results for One-Way
Packet Loss ........................................16
6.2. One-Way Loss: Delay Threshold .............................16
6.2.1. NetProbe Results for Loss Threshold ................17
6.2.2. Perfas+ Results for Loss Threshold .................17
6.2.3. Conclusions for Loss Threshold .....................17
6.3. One-Way Loss with Out-of-Order Arrival ....................17
6.4. Poisson Sending Process Evaluation ........................19
6.4.1. NetProbe Results ...................................19
6.4.2. Perfas+ Results ....................................20
6.4.3. Conclusions for Goodness-of-Fit ....................22
6.5. Implementation of Statistics for One-Way Loss .............23
7. Conclusions for a Revision of RFC 2680 .........................23
8. Security Considerations ........................................24
9. Acknowledgements ...............................................24
10. Appendix - Network Configuration and Sample Commands ..........25
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................29
The IETF IP Performance Metrics (IPPM) working group has considered how to advance their metrics along the Standards Track since 2001.
IETF IPパフォーマンスメトリック（IPPM）ワーキンググループは、2001年以降、標準トラックに沿ってメトリックを進める方法を検討しています。
The renewed work effort sought to investigate ways in which the measurement variability could be reduced in order to thereby simplify the problem of comparison for equivalence. As a result, there is consensus (captured in [RFC6576]) that equivalent results from independent implementations of metric specifications are sufficient evidence that the specifications themselves are clear and unambiguous; it is the parallel concept of protocol interoperability for metric specifications. The advancement process either (1) produces confidence that the metric definitions and supporting material are clearly worded and unambiguous or (2) identifies ways in which the metric definitions should be revised to achieve clarity. It is a non-goal to compare the specific implementations themselves.
更新された作業は、同等性の比較の問題を簡略化するために、測定のばらつきを減らす方法を調査することを目的としていました。その結果、メトリック仕様の独立した実装からの同等の結果は、仕様自体が明確で明確であることの十分な証拠であるというコンセンサスがあります（[RFC6576]で取得）。これは、メトリック仕様のプロトコルの相互運用性の並行概念です。進歩プロセスは、（1）メトリック定義とサポート資料が明確に記述され、明確であることの信頼を生み出すか、または（2）メトリック定義を修正して明確にするための方法を特定します。特定の実装自体を比較することは目的ではありません。
The process also permits identification of options described in the metric RFC 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).
このプロセスでは、実装されなかったメトリックRFCに記載されているオプションの識別も許可されるため、拡張仕様からそれらを削除できます（これは、標準トラックに沿ったプロトコル拡張のより一般的な側面です）。
This memo's purpose is to implement the current approach for [RFC2680] and document the results.
このメモの目的は、[RFC2680]の現在のアプローチを実装し、結果を文書化することです。
In particular, this memo documents consensus on the extent of tolerable errors when assessing equivalence in the results. In discussions, the IPPM working group agreed that the test plan and procedures should include the threshold for determining equivalence, and this information should be available in advance of cross-implementation comparisons. This memo includes procedures for same-implementation comparisons to help set the equivalence threshold.
特に、このメモは、結果の同等性を評価する際の許容可能なエラーの程度に関するコンセンサスを文書化しています。議論の中で、IPPMワーキンググループは、テスト計画と手順に同等性を判断するためのしきい値を含める必要があり、この情報は実装間の比較の前に利用できるようにする必要があることに同意しました。このメモには、同等のしきい値の設定に役立つ同じ実装の比較の手順が含まれています。
Another aspect of the metric RFC advancement process is the requirement to document the work and results. The procedures of [RFC2026] are expanded in [RFC5657], including sample implementation and interoperability reports. This memo follows the template in [RFC6808] for the report that accompanies the protocol action request submitted to the Area Director, including a description of the test setup, procedures, results for each implementation, and conclusions.
メトリックRFCアドバンスプロセスの別の側面は、作業と結果を文書化する要件です。 [RFC2026]の手順は、[RFC5657]で拡張され、サンプルの実装と相互運用性レポートが含まれています。このメモは、[RFC6808]のテンプレートに従い、テストセットアップ、手順、各実装の結果、および結論の説明を含む、エリアディレクターに提出されたプロトコルアクションリクエストに付随するレポートに対応します。
The conclusion reached is that [RFC2680], with modifications, should be advanced on the Standards Track. The revised text of RFC 2680 [LOSS-METRIC] is ready for review but awaits work in progress to update the IPPM Framework [RFC2330]. Therefore, this memo documents the information to support the advancement of [RFC2680], and the approval of a revision of RFC 2680 is left for future action.
到達した結論は、[RFC2680]を変更して、標準化トラックで進める必要があるということです。 RFC 2680 [LOSS-METRIC]の改訂されたテキストはレビューの準備ができていますが、IPPMフレームワーク[RFC2330]の更新が進行中の作業を待っています。したがって、このメモは[RFC2680]の進歩をサポートするための情報を文書化しており、RFC 2680の改訂の承認は将来の行動に委ねられています。
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]. Some of these key words were used in [RFC2680], but there are no requirements specified in this memo.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。これらのキーワードの一部は[RFC2680]で使用されましたが、このメモで指定された要件はありません。
This plan is intended to cover all critical requirements and sections of [RFC2680].
この計画は、[RFC2680]のすべての重要な要件とセクションをカバーすることを目的としています。
Note that there are only five relevant instances of the requirement term "MUST" in [RFC2680], outside of the boilerplate and [RFC2119] reference; the instance of "MUST" in the Security Considerations section of [RFC2680] is not a basis for implementation equivalence comparisons.
[RFC2680]では、ボイラープレートと[RFC2119]参照の外に、要件用語「MUST」の関連インスタンスが5つしかないことに注意してください。 [RFC2680]のセキュリティに関する考慮事項セクションの「MUST」のインスタンスは、実装の同等性比較の基礎ではありません。
Statements in RFC 2680 that have the character of requirements may be included if the community reaches consensus that the wording implies a requirement. At least one instance of an implied requirement has been found in Section 3.6 of [RFC2680].
コミュニティーが表現が要件を暗示するというコンセンサスに達した場合、要件の特性を持つRFC 2680のステートメントを含めることができます。 [RFC2680]のセクション3.6で、暗黙の要件の少なくとも1つのインスタンスが見つかりました。
The process described in Section 3.5 of [RFC6576] takes as a first principle 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 the WIPM system and deployed worldwide [WIPM]). NetProbe uses UDP packets of variable size and can produce test streams with Periodic [RFC3432] or Poisson [RFC2330] sample distributions.
使用された1つのメトリック実装はNetProbeバージョン5.8.5でした（以前のバージョンはWIPMシステムで使用され、世界中に展開されています[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) [RFC3931] tunnel IDs (1 and 2), based on Figure 1 of [RFC6576].
図1は、[RFC6576]の図1に基づいて、各実装のテストフローがインターネットとレイヤ2トンネリングプロトコルバージョン3（L2TPv3）[RFC3931]トンネルID（1および2）を通過するときのテストパスのビューを示しています。
+------------+ +------------+
| Imp 1 | ,---. | Imp 2 |
+------------+ / \ +-------+ +------------+
| 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 (where "Imp #" is the sender and receiver of implementation 1 or 2 -- either Perfas+ or NetProbe in this test). The lower diagram shows example flows traveling between two measurement implementations. For simplicity, only two flows are shown, and the netem emulator is omitted (it would appear before or after the Internet, depending on the flow).
双方向トンネルを使用したテストセットアップの図。上の図は、VLAN接続と地理的な場所を強調しています（「Imp＃」は実装1または2の送信側と受信側です-このテストではPerfas +またはNetProbeのいずれかです）。下の図は、2つの測定実装間を移動するフローの例を示しています。簡単にするために、2つのフローのみが示され、netemエミュレーターは省略されます（フローに応じて、インターネットの前または後に表示されます）。
Figure 1
図1
The testing employs the 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.
このテストでは、インターネット上のテストサイト間に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 point of view of the test equipment.
トンネルの両端で、トンネルにカプセル化された1組のVLANがループバックされ、テストトラフィックが各テストサイトに返されます。したがって、テストストリームはL2TPトンネルを2回通過しますが、テスト機器の観点からは一方向のテストのように見えます。
The network emulator is a host running Fedora 14 Linux [FEDORA], with IP forwarding enabled and the "netem" Network emulator as part of the Fedora Kernel 2.6.35.11 [NETEM] loaded and operating. The standard kernel is "tickless", replacing the previous periodic timer (250 Hz, with 4 ms uncertainty) interrupts with on-demand interrupts. 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 operated on test streams traveling in one direction. In some tests, independent netem instances operated separately on each VLAN. See the Appendix for more details.
ネットワークエミュレータは、Fedora 14 Linux [FEDORA]を実行しているホストで、IP転送が有効になっており、Fedora Kernel 2.6.35.11 [NETEM]の一部として読み込まれ、動作している「netem」ネットワークエミュレータです。標準カーネルは「ティックレス」であり、以前の定期的なタイマー（250 Hz、4 ms不確実性）割り込みをオンデマンド割り込みに置き換えます。 netem / Fedoraホストを介した接続は、「brctl」コマンド（eth1.100 <-> eth2.100など）を使用してイーサネットVLANインターフェースをブリッジすることで実現されました。 netemエミュレーターは1つのインターフェース（eth1）でアクティブ化され、一方向に移動するテストストリームでのみ動作しました。一部のテストでは、独立したnetemインスタンスが各VLANで個別に動作しました。詳細については、付録を参照してください。
The links between the netem emulator host, the router, and the switch were found to be 100BaseTX-HD (100 Mbps half duplex), as reported by "mii-tool" [MII-TOOL] when testing was complete. The 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.
テストが完了したときに「mii-tool」[MII-TOOL]によって報告されたように、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.
個々のテストは、共通のパケットレート（1 pps、10 pps）のポアソン/定期分布、および64、340、500バイトのIPパケットサイズで実行されました。
For these tests, a stream of at least 300 packets was 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]による）が使用されました。
As required in Section 2.8.1 of [RFC2680], packet Type-P must be reported. The packet Type-P for this test was IP-UDP with Best Effort Differentiated Services Code Point (DSCP). These headers were encapsulated according to the L2TPv3 specification [RFC3931] and were unlikely to influence the treatment received as the packets traversed the Internet.
[RFC2680]のセクション2.8.1で要求されているように、パケットType-Pを報告する必要があります。このテストのパケットType-Pは、Best-Effort Differentiated Services Code Point（DSCP）を使用したIP-UDPでした。これらのヘッダーはL2TPv3仕様[RFC3931]に従ってカプセル化されており、パケットがインターネットを通過するときに受信される処理に影響を与えることはほとんどありませんでした。
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-Packet-Loss-<StreamType>-Stream
Type-IP-protocol-115-One-way-Packet-Loss- <StreamType> -Stream
With (Section 3.2 of [RFC2680]) metric parameters:
（[RFC2680]のセクション3.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 2.8.2 of [RFC2680])
+ 秒単位の最大待機時間（[RFC2680]のセクション2.8.2を参照）
Metric Units: A sequence of pairs; the elements of each pair are:
メートル法の単位：ペアのシーケンス。各ペアの要素は次のとおりです。
+ T, a time, and
+ T、時間、そして
+ L, either a zero or a one
+ L、ゼロまたは1
The values of T in the sequence are monotonically increasing. Note that T would be a valid parameter of *singleton* Type-P-One-way-Packet-Loss and that L would be a valid value of Type-P-One-way-Packet-Loss (see Section 3.3 of [RFC2680]).
シーケンスのTの値は単調に増加しています。 Tは* singleton * Type-P-One-way-Packet-Lossの有効なパラメーターであり、LはType-P-One-way-Packet-Lossの有効な値になることに注意してください（[RFC2680のセクション3.3を参照] ]）。
Also, Section 2.8.4 of [RFC2680] 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 traceroute can be conducted by the routers at each location.
また、[RFC2680]のセクション2.8.4は、パスを報告する必要があることを推奨しています。このテストセットアップでは、パスの詳細のほとんどがL2TPv3トンネルによって実装から隠されます。したがって、各ロケーションのルーターによって、より有益なパスtracerouteを実行できます。
When NetProbe is used in production, a traceroute is conducted in parallel at the outset of measurements.
NetProbeが本番環境で使用される場合、トレースルートは測定の最初に並行して実行されます。
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 * * *
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 * * *
NetProbe Traceroute
NetProbe Traceroute
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つで測定パスのtracerouteを実行することのみが可能でした（測定システムの通常のトレース機能は、L2TPv3トンネルカプセル化によって混乱します）。
An implementation is required to report calibration results on clock synchronization per Section 2.8.3 of [RFC2680] (also required in Section 3.7 of [RFC2680] for sample metrics).
[RFC2680]のセクション2.8.3に従ってクロック同期に関する調整結果を報告するための実装が必要です（サンプル指標については[RFC2680]のセクション3.7でも必要です）。
Also, it is recommended to report the probability that a packet successfully arriving at the destination network interface is incorrectly designated as lost due to resource exhaustion in Section 2.8.3 of [RFC2680].
また、[RFC2680]のセクション2.8.3で、リソース不足により、宛先ネットワークインターフェースに正常に到着したパケットが失われたと誤って指定されている確率を報告することをお勧めします。
For NetProbe and Perfas+ clock synchronization test results, refer to Section 4 of [RFC6808].
NetProbeとPerfas +のクロック同期テストの結果については、[RFC6808]のセクション4を参照してください。
Since both measurement implementations have resource limitations, it is theoretically possible that these limits could be exceeded and a packet that arrived at the destination successfully might be discarded in error.
どちらの測定実装にもリソース制限があるため、理論的にはこれらの制限を超え、宛先に正常に到着したパケットが誤って破棄される可能性があります。
In previous test efforts [ADV-METRICS], NetProbe produced six multicast streams with an aggregate bit rate over 53 Mbit/s, in order to characterize the one-way capacity of an emulator based on NIST Net. Neither the emulator nor the pair of NetProbe implementations used in this testing dropped any packets in these streams.
以前のテスト作業[ADV-METRICS]で、NetProbeはNIST Netに基づくエミュレーターの一方向容量を特徴付けるために、53 Mbit / sを超える総ビットレートで6つのマルチキャストストリームを生成しました。このテストで使用されたエミュレーターもNetProbe実装のペアも、これらのストリームのパケットをドロップしませんでした。
The maximum load used here between any two NetProbe implementations was 11.5 Mbit/s divided equally among three unicast test streams. We concluded that steady resource usage does not contribute error (additional loss) to the measurements.
ここで2つのNetProbe実装間で使用される最大負荷は、3つのユニキャストテストストリーム間で均等に分割された11.5 Mbit / sでした。安定したリソースの使用は、測定値にエラー（追加の損失）を引き起こさないと結論付けました。
In this section, we provide the numerical limits on comparisons between implementations in order to declare that the results are equivalent and that the tested specification is therefore clear.
このセクションでは、結果が同等であり、テストされた仕様が明確であることを宣言するために、実装間の比較に関する数値制限を提供します。
A key point is that the allowable errors, corrections, and confidence levels only need to be sufficient to detect any misinterpretation of the tested specification that would indicate 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) [ADK] comparisons, the required confidence factor for the cross-implementation comparisons SHALL be the smallest of:
Anderson-Darling K-sample（ADK）[ADK]比較の場合、クロス実装比較に必要な信頼係数は、以下の最小値でなければなりません。
o 0.95 confidence factor at 1-packet resolution, or
o 1パケットの解像度で0.95の信頼係数、または
o the smallest confidence factor (in combination with resolution) of the two same-implementation comparisons for the same test conditions (if the number of streams is sufficient to allow such comparisons).
o 同じテスト条件に対する2つの同じ実装の比較の最小の信頼係数（分解能と組み合わせたもの）（ストリームの数がそのような比較を可能にするのに十分である場合）。
For Anderson-Darling Goodness-of-Fit (ADGoF) [RADGOF] comparisons, the required level of significance for the same-implementation Goodness-of-Fit (GoF) SHALL be 0.05 or 5%, as specified in Section 11.4 of [RFC2330]. This is equivalent to a 95% confidence factor.
[RFC2330のセクション11.4で指定されているように、アンダーソンダーリングの適合度（ADGoF）[RADGOF]の比較では、同じ実装の適合度（GoF）に必要な有意水準は0.05または5％である必要があります（SHALL）。 ]。これは95％の信頼係数に相当します。
This section describes some results from production network (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 similar to those contained in Appendix A.1 of [RFC6576] for one-way delay.
手順は、一方向の遅延については、[RFC6576]の付録A.1に記載されているものと同様です。
This test determines if implementations produce results that appear to come from a common packet loss distribution, as an overall evaluation of Section 3 of [RFC2680] ("A Definition for Samples of One-way Packet Loss"). Same-implementation comparison results help to set the threshold of equivalence that will be applied to cross-implementation comparisons.
このテストでは、[RFC2680]のセクション3（「一方向パケット損失のサンプルの定義」）の総合評価として、実装が一般的なパケット損失の分布に由来するように見える結果を生成するかどうかを決定します。同じ実装の比較結果は、実装間の比較に適用される同等性のしきい値の設定に役立ちます。
This test is intended to evaluate measurements in Sections 2, 3, and 4 of [RFC2680].
このテストは、[RFC2680]のセクション2、3、および4の測定を評価することを目的としています。
By testing the extent to which the counts of one-way packet loss on different test streams of two [RFC2680] implementations appear to be from the same loss process, we reduce comparison steps because comparing the resulting summary statistics (as defined in Section 4 of [RFC2680]) would require a redundant set of equivalence evaluations. We can easily check whether the single statistic in Section 4 of [RFC2680] was implemented and report on that fact.
2つの[RFC2680]実装の異なるテストストリームで一方向パケット損失の数が同じ損失プロセスからのものであるように見える程度をテストすることにより、結果の要約統計量を比較するため、比較手順を減らします（セクション4で定義）。 [RFC2680]）は、等価評価の冗長なセットを必要とします。 [RFC2680]のセクション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 a sample of one-way packet loss singletons with two or more implementations, using identical options and network emulator settings (if used).
2. 同じオプションとネットワークエミュレーター設定（使用する場合）を使用して、2つ以上の実装で一方向のパケット損失シングルトンのサンプルを測定します。
3. Measure a sample of one-way packet loss singletons with *four or more* instances of the *same* implementations, using identical options, noting that connectivity differences SHOULD be the same as for cross-implementation testing.
3. 同じオプションを使用して、*同じ*実装の* 4つ以上*のインスタンスで一方向のパケット損失シングルトンのサンプルを測定します。接続の違いは、実装間のテストと同じである必要があることに注意してください。
4. If less than ten test streams are available, skip to step 7.
4. 使用できるテストストリームが10未満の場合は、手順7に進みます。
5. Apply the ADK comparison procedures (see Appendix B of [RFC6576]), and determine the resolution and confidence factor for distribution equivalence of each same-implementation comparison and each cross-implementation comparison.
5. ADK比較手順（[RFC6576]の付録Bを参照）を適用し、同じ実装ごとの比較と実装間の相互比較の分布の同等性に対する解像度と信頼係数を決定します。
6. 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.
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 metric parameters varied for each loss test, and they are listed first in each sub-section below.
メトリックパラメータは損失テストごとに異なり、以下の各サブセクションの最初にリストされています。
The cross-implementation comparison uses a simple ADK analysis [RTOOL] [RADK], where all NetProbe loss counts are compared with all Perfas+ loss results.
実装間の比較では、単純なADK分析[TOOL] [RACK]が使用され、すべてのNetProbe損失数がすべてのPerfas損失結果と比較されます。
In the results analysis of this section:
このセクションの結果分析では：
o All comparisons used 1-packet resolution.
o すべての比較で1パケットの解像度を使用しました。
o No correction factors were applied.
o 補正係数は適用されませんでした。
o The 0.95 confidence factor (and ADK criterion for t.obs < 1.960 for cross-implementation comparison) was used.
o 0.95の信頼係数（および実装間の比較のためのt.obs <1.960のADK基準）が使用されました。
Tests described in this section used:
このセクションで説明するテストでは、以下を使用しました。
o IP header + payload = 340 octets
o IPヘッダー+ペイロード= 340オクテット
o Periodic sampling at 1 packet per second
o 1パケット/秒での定期的なサンプリング
o Test duration = 1200 seconds (during April 7, 2011, EDT) The netem emulator was set for 100 ms constant delay, with a 10% loss ratio. 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テスト期間= 1200秒（2011年4月7日、EDT）netemエミュレーターは、100 msの一定遅延、10％の損失率に設定されました。この実験では、netemエミュレータは各VLANで独立して動作するように構成されました。したがって、エミュレータ自体が、テストパスをさまざまな方向に通過するストリームを比較するときに、潜在的なエラーの原因になります。
=======================================
A07bps_loss <- c(114, 175, 138, 142, 181, 105) (NetProbe)
A07per_loss <- c(115, 128, 136, 127, 139, 138) (Perfas+)
> A07bps_loss <- c(114, 175, 138, 142, 181, 105) > A07per_loss <- c(115, 128, 136, 127, 139, 138) > > A07cross_loss_ADK <- adk.test(A07bps_loss, A07per_loss) > A07cross_loss_ADK Anderson-Darling k-sample test.
> A07bps_loss <-c（114、175、138、142、181、105）> A07per_loss <-c（115、128、136、127、139、138）>> A07cross_loss_ADK <-adk.test（A07bps_loss、A07per_loss）> A07cross_loss_ADK Anderson-Darling k-sample test。
Number of samples: 2 Sample sizes: 6 6 Total number of values: 12 Number of unique values: 11
サンプル数：2サンプルサイズ：6 6値の総数：12一意の値の数：11
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.6569
アンダーソンダーリング基準の平均：1アンダーソンダーリング基準の標準偏差：0.6569
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.52043 0.20604 0 adj. for ties 0.62679 0.18607 0 >
t.obs P値の外挿は調整されていません。ネクタイ用0.52043 0.20604 0調整ネクタイ用0.62679 0.18607 0>
=======================================
The cross-implementation comparisons pass the ADK criterion (t.obs < 1.960).
実装間の比較はADK基準に合格しています（t.obs <1.960）。
Tests described in this section used:
このセクションで説明するテストでは、以下を使用しました。
o IP header + payload = 64 octets
o IPヘッダー+ペイロード= 64オクテット
o Periodic sampling at 1 packet per second
o 1パケット/秒での定期的なサンプリング
o Test duration = 300 seconds (during March 24, 2011, EDT)
o テスト期間= 300秒（2011年3月24日、EDT）
The netem emulator was set for 0 ms constant delay, with a 10% loss ratio.
netemエミュレーターは0 msの一定の遅延、10％の損失率に設定されました。
=======================================
> M24per_loss <- c(42,34,35,35) (Perfas+) > M24apd_23BC_loss <- c(27,39,29,24) (NetProbe) > M24apd_loss23BC_ADK <- adk.test(M24apd_23BC_loss,M24per_loss) > M24apd_loss23BC_ADK Anderson-Darling k-sample test.
> M24per_loss <-c（42,34,35,35）（Perfas +）> M24apd_23BC_loss <-c（27,39,29,24）（NetProbe）> M24apd_loss23BC_ADK <-adk.test（M24apd_23BC_loss、M24per_loss）> M24apd_lossersonBC_A23ダーリンk標本検定。
Number of samples: 2 Sample sizes: 4 4 Total number of values: 8 Number of unique values: 7
サンプル数：2サンプルサイズ：4 4値の総数：8一意の値の数：7
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.60978
アンダーソンダーリング基準の平均：1アンダーソンダーリング基準の標準偏差：0.60978
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.76921 0.16200 0 adj. for ties 0.90935 0.14113 0
t.obs P値の外挿は調整されていません。ネクタイ用0.76921 0.16200 0調整ネクタイ用0.90935 0.14113 0
Warning: At least one sample size is less than 5. p-values may not be very accurate. >
警告：少なくとも1つのサンプルサイズが5未満です。p値はあまり正確ではない場合があります。 >
=======================================
The cross-implementation comparisons pass the ADK criterion.
実装間の比較は、ADK基準に合格しています。
Tests described in this section used:
このセクションで説明するテストでは、以下を使用しました。
o IP header + payload = 64 octets
o IPヘッダー+ペイロード= 64オクテット
o Poisson sampling at lambda = 1 packet per second
o ラムダでのポアソンサンプリング= 1パケット/秒
o Test duration = 1200 seconds (during April 27, 2011, EDT)
o テスト期間= 1200秒（2011年4月27日、EDT）
The netem configuration was 0 ms delay and 10% loss, but there were two passes through an emulator for each stream, and loss emulation was present for 18 minutes of the 20-minute (1200-second) test.
netem構成は0 msの遅延と10％の損失でしたが、各ストリームに対してエミュレーターを2回通過し、20分間（1200秒）テストの18分間に損失エミュレーションが存在しました。
=======================================
A27aps_loss <- c(91,110,113,102,111,109,112,113) (NetProbe)
A27per_loss <- c(95,123,126,114) (Perfas+)
A27cross_loss_ADK <- adk.test(A27aps_loss, A27per_loss)
A27cross_loss_ADK <-adk.test（A27aps_loss、A27per_loss）
> A27cross_loss_ADK Anderson-Darling k-sample test.
> A27cross_loss_ADK Anderson-Darling k-sample test。
Number of samples: 2 Sample sizes: 8 4 Total number of values: 12 Number of unique values: 11
サンプル数：2サンプルサイズ：8 4値の総数：12一意の値の数：11
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.65642
アンダーソンダーリング基準の平均：1アンダーソンダーリング基準の標準偏差：0.65642
T = (Anderson Darling Criterion - mean)/sigma
Null Hypothesis: All samples come from a common population.
帰無仮説：すべてのサンプルは共通の母集団からのものです。
t.obs P-value extrapolation not adj. for ties 2.15099 0.04145 0 adj. for ties 1.93129 0.05125 0
t.obs P値の外挿は調整されていません。タイ用2.15099 0.04145 0調整タイ用1.93129 0.05125 0
Warning: At least one sample size is less than 5. p-values may not be very accurate. >
警告：少なくとも1つのサンプルサイズが5未満です。p値はあまり正確ではない場合があります。 >
=======================================
The cross-implementation comparisons barely pass the ADK criterion at 95% = 1.960 when adjusting for ties.
相互実装の比較は、同点を調整するときに95％= 1.960でADK基準をほとんど通過しません。
We conclude that the two implementations are capable of producing equivalent one-way packet loss measurements based on their interpretation of [RFC2680].
2つの実装は、[RFC2680]の解釈に基づいて、同等の一方向パケット損失測定値を生成できると結論付けます。
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 Section 2.8.2 of [RFC2680].
[RFC2680]のセクション2.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 second of one-way constant delay in one direction of transmission.
2. 送信の一方向に一方向の一定の遅延を1秒追加するようにネットワークエミュレーターを構成します。
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 seconds of one-way constant delay in one direction of transmission equivalent to 2 seconds of additional one-way delay (or change the path delay while the test is in progress, when there are sufficient packets at the first delay setting).
4. ネットワークエミュレーターを構成して、1方向の一定の遅延を1方向に3秒追加し、2秒間の追加の一方向遅延に相当します（または、最初に十分なパケットがある場合は、テストの進行中にパス遅延を変更します）遅延設定）。
5. Repeat/continue measurements.
5. 測定を繰り返します。
6. Observe that the increase measured in step 5 caused all packets with 2 seconds of 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 EDT) The netem emulator settings added constant delays as specified in the procedure above.
oテスト期間=合計900秒（2011年3月21日EDT）netemエミュレーターの設定により、上記の手順で指定された一定の遅延が追加されました。
In NetProbe, the loss threshold was 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 were 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, which 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 [RFC2680]. This is a simple way to enforce the constant loss threshold envisioned in [RFC2680] (see Section 2.8.2 of [RFC2680]). We take the position that the assumption of post-processing is compliant and that the text of the revision of RFC 2680 should be revised slightly to include this point.
すべての遅延は[RFC2680]で要求されるように<Time、Delay>のペアとして保存されるため、どちらの実装でも、必要な一定の遅延値を損失しきい値として使用できると想定しています。これは、[RFC2680]で想定されている一定の損失しきい値を適用する簡単な方法です（[RFC2680]のセクション2.8.2を参照）。私たちは、後処理の前提が準拠していること、およびこの点を含むようにRFC 2680の改訂のテキストを少し修正する必要があるという立場をとっています。
Section 3.6 of [RFC2680] indicates, with a lowercase "must" in the text, that implementations need to ensure that reordered packets are handled correctly. In essence, this is an implied requirement because the correct packet must be identified as lost if it fails to arrive before its delay threshold under all circumstances, and reordering is always a possibility on IP network paths. See [RFC4737] for the definition of reordering used in IETF standard-compliant measurements.
[RFC2680]のセクション3.6は、テキストに小文字の「必須」が含まれているため、実装では、並べ替えられたパケットが正しく処理されるようにする必要があることを示しています。本質的に、これは暗黙の要件です。すべての状況下で遅延しきい値の前に到着できなかった場合、正しいパケットが失われたと識別される必要があり、IPネットワークパスでは常に並べ替えが発生する可能性があるためです。 IETF標準に準拠した測定で使用される並べ替えの定義については、[RFC4737]を参照してください。
The netem emulator can produce packet reordering because each packet's delay is drawn from an independent distribution. Here, significant delay (2000 ms) and delay variation (1000 ms) were sufficient to produce packet reordering. Using the procedure described in Section 6.1, the netem emulator was set to introduce 10% loss while reordering was present.
各パケットの遅延は独立した分布から引き出されるため、netemエミュレータはパケットの並べ替えを生成できます。ここでは、大幅な遅延（2000ミリ秒）と遅延変動（1000ミリ秒）でパケットの並べ替えを行うのに十分でした。セクション6.1で説明した手順を使用して、Netemエミュレータは、並べ替えが存在する間に10％の損失をもたらすように設定されました。
The tests described in this section used:
このセクションで説明するテストでは、以下を使用しました。
o IP header + payload = 64 octets
o IPヘッダー+ペイロード= 64オクテット
o Periodic sampling = 1 packet per second
o 定期的なサンプリング= 1パケット/秒
o Test duration = 600 seconds (during May 2, 2011, EDT)
o テスト期間= 600秒（2011年5月2日、EDT）
=======================================
> Y02aps_loss <- c(53,45,67,55) (NetProbe) > Y02per_loss <- c(59,62,67,69) (Perfas+) > Y02cross_loss_ADK <- adk.test(Y02aps_loss, Y02per_loss) > Y02cross_loss_ADK Anderson-Darling k-sample test.
> Y02aps_loss <-c（53,45,67,55）（NetProbe）> Y02per_loss <-c（59,62,67,69）（Perfas +）> Y02cross_loss_ADK <-adk.test（Y02aps_loss、Y02per_loss）> Y02cross_loss_ADK Anderson-ダーリンk標本検定。
Number of samples: 2 Sample sizes: 4 4 Total number of values: 8 Number of unique values: 7
サンプル数：2サンプルサイズ：4 4値の総数：8一意の値の数：7
Mean of Anderson Darling Criterion: 1 Standard deviation of Anderson Darling Criterion: 0.60978
アンダーソンダーリング基準の平均：1アンダーソンダーリング基準の標準偏差：0.60978
T = (Anderson Darling Criterion - mean)/sigma
Null Hypothesis: All samples come from a common population.
帰無仮説：すべてのサンプルは共通の母集団からのものです。
t.obs P-value extrapolation not adj. for ties 1.11282 0.11531 0 adj. for ties 1.19571 0.10616 0
t.obs P値の外挿は調整されていません。タイ用1.11282 0.11531 0調整ネクタイ用1.19571 0.10616 0
Warning: At least one sample size is less than 5. p-values may not be very accurate. >
警告：少なくとも1つのサンプルサイズが5未満です。p値はあまり正確ではない場合があります。 >
=======================================
The test results indicate that extensive reordering was present. Both implementations capture the extensive delay variation between adjacent packets. In NetProbe, packet arrival order is preserved in the raw measurement files, so an examination of arrival packet sequence numbers also reveals reordering.
テスト結果は、大規模な並べ替えが存在したことを示しています。どちらの実装も、隣接するパケット間の広範な遅延変動をキャプチャします。 NetProbeでは、パケットの到着順序が未加工の測定ファイルに保存されるため、到着パケットのシーケンス番号を調べると、再順序付けもわかります。
Despite extensive continuous packet reordering present in the transmission path, the distributions of loss counts from the two implementations pass the ADK criterion at 95% = 1.960.
伝送パスに存在する広範な連続パケットの並べ替えにもかかわらず、2つの実装からの損失数の分布は、95％= 1.960でADK基準を満たしています。
Section 3.7 of [RFC2680] indicates that implementations need to ensure that their sending process is reasonably close to a classic Poisson distribution when used. Much more detail on sample distribution generation and Goodness-of-Fit testing is specified in Section 11.4 of [RFC2330] and the Appendix of [RFC2330].
[RFC2680]のセクション3.7は、実装では、使用する場合、送信プロセスが従来のポアソン分布にかなり近いことを確認する必要があることを示しています。サンプル分布の生成と適合度テストの詳細については、[RFC2330]のセクション11.4と[RFC2330]の付録に記載されています。
In this section, each implementation's Poisson distribution is compared with an idealistic version of the distribution available in the base functionality of the R-tool for Statistical Analysis [RTOOL] and performed using the Anderson-Darling Goodness-of-Fit test package (ADGofTest) [RADGOF]. The Goodness-of-Fit criterion derived from [RFC2330] requires a test statistic value AD <= 2.492 for 5% significance. The Appendix of [RFC2330] also notes that there may be difficulty satisfying the ADGofTest when the sample includes many packets (when 8192 were used, the test always failed, but smaller sets of the stream passed).
このセクションでは、各実装のポアソン分布を、統計分析用Rツール[RTOOL]の基本機能で使用可能な理想的なバージョンの分布と比較し、Anderson-Darling Goodness-of-Fitテストパッケージ（ADGofTest）を使用して実行します。 [RADGOF]。 [RFC2330]から導出された適合度基準は、5％の有意性に対して検定統計値AD <= 2.492を必要とします。 [RFC2330]の付録には、サンプルに多くのパケットが含まれている場合、ADGofTestを満たすのが難しい場合があることも記載されています（8192が使用された場合、テストは常に失敗しましたが、ストリームの小さなセットは合格しました）。
Both implementations were configured to produce Poisson distributions with lambda = 1 packet per second and to assign received packet timestamps in the measurement application (above the UDP layer; see the calibration results in Section 4 of [RFC6808] for error assessment).
どちらの実装も、ラムダ= 1パケット/秒のポアソン分布を生成し、測定アプリケーションで受信パケットのタイムスタンプを割り当てます（UDPレイヤーの上。エラー評価については、[RFC6808]のセクション4の調整結果を参照してください）。
Section 11.4 of [RFC2330] suggests three possible measurement points to evaluate the Poisson distribution. The NetProbe analysis uses "user-level timestamps made just before or after the system call for transmitting the packet".
[RFC2330]のセクション11.4は、ポアソン分布を評価するための3つの可能な測定点を示唆しています。 NetProbe分析では、「パケットを送信するためのシステムコールの直前または直後に作成されたユーザーレベルのタイムスタンプ」を使用します。
The statistical summary for two NetProbe streams is below:
2つのNetProbeストリームの統計の概要は次のとおりです。
=======================================
> summary(a27ms$s1[2:1152]) Min. 1st Qu. Median Mean 3rd Qu. Max. 0.0100 0.2900 0.6600 0.9846 1.3800 8.6390 > summary(a27ms$s2[2:1152]) Min. 1st Qu. Median Mean 3rd Qu. Max. 0.010 0.280 0.670 0.979 1.365 8.829
>要約（a27ms $ s1 [2：1152]）最小第1四半期中央値第3四半期マックス。 0.0100 0.2900 0.6600 0.9846 1.3800 8.6390>サマリー（a27ms $ s2 [2：1152]）最小第1四半期中央値第3四半期マックス。 0.010 0.280 0.670 0.979 1.365 8.829
=======================================
We see that both of the means are near the specified lambda = 1.
The results of ADGoF tests for these two streams are shown below:
これら2つのストリームのADGoFテストの結果を以下に示します。
=======================================
> ad.test( a27ms$s1[2:101], pexp, 1)
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27ms$s1[2:101] and pexp
AD = 0.8908, p-value = 0.4197
alternative hypothesis: NA
> ad.test( a27ms$s1[2:1001], pexp, 1)
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27ms$s1[2:1001] and pexp
AD = 0.9284, p-value = 0.3971
alternative hypothesis: NA
> ad.test( a27ms$s2[2:101], pexp, 1)
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27ms$s2[2:101] and pexp
AD = 0.3597, p-value = 0.8873
alternative hypothesis: NA
> ad.test( a27ms$s2[2:1001], pexp, 1)
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27ms$s2[2:1001] and pexp
AD = 0.6913, p-value = 0.5661
alternative hypothesis: NA
=======================================
We see that both sets of 100 packets and 1000 packets from two different streams (s1 and s2) all passed the AD <= 2.492 criterion.
2つの異なるストリーム（s1とs2）からの100パケットと1000パケットの両方のセットがすべてAD <= 2.492基準に合格したことがわかります。
Section 11.4 of [RFC2330] suggests three possible measurement points to evaluate the Poisson distribution. The Perfas+ analysis uses "wire times for the packets as recorded using a packet filter".
[RFC2330]のセクション11.4は、ポアソン分布を評価するための3つの可能な測定点を示唆しています。 Perfas +分析では、「パケットフィルターを使用して記録されたパケットのワイヤ時間」を使用します。
However, due to limited access at the Perfas+ side of the test setup, the captures were made after the Perfas+ streams traversed the production network, adding a small amount of unwanted delay variation to the wire times (and possibly error due to packet loss).
ただし、テストセットアップのPerfas +側でのアクセスが制限されているため、Perfas +ストリームが本番ネットワークを通過した後にキャプチャが行われ、ワイヤ時間に少量の不要な遅延変動が追加されました（パケット損失によるエラーも発生する可能性があります）。
The statistical summary for two Perfas+ streams is below:
2つのPerfas +ストリームの統計の概要は以下のとおりです。
=======================================
> summary(a27pe$p1) Min. 1st Qu. Median Mean 3rd Qu. Max. 0.004 0.347 0.788 1.054 1.548 4.231 > summary(a27pe$p2) Min. 1st Qu. Median Mean 3rd Qu. Max. 0.0010 0.2710 0.7080 0.9696 1.3740 7.1160
>要約（a27pe $ p1）最小第1四半期中央値第3四半期マックス。 0.004 0.347 0.788 1.054 1.548 4.231>要約（a27pe $ p2）最小第1四半期中央値第3四半期マックス。 0.0010 0.2710 0.7080 0.9696 1.3740 7.1160
=======================================
We see that both of the means are near the specified lambda = 1.
両方の平均が指定されたラムダ= 1に近いことがわかります。
The results of ADGoF tests for these two streams are shown below:
これら2つのストリームのADGoFテストの結果を以下に示します。
=======================================
> ad.test(a27pe$p1, pexp, 1 )
> ad.test（a27pe $ p1、pexp、1）
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27pe$p1 and pexp AD = 1.1364, p-value = 0.2930 alternative hypothesis: NA
データ：a27pe $ p1およびpexp AD = 1.1364、p値= 0.2930対立仮説：NA
> ad.test(a27pe$p2, pexp, 1 )
> ad.test（a27pe $ p2、pexp、1）
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27pe$p2 and pexp AD = 0.5041, p-value = 0.7424 alternative hypothesis: NA
データ：a27pe $ p2およびpexp AD = 0.5041、p値= 0.7424対立仮説：NA
> ad.test(a27pe$p1[1:100], pexp, 1 )
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27pe$p1[1:100] and pexp
AD = 0.7202, p-value = 0.5419
alternative hypothesis: NA
> ad.test(a27pe$p1[101:193], pexp, 1 )
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27pe$p1[101:193] and pexp
AD = 1.4046, p-value = 0.201
alternative hypothesis: NA
> ad.test(a27pe$p2[1:100], pexp, 1 )
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27pe$p2[1:100] and pexp
AD = 0.4758, p-value = 0.7712
alternative hypothesis: NA
> ad.test(a27pe$p2[101:193], pexp, 1 )
Anderson-Darling GoF Test
アンダーソンダーリングGoFテスト
data: a27pe$p2[101:193] and pexp
AD = 0.3381, p-value = 0.9068
alternative hypothesis: NA
>
＞
=======================================
We see that sets of 193, 100, and 93 packets from two different streams (p1 and p2) all passed the AD <= 2.492 criterion.
2つの異なるストリーム（p1およびp2）からの193、100、および93パケットのセットがすべてAD <= 2.492基準に合格したことがわかります。
Both NetProbe and Perfas+ implementations produce adequate Poisson distributions according to the Anderson-Darling Goodness-of-Fit at the 5% significance (1-alpha = 0.05, or 95% confidence level).
NetProbeとPerfas +の両方の実装は、5％の有意性（1-alpha = 0.05、つまり95％の信頼水準）でアンダーソンダーリング適合度に従って適切なポアソン分布を生成します。
We check to see which statistics were implemented and report on those facts, noting that Section 4 of [RFC2680] does not specify the calculations exactly and only gives some illustrative examples.
[RFC2680]のセクション4では計算が正確に指定されておらず、いくつかの例示的な例しか示されていないことに注意して、実装された統計を確認し、それらの事実について報告します。
NetProbe Perfas+
NetProbeクマ+
Type-P-One-way-Packet-Loss-Average yes yes (this is more commonly referred to as "loss ratio")
Type-P-One-way-Packet-Loss-Averageはいはい（これはより一般的に「損失率」と呼ばれます）
Implementation of RFC 2680 Section 4 Statistics
RFC 2680セクション4統計の実装
We note that implementations refer to this metric as a loss ratio, and this is an area for likely revision of the text to make it more consistent with widespread usage.
実装ではこのメトリクスを損失率と呼んでいることに注意してください。これは、広範な使用法との一貫性を保つために、テキストを改訂する可能性がある領域です。
This memo concludes that [RFC2680] should be advanced on the Standards Track and recommends the following edits to improve the text (which are not deemed significant enough to affect maturity).
このメモは、[RFC2680]を標準化トラックで進める必要があると結論付け、テキストを改善するために以下の編集を推奨します（成熟度に影響を与えるほど重要ではないと見なされます）。
o Revise Type-P-One-way-Packet-Loss-Ave to Type-P-One-way-Delay-Packet-Loss-Ratio.
o Type-P-One-way-Packet-Loss-AveをType-P-One-way-Packet-Loss-Ratioに修正します。
o Regarding implementation of the loss delay threshold (Section 6.2), the assumption of post-processing is compliant, and the text of the revision of RFC 2680 should be revised slightly to include this point.
o 損失遅延しきい値の実装（セクション6.2）に関しては、後処理の仮定は準拠しており、RFC 2680の改訂のテキストは、この点を含むように少し改訂する必要があります。
o The IETF has reached consensus on guidance for reporting metrics [RFC6703], and this memo should be referenced in a revision of RFC 2680 to incorporate recent experience where appropriate.
o IETFは、レポートメトリックス[RFC6703]のガイダンスについてコンセンサスに達しました。このメモは、RFC 2680の改訂で参照して、必要に応じて最近の経験を組み込む必要があります。
We note that there are at least two errata for [RFC2680], and it appears that these minor revisions should be incorporated in a revision of RFC 2680.
[RFC2680]には少なくとも2つのエラッタがあり、これらのマイナーリビジョンはRFC 2680のリビジョンに組み込む必要があるようです。
The authors that revise [RFC2680] 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.
[RFC2680]を改訂する執筆者は、ドキュメントの執筆時に提出されたすべての正誤表を確認する必要があります。関連するすべての正誤表の更新を示すために、このドキュメントに依存すべきではありません。
We recognize the existence of BCP 170 [RFC6390], which provides guidelines for development of documents describing new performance metrics. However, the advancement of [RFC2680] represents fine-tuning of long-standing specifications based on experience that helped to formulate BCP 170, and material that satisfies some of the requirements of [RFC6390] can be found in other RFCs, such as the IPPM Framework [RFC2330]. Thus, no specific changes to address BCP 170 guidelines are recommended for a revision of RFC 2680.
新しいパフォーマンスメトリックを説明するドキュメントの開発に関するガイドラインを提供するBCP 170 [RFC6390]の存在を認識しています。ただし、[RFC2680]の進歩は、BCP 170の策定に役立った経験に基づいた長年の仕様の微調整を表しており、[RFC6390]の要件の一部を満たす資料は、IPPMなどの他のRFCにあります。フレームワーク[RFC2330]。したがって、BCP 170ガイドラインに対処するための特定の変更は、RFC 2680の改訂では推奨されていません。
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 Customer Premises Equipment (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 on statistical interpretation with Ganga Maguluri.
「NetProbeチーム」は、Ganga Maguluriとの統計的解釈に関する多くの有用な議論も認めています。
Constructive comments and helpful reviews were also provided by Bill Cerveny, Joachim Fabini, and Ann Cerveny.
建設的なコメントと役立つレビューも、ビルサーヴェニー、ヨアヒムファビーニ、アンサーヴェニーから提供されました。
This Appendix provides some background information on the host configuration and sample tc commands for the "netem" network emulator, as described in Section 3 and Figure 1 of this memo. These details are also applicable to the test plan in [RFC6808].
この付録は、このメモのセクション3と図1で説明されているように、「netem」ネットワークエミュレーターのホスト構成とサンプルtcコマンドに関するいくつかの背景情報を提供します。これらの詳細は、[RFC6808]のテスト計画にも適用されます。
The host interface and configuration are shown below. Due to the limit of 72 characters per line, line breaks were added to the "tc" commands in the output below.
ホストのインターフェースと構成を以下に示します。 1行あたり72文字の制限があるため、以下の出力の「tc」コマンドに改行が追加されました。
[system@dell4-4 ~]$ su
Password:
[root@dell4-4 system]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
[root@dell4-4 system]# service iptables stop
iptables: Flushing firewall rules: [ OK ]
iptables: Setting chains to policy ACCEPT: nat filter [ OK ]
iptables: Unloading modules: [ OK ]
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.000000000000 yes
[root@dell4-4 system]# ifconfig eth1.300 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth1.400 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.400 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.300 0.0.0.0 promisc up
[root@dell4-4 system]# brctl addbr br300
[root@dell4-4 system]# brctl addif br300 eth1.300
[root@dell4-4 system]# brctl addif br300 eth2.300
[root@dell4-4 system]# ifconfig br300 up
[root@dell4-4 system]# brctl addbr br400
[root@dell4-4 system]# brctl addif br400 eth1.400
[root@dell4-4 system]# brctl addif br400 eth2.400
[root@dell4-4 system]# ifconfig br400 up
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
br300 8000.0002b3109b8a no eth1.300
eth2.300
br400 8000.0002b3109b8a no eth1.400
eth2.400
virbr0 8000.000000000000 yes
[root@dell4-4 system]# brctl showmacs br300
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
1 00:02:b3:c4:c9:7a no 0.52
2 00:02:b3:cf:02:c6 no 0.52
2 00:0b:5f:54:de:81 no 0.01
[root@dell4-4 system]# brctl showmacs br400
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
2 00:02:b3:c4:c9:7a no 0.60
1 00:02:b3:cf:02:c6 no 0.42
2 00:0b:5f:54:de:81 no 0.33
[root@dell4-4 system]# tc qdisc add dev eth1.300 root netem
delay 100ms
[root@dell4-4 system]# ifconfig eth1.200 0.0.0.0 promisc up
[root@dell4-4 system]# vconfig add eth1 100
Added VLAN with VID == 100 to IF -:eth1:-
[root@dell4-4 system]# ifconfig eth1.100 0.0.0.0 promisc up
[root @ dell4-4 system]＃ifconfig eth1.100 0.0.0.0 promisc up
[root@dell4-4 system]# vconfig add eth2 100
Added VLAN with VID == 100 to IF -:eth2:-
[root@dell4-4 system]# ifconfig eth2.100 0.0.0.0 promisc up
[root@dell4-4 system]# ifconfig eth2.200 0.0.0.0 promisc up
[root@dell4-4 system]# brctl addbr br100
[root@dell4-4 system]# brctl addif br100 eth1.100
[root@dell4-4 system]# brctl addif br100 eth2.100
[root@dell4-4 system]# ifconfig br100 up
[root@dell4-4 system]# brctl addbr br200
[root@dell4-4 system]# brctl addif br200 eth1.200
[root@dell4-4 system]# brctl addif br200 eth2.200
[root@dell4-4 system]# ifconfig br200 up
[root@dell4-4 system]# brctl show
bridge name bridge id STP enabled interfaces
br100 8000.0002b3109b8a no eth1.100
eth2.100
br200 8000.0002b3109b8a no eth1.200
eth2.200
br300 8000.0002b3109b8a no eth1.300
eth2.300
br400 8000.0002b3109b8a no eth1.400
eth2.400
virbr0 8000.000000000000 yes
[root@dell4-4 system]# brctl showmacs br100
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
1 00:0a:e4:83:89:07 no 0.19
2 00:0b:5f:54:de:81 no 0.91
2 00:e0:ed:0f:72:86 no 1.28
[root@dell4-4 system]# brctl showmacs br200
port no mac addr is local? ageing timer
2 00:02:b3:10:9b:8a yes 0.00
1 00:02:b3:10:9b:99 yes 0.00
2 00:0a:e4:83:89:07 no 1.14
2 00:0b:5f:54:de:81 no 1.87
1 00:e0:ed:0f:72:86 no 0.24
[root@dell4-4 system]# tc qdisc add dev eth1.100 root netem
delay 100ms
[root@dell4-4 system]#
=====================================================================
Some sample tc command lines controlling netem and its impairments are given below.
netemとその障害を制御するいくつかのサンプルtcコマンドラインを以下に示します。
tc qdisc add dev eth1.100 root netem loss 0% tc qdisc add dev eth1.200 root netem loss 0% tc qdisc add dev eth1.300 root netem loss 0% tc qdisc add dev eth1.400 root netem loss 0%
tc qdisc add dev eth1.100ルートnetem損失0％tc qdisc add dev eth1.200ルートnetem損失0％tc qdisc add dev eth1.300ルートnetem損失0％tc qdisc add dev eth1.400ルートnetem損失0％
Add delay and delay variation: tc qdisc change dev eth1.100 root netem delay 100ms 50ms tc qdisc change dev eth1.200 root netem delay 100ms 50ms tc qdisc change dev eth1.300 root netem delay 100ms 50ms tc qdisc change dev eth1.400 root netem delay 100ms 50ms
遅延と遅延の変化を追加：tc qdisc change dev eth1.100 root netem delay 100ms 50ms tc qdisc change dev eth1.200 root netem delay 100ms 50ms tc qdisc change dev eth1.300 root netem delay 100ms 50ms tc qdisc change dev eth1.400 root netem遅延100ms 50ms
Add delay, delay variation, and loss: tc qdisc change dev eth1 root netem delay 2000ms 1000ms loss 10%
遅延、遅延変動、および損失を追加：tc qdisc change dev eth1 root netem delay 2000ms 1000ms loss 10％
=====================================================================
[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.、Madhavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、1998年5月。
[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月。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.
[RFC4737] Morton、A.、Ciavattone、L.、Ramachandran、G.、Shalunov、S。、およびJ. Perser、「Packet Reordering Metrics」、RFC 4737、2006年11月。
[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月。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[RFC6390] Clark、A。およびB. Claise、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、2011年10月。
[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月。
[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track", RFC 6808, December 2012.
[RFC6808] Ciavattone、L.、Geib、R.、Morton、A。、およびM. Wieser、「Test Plan and Results Supporting RFC 2679 on the Standards Track」、RFC 6808、2012年12月。
[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月。
[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月。
[FEDORA] "Fedora", <http://fedoraproject.org/>.
[FEDORA]「Fedora」、<http://fedoraproject.org/>。
[LOSS-METRIC] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IPPM", Work in Progress, July 2014.
[ロスメトリック] Almes、G.、Kalidindi、S.、Zekauskas、M。、およびA. Morton、編、「A IP-Way Loss Metric for IPPM」、Work in Progress、2014年7月。
[MII-TOOL] Hinds, D., Becker, D., and B. Eckenfels, "Linux System Administrator's Manual", February 2013, <http://man7.org/linux/man-pages/man8/mii-tool.8.html>.
[MII-TOOL] Hinds、D.、Becker、D。、およびB. Eckenfels、「Linux System Administrator's Manual」、2013年2月、<http://man7.org/linux/man-pages/man8/mii-tool .8.html>。
[NETEM] Linux Foundation, "netem", <http://www.linuxfoundation.org/collaborate/workgroups/ networking/netem>.
[NETEM] Linux Foundation、「netem」、<http://www.linuxfoundation.org/collaborate/workgroups/ networking / netem>。
[Perfas] Heidemann, C., "Qualitaet in IP-Netzen Messverfahren", published by ITG Fachgruppe, 2nd meeting 5.2.3, November 2001, <www.itg523.de/oeffentlich/01nov/ Heidemann_QOS_Messverfahren.pdf>.
[Perfas] Heidemann、C。、「Qualitaet in IP-Netzen Messverfahren」、ITG Fachgruppeによる第2会議5.2.3、2001年11月、<www.itg523.de/oeffnahm/01nov/ Heidemann_QOS_Messverfahren.pdf>。
[RADGOF] Bellosta, C., "ADGofTest: Anderson-Darling Goodness-of-Fit Test. R package version 0.3.", R-Package Version 0.3, December 2011, <http://cran.r-project.org/web/packages/ ADGofTest/index.html>.
[RADGOF] Bellosta、C。、「ADGofTest：Anderson-Darling Goodness-of-Fit Test。R package version 0.3。」、R-Package Version 0.3、2011年12月、<http://cran.r-project.org/ web / packages / ADGofTest / index.html>。
[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年。
[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月。
[RTOOL] R Development Core Team, "R: A Language and Environment for Statistical Computing", ISBN 3-900051-07-0, 2014, <http://www.R-project.org/>.
[RTOOL] R開発コアチーム、「R：統計計算のための言語と環境」、ISBN 3-900051-07-0、2014、<http://www.R-project.org/>。
[WIPM] AT&T, "AT&T Global IP Network", 2014, <http://ipnetwork.bgtmo.ip.att.net/pws/index.html>.
[WIPM] AT＆T、「AT＆TグローバルIPネットワーク」、2014、<http://ipnetwork.bgtmo.ip.att.net/pws/index.html>。
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ダルムシュタット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/
Matthias Wieser Technical University Darmstadt Darmstadt Germany
マティアスヴィーザー工科大学ダルムシュタットダルムシュタットドイツ
EMail: matthias_michael.wieser@stud.tu-darmstadt.de