RFC3432 日本語訳
3432 Network performance measurement with periodic streams. V.Raisanen, G. Grotefeld, A. Morton. November 2002. (Format: TXT=52493 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Raisanen
Request for Comments: 3432 Nokia
Category: Standards Track G. Grotefeld
Motorola
A. Morton
AT&T Labs
November 2002
Raisanenがコメントのために要求するワーキンググループV.をネットワークでつないでください: 3432年のノキアカテゴリ: 標準化過程G.GrotefeldモトローラA.モートンAT&T研究室2002年11月
Network performance measurement with periodic streams
周期的な流れによるネットワーク性能測定
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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ネットワークの性能を評価するために周期的な標本抽出方法と関連測定基準について説明します。 まず最初に、メモは、RFC2330で説明されたポアソン標本抽出に代わる手段として周期的な標本抽出を動機づけて、価値の問題を記述します。 利益は分析を簡素化できるアクティブで受け身の測定値、(マルチメディア通信、またはほとんどCBRの典型と、声のアクティビティ検出について備え付け)の固定ビットレート(CBR)交通のシミュレーション、およびいくつかの例への適用性を含んでいます。 標本抽出方法は、ランダム・スタート時間と有限長さ試験を強制することによって、予見性を避けます。 標本抽出方法とサンプルのメートル法のパラメタ、測定方法、および誤りの後述について議論します。 最終的に、私たちはセキュリティ問題を含む周期的な測定値に関する追加情報を与えます。
Raisanen, et al. Standards Track [Page 1] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[1ページ]RFC3432Network性能測定2002年11月
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
1. このドキュメントで中古のコンベンション… 2 2. 序論… 3 2.1動機… 3 3. 周期的なサンプリング法… 4 4. 周期的な流れのために測定基準を抽出してください… 5 4.1のメートル法の名… 5 4.2のメートル法のパラメタ… 5 4.3 サンプルを集める手順の高い平らな記述… 7 4.4議論… 8 4.5 追加方法論局面… 9 4.6の誤りと不明確なこと… 9 4.7 報告します… 13 5. 周期的な標本抽出についての追加議論… 14 5.1 測定アプリケーション… 15 1個のサンプルから計算できる5.2の統計… 18 複数のサンプルから計算できる5.3の統計… 18 5.4 バックグラウンド状態… 19 5.5の問題が遅れに関連しました… 19 6. セキュリティ問題… 19 6.1サービス妨害は攻撃されます… 19 6.2 ユーザデータの機密性… 20 メートル法の6.3干渉… 20 7. IANA問題… 20 8. 標準の参照… 20 9. 有益な参照… 21 10. 承認… 21 11. 作者のアドレス… 22 12. 完全な著作権宣言文… 23
1. Conventions used in this document
1. 本書では使用されるコンベンション
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.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。 RFC2119は念頭にプロトコルで書かれましたが、キーワードは本書では同様の理由に使用されます。 それらは、2つの異なった実現からの測定値の結果が匹敵しているのを保証して、実現がネットワークを混乱させることができた例に注意するのに使用されます。
Raisanen, et al. Standards Track [Page 2] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[2ページ]RFC3432Network性能測定2002年11月
2. Introduction
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の上のマルチメディア会議などの対話的な周期的な流れのServiceのQualityでしたが、周期的な標本抽出と測定の考えには、より広い適用性があります。 インタラクティブ・マルチメディア交通は、概念を例証するのに以下の例として使用されます。
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.
以下のセクションでは、サンプリング法と測定基準は周期的な流れのために提示されます。測定結果は平均して最大の遅れなどの派生している測定基準に使用されるかもしれません。 メモは、独立している実現の間の同様の結果を獲得するために周期的な流れの測定を正式にしようとします。
2.1 Motivation
2.1 動機
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枠組みのRFC2330[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.
* 多くのネットワーク損傷(例えば、遅れ変化、連続した損失、再命令)の測定値はサンプリング周波数に機密です。 損傷自体が時変しているとき(変化は、いくらかまれであって、しかし、重要です)、一定のサンプリング周波数は分析を簡素化します。
Raisanen, et al. Standards Track [Page 3] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[3ページ]RFC3432Network性能測定2002年11月
* Frequency Domain analysis is simplified when the samples are
equally spaced.
* サンプルが等しく区切られるとき、頻度Domain分析は簡易型です。
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流れのシミュレーションはネットワーク性能の濃い標本抽出を奨励します、典型的なマルチメディア流れが各2番目に10〜100のパケットを持っているので。 濃い標本抽出は短期間でネットワーク現象の特殊化を可能にします。
3. Periodic Sampling Methodology
3. 周期的なサンプリング法
The Framework RFC [3] points out the following potential problems with Periodic Sampling:
Framework RFC[3]はPeriodic Samplingの以下の潜在的な問題を指摘します:
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).
ポアソン標本抽出は様々なIP性能測定基準のための不遍のサンプルを作り出しますが、状況が代替の標本抽出方法が有利である(Motivationの下で議論するように)ところにあります。
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(相互パケット間隔の名目上の持続時間)は最初に、最初のビットまで噛み付きました。
Raisanen, et al. Standards Track [Page 4] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[4ページ]RFC3432Network性能測定2002年11月
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.
パケットサイズのミックスが望まれているとき、受け身の測定値には、通常、実際の使用でのサイズの系列と統計があります、アクティブな測定値は、サイズの意図している分配を再生させる必要があるでしょうが。
4. Sample metrics for periodic streams
4. 周期的な流れのためのサンプル測定基準
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]に提示されたメートル法のType-P片道遅れポアソンの流れがここにサンプルと同様の状態であります。 [3]と[4]で定義された単独個体はここで適切です。
4.1 Metric name
4.1 メートル法の名前
Type-P-One-way-Delay-Periodic-Stream
タイプのP片道遅れ周期的な流れ
4.2 Metric parameters
4.2 メートル法のパラメタ
4.2.1 Global metric parameters
4.2.1 グローバルなメートル法のパラメタ
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アドレス、IPバージョン(IPv4/IPv6)は測定に+ dTlossを使用しました、時間間隔、それが損をしたと宣言する前のパケットのための最大の待ち時間。 + パケットサイズp(j)、バイトの必要な数はjがType-Pパケットサイズであるところで索引をつけます。
Optional parameters:
+ PktType, any additional qualifiers (transport address)
+ Tcons, a time interval for consolidating parameters collected at
the measurement points.
任意のパラメタ: + PktType、+ どんな追加資格を与える人(輸送アドレス)Tcons、測定ポイントに集められたパラメタを統合するための時間間隔。
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)のパケットを使用するかもしれません。 特に混雑の場合では、周期的な流れのパケットの最大の、または、支配的なサイズより小さいパケットを使用するのは役に立つかもしれません。
Raisanen, et al. Standards Track [Page 5] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[5ページ]RFC3432Network性能測定2002年11月
A topology where Src and Dst are separate from the measurement points is assumed.
SrcとDstが測定ポイントから別々であるトポロジーは想定されます。
4.2.2 Parameters collected at the measurement point MP(Src)
4.2.2 測定ポイントMPに集められたパラメタ(Src)
Parameters that each Singleton usually includes:
+ Tstamp(Src)[i], for each packet [i], the time of the packet as
measured at MP(Src)
通常、各シングルトンが含んでいるパラメタ: + 各パケット[i]、MPの測定されるとしてのパケットの時間のTstamp(Src)[i](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.
追加パラメタ: + 各パケット[i]、ユニークな識別または一連番号のためのPktID(Src)[i]。 + 各パケット[i]、実際のパケットサイズのためのPktSi(Src)[i]。
Some applications may use packets of different sizes, either because of application requirements or in response to IP performance experienced.
いくつかのアプリケーションがアプリケーション要件か経験されたIP性能に対応して異なったサイズのパケットを使用するかもしれません。
4.2.3 Parameters collected at the measurement point MP(Dst)
4.2.3 測定ポイントMPに集められたパラメタ(Dst)
+ 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.
+ 各パケット[i]、MP(Dst)+PktID(Dst)[i]で測定される各パケット[i]、ユニークな識別または一連番号のためのパケットの時間のTstamp(Dst)[i]。 + 各パケット[i]、実際のパケットサイズのためのPktSi(Dst)[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(時間間隔)は以前はよくサンプル+PktStatus[i]のために測定基準を集めるのをいつ止めるかを決定する時間Tfに加えていました、各パケット[i]のために受けました。 可能な状態はOK、パケットのヘッダーの不正で、パケットペイロード改悪された写しを含んで、断片化してください。 使用されるなら、状態を決定する評価基準を指定しなければなりません。
4.2.4 Sample Metrics resulting from combining parameters at MP(Src)
and MP(Dst)
4.2.4 MP(Src)とMPにおけるパラメタを結合するので、Metricsの結果になることを抽出してください。(Dst)
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]
Tstamp(Dst)+ 各パケット[i]、時間間隔Delay[i]の間の遅れ[i]=[i]--Tstamp(Src)[i]
Raisanen, et al. Standards Track [Page 6] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[6ページ]RFC3432Network性能測定2002年11月
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.
偽り: Notが得たTstamp(Src)[i]時間が全くないでしょう: どんなTstamp(Dst)の[i]の不正なパケットのヘッダーもいないでしょう: Tstamp(Dst)[i]写しが全くないでしょう: Dstに受け取られたパケットの最初の非不正なコピーだけで、Delay[i]を計算するはずです。
A sample metric for average delay is as follows
平均した遅れにおける、メートル法のサンプルは以下の通りです。
AveDelay = (1/N)Sum(from i=1 to N, Delay[i])
AveDelayは(1/N)合計と等しいです。(i=1からN、Delay[i])
assuming all packets i= 1 through N have valid singletons.
1〜すべてのパケットがiであると仮定する=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
+ 最初のもの以外の各パケット[i]、連続したパケットの間の変化が計算される遅れIPDV[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[])
RangeIPDV=が最大限にする、(IPDV[])--、分(IPDV[])
4.3 High level description of the procedure to collect a sample
4.3 サンプルを集める手順の高い平らな記述
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).
最初のビットのincTの連続したパケットの間には、名目上の間隔がある状態で時間Tfに達するまで、Type-PパケットをSrcを発生させて、T0か時間T0の後からDstに送ります、MP(Src)で測定されるように。incTは多くの理由のために名目上であるかもしれません: Srcのパケット世代、時計問題(セクション4.6を見る)などの変化 (Src)がパケットだけにおける、タイムスタンプによる上記のパラメタを記録するMPとT0とTfを含んでいること必要なSrc、Dst、およびいかなる他の資格を与える人もいる。 また、T0と(Tf+dTstop)の間には、タイムスタンプがある状態で、MP(Dst)はパケットのために記録します。
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.
任意に、a時間Tf+Tcons(結局しかし、すべてがケースに入れるコネ)のときに、MP(Src)とMP(Dst)からのデータは、サンプルのメートル法の結果を引き出すために統合されます。 dTconsは、あまりに早くデータ収集を止めるのを防ぐためには、そう以上であるべきです。dTstop。 逆に、dTstopはかなり効率的にデータ収集を保管するためには、いくつかの妥当な時間間隔であるべきです(/一時間の秒/分)、dTlossが無限である、または非常に長くても。
Raisanen, et al. Standards Track [Page 7] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[7ページ]RFC3432Network性能測定2002年11月
4.4 Discussion
4.4 議論
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.
Type-Pの片道遅れ周期的な流れにおけるメートル法のサンプルを集めるとき考慮に入れられるべきである多くの要因があります。
+ 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).
Tfへの+ 間隔T0はテストでアプリケーションの合理的な使用を表すために十分長い時間間隔を覆うために指定されるべきです、同じ文脈でまだ過度に長くはありません(例えば電話はしかし、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のイングレスポート、または介入しているネットワークの容量の容量を超えている同等なビット伝送速度を定義するはずがありません、知られているなら。 転送ネットワークで状態を積みすぎるためにアプリケーションの応答をテストする例外的なケースがあるかもしれませんが、これらのケースは厳密に制御されるべきです。
+ 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.
+ 測定トポロジーによる遅れ値は10msecへの100usecと同じくらい低いかもしれません。(SrcとDstが非常に密接に連動するのは、msecで重要であるかもしれません)。 GPSシステムはusecのいくつかの10年代に同期を達成する1つの方法を提供します。 これはエージェントが使用したNTPの中で遅れの特性の安定性と対称によります、そして、NTPの普通のアプリケーションは数個のmsecに同期を許容するかもしれませんが、この遅れは私たちが測定しようとしているものです。
+ 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データ・パケットは失われるほうがよいです。}
Raisanen, et al. Standards Track [Page 8] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[8ページ]RFC3432Network性能測定2002年11月
4.5 Additional Methodology Aspects
4.5 追加方法論局面
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).
他のType-P-*測定基準の場合、詳細な方法論はType-Pによるでしょう(例えば、プロトコル番号、UDP/TCPが数を移植します、サイズ、先行)。
4.6 Errors and uncertainties
4.6 誤りと不明確なこと
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:
どんな特定の測定方法の記述も誤りか不確実性の様々な源の会計学と分析を含むべきです。 Framework 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'.
+ 'ワイヤ時間'と'ホスト時間'の違いによる誤りか不明確なこと。
4.6.1. Errors or uncertainties related to Clocks
4.6.1. Clocksに関連する誤りか不明確なこと
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)の時計の不明確なことに一部関係づけられます。 以下では、私たちはMP(Src)が時間を計って、私たちがMP(Dst)が時間を計るときパケットがいつMP(Dst)に受け取られたかを測定するのに使用される時計について言及するときパケットがいつMP(Src)で測定されたかを測定するのに使用される時計について言及します。 同期、精度、解決、および斜行の概念について暗示して、私たちは以下に注意します:
+ 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(Dst)時計にはTsynchの同期誤りがMP(Src)時計がMP(Dst)時計の前のTsynchであるならあると言います。 したがって、まさにTsynchの値を知っているなら、私たちは時計のためにTstamp(Dst)[i]の非修正の値にTsynchを加えることによって、同期を修正するかもしれません--Tstamp(Src)[i]。
+ 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)時計に10msecの解決があるなら、これはそれで測定されたどんな時間的価値にも不確実性の10msecを加えます。 私たちはResMP(Src)とResMP(Dst)としてそれぞれソース時計とMP(Dst)時計の解決を指示するつもりです。
Raisanen, et al. Standards Track [Page 9] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[9ページ]RFC3432Network性能測定2002年11月
+ 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]に注意します--Tsynch(t)+/-(ResMP(SRc)+ResMP(Dst))でTstamp(Src)[i]はオフになるでしょう。 Esynch(t)の概念を使用して、私たちは、これらの時計関連の問題がEsynch(t)+Rsource+Rdestの総不確実性を導入することに注意します。 総時計関連の不確実性のこの見積りはどんな測定実現の誤り/不確実性分析にも含まれるべきです。
4.6.2. Errors or uncertainties related to wire time vs host time
4.6.2. ワイヤ時間対ホスト時間まで関係づけられた誤りか不明確なこと
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".
それがパケットが測定され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.
正確にワイヤ時間とホスト時間の違いを知っていて、ワイヤのために時間測定値を修正するのにこの知識を使用できるという範囲に。 直っている値が、より正確にメートル法で必要を見積もっている、(ホスト時間)そして、その逆も又同様。
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.
しかしながら、範囲に、与えられた測定方法の分析でワイヤ時間とホスト時間の違いが不確実であり、これが不確実性であることを説明しなければなりません。 私たちは、Srcホストの上で不確実性でHsourceでMP(Src)のワイヤ時間とホスト時間の違いで上限を指示して、Dstホストのホスト時間とMP(Dst)のワイヤ時間の違いのために同様にHdestを定義します。 そして、私たちは、これらの問題がHsource+Hdestの総不確実性を導入することに注意します。 総ワイヤホストの不確実性のこの見積りはどんな測定実現の誤り/不確実性分析にも含まれるべきです。
Raisanen, et al. Standards Track [Page 10] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[10ページ]RFC3432Network性能測定2002年11月
4.6.3. Calibration
4.6.3. 較正
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.}
較正の目標は器具自体でできるだけ多くの詳細に発生する系統的で無作為の誤りを決定することです。 最小限では、バウンド(「e」)が見つけられるべきであるので、(真の値+e)には報告された値が範囲(真の値--e)に少なくとも95パーセントの割合であります。 私たちは、「e」を測定値のための校正誤差と呼びます。 それは測定器具によって生産された値が反復可能である程度を表します。 すなわち、30msの実際の遅れは30原稿としてどれくらい密接に報告されますか。コメントしてください: 95パーセントはどんな物理的性質も測定する際に見つけられる(1) 何らかの信頼水準がアウトライアーを取り除くことができるのにおいて望ましいので簡潔にまとめられた[4]で議論した理由のため選ばれました; (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
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
例えば、時計関連の不明確なことはGPS時間ソースの使用で大いに減少します。 Esynch(t)+ResMP(Src)+ResMP(Dst)の合計も、小さく、測定の持続時間において、また、グローバルな時間ソースのために境界があります。 ホスト関連の不明確なこと(Hsource+Hdest)を制限できました。
Raisanen, et al. Standards Track [Page 11] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[11ページ]RFC3432Network性能測定2002年11月
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.
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つの方法は何回も実験を繰り返すことです--少なくとも何百ものテスト。 そして系統誤差はメディアンでしょう。 そして、測定値から系統誤差を取り除くことによって、無作為の誤りを見つけることができるでしょう。 2.5番目の百分順位から真の値からのこれらの逸脱の97.5番目の百分順位まで95%の信頼区間は範囲でしょう。 そして、これらの2つの番号の最も大きい絶対値と、時計関連の不確実性になるように校正誤差「e」を取ることができました。 {コメント: 説明されるように、不明確なことが加えられるので、このバウンドは比較的ゆるいです、そして、最も大きい逸脱の絶対値は使用されています。 結果として起こる値が測定値の重要な部分でない限り、それは合理的なバウンドです。 結果として起こる値が測定値の重要な部分であるなら、より正確な方法が、校正誤差を計算するのに必要でしょう。}
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個の器具によって測定されるなら、これは中断、過程スケジューリング、およびディスク入出力(例えば、測定値を記録する)を増加させるかもしれません。そのすべてが測定単独個体における無作為の誤りを増加させるかもしれません。 したがって、系統誤差を見つける最小量の負荷測定値に加えて、較正測定は器具がその分野で見るのと同じ測定負荷で実行されるべきです。
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.
この統計的な処理が器具の較正について言及するのを繰り返したいと思います。 それは、「メーター棒を較正し」て、メーター棒が現実をどれくらいよく反映するかを言うのに使用されます。
4.6.4 Errors in incT
4.6.4 incTの誤り
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
パケットの名目上の間隔(incT)はアクティブであるか受け身の測定値の間、異なることができます。 受け身の測定では、パケットのヘッダーはプロトコル・スタックの大部分前で適用されたタイムスタンプを入れるかもしれません、そして、実際の送付時間はプロセッサスケジューリングのため異なるかもしれません。 例えば、H.323システムが、彼らの理想的な時間の5msの中でパケットをネットワークスタックの準備ができるようにするのに必要です。 そしてSrcの間には、ネットワークからの追加変化があるかもしれない。
Raisanen, et al. Standards Track [Page 12] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[12ページ]RFC3432Network性能測定2002年11月
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.
MP(Src。) 同様の誤りに遭遇しますが、アクティブな測定システムは、より少ない程度までそうするかもしれません。 何人かのタイプの分析でこれらの誤りを説明しなければなりません。
4.7 Reporting
4.7 報告
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.
慎重に、方法が使用されている較正と文脈を考えなければならない、SHOULD、メートル法の結果と共にいつも報告されてください。 私たち、考える次の現在の5つの項目: テストパケット(サンプルの間、損失、誤り較正、テストパケットによって横断された経路、Srcの背景条件、Dst、および介入しているネットワークに同等な遅れの敷居)のType-P。 このリストは徹底的ではありません。 また、どんな測定基準の応用を解釈する際に役に立つかもしれない追加情報も報告されるべきです。
4.7.1. Type-P
4.7.1. Pをタイプします。
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.
Frameworkドキュメント[3]に述べられるように、aメートル法の値は測定をするのに使用されるIPパケット、または「タイプP」のタイプに頼るかもしれません。 Type-Pの片道周期的な遅れの値は、特別な処理のためのプロトコル(UDPかTCP)、ポートナンバー、サイズ、またはアレンジメント(例えば、IP先行かRSVP)が変化するかどうかを変えるかもしれません。 測定をするのに使用される正確なType-Pを報告しなければなりません。
4.7.2. Threshold for delay equivalent to loss
4.7.2. 損失に同等な遅れのための敷居
In addition, the threshold for delay equivalent to loss (or methodology to determine this threshold) MUST be reported.
さらに、損失(または、この敷居を決定する方法論)に同等な遅れのための敷居を報告しなければなりません。
4.7.3. Calibration results
4.7.3. 較正結果
+ 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.
+は系統誤差であるなら断固とする場合があって、それはSHOULDです。測定値から、取り除きます。 + あなた、また、SHOULDは校正誤差を報告します、e、真の値が報告された値のプラスかマイナスeであるように、95%の自信をもって(最後のセクションを見てください。) + できれば有限であるのがあるテストパケットが延着する状態はそうです。測定器具SHOULDにおけるリソース疲労困憊のため失われているように報告されて、報告されてください。
4.7.4. Path
4.7.4. 経路
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
経路はパケットでSHOULDを横断しました。可能であるなら、報告されてください。 一般に、与えられたパケットがネットワークを通して取る正確な経路を知るのは非実用的です。 正確な経路はあるType-Pパケットで短いか安定した経路で知られているかもしれません。 そしてType-Pが記録を含んでいるならIPヘッダーでオプションを発送してください、(または、ゆるい送信元経路)。
Raisanen, et al. Standards Track [Page 13] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[13ページ]RFC3432Network性能測定2002年11月
path is short enough, and all routers on the path support record (or loose-source) route, then the path will be precisely recorded.
経路は十分短いです、そして、経路のすべてのルータが記録的で(自由なソース)のルートを支えます、そして、次に、経路は正確に記録されるでしょう。
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個のリンクを選ぶことができるなら(したがって、2はSrcからDstまでルートを切り離します)、使用される初期のリンクは貴重な文脈です。 例えば、1つの商業セットアップ(1のNAPがいくつかの異なった背骨ネットワークについて別のNAPの上のDstに達することができるSrc)で以下について論評してください。
5. Additional discussion on periodic sampling
5. 周期的な標本抽出についての追加議論
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.
Fig.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).
+ 無くなっているパケット: アプリケーションは無くなっているパケットに異なった寛容を持っているかもしれません。 別の考慮は無くなっているパケット(すなわち、無作為の、または、burstyな)の分配です。
Raisanen, et al. Standards Track [Page 14] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[14ページ]RFC3432Network性能測定2002年11月
+ 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.
+ 長時間の遅延: 多くのアプリケーションが、ある値より長い間遅れたパケットが無くなっているパケット(すなわち、リアルタイムのアプリケーション)に相当していると考えるでしょう。 + 写しパケット: 写しパケットが受け取られているなら、いくつかのアプリケーションが混乱させられるかもしれません。 + Reordering: パケットが順序が狂って到着するなら、いくつかのアプリケーションが混乱させられるかもしれません。 これは系列から脱していることの結果、「長い」遅れ敷居を超えている可能性に加えているかもしれません。 + 不正なパケットのヘッダー: ほとんどのアプリケーションがたぶん無くなっているパケットに同じくらい同等な不正なヘッダーと共にパケットを扱うでしょう。 + 不正なパケットペイロード: いくつかのアプリケーション(例えば、デジタル音声コーデック)が不正なパケットペイロードを受け入れるかもしれません。 いくつかの場合、パケットペイロードは何らかのレベルの不正を補うことができるアプリケーションの特定の前進型誤信号訂正(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、そして/または、中間ネットワークのために区別を保存するのは重要であるかもしれません。
5.1 Measurement applications
5.1 測定アプリケーション
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.
国際Telecommunications Union(ITU)の中でIPデリバリ・サービス測定値について議論しました。 IPサービスのための枠組みは測定値を平らにします。(枠組みのサービスに適していることを意図するIP性能[3])の参照で、計画はI.380[7]として承認されました。 ITU-T Recommendation I.380は性能測定基準の抽象的な定義をカバーしています。 このメモは役に立つ方法を説明します、サービス計画とエンドユーザテスト目的のために、アクティブなものと同様に受け身の測定値で。
Raisanen, et al. Standards Track [Page 15] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[15ページ]RFC3432Network性能測定2002年11月
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]であるかもしれない。 それに従って、測定は連動するかunsynchronized Src/Dstホスト時計で実行されるかもしれません。 異なった可能性は以下に記載されています。
The reference measurement setup for all measurement types is shown in Fig. 2.
すべての測定タイプのための基準測定セットアップは図2に示されます。
----------------< IP >--------------------
| | | |
------- ------- -------- --------
| Src | | MP | | MP | | Dst |
------- |(Src)| |(Dst) | --------
------- --------
----------------<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.
方法の使用に関する例は送信元ホスト(Src)あて先ホスト(Dst)と図2で見せられる対応する測定ポイント(MP(Src)とMP(Dst))があるセットアップです。 Src、そして/または、Dstに測定を行わせるなら測定ポイントが使用されるかもしれないので、別々の設備は測定されるべき遅れ性能にかなり影響するかもしれません。 MP(Src)は、パケットの出口ポイントの近くでSrcから置かれるべきであるか、または測定されるべきです。 MP(Dst)はDstのためのパケットのイングレスポイントの近くの置かれた/測定であるべきです。 「閉鎖」は、特性が測定したアプリケーションレベル性能(遅れなどの)がSrcとDstの間の対応する性能の特性に適切な精度に続くと予想できるように十分小さく距離と定義されます。 MP(Src)とMP(Dst)の間の測定結果がSrcとDstの間の測定のように同じであるべきであるという基本原理がここにあります、測定の一般的なエラーマージン目標の中で(例えば、<1ms; 無くなっているパケットの数は同じです)。 これが可能でないなら、望ましくは、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)の間の中間的測定ポイントを持っているのも可能ですが、それはこのドキュメントの範囲を超えています。
Raisanen, et al. Standards Track [Page 16] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[16ページ]RFC3432Network性能測定2002年11月
5.1.1 One way measurement
5.1.1 一方通行の測定
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.
一般に、できるだけ適切な測定基準を指定することのために、アプリケーションレベル測定値は遅れが例の測定基準に使用される1つの方法を基礎づけました。 以下で対話的なマルチメディア会議などの双方向のアプリケーションのためのアプリケーションレベル測定の含意について議論します。
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.
ただ一つの片道測定を実行すると、ネットワークの振舞いの情報は一方向にもたらされるだけです。 そのうえ、ネットワーク輸送レベルにおける流れは正確に全二重マルチメディア接続を見習いません。
5.1.2 Paired one way measurement
5.1.2 対にされた一方通行の測定
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.
対にされた一方通行の遅れは2つのマルチメディアの流れについて言及します: 同じSrcとDstのためのDstへのSrcとSrcへのDst。 いくつかのアプリケーション、経路が周遊旅行遅れより重要であるそれぞれ方法の遅れ性能のための例として。 これはVoIPなどの遅れの限られた信号のためのそうです。 片道遅れの違いの可能な理由はSrcからDstまでの流れ対Srcへの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.
例えば、対にされた一方通行の測定は、DstへのSrcには30msの平均した遅れがあるのを示すかもしれなくて、SrcへのDstに120ms. Toの平均した遅れがある間、周遊旅行は測定を遅らせて、この例は平均に150ms遅れのように見えるでしょう。 非対称に関する知識がなければ、私たちは100ms.以上を平均することにおけるどちらかの終わりのアプリケーションが遅れで持っているかもしれない問題を逃すかもしれません。
Moreover, paired one way delay measurement emulates a full-duplex VoIP call more accurately than a single one-way measurement only.
そのうえ、対にされた一方通行の遅れ測定はただ一つの片道測定だけより正確に全二重VoIP呼び出しを見習います。
5.1.3 Round trip measurement
5.1.3 周遊旅行測定
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
往復の測定の下落傾向はパケット損失の片道テストと、より複雑な会計より多くの帯域幅の必要性です。 そのうえ、元の送り主に向かって戻る予定である小川は1日のものが「急いで歩く」より多くのburstyであるかもしれません。
Raisanen, et al. Standards Track [Page 17] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[17ページ]RFC3432Network性能測定2002年11月
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.
適当なアレンジメントでそれに注意してください、そして、往復の測定は、対にされた一方通行の測定を使用することで実行されてもよいです。
5.2 Statistics calculable from one sample
5.2 1個のサンプルから計算できる統計
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):
例えば、aのサンプルメートル法、以下の測定値が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
+ ms+8つのパケットが最初の項目にみられるように+ 3つのパケットが正しく受け取られた80のパケットの1つをコピーする不正なパケットペイロードと遅れ[i]<=20ms+2つのパケットで受けたMP(Dst)(事実上、失われている)に記録されない合っているパケットで全くMP(Src)から不正なパケットのヘッダー+4つのパケットで遅れ[i]>20ms+5つのパケットを受け取っていて受け取った遅れ[i]<=20で受け取られた80のパケット
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%.
この例に関しては、20msより遅れと不正なパケットのヘッダーもパケットペイロードなしでそれらを受け取るなら、許容できるとパケットを考えます。 この場合、許容できるパケットの割合は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%です。
5.3 Statistics calculable from multiple samples
5.3 複数のサンプルから計算できる統計
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
「サンプルのサンプル」を集めるこの方法を使用することで複数のテストを走らせるのにおいて値があるかもしれません。 例えば、2,000分間のただ一つの呼び出しよりむしろ1,000の2分のVoIP呼び出しをシミュレートするのはさらに適切であるかもしれません。 サンプル(例えば、数分、何時間も)、サンプルの構成の間で複数のサンプル、間隔のような問題の収集を考える、(例えば、等しいTf-T0持続時間で、異なる。
Raisanen, et al. Standards Track [Page 18] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[18ページ]RFC3432Network性能測定2002年11月
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.
パケットサイズ)、ネットワーク問題(例えば、異なった介入しているリンクホスト組み合わせの上で異なったサンプルを動かす)は考慮に入れられるべきです。 サンプルの間隔のような項目において、興味深いアプリケーションのための用法パターンは考えられるべきです。
When computing statistics for multiple samples, more general statistics (e.g. median, percentile, etc.) may have relevance with a larger number of packets.
複数のサンプルのために統計を計算するとき、より一般的な統計(例えば、メディアン、百分順位など)には、より多くのパケットがある関連性があるかもしれません。
5.4 Background conditions
5.4 バックグラウンド状態
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、そして/または、どんな介入しているネットワークでも状態によって影響を及ぼされるかもしれません。 結果に影響するかもしれない要素は: 交通レベル、そして/または、サンプル、リンク、そして/または、ホスト障害の間の炸裂など 背景条件に関する情報は、単に外部の手段(例えば、電話、テレビ)で利用可能であるかもしれなく、サンプルを取った何日も後に利用可能になるだけであるかもしれません。
5.5 Considerations related to delay
5.5の問題が遅れに関連しました。
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つのアプローチは1ドメインあたりの遅れ割当て(例えば、特定のIPドメインへの50ms)を使用することです。 しかしながら、この計画は、明確な非能率を持って、終わりから終わりへの遅れ何らかの目的を達成するという問題を抑制し過ぎることができます。 よりフレキシブルな実現は経路の非対称の遅れ、およびアプリケーションの感度が与えられたドメインの変化を遅らせる可能性のような問題を記述するべきです。 終わりから終わりへのQoSを管理する際に使用するべきである遅れ統計値に関していくつかの選択肢があります。 この問題について、非常におもしろいのですが、このメモの範囲の中になくて、またここでさらに議論しません。
6. Security Considerations
6. セキュリティ問題
6.1 Denial of Service Attacks
6.1 サービス妨害攻撃
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).
この方法は介入しているネットワークを通してパケットの周期的な1人のホスト(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
Src、Dst、および介入しているネットワークの管理者はサンプル測定基準の収集のタイミング、サイズ、および頻度に関する双方の、または、マルチ側部の協定を確立するべきです。 これの使用
Raisanen, et al. Standards Track [Page 19] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[19ページ]RFC3432Network性能測定2002年11月
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.
関係者の間で同意される諸条件を超えた方法は、即座の拒絶の原因、パケットの破棄、または影響を受けた当事者の間で定義された他の増大手順であるかもしれません。
6.2 User data confidentiality
6.2 ユーザデータの機密性
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.
この方法の能動的使用は、サンプルのために利用者データに基づいて見本を作るよりパケットをむしろ発生させて、ユーザデータの機密性を脅かしません。 受け身の測定は興味があるヘッダーへの注意を制限しなければなりません。 ユーザペイロードが長さの分析のために一時格納されるかもしれないので、この情報を安全で秘密に保つために適当な注意を払わなければなりません。
6.3 Interference with the metric
6.3 メートル法の干渉
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.
前記のように干渉の種類に水をさしているために、暗号の細切れ肉料理などのパケット干渉チェックは使用されるかもしれません。
7. IANA Considerations
7. IANA問題
Since this method and metric do not define a protocol or well-known values, there are no IANA considerations in this memo.
この方法でメートル法であるので、プロトコルを定義しないでください。さもないと、周知の値でありこのメモにはIANA問題が全くありません。
8. Normative References
8. 引用規格
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998.
[3] パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マシス(「IPパフォーマンス測定基準のための枠組み」、RFC2330)は1998がそうするかもしれません。
[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における、メートル法の片道遅れ」、RFC2679、1999年9月。
Raisanen, et al. Standards Track [Page 20] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[20ページ]RFC3432Network性能測定2002年11月
[5] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, November
2002.
[5] デミチェリスとC.とP.Chimento、「IPパフォーマンス測定基準(IPPM)における、メートル法のIPパケット遅れ変化」、RFC3393、2002年11月。
9. Informative References
9. 有益な参照
[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システムのServiceの終わりから終わりへのQuality」。 パート5: 「Service(QoS)測定方法論の品質」、ETSI TS101 329-5V1.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]の国際Telecommunications Union、「インターネットプロトコルデータ通信サービス_IPパケット転送と有用性性能パラメタ」、Telecommunications Sector Recommendation 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における、メートル法の往復の遅れ」、RFC2681、1999年9月。
10. Acknowledgments
10. 承認
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(マットZekauskasとMerike Kaeo)のいすに感謝したがっています。 また、ハワードStanislevicとウィル・リーランドは役に立つコメントと質問を提示しました。 また、私たちは感謝してこの方法に関する動機を育むヘンクUijterwaalの継続的な挑戦を承諾します。 作者はIP性能[3]のために枠組みの作者によって築かれたかなりの基礎に建てました。
Raisanen, et al. Standards Track [Page 21] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[21ページ]RFC3432Network性能測定2002年11月
11. Author's Addresses
11. 作者のアドレス
Vilho Raisanen Nokia Networks P.O. Box 300 FIN-00045 Nokia Group Finland
Vilho Raisanenノキアは私書箱300フィン-00045Nokia Groupフィンランドをネットワークでつなぎます。
Phone: +358 7180 8000 Fax: +358 9 4376 6852 EMail: Vilho.Raisanen@nokia.com
以下に電話をしてください。 +358 7180 8000、Fax: +358 9 4376 6852はメールされます: Vilho.Raisanen@nokia.com
Glenn Grotefeld Motorola, Inc. 1501 W. Shure Drive, MS 2F1 Arlington Heights, IL 60004 USA
グレンGrotefeldモトローラ1501W.シュアーのドライブ、2F1アーリントンハイツ、MS IL60004米国
Phone: +1 847 435-0730 Fax: +1 847 632-6800 EMail: g.grotefeld@motorola.com
以下に電話をしてください。 +1 847 435-0730Fax: +1 847 632-6800 メールしてください: g.grotefeld@motorola.com
Al Morton AT&T Labs Room D3 - 3C06 200 Laurel Ave. South Middletown, NJ 07748 USA
アルモートンAT&T研究室Room D3--3C06 200ローレルAve。 南ミドルタウン、ニュージャージー07748米国
Phone: +1 732 420 1571 Fax: +1 732 368 1192 EMail: acmorton@att.com
以下に電話をしてください。 +1 732 420、1571Fax: +1 1192年の732 368メール: acmorton@att.com
Raisanen, et al. Standards Track [Page 22] RFC 3432 Network performance measurement November 2002
Raisanen、他 規格Track[22ページ]RFC3432Network性能測定2002年11月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Raisanen, et al. Standards Track [Page 23]
Raisanen、他 標準化過程[23ページ]
一覧
スポンサーリンク
