[要約] RFC 3432は、定期的なストリームを使用したネットワークのパフォーマンス測定に関するものです。その目的は、ネットワークの性能を定量的に評価し、改善するための方法を提供することです。
Network Working Group V. Raisanen
Request for Comments: 3432 Nokia
Category: Standards Track G. Grotefeld
Motorola
A. Morton
AT&T Labs
November 2002
Network performance measurement with periodic streams
周期的なストリームを使用したネットワークパフォーマンス測定
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations.
このメモは、IPネットワークのパフォーマンスを評価するための定期的なサンプリング方法と関連するメトリックについて説明しています。まず、メモは定期的なサンプリングを動機付け、RFC 2330で説明されているポアソンサンプリングに代わるものとしてのその価値の問題に対処します。利点には、アクティブおよびパッシブ測定への適用性、一定ビットレート（CBR）トラフィックのシミュレーション（マルチメディア通信の典型的なもの）が含まれます。、または、音声アクティビティ検出で見られるように、ほぼCBR）、および分析を簡素化できるいくつかのインスタンス。サンプリング方法は、ランダム開始時間と有限長テストを義務付けることにより、予測可能性を回避します。サンプリング方法とサンプルメトリックパラメーターの次の説明、測定方法とエラーについて説明します。最後に、セキュリティ上の考慮事項を含む定期的な測定に関する追加情報を提供します。
Table of Contents
目次
1. Conventions used in this document........................... 2
2. Introduction................................................ 3
2.1 Motivation.............................................. 3
3. Periodic Sampling Methodology............................... 4
4. Sample metrics for periodic streams......................... 5
4.1 Metric name............................................. 5
4.2 Metric parameters....................................... 5
4.3 High level description of the procedure to collect a
sample.................................................. 7
4.4 Discussion.............................................. 8
4.5 Additional Methodology Aspects.......................... 9
4.6 Errors and uncertainties................................ 9
4.7 Reporting............................................... 13
5. Additional discussion on periodic sampling.................. 14
5.1 Measurement applications................................ 15
5.2 Statistics calculable from one sample................... 18
5.3 Statistics calculable from multiple samples............. 18
5.4 Background conditions................................... 19
5.5 Considerations related to delay......................... 19
6. Security Considerations..................................... 19
6.1 Denial of Service Attacks............................... 19
6.2 User data confidentiality............................... 20
6.3 Interference with the metric............................ 20
7. IANA Considerations......................................... 20
8. Normative References........................................ 20
9. Informative References...................................... 21
10. Acknowledgments............................................. 21
11. Author's Addresses.......................................... 22
12. Full Copyright Statement.................................... 23
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 BCP 14, RFC 2119 [2]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure that the results of measurements from two different implementations are comparable, and to note instances in which an implementation could perturb the network.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。RFC 2119はプロトコルを念頭に置いて書かれていますが、キーワードは同様の理由でこのドキュメントで使用されています。これらは、2つの異なる実装からの測定結果が同等であることを保証し、実装がネットワークを摂動できるインスタンスに注意するために使用されます。
This memo describes a sampling method and performance metrics relevant to certain applications of IP networks. The original driver for this work was Quality of Service of interactive periodic streams, such as multimedia conferencing over IP, but the idea of periodic sampling and measurement has wider applicability. Interactive multimedia traffic is used as an example below to illustrate the concept.
このメモは、IPネットワークの特定のアプリケーションに関連するサンプリング方法とパフォーマンスメトリックについて説明しています。この作業の元のドライバーは、IPを介したマルチメディア会議など、インタラクティブな定期的なストリームの品質でしたが、定期的なサンプリングと測定のアイデアはより広範な適用性を持っています。インタラクティブなマルチメディアトラフィックは、概念を説明するために以下の例として使用されます。
Transmitting equally sized packets (or mostly same-size packets) through a network at regular intervals simulates a constant bit-rate (CBR), or a nearly CBR multimedia bit stream. Hereafter, these packets are called periodic streams. Cases of "mostly same-size packets" may be found in applications that have multiple coding methods (e.g. digitally coded comfort noise during silence gaps in speech).
定期的にネットワークを介して等しくサイズのパケット（またはほとんど同じサイズのパケット）を送信すると、一定のビットレート（CBR）、またはほぼCBRマルチメディアビットストリームがシミュレートされます。以下、これらのパケットは定期的なストリームと呼ばれます。「ほとんど同じサイズのパケット」のケースは、複数のコーディング方法を持つアプリケーション（たとえば、沈黙の沈黙のギャップ中にデジタルコード化されたコンフォートノイズ）に見られる場合があります。
In the following sections, a sampling methodology and metrics are presented for periodic streams. The measurement results may be used in derivative metrics such as average and maximum delays. The memo seeks to formalize periodic stream measurements to achieve comparable results between independent implementations.
次のセクションでは、定期的なストリームについてサンプリング方法とメトリックを提示します。測定結果は、平均遅延や最大遅延などの微分メトリックで使用できます。このメモは、定期的なストリーム測定を正式化して、独立した実装間で同等の結果を達成しようとしています。
As noted in the IPPM framework RFC 2330 [3], a sample metric using regularly spaced singleton tests has some limitations when considered from a general measurement point of view: only part of the network performance spectrum is sampled. However, some applications also sample this limited performance spectrum and their performance may be of critical interest.
IPPMフレームワークRFC 2330 [3]で述べたように、定期的に間隔を空けたシングルトンテストを使用したサンプルメトリックには、一般的な測定の観点から考慮されると、いくつかの制限があります。ネットワークパフォーマンススペクトルの一部のみがサンプリングされます。ただし、一部のアプリケーションは、この限られたパフォーマンススペクトルをサンプリングし、そのパフォーマンスは非常に重要なものである可能性があります。
Periodic sampling is useful for the following reasons:
定期的なサンプリングは、次の理由で役立ちます。
* It is applicable to passive measurement, as well as active measurement.
* パッシブ測定とアクティブ測定に適用できます。
* An active measurement can be configured to match the characteristics of media flows, and simplifies the estimation of application performance.
* アクティブな測定は、メディアフローの特性と一致するように構成でき、アプリケーションパフォーマンスの推定を簡素化できます。
* Measurements of many network impairments (e.g., delay variation, consecutive loss, reordering) are sensitive to the sampling frequency. When the impairments themselves are time-varying (and the variations are somewhat rare, yet important), a constant sampling frequency simplifies analysis.
* 多くのネットワーク障害の測定（たとえば、遅延変動、連続した損失、再注文など）は、サンプリング頻度に敏感です。障害自体が時間変動（そして変動がややまれであるが重要であるが重要である）の場合、一定のサンプリング頻度が分析を簡素化します。
* Frequency Domain analysis is simplified when the samples are equally spaced.
* サンプルが等しく間隔を置いている場合、周波数ドメイン分析は簡素化されます。
Simulation of CBR flows with periodic streams encourages dense sampling of network performance, since typical multimedia flows have 10 to 100 packets in each second. Dense sampling permits the characterization of network phenomena with short duration.
定期的なストリームを使用したCBRフローのシミュレーションは、典型的なマルチメディアフローには毎秒10〜100個のパケットがあるため、ネットワークパフォーマンスの密なサンプリングを促進します。密なサンプリングにより、ネットワーク現象の特性評価が短い期間で可能になります。
The Framework RFC [3] points out the following potential problems with Periodic Sampling:
フレームワークRFC [3]は、定期的なサンプリングに関する次の潜在的な問題を指摘しています。
1. The performance sampled may be synchronized with some other periodic behavior, or the samples may be anticipated and the results manipulated. Unpredictable sampling is preferred.
1. サンプリングされたパフォーマンスは、他の周期的な動作と同期することも、サンプルが予想され、結果が操作される場合があります。予測不可能なサンプリングが推奨されます。
2. Active measurements can cause congestion, and periodic sampling might drive congestion-aware senders into a synchronized state, producing atypical results.
2. アクティブな測定は輻輳を引き起こす可能性があり、定期的なサンプリングは、混雑を認識している送信者を同期状態に駆り立て、非定型の結果を生成する可能性があります。
Poisson sampling produces an unbiased sample for the various IP performance metrics, yet there are situations where alternative sampling methods are advantageous (as discussed under Motivation).
Poissonサンプリングは、さまざまなIPパフォーマンスメトリックの公平なサンプルを生成しますが、代替サンプリング方法が有利な状況（動機付けの下で説明されているように）があります。
We can prescribe periodic sampling methods that address the problems listed above. Predictability and some forms of synchronization can be mitigated through the use of random start times and limited stream duration over a test interval. The periodic sampling parameters produce bias, and judicious selection can produce a known bias of interest. The total traffic generated by this or any sampling method should be limited to avoid adverse affects on non-test traffic (packet size, packet rate, and sample duration and frequency should all be considered).
上記の問題に対処する定期的なサンプリング方法を規定できます。予測可能性といくつかの形式の同期は、テスト間隔でランダム開始時間と制限されたストリーム期間を使用することで軽減できます。周期的なサンプリングパラメーターはバイアスを生成し、賢明な選択は既知の関心のあるバイアスを生成する可能性があります。非テストトラフィックへの悪影響を避けるために、このまたは任意のサンプリング方法によって生成される総トラフィックは制限する必要があります（パケットサイズ、パケットレート、サンプルの期間と頻度をすべて考慮する必要があります）。
The configuration parameters of periodic sampling are: + T, the beginning of a time interval where a periodic sample is desired. + dT, the duration of the interval for allowed sample start times. + T0, a time that MUST be selected at random from the interval [T, T+dT] to start generating packets and taking measurements. + Tf, a time, greater than T0, for stopping generation of packets for a sample (Tf may be relative to T0 if desired). + incT, the nominal duration of inter-packet interval, first bit to first bit.
周期的なサンプリングの構成パラメーターは次のとおりです。T、周期的なサンプルが望まれる時間間隔の始まりです。DT、許可されたサンプル開始時間の間隔の持続時間。T0、間隔[t、t dt]からランダムに選択して、パケットの生成と測定を開始する必要があります。サンプルのパケットの生成を停止するためのTF、T0より大きい時間（TFは、必要に応じてT0に関連する場合があります）。INCT、パケット間間隔の公称持続時間、最初のビットから最初のビット。
T0 may be drawn from a uniform distribution, or T0 = T + Unif(0,dT). Other distributions may also be appropriate. Start times in successive time intervals MUST use an independent value drawn from the distribution. In passive measurement, the arrival of user media flows may have sufficient randomness, or a randomized start time of the measurement during a flow may be needed to meet this requirement.
T0は、均一な分布、またはT0 = T unif（0、dt）から描画できます。他の分布も適切かもしれません。連続した時間間隔での開始時間は、分布から描かれた独立した値を使用する必要があります。パッシブ測定では、ユーザーメディアフローの到着には十分なランダム性があるか、この要件を満たすためにフロー中の測定のランダム化開始時間が必要になる場合があります。
When a mix of packet sizes is desired, passive measurements usually possess the sequence and statistics of sizes in actual use, while active measurements would need to reproduce the intended distribution of sizes.
パケットサイズの組み合わせが必要な場合、パッシブ測定は通常、実際の使用でサイズのシーケンスと統計を持っていますが、アクティブな測定では、意図したサイズの分布を再現する必要があります。
The sample metric presented here is similar to the sample metric Type-P-One-way-Delay-Poisson-Stream presented in RFC 2679[4]. Singletons defined in [3] and [4] are applicable here.
ここに示されているサンプルメトリックは、RFC 2679 [4]で提示されたサンプルメトリックタイプ-P-ne-way-delay-poisson-streamに似ています。[3]および[4]で定義されているシングルトンは、ここで適用できます。
Type-P-One-way-Delay-Periodic-Stream
タイプ-P-One-Way-Delay-Preiodic-Stream
These parameters apply in the following sub-sections (4.2.2, 4.2.3, and 4.2.4).
これらのパラメーターは、次のサブセクション（4.2.2、4.2.3、および4.2.4）に適用されます。
Parameters that each Singleton usually includes: + Src, the IP address of a host + Dst, the IP address of a host + IPV, the IP version (IPv4/IPv6) used in the measurement + dTloss, a time interval, the maximum waiting time for a packet before declaring it lost. + packet size p(j), the desired number of bytes in the Type-P packet, where j is the size index.
各シングルトンには通常、SRC、ホストDSTのIPアドレス、ホストIPVのIPアドレス、測定DTLOSSで使用されるIPバージョン（IPv4/IPv6）、時間間隔、パケットの最大待機時間が含まれます。それが失われたと宣言する前に。パケットサイズP（j）、タイプ-Pパケットのバイト数の目的の数。ここで、jはサイズインデックスです。
Optional parameters: + PktType, any additional qualifiers (transport address) + Tcons, a time interval for consolidating parameters collected at the measurement points.
オプションのパラメーター：PKTTYPE、追加の予選（輸送アドレス）TCON、測定ポイントで収集されたパラメーターを統合するための時間間隔。
While a number of applications will use one packet size (j = 1), other applications may use packets of different sizes (j > 1). Especially in cases of congestion, it may be useful to use packets smaller than the maximum or predominant size of packets in the periodic stream.
多くのアプリケーションでは1つのパケットサイズ（j = 1）を使用しますが、他のアプリケーションは異なるサイズのパケット（J> 1）を使用する場合があります。特に輻輳の場合、周期的なストリーム内のパケットの最大サイズまたは主要なサイズよりも小さいパケットを使用すると便利かもしれません。
A topology where Src and Dst are separate from the measurement points is assumed.
SRCとDSTが測定ポイントとは別のトポロジが想定されています。
Parameters that each Singleton usually includes: + Tstamp(Src)[i], for each packet [i], the time of the packet as measured at MP(Src)
各シングルトンには通常、tstamp（src）[i]、各パケット[i]、MP（SRC）で測定されたパケットの時間、
Additional parameters: + PktID(Src) [i], for each packet [i], a unique identification or sequence number. + PktSi(Src) [i], for each packet [i], the actual packet size.
追加のパラメーター：pktid（src）[i]、各パケット[i]、一意の識別またはシーケンス番号。pktsi（src）[i]、各パケット[i]、実際のパケットサイズ。
Some applications may use packets of different sizes, either because of application requirements or in response to IP performance experienced.
一部のアプリケーションでは、アプリケーション要件のため、または経験豊富なIPパフォーマンスに応じて、さまざまなサイズのパケットを使用する場合があります。
+ Tstamp(Dst)[i], for each packet [i], the time of the packet as measured at MP(Dst) + PktID(Dst) [i], for each packet [i], a unique identification or sequence number. + PktSi(Dst) [i], for each packet [i], the actual packet size.
+ TStamp（dst）[i]、各パケット[i]、MP（dst）pktid（dst）[i]で測定されたパケットの時間、各パケット[i]、一意の識別またはシーケンス番号。pktsi（dst）[i]、各パケット[i]、実際のパケットサイズ。
Optional parameters: + dTstop, a time interval, used to add to time Tf to determine when to stop collecting metrics for a sample + PktStatus [i], for each packet [i], the status of the packet received. Possible status includes OK, packet header corrupt, packet payload corrupt, duplicate, fragment. The criteria to determine the status MUST be specified, if used.
オプションのパラメーター：時間間隔であるDTSTOPは、時間TFを追加して、サンプルPKTSTATUS [i]のメトリックの収集を停止するタイミングを決定するために使用されます。可能なステータスには、OK、パケットヘッダーの破損、パケットペイロードが破損、重複、フラグメントが含まれます。使用する場合は、ステータスを決定するための基準を指定する必要があります。
Using the parameters above, a delay singleton would be calculated as follows:
上記のパラメーターを使用して、遅延シングルトンを次のように計算します。
+ Delay [i], for each packet [i], the time interval Delay[i] = Tstamp(Dst)[i] - Tstamp(Src)[i]
+ 遅延[i]、各パケット[i]について、時間間隔の遅延[i] = tstamp（dst）[i] -tstamp（src）[i]
For the following conditions, it will not be possible to compute delay singletons:
次の条件では、遅延シングルトンを計算することはできません。
Spurious: There will be no Tstamp(Src)[i] time Not received: There will be no Tstamp (Dst) [i] Corrupt packet header: There will be no Tstamp (Dst) [i] Duplicate: Only the first non-corrupt copy of the packet received at Dst should have Delay [i] computed.
偽：tStamp（src）[i]受信しない時間はありません：tstamp（dst）[i]破損したパケットヘッダーはありません：tstamp（dst）[i] duplicate：最初の非のみDSTで受信したパケットの破損コピーには、[i]計算された遅延が必要です。
A sample metric for average delay is as follows
平均遅延のサンプルメトリックは次のとおりです
AveDelay = (1/N)Sum(from i=1 to N, Delay[i])
assuming all packets i= 1 through N have valid singletons.
すべてのパケットi = 1からnが有効なシングルトンを持っていると仮定します。
A delay variation [5] singleton can also be computed:
遅延バリエーション[5]シングルトンも計算できます。
+ IPDV[i], for each packet [i] except the first one, delay variation between successive packets would be calculated as
+ IPDV [i]、最初のパケットを除く各パケット[i]について、連続パケット間の遅延変動はとして計算されます
IPDV[i] = Delay[i] - Delay [i-1]
IPDV [i] =遅延[i] - 遅延[i -1]
IPDV[i] may be negative, zero, or positive. Delay singletons for packets i and i-1 must be calculable or IPDV[i] is undefined.
IPDV [i]は負、ゼロ、または陽性である可能性があります。パケットIおよびI-1のシングルトンの遅延は計算可能であるか、IPDV [i]が定義されていません。
An example metric for the IPDV sample is the range:
IPDVサンプルのメトリックの例は、範囲です。
RangeIPDV = max(IPDV[]) - min(IPDV[])
Beginning on or after time T0, Type-P packets are generated by Src and sent to Dst until time Tf is reached with a nominal interval between the first bit of successive packets of incT, as measured at MP(Src). incT may be nominal due to a number of reasons: variation in packet generation at Src, clock issues (see section 4.6), etc. MP(Src) records the parameters above only for packets with timestamps between and including T0 and Tf having the required Src, Dst, and any other qualifiers. MP (Dst) also records for packets with time stamps between T0 and (Tf + dTstop).
時間T0以降に、タイプ-PパケットはSRCによって生成され、MP（SRC）で測定されたINCTの最初のビットの間の公称間隔でTFに達するまでDSTに送信されます。INCTは、SRCでのパケット生成の変動、クロックの問題（セクション4.6を参照）などの多くの理由により、名目上の場合があります。MP（SRC）は、必要なT0とTFの間のタイムスタンプを含むパケットのみで上記のパラメーターを記録します。SRC、DST、およびその他の予選。MP（DST）は、T0と（TF DTSTOP）の間にタイムスタンプを備えたパケットの記録も記録しています。
Optionally at a time Tf + Tcons (but eventually in all cases), the data from MP(Src) and MP(Dst) are consolidated to derive the sample metric results. To prevent stopping data collection too soon, dTcons should be greater than or equal to dTstop. Conversely, to keep data collection reasonably efficient, dTstop should be some reasonable time interval (seconds/minutes/hours), even if dTloss is infinite or extremely long.
オプションでは、時間TF TCON（ただし、最終的にはすべての場合）で、MP（SRC）とMP（DST）のデータが統合され、サンプルメトリック結果が導出されます。データ収集の停止を早すぎるのを防ぐために、DTConsはDTSTOP以上である必要があります。逆に、データ収集を適度に効率的に保つために、DTSTOPは、DTLossが無限または非常に長い場合でも、合理的な時間間隔（秒/分/時間）でなければなりません。
This sampling methodology is intended to quantify the delays and the delay variation as experienced by multimedia streams of an application. Due to the definitions of these metrics, packet loss status is also recorded. The nominal interval between packets assesses network performance variations on a specific time scale.
このサンプリング方法論は、アプリケーションのマルチメディアストリームが経験する遅延と遅延変動を定量化することを目的としています。これらのメトリックの定義により、パケット損失ステータスも記録されます。パケット間の名目間隔は、特定の時間スケールでネットワークのパフォーマンスの変動を評価します。
There are a number of factors that should be taken into account when collecting a sample metric of Type-P-One-way-Delay-Periodic-Stream.
タイプ-P-One-Way-Delay-Periodic-Streamのサンプルメトリックを収集する際に考慮すべき多くの要因があります。
+ The interval T0 to Tf should be specified to cover a long enough time interval to represent a reasonable use of the application under test, yet not excessively long in the same context (e.g. phone calls last longer than 100ms, but less than one week).
+ 間隔T0からTFは、テスト中のアプリケーションの合理的な使用を表すのに十分な長い時間間隔をカバーするように指定する必要がありますが、同じコンテキストでは過度に長くはありません（たとえば、電話の呼び出しは100ms以下、1週間未満です）。
+ The nominal interval between packets (incT) and the packet size(s) (p(j)) should not define an equivalent bit rate that exceeds the capacity of the egress port of Src, the ingress port of Dst, or the capacity of the intervening network(s), if known. There may be exceptional cases to test the response of the application to overload conditions in the transport networks, but these cases should be strictly controlled.
+ パケット（INCT）とパケットサイズ（P（j））の間の名目間隔は、SRCの出口ポート、DSTの侵入ポート、または介入ネットワーク（s）が知られている場合。輸送ネットワークの過負荷条件に対するアプリケーションの応答をテストするための例外的なケースがあるかもしれませんが、これらのケースは厳密に制御する必要があります。
+ Real delay values will be positive. Therefore, it does not make sense to report a negative value as a real delay. However, an individual zero or negative delay value might be useful as part of a stream when trying to discover a distribution of the delay errors.
+ 実際の遅延値はプラスになります。したがって、ネガティブ値を実際の遅延として報告することは意味がありません。ただし、遅延エラーの分布を発見しようとする場合、個々のゼロまたは負の遅延値がストリームの一部として役立つ場合があります。
+ Depending on measurement topology, delay values may be as low as 100 usec to 10 msec, whereby it may be important for Src and Dst to synchronize very closely. GPS systems afford one way to achieve synchronization to within several 10s of usec. Ordinary application of NTP may allow synchronization to within several msec, but this depends on the stability and symmetry of delay properties among the NTP agents used, and this delay is what we are trying to measure.
+ 測定トポロジに応じて、遅延値は100 USECから10ミリ秒の低い場合があります。これにより、SRCとDSTが非常に密接に同期することが重要になる場合があります。GPSシステムは、USECから数十10秒以内に同期を実現する1つの方法を提供します。NTPの通常の適用により、複数のMSEC内で同期が可能になる場合がありますが、これは使用されるNTPエージェント間の遅延特性の安定性と対称性に依存し、この遅延は測定しようとしているものです。
+ A given methodology will have to include a way to determine whether a packet was lost or whether delay is merely very large (and the packet is yet to arrive at Dst). The global metric parameter dTloss defines a time interval such that delays larger than dTloss are interpreted as losses. {Comment: For many applications, the treatment of a large delay as infinite/loss will be inconsequential. A TCP data packet, for example, that arrives only after several multiples of the usual RTT may as well have been lost.}
+ 特定の方法論には、パケットが失われたかどうか、遅延が非常に大きいかどうかを判断する方法を含める必要があります（パケットはまだDSTに到達していません）。グローバルメトリックパラメーターDTLOSSは、DTLOSSよりも大きい遅延が損失として解釈されるように時間間隔を定義します。{コメント：多くのアプリケーションでは、無限/損失としての大きな遅延の処理は取るに足らないものになります。たとえば、通常のRTTの数倍の倍数が失われた後にのみ到着するTCPデータパケット。}
As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence).
他のタイプ-P-*メトリックと同様に、詳細な方法論は、タイプP（たとえば、プロトコル番号、UDP/TCPポート番号、サイズ、優先順位）に依存します。
The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework RFC [3] provides general guidance on this point, but we note here the following specifics related to periodic streams and delay metrics:
特定の測定方法の説明には、さまざまなエラーまたは不確実性のソースの会計と分析を含める必要があります。フレームワークRFC [3]は、この点に関する一般的なガイダンスを提供しますが、ここでは、定期的なストリームと遅延メトリックに関連する以下の詳細に注意してください。
+ Error due to variation of incT. The reasons for this can be uneven process scheduling, possibly due to CPU load.
+ INCTの変動によるエラー。この理由は、おそらくCPU負荷による不均一なプロセススケジューリングです。
+ Errors or uncertainties due to uncertainties in the clocks of the MP(Src) and MP(Dst) measurement points.
+ MP（SRC）およびMP（DST）測定ポイントのクロックの不確実性によるエラーまたは不確実性。
+ Errors or uncertainties due to the difference between 'wire time' and 'host time'.
+ 「ワイヤ時間」と「ホスト時間」の違いによるエラーまたは不確実性。
The uncertainty in a measurement of one-way delay is related, in part, to uncertainties in the clocks of MP(Src) and MP(Dst). In the following, we refer to the clock used to measure when the packet was measured at MP(Src) as the MP(Src) clock and we refer to the clock used to measure when the packet was received at MP(Dst) as the MP(Dst) clock. Alluding to the notions of synchronization, accuracy, resolution, and skew, we note the following:
一元配置遅延の測定における不確実性は、部分的には、MP（SRC）およびMP（DST）の時計の不確実性に関連しています。以下では、PacketがMP（SRC）でMP（SRC）クロックとして測定されたときに測定するために使用されるクロックを参照し、MP（DST）でパケットが受信されたときに使用されるクロックを参照してください。MP（DST）クロック。同期、正確性、解像度、およびスキューの概念をほのめかし、次のことに注意してください。
+ Any error in the synchronization between the MP(Src) clock and the MP(Dst) clock will contribute to error in the delay measurement. We say that the MP(Src) clock and the MP(Dst) clock have a synchronization error of Tsynch if the MP(Src) clock is Tsynch ahead of the MP(Dst) clock. Thus, if we know the value of Tsynch exactly, we could correct for clock synchronization by adding Tsynch to the uncorrected value of Tstamp(Dst)[i] - Tstamp(Src) [i].
+ MP（SRC）クロックとMP（DST）クロック間の同期のエラーは、遅延測定のエラーに寄与します。MP（SRC）クロックがMP（SRC）クロックがMP（DST）クロックより先にTSYNCHである場合、MP（SRC）クロックとMP（DST）クロックにはTSYNCHの同期エラーがあると言います。したがって、TSYNCHの値を正確に知っている場合、TSTYNCHをtStamp（DST）[i] -Tstamp（SRC）[i]の補正値にtsynchを追加することにより、クロック同期を修正できます。
+ The resolution of a clock adds to uncertainty about any time measured with it. Thus, if the MP(Src) clock has a resolution of 10 msec, then this adds 10 msec of uncertainty to any time value measured with it. We will denote the resolution of the source clock and the MP(Dst) clock as ResMP(Src) and ResMP(Dst), respectively.
+ 時計の解像度は、測定された時間について不確実性を追加します。したがって、MP（SRC）クロックの解像度が10ミリ秒の場合、これにより10ミリ秒の不確実性が測定された任意の時間値に追加されます。ソースクロックとMP（DST）クロックの解像度を、それぞれRESMP（SRC）およびRESMP（DST）として示します。
+ The skew of a clock is not so much an additional issue as it is a realization of the fact that Tsynch is itself a function of time. Thus, if we attempt to measure or to bound Tsynch, this measurement or calculation must be repeated periodically. Over some periods of time, this function can be approximated as a linear function plus some higher order terms; in these cases, one option is to use knowledge of the linear component to correct the clock. Using this correction, the residual Tsynch is made smaller, but remains a source of uncertainty that must be accounted for. We use the function Esynch(t) to denote an upper bound on the uncertainty in synchronization. Thus, |Tsynch(t)| <= Esynch(t).
+ 時計のスキューは、Tsynchそれ自体が時間の関数であるという事実の実現であるため、それほど追加の問題ではありません。したがって、Tsynchを測定または結合しようとする場合、この測定または計算を定期的に繰り返す必要があります。ある期間にわたって、この関数は線形関数といくつかの高次項として近似できます。これらの場合、1つのオプションは、線形コンポーネントの知識を使用してクロックを修正することです。この補正を使用して、残留TSYNCHは小さくなりますが、考慮しなければならない不確実性の原因のままです。関数Esynch（T）を使用して、同期の不確実性に関する上限を示します。したがって、| tsynch（t）|<= esynch（t）。
Taking these items together, we note that naive computation Tstamp(Dst)[i] - Tstamp(Src) [i] will be off by Tsynch(t) +/- (ResMP(SRc) + ResMP(Dst)). Using the notion of Esynch(t), we note that these clock-related problems introduce a total uncertainty of Esynch(t)+ Rsource + Rdest. This estimate of total clock-related uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
これらのアイテムをまとめると、素朴な計算tStamp（dst）[i] -tstamp（src）[i]はtsynch（t） / - （resmp（src）resmp（dst））によってオフになることに注意してください。esynch（t）の概念を使用して、これらの時計関連の問題は、esynch（t）rsource rdestの完全な不確実性をもたらすことに注意してください。クロック関連の総不確実性のこの推定は、測定の実装のエラー/不確実性分析に含める必要があります。
We would like to measure the time between when a packet is measured and time-stamped at MP(Src) and when it arrives and is time-stamped at MP(Dst); we refer to these as "wire times." However, if timestamps are applied by software on Src and Dst, then this software can only directly measure the time between when Src generates the packet just prior to sending the test packet and when Dst has started to process the packet after having received the test packet; we refer to these two points as "host times".
PacketがMP（SRC）で測定され、時間刻印されている場合と、MP（DST）で到着してタイムスタンプされている場合の間の時間を測定したいと思います。これらを「ワイヤータイム」と呼びます。ただし、タイムスタンプがSRCとDSTのソフトウェアによって適用されている場合、このソフトウェアは、テストパケットを送信する直前にSRCがパケットを生成するときと、テストパケットを受信した後にDSTがパケットの処理を開始したときの間の時間を直接測定できます。;これらの2つのポイントを「ホストタイム」と呼びます。
To the extent that the difference between wire time and host time is accurately known, this knowledge can be used to correct for wire time measurements. The corrected value more accurately estimates the desired (host time) metric, and visa-versa.
ワイヤ時間とホスト時間の違いが正確にわかっている限り、この知識は、ワイヤータイムの測定を修正するために使用できます。修正された値は、より正確に望ましい（ホストタイム）メトリックを推定し、ビザ-versaを推定します。
To the extent, however, that the difference between wire time and host time is uncertain, this uncertainty must be accounted for in an analysis of a given measurement method. We denote by Hsource an upper bound on the uncertainty in the difference between wire time of MP(Src) and host time on the Src host, and similarly define Hdest for the difference between the host time on the Dst host and the wire time of MP(Dst). We then note that these problems introduce a total uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of any measurement implementation.
ただし、ワイヤ時間とホスト時間の違いが不確実である限り、この不確実性は、特定の測定方法の分析で説明する必要があります。Hsourceは、MP（SRC）のワイヤ時間とSRCホストのホスト時間の差の不確実性に関する上限を示し、DSTホストのホスト時間とMPのワイヤ時間の差について同様にHDESTを定義します。（DST）。次に、これらの問題がHsource HDestの完全な不確実性をもたらすことに注意します。総測定の実装のエラー/不確実性分析には、ワイヤ-VS-HOST総不確実性のこの推定値を含める必要があります。
Generally, the measured values can be decomposed as follows:
一般に、測定値は次のように分解できます。
measured value = true value + systematic error + random error
If the systematic error (the constant bias in measured values) can be determined, it can be compensated for in the reported results.
系統的誤差（測定値の一定のバイアス）を決定できる場合、報告された結果で補償できます。
reported value = measured value - systematic error
報告値=測定値 - 系統的エラー
therefore
したがって従って故にだからですから其れ故依って因って仍って
reported value = true value + random error
報告値=真の値ランダムエラー
The goal of calibration is to determine the systematic and random error generated by the instruments themselves in as much detail as possible. At a minimum, a bound ("e") should be found such that the reported value is in the range (true value - e) to (true value + e) at least 95 percent of the time. We call "e" the calibration error for the measurements. It represents the degree to which the values produced by the measurement instrument are repeatable; that is, how closely an actual delay of 30 ms is reported as 30 ms. {Comment: 95 percent was chosen due to reasons discussed in [4], briefly summarized as (1) some confidence level is desirable to be able to remove outliers, which will be found in measuring any physical property; (2) a particular confidence level should be specified so that the results of independent implementations can be compared.}
キャリブレーションの目標は、機器自体によって生成された系統的およびランダムな誤差を、できるだけ詳細に決定することです。少なくとも、報告された値が少なくとも95％の範囲（真の値-e）から（真の値e）の範囲にあるように、バウンド（ "e"）を見つける必要があります。測定のキャリブレーションエラーを「E」と呼びます。これは、測定機器によって生成される値が再現可能である程度を表します。つまり、30ミリ秒の実際の遅延が30ミリ秒と報告されています。{コメント：[4]で議論された理由により95％が選ばれました。（2）独立した実装の結果を比較できるように、特定の信頼レベルを指定する必要があります。}
From the discussion in the previous two sections, the error in measurements could be bounded by determining all the individual uncertainties, and adding them together to form:
前の2つのセクションでの議論から、測定のエラーは、個々の不確実性をすべて決定し、それらを一緒に追加して形成することによって制限される可能性があります。
Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest
However, reasonable bounds on both the clock-related uncertainty captured by the first three terms and the host-related uncertainty captured by the last two terms should be possible by careful design techniques and calibrating the instruments using a known, isolated, network in a lab.
ただし、最初の3つの用語でキャプチャされた時計関連の不確実性と、最後の2つの用語でキャプチャされたホスト関連の不確実性の両方の合理的な範囲は、慎重な設計技術とラボ内の既知の孤立したネットワークを使用して機器を調整することで可能になるはずです。。
For example, the clock-related uncertainties are greatly reduced through the use of a GPS time source. The sum of Esynch(t) + ResMP(Src) + ResMP(Dst) is small, and is also bounded for the duration of the measurement because of the global time source. The host-related uncertainties, Hsource + Hdest, could be bounded by connecting two instruments back-to-back with a high-speed serial link or isolated LAN segment. In this case, repeated measurements are measuring the same one-way delay.
たとえば、時計関連の不確実性は、GPS時間源を使用することにより大幅に減少します。Esynch（T）RESMP（SRC）RESMP（DST）の合計は小さく、グローバルな時間源のために測定期間中も境界があります。ホスト関連の不確実性であるHsource HDestは、2つの楽器を高速シリアルリンクまたは孤立したLANセグメントと連続して接続することで境界を獲得できます。この場合、繰り返し測定が同じ一方向遅延を測定しています。
If the test packets are small, such a network connection has a minimal delay that may be approximated by zero. The measured delay therefore contains only systematic and random error in the instrumentation. The "average value" of repeated measurements is the systematic error, and the variation is the random error. One way to compute the systematic error, and the random error, to a 95% confidence, is to repeat the experiment many times - at least hundreds of tests. The systematic error would then be the median. The random error could then be found by removing the systematic error from the measured values. The 95% confidence interval would be the range from the 2.5th percentile to the 97.5th percentile of these deviations from the true value. The calibration error "e" could then be taken to be the largest absolute value of these two numbers, plus the clock-related uncertainty. {Comment: as described, this bound is relatively loose since the uncertainties are added, and the absolute value of the largest deviation is used. As long as the resulting value is not a significant fraction of the measured values, it is a reasonable bound. If the resulting value is a significant fraction of the measured values, then more exact methods will be needed to compute the calibration error.}
テストパケットが小さい場合、このようなネットワーク接続には、ゼロで近似する可能性がある最小限の遅延があります。したがって、測定された遅延には、計装に系統的およびランダムな誤差のみが含まれます。繰り返される測定の「平均値」は系統的誤差であり、変動はランダムエラーです。系統的エラーとランダムエラーを95％の信頼性に計算する1つの方法は、実験を何度も繰り返すことです - 少なくとも数百のテスト。系統的エラーは中央値になります。ランダムエラーは、測定された値から系統的エラーを削除することで見つけることができます。95％の信頼区間は、2.5パーセンタイルからこれらの逸脱の97.5パーセンタイルから真の値からの範囲です。キャリブレーションエラー「E」は、これら2つの数値の最大の絶対値と、クロック関連の不確実性と見なすことができます。{コメント：説明されているように、不確実性が追加されているため、このバウンドは比較的緩くなり、最大偏差の絶対値が使用されます。結果の値が測定値の大部分ではない限り、それは合理的な境界です。結果の値が測定値のかなりの部分である場合、キャリブレーションエラーを計算するには、より正確な方法が必要になります。}
Note that random error is a function of measurement load. For example, if many paths will be measured by one instrument, this might increase interrupts, process scheduling, and disk I/O (for example, recording the measurements), all of which may increase the random error in measured singletons. Therefore, in addition to minimal load measurements to find the systematic error, calibration measurements should be performed with the same measurement load that the instruments will see in the field.
ランダムエラーは測定負荷の関数であることに注意してください。たとえば、多くのパスが1つの機器で測定される場合、これにより割り込み、プロセススケジューリング、ディスクI/O（たとえば、測定値の記録）が増加する可能性があります。したがって、系統的誤差を見つけるための最小負荷測定に加えて、機器がフィールドに表示されるのと同じ測定荷重でキャリブレーション測定を実行する必要があります。
We wish to reiterate that this statistical treatment refers to the calibration of the instrument; it is used to "calibrate the meter stick" and say how well the meter stick reflects reality.
この統計的治療は、機器のキャリブレーションを指していることを繰り返したいと思います。「メータースティックをキャリブレーション」し、メータースティックが現実をどれほどうまく反映しているかを言うために使用されます。
The nominal interval between packets, incT, can vary during either active or passive measurements. In passive measurement, packet headers may include a timestamp applied prior to most of the protocol stack, and the actual sending time may vary due to processor scheduling. For example, H.323 systems are required to have packets ready for the network stack within 5 ms of their ideal time. There may be additional variation from the network between the Src and the MP(Src). Active measurement systems may encounter similar errors, but to a lesser extent. These errors must be accounted for in some types of analysis.
パケット間の公称間隔、INCTは、アクティブ測定またはパッシブ測定中に異なる場合があります。パッシブ測定では、パケットヘッダーには、ほとんどのプロトコルスタックの前に適用されるタイムスタンプが含まれる場合があり、実際の送信時間はプロセッサのスケジューリングにより異なる場合があります。たとえば、H.323システムは、理想的な時間から5ミリ秒以内にネットワークスタックのパケットを準備する必要があります。SRCとMP（SRC）の間にネットワークから追加のバリエーションがある場合があります。アクティブ測定システムは、同様のエラーに遭遇する可能性がありますが、それほどではありません。これらのエラーは、ある種の分析で説明する必要があります。
The calibration and context in which the method is used MUST be carefully considered, and SHOULD always be reported along with metric results. We next present five items to consider: the Type-P of test packets, the threshold of delay equivalent to loss, error calibration, the path traversed by the test packets, and background conditions at Src, Dst, and the intervening networks during a sample. This list is not exhaustive; any additional information that could be useful in interpreting applications of the metrics should also be reported.
メソッドが使用されるキャリブレーションとコンテキストを慎重に考慮する必要があり、メトリック結果とともに常に報告する必要があります。次に、検討すべき5つの項目を提示します。テストパケットのタイプ-P、損失に相当する遅延のしきい値、エラーキャリブレーション、テストパケットによって移動されるパス、およびサンプル中のSRC、DST、および介在するネットワークの背景条件を提示します。。このリストは網羅的ではありません。メトリックのアプリケーションの解釈に役立つ可能性のある追加情報も報告する必要があります。
As noted in the Framework document [3], the value of a metric may depend on the type of IP packets used to make the measurement, or "type-P". The value of Type-P-One-way-Periodic-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes. The exact Type-P used to make the measurements MUST be reported.
フレームワークドキュメント[3]に記載されているように、メトリックの値は、測定を行うために使用されるIPパケットのタイプ、または「タイプP」に依存する場合があります。特別な治療のためのプロトコル（UDPまたはTCP）、ポート番号、サイズ、または配置（IPの優先順位やRSVPなど）が変更された場合、タイプ-P-One-Way-Periodic-Delayの値は変化する可能性があります。測定を行うために使用される正確なタイプ-Pを報告する必要があります。
In addition, the threshold for delay equivalent to loss (or methodology to determine this threshold) MUST be reported.
さらに、損失（またはこのしきい値を決定する方法論）に相当する遅延のしきい値を報告する必要があります。
+ If the systematic error can be determined, it SHOULD be removed from the measured values. + You SHOULD also report the calibration error, e, such that the true value is the reported value plus or minus e, with 95% confidence (see the last section.) + If possible, the conditions under which a test packet with finite delay is reported as lost due to resource exhaustion on the measurement instrument SHOULD be reported.
+ 系統的誤差を決定できる場合は、測定値から削除する必要があります。また、真の値が報告された値プラスまたはマイナスEであるキャリブレーションエラーを報告する必要があります。測定機器のリソースの疲労のために失われたように、報告する必要があります。
The path traversed by the packets SHOULD be reported, if possible. In general, it is impractical to know the precise path a given packet takes through the network. The precise path may be known for certain Type-P packets on short or stable paths. If Type-P includes the record route (or loose-source route) option in the IP header, and the path is short enough, and all routers on the path support record (or loose-source) route, then the path will be precisely recorded.
可能であれば、パケットによって横断されるパスを報告する必要があります。一般に、特定のパケットがネットワークを介して取る正確なパスを知ることは非現実的です。正確なパスは、短いパスまたは安定したパス上の特定のタイプPパケットで知られている場合があります。IPヘッダーのType-PがIPヘッダーのレコードルート（またはルーズソースルート）オプションを含み、パスが十分に短く、パスサポートレコード（またはルーズソース）ルートのすべてのルーターが十分に短い場合、パスは正確になります録音。
This may be impractical because the route must be short enough. Many routers do not support (or are not configured for) record route, and use of this feature would often artificially worsen the performance observed by removing the packet from common-case processing.
ルートは十分に短くなければならないため、これは非現実的かもしれません。多くのルーターはレコードルートをサポートしていません（または構成されていません）。この機能を使用すると、一般的なケース処理からパケットを削除することで観察されるパフォーマンスが人為的に悪化することがよくあります。
However, partial information is still valuable context. For example, if a host can choose between two links (and hence two separate routes from Src to Dst), then the initial link used is valuable context. {Comment: For example, with one commercial setup, a Src on one NAP can reach a Dst on another NAP by either of several different backbone networks.}
ただし、部分情報は依然として貴重なコンテキストです。たとえば、ホストが2つのリンク（したがってSRCからDSTまでの2つの別々のルート）から選択できる場合、使用される初期リンクは貴重なコンテキストです。{コメント：たとえば、1つのコマーシャルセットアップにより、ある昼寝のSRCは、いくつかの異なるバックボーンネットワークのいずれかによって別の昼寝のDSTに到達できます。}
Fig.1 illustrates measurements on multiple protocol levels that are relevant to this memo. The user's focus is on transport quality evaluation from the application point of view. However, to properly separate the quality contribution of the operating system and codec on packet voice, for example, it is beneficial to be able to measure quality at the IP level [6]. Link layer monitoring provides a way of accounting for link layer characteristics such as bit error rates.
図1は、このメモに関連する複数のプロトコルレベルの測定値を示しています。ユーザーの焦点は、アプリケーションの観点からの輸送品質評価に焦点を当てています。ただし、たとえば、パケット音声でオペレーティングシステムとコーデックの品質貢献を適切に分離するには、IPレベルで品質を測定できることが有益です[6]。リンクレイヤー監視は、ビットエラーレートなどのリンクレイヤー特性を説明する方法を提供します。
---------------
| application |
---------------
| transport | <--
---------------
| network | <--
---------------
| link | <--
---------------
| physical |
---------------
Fig. 1: Different possibilities for performing measurements: a protocol view. Above, "application" refers to all layers above L4 and is not used in the OSI sense.
図1：測定を実行するためのさまざまな可能性：プロトコルビュー。上記の「アプリケーション」とは、L4を超えるすべての層を指し、OSIの意味では使用されません。
In general, the results of measurements may be influenced by individual application requirements/responses related to the following issues:
一般に、測定の結果は、次の問題に関連する個々のアプリケーション要件/回答の影響を受ける可能性があります。
+ Lost packets: Applications may have varying tolerance to lost packets. Another consideration is the distribution of lost packets (i.e. random or bursty).
+ 失われたパケット：アプリケーションは、紛失したパケットに対して耐性が異なる場合があります。別の考慮事項は、失われたパケットの分布（つまり、ランダムまたはバースト）です。
+ Long delays: Many applications will consider packets delayed longer than a certain value to be equivalent to lost packets (i.e. real time applications). + Duplicate packets: Some applications may be perturbed if duplicate packets are received. + Reordering: Some applications may be perturbed if packets arrive out of sequence. This may be in addition to the possibility of exceeding the "long" delay threshold as a result of being out of sequence. + Corrupt packet header: Most applications will probably treat a packet with a corrupt header as equivalent to a lost packet. + Corrupt packet payload: Some applications (e.g. digital voice codecs) may accept corrupt packet payload. In some cases, the packet payload may contain application specific forward error correction (FEC) that can compensate for some level of corruption. + Spurious packet: Dst may receive spurious packets (i.e. packets that are not sent by the Src as part of the metric). Many applications may be perturbed by spurious packets.
+ 長い遅延：多くのアプリケーションでは、特定の値よりも長く遅延しているパケットが失われたパケット（つまり、リアルタイムアプリケーション）と同等であると考えられます。重複パケット：複製パケットが受信された場合、一部のアプリケーションが乱れている場合があります。並べ替え：パケットが順序外に到着した場合、一部のアプリケーションが乱れている場合があります。これは、シーケンスがなくなった結果、「長い」遅延しきい値を超える可能性に加えている場合があります。破損したパケットヘッダー：ほとんどのアプリケーションは、おそらくパケットを腐敗したパケットに相当するパケットを扱います。破損したパケットペイロード：一部のアプリケーション（デジタル音声コーデックなど）は、破損したパケットペイロードを受け入れる場合があります。場合によっては、パケットペイロードには、ある程度の腐敗を補うことができるアプリケーション固有のフォワードエラー補正（FEC）が含まれる場合があります。スプリアスパケット：DSTは、スプリアスパケット（つまり、メトリックの一部としてSRCから送信されないパケット）を受信する場合があります。多くのアプリケーションは、偽のパケットによって乱れられる場合があります。
Depending, e.g., on the observed protocol level, some issues listed above may be indistinguishable from others by the application, it may be important to preserve the distinction for the operators of Src, Dst, and/or the intermediate network(s).
たとえば、観察されたプロトコルレベルに応じて、上記のいくつかの問題は、アプリケーションによって他の問題と見分けがつかない場合があり、SRC、DST、および/または中間ネットワークのオペレーターの区別を維持することが重要かもしれません。
This sampling method provides a way to perform measurements irrespective of the possible QoS mechanisms utilized in the IP network. As an example, for a QoS mechanism without hard guarantees, measurements may be used to ascertain that the "best" class gets the service that has been promised for the traffic class in question. Moreover, an operator could study the quality of a cheap, low-guarantee service implemented using possible slack bandwidth in other classes. Such measurements could be made either in studying the feasibility of a new service, or on a regular basis.
このサンプリング方法は、IPネットワークで利用される可能性のあるQoSメカニズムに関係なく、測定を実行する方法を提供します。例として、ハード保証のないQOSメカニズムの場合、測定を使用して、「最良の」クラスが問題のトラフィッククラスに約束されたサービスを取得することを確認することができます。さらに、オペレーターは、他のクラスで可能なスラック帯域幅を使用して実装された安価で低保証サービスの品質を研究できます。このような測定は、新しいサービスの実現可能性を研究すること、または定期的に行うことができます。
IP delivery service measurements have been discussed within the International Telecommunications Union (ITU). A framework for IP service level measurements (with references to the framework for IP performance [3]) that is intended to be suitable for service planning has been approved as I.380 [7]. ITU-T Recommendation I.380 covers abstract definitions of performance metrics. This memo describes a method that is useful, both for service planning and end-user testing purposes, in both active and passive measurements.
IP配信サービスの測定は、国際電気通信連合（ITU）で議論されています。サービス計画に適していることを目的としたIPサービスレベル測定のフレームワーク（IPパフォーマンスのフレームワークへの参照[3]）は、i.380 [7]として承認されています。ITU-Tの推奨I.380は、パフォーマンスメトリックの抽象的な定義をカバーしています。このメモは、アクティブ測定とパッシブ測定の両方で、サービスプランニングとエンドユーザーテストの両方の目的で有用な方法を説明しています。
Delay measurements can be one-way [3,4], paired one-way, or round-trip [8]. Accordingly, the measurements may be performed either with synchronized or unsynchronized Src/Dst host clocks. Different possibilities are listed below.
遅延測定は、一方向[3,4]、ペアの一方向、または往復[8]になる可能性があります。したがって、測定値は、同期または無効化されていないSRC/DSTホストクロックのいずれかで実行できます。さまざまな可能性を以下に示します。
The reference measurement setup for all measurement types is shown in Fig. 2.
すべての測定タイプの参照測定セットアップを図2に示します。
----------------< IP >--------------------
| | | |
------- ------- -------- --------
| Src | | MP | | MP | | Dst |
------- |(Src)| |(Dst) | --------
------- --------
Fig. 2: Example measurement setup.
図2：測定セットアップの例。
An example of the use of the method is a setup with a source host (Src), a destination host (Dst), and corresponding measurement points (MP(Src) and MP(Dst)) as shown in Figure 2. Separate equipment for measurement points may be used if having Src and/or Dst conduct the measurement may significantly affect the delay performance to be measured. MP(Src) should be placed/measured close to the egress point of packets from Src. MP(Dst) should be placed/measure close to the ingress point of packets for Dst. "Close" is defined as a distance sufficiently small so that application-level performance characteristics measured (such as delay) can be expected to follow the corresponding performance characteristic between Src and Dst to an adequate accuracy. The basic principle here is that measurement results between MP(Src) and MP(Dst) should be the same as for a measurement between Src and Dst, within the general error margin target of the measurement (e.g., < 1 ms; number of lost packets is the same). If this is not possible, the difference between MP-MP measurement and Src-Dst measurement should preferably be systematic.
この方法の使用の例は、図2に示すように、ソースホスト（SRC）、宛先ホスト（DST）、および対応する測定ポイント（MP（SRC）およびMP（DST））を使用したセットアップです。SRCおよび/またはDSTの導電性を持つ場合、測定が測定される遅延性能に大きく影響する場合がある場合、測定ポイントを使用できます。MP（SRC）は、SRCのパケットの出力点の近くに配置/測定する必要があります。MP（DST）は、DSTのパケットの侵入点の近くに配置/測定する必要があります。「Close」は、測定されたアプリケーションレベルのパフォーマンス特性（遅延など）がSRCとDSTの間の対応するパフォーマンス特性を適切な精度に従うことが期待できるように、十分に小さく距離として定義されます。ここでの基本原則は、MP（SRC）とMP（DST）の間の測定結果は、測定の一般的な誤差マージンターゲット内で、SRCとDSTの測定と同じであるべきであることです（例えば、<1 ms、紛失の数パケットは同じです）。これが不可能な場合、MP-MP測定とSRC-DST測定の違いは、できれば体系的でなければなりません。
The test setup just described fulfills two important criteria:
説明されているテストのセットアップは、2つの重要な基準を満たしています。
1) The test is made with realistic stream metrics, emulating - for example - a full-duplex Voice over IP (VoIP) call.
1) このテストは、リアルなストリームメトリックで行われ、たとえばエミュレート - IP（VOIP）通話をエミュレートします。
2) Either one-way or round-trip characteristics may be obtained.
2) 一方向または往復特性のいずれかが取得される場合があります。
It is also possible to have intermediate measurement points between MP(Src) and MP(Dst), but that is beyond the scope of this document.
MP（SRC）とMP（DST）の間に中間測定ポイントを持つことも可能ですが、これはこのドキュメントの範囲を超えています。
In the interests of specifying metrics that are as generally applicable as possible, application-level measurements based on one-way delays are used in the example metrics. The implication of application-level measurement for bi-directional applications, such as interactive multimedia conferencing, is discussed below.
可能な限り一般的に適用可能なメトリックを指定するために、一元配置遅延に基づくアプリケーションレベルの測定値が例メトリックで使用されます。インタラクティブなマルチメディア会議など、双方向アプリケーションのアプリケーションレベルの測定の意味については、以下で説明します。
Performing a single one-way measurement only yields information on network behavior in one direction. Moreover, the stream at the network transport level does not emulate accurately a full-duplex multimedia connection.
単一の一方向測定を実行すると、ネットワークの動作に関する情報が一方向に生成されます。さらに、ネットワークトランスポートレベルのストリームは、フルダプレックスマルチメディア接続を正確にエミュレートしません。
Paired one way delay refers to two multimedia streams: Src to Dst and Dst to Src for the same Src and Dst. By way of example, for some applications, the delay performance of each one way path is more important than the round trip delay. This is the case for delay-limited signals such as VoIP. Possible reasons for the difference between one-way delays is different routing of streams from Src to Dst vs. Dst to Src.
ペアの片道遅延とは、同じSRCとDSTの2つのマルチメディアストリーム、DSTからDSTへのDSTからSRCへの2つのマルチメディアストリームを指します。例として、一部のアプリケーションでは、各片道パスの遅延パフォーマンスが往復遅延よりも重要です。これは、VoIPなどの遅延制限信号の場合です。一方向遅延間の違いの考えられる理由は、SRCからDST対DSTへのストリームの異なるルーティングです。
For example, a paired one way measurement may show that Src to Dst has an average delay of 30ms, while Dst to Src has an average delay of 120ms. To a round trip delay measurement, this example would look like an average of 150ms delay. Without the knowledge of the asymmetry, we might miss a problem that the application at either end may have with delays averaging more than 100ms.
たとえば、ペアの片道測定では、SRCからDSTの平均遅延が30msであることが示され、DSTからSRCの平均遅延は120msです。往復遅延測定には、この例は平均150ms遅延のように見えます。非対称性の知識がなければ、どちらかの端でのアプリケーションが平均して100ミリ秒以上の遅延で抱えている問題を見逃す可能性があります。
Moreover, paired one way delay measurement emulates a full-duplex VoIP call more accurately than a single one-way measurement only.
さらに、ペアの片道遅延測定は、単一の一方向測定のみよりも正確にフルダップレックスVoIPコールをエミュレートします。
From the point of view of periodic multimedia streams, round-trip measurements have two advantages: they avoid the need of host clock synchronization and they allow for a simulation of full-duplex communication. The former aspect means that a measurement is easily performed, since no special equipment or NTP setup is needed. The latter property means that measurement streams are transmitted in both directions. Thus, the measurement provides information on quality of service as experienced by two-way applications.
周期的なマルチメディアストリームの観点から、往復測定には2つの利点があります。ホストクロック同期の必要性を回避し、フルダプレックス通信のシミュレーションを可能にします。前の側面は、特別な機器やNTPセットアップが必要ないため、測定が簡単に実行できることを意味します。後者のプロパティは、測定ストリームが両方向に送信されることを意味します。したがって、この測定は、双方向アプリケーションが経験したサービス品質に関する情報を提供します。
The downsides of round-trip measurement are the need for more bandwidth than a one-way test and more complex accounting of packet loss. Moreover, the stream that is returning towards the original sender may be more bursty than the one on the first "leg" of the round-trip journey. The last issue, however, means in practice that the returning stream may experience worse QoS than the out-going one, and the performance estimates thus obtained are pessimistic ones. The possibility of asymmetric routing and queuing must be taken into account during an analysis of the results.
往復測定の欠点は、一方向テストやパケット損失のより複雑な会計よりも多くの帯域幅が必要です。さらに、元の送信者に向かって戻っているストリームは、往復の最初の「脚」のストリームよりも破裂している可能性があります。ただし、最後の号では、実際には、戻ってくるストリームが出て行くものよりも悪いQosを経験する可能性があり、このようにして得られたパフォーマンスの推定は悲観的なものであることを意味します。非対称ルーティングとキューイングの可能性は、結果の分析中に考慮する必要があります。
Note that with suitable arrangements, round-trip measurements may be performed using paired one way measurements.
適切な配置を使用すると、ペアの片道測定を使用して往復測定を実行できることに注意してください。
Some statistics may be particularly relevant to applications simulated by periodic streams, such as the range of delay values recorded during the sample.
一部の統計は、サンプル中に記録された遅延値の範囲など、周期的なストリームによってシミュレートされたアプリケーションに特に関連する場合があります。
For example, a sample metric generates 100 packets at MP(Src) with the following measurements at MP(Dst):
たとえば、サンプルメトリックは、MP（DST）で次の測定値でMP（SRC）で100個のパケットを生成します。
+ 80 packets received with delay [i] <= 20 ms
+ 8 packets received with delay [i] > 20 ms
+ 5 packets received with corrupt packet headers
+ 4 packets from MP(Src) with no matching packet recorded at
MP(Dst) (effectively lost)
+ 3 packets received with corrupt packet payload and delay
[i] <= 20 ms
+ 2 packets that duplicate one of the 80 packets received correctly
as indicated in the first item
For this example, packets are considered acceptable if they are received with less than or equal to 20ms delays and without corrupt packet headers or packet payload. In this case, the percentage of acceptable packets is 80/100 = 80%.
この例では、パケットが20ミリ秒以下の遅延で受信され、破損したパケットヘッダーまたはパケットペイロードなしで受信された場合、受け入れられると見なされます。この場合、許容可能なパケットの割合は80/100 = 80％です。
For a different application that will accept packets with corrupt packet payload and no delay bounds (so long as the packet is received), the percentage of acceptable packets is (80+8+3)/100 = 91%.
破損したパケットペイロードと遅延境界なしのパケットを受け入れる別のアプリケーションの場合（パケットが受信される限り）、許容可能なパケットの割合は（80 8 3）/100 = 91％です。
There may be value in running multiple tests using this method to collect a "sample of samples". For example, it may be more appropriate to simulate 1,000 two-minute VoIP calls rather than a single 2,000 minute call. When considering a collection of multiple samples, issues like the interval between samples (e.g. minutes, hours), composition of samples (e.g. equal Tf-T0 duration, different packet sizes), and network considerations (e.g. run different samples over different intervening link-host combinations) should be taken into account. For items like the interval between samples, the usage pattern for the application of interest should be considered.
この方法を使用して複数のテストを実行して「サンプルのサンプル」を収集することには価値があるかもしれません。たとえば、2,000分間のコールではなく、1,000の2分間のVoIPコールをシミュレートする方が適切かもしれません。複数のサンプルのコレクションを検討する場合、サンプル間の間隔（数分、時間）、サンプルの構成（たとえば、TF-T0の持続時間等しい時間、異なるパケットサイズ）、およびネットワークの考慮事項（例：異なる介在リンクで異なるサンプルを実行するなどの問題 - ホストの組み合わせ）を考慮する必要があります。サンプル間の間隔などの項目の場合、関心を適用するための使用パターンを考慮する必要があります。
When computing statistics for multiple samples, more general statistics (e.g. median, percentile, etc.) may have relevance with a larger number of packets.
複数のサンプルの統計を計算する場合、より一般的な統計（例：中央値、パーセンタイルなど）は、より多くのパケットに関連する可能性があります。
In many cases, the results may be influenced by conditions at Src, Dst, and/or any intervening networks. Factors that may affect the results include: traffic levels and/or bursts during the sample, link and/or host failures, etc. Information about the background conditions may only be available by external means (e.g. phone calls, television) and may only become available days after samples are taken.
多くの場合、結果は、SRC、DST、および/または介入ネットワークの条件の影響を受ける可能性があります。結果に影響を与える可能性のある要因には、サンプル、リンク、および/またはホストの障害などのトラフィックレベルおよび/またはバーストが含まれます。背景条件に関する情報は、外部手段（電話、テレビなど）でのみ利用可能であり、サンプルが採取されてから数日後に利用可能。
For interactive multimedia sessions, end-to-end delay is an important factor. Too large a delay reduces the quality of the multimedia session as perceived by the participants. One approach for managing end-to-end delays on an Internet path involving heterogeneous link layer technologies is to use per-domain delay quotas (e.g. 50 ms for a particular IP domain). However, this scheme has clear inefficiencies, and can over-constrain the problem of achieving some end-to-end delay objective. A more flexible implementation ought to address issues like the possibility of asymmetric delays on paths, and sensitivity of an application to delay variations in a given domain. There are several alternatives as to the delay statistic one ought to use in managing end-to-end QoS. This question, although very interesting, is not within the scope of this memo and is not discussed further here.
インタラクティブなマルチメディアセッションの場合、エンドツーエンドの遅延が重要な要素です。遅延が大きすぎると、参加者が知覚するマルチメディアセッションの品質が低下します。不均一なリンクレイヤーテクノロジーを含むインターネットパスでエンドツーエンドの遅延を管理するための1つのアプローチは、ドメインごとの遅延クォータを使用することです（特定のIPドメインでは50ミリ秒）。ただし、このスキームには明確な非効率性があり、エンドツーエンドの遅延目標を達成するという問題を過剰に制約することができます。より柔軟な実装は、パスの非対称的な遅延の可能性や、特定のドメインの変動を遅らせるアプリケーションの感度などの問題に対処する必要があります。エンドツーエンドQosの管理に使用すべき遅延統計に関するいくつかの選択肢があります。この質問は、非常に興味深いものですが、このメモの範囲内ではなく、ここではこれ以上議論されていません。
This method generates a periodic stream of packets from one host (Src) to another host (Dst) through intervening networks. This method could be abused for denial of service attacks directed at Dst and/or the intervening network(s).
この方法では、介在するネットワークを介して、あるホスト（SRC）から別のホスト（DST）までのパケットの周期的なストリームを生成します。この方法は、DSTおよび/または介入ネットワークに向けられたサービス拒否攻撃のために乱用される可能性があります。
Administrators of Src, Dst, and the intervening network(s) should establish bilateral or multi-lateral agreements regarding the timing, size, and frequency of collection of sample metrics. Use of this method in excess of the terms agreed between the participants may be cause for immediate rejection, discard of packets, or other escalation procedures defined between the affected parties.
SRC、DST、および介入ネットワークの管理者は、サンプルメトリックの収集のタイミング、サイズ、頻度に関する二国間または多国間協定を確立する必要があります。参加者間で合意された条件を超えるこの方法の使用は、影響を受ける当事者間で定義されている即時拒否、パケットの破棄、またはその他のエスカレーション手順の原因である可能性があります。
Active use of this method generates packets for a sample, rather than taking samples based on user data, and does not threaten user data confidentiality. Passive measurement must restrict attention to the headers of interest. Since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep this information safe and confidential.
このメソッドを積極的に使用すると、ユーザーデータに基づいてサンプルを採取するのではなく、サンプル用のパケットを生成し、ユーザーデータの機密性を脅かすことはありません。パッシブ測定は、関心のあるヘッダーへの注意を制限する必要があります。ユーザーのペイロードは長さ分析のために一時的に保存される可能性があるため、この情報を安全かつ機密に保つために適切な予防措置を講じる必要があります。
It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at Dst and/or the intervening networks, it is possible to change the processing of the packets (e.g. increasing or decreasing delay) that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement.
特定のパケットまたはパケットのストリームがサンプルの一部であることを特定することが可能かもしれません。DSTおよび/または介在するネットワークでのその知識により、測定されたパフォーマンスを歪める可能性のあるパケットの処理（たとえば、遅延の増加または減少）を変更することができます。サンプルメトリックの一部であると思われる追加のパケットを生成することも可能です。これらの追加のパケットは、サンプル測定の結果を乱す可能性があります。
To discourage the kind of interference mentioned above, packet interference checks, such as cryptographic hash, MAY be used.
上記の干渉の種類を思いとどまらせるために、暗号化のハッシュなどのパケット干渉チェックを使用できます。
Since this method and metric do not define a protocol or well-known values, there are no IANA considerations in this memo.
この方法とメトリックはプロトコルまたはよく知られている値を定義していないため、このメモにはIANAの考慮事項はありません。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[3] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[4] Almes, G., Kalidindi, S. and M. Zekauskas, "A one-way delay metric for IPPM", RFC 2679, September 1999.
[4] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一元配置遅延メトリック」、RFC 2679、1999年9月。
[5] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[5] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、RFC 3393、2002年11月。
[6] "End-to-end Quality of Service in TIPHON systems; Part 5: Quality of Service (QoS) measurement methodologies", ETSI TS 101 329-5 V1.1.2, January 2002.
[6] 「Tiphon Systemsのエンドツーエンドサービス品質;パート5：サービス品質（QOS）測定方法」、ETSI TS 101 329-5 V1.1.2、2002年1月。
[7] International Telecommunications Union, "Internet protocol data communication service _ IP packet transfer and availability performance parameters", Telecommunications Sector Recommendation I.380 (re-numbered Y.1540), February 1999.
[7] International Telecommunications Union、「インターネットプロトコルデータ通信サービス_ IPパケット転送および可用性パフォーマンスパラメーター」、電気通信セクターの推奨I.380（再番号Y.1540）、1999年2月。
[8] Almes, G., Kalidindi, S. and M. Zekauskas, "A round-trip delay metric for IPPM", RFC 2681, September 1999.
[8] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
The authors wish to thank the chairs of the IPPM WG (Matt Zekauskas and Merike Kaeo) for comments that have made the present document more clear and focused. Howard Stanislevic and Will Leland have also presented useful comments and questions. We also gratefully acknowledge Henk Uijterwaal's continued challenge to develop the motivation for this method. The authors have built on the substantial foundation laid by the authors of the framework for IP performance [3].
著者は、現在の文書をより明確で集中させたコメントについて、IPPM WG（Matt ZekauskasおよびMerige Kaeo）の椅子に感謝したいと考えています。Howard StanislevicとWill Lelandも有用なコメントや質問を提示しています。また、この方法の動機を開発するというHenk Uijterwaalの継続的な挑戦にも感謝します。著者は、IPパフォーマンスのフレームワークの著者によって築かれた実質的な基盤の上に構築されています[3]。
Vilho Raisanen Nokia Networks P.O. Box 300 FIN-00045 Nokia Group Finland
Vilho Raisanen Nokia Networks P.O.ボックス300フィン-00045ノキアグループフィンランド
Phone: +358 7180 8000
Fax: +358 9 4376 6852
EMail: Vilho.Raisanen@nokia.com
Glenn Grotefeld Motorola, Inc. 1501 W. Shure Drive, MS 2F1 Arlington Heights, IL 60004 USA
Glenn Grotefeld Motorola、Inc。1501 W. Shure Drive、MS 2F1 Arlington Heights、IL 60004 USA
Phone: +1 847 435-0730
Fax: +1 847 632-6800
EMail: g.grotefeld@motorola.com
Al Morton AT&T Labs Room D3 - 3C06 200 Laurel Ave. South Middletown, NJ 07748 USA
Al Morton AT＆T Labs Room D3-3C06 200 Laurel Ave. South Middletown、NJ 07748 USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。