この文書はRFC3432の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
※：どう訳していいのかわからない言葉が多すぎるので、 この翻訳の出来はかなり悪くなりました。可能であれば翻訳しなおして下さい。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (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.
このメモはＩＰネットワークの能力を算定するための、周期的サンプリング
方法と適切な範囲を記述します。最初に、メモは周期的サンプリングの動機
を与え、そしてＲＦＣ２３３０で記述された毒サンプリングの選択肢として
その値の問題を扱います。具体的には、積極的測定と受動的な測定の適用性
と、定ビット率（ＣＢＲ）トラヒック（マルチメディアでの典型、または音
声活性発見で見つかるほとんどＣＢＲ）のシュミレーションと、いくつかの
解析が単純化される例を含みます。サンプリング方法はランダム開始と有限
長テストを必須にすることで予測可能性を避けます。サンプリング方法とサ
ンプル範囲パラメータの記述に続いて、測定方法とエラーが論じられます。
最終的に、我々は、セキュリティの考慮を含めて、周期的な測定についての
追加情報を与えます。
Table of Contents
目次
1. Conventions used in this document
1. この文書で使われる取り決め
2. Introduction
2. はじめに
2.1 Motivation
2.1 動機
3. Periodic Sampling Methodology
3. 周期的なサンプリング方法論
4. Sample metrics for periodic streams
4. 周期的な流れのサンプル測定
4.1 Metric name
4.1 測定名
4.2 Metric parameters
4.2 測定パラメータ
4.3 High level description of the procedure to collect a sample
4.3 サンプルを集めるための手順のレベルが高い記述
4.4 Discussion
4.4 議論
4.5 Additional Methodology Aspects
4.5 追加方法面
4.6 Errors and uncertainties
4.6 エラーと不確定
4.7 Reporting
4.7 報告
5. Additional discussion on periodic sampling
5. 周期的なサンプリングについての追加の論議
5.1 Measurement applications
5.1 測定アプリケーション
5.2 Statistics calculable from one sample
5.2 １つのサンプルからの計算可能な統計値
5.3 Statistics calculable from multiple samples
5.3 多数のサンプルからの計算できる統計値
5.4 Background conditions
5.4 背景状態
5.5 Considerations related to delay
5.5 遅延と関係がある考慮
6. Security Considerations
6. セキュリティの考慮
6.1 Denial of Service Attacks
6.1 サービス妨害攻撃
6.2 User data confidentiality
6.2 ユーザーデータ機密性
6.3 Interference with the metric
6.3 インターフェースの測定量
7. IANA Considerations
7. ＩＡＮＡの考慮
8. Normative References
8. 参照する参考文献
9. Informative References
9. 有益な参考文献
10. Acknowledgments
10. 謝辞
11. Author's Addresses
11. 著者のアドレス
12. Full Copyright Statement
12 著作権表示全文
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"と"MUST NOT"と"REQUIRED"と"SHALL"と
"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"
は、ＢＣＰ１４、ＲＦＣ２１１９[2]で記述されたように解釈されるはずです。
ＲＦＣ２１１９がプロトコルを念頭に書かれたけれども、この文書でキーワー
ドが類似の理由で使われます。これらは２つの異なった実行からの測定結果
が類似であることを保証し、そして実行がネットワークを不安にさせる例に
注意するために使われます。
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.
このメモはＩＰネットワークのある特定のアプリケーションに関係があるサ
ンプリング方法と能力測定を記述します。この仕事を最初に動かしたのは、
ＩＰの上のマルチメディアの会議のような、対話型の周期的な流れのサービ
スの品質でした、しかし周期的サンプリングと測定のアイデアはより広い適
用性を持っています。対話型マルチメディアのトラフィックが考えをを示す
ために以下で例として用いられます。
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).
ネットワークを通して一定間隔で同じサイズのパケット（あるいはたいてい
同じサイズのパケット）を伝達することは一定のビット率（ＣＢＲ）を擬似
するか、あるいはほとんどＣＢＲマルチメディアビットストリームです。今
後、これらのパケットは周期的な流れと呼ばれます。「たいてい同じサイズ
のパケット」の場合は、多数のコーディング方法を持つアプリケーションで
見いだされるかもしれません（例えば音声で無音区間はデジタルコード化さ
れた快適ノイズ）。
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.
ＩＰＰＭフレームワークＲＦＣ２３３０[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.
周期的な流れを持っているＣＢＲ流の擬似が、典型的なマルチメディアの流
れが毎秒１０から１００のパケットを持つので、ネットワーク性能の密集サ
ンプリングを奨励します。密集サンプリングが短い持続時間でネットワーク
現象の性格付けを認めます。
3. Periodic Sampling Methodology
3. 周期的なサンプリング方法論
The Framework RFC [3] points out the following potential problems
with Periodic Sampling:
フレームワークＲＦＣ[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).
毒サンプリングが種々なＩＰパフォーマンス測定のために公平なサンプルを
作り出しますが、それでもなお代わりのサンプリング方法が有利である状態
があります（以下の動機で議論）。
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.
+ T, 周期的なサンプルが望まれる最初の時間間隔。
+ dT, the duration of the interval for allowed sample start times.
+ dT, サンプルスタート時に許された間隔の期間。
+ T0, a time that MUST be selected at random from the interval
[T, T+dT] to start generating packets and taking measurements.
+ T0, 区間[T, T+dT]からランダムに選択した(MUST)時間で、パケットを生
成し測定を開始する。
+ Tf, a time, greater than T0, for stopping generation of packets
for a sample (Tf may be relative to T0 if desired).
+ Tf, T0より大きい時間で、サンプルパケットの生成を止める時間（もし望
むなら、Tfが、T0に関連するかもしれません）。
+ incT, the nominal duration of inter-packet interval, first bit to
first bit.
+ 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)から引き出されるかもしれませ
ん。他の分布が適切かもしれません。連続時間間隔の開始時間は分布から引
き出された独立な値を使わなくてはなりません(MUST)。受動的測定で、ユー
ザーメディアの流れの到着は十分な乱雑さを持っているかもしれません、あ
るいは流れの測定のランダム開始がこの必要条件を満たすために必要かもし
れません。
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.
ここで提出されたサンプル測定は、ＲＦＣ２６７９[4]の
Type-P-One-way-Delay-Poisson-Streamサンプル測定に類似しています。
[3]と[4]で定義された単独はここで適用可能です。
4.1 Metric name
4.1 測定名
Type-P-One-way-Delay-Periodic-Stream
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).
これらのパラメータは次の章（４.２.２と４.２.３と４.２.４）に当てはま
ります。
Parameters that each Singleton usually includes:
それぞれの単体が通常含むパラメータ：
+ Src, the IP address of a host
+ Src, ホストのＩＰアドレス。
+ Dst, the IP address of a host
+ Dst, ホストのＩＰアドレス。
+ IPV, the IP version (IPv4/IPv6) used in the measurement
+ IPV, 測定で使ったＩＰバージョン（ＩＰｖ４／ＩＰｖ６）。
+ dTloss, a time interval, the maximum waiting time for a packet
before declaring it lost.
+ dTloss, 時間間隔、パケット損失と判定する前に待つべき最大時間。
+ packet size p(j), the desired number of bytes in the Type-P
packet, where j is the size index.
+ パケットサイズp(j), タイプＰパケットの望ましいバイト数、ｊがサ
イズインデックス。
Optional parameters:
任意パラメータ：
+ PktType, any additional qualifiers (transport address)
+ PktType, 追加の限定（転送アドレス）。
+ Tcons, a time interval for consolidating parameters collected at
the measurement points.
+ 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)を使うかもしれま
せん。特に輻輳した場合、周期的な流れで、最大あるいは優勢なパケットサ
イズより小さいパケットを使うことは、有利かもしれません。
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)
+ Tstamp(Src)[i], 各パケット［ｉ］に対し、MP(Src)で測られたパケット
の時間。
Additional parameters:
追加パラメータ：
+ PktID(Src) [i], for each packet [i], a unique identification or
sequence number.
+ PktID(Src) [i], 各パケット［ｉ］のための、ユニークな識別子あるいは
シーケンス番号。
+ PktSi(Src) [i], for each packet [i], the actual packet size.
+ PktSi(Src) [i], 各パケット［ｉ］のための、実際のパケットサイズ。
Some applications may use packets of different sizes, either because
of application requirements or in response to IP performance
experienced.
あるアプリケーションが、アプリケーション必要条件やＩＰ性能試験に応じ
て、異なった大きさのパケットを使うかもしれません。
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)
+ Tstamp(Dst)[i], 各パケット［ｉ］について、MP(Dst)で測定された時刻。
+ PktID(Dst) [i], for each packet [i], a unique identification or
sequence number.
+ PktID(Dst) [i], 各パケット［ｉ］について、ユニークな識別子あるいは
シーケンス番号。
+ PktSi(Dst) [i], for each packet [i], the actual packet size.
+ 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
+ dTstop, 時間間隔、いつサンプル測定をやめるか決定するために時刻Tfに
加算するために使用。
+ 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.
＋ PktStatus ［ｉ］, 各パケット［ｉ］について、パケットの受信状態。可
能な状態はＯＫや、不正パケットヘッダや、パケットペイロードの誤りや、
重複や、分割を含みます。もし使用するなら、状態を決定する基準が指定
されなくてはなりません(MUST)。
4.2.4 Sample Metrics resulting from combining parameters at MP(Src)
and MP(Dst)
4.2.4 MP(Src)とMP(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]
For the following conditions, it will not be possible to compute
delay singletons:
次の状態で、遅延単体を計算することは可能ではないでしょう：
Spurious: There will be no Tstamp(Src)[i] time
偽造：Tstamp(Src)[i]時間がない。
Not received: There will be no Tstamp (Dst) [i]
非受信：Tstamp (Dst) [i]がない。
Corrupt packet header: There will be no Tstamp (Dst) [i]
不正パケットヘッダ：Tstamp (Dst) [i]がない。
Duplicate: Only the first non-corrupt copy of the packet
received at Dst should have Delay [i] computed.
重複：Dstが受信した際その最初の不正でないパケットのだけがDelay[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] 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[])
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).
時刻T0に始まり、タイプＰパケットがSrcで生成され、MP(Src)で測定される
ように、incTの連続パケットの最初のビットの名目間隔に達する時刻Tfにま
でに、Dstに送られます。incTは多くの理由のために名目上であるかもしれま
せん：Srcのパケット生成の変化、クロック問題（４.６章参照）、など。
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 + Tcons時に（しかし結局は例外なく）、MP(Src)とMP(Dst) からの
データはサンプル測定結果を得るために統合されます。あまりにも早くデー
タ収集を止めることを避けるために、dTconsはdTstop以上であるべきです。
逆に、データ収集を合理的に効率的にしておくために、 たとえdTlossが無限
かあるいは非常に長いとしても、dTstopが合理的な時間隔（秒／分／時間）
であるべきです。
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.
タイプＰ一方向遅延周期的な流れのサンプル測定量を集める時、考慮に入れ
るべき多くの要因があります。
+ 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の間隔は、テスト下のアプリケーションの合理的使用の表現に十
分長い時間間隔で、同じ状況での過度の期間ではないように、指定すべき
です（例えば電話が１００msより長いが、１週以下です）。
+ 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.
+ 測定トポロジーによって、遅延値は１００マイクロ秒から１０ミリ秒と小
さいかも知れず、これはSrcとDstにとって非常に注意深い同期が重要であ
るかもしれません。ＧＰＳシステムが１０マイクロ秒以内の同期を成しえ
るひとつの方法です。ＮＴＰの通常のアプリケーションが数ミリ秒以内の
同期を許すかもしれませんが、これはＮＴＰエージェントが使う遅延の安
定性と対称性に依存し、この遅延はは我々が測ろうとしているものです。
+ 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
より大きい遅延が損失と解釈される時間間隔を定義します。{コメント：
多くのアプリケーションで、大きい遅延を無限／損失と扱うのは問題ない
でしょう。ＴＣＰデータパケットで、例えば、通常のＲＴＴの数倍以上遅
れて届いたパケットを損失と扱います。｝
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).
他のタイプＰ＊測定量と同じように、詳細な方法はタイプＰに依存するでしょ
う（例えば、プロトコル番号、ＵＤＰ／ＴＣＰポート番号、サイズ、優先）。
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:
特定の測定方法の記述は課金と、エラーや不確定の種々な原因の分析を含む
べきです。枠組みＲＦＣ[3]はこの点について一般的な指導を供給しますが、
我々はここに次の周期的な流れと遅延測定量と関係がある詳細に気付きます：
+ Error due to variation of incT. The reasons for this can be
uneven process scheduling, possibly due to CPU load.
+ incTの変化のためのエラー。これの理由は、多分ＣＰＵ負荷のために、一
定でないプロセススケジューリングによります。
+ 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. 時計と関係があるエラーや不確実
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(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(Dst)時計よりもTsynch進んでいるな
ら、我々はMP(Src)時計とMP(Dst)時計がTsynch同時発生エラーを持つと言
います。それで、もし我々が正確にTsynch値を知っているなら、不正確な
値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)時計が１０ミリ秒の解像度を持つなら、これで測られた時間
値は１０ミリ秒の不確実さがあります。我々は情報源時計の解像度
ResMP(Src)とMP(Dst)時計の解像度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を測定するか範囲を知ろうと試
みるなら、この測定や計算が周期的に繰り返されなくてはなりません。あ
る一定期間で、この関数は線形関数と高位項で近似できます；この場合、
１つの選択が線形要素を時計の修正に使うことです。この訂正を使って、
残りの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の不確実さであることを指摘します。この完全な時計関連の
不確実の見積もりは測定実行のエラー／不確実分析に含められるべきです。
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がテストパケットを受信
した後処理し始めた時の間を、直接はかれます；我々はこの２点を「ホスト
時間」と述べます。
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.
しかしながら、ワイヤ時間とホスト時間の間の差が不確実な程度に、、この
不確実さは所定の測定方法の分析で説明されなくてはなりません。我々は
MP(Src)のワイヤ時間とSrcホスト上のホスト時間の差の不確実さの上限を
Hsourceと言い、同様にDstホストのホスト時間とMP(Dst)のワイヤ時間の差
の不確実さの上限Hdestを定義します。我々はそれからこれらの問題が
Hsource+Hdestの完全な変わりやすさを紹導入することを指摘します。この
完全なワイヤ対ホストの不確実さの見積もりは測定実行のエラー／不確実分
析に含められるべきです。
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.}
目盛りゴールは可能な限り細かい手段で発生した秩序立ったエラーと、ラン
ダムエラーを決定することです。少なくとも、報告値が（本当の値-ｅ）から
（本当の値+ｅ）の範囲に９５％あるような、限界（「ｅ」）が見いだされる
べきです。我々は測定で「ｅ」を目盛りエラーと呼びます。これは測定手段
によって作り出された値が再現可能である程度を表します；すなわち、実際
の遅延３０ミリセカンドが、どれだけ３０ミリセカンドに近い値で報告され
るか。{コメント：[4]で論じた理由で９５％が選択されます、手短かに要約
すると（１）若干の信頼レベルがどんな物理的な特性の測定でも見いだされ
る異常値を取り去ることが可能であるために、望ましいです；（２）独立な
実行結果が比較できるように、特定の信頼レベルが指定されるべきです。｝
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:
前の２つの章の論議で、測定エラーはすべての個別の不確実さを決定する限
界があり、次の形式を取ります：
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.
しかしながら、時計関連の最初の３項の不確実さと後の２項のホスト関連の
不確実さの両方で、合理的な範囲は注意深い設計技術と研究室で周知の、独
立の、ネットワークを使った目盛り手段で可能であるべきです。
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.
例えば、時計関連の不確実さはＧＰＳ時刻源の使用で大いに減少します。
Esynch(t) + ResMP(Src) + ResMP(Dst)の合計は小さく、グローバルな時刻情
報源のため継続的測定でも限度があります。ホスト関連の不確実さ、Hsource
+ Hdest、は２つの装置を裏で高速シリアルリンクや孤立ＬＡＮセグメントで
結ぶことで限度が得られます。この場合、繰り返し測定が同じ一方的遅延を
測ります。
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.}
もしテストパケットが小さいなら、このようなネットワーク接続はゼロに近
い最小遅延を持ちます。従って測定遅延は、器具の秩序立ったエラーとラン
ダムエラーだけを含んでいます。継続測定の「平均値」は秩序立ったエラー
で、変化はランダムエラーです。秩序立ったエラーとランダムエラーを計算
する一つの方法が、９５％信頼で、何度も実験を繰り返す事です−少なくと
も何百のテストで。秩序立ったエラーはその中間値であるでしょう。ランダ
ムエラーは測定値から秩序立ったエラーを取り除くことで見いだされます。
９５％の信頼間隔は、真の値からの偏差の２.５％から９７.５％の範囲であ
るでしょう。目盛りエラー「ｅ」はこれらの２つの数の絶対値の大きいもの
に、時計関連の不確実さを足して得られます。{コメント：記述されるよう
に、この範囲は、不確実が加えられるので、比較的緩く、そして最も大きい
偏差の絶対値が使われます。結果として生じている値が測定値の意味のある
断片ではない限り、それは合理的な範囲です。もし結果として生じている値
が測定値の意味のある断片であるなら、より正確な方法が目盛りエラーを計
算するために必要とされるでしょう。｝
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.
ランダムエラーが測定負荷の関数であることに注意してください。例えば、
もし多くのパスが１つの道具で測られるなら、これは（例えば、測定を記録
している）割り込みや、プロセススケジューリングや、ディスクＩ／Ｏを増
やすかもしれず、そしてそのすべては測定単体でランダムエラーを増やしま
す。従って、秩序立ったエラーを見いだす最小負荷測定のほかに、目盛り測
定がフィールドで発生するのと同じ測定負荷で行われるべきです。
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
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、は能動的と受動的測定で変化します。受動的
測定で、パケットヘッダーがプロトコルスタックの最も前にタイムスタンプ
を含むかもしれず、実際の送信時刻はプロセッサスケジューリングで変化す
るかもしれません。例えば、Ｈ.３２３システムは理想的な時に５ミリセカ
ンドの内にネットワークスタックの準備ができたパケットを持つように要求
されます。Srcと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.
方法が使われる目盛りと文脈は慎重に評価されているに違いなくて(MUST)、
そして常に測定量結果とともに報告されるべきです(SHOULD)。我々は次に考
慮するべき５つの項目を提出します：タイプPテストパケット、損失と等しい
遅延の閾値、エラー目盛り、テストパケットの通る経路、SrcとDstとサンプ
ルの中間ネットワークのの背景条件。このリストは徹底的ではありません；
測定量のアプリケーションを解釈することにおいて有用であり得たどんな追
加の情報でも同じく報告されるべきです。
4.7.1. Type-P
4.7.1. タイプＰ
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.
骨組み文書［３］で述べたように、測定量の値は測定に使ったパケットのタ
イプ、あるいは「タイプＰ」に依存するかもしれません。タイプＰ一方向周
期的遅延値は、プロトコル（ＵＤＰかＴＣＰ）や、ポート番号や、サイズや、
特別な待遇（例えば、ＩＰ優先あるいはＲＳＶＰ）の組合せで変化します。
測定をするために使われた正確なタイプＰは報告されなくてはなりません
(MUST)。
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.
加えるに、損失と等しい遅延の閾値（あるいはこの閾値を決定する方法論）
が報告されなくてはなりません(MUST)。
4.7.3. Calibration results
4.7.3. 目盛り結果
+ If the systematic error can be determined, it SHOULD be removed
from the measured values.
+ がもし秩序立ったエラーが決定でるなら、それは測定値から取り除かれる
べきです(SHOULD)。
+ 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.)
+ あなたは、本当の価値が、９５％の信頼度で、報告された価値プラスある
いはマイナスｅであような、目盛りエラー、ｅ、を報告するべきです
(SHOULD)（最後の章を参照）。
+ 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)。
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
path is short enough, and all routers on the path support record (or
loose-source) route, then the path will be precisely recorded.
パケットの通過するパスは、可能であるなら、報告されるべきです(SHOULD)。
一般に、あるパケットがネットワークを通る正確なパスを知ることは非実用
的です。正確なパスは短いか安定したパス上での特定のタイプＰパケットの
ために知られているかもしれません。もしタイプＰがＩＰヘッダのオプショ
ンに経路記録（あるいは緩いソースルート）を含み、そしてパスは十分に短
く、そしてパスの上の全ルータが経路記録（あるいは緩いソースルート）を
実装するなら、パスは正確に記録されるでしょう。
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.}
しかしながら、部分的な情報はまだ貴重な状況です。例えば、もしホストが
２つのリンクの中から選択ができるなら（つまりSrcからDstへの２つの異な
る経路がある）、使用する最初のリンクは貴重な状況です。｛コメント：例
えば、ある商用設定で、１つのＮＡＰ上のSrcが、いくつもの異なったバック
ボーンネットワークにより、他のＮＡＰ上のDstに到達できます。｝
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.
図１がこのメモに関係がある多数のプロトコルレベルの測定を例示します。
ユーザーの焦点はアプリケーションから見た転送品質評価にあります。しか
しながら、パケット音声で正確にオペレーティング・システムとコーデック
の品質への貢献を切り離すために、例えば、ＩＰレベルにおいて品質を測る
ことが可能であることは有益です[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.
図１：測定を行う異なった可能性： プロトコル光景。上で、「アプリケー
ション」がＬ４上のすべてのレイヤを参照し、ＯＳＩの意味では使われません。
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.
+ もっともらしいパケット：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 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.
ＩＰ配送サービス測定が国際電気通信連合（ＩＴＵ）の中で論じられました。
サービス計画に適しているように意図されるＩＰサービスレベル測定（ＩＰ
能力[3]のために枠組みの参考文献で）のための枠組みがI.３８０[7]として
承認されました。ＩＴＵ−Ｔ勧告I.３８０が性能測定の抽象的な定義をカバー
します。このメモは共に能動的と受動的な測定で、共にサービス計画とエン
ドユーザーテストの目的のために、有用な方法を記述します。
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.
すべての測定タイプのための参照測定設定は図２で示されます。
----------------< IP >--------------------
| | | |
------- ------- -------- --------
| Src | | MP | | MP | | Dst |
------- |(Src)| |(Dst) | --------
------- --------
Fig. 2: Example measurement setup.
図２：測定設定例
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）、対応する測定ポイント（MP(Src)とMP(Dst)）の設定です。測定ポ
イントのための別の装置は、もしSrcやDstが測定を行うようにすると測定す
る遅延能力に影響を与えるかもしれない場合、使われるかもしれません。
MP(Src)はSrcパケットの出口ポイントの近くに設置され測定されるべきです。
MP(Dst)はDstのパケットの入り口ポイントに設置され測定するべきです。
「近く」がアプリケーションレベル性能特性（遅延の様な）の測定に十分な
ほど小さい距離と定義され、適切な正確さでSrcとDst間の対応する性能特性
に従うことを期待されます。ここの基本的な原則はMP(Src)とMP(Dst)間の測
定結果が、測定の一般的なエラーマージン目標の中でSrcとDst間の測定と同
じべきでであるということです（例えば、＜１ミリセカンド；損失パケット
数も同様）。もしこれが可能ではないなら、MP-MP測定とSrc-Dst測定の間の
相違はなるべく秩序立っているべきです。
The test setup just described fulfills two important criteria:
ちょうど記述されたテスト設定は２つの重要な基準を果たします：。
1) The test is made with realistic stream metrics, emulating - for
example - a full-duplex Voice over IP (VoIP) call.
1) テストは現実的な流れ測定量の模倣でされます。−例えば−全二重の
ＩＰ上の音声（ＶｏＩＰ）呼。
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)の間に中間測定ポイントを持つことは同じく可能ですが、
これはこの文書の範囲外です。
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.
可能な限り一般に適用可能な測定量を指定するため、一方向遅延に基づいた
アプリケーションレベル測定が例の測定量で使われます。対話型のマルチメ
ディアの会議のような、双方向性の応用のためのアプリケーションレベル測
定のほのめかしは下に論じられます。
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.
対の一方向遅延が２つのマルチメディアストリームを参照します：同じSrcと
Dstで、SrcからDstとDstからSrc。例で、あるアプリケーションのために、そ
れぞれの一方向パスの遅延能力は往復遅延より重要です。これはＶｏＩＰの
ような遅延限定された信号で本当です。一方向遅延の間の相違の可能な理由
はSrcからDstとDstからSrcへのフローの異なったルーティングです。
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で３０msの平均の遅延を持つこ
とを示すかもしれない、他方DstからSrcは１２０msの平均の遅延を持ちます。
往復の遅延測定で、この例は平均１５０ms遅延のように見えるでしょう。非
対称の知識無しで、我々はいずれかの端のアプリケーションが平均遅延が
１００msの問題があるのを残念に思うかもしれません。
Moreover, paired one way delay measurement emulates a full-duplex
VoIP call more accurately than a single one-way measurement only.
さらに、対の一方向遅延測定は、全二重ＶｏＩＰ呼を、単体の一方向測定よ
りも、正確に擬似します。
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.
周期的なマルチメディアストリームの見地から、往復の測定が２つの利点を
持っています：ホスト時計同期の必要を避けます、そして全二重通信の擬似
を考慮します。前の利点は測定で、特別な装置あるいはＮＴＰ設定が必要で
ないから、容易に行えることを意味します。後の特性は測定流が両方向で伝
達されることを意味します。それで、測定は、両方向のアプリケーションの
実行同様の、サービスの品質の情報を供給します。
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.
往復の測定の悪い面は片道のテストより多く必要なバンド幅とパケット損失
のいっそう複雑な計算です。さらに、オリジナルの送信者に向かって戻る復
路の流れは、往路よりバースト的かもしれません。後の問題は、しかしなが
ら、実際は戻っている流れが行きのより悪いＱｏＳを経験するかもしれない
ことを意味し、そして得られた性能の見積もりは悲観的なものです。不均衡
のルーティングとキューの可能性は結果の分析の間に考慮されなくてはなり
ません。
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 １つのサンプルからの計算可能な統計値
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(Src)で１００のパケットを生成し、次に
MP(Dst)で測定します：
+ 80 packets received with delay [i] <= 20 ms
+ 80パケットが遅延[i] <= 20ミリ秒で受信
+ 8 packets received with delay [i] > 20 ms
+ 8パケットが遅延[i] > 20ミリ秒で受信
+ 5 packets received with corrupt packet headers
+ 5パケットが不正なパケットヘッダーで受信
+ 4 packets from MP(Src) with no matching packet recorded at
MP(Dst) (effectively lost)
+ MP(Src)からの4パケットが、対応するパケットがMP(Dst)で記録されて
いない（効率的に損失）
+ 3 packets received with corrupt packet payload and delay
[i] <= 20 ms
+ 3パケットが不正なパケットペイロードと遅延[i] <= 20ミリ秒で受信
+ 2 packets that duplicate one of the 80 packets received correctly
as indicated in the first item
+ 2つのパケットが、最初の項目で示される正確に受信した８０のパケッ
トのどれかと重複受信
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%.
この例で、パケットは、もし遅延が２０ms以下で、不正なパケットヘッダや
パケットペイロードなしで受信するなら、受容できると思われます。この場
合、受容できるパケットのパーセンテージは８０/１００ ＝ ８０％です。
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%.
（パケットが受信される限り）、遅延限界がなく、不正なパケットペイロー
ドのパケットを受け入れる、他のアプリケーションで、許容できるパケット
のパーセンテージは（８０＋８＋３）／１００＝９１％です。
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
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.
「サンプルのサンプル」を集めるこの方法を使っている多数のテストを行う
のに価値があるかもしれません。例えば、１回の２,０００分の電話より、
１,０００回の２分のＶｏＩＰ電話を擬似することがいっそう適当であるかも
しれません。多数のサンプルの集計を考えると、サンプル間隔（例えば分、
時）、サンプル構成（例えば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.
多数のサンプルの統計値を計算する時、より一般的な統計値（例えば中央値、
パーセントなど）が多数のパケットと関連を持っているかもしれません。
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.
対話型のマルチメディアのセッションのために、エンドエンド遅延は重要な
ファクターです。あまりにも大きい遅延は、関係者によって認知されるよう
に、マルチメディアのセッションの品質を減らします。複数のリンクレイヤ
技術を使うインターネットパス上でエンドエンド遅延を処理するための１つ
の方法は、ドメイン毎の遅延ｎ定数を使う事です（例えば特定のＩＰドメイ
ンで５０ミリセカンド）。しかしながら、この案は明確な非能力を持ち、そ
していずれかのエンドエンドをつないだ遅延の目的を成し遂げることについ
ての問題を過度に制限することができます。いっそう柔軟な実装がパス上の
不均斉の遅延の可能性のような問題を、そして与えられたドメインでの遅延
の相違に対するアプリケーションの敏感さを扱うべきです。エンドエンド
ＱｏＳを管理することに使うべきである遅延統計値についていくつかの選択
肢があります。この質問は、非常に面白いけれども、このメモの範囲外で、
そしてここでさらに論じられません。
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).
この方法は中間ネットワークを通して１つのホスト（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と中間ネットワークの管理者ががタイミングとサイズとサンプル測
定量の収集の頻度に関して双方か、あるいは多者間の協定を確立するべきで
す。関係者の間に同意された基準より超過したこの方法の使用は即刻の拒絶
や、パケット廃棄や、他の影響を受けた関係者の間に定義した急上昇手順を
起こすかもしれません。
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.
この方法のアクティブな使用がサンプルパケットを生成し、ユーザーデータ
に基づいた魅力的なサンプルではなく、そしてユーザーデータ機密性を脅か
しません。受動的な測定は注意を興味のヘッダに制限しなくてはなりません。
ユーザペイロードが長さ分析のために一時的に記憶されるかもしれないので、
適当な用心がこの情報を安全で、そして秘密にしておくためにとられなくて
はなりません(MUST)。
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. ＩＡＮＡの考慮
Since this method and metric do not define a protocol or well-known
values, there are no IANA considerations in this memo.
この方法と測定量がプロトコルあるいはよく知られている値を定義しないの
で、このメモにＩＡＮＡの考慮がありません。
8. Normative References
8. 参照する参考文献
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998.
[4] Almes, G., Kalidindi, S. and M. Zekauskas, "A one-way delay
metric for IPPM", RFC 2679, September 1999.
[5] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, November
2002.
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.
[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.
[8] Almes, G., Kalidindi, S. and M. Zekauskas, "A round-trip delay
metric for IPPM", RFC 2681, September 1999.
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の議長（Matt ZekauskasとMerike Kaeo）に感謝することを
望みます。Howard StanislevicとWill Lelandは同じく有用なコメントと質問
を提出しました。我々はこの方法のために動機づけを発達させるHenk
Uijterwaalの継続的な挑戦を認め、同じく感謝します。著者はＩＰ能力のた
めの枠組み[3]の著者によって提出された相当な基礎をもとに作り上げました。
11. Author's Addresses
11. 著者のアドレス
Vilho Raisanen
Nokia Networks
P.O. Box 300
FIN-00045 Nokia Group
Finland
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
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
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
12. Full Copyright Statement
12 著作権表示全文
Copyright (C) The Internet Society (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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。