[要約] 要約：RFC 6703は、異なる視点からIPネットワークのパフォーマンスメトリクスを報告するためのガイドラインです。 目的：このRFCの目的は、ネットワークパフォーマンスの測定と報告に関する異なる視点を提供し、ネットワーク管理者や研究者がより効果的なネットワークトラブルシューティングや最適化を行えるようにすることです。
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 6703 G. Ramachandran
Category: Informational G. Maguluri
ISSN: 2070-1721 AT&T Labs
August 2012
Reporting IP Network Performance Metrics: Different Points of View
IPネットワークパフォーマンスメトリックのレポート：さまざまな視点
Abstract
概要
Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs.
IPネットワークパフォーマンスメトリックの利用者は、さまざまな用途を想定しています。このメモは、2人の主要な対象者の視点の分析に基づいて、「長期」のレポートに関する考慮事項（たとえば、10秒ではなく、時間、日、週、または月）を提供します。これらのオーディエンスカテゴリが、ニーズに役立つ情報を探すときに、メトリックパラメータとオプションの選択にどのように影響するかを説明します。
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/rfc6703.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6703で入手できます。
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標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
2. Purpose and Scope ...............................................4
3. Reporting Results ...............................................5
3.1. Overview of Metric Statistics ..............................5
3.2. Long-Term Reporting Considerations .........................6
4. Effect of POV on the Loss Metric ................................8
4.1. Loss Threshold .............................................8
4.1.1. Network Characterization ............................8
4.1.2. Application Performance ............................11
4.2. Errored Packet Designation ................................11
4.3. Causes of Lost Packets ....................................11
4.4. Summary for Loss ..........................................12
5. Effect of POV on the Delay Metric ..............................12
5.1. Treatment of Lost Packets .................................12
5.1.1. Application Performance ............................13
5.1.2. Network Characterization ...........................13
5.1.3. Delay Variation ....................................14
5.1.4. Reordering .........................................15
5.2. Preferred Statistics ......................................15
5.3. Summary for Delay .........................................16
6. Reporting Raw Capacity Metrics .................................16
6.1. Type-P Parameter ..........................................17
6.2. A priori Factors ..........................................17
6.3. IP-Layer Capacity .........................................17
6.4. IP-Layer Utilization ......................................18
6.5. IP-Layer Available Capacity ...............................18
6.6. Variability in Utilization and Available Capacity .........19
6.6.1. General Summary of Variability .....................19
7. Reporting Restricted Capacity Metrics ..........................20
7.1. Type-P Parameter and Type-C Parameter .....................21
7.2. A Priori Factors ..........................................21
7.3. Measurement Interval ......................................22
7.4. Bulk Transfer Capacity Reporting ..........................22
7.5. Variability in Bulk Transfer Capacity .....................23
8. Reporting on Test Streams and Sample Size ......................23
8.1. Test Stream Characteristics ...............................23
8.2. Sample Size ...............................................24
9. Security Considerations ........................................25
10. Acknowledgements ..............................................25
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
When designing measurements of IP networks and presenting a result, knowledge of the audience is a key consideration. To present a useful and relevant portrait of network conditions, one must answer the following question:
IPネットワークの測定を設計して結果を提示する場合、対象者の知識が重要な考慮事項です。ネットワーク状態の有用で関連性のある肖像画を提示するには、次の質問に答える必要があります。
"How will the results be used?"
「結果はどのように使用されますか？」
There are two main audience categories for the report of results:
結果のレポートには、主に2つのオーディエンスカテゴリがあります。
1. Network Characterization - describes conditions in an IP network for quality assurance, troubleshooting, modeling, Service Level Agreements (SLAs), etc. This point of view (POV) looks inward toward the network where the report consumer intends their actions.
1. ネットワークの特性評価-品質保証、トラブルシューティング、モデリング、サービスレベルアグリーメント（SLA）などのIPネットワークの状態について説明します。この視点（POV）は、レポートの消費者がアクションを意図しているネットワークを内向きに見ます。
2. Application Performance Estimation - describes the network conditions in a way that facilitates determining effects on user applications, and ultimately the users themselves. This POV looks outward, toward the user(s), accepting the network as is. This report consumer intends to estimate a network-dependent aspect of performance or design some aspect of an application's accommodation of the network. (These are *not* application metrics; they are defined at the IP layer.)
2. アプリケーションパフォーマンスの見積もり-ユーザーのアプリケーション、そして最終的にはユーザー自身への影響を特定しやすくする方法でネットワークの状態を説明します。このPOVは、ネットワークをそのまま受け入れて、ユーザーの方を外側に向けます。このレポートコンシューマは、ネットワークに依存するパフォーマンスの側面を推定したり、アプリケーションのネットワークへの対応の一部の側面を設計したりすることを目的としています。 （これらはアプリケーションメトリックではありません。IPレイヤーで定義されます。）
This memo considers how these different POVs affect both the measurement design (parameters and options of the metrics) and statistics reported when serving the report consumer's needs.
このメモは、これらのさまざまなPOVが、レポートの消費者のニーズに応えるときにレポートされる測定デザイン（パラメーターのパラメーターとオプション）と統計の両方にどのように影響するかを考慮しています。
The IP Performance Metrics (IPPM) Framework [RFC2330] and other RFCs describing IPPM provide a background for this memo.
IPパフォーマンスメトリック（IPPM）フレームワーク[RFC2330]およびIPPMを説明する他のRFCは、このメモの背景を提供します。
The purpose of this memo is to clearly delineate two POVs for using measurements and describe their effects on the test design, including the selection of metric parameters and reporting the results.
このメモの目的は、測定を使用するための2つのPOVを明確に描写し、メトリックパラメーターの選択と結果のレポートを含む、テスト設計へのそれらの影響を説明することです。
The scope of this memo primarily covers the test design and reporting of the loss and delay metrics [RFC2680] [RFC2679]. It will also discuss the delay variation [RFC3393] and reordering metrics [RFC4737] where applicable.
このメモの範囲は、主にテスト設計と損失および遅延メトリックのレポート[RFC2680] [RFC2679]をカバーしています。また、遅延変動[RFC3393]と、必要に応じてメトリックの順序変更[RFC4737]についても説明します。
With capacity metrics growing in relevance to the industry, the memo also covers POV and reporting considerations for metrics resulting from the Bulk Transfer Capacity Framework [RFC3148] and Network Capacity Definitions [RFC5136]. These memos effectively describe two different categories of metrics:
容量メトリックが業界に関連して成長しているため、メモはPOVおよびバルク転送容量フレームワーク[RFC3148]とネットワーク容量定義[RFC5136]から生じるメトリックのレポートに関する考慮事項もカバーしています。これらのメモは、2つの異なるメトリックカテゴリを効果的に説明しています。
o Restricted [RFC3148]: includes restrictions of congestion control and the notion of unique data bits delivered, and
o 制限付き[RFC3148]：輻輳制御の制限と配信される一意のデータビットの概念が含まれます。
o Raw [RFC5136]: uses a definition of raw capacity without the restrictions of data uniqueness or congestion awareness.
o Raw [RFC5136]：データの一意性や輻輳認識の制限なしに、未加工容量の定義を使用します。
It might seem, at first glance, that each of these metrics has an obvious audience (raw = network characterization, restricted = application performance), but reality is more complex and consistent with the overall topic of capacity measurement and reporting. For example, TCP is usually used in restricted capacity measurement methods, while UDP appears in raw capacity measurement. The raw and restricted capacity metrics will be treated in separate sections, although they share one common reporting issue: representing variability in capacity metric results as part of a long-term report.
一見すると、これらの各メトリックには明らかな対象者（生=ネットワークの特性、制限=アプリケーションのパフォーマンス）があるように見えますが、実際はより複雑で、容量測定とレポートの全体的なトピックと一致しています。たとえば、TCPは通常、制限された容量測定方法で使用されますが、UDPはraw容量測定で使用されます。未加工の容量メトリックと制限された容量メトリックは、別々のセクションで扱われますが、それらは1つの共通のレポートの問題を共有します：長期レポートの一部として容量メトリック結果の変動性を表します。
Sampling, or the design of the active packet stream that is the basis for the measurements, is also discussed.
サンプリング、または測定の基礎となるアクティブパケットストリームの設計についても説明します。
This section gives an overview of recommendations, followed by additional considerations for reporting results in the "long term", based on the discussion and conclusions of the major sections that follow.
このセクションでは、推奨事項の概要を示し、その後に続く主要セクションの説明と結論に基づいて、「長期」で結果を報告するための追加の考慮事項を示します。
This section gives an overview of reporting recommendations for all the metrics considered in this memo.
このセクションでは、このメモで検討されているすべてのメトリックのレポートに関する推奨事項の概要を示します。
The minimal report on measurements must include both loss and delay metrics.
測定に関する最小限のレポートには、損失と遅延の両方のメトリックを含める必要があります。
For packet loss, the loss ratio defined in [RFC2680] is a sufficient starting point -- especially the existing guidance for setting the loss threshold waiting time. In Section 4.1.1, we have calculated a waiting time -- 51 seconds -- that should be sufficient to differentiate between packets that are truly lost or have long finite delays under general measurement circumstances. Knowledge of specific conditions can help to reduce this threshold, and a waiting time of approximately 50 seconds is considered to be manageable in practice.
パケット損失の場合、[RFC2680]で定義された損失率は十分な出発点です。特に、損失しきい値の待機時間を設定するための既存のガイダンスです。セクション4.1.1では、一般的な測定環境で本当に失われたパケットや長い有限遅延があるパケットを区別するのに十分な待機時間（51秒）を計算しました。特定の条件の知識は、このしきい値を減らすのに役立ちます。約50秒の待機時間は、実際には管理可能であると見なされます。
We note that a loss ratio calculated according to [Y.1540] would exclude errored packets from the numerator. In practice, the difference between these two loss metrics is small, if any, depending on whether the last link prior to the Destination contributes errored packets.
[Y.1540]に従って計算された損失率は、分子からエラーのあるパケットを除外することに注意してください。実際には、宛先の前の最後のリンクがエラーのあるパケットに寄与しているかどうかに応じて、これらの2つの損失メトリックの差はあるとしてもわずかです。
For packet delay, we recommend providing both the mean delay and the median delay with lost packets designated as undefined (as permitted by [RFC2679]). Both statistics are based on a conditional distribution, and the condition is packet arrival prior to a waiting time dT, where dT has been set to take maximum packet lifetimes into account, as discussed above for loss. Using a long dT helps to ensure that delay distributions are not truncated.
パケット遅延については、失われたパケットを未定義として指定して、平均遅延と中央遅延の両方を提供することをお勧めします（[RFC2679]で許可されているとおり）。どちらの統計情報も条件付き分布に基づいており、条件は待機時間dTの前のパケット到着です。dTは、前述の損失について説明したように、最大パケットライフタイムを考慮するように設定されています。長いdTを使用すると、遅延分布が切り捨てられないようにするのに役立ちます。
For Packet Delay Variation (PDV), the minimum delay of the conditional distribution should be used as the reference delay for computing PDV according to [Y.1540] or [RFC5481] and [RFC3393]. A useful value to report is a "pseudo" range of delay variation based on calculating the difference between a high percentile of delay and the minimum delay. For example, the 99.9th percentile minus the minimum will give a value that can be compared with objectives in [Y.1541].
パケット遅延変動（PDV）の場合、[Y.1540]または[RFC5481]および[RFC3393]に従ってPDVを計算するための基準遅延として、条件付き分布の最小遅延を使用する必要があります。報告するのに役立つ値は、遅延の高いパーセンタイルと最小遅延との差の計算に基づく遅延変動の「疑似」範囲です。たとえば、99.9パーセンタイルから最小値を引いた値は、[Y.1541]の目標と比較できる値になります。
For both raw capacity and restricted capacity, reporting the variability in a useful way is identified as the main challenge. The min, max, and range statistics are suggested along with a ratio of max to min and moving averages. In the end, a simple plot of the singleton results over time may succeed where summary metrics fail or may serve to confirm that the summaries are valid.
生の容量と制限された容量の両方で、有用な方法で変動を報告することが主な課題として特定されています。最小、最大、および範囲の統計が、最大と最小の比率、移動平均とともに提示されます。最後に、時間の経過に伴うシングルトンの結果の単純なプロットは、要約メトリックが失敗した場合に成功するか、要約が有効であることを確認するのに役立ちます。
[IPPM-RPT] describes methods to conduct measurements and report the results on a near-immediate time scale (10 seconds, which we consider to be "short-term").
[IPPM-RPT]は、測定を行い、その結果をほぼ即時のタイムスケール（10秒、これは「短期」と見なす）で報告する方法を説明しています。
Measurement intervals and reporting intervals need not be the same length. Sometimes, the user is only concerned with the performance levels achieved over a relatively long interval of time (e.g., days, weeks, or months, as opposed to 10 seconds). However, there can be risks involved with running a measurement continuously over a long period without recording intermediate results: o Temporary power failure may cause loss of all results to date.
測定間隔とレポート間隔は同じ長さである必要はありません。場合によっては、ユーザーは比較的長い時間間隔（たとえば、10秒ではなく、数日、数週間、または数か月）で達成されるパフォーマンスレベルのみに関心がある場合があります。ただし、中間結果を記録せずに長期間にわたって連続して測定を実行すると、次のようなリスクが発生する可能性があります。o一時的な停電により、現在までの結果がすべて失われる場合があります。
o Measurement system timing synchronization signals may experience a temporary outage, causing subsets of measurements to be in error or invalid.
o 測定システムのタイミング同期信号で一時的な停止が発生し、測定のサブセットがエラーまたは無効になる場合があります。
o Maintenance on the measurement system or on its connectivity to the network under test may be necessary.
o 測定システムまたはテスト対象のネットワークへの接続のメンテナンスが必要になる場合があります。
For these and other reasons, such as
これらおよびその他の理由により、
o the constraint to collect measurements on intervals similar to user session length,
o ユーザーセッションの長さと同様の間隔で測定値を収集するための制約
o the dual use of measurements in monitoring activities where results are needed on a period of a few minutes, or
o 数分の間に結果が必要な監視活動における測定の二重使用、または
o the ability to inspect results of a single measurement interval for deeper analysis,
o より深い分析のために単一の測定間隔の結果を検査する機能、
there is value in conducting measurements on intervals that are much shorter than the reporting interval.
レポート間隔よりもはるかに短い間隔で測定を行うことには価値があります。
There are several approaches for aggregating a series of measurement results over time in order to make a statement about the longer reporting interval. One approach requires the storage of all metric singletons collected throughout the reporting interval, even though the measurement interval stops and starts many times.
長いレポート間隔について説明するために、一連の測定結果を時間をかけて集計するには、いくつかの方法があります。 1つのアプローチでは、測定間隔が何度も停止および開始される場合でも、レポート間隔全体で収集されたすべてのメトリックシングルトンを格納する必要があります。
Another approach is described in [RFC5835] as "temporal aggregation". This approach would estimate the results for the reporting interval based on combining many individual short-term measurement interval statistics to yield a long-term result. The result would ideally appear in the same form as though a continuous measurement had been conducted. A memo addressing the details of temporal aggregation is yet to be prepared.
[RFC5835]では、別のアプローチが「時間的集約」として説明されています。このアプローチでは、多数の個々の短期測定間隔統計を組み合わせて長期結果を得ることに基づいて、レポート間隔の結果を推定します。結果は、理想的には、連続測定が行われた場合と同じ形式で表示されます。時間的集計の詳細を説明するメモはまだ準備されていません。
Yet another approach requires a numerical objective for the metric, and the results of each measurement interval are compared with the objective. Every measurement interval where the results meet the objective contribute to the fraction of time with performance as specified. When the reporting interval contains many measurement intervals, it is possible to present the results as "metric A was less than or equal to objective X during Y% of time".
さらに別のアプローチでは、メトリックの数値目標が必要であり、各測定間隔の結果が目標と比較されます。結果が目的を達成するすべての測定間隔は、指定されたパフォーマンスで時間の一部に貢献します。レポート間隔に多くの測定間隔が含まれている場合、「メトリックAがY％の時間に目標X以下であった」として結果を提示することが可能です。
NOTE that numerical thresholds of acceptability are not set in IETF performance work and are therefore excluded from the scope of this memo.
許容性の数値的なしきい値はIETFパフォーマンス作業で設定されていないため、このメモの範囲から除外されていることに注意してください。
In all measurements, it is important to avoid unintended synchronization with network events. This topic is treated in [RFC2330] for Poisson-distributed inter-packet time streams and in [RFC3432] for Periodic streams. Both avoid synchronization by using random start times.
すべての測定において、ネットワークイベントとの意図しない同期を回避することが重要です。このトピックは、ポアソン分散型パケット間時間ストリームの場合は[RFC2330]で、周期的ストリームの場合は[RFC3432]で扱われます。どちらもランダムな開始時間を使用して同期を回避します。
There are network conditions where it is simply more useful to report the connectivity status of the Source-Destination path, and to distinguish time intervals where connectivity can be demonstrated from other time intervals (where connectivity does not appear to exist). [RFC2678] specifies a number of one-way and two-way connectivity metrics of increasing complexity. In this memo, we recommend that long-term reporting of loss, delay, and other metrics be limited to time intervals where connectivity can be demonstrated, and that other intervals be summarized as the percent of time where connectivity does not appear to exist. We note that this same approach has been adopted in ITU-T Recommendation [Y.1540] where performance parameters are only valid during periods of service "availability" (evaluated according to a function based on packet loss, and sustained periods of loss ratio greater than a threshold are declared "unavailable").
送信元と宛先のパスの接続ステータスを報告し、接続を他の時間間隔から確認できる時間間隔（接続が存在しないように見える）を区別するほうが便利なネットワーク条件があります。 [RFC2678]は、複雑さが増している一方向および双方向の接続メトリックの数を指定しています。このメモでは、損失、遅延、およびその他のメトリックの長期レポートを、接続を実証できる時間間隔に制限し、その他の間隔を接続が存在しないように見える時間の割合として要約することをお勧めします。この同じアプローチがITU-T勧告[Y.1540]で採用されていることに注意してください。パフォーマンスパラメータは、サービスの「可用性」の期間中にのみ有効です（パケット損失に基づく関数に従って評価され、損失率の持続期間はより長くなります）しきい値よりも「利用不可」と宣言されています）。
This section describes the ways in which the loss metric can be tuned to reflect the preferences of the two audience categories, or different POVs. The waiting time before declaring that a packet is lost -- the loss threshold -- is one area where there would appear to be a difference, but the ability to post-process the results may resolve it.
このセクションでは、2つのオーディエンスカテゴリまたは異なるPOVの設定を反映するように損失メトリックを調整する方法について説明します。パケットが失われたことを宣言するまでの待機時間（損失しきい値）は、差異があるように見える領域の1つですが、結果を後処理する機能で解決できる場合があります。
RFC 2680 [RFC2680] defines the concept of a waiting time for packets to arrive, beyond which they are declared lost. The text of the RFC declines to recommend a value, instead saying that "good engineering, including an understanding of packet lifetimes, will be needed in practice". Later, in the methodology, they give reasons for waiting "a reasonable period of time" and leave the definition of "reasonable" intentionally vague. Below, we estimate a practical bound on waiting time.
RFC 2680 [RFC2680]は、パケットが到着するまでの待機時間の概念を定義しており、それを超えるとパケットが失われたと宣言されます。 RFCのテキストは値を推奨することを拒否し、代わりに「実際にはパケットの有効期間の理解を含む優れたエンジニアリングが必要になる」と述べています。その後、方法論では、「妥当な期間」待機する理由を示し、「合理的」の定義を意図的に曖昧にします。以下に、待ち時間の実際的な限界を推定します。
Practical measurement experience has shown that unusual network circumstances can cause long delays. One such circumstance is when routing loops form during IGP re-convergence following a failure or drastic link cost change. Packets will loop between two routers until new routes are installed or until the IPv4 Time-to-Live (TTL) field (or the IPv6 Hop Limit) decrements to zero. Very long delays on the order of several seconds have been measured [Casner] [Cia03].
実際の測定経験では、異常なネットワーク状況が長時間の遅延を引き起こす可能性があることが示されています。このような状況の1つは、IGPの再コンバージェンス中に、障害またはリンクコストの大幅な変更に続いてルーティングループが形成される場合です。パケットは、新しいルートがインストールされるまで、またはIPv4の存続可能時間（TTL）フィールド（またはIPv6のホップ制限）がゼロになるまで、2つのルーター間でループします。数秒程度の非常に長い遅延が測定されています[Casner] [Cia03]。
Therefore, network characterization activities prefer a long waiting time in order to distinguish these events from other causes of loss (such as packet discard at a full queue, or tail drop). This way, the metric design helps to distinguish more reliably between packets that might yet arrive and those that are no longer traversing the network.
したがって、ネットワーク特性化アクティビティは、これらのイベントを他の損失原因（フルキューでのパケット破棄、テールドロップなど）と区別するために、長い待機時間を優先します。このように、メトリック設計は、まだ到着していない可能性があるパケットと、ネットワークを通過しなくなったパケットをより確実に区別するのに役立ちます。
It is possible to calculate a worst-case waiting time, assuming that a routing loop is the cause. We model the path between Source and Destination as a series of delays in links (t) and queues (q), as these are the dominant contributors to delay (in active measurement, the Source and Destination hosts contribute minimal delay). The normal path delay, D, across n queues (where TTL is decremented at a node with a queue) and n+1 links without encountering a loop, is
ルーティングループが原因であると想定すると、最悪の場合の待機時間を計算できます。リンク（t）とキュー（q）の一連の遅延として送信元と宛先の間のパスをモデル化します。これらは遅延の主要な原因であるためです（アクティブな測定では、送信元ホストと宛先ホストは遅延を最小限に抑えます）。 n個のキュー（キューのあるノードでTTLが減少する）とループに遭遇しないn + 1リンクにわたる通常のパス遅延Dは、次のとおりです。
Path model with n=5
Source --- q1 --- q2 --- q3 --- q4 --- q5 --- Destination
t0 t1 t2 t3 t4 t5
n
---
\
D = t + > (t + q)
0 / i i
---
i = 1
Figure 1: Normal Path Delay
図1：通常のパス遅延
and the time spent in the loop with L queues is
Lキューのループで費やされた時間は
Path model with n=5 and L=3
Time in one loop = (qx+tx + qy+ty + qz+tz)
qy -- qz
| ?/exit?
qx--/\
Src --- q1 --- q2 ---/ q3 --- q4 --- q5 --- Dst
t0 t1 t2 t3 t4 t5
j + L-1
---
\ (TTL - n)
R = C > (t + q) where C = ---------
/ i i max L
---
i=j
Figure 2: Delay Due to Rotations in a Loop
図2：ループの回転による遅延
where n is the total number of queues in the non-loop path (with n+1 links), j is the queue number where the loop begins, C is the number of times a packet circles the loop, and TTL is the packet's initial Time-to-Live value at the Source (or Hop Count in IPv6).
ここで、nは（n + 1リンクの）非ループパス内のキューの総数、jはループが始まるキュー番号、Cはパケットがループを周回する回数、TTLはパケットの初期値ですソース（またはIPv6のホップカウント）での存続可能時間の値。
If we take the delays of all links and queues as 100 ms each, the TTL=255, the number of queues n=5, and the queues in the loop L=4, then using C_max:
すべてのリンクとキューの遅延をそれぞれ100ミリ秒、TTL = 255、キューの数n = 5、ループ内のキューL = 4とすると、C_maxが使用されます。
D = 1.1 seconds and R ~= 50 seconds, and D + R ~= 51.1 seconds
We note that the link delays of 100 ms would span most continents, and a constant queue length of 100 ms is also very generous. When a loop occurs, it is almost certain to be resolved in 10 seconds or less. The value calculated above is an upper limit for almost any real-world circumstance.
100ミリ秒のリンク遅延はほとんどの大陸にまたがることに注意してください。100ミリ秒の一定のキューの長さも非常に寛大です。ループが発生した場合、10秒以内に解決されることはほぼ確実です。上記で計算された値は、ほとんどすべての実際の状況の上限です。
A waiting time threshold parameter, dT, set consistent with this calculation, would not truncate the delay distribution (possibly causing a change in its mathematical properties), because the packets that might arrive have been given sufficient time to traverse the network.
到着する可能性のあるパケットにはネットワークを通過するのに十分な時間が与えられているため、この計算と一致して設定された待機時間しきい値パラメーターdTは、遅延分布を切り捨てません（その数学的特性の変化を引き起こす可能性があります）。
It is worth noting that packets that are stored and deliberately forwarded at a much later time constitute a replay attack on the measurement system and are beyond the scope of normal performance reporting.
保存して後で意図的に転送するパケットは、測定システムに対するリプレイアタックを構成し、通常のパフォーマンスレポートの範囲を超えていることに注意してください。
Fortunately, application performance estimation activities are not adversely affected by the long estimated limit on waiting time, because most applications will use shorter time thresholds. Although the designer's tendency might be to set the loss threshold at a value equivalent to a particular application's threshold, this specific threshold can be applied when post-processing the measurements. A shorter waiting time can be enforced by locating packets with delays longer than the application's threshold and re-designating such packets as lost. Thus, the measurement system can use a single loss waiting time and support both application and network performance POVs simultaneously.
幸いにも、ほとんどのアプリケーションはより短い時間しきい値を使用するため、アプリケーションのパフォーマンス推定アクティビティは、待機時間の長い推定制限によって悪影響を受けません。設計者の傾向は、損失しきい値を特定のアプリケーションのしきい値と同等の値に設定することですが、この特定のしきい値は、測定を後処理するときに適用できます。アプリケーションのしきい値よりも長い遅延を持つパケットを特定し、そのようなパケットを失われたものとして再指定することで、待機時間を短縮できます。したがって、測定システムは単一の損失待ち時間を使用し、アプリケーションとネットワークの両方のパフォーマンスPOVを同時にサポートできます。
RFC 2680 designates packets that arrive containing errors as lost packets. Many packets that are corrupted by bit errors are discarded within the network and do not reach their intended destination.
RFC 2680は、エラーを含む到着パケットを損失パケットとして指定します。ビットエラーによって破損した多くのパケットはネットワーク内で破棄され、目的の宛先に到達しません。
This is consistent with applications that would check the payload integrity at higher layers and discard the packet. However, some applications prefer to deal with errored payloads on their own, and even a corrupted payload is better than no packet at all.
これは、上位層でペイロードの整合性をチェックしてパケットを破棄するアプリケーションと一致しています。ただし、一部のアプリケーションは、エラーのあるペイロードを単独で処理することを好み、破損したペイロードでさえも、パケットがない場合よりも優れています。
To address this possibility, and to make network characterization more complete, distinguishing between packets that do not arrive (lost) and errored packets that arrive (conditionally lost) is recommended.
この可能性に対処し、ネットワーク特性をより完全にするために、到着しない（失われた）パケットと到着した（条件付きで失われた）エラーのあるパケットを区別することをお勧めします。
Although many measurement systems use a waiting time to determine whether or not a packet is lost, most of the waiting is in vain. The packets are no longer traversing the network and have not reached their destination.
多くの測定システムは待機時間を使用してパケットが失われたかどうかを判断しますが、待機のほとんどは無駄です。パケットはネットワークを通過しなくなり、宛先に到達していません。
There are many causes of packet loss, including the following:
パケット損失には、次のような多くの原因があります。
1. Queue drop, or discard
1. キューのドロップ、または破棄
2. Corruption of the IP header, or other essential header information
2. IPヘッダーの破損、またはその他の重要なヘッダー情報
3. TTL expiration (or use of a TTL value that is too small) 4. Link or router failure
3. TTLの有効期限（または小さすぎるTTL値の使用）4.リンクまたはルーターの障害
5. Layers below the Source-to-Destination IP layer can discard packets that fail error checking, and link-layer checksums often cover the entire packet
5. ソースから宛先へのIPレイヤーの下にあるレイヤーは、エラーチェックに失敗したパケットを破棄でき、リンクレイヤーチェックサムは多くの場合、パケット全体をカバーします。
It is reasonable to consider a packet that has not arrived after a large amount of time to be lost (due to one of the causes above) because packets do not "live forever" in the network or have infinite delay.
パケットはネットワーク内で「永久に存続」することも、無限の遅延もないため、（上記の原因の1つが原因で）かなりの時間後に失われたパケットが失われると考えるのは妥当です。
Given that measurement post-processing is possible (even encouraged in the definitions of IPPM), measurements of loss can easily serve both POVs:
測定後処理が可能であることを考えると（IPPMの定義でも推奨されます）、損失の測定は両方のPOVに簡単に対応できます。
o Use a long waiting time to serve network characterization and revise results for specific application delay thresholds as needed.
o 長い待機時間を使用してネットワーク特性を提供し、必要に応じて特定のアプリケーション遅延しきい値の結果を修正します。
o Distinguish between errored packets and lost packets when possible to aid network characterization, and combine the results for application performance if appropriate.
o 可能であれば、エラーのあるパケットと失われたパケットを区別して、ネットワークの特性を評価し、必要に応じて結果を組み合わせてアプリケーションのパフォーマンスを向上させます。
This section describes the ways in which the delay metric can be tuned to reflect the preferences of the two consumer categories, or different POVs.
このセクションでは、2つの消費者カテゴリまたは異なるPOVの設定を反映するように遅延メトリックを調整する方法について説明します。
The delay metric [RFC2679] specifies the treatment of packets that do not successfully traverse the network: their delay is undefined.
遅延メトリック[RFC2679]は、ネットワークを正常に通過しないパケットの処理を指定します。それらの遅延は定義されていません。
>>The *Type-P-One-way-Delay* from Src to Dst at T is undefined (informally, infinite)<< means that Src sent the first bit of a Type-P packet to Dst at wire-time T and that Dst did not receive that packet.
>> TでのSrcからDstへの* Type-P-One-way-Delay *は未定義（非公式には無限）<<は、SrcがType-Pパケットの最初のビットをワイヤタイムTでDstに送信し、そのDstはそのパケットを受信しませんでした。
It is an accepted but informal practice to assign infinite delay to lost packets. We next look at how these two different treatments align with the needs of measurement consumers who wish to characterize networks or estimate application performance. Also, we look at the way that lost packets have been treated in other metrics: delay variation and reordering.
失われたパケットに無限の遅延を割り当てることは受け入れられていますが、非公式な慣行です。次に、これら2つの異なる処理が、ネットワークの特性を評価したり、アプリケーションのパフォーマンスを推定したりする測定消費者のニーズにどのように対応するかを検討します。また、失われたパケットが他のメトリックで処理されている方法を確認します。それは、遅延変動と並べ替えです。
Applications need to perform different functions, dependent on whether or not each packet arrives within some finite tolerance. In other words, a receiver's packet processing takes only one of two alternative directions (a "fork" in the road):
アプリケーションは、各パケットが有限の許容範囲内に到着するかどうかに応じて、さまざまな機能を実行する必要があります。言い換えれば、受信側のパケット処理は、2つの代替方向（道路の「分岐」）のうちの1つだけを取ります。
o Packets that arrive within expected tolerance are handled by removing headers, restoring smooth delivery timing (as in a de-jitter buffer), restoring sending order, checking for errors in payloads, and many other operations.
o 予想される許容範囲内で到着したパケットは、ヘッダーの削除、スムーズな配信タイミングの復元（デジッタバッファーの場合など）、送信順序の復元、ペイロードのエラーのチェック、およびその他の多くの操作によって処理されます。
o Packets that do not arrive when expected lead to attempted recovery from the apparent loss, such as retransmission requests, loss concealment, or forward error correction to replace the missing packet.
o 予期したときに到着しないパケットは、再送要求、損失の隠蔽、欠落したパケットを置き換える転送エラー訂正などの明らかな損失からの回復の試みにつながります。
So, it is important to maintain a distinction between packets that actually arrive and those that do not. Therefore, it is preferable to leave the delay of lost packets undefined and to characterize the delay distribution as a conditional distribution (conditioned on arrival).
したがって、実際に到着するパケットと到着しないパケットを区別しておくことが重要です。したがって、失われたパケットの遅延を未定義のままにし、遅延分布を条件付き分布（到着時に条件付き）として特徴付けることが望ましいです。
In this discussion, we assume that both loss and delay metrics will be reported for network characterization (at least).
この説明では、ネットワークの特性評価のために、損失と遅延の両方のメトリックが報告されることを想定しています。
Assume that packets that do not arrive are reported as lost, usually as a fraction of all sent packets. If these lost packets are assigned an undefined delay, then the network's inability to deliver them (in a timely way) is relegated only in the loss metric when we report statistics on the delay distribution conditioned on the event of packet arrival (within the loss waiting time threshold). We can say that the delay and loss metrics are orthogonal in that they convey non-overlapping information about the network under test. This is a valuable property whose absence is discussed below.
到着しないパケットは、通常は送信されたすべてのパケットの一部として失われたと報告されると仮定します。これらの失われたパケットに未定義の遅延が割り当てられている場合、ネットワークがパケットを（タイムリーに）配信できないことは、パケット到着のイベントを条件とする遅延の分布に関する統計を報告するときに（損失待ちの範囲内で）損失メトリックのみに追いやられます。時間のしきい値）。遅延と損失のメトリックは、テスト対象のネットワークに関する重複しない情報を伝えるという点で直交していると言えます。これは貴重な資産であり、その不在は以下で説明されます。
However, if we assign infinite delay to all lost packets, then
ただし、失われたすべてのパケットに無限遅延を割り当てると、
o The delay metric results are influenced both by packets that arrive and those that do not.
o 遅延メトリックの結果は、到着するパケットと到着しないパケットの両方に影響されます。
o The delay singleton and the loss singleton do not appear to be orthogonal (delay is finite when loss=0; delay is infinite when loss=1).
o 遅延シングルトンと損失シングルトンは直交していないように見えます（損失= 0の場合、遅延は有限です。損失= 1の場合、遅延は無限です）。
o The network is penalized in both the loss and delay metrics, effectively double-counting the lost packets.
o ネットワークは、損失メトリックと遅延メトリックの両方でペナルティが課され、失われたパケットを効果的に二重にカウントします。
As further evidence of overlap, consider the Cumulative Distribution Function (CDF) of delay when the value "positive infinity" is assigned to all lost packets. Figure 3 shows a CDF where a small fraction of packets are lost.
重複のさらなる証拠として、値「正の無限大」がすべての失われたパケットに割り当てられている場合の遅延の累積分布関数（CDF）を検討してください。図3は、一部のパケットが失われたCDFを示しています。
1 | - - - - - - - - - - - - - - - - - -+
| |
| _..----''''''''''''''''''''
| ,-''
| ,'
| / Mass at
| / +infinity
| / = fraction
|| lost
|/
0 |_____________________________________
0 Delay +o0
0遅延+ o0
Figure 3: Cumulative Distribution Function for Delay When Loss = +Infinity
図3：損失= +無限大の場合の遅延の累積分布関数
We note that a delay CDF that is conditioned on packet arrival would not exhibit this apparent overlap with loss.
パケットの到着を条件とする遅延CDFは、この明らかな損失との重複を示さないことに注意してください。
Although infinity is a familiar mathematical concept, it is somewhat disconcerting to see any time-related metric reported as infinity. Questions are bound to arise and tend to detract from the goal of informing the consumer with a performance report.
無限大はおなじみの数学的概念ですが、時間に関連するメトリックが無限大として報告されるのを見るのはやや当惑しています。質問は必ず発生し、パフォーマンスレポートを消費者に知らせるという目標を損なう傾向があります。
[RFC3393] excludes lost packets from samples, effectively assigning an undefined delay to packets that do not arrive in a reasonable time. Section 4.1 of [RFC3393] describes this specification and its rationale (ipdv = inter-packet delay variation in the quote below).
[RFC3393]は失われたパケットをサンプルから除外し、妥当な時間内に到着しないパケットに未定義の遅延を効果的に割り当てます。 [RFC3393]のセクション4.1は、この仕様とその理論的根拠を説明しています（ipdv =パケット間の遅延変動、以下の引用）。
The treatment of lost packets as having "infinite" or "undefined" delay complicates the derivation of statistics for ipdv. Specifically, when packets in the measurement sequence are lost, simple statistics such as sample mean cannot be computed. One possible approach to handling this problem is to reduce the event space by conditioning. That is, we consider conditional statistics; namely we estimate the mean ipdv (or other derivative statistic) conditioned on the event that selected packet pairs arrive at the Destination (within the given timeout). While this itself is not without problems (what happens, for example, when every other packet is lost), it offers a way to make some (valid) statements about ipdv, at the same time avoiding events with undefined outcomes.
失われたパケットを「無限」または「未定義」の遅延を持つものとして処理すると、ipdvの統計情報の導出が複雑になります。具体的には、測定シーケンスのパケットが失われると、サンプル平均などの単純な統計を計算できません。この問題を処理する1つの可能なアプローチは、条件付けによってイベントスペースを減らすことです。つまり、条件付き統計を考慮します。つまり、選択されたパケットのペアが宛先に到着する（指定されたタイムアウト内に）ことを条件として、平均ipdv（または他の微分統計）を推定します。これ自体には問題がないわけではありませんが（たとえば、他のすべてのパケットが失われたときに何が起こるか）、ipdvに関する（有効な）ステートメントを作成すると同時に、未定義の結果を伴うイベントを回避する方法を提供します。
We note that the argument above applies to all forms of packet delay variation that can be constructed using the "selection function" concept of [RFC3393]. In recent work, the two main forms of delay variation metrics have been compared, and the results are summarized in [RFC5481].
上記の議論は、[RFC3393]の「選択機能」の概念を使用して構築できるすべての形式のパケット遅延変動に適用されることに注意してください。最近の研究では、2つの主要な形式の遅延変動メトリックが比較され、その結果が[RFC5481]にまとめられています。
[RFC4737] defines metrics that are based on evaluation of packet arrival order and that include a waiting time before declaring that a packet is lost (to exclude the packet from further processing).
[RFC4737]は、パケットの到着順序の評価に基づいており、パケットが失われたことを宣言する前の待機時間を含むメトリックを定義します（パケットを以降の処理から除外するため）。
If packets are assigned a delay value, then the reordering metric would declare any packets with infinite delay to be reordered, because their sequence numbers will surely be less than the "Next Expected" threshold when (or if) they arrive. But this practice would fail to maintain orthogonality between the reordering metric and the loss metric. Confusion can be avoided by designating the delay of non-arriving packets as undefined and reserving delay values only for packets that arrive within a sufficiently long waiting time.
パケットに遅延値が割り当てられている場合、再配列メトリックは、無限遅延のあるパケットが再配列されることを宣言します。これは、パケットが到着したとき（または到着したとき）にシーケンス番号が「次の予想」しきい値よりも確実に小さくなるためです。ただし、この方法では、並べ替えメトリックと損失メトリックの間の直交性を維持できません。非到着パケットの遅延を未定義として指定し、十分に長い待機時間内に到着するパケットに対してのみ遅延値を予約することにより、混乱を回避できます。
Today in network characterization, the sample mean is one statistic that is almost ubiquitously reported. It is easily computed and understood by virtually everyone in this audience category. Also, the sample is usually filtered on packet arrival, so that the mean is based on a conditional distribution.
今日のネットワーク特性評価では、サンプル平均はほぼどこにでも報告されている1つの統計です。このオーディエンスカテゴリのほぼ全員が簡単に計算して理解できます。また、サンプルは通常、パケットの到着時にフィルタリングされるため、平均は条件付き分布に基づいています。
The median is another statistic that summarizes a distribution, having somewhat different properties from the sample mean. The median is stable in distributions with a few outliers or without them. However, the median's stability prevents it from indicating when a large fraction of the distribution changes value. 50% or more values would need to change for the median to capture the change.
中央値は、分布を要約する別の統計であり、サンプルの平均とはやや異なる特性を持っています。中央値は、いくつかの外れ値がある、またはない外れ値の分布で安定しています。ただし、中央値の安定性により、分布の大部分が値を変更する時期を示すことができません。中央値が変化を捉えるためには、50％以上の値を変化させる必要があります。
Both the median and sample mean have difficulty with bimodal distributions. The median will reside in only one of the modes, and the mean may not lie in either mode range. For this and other reasons, additional statistics such as the minimum, maximum, and 95th percentile have value when summarizing a distribution.
中央値とサンプル平均の両方で、二峰性分布が困難です。中央値はモードの1つにのみ存在し、平均はどちらのモード範囲にもない場合があります。この理由やその他の理由により、分布を要約するときに、最小、最大、95パーセンタイルなどの追加の統計に価値があります。
When both the sample mean and median are available, a comparison will sometimes be informative, because these two statistics are equal only under unusual circumstances, such as when the delay distribution is perfectly symmetrical.
サンプルの平均と中央値の両方が利用可能な場合、これらの2つの統計は、遅延分布が完全に対称であるような異常な状況下でのみ等しいため、比較が役立つ場合があります。
Also, these statistics are generally useful from the application performance POV, so there is a common set that should satisfy audiences.
また、これらの統計は一般にアプリケーションのパフォーマンスPOVから有用であるため、対象者を満足させる必要のある共通のセットがあります。
Plots of the delay distribution may also be useful when single-value statistics indicate that new conditions are present. An empirically derived probability distribution function will usually describe multiple modes more efficiently than any other form of result.
遅延分布のプロットは、単一値統計が新しい条件が存在することを示している場合にも役立ちます。経験的に得られた確率分布関数は通常、他の形式の結果よりも効率的に複数のモードを記述します。
From the perspectives of
の観点から
1. application/receiver analysis, where subsequent processing depends on whether the packet arrives or times out,
1. アプリケーション/レシーバー分析。後続の処理は、パケットが到着するか、タイムアウトするかによって異なります。
2. straightforward network characterization without double-counting defects, and
2. ダブルカウントの欠陥のない簡単なネットワーク特性評価、および
3. consistency with delay variation and reordering metric definitions,
3. 遅延変動との整合性とメトリック定義の並べ替え、
the most efficient practice is to distinguish between packets that are truly lost and those that are delayed packets with a sufficiently long waiting time, and to designate the delay of non-arriving packets as undefined.
最も効率的な方法は、本当に失われたパケットと、遅延時間が十分に長いパケットであるパケットを区別し、到着していないパケットの遅延を未定義として指定することです。
Raw capacity refers to the metrics defined in [RFC5136], which do not include restrictions such as data uniqueness or flow-control response to congestion.
Rawキャパシティとは、[RFC5136]で定義されているメトリックを指し、データの一意性や輻輳に対するフロー制御応答などの制限は含まれていません。
The metrics considered are IP-layer capacity, utilization (or used capacity), and available capacity, for individual links and complete paths. These three metrics form a triad: knowing one metric constrains the other two (within their allowed range), and knowing two determines the third. The link metrics have another key aspect in common: they are single-measurement-point metrics at the egress of a link. The path capacity and available capacity are derived by examining the set of single-point link measurements and taking the minimum value.
考慮されるメトリックは、個々のリンクと完全なパスのIPレイヤー容量、使用率（または使用済み容量）、および使用可能な容量です。これらの3つのメトリックは3つの要素を形成します。1つのメトリックが他の2つを（それらの許容範囲内で）制約していることを知ること、および2つを知っていることが3番目を決定します。リンクメトリックには、共通の別の重要な側面があります。リンクメトリックは、リンクの出口での単一測定ポイントメトリックです。パスキャパシティと使用可能なキャパシティは、一連のシングルポイントリンク測定値を調べ、最小値をとることによって導き出されます。
The concept of "packets of Type-P" is defined in [RFC2330]. The Type-P categorization has critical relevance in all forms of capacity measurement and reporting. The ability to categorize packets based on header fields for assignment to different queues and scheduling mechanisms is now commonplace. When unused resources are shared across queues, the conditions in all packet categories will affect capacity and related measurements. This is one source of variability in the results that all audiences would prefer to see reported in a useful and easily understood way.
「Type-Pのパケット」の概念は、[RFC2330]で定義されています。 Type-Pの分類は、すべての形式の容量測定およびレポートで重要な関連性があります。ヘッダーフィールドに基づいてパケットを分類し、さまざまなキューおよびスケジューリングメカニズムに割り当てる機能が一般的になりました。未使用のリソースがキュー間で共有されると、すべてのパケットカテゴリの条件が容量と関連する測定に影響します。これは、結果が変動する原因の1つであり、すべての聴衆が、有用でわかりやすい方法でレポートを表示することを望んでいます。
Communication of Type-P within the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) is essentially confined to the Diffserv Code Point (DSCP) [RFC4656]. DSCP is the most common qualifier for Type-P.
一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）内でのType-Pの通信は、基本的にDiffservコードポイント（DSCP）[RFC4656]に限定されます。 DSCPはType-Pの最も一般的な修飾子です。
Each audience will have a set of Type-P qualifications and value combinations that are of interest. Measurements and reports should have the flexibility to report per-type and aggregate performance.
各オーディエンスには、興味深いType-P資格と値の組み合わせのセットがあります。測定とレポートには、タイプごとにレポートし、パフォーマンスを集計する柔軟性が必要です。
The audience for network characterization may have detailed information about each link that comprises a complete path (due to ownership, for example), or some of the links in the path but not others, or none of the links.
ネットワークの特性評価の対象者は、完全なパス（所有権などによる）を構成する各リンクに関する詳細情報、またはパス内の一部のリンクのみを含む、またはリンクをまったく含まない場合があります。
There are cases where the measurement audience only has information on one of the links (the local access link) and wishes to measure one or more of the raw capacity metrics. This scenario is quite common and has spawned a substantial number of experimental measurement methods (e.g., http://www.caida.org/tools/taxonomy/). Many of these methods respect that their users want a result fairly quickly and in one trial. Thus, the measurement interval is kept short (a few seconds to a minute). For long-term reporting, a sample of short-term results needs to be summarized.
測定対象者が1つのリンク（ローカルアクセスリンク）に関する情報しか持っておらず、1つ以上の未処理容量メトリックを測定したい場合があります。このシナリオは非常に一般的であり、かなりの数の実験的な測定方法が生み出されています（例：http://www.caida.org/tools/taxonomy/）。これらの方法の多くは、ユーザーが非常に迅速に1つの試行で結果を望んでいることを尊重しています。したがって、測定間隔は短く保たれます（数秒から1分）。長期的なレポートを作成するには、短期的な結果のサンプルを要約する必要があります。
For links, this metric's theoretical maximum value can be determined from the physical-layer bit rate and the bit rate reduction due to the layers between the physical layer and IP. When measured, this metric takes additional factors into account, such as the ability of the sending device to process and forward traffic under various conditions. For example, the arrival of routing updates may spawn high-priority processes that reduce the sending rate temporarily.
リンクの場合、このメトリックの理論上の最大値は、物理層のビットレートと、物理層とIPの間の層によるビットレートの削減から決定できます。このメトリックは、測定時に、さまざまな条件下でトラフィックを処理して転送する送信デバイスの能力など、追加の要素を考慮に入れます。たとえば、ルーティングアップデートが到着すると、優先度の高いプロセスが生成され、送信レートが一時的に低下することがあります。
Thus, the measured capacity of a link will be variable, and the maximum capacity observed applies to a specific time, time interval, and other relevant circumstances.
したがって、測定されたリンクの容量は変動し、観測された最大容量は特定の時間、時間間隔、およびその他の関連する状況に適用されます。
For paths composed of a series of links, it is easy to see how the sources of variability for the results grow with each link in the path. Variability of results will be discussed in more detail below.
一連のリンクで構成されるパスの場合、結果の変動の原因がパス内のリンクごとにどのように増加するかを簡単に確認できます。結果の変動性については、以下で詳しく説明します。
The ideal metric definition of link utilization [RFC5136] is based on the actual usage (bits successfully received during a time interval) and the maximum capacity for the same interval.
リンク使用率の理想的なメトリック定義[RFC5136]は、実際の使用量（時間間隔中に正常に受信されたビット）と同じ間隔の最大容量に基づいています。
In practice, link utilization can be calculated by counting the IP-layer (or other layer) octets received over a time interval and dividing by the theoretical maximum number of octets that could have been delivered in the same interval. A commonly used time interval is 5 minutes, and this interval has been sufficient to support network operations and design for some time. 5 minutes is somewhat long compared with the expected download time for web pages but short with respect to large file transfers and TV program viewing. It is fair to say that considerable variability is concealed by reporting a single (average) utilization value for each 5-minute interval. Some performance management systems have begun to make 1-minute averages available.
実際には、リンク使用率は、時間間隔で受信されたIPレイヤー（または他のレイヤー）オクテットをカウントし、同じ間隔で配信される可能性のある理論上の最大オクテット数で割ることによって計算できます。一般的に使用される時間間隔は5分です。この間隔は、しばらくの間、ネットワークの運用と設計をサポートするのに十分でした。 5分は、Webページの予想されるダウンロード時間と比べてやや長くなりますが、大きなファイル転送やテレビ番組の視聴に関しては短くなります。 5分間隔ごとに1つの（平均）使用率値を報告することで、かなりの変動が隠されていると言っても過言ではありません。一部のパフォーマンス管理システムでは、1分間の平均を使用できるようになっています。
There is also a limit on the smallest useful measurement interval. Intervals on the order of the serialization time for a single Maximum Transmission Unit (MTU) packet will observe on/off behavior and report 100% or 0%. The smallest interval needs to be some multiple of MTU serialization time for averaging to be effective.
また、有用な最小測定間隔にも制限があります。単一の最大転送ユニット（MTU）パケットのシリアル化時間のオーダーの間隔では、オン/オフの動作が観察され、100％または0％が報告されます。平均化を有効にするには、最小間隔がMTUシリアル化時間の倍数である必要があります。
The available capacity of a link can be calculated using the capacity and utilization metrics.
リンクの使用可能な容量は、容量と使用率のメトリックを使用して計算できます。
When available capacity of a link or path is estimated through some measurement technique, the following parameters should be reported:
リンクまたはパスの使用可能な容量が何らかの測定手法によって推定される場合、次のパラメーターが報告されます。
o Name and reference to the exact method of measurement
o 正確な測定方法の名前と参照
o IP packet length, octets (including IP header)
o IPパケット長、オクテット（IPヘッダーを含む）
o Maximum capacity that can be assessed in the measurement configuration
o 測定構成で評価できる最大容量
o Time duration of the measurement
o 測定の継続時間
o All other parameters specific to the measurement method
o 測定方法に固有のその他すべてのパラメーター
Many methods of available capacity measurement have a maximum capacity that they can measure, and this maximum may be less than the actual available capacity of the link or path. Therefore, it is important to know the capacity value beyond which there will be no measured improvement.
利用可能な容量測定の多くの方法には、測定可能な最大容量があり、この最大値は、リンクまたはパスの実際の利用可能な容量よりも少ない場合があります。したがって、それを超えると測定値の改善が見られなくなる容量値を知ることが重要です。
The application performance estimation audience may have a desired target capacity value and simply wish to assess whether there is sufficient available capacity. This case simplifies the measurement of link and path capacity to some degree, as long as the measurable maximum exceeds the target capacity.
アプリケーションのパフォーマンスを見積もるオーディエンスは、望ましいターゲットキャパシティ値を持っている可能性があり、十分なキャパシティがあるかどうかを評価したいだけです。このケースでは、測定可能な最大値がターゲット容量を超えている限り、リンクおよびパス容量の測定がある程度簡略化されます。
As with most metrics and measurements, assessing the consistency or variability in the results gives the user an intuitive feel for the degree (or confidence) that any one value is representative of other results, or the spread of the underlying distribution of the singleton measurements.
ほとんどのメトリックや測定と同様に、結果の一貫性または変動性を評価することで、ユーザーは1つの値が他の結果を表す程度（または信頼度）、またはシングルトン測定値の基になる分布の広がりを直感的に感じることができます。
How can utilization be measured and summarized to describe the potential variability in a useful way?
使用率を測定および要約して、潜在的な変動を有用な方法で説明するにはどうすればよいですか？
How can the variability in available capacity estimates be reported, so that the confidence in the results is also conveyed?
結果の信頼性も伝えられるように、使用可能な容量の見積もりの変動性をどのように報告できますか？
We suggest some methods below.
以下にいくつかの方法を提案します。
With a set of singleton utilization or available capacity estimates, each representing a time interval needed to ascertain the estimate, we seek to describe the variation over the set of singletons as though reporting summary statistics of a distribution. Three useful summary statistics are
シングルトンの使用率または使用可能な容量の推定値のセットは、それぞれが推定値を確認するために必要な時間間隔を表し、分布の要約統計量を報告するかのように、シングルトンのセット全体の変動を説明しようとします。 3つの有用な要約統計は
o Minimum,
o 最小、
o Maximum, and
o 最大、および
o Range An alternate way to represent the range is as a ratio of maximum to minimum value. This enables an easily understandable statistic to describe the range observed. For example, when maximum = 3*minimum, then the max/min ratio is 3, and users may see variability of this order. On the other hand, capacity estimates with a max/min ratio near 1 are quite consistent and near the central measure or statistic reported.
o範囲範囲を表す別の方法は、最大値と最小値の比率です。これにより、観察された範囲を説明する統計を簡単に理解できます。たとえば、max = 3 * minimumの場合、max / min比は3であり、ユーザーにはこの順序の変動が見られる場合があります。一方、最大/最小比が1に近い容量の推定値は非常に一貫しており、中央の測定値または統計値に近く報告されています。
For an ongoing series of singleton estimates, a moving average of n estimates may provide a single value estimate to more easily distinguish substantial changes in performance over time. For example, in a window of n singletons observed in time interval t, a percentage change of x% is declared to be a substantial change and reported as an exception.
進行中の一連のシングルトン推定値の場合、n個の推定値の移動平均によって単一の値の推定値が得られ、時間の経過によるパフォーマンスの大幅な変化をより簡単に区別できます。たとえば、時間間隔tで観測されたn個のシングルトンのウィンドウでは、x％の変化率が大幅な変化であると宣言され、例外として報告されます。
Often, the most informative summary of the results is a two-axis plot rather than a table of statistics, where time is plotted on the x-axis and the singleton value on the y-axis. The time-series plot can illustrate sudden changes in an otherwise stable range, identify bi-modality easily, and help quickly assess correlation with other time-series. Plots of frequency of the singleton values are likewise useful tools to visualize the variation.
多くの場合、結果の最も有益な要約は、統計の表ではなく2軸のプロットであり、時間はx軸にプロットされ、シングルトン値はy軸にプロットされます。時系列プロットは、他の安定した範囲での突然の変化を示し、バイモダリティを簡単に識別し、他の時系列との相関をすばやく評価するのに役立ちます。シングルトン値の周波数のプロットは、変動を視覚化するための同様に有用なツールです。
Restricted capacity refers to the metrics defined in [RFC3148], which include criteria of data uniqueness or flow-control response to congestion.
制限付き容量とは、[RFC3148]で定義されているメトリックを指し、データの一意性または輻輳に対するフロー制御応答の基準が含まれます。
One primary metric considered is Bulk Transfer Capacity (BTC) for complete paths. [RFC3148] defines BTC as
考慮される1つの主要なメトリックは、完全なパスの一括転送容量（BTC）です。 [RFC3148]はBTCを次のように定義しています
BTC = data_sent / elapsed_time
for a connection with congestion-aware flow control, where data_sent is the total number of unique payload bits (no headers).
輻輳認識フロー制御を使用した接続の場合、data_sentは一意のペイロードビット（ヘッダーなし）の総数です。
We note that this definition *differs* from the raw capacity definition in Section 2.3.1 of [RFC5136], where IP-layer capacity *includes* all bits in the IP header and payload. This means that restricted capacity BTC is already operating at a disadvantage when compared to the raw capacity at layers below TCP. Further, there are cases where one IP layer is encapsulated in another IP layer or other form of tunneling protocol, designating more and more of the fundamental transport capacity as header bits that are pure overhead to the BTC measurement.
この定義は、[RFC5136]のセクション2.3.1の未加工容量の定義と*異なる*ことに注意してください。IP層の容量には、IPヘッダーとペイロードのすべてのビットが*含まれます*。これは、制限された容量のBTCが、TCPの下のレイヤーでの未加工容量と比較すると、すでに不利に動作していることを意味します。さらに、1つのIP層が別のIP層または他の形式のトンネリングプロトコルにカプセル化され、BTC測定の純粋なオーバーヘッドであるヘッダービットとして、ますます多くの基本的な転送容量を指定する場合があります。
We also note that raw and restricted capacity metrics are not orthogonal in the sense defined in Section 5.1.2 above. The information they convey about the network under test is certainly overlapping, but they reveal two different and important aspects of performance.
また、未加工の容量メトリックと制限された容量メトリックは、上記のセクション5.1.2で定義されている意味で直交していないことにも注意してください。テスト対象のネットワークについて彼らが伝える情報は確かに重複していますが、パフォーマンスの2つの異なる重要な側面を明らかにしています。
When thinking about the triad of raw capacity metrics, BTC is most akin to the "IP-Type-P Available Path Capacity", at least in the eyes of a network user who seeks to know what transmission performance a path might support.
生の容量メトリックの3つの要素について考えると、BTCは「IP-Type-P利用可能なパス容量」に最も似ており、少なくともパスがサポートする可能性のある伝送パフォーマンスを知りたいネットワークユーザーの目には似ています。
The concept of "packets of Type-P" is defined in [RFC2330]. The considerations for restricted capacity are identical to the raw capacity section on this topic, with the addition that the various fields and options in the TCP header must be included in the description.
「Type-Pのパケット」の概念は、[RFC2330]で定義されています。制限された容量に関する考慮事項は、このトピックのraw容量のセクションと同じですが、TCPヘッダーのさまざまなフィールドとオプションを説明に含める必要がある点が異なります。
The vast array of TCP flow-control options are not well captured by Type-P, because they do not exist in the TCP header bits. Therefore, we introduce a new notion here: TCP Configuration of "Type-C". The elements of Type-C describe all of the settings for TCP options and congestion control algorithm variables, including the main form of congestion control in use. Readers should consider the parameters and variables of [RFC3148] and [RFC6349] when constructing Type-C.
大量のTCPフロー制御オプションは、TCPヘッダービットに存在しないため、Type-Pでうまくキャプチャされません。したがって、ここでは新しい概念を紹介します。「Type-C」のTCP構成です。 Type-Cの要素は、使用中の輻輳制御のメインフォームを含む、TCPオプションと輻輳制御アルゴリズム変数のすべての設定を記述します。 Type-Cを構築するとき、読者は[RFC3148]と[RFC6349]のパラメーターと変数を考慮する必要があります。
The audience for network characterization may have detailed information about each link that comprises a complete path (due to ownership, for example), or some of the links in the path but not others, or none of the links.
ネットワークの特性評価の対象者は、完全なパス（所有権などによる）を構成する各リンクに関する詳細情報、またはパス内の一部のリンクのみを含む、またはリンクをまったく含まない場合があります。
There are cases where the measurement audience only has information on one of the links (the local access link) and wishes to measure one or more BTC metrics. The discussion in Section 6.2 applies here as well.
測定対象者が1つのリンク（ローカルアクセスリンク）に関する情報しか持っておらず、1つ以上のBTCメトリックを測定したい場合があります。セクション6.2の議論はここにも適用されます。
There are limits on a useful measurement interval for BTC. Three factors that influence the interval duration are listed below:
BTCの有効な測定間隔には制限があります。インターバル期間に影響を与える3つの要素を以下に示します。
1. Measurements may choose to include or exclude the 3-way handshake of TCP connection establishment, which requires at least 1.5 * RTT (round-trip time) and contains both the delay of the path and the host processing time for responses. However, user experience includes the 3-way handshake for all new TCP connections.
1. 測定では、TCP接続確立の3ウェイハンドシェイクを含めるか除外するかを選択できます。これには、少なくとも1.5 * RTT（往復時間）が必要であり、パスの遅延と応答のホスト処理時間の両方が含まれます。ただし、ユーザーエクスペリエンスには、すべての新しいTCP接続に対する3ウェイハンドシェイクが含まれます。
2. Measurements may choose to include or exclude Slow-Start, preferring instead to focus on a portion of the transfer that represents "equilibrium" (which needs to be defined for particular circumstances if used). However, user experience includes the Slow-Start for all new TCP connections.
2. 測定では、スロースタートを含めるか除外するかを選択できます。代わりに、「平衡」（使用する場合は特定の状況で定義する必要がある）を表す転送の部分に焦点を当てることを優先します。ただし、ユーザーエクスペリエンスには、すべての新しいTCP接続のスロースタートが含まれます。
3. Measurements may choose to use a fixed block of data to transfer, where the size of the block has a relationship to the file size of the application of interest. This approach yields variable size measurement intervals, where a path with faster BTC is measured for less time than a path with slower BTC, and this has implications when path impairments are time-varying, or transient. Users are likely to turn their immediate attention elsewhere when a very large file must be transferred; thus, they do not directly experience such a long transfer -- they see the result (success or failure) and possibly an objective measurement of the transfer time (which will likely include the 3-way handshake, Slow-Start, and application file management processing time as well as the BTC).
3. 測定では、データの固定ブロックを使用して転送することを選択できます。ブロックのサイズは、対象のアプリケーションのファイルサイズと関係があります。このアプローチでは、可変サイズの測定間隔が得られます。BTCが速いパスは、遅いBTCのパスよりも短い時間で測定されます。これは、パスの障害が時変または一時的な場合に影響します。非常に大きなファイルを転送する必要がある場合、ユーザーはすぐに別の場所に注意を向けます。したがって、このような長い転送は直接行われません-結果（成功または失敗）と、おそらく転送時間の客観的な測定（3ウェイハンドシェイク、スロースタート、およびアプリケーションファイル管理が含まれる可能性が高い）が表示されます処理時間およびBTC）。
Individual measurement intervals may be short or long, but there is a need to report the results on a long-term basis that captures the BTC variability experienced between each interval. Consistent BTC is a valuable commodity along with the value attained.
個々の測定間隔は短い場合と長い場合がありますが、各間隔で発生するBTCの変動を捉えた結果を長期的に報告する必要があります。一貫したBTCは、達成された価値とともに価値のある商品です。
When BTC of a link or path is estimated through some measurement technique, the following parameters should be reported:
リンクまたはパスのBTCが何らかの測定手法によって推定される場合、次のパラメーターが報告されます。
o Name and reference to the exact method of measurement
o 正確な測定方法の名前と参照
o Maximum Transmission Unit (MTU)
o 最大転送単位（MTU）
o Maximum BTC that can be assessed in the measurement configuration
o 測定構成で評価できる最大BTC
o Time and duration of the measurement o Number of BTC connections used simultaneously
o測定の時間と期間o同時に使用されるBTC接続の数
o *All* other parameters specific to the measurement method, especially the congestion control algorithm in use
o *すべての*測定方法に固有のその他のパラメーター、特に使用中の輻輳制御アルゴリズム
See also [RFC6349].
[RFC6349]も参照してください。
Many methods of BTC measurement have a maximum capacity that they can measure, and this maximum may be less than the available capacity of the link or path. Therefore, it is important to specify the measured BTC value beyond which there will be no measured improvement.
BTC測定の多くの方法には、測定可能な最大容量があり、この最大値は、リンクまたはパスの使用可能な容量より少ない場合があります。したがって、測定されたBTC値を指定することが重要です。それを超えると、測定された改善はありません。
The application performance estimation audience may have a desired target capacity value and simply wish to assess whether there is sufficient BTC. This case simplifies the measurement of link and path capacity to some degree, as long as the measurable maximum exceeds the target capacity.
アプリケーションのパフォーマンスを見積もるオーディエンスは、必要なターゲットキャパシティ値を持っている可能性があり、十分なBTCがあるかどうかを評価したいだけです。このケースでは、測定可能な最大値がターゲット容量を超えている限り、リンクおよびパス容量の測定がある程度簡略化されます。
As with most metrics and measurements, assessing the consistency or variability in the results gives the user an intuitive feel for the degree (or confidence) that any one value is representative of other results, or the underlying distribution from which these singleton measurements have come.
ほとんどのメトリックと測定と同様に、結果の一貫性または変動性を評価することで、1つの値が他の結果を表す程度（または信頼度）、またはこれらのシングルトン測定の基になる分布について直感的に感じることができます。
With two questions looming --
2つの質問が迫っています-
1. What ways can BTC be measured and summarized to describe the potential variability in a useful way?
1. BTCを測定および要約して、潜在的な変動性を有用な方法で説明するにはどうすればよいですか？
2. How can the variability in BTC estimates be reported, so that the confidence in the results is also conveyed?
2. 結果の信頼性も伝えられるように、BTC見積もりの変動性をどのように報告できますか？
-- we suggest the methods listed in Section 6.6.1 above, and the additional results presentations given in [RFC6349].
-上記のセクション6.6.1にリストされている方法と、[RFC6349]で提供されている追加の結果のプレゼンテーションをお勧めします。
This section discusses two key aspects of measurement that are sometimes omitted from the report: the description of the test stream on which the measurements are based, and the sample size.
このセクションでは、レポートから省略されることがある測定の2つの重要な側面について説明します。測定の基礎となるテストストリームの説明とサンプルサイズです。
Network characterization has traditionally used Poisson-distributed inter-packet spacing, as this provides an unbiased sample. The average inter-packet spacing may be selected to allow observation of specific network phenomena. Other test streams are designed to sample some property of the network, such as the presence of congestion, link bandwidth, or packet reordering.
これは公平なサンプルを提供するため、ネットワークの特性評価では、伝統的にポアソン分布のパケット間間隔が使用されてきました。特定のネットワーク現象を観察できるように、平均パケット間間隔を選択できます。他のテストストリームは、輻輳の存在、リンク帯域幅、パケットの並べ替えなど、ネットワークのいくつかのプロパティをサンプリングするように設計されています。
If measuring a network in order to make inferences about applications or receiver performance, then there are usually efficiencies derived from a test stream that has similar characteristics to the sender. In some cases, it is essential to synthesize the sender stream, as with BTC estimates. In other cases, it may be sufficient to sample with a "known bias", e.g., a Periodic stream to estimate real-time application performance.
アプリケーションまたはレシーバーのパフォーマンスについて推論を行うためにネットワークを測定する場合、通常、送信者と同様の特性を持つテストストリームから得られる効率があります。場合によっては、BTC見積もりと同様に、送信者ストリームを合成することが不可欠です。他の場合では、「既知のバイアス」、たとえば定期的なストリームでサンプリングして、リアルタイムのアプリケーションパフォーマンスを推定するだけで十分な場合があります。
Sample size is directly related to the accuracy of the results and plays a critical role in the report. Even if only the sample size (in terms of number of packets) is given for each value or summary statistic, it imparts a notion of the confidence in the result.
サンプルサイズは結果の正確さに直接関係し、レポートで重要な役割を果たします。各値または要約統計量にサンプルサイズ（パケット数の観点から）のみが指定されている場合でも、結果の信頼性の概念が与えられます。
In practice, the sample size will be selected taking both statistical and practical factors into account. Among these factors are the following:
実際には、サンプルサイズは、統計的要因と実際的な要因の両方を考慮して選択されます。これらの要因には、次のものがあります。
1. The estimated variability of the quantity being measured.
1. 測定される数量の推定変動性。
2. The desired confidence in the result (although this may be dependent on assumption of the underlying distribution of the measured quantity).
2. 結果の望ましい信頼度（これは、測定された量の基礎となる分布の仮定に依存する場合があります）。
3. The effects of active measurement traffic on user traffic.
3. アクティブな測定トラフィックがユーザートラフィックに与える影響。
A sample size may sometimes be referred to as "large". This is a relative and qualitative term. It is preferable to describe what one is attempting to achieve with his sample. For example, stating an implication may be helpful: this sample is large enough that a single outlying value at ten times the "typical" sample mean (the mean without the outlying value) would influence the mean by no more than X.
サンプルサイズは「大」と呼ばれることがあります。これは相対的で定性的な用語です。彼のサンプルで達成しようとしていることを説明することが望ましい。たとえば、意味を述べると役立つ場合があります。このサンプルは十分に大きいため、「標準」サンプル平均の10倍の単一の外れ値（外れ値のない平均）は、Xを超えない範囲で平均に影響します。
The Appendix of [RFC2330] indicates that a sample size of 128 singletons worked well for goodness-of-fit testing, while a much larger size (8192 singletons) almost always failed.
[RFC2330]の付録は、128シングルトンのサンプルサイズが適合度テストに適していることを示していますが、はるかに大きいサイズ（8192シングルトン）はほとんどの場合失敗しました。
The security considerations that apply to any active measurement of live networks are relevant here as well. See the Security Considerations section of [RFC4656] for mandatory-to-implement security features that intend to mitigate attacks.
ライブネットワークのアクティブな測定に適用されるセキュリティの考慮事項は、ここでも関係があります。攻撃を軽減することを目的とした実装から実装までのセキュリティ機能については、[RFC4656]のセキュリティに関する考慮事項のセクションを参照してください。
Measurement systems conducting long-term measurements are more exposed to threats as a by-product of ports open longer to perform their task, and more easily detected measurement activity on those ports. Further, use of long packet waiting times affords an attacker a better opportunity to prepare and launch a replay attack.
長期間の測定を実行する測定システムは、ポートの副産物がタスクを実行するために長時間開いているため、脅威にさらされやすく、これらのポートで測定アクティビティをより簡単に検出できます。さらに、長いパケット待機時間を使用すると、攻撃者はリプレイ攻撃を準備して開始するより良い機会を与えられます。
The authors thank Phil Chimento for his suggestion to employ conditional distributions for delay, Steve Konish Jr. for his careful review and suggestions, Dave McDysan and Don McLachlan for useful comments based on their long experience with measurement and reporting, Daniel Genin for his observation of non-orthogonality between raw and restricted capacity metrics (and for noticing our previous omission of this fact), and Matt Zekauskas for suggestions on organizing the memo for easier consumption.
著者は、遅延のために条件付き分布を採用するように提案してくれたPhil Chimentoに、慎重なレビューと提案をしてくれたSteve Konish Jr.、測定と報告に関する長年の経験に基づく有益なコメントを提供してくれたDave McDysanとDon McLachlanに、未処理の容量メトリックと制限された容量メトリックの間の非直交性（およびこの事実の以前の省略に気付いた場合）、および消費を容易にするためのメモの整理に関する提案のためのMatt Zekauskas。
[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月。
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999.
[RFC2678] Mahdavi、J。およびV. Paxson、「IPPM Metrics for Measurement Connectivity」、RFC 2678、1999年9月。
[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月。
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001.
[RFC3148] Mathis、M。およびM. Allman、「経験的バルク転送容量メトリックを定義するためのフレームワーク」、RFC 3148、2001年7月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]デミケリス、CおよびP.キメント、「IPパフォーマンスメトリックのIPパケット遅延変動メトリック（IPPM）」、RFC 3393、2002年11月。
[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月。
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008.
[RFC5136] Chimento、P。およびJ. Ishac、「Defining Network Capacity」、RFC 5136、2008年2月。
[Casner] Casner, S., Alaettinoglu, C., and C. Kuan, "A Fine-Grained View of High-Performance Networking", NANOG 22 Conf., May 20-22 2001, <http://www.nanog.org/presentations/archive/index.php>.
[Casner] Casner、S.、Alaettinoglu、C。、およびC. Kuan、「高性能ネットワークの詳細なビュー」、NANOG 22会議、2001年5月20〜22日、<http：//www.nanog .org / presentations / archive / index.php>。
[Cia03] Ciavattone, L., Morton, A., and G. Ramachandran, "Standardized Active Measurements on a Tier 1 IP Backbone", IEEE Communications Magazine, Vol. 41 No. 6, pp. 90-97, June 2003.
[Cia03] Ciavattone、L.、Morton、A。、およびG. Ramachandran、「Tier 1 IP Backboneの標準化されたアクティブ測定」、IEEE Communications Magazine、Vol。 41 No. 6、pp.90-97、2003年6月。
[IPPM-RPT] Shalunov, S. and M. Swany, "Reporting IP Performance Metrics to Users", Work in Progress, March 2011.
[IPPM-RPT] Shalunov、S。およびM. Swany、「Reporting IP Performance Metrics to Users」、Work in Progress、2011年3月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481] Morton、A。およびB. Claise、「Packet Delay Variation Applicability Statement」、RFC 5481、2009年3月。
[RFC5835] Morton, A., Ed., and S. Van den Berghe, Ed., "Framework for Metric Composition", RFC 5835, April 2010.
[RFC5835] Morton、A.、Ed。およびS. Van den Berghe、Ed。、「Framework for Metric Composition」、RFC 5835、2010年4月。
[RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, "Framework for TCP Throughput Testing", RFC 6349, August 2011.
[RFC6349] Constantine、B.、Forget、G.、Geib、R。、およびR. Schrage、「TCPスループットテストのフレームワーク」、RFC 6349、2011年8月。
[Y.1540] International Telecommunication Union, "Internet protocol data communication service - IP packet transfer and availability performance parameters", ITU-T Recommendation Y.1540, March 2011.
[Y.1540]国際電気通信連合、「インターネットプロトコルデータ通信サービス-IPパケット転送および可用性パフォーマンスパラメータ」、ITU-T勧告Y.1540、2011年3月。
[Y.1541] International Telecommunication Union, "Network performance objectives for IP-based services", ITU-T Recommendation Y.1541, December 2011.
[Y.1541]国際電気通信連合、「IPベースのサービスのネットワークパフォーマンス目標」、ITU-T勧告Y.1541、2011年12月。
Authors' Addresses
著者のアドレス
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/
Gomathi Ramachandran AT&T Labs 200 Laurel Avenue South Middletown, New Jersey 07748 USA
Gomathi Ramachandran AT＆T Labs 200 Laurel Avenue South Middletown、New Jersey 07748 USA
Phone: +1 732 420 2353
EMail: gomathi@att.com
Ganga Maguluri AT&T Labs 200 Laurel Avenue South Middletown, New Jersey 07748 USA
Ganga Maguluri AT＆T Labs 200 Laurel Avenue South Middletown、New Jersey 07748 USA
Phone: +1 732 420 2486
EMail: gmaguluri@att.com