この文書はRFC3432の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。

※:どう訳していいのかわからない言葉が多すぎるので、 この翻訳の出来はかなり悪くなりました。可能であれば翻訳しなおして下さい。


Network Working Group                                        V. Raisanen
Request for Comments: 3432                                         Nokia
Category: Standards Track                                   G. Grotefeld
                                                                Motorola
                                                               A. Morton
                                                               AT&T Labs
                                                           November 2002


         Network performance measurement with periodic streams
                周期的な流れによるネットワーク能力測定

Status of this Memo
この文書の状態


   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD
   1)の現在の版を参照してください。このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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)のシュミレーションと、いくつかの
   解析が単純化される例を含みます。サンプリング方法はランダム開始と有限
   長テストを必須にすることで予測可能性を避けます。サンプリング方法とサ
   ンプル範囲パラメータの記述に続いて、測定方法とエラーが論じられます。
   最終的に、我々は、セキュリティの考慮を含めて、周期的な測定についての
   追加情報を与えます。


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 1つのサンプルからの計算可能な統計値
       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.  IANAの考慮
   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"
   は、BCP14、RFC2119[2]で記述されたように解釈されるはずです。
   RFC2119がプロトコルを念頭に書かれたけれども、この文書でキーワー
   ドが類似の理由で使われます。これらは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.
   このメモはIPネットワークのある特定のアプリケーションに関係があるサ
   ンプリング方法と能力測定を記述します。この仕事を最初に動かしたのは、
   IPの上のマルチメディアの会議のような、対話型の周期的な流れのサービ
   スの品質でした、しかし周期的サンプリングと測定のアイデアはより広い適
   用性を持っています。対話型マルチメディアのトラフィックが考えをを示す
   ために以下で例として用いられます。

   Transmitting equally sized packets (or mostly same-size packets)
   through a network at regular intervals simulates a constant bit-rate
   (CBR), or a nearly CBR multimedia bit stream.  Hereafter, these
   packets are called periodic streams.  Cases of "mostly same-size
   packets" may be found in applications that have multiple coding
   methods (e.g.  digitally coded comfort noise during silence gaps in
   speech).
   ネットワークを通して一定間隔で同じサイズのパケット(あるいはたいてい
   同じサイズのパケット)を伝達することは一定のビット率(CBR)を擬似
   するか、あるいはほとんどCBRマルチメディアビットストリームです。今
   後、これらのパケットは周期的な流れと呼ばれます。「たいてい同じサイズ
   のパケット」の場合は、多数のコーディング方法を持つアプリケーションで
   見いだされるかもしれません(例えば音声で無音区間はデジタルコード化さ
   れた快適ノイズ)。

   In the following sections, a sampling methodology and metrics are
   presented for periodic streams.  The measurement results may be used
   in derivative metrics such as average and maximum delays.  The memo
   seeks to formalize periodic stream measurements to achieve comparable
   results between independent implementations.
   次の章で、サンプリング方法と測定量が周期的な流れのために提出されます。
   測定結果は平均と最大遅延のような派生測定量で使われるかもしれません。
   メモは、独立な実行の間で類似の結果を成し遂げるために、周期的な流れの
   測定を公式化しようと努めます。

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.
   * 多くのネットワーク損傷の測定(例えば、遅延変化、連続損失、順序変更)
     はサンプリング頻度に敏感です。損傷自身が時間と共に変化している時
     (そして変化は幾分まれで、それでも重要なとき)、単純化する一定のサ
     ンプリング頻度は分析を単純化します。

   * Frequency Domain analysis is simplified when the samples are
     equally spaced.
   * 周期的ドメイン分析は、サンプルが等間隔である時、単純化されています。

   Simulation of CBR flows with periodic streams encourages dense
   sampling of network performance, since typical multimedia flows have
   10 to 100 packets in each second.  Dense sampling permits the
   characterization of network phenomena with short duration.
   周期的な流れを持っているCBR流の擬似が、典型的なマルチメディアの流
   れが毎秒10から100のパケットを持つので、ネットワーク性能の密集サ
   ンプリングを奨励します。密集サンプリングが短い持続時間でネットワーク
   現象の性格付けを認めます。

3. Periodic Sampling Methodology
3. 周期的なサンプリング方法論

   The Framework RFC [3] points out the following potential problems
   with Periodic Sampling:
   フレームワークRFC[3]は次の周期的なサンプリングにおける可能性がある
   問題を指摘します:

   1. The performance sampled may be synchronized with some other
      periodic behavior, or the samples may be anticipated and the
      results manipulated.  Unpredictable sampling is preferred.
   1. 能力測定は何か他の周期的動作に同期するかもしれません、あるいはサン
      プルは予想できるかもしれません、そして操作された結果かもしれません。
      予想できないサンプリングが好まれます。

   2. Active measurements can cause congestion, and periodic sampling
      might drive congestion-aware senders into a synchronized state,
      producing atypical results.
   2. 能動的測定が輻輳を起こすことができ、周期的サンプリングが送信者を同
      期状態に入れ輻輳状態にし、異常な結果を引き起こすかもしれません。

   Poisson sampling produces an unbiased sample for the various IP
   performance metrics, yet there are situations where alternative
   sampling methods are advantageous (as discussed under Motivation).
   毒サンプリングが種々なIPパフォーマンス測定のために公平なサンプルを
   作り出しますが、それでもなお代わりのサンプリング方法が有利である状態
   があります(以下の動機で議論)。

   We can prescribe periodic sampling methods that address the problems
   listed above.  Predictability and some forms of synchronization can
   be mitigated through the use of random start times and limited stream
   duration over a test interval.  The periodic sampling parameters
   produce bias, and judicious selection can produce a known bias of
   interest.  The total traffic generated by this or any sampling method
   should be limited to avoid adverse affects on non-test traffic
   (packet size, packet rate, and sample duration and frequency should
   all be considered).
   我々は上にリストアップされた問題を扱う周期的なサンプリング方法を定め
   ることができます。予測可能性とある同時発生の形式がテスト間隔のランダ
   ム開始と限定した流れ持続時間の使用を通して和らげられることができます。
   周期的サンプリングパラメータは偏見を作り出し、そして賢明な選択が周知
   の偏見を作り出すことができます。非テストにトラフィックに影響を与える
   のを避けるために、これによって生成した総トラフィックや、サンプリング
   方法が限定されるべきです。(パケットサイズとパケット率とサンプル持続
   時間と頻度がすべて考慮されるべきです)。

   The configuration parameters of periodic sampling are:
   周期的なサンプリングの設定パラメータは以下です:
   +  T, the beginning of a time interval where a periodic sample is
      desired.
   +  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.
   ここで提出されたサンプル測定は、RFC2679[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).
   これらのパラメータは次の章(4.2.2と4.2.3と4.2.4)に当てはま
   ります。

   Parameters that each Singleton usually includes:
   それぞれの単体が通常含むパラメータ:
     +  Src, the IP address of a host
     +  Src, ホストのIPアドレス。
     +  Dst, the IP address of a host
     +  Dst, ホストのIPアドレス。
     +  IPV, the IP version (IPv4/IPv6) used in the measurement
     +  IPV, 測定で使ったIPバージョン(IPv4/IPv6)。
     +  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), タイプ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)を使うだろうが、
   他のアプリケーションが異なったサイズのパケット(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], 各パケット[i]に対し、MP(Src)で測られたパケット
      の時間。

   Additional parameters:
   追加パラメータ:
   +  PktID(Src) [i], for each packet [i], a unique identification or
      sequence number.
   +  PktID(Src) [i], 各パケット[i]のための、ユニークな識別子あるいは
      シーケンス番号。
   +  PktSi(Src) [i], for each packet [i], the actual packet size.
   +  PktSi(Src) [i], 各パケット[i]のための、実際のパケットサイズ。

   Some applications may use packets of different sizes, either because
   of application requirements or in response to IP performance
   experienced.
   あるアプリケーションが、アプリケーション必要条件やIP性能試験に応じ
   て、異なった大きさのパケットを使うかもしれません。

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], 各パケット[i]について、MP(Dst)で測定された時刻。
   +  PktID(Dst) [i], for each packet [i], a unique identification or
      sequence number.
   +  PktID(Dst) [i], 各パケット[i]について、ユニークな識別子あるいは
      シーケンス番号。
   +  PktSi(Dst) [i], for each packet [i], the actual packet size.
   +  PktSi(Dst) [i], 各パケット[i]について、実際のパケットサイズ。

   Optional parameters:
   任意パラメータ:
   +  dTstop, a time interval, used to add to time Tf to determine when
      to stop collecting metrics for a sample
   +  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 [i], 各パケット[i]について、パケットの受信状態。可
      能な状態はOKや、不正パケットヘッダや、パケットペイロードの誤りや、
      重複や、分割を含みます。もし使用するなら、状態を決定する基準が指定
      されなくてはなりません(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に始まり、タイプPパケットがSrcで生成され、MP(Src)で測定される
   ように、incTの連続パケットの最初のビットの名目間隔に達する時刻Tfにま
   でに、Dstに送られます。incTは多くの理由のために名目上であるかもしれま
   せん:Srcのパケット生成の変化、クロック問題(4.6章参照)、など。
   MP(Src)はT0とTfの間にのタイムスタンプが必要なパケット、SrcとDstと他の
   条件を満たすパケットだけのパラメータを記録します。MP (Dst)はT0と
   (Tf + dTstop)の間のタイムスタンプでパケットも記録します。

   Optionally at a time Tf + Tcons (but eventually in all cases), the
   data from MP(Src) and MP(Dst) are consolidated to derive the sample
   metric results.  To prevent stopping data collection too soon, dTcons
   should be greater than or equal to dTstop.  Conversely, to keep data
   collection reasonably efficient, dTstop should be some reasonable
   time interval  (seconds/minutes/hours), even if dTloss is infinite or
   extremely long.
   人で、Tf + 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.
   タイプ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).
   +  T0からTfの間隔は、テスト下のアプリケーションの合理的使用の表現に十
      分長い時間間隔で、同じ状況での過度の期間ではないように、指定すべき
      です(例えば電話が100msより長いが、1週以下です)。

   +  The nominal interval between packets (incT) and the packet size(s)
      (p(j)) should not define an equivalent bit rate that exceeds the
      capacity of the egress port of Src, the ingress port of Dst, or
      the capacity of the intervening network(s), if known.  There may
      be exceptional cases to test the response of the application to
      overload conditions in the transport networks, but these cases
      should be strictly controlled.
   +  パケット(incT)とパケットサイズ(p(j))間の名目間隔は、もし知って
      いるなら、Srcの出口ポート容量やDstの入口ポート容量や中間ネットワー
      クの容量を以上のビット率を定義するべきではありません。転送ネットワー
      ク状態に負荷をかけ過ぎるアプリケーションの反応をテストするための特
      別な場合があるかもしれませんが、これらの場合は厳密に制御されるべき
      です。

   +  Real delay values will be positive.  Therefore, it does not make
      sense to report a negative value as a real delay.  However, an
      individual zero or negative delay value might be useful as part of
      a stream when trying to discover a distribution of the delay
      errors.
   +  実際の遅延値は正の値でしょう。それ故に負の値を本当の遅延として報告
      するのは意味をなしません。しかしながら、個別のゼロや負の遅延値が、
      遅延エラーの分散を発見しようとする時、流れの一部で有用であるかもし
      れません。

   +  Depending on measurement topology, delay values may be as low as
      100 usec to 10 msec, whereby it may be important for Src and Dst
      to synchronize very closely.  GPS systems afford one way to
      achieve synchronization to within several 10s of usec.  Ordinary
      application of NTP may allow synchronization to within several
      msec, but this depends on the stability and symmetry of delay
      properties among the NTP agents used, and this delay is what we
      are trying to measure.
   +  測定トポロジーによって、遅延値は100マイクロ秒から10ミリ秒と小
      さいかも知れず、これはSrcとDstにとって非常に注意深い同期が重要であ
      るかもしれません。GPSシステムが10マイクロ秒以内の同期を成しえ
      るひとつの方法です。NTPの通常のアプリケーションが数ミリ秒以内の
      同期を許すかもしれませんが、これはNTPエージェントが使う遅延の安
      定性と対称性に依存し、この遅延はは我々が測ろうとしているものです。

   +  A given methodology will have to include a way to determine
      whether a packet was lost or whether delay is merely very large
      (and  the packet is yet to arrive at Dst).  The global metric
      parameter dTloss defines a time interval such that delays larger
      than dTloss are interpreted as losses.  {Comment: For many
      applications, the treatment of a large delay as infinite/loss will
      be inconsequential.  A TCP data packet, for example, that arrives
      only after several multiples of the usual RTT may as well have
      been lost.}
   +  与えられた方法でパケットが失われたか、あるいは遅延が非常に大きい
      (そしてパケットがまだDstに到着していない)かを決定する方法を含ま
      なければならないでしょう。グローバル測定パラメータdTlossは、dTloss
      より大きい遅延が損失と解釈される時間間隔を定義します。{コメント:
      多くのアプリケーションで、大きい遅延を無限/損失と扱うのは問題ない
      でしょう。TCPデータパケットで、例えば、通常のRTTの数倍以上遅
      れて届いたパケットを損失と扱います。}

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).
   他のタイプP*測定量と同じように、詳細な方法はタイプ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:
   特定の測定方法の記述は課金と、エラーや不確定の種々な原因の分析を含む
   べきです。枠組み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. 時計と関係があるエラーや不確実

   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)時計が10ミリ秒の解像度を持つなら、これで測られた時間
      値は10ミリ秒の不確実さがあります。我々は情報源時計の解像度
      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を測定するか範囲を知ろうと試
      みるなら、この測定や計算が周期的に繰り返されなくてはなりません。あ
      る一定期間で、この関数は線形関数と高位項で近似できます;この場合、
      1つの選択が線形要素を時計の修正に使うことです。この訂正を使って、
      残りのTsynchをより小さくします、しかし説明されなくてはならない不確
      実さの原因のままでいます。我々は同期の不確実さの上限を示すために関
      数Esynch(t)を使います。つまり、|Tsynch(t)| <= Esynch(t)です。

   Taking these items together, we note that naive computation
   Tstamp(Dst)[i] - Tstamp(Src) [i] will be off by Tsynch(t) +/-
   (ResMP(SRc) + ResMP(Dst)).  Using the notion of Esynch(t), we note
   that these clock-related problems introduce a total uncertainty of
   Esynch(t)+ Rsource + Rdest.  This estimate of total clock-related
   uncertainty should be included in the error/uncertainty analysis of
   any measurement implementation.
   これらの項目を使って、我々はTstamp(Dst)[i] - Tstamp(Src) [i]の計算は
   Tsynch(t) +/- (ResMP(SRc) + ResMP(Dst))の誤差を持つのに気付きます。
   Esynch(t)の考えを使って、我々はこれらの時計関連の問題がEsynch(t)+
   Rsource+Rdestの不確実さであることを指摘します。この完全な時計関連の
   不確実の見積もりは測定実行のエラー/不確実分析に含められるべきです。

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.
   しかしながら、ワイヤ時間とホスト時間の間の差が不確実な程度に、、この
   不確実さは所定の測定方法の分析で説明されなくてはなりません。我々は
   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.}
   目盛りゴールは可能な限り細かい手段で発生した秩序立ったエラーと、ラン
   ダムエラーを決定することです。少なくとも、報告値が(本当の値-e)から
   (本当の値+e)の範囲に95%あるような、限界(「e」)が見いだされる
   べきです。我々は測定で「e」を目盛りエラーと呼びます。これは測定手段
   によって作り出された値が再現可能である程度を表します;すなわち、実際
   の遅延30ミリセカンドが、どれだけ30ミリセカンドに近い値で報告され
   るか。{コメント:[4]で論じた理由で95%が選択されます、手短かに要約
   すると(1)若干の信頼レベルがどんな物理的な特性の測定でも見いだされ
   る異常値を取り去ることが可能であるために、望ましいです;(2)独立な
   実行結果が比較できるように、特定の信頼レベルが指定されるべきです。}

   From the discussion in the previous two sections, the error in
   measurements could be bounded by determining all the individual
   uncertainties, and adding them together to form:
   前の2つの章の論議で、測定エラーはすべての個別の不確実さを決定する限
   界があり、次の形式を取ります:

           Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest

   However, reasonable bounds on both the clock-related uncertainty
   captured by the first three terms and the host-related uncertainty
   captured by the last two terms should be possible by careful design
   techniques and calibrating the instruments using a known, isolated,
   network in a lab.
   しかしながら、時計関連の最初の3項の不確実さと後の2項のホスト関連の
   不確実さの両方で、合理的な範囲は注意深い設計技術と研究室で周知の、独
   立の、ネットワークを使った目盛り手段で可能であるべきです。

   For example, the clock-related uncertainties are greatly reduced
   through the use of a GPS time source.  The sum of Esynch(t) +
   ResMP(Src) + ResMP(Dst) is small, and is also bounded for the
   duration of the measurement because of the global time source.  The
   host-related uncertainties, Hsource + Hdest, could be bounded by
   connecting two instruments back-to-back with a high-speed serial link
   or isolated LAN segment.  In this case, repeated measurements are
   measuring the same one-way delay.
   例えば、時計関連の不確実さはGPS時刻源の使用で大いに減少します。
   Esynch(t) + ResMP(Src) + ResMP(Dst)の合計は小さく、グローバルな時刻情
   報源のため継続的測定でも限度があります。ホスト関連の不確実さ、Hsource
   + Hdest、は2つの装置を裏で高速シリアルリンクや孤立LANセグメントで
   結ぶことで限度が得られます。この場合、繰り返し測定が同じ一方的遅延を
   測ります。

   If the test packets are small, such a network connection has a
   minimal delay that may be approximated by zero.  The measured delay
   therefore contains only systematic and random error in the
   instrumentation.  The "average value" of repeated measurements is the
   systematic error, and the variation is the random error.  One way to
   compute the systematic error, and the random error, to a 95%
   confidence, is to repeat the experiment many times - at least
   hundreds of tests.  The systematic error would then be the median.
   The random error could then be found by removing the systematic error
   from the measured values.  The 95% confidence interval would be the
   range from the 2.5th percentile to the 97.5th percentile of these
   deviations from the true value.  The calibration error "e" could then
   be taken to be the largest absolute value of these two numbers, plus
   the clock-related uncertainty.  {Comment: as described, this bound is
   relatively loose since the uncertainties are added, and the absolute
   value of the largest deviation is used.  As long as the resulting
   value is not a significant fraction of the measured values, it is a
   reasonable bound.  If the resulting value is a significant fraction
   of the measured values, then more exact methods will be needed to
   compute the calibration error.}
   もしテストパケットが小さいなら、このようなネットワーク接続はゼロに近
   い最小遅延を持ちます。従って測定遅延は、器具の秩序立ったエラーとラン
   ダムエラーだけを含んでいます。継続測定の「平均値」は秩序立ったエラー
   で、変化はランダムエラーです。秩序立ったエラーとランダムエラーを計算
   する一つの方法が、95%信頼で、何度も実験を繰り返す事です−少なくと
   も何百のテストで。秩序立ったエラーはその中間値であるでしょう。ランダ
   ムエラーは測定値から秩序立ったエラーを取り除くことで見いだされます。
   95%の信頼間隔は、真の値からの偏差の2.5%から97.5%の範囲であ
   るでしょう。目盛りエラー「e」はこれらの2つの数の絶対値の大きいもの
   に、時計関連の不確実さを足して得られます。{コメント:記述されるよう
   に、この範囲は、不確実が加えられるので、比較的緩く、そして最も大きい
   偏差の絶対値が使われます。結果として生じている値が測定値の意味のある
   断片ではない限り、それは合理的な範囲です。もし結果として生じている値
   が測定値の意味のある断片であるなら、より正確な方法が目盛りエラーを計
   算するために必要とされるでしょう。}

   Note that random error is a function of measurement load.  For
   example, if many paths will be measured by one instrument, this might
   increase interrupts, process scheduling, and disk I/O (for example,
   recording the measurements), all of which may increase the random
   error in measured singletons.  Therefore, in addition to minimal load
   measurements to find the systematic error, calibration measurements
   should be performed with the same measurement load that the
   instruments will see in the field.
   ランダムエラーが測定負荷の関数であることに注意してください。例えば、
   もし多くのパスが1つの道具で測られるなら、これは(例えば、測定を記録
   している)割り込みや、プロセススケジューリングや、ディスクI/Oを増
   やすかもしれず、そしてそのすべては測定単体でランダムエラーを増やしま
   す。従って、秩序立ったエラーを見いだす最小負荷測定のほかに、目盛り測
   定がフィールドで発生するのと同じ測定負荷で行われるべきです。

   We wish to reiterate that this statistical treatment refers to the
   calibration of the instrument; it is used to "calibrate the meter
   stick" and say how well the meter stick reflects reality.
   我々はこの統計上の扱いが道具の目盛りを参照するのを繰り返すことを望み
   ます;これは「測定棒目盛り付け」と、どれほど上手に測定器棒が現実を反
   映するか言うために使われます。

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、は能動的と受動的測定で変化します。受動的
   測定で、パケットヘッダーがプロトコルスタックの最も前にタイムスタンプ
   を含むかもしれず、実際の送信時刻はプロセッサスケジューリングで変化す
   るかもしれません。例えば、H.323システムは理想的な時に5ミリセカ
   ンドの内にネットワークスタックの準備ができたパケットを持つように要求
   されます。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)。我々は次に考
   慮するべき5つの項目を提出します:タイプPテストパケット、損失と等しい
   遅延の閾値、エラー目盛り、テストパケットの通る経路、SrcとDstとサンプ
   ルの中間ネットワークのの背景条件。このリストは徹底的ではありません;
   測定量のアプリケーションを解釈することにおいて有用であり得たどんな追
   加の情報でも同じく報告されるべきです。

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.
   骨組み文書[3]で述べたように、測定量の値は測定に使ったパケットのタ
   イプ、あるいは「タイプP」に依存するかもしれません。タイプP一方向周
   期的遅延値は、プロトコル(UDPかTCP)や、ポート番号や、サイズや、
   特別な待遇(例えば、IP優先あるいはRSVP)の組合せで変化します。
   測定をするために使われた正確なタイプPは報告されなくてはなりません
   (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.)
   +  あなたは、本当の価値が、95%の信頼度で、報告された価値プラスある
      いはマイナスeであような、目盛りエラー、e、を報告するべきです
      (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)。
   一般に、あるパケットがネットワークを通る正確なパスを知ることは非実用
   的です。正確なパスは短いか安定したパス上での特定のタイプPパケットの
   ために知られているかもしれません。もしタイプPがIPヘッダのオプショ
   ンに経路記録(あるいは緩いソースルート)を含み、そしてパスは十分に短
   く、そしてパスの上の全ルータが経路記録(あるいは緩いソースルート)を
   実装するなら、パスは正確に記録されるでしょう。

   This may be impractical because the route must be short enough.  Many
   routers do not support (or are not configured for) record route, and
   use of this feature would often artificially worsen the performance
   observed by removing the packet from common-case processing.
   これは、経路が十分に短いに違いないから、非実用的であるかもしれません。
   多くのルータが経路記録を実装せず(あるいは実行するように設定されず)、
   そしてこの機能の使用はパケットを通常処理から取り除くので観察される能
   力を悪化させます。

   However, partial information is still valuable context.  For example,
   if a host can choose between two links (and hence two separate routes
   from Src to Dst), then the initial link used is valuable context.
   {Comment: For example, with one commercial setup, a Src on one NAP
   can reach a Dst on another NAP by either of several different
   backbone networks.}
   しかしながら、部分的な情報はまだ貴重な状況です。例えば、もしホストが
   2つのリンクの中から選択ができるなら(つまりSrcからDstへの2つの異な
   る経路がある)、使用する最初のリンクは貴重な状況です。{コメント:例
   えば、ある商用設定で、1つのNAP上のSrcが、いくつもの異なったバック
   ボーンネットワークにより、他のNAP上の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.
   図1がこのメモに関係がある多数のプロトコルレベルの測定を例示します。
   ユーザーの焦点はアプリケーションから見た転送品質評価にあります。しか
   しながら、パケット音声で正確にオペレーティング・システムとコーデック
   の品質への貢献を切り離すために、例えば、IPレベルにおいて品質を測る
   ことが可能であることは有益です[6]。リンクレイヤモニタリングがビットエ
   ラー率のようなリンクレイヤ特有の課金の仕方を提供します。

        ---------------
        | application |
        ---------------
        |  transport  | <--
        ---------------
        |   network   | <--
        ---------------
        |    link     | <--
        ---------------
        |   physical  |
        ---------------

   Fig. 1: Different possibilities for performing measurements: a
   protocol view.  Above, "application" refers to all layers above L4
   and is not used in the OSI sense.
   図1:測定を行う異なった可能性: プロトコル光景。上で、「アプリケー
   ション」がL4上のすべてのレイヤを参照し、OSIの意味では使われません。

   In general, the results of measurements may be influenced by
   individual application requirements/responses related to the
   following issues:
   一般に、測定の結果は次の問題と関係がある個別のアプリケーション必要条件
   /回答によって影響を与えられるかもしれません:。

   +  Lost packets: Applications may have varying tolerance to lost
      packets.  Another consideration is the distribution of lost
      packets (i.e. random or bursty).
   +  損失パケット:アプリケーションが損失パケットにさまざまな耐久力を持
      つかもしれません。他の考慮は損失パケットの分布です(すなわちランダ
      ムか、バーストか)。
   +  Long delays: Many applications will consider packets delayed
      longer than a certain value to be equivalent to lost packets (i.e.
      real time applications).
   +  長い遅延:多くのアプリケーションが一定以上遅延したパケットを損失と
      思うでしょう(すなわちリアルタイムアプリケーション)。
   +  Duplicate packets: Some applications may be perturbed if duplicate
      packets are received.
   +  重複パケット:あるアプリケーションは、もし重複パケットを受信すると、
      当惑するかもしれません。
   +  Reordering: Some applications may be perturbed if packets arrive
      out of sequence.  This may be in addition to the possibility of
      exceeding the "long" delay threshold as a result of being out of
      sequence.
   +  順序変更:あるアプリケーションは、もしパケットが順序どおり到着しな
      いと、当惑するかもしれません。これは順序変更の結果としての「長い」
      遅延限界を超える可能性を追加するかもしれません。
   +  Corrupt packet header: Most applications will probably treat a
      packet with a corrupt header as equivalent to a lost packet.
   +  不正なパケットヘッダ:たいていのアプリケーションが不正なヘッダーの
      パケットをパケット損失と同様に扱うでしょう。
   +  Corrupt packet payload: Some applications (e.g. digital voice
      codecs) may accept corrupt packet payload.  In some cases, the
      packet payload may contain application specific forward error
      correction (FEC) that can compensate for some level of corruption.
   +  不正なパケットペイロード:あるアプリケーション(例えばデジタル声
      コーデック)が不正なパケットペイロードを受け入れるかもしれません。
      ある場合には、パケットペイロードは数レベルのエラーを埋め合わせるこ
      とができるアプリケーション特有の前進的なエラー訂正(FEC)を含ん
      でいるかもしれません。
   +  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.
   このサンプリング方法はQoSメカニズムをIPネットワークで利用した可
   能性にかかわらず測定を行う方法を供給します。例として、厳しい保証がな
   いQoSメカニズムのために、測定が「最も良い」クラスが問題のトラフィッ
   ククラスのために約束されたサービスを手に入れることを確かめるために使
   われるかもしれません。さらに、オペレーターが他のクラスで可能なのろい
   バンド幅を使って実行された安い、低い保証のサービスの品質を調査するこ
   とができます。このような測定は新しいサービスの可能性を調査することに
   おいて、あるいは通常の基礎の上にすることができます。

   IP delivery service measurements have been discussed within the
   International Telecommunications Union (ITU).  A framework for IP
   service level measurements (with references to the framework for IP
   performance [3]) that is intended to be suitable for service planning
   has been approved as I.380 [7].  ITU-T Recommendation I.380 covers
   abstract definitions of performance metrics.  This memo describes a
   method that is useful, both for service planning and end-user testing
   purposes, in both active and passive measurements.
   IP配送サービス測定が国際電気通信連合(ITU)の中で論じられました。
   サービス計画に適しているように意図されるIPサービスレベル測定(IP
   能力[3]のために枠組みの参考文献で)のための枠組みがI.380[7]として
   承認されました。ITU−T勧告I.380が性能測定の抽象的な定義をカバー
   します。このメモは共に能動的と受動的な測定で、共にサービス計画とエン
   ドユーザーテストの目的のために、有用な方法を記述します。

   Delay measurements can be one-way [3,4], paired one-way, or round-
   trip [8]. Accordingly, the measurements may be performed either with
   synchronized or unsynchronized Src/Dst host clocks.  Different
   possibilities are listed below.
   遅延測定は一方向[3,4]、対担った一方向、あるいは往復[8]があり得ます。
   したがって、測定は同期したか、あるいは非同期のSrc/Dstホスト時計で同
   様行われるかもしれません。異なった可能性が下にリストアップされます。

   The reference measurement setup for all measurement types is shown in
   Fig. 2.
   すべての測定タイプのための参照測定設定は図2で示されます。

        ----------------< IP >--------------------
        |          |                  |          |
      -------   -------           --------    --------
      | Src |   | MP  |           | MP   |    | Dst  |
      -------   |(Src)|           |(Dst) |    --------
                -------           --------

                    Fig. 2: Example measurement setup.
                    図2:測定設定例

   An example of the use of the method is a setup with a source host
   (Src), a destination host (Dst), and corresponding measurement points
   (MP(Src) and MP(Dst)) as shown in Figure 2.  Separate equipment for
   measurement points may be used if having Src and/or Dst conduct the
   measurement may significantly affect the delay performance to be
   measured.  MP(Src) should be placed/measured close to the egress
   point  of packets from Src.  MP(Dst) should be placed/measure close
   to the ingress point of packets for Dst.  "Close" is defined as a
   distance sufficiently small so that application-level performance
   characteristics measured (such as delay) can be expected to follow
   the corresponding performance characteristic between Src and Dst to
   an adequate accuracy. The basic principle here is that measurement
   results between MP(Src) and MP(Dst) should be the same as for a
   measurement between Src and Dst, within the general error margin
   target of the measurement (e.g., < 1 ms; number of lost packets is
   the same).  If this is not possible, the difference between MP-MP
   measurement and Src-Dst measurement should preferably be systematic.
   方法の使用の例が、図2に示されるように、ソースホスト(Src)、宛先ホス
   ト(Dst)、対応する測定ポイント(MP(Src)とMP(Dst))の設定です。測定ポ
   イントのための別の装置は、もしSrcやDstが測定を行うようにすると測定す
   る遅延能力に影響を与えるかもしれない場合、使われるかもしれません。
   MP(Src)はSrcパケットの出口ポイントの近くに設置され測定されるべきです。
   MP(Dst)はDstのパケットの入り口ポイントに設置され測定するべきです。
   「近く」がアプリケーションレベル性能特性(遅延の様な)の測定に十分な
   ほど小さい距離と定義され、適切な正確さでSrcとDst間の対応する性能特性
   に従うことを期待されます。ここの基本的な原則はMP(Src)とMP(Dst)間の測
   定結果が、測定の一般的なエラーマージン目標の中でSrcとDst間の測定と同
   じべきでであるということです(例えば、<1ミリセカンド;損失パケット
   数も同様)。もしこれが可能ではないなら、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)の間に中間測定ポイントを持つことは同じく可能ですが、
   これはこの文書の範囲外です。


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.
   ひとつの一方向の測定を行うことはただ1つの方向でのネットワーク動作の
   情報をもたらすだけです。さらに、ネットワーク転送レベルでの流れは正確
   に全二重のマルチメディア接続を擬似しません。

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で、SrcからDstとDstからSrc。例で、あるアプリケーションのために、そ
   れぞれの一方向パスの遅延能力は往復遅延より重要です。これはVoIPの
   ような遅延限定された信号で本当です。一方向遅延の間の相違の可能な理由
   は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で30msの平均の遅延を持つこ
   とを示すかもしれない、他方DstからSrcは120msの平均の遅延を持ちます。
   往復の遅延測定で、この例は平均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
   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):
   例えば、サンプル測定量がMP(Src)で100のパケットを生成し、次に
   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つのパケットが、最初の項目で示される正確に受信した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
   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.
   「サンプルのサンプル」を集めるこの方法を使っている多数のテストを行う
   のに価値があるかもしれません。例えば、1回の2,000分の電話より、
   1,000回の2分のVoIP電話を擬似することがいっそう適当であるかも
   しれません。多数のサンプルの集計を考えると、サンプル間隔(例えば分、
   時)、サンプル構成(例えばTf-T0と等しい、異なったパケット大きさ)、
   ネットワークの考慮(例えば、異なる間のリンクとホストの組合せ上での異
   なるサンプル)の問題が考えられるべきです。サンプル間隔のような項目で、
   アプリケーションのために重要な使用パターンは考慮されるべきです。

   When computing statistics for multiple samples, more general
   statistics (e.g. median, percentile, etc.) may have relevance with a
   larger number of packets.
   多数のサンプルの統計値を計算する時、より一般的な統計値(例えば中央値、
   パーセントなど)が多数のパケットと関連を持っているかもしれません。

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つ
   の方法は、ドメイン毎の遅延n定数を使う事です(例えば特定のIPドメイ
   ンで50ミリセカンド)。しかしながら、この案は明確な非能力を持ち、そ
   していずれかのエンドエンドをつないだ遅延の目的を成し遂げることについ
   ての問題を過度に制限することができます。いっそう柔軟な実装がパス上の
   不均斉の遅延の可能性のような問題を、そして与えられたドメインでの遅延
   の相違に対するアプリケーションの敏感さを扱うべきです。エンドエンド
   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)からもう1つのホ
   スト(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. 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.

   [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の継続的な挑戦を認め、同じく感謝します。著者はIP能力のた
   めの枠組み[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.
   著作権(C)インターネット学会(2002)。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So