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.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations.
このメモは、IPネットワークのパフォーマンスを評価するための定期的なサンプリング方法と関連する指標を説明しています。まず、メモは、周期的なサンプリングを動機と利点は、アクティブおよびパッシブ測定への適用を含むRFC 2330に記載のポアソンサンプリングに代わるものとして、その値の問題に対処し、マルチメディア通信の（典型的な固定ビットレート（CBR）トラフィックのシミュレーション、またはほぼCBR、音声アクティビティ検出）、および分析を簡素化することができるいくつかの例で見られるように。サンプリング方法は、ランダムな開始時刻と有限の長さのテストを義務付けることにより、予測可能性を回避します。サンプリング方法とサンプルメトリックパラメータの説明を以下、測定方法および誤差が議論されています。最後に、我々は、セキュリティ上の配慮を含む定期的な測定、に関する追加情報を提供します。
Table of Contents
目次
1. Conventions used in this document........................... 2
2. Introduction................................................ 3
2.1 Motivation.............................................. 3
3. Periodic Sampling Methodology............................... 4
4. Sample metrics for periodic streams......................... 5
4.1 Metric name............................................. 5
4.2 Metric parameters....................................... 5
4.3 High level description of the procedure to collect a
sample.................................................. 7
4.4 Discussion.............................................. 8
4.5 Additional Methodology Aspects.......................... 9
4.6 Errors and uncertainties................................ 9
4.7 Reporting............................................... 13
5. Additional discussion on periodic sampling.................. 14
5.1 Measurement applications................................ 15
5.2 Statistics calculable from one sample................... 18
5.3 Statistics calculable from multiple samples............. 18
5.4 Background conditions................................... 19
5.5 Considerations related to delay......................... 19
6. Security Considerations..................................... 19
6.1 Denial of Service Attacks............................... 19
6.2 User data confidentiality............................... 20
6.3 Interference with the metric............................ 20
7. IANA Considerations......................................... 20
8. Normative References........................................ 20
9. Informative References...................................... 21
10. Acknowledgments............................................. 21
11. Author's Addresses.......................................... 22
12. Full Copyright Statement.................................... 23
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure that the results of measurements from two different implementations are comparable, and to note instances in which an implementation could perturb the network.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。 RFC 2119を念頭にプロトコルで書かれていたが、キーワードは、同様の理由でこの文書で使用されています。それらは二つの異なる実装からの測定結果が同等であることを保証するために、実装は、ネットワークを混乱ができたインスタンスを注意するために使用されます。
This memo describes a sampling method and performance metrics relevant to certain applications of IP networks. The original driver for this work was Quality of Service of interactive periodic streams, such as multimedia conferencing over IP, but the idea of periodic sampling and measurement has wider applicability. Interactive multimedia traffic is used as an example below to illustrate the concept.
このメモは、IPネットワークの特定のアプリケーションに関連するサンプリング方法とパフォーマンスメトリックを説明します。この作品の元のドライバは、このようなIPを介したマルチメディア会議などのインタラクティブ定期的なストリームのサービス品質でしたが、定期的なサンプリングと測定の考え方は、より広い適用性を有します。インタラクティブなマルチメディアトラフィックは、以下の概念を説明するために例として使用されています。
Transmitting equally sized packets (or mostly same-size packets) through a network at regular intervals simulates a constant bit-rate (CBR), or a nearly CBR multimedia bit stream. Hereafter, these packets are called periodic streams. Cases of "mostly same-size packets" may be found in applications that have multiple coding methods (e.g. digitally coded comfort noise during silence gaps in speech).
定期的にネットワークを介して、同じサイズのパケット（またはほとんど同じサイズのパケット）を送信することは、一定ビットレート（CBR）、またはほぼCBRマルチメディアビットストリームをシミュレートします。以下、これらのパケットは、定期的なストリームと呼ばれています。 「ほぼ同じサイズのパケット」の場合は、複数の符号化方式（音声における無音ギャップの間、例えば、デジタル符号化された快適雑音）を有するアプリケーションに見出すことができます。
In the following sections, a sampling methodology and metrics are presented for periodic streams. The measurement results may be used in derivative metrics such as average and maximum delays. The memo seeks to formalize periodic stream measurements to achieve comparable results between independent implementations.
次のセクションでは、サンプリングの方法論とメトリックは、定期的な流れのために提示されています。測定結果は、平均値と最大遅延のような誘導体メトリックで使用することができます。メモは、独立した実装の間で同等の結果を達成するために定期的な流れの測定を形式化することを目指しています。
As noted in the IPPM framework RFC 2330 [3], a sample metric using regularly spaced singleton tests has some limitations when considered from a general measurement point of view: only part of the network performance spectrum is sampled. However, some applications also sample this limited performance spectrum and their performance may be of critical interest.
IPPMフレームワークRFC 2330に述べたように、ビューの一般的な測定点から考慮した場合、[3]、等間隔シングルトン試験を使用してサンプルメトリックは、いくつかの制限がありますネットワーク性能スペクトルの一部のみがサンプリングされます。ただし、一部のアプリケーションでも、この限られた性能スペクトルをサンプリングし、その性能が重要な関心であってもよいです。
Periodic sampling is useful for the following reasons:
定期的なサンプリングは、次のような理由で有用です。
* It is applicable to passive measurement, as well as active measurement.
*これは、受動的な測定だけでなく、アクティブな測定に適用されます。
* An active measurement can be configured to match the characteristics of media flows, and simplifies the estimation of application performance.
*能動的測定は、メディアフローの特性と一致するように構成され、アプリケーションのパフォーマンスの評価を簡素化することができます。
* Measurements of many network impairments (e.g., delay variation, consecutive loss, reordering) are sensitive to the sampling frequency. When the impairments themselves are time-varying (and the variations are somewhat rare, yet important), a constant sampling frequency simplifies analysis.
*多くのネットワーク障害（例えば、遅延変動、連続的な損失、並び替え）の測定は、サンプリング周波数に敏感です。障害自体が時間的に変化する（および変形が幾分稀で、まだ重要）である場合、一定のサンプリング周波数は、解析を単純化します。
* Frequency Domain analysis is simplified when the samples are equally spaced.
サンプルが等間隔である場合*周波数領域分析が簡略化されます。
Simulation of CBR flows with periodic streams encourages dense sampling of network performance, since typical multimedia flows have 10 to 100 packets in each second. Dense sampling permits the characterization of network phenomena with short duration.
CBRのシミュレーションは、周期的なストリームに流れる典型的なマルチメディアフローは、各第二に、10〜100のパケットを有しているので、ネットワーク性能の密なサンプリングを促進します。密なサンプリングは、短期間でネットワーク現象の特性評価が可能になります。
The Framework RFC [3] points out the following potential problems with Periodic Sampling:
フレームワークRFC [3]は周期的サンプリングでは、次の潜在的な問題を指摘します。
1. The performance sampled may be synchronized with some other periodic behavior, or the samples may be anticipated and the results manipulated. Unpredictable sampling is preferred.
1.サンプリング性能は、いくつかの他の周期的挙動と同期させることができる、またはサンプルを予想することができ、その結果を操作します。予測不可能なサンプリングが好ましいです。
2. Active measurements can cause congestion, and periodic sampling might drive congestion-aware senders into a synchronized state, producing atypical results.
2.アクティブな測定が輻輳を引き起こす可能性があり、定期的なサンプリングは、非定型の成果を、同期状態に渋滞を意識した送信者を駆動することがあります。
Poisson sampling produces an unbiased sample for the various IP performance metrics, yet there are situations where alternative sampling methods are advantageous (as discussed under Motivation).
ポアソンサンプリングは、様々なIPのパフォーマンスメトリックの公正なサンプルを生成し、まだ（動機の下で議論されるように）別のサンプリング方法が有利である状況があります。
We can prescribe periodic sampling methods that address the problems listed above. Predictability and some forms of synchronization can be mitigated through the use of random start times and limited stream duration over a test interval. The periodic sampling parameters produce bias, and judicious selection can produce a known bias of interest. The total traffic generated by this or any sampling method should be limited to avoid adverse affects on non-test traffic (packet size, packet rate, and sample duration and frequency should all be considered).
私たちは、上記の問題を解決する定期的なサンプリング方法を処方することができます。予測可能性と同期のいくつかの形態は、テスト期間にわたるランダム開始時間と限られたストリームの期間を使用して緩和することができます。定期的なサンプリングパラメータは、バイアスを生成し、賢明な選択は、関心のある既知のバイアスを生成することができます。このまたは任意のサンプリング方法によって生成された総トラフィックが有害（すべてを考慮すべきパケットサイズ、パケットレート、およびサンプル時間と周波数）非試験トラフィックに影響を避けるために制限されるべきです。
The configuration parameters of periodic sampling are: + T, the beginning of a time interval where a periodic sample is desired. + dT, the duration of the interval for allowed sample start times. + T0, a time that MUST be selected at random from the interval [T, T+dT] to start generating packets and taking measurements. + Tf, a time, greater than T0, for stopping generation of packets for a sample (Tf may be relative to T0 if desired). + incT, the nominal duration of inter-packet interval, first bit to first bit.
定期的なサンプリングの構成パラメータは、+ T、周期的なサンプルが所望される時間間隔の開始。 + dTを、許可されたサンプルの開始時間の間隔の期間。 + T0、パケットを生成し、測定を行う開始する間隔[T、T + dTの]からランダムに選択されなければならない時間。 + Tfは、時間、T0よりも大きく、試料のパケットの生成を停止させる（所望であれば、TfはT0に対してであってもよいです）。 + INCT、パケット間間隔、最初のビットの最初のビットの公称持続時間。
T0 may be drawn from a uniform distribution, or T0 = T + Unif(0,dT). Other distributions may also be appropriate. Start times in successive time intervals MUST use an independent value drawn from the distribution. In passive measurement, the arrival of user media flows may have sufficient randomness, or a randomized start time of the measurement during a flow may be needed to meet this requirement.
T0は一様分布から引き出され、又はT0 = T + UNIF（0、DT）してもよいです。他のディストリビューションにも適切かもしれません。連続した時間間隔で開始時間が分布から引き出される独立した値を使用する必要があります。受動的測定では、ユーザメディアフローの到着は、十分なランダム性を有していてもよく、又は流量時測定のランダム化開始時間は、この要件を満たすために必要とされるかもしれません。
When a mix of packet sizes is desired, passive measurements usually possess the sequence and statistics of sizes in actual use, while active measurements would need to reproduce the intended distribution of sizes.
パケットサイズのミックスが所望される場合に活性の測定はサイズの意図分布を再現する必要があるが、受動的測定は通常、実際の使用中サイズの配列と統計を有します。
The sample metric presented here is similar to the sample metric Type-P-One-way-Delay-Poisson-Stream presented in RFC 2679[4]. Singletons defined in [3] and [4] are applicable here.
ここに提示サンプルメトリックがメトリックタイプ-P-ワンウェイ遅延ポアソンストリームは、RFC 2679に提示サンプルと類似している[4]。 [3]と[4]で定義されたシングルトンは、ここで適用可能です。
Type-P-One-way-Delay-Periodic-Stream
タイプ-P-ワンウェイ遅延定期ストリーム
These parameters apply in the following sub-sections (4.2.2, 4.2.3, and 4.2.4).
これらのパラメータは、以下のサブセクション（4.2.2、4.2.3および4.2.4）に適用します。
Parameters that each Singleton usually includes: + Src, the IP address of a host + Dst, the IP address of a host + IPV, the IP version (IPv4/IPv6) used in the measurement + dTloss, a time interval, the maximum waiting time for a packet before declaring it lost. + packet size p(j), the desired number of bytes in the Type-P packet, where j is the size index.
+ SRC、ホストのIPアドレス+ Dstの、ホストのIPアドレス+ IPV、測定+ dTlossで使用されるIPバージョン（IPv4の/ IPv6）の、時間間隔、最大待ち時間を各シングルトンは通常含むパラメータそれが失われたと宣言する前に、パケットのための時間。 +パケット・サイズP（j）は、jは大きさの指標であるタイプPパケットのバイトの所望の数。
Optional parameters: + PktType, any additional qualifiers (transport address) + Tcons, a time interval for consolidating parameters collected at the measurement points.
オプションのパラメータ：+するPktType、追加の修飾子（トランスポートアドレス）+ Tcons、測定点で収集パラメータを統合するための時間間隔。
While a number of applications will use one packet size (j = 1), other applications may use packets of different sizes (j > 1). Especially in cases of congestion, it may be useful to use packets smaller than the maximum or predominant size of packets in the periodic stream.
アプリケーションの数が1つのパケットサイズ（J = 1）を使用するが、他のアプリケーションは、異なるサイズ（J> 1）のパケットを使用してもよいです。特に渋滞の場合には、周期的なストリーム内のパケットの最大又は優勢なサイズより小さいパケットを使用することが有用であり得ます。
A topology where Src and Dst are separate from the measurement points is assumed.
SrcとDstの測定点から分離されているトポロジーが仮定されます。
Parameters that each Singleton usually includes: + Tstamp(Src)[i], for each packet [i], the time of the packet as measured at MP(Src)
各シングルトンが通常含まパラメータ：+ TSTAMP（SRC）[i]は、各パケットのために[i]は、MPで測定されたパケットの時間（SRC）
Additional parameters: + PktID(Src) [i], for each packet [i], a unique identification or sequence number. + PktSi(Src) [i], for each packet [i], the actual packet size.
追加のパラメータ：+ PktID（SRC）[i]は、各パケット[i]は、固有の識別またはシーケンス番号の。 + PktSi（SRC）[i]は、各パケット[i]は、実際のパケットサイズ。
Some applications may use packets of different sizes, either because of application requirements or in response to IP performance experienced.
一部のアプリケーションでは、ため、アプリケーションの要件のか、経験豊富なIP性能に応じていずれか、異なるサイズのパケットを使用することができます。
+ Tstamp(Dst)[i], for each packet [i], the time of the packet as measured at MP(Dst) + PktID(Dst) [i], for each packet [i], a unique identification or sequence number. + PktSi(Dst) [i], for each packet [i], the actual packet size.
+ TSTAMP（DST）[i]は、各パケット[i]は、MP（DST）+ PktID（DST）で測定されたパケットの時間[i]は、各パケットのために[i]は、固有の識別またはシーケンス番号。 + PktSi（DST）[i]は、各パケット[i]は、実際のパケットサイズ。
Optional parameters: + dTstop, a time interval, used to add to time Tf to determine when to stop collecting metrics for a sample + PktStatus [i], for each packet [i], the status of the packet received. Possible status includes OK, packet header corrupt, packet payload corrupt, duplicate, fragment. The criteria to determine the status MUST be specified, if used.
オプションのパラメータ：+ dTstop、サンプル+ PktStatusのメトリックの収集を停止する時を決定するために時間Tfに追加するために使用される時間間隔、[i]は、各パケットのために[i]は、パケットのステータスを受信しました。可能なステータスがOK、パケットヘッダ破損、パケットペイロード破損し、重複、断片を含みます。使用している場合、ステータスを決定するための基準は、指定されなければなりません。
4.2.4 Sample Metrics resulting from combining parameters at MP(Src) and MP(Dst)
MP（SRC）及びMP（DST）でパラメータを組み合わせることから生じる4.2.4サンプルメトリック
Using the parameters above, a delay singleton would be calculated as follows:
次のように上記のパラメータを用いて、遅延シングルトンが計算されます。
+ Delay [i], for each packet [i], the time interval Delay[i] = Tstamp(Dst)[i] - Tstamp(Src)[i]
各パケットの遅延+ [i]は、[i]は、時間間隔遅延[I] = TSTAMP（DST）[I] - TSTAMP（SRC）[I]
For the following conditions, it will not be possible to compute delay singletons:
以下の条件の場合は、遅延シングルトンを計算することはできません。
Spurious: There will be no Tstamp(Src)[i] time Not received: There will be no Tstamp (Dst) [i] Corrupt packet header: There will be no Tstamp (Dst) [i] Duplicate: Only the first non-corrupt copy of the packet received at Dst should have Delay [i] computed.
スプリアス：NO TSTAMP（SRC）[i]の時間受信していないが存在しません：NO TSTAMP（DST）[i]が破損パケットのヘッダが存在しません：[i]が重複しないTSTAMP（DST）が存在しないであろう。のみ最初の非Dstので受信したパケットの破損したコピーは、遅延[i]が計算されている必要があります。
A sample metric for average delay is as follows
次のように平均遅延のサンプル・メトリックは、あります
AveDelay = (1/N)Sum(from i=1 to N, Delay[i])
AveDelay =（1 / N）合計（i = 1からN、遅延に[i]）と
assuming all packets i= 1 through N have valid singletons.
私は= N 1〜は、有効なシングルトンを持っているすべてのパケットを仮定。
A delay variation [5] singleton can also be computed:
遅延変動[5]シングルトンも計算することができます。
+ IPDV[i], for each packet [i] except the first one, delay variation between successive packets would be calculated as
+ IPDV [i]は、パケットごと[i]は最初のものを除いて、連続するパケット間の遅延変動は以下のように計算されます
IPDV[i] = Delay[i] - Delay [i-1]
IPDV [I] =ディレイ[I] - 遅延[I-1]
IPDV[i] may be negative, zero, or positive. Delay singletons for packets i and i-1 must be calculable or IPDV[i] is undefined.
IPDV [i]がゼロ、負、または正であってもよいです。パケットの遅延シングルトンはIとI-1が計算可能でなければならないか、IPDV [i]は未定義です。
An example metric for the IPDV sample is the range:
IPDVサンプルの例メトリックの範囲です。
RangeIPDV = max(IPDV[]) - min(IPDV[])
RangeIPDV = MAX（IPDV []） - 分（IPDV []）
Beginning on or after time T0, Type-P packets are generated by Src and sent to Dst until time Tf is reached with a nominal interval between the first bit of successive packets of incT, as measured at MP(Src). incT may be nominal due to a number of reasons: variation in packet generation at Src, clock issues (see section 4.6), etc. MP(Src) records the parameters above only for packets with timestamps between and including T0 and Tf having the required Src, Dst, and any other qualifiers. MP (Dst) also records for packets with time stamps between T0 and (Tf + dTstop).
時間T0以降に開始、タイプPパケットは、Srcによって生成され、時間TfがMP（SRC）で測定し、INCTの連続するパケットの最初のビットとの間の公称間隔に到達するまでのDstに送られます。 Srcのでパケット生成の変化、クロックの問題（セクション4.6を参照）、等MP（SRC）が唯一の必須を有するT0とTfとを含む間でタイムスタンプ付きパケットのための上記のパラメータを記録する：INCT起因理由の数に名目であってもよいです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以上でなければなりません。逆に、合理的、効率的なデータ収集を維持するために、dTstopはdTlossが無限または極端に長い場合でも、いくつかの合理的な時間間隔（秒/分/時間）でなければなりません。
This sampling methodology is intended to quantify the delays and the delay variation as experienced by multimedia streams of an application. Due to the definitions of these metrics, packet loss status is also recorded. The nominal interval between packets assesses network performance variations on a specific time scale.
このサンプリング方法は、アプリケーションのマルチメディアストリームが経験するような遅延と遅延変動を定量化することを意図しています。これらのメトリックの定義のため、パケットロスの状態も記録されています。パケット間の公称間隔は、特定のタイムスケールでネットワーク性能のばらつきを評価します。
There are a number of factors that should be taken into account when collecting a sample metric of Type-P-One-way-Delay-Periodic-Stream.
タイプP-ワンウェイ遅延周期ストリームのサンプルメトリックを収集する際に考慮すべき要素がいくつかあります。
+ The interval T0 to Tf should be specified to cover a long enough time interval to represent a reasonable use of the application under test, yet not excessively long in the same context (e.g. phone calls last longer than 100ms, but less than one week).
+ Tfとの間隔T0は、テスト中のアプリケーションの合理的な使用を表すために十分な長さの時間間隔をカバーするために指定され、まだない過度に長く同じ文脈にする必要があります（たとえば、電話の呼び出しが長く100msのより持続しますが、一週間以内） 。
+ 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）とパケットサイズ（S）（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のは非常に密接に同期することが重要であり得ることにより、10ミリ秒、100マイクロ秒ほど低くてもよいです。 GPSシステムは、マイクロ秒の数十の中に同期を達成する1つの方法を与えます。 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.}
与えられた方法論を+は、パケットが失われた又は遅れは、単に非常に大きいかどうか（およびパケット夏時間に到達するためにまだある）かどうかを決定する方法を含むことがあります。グローバルメトリックパラメータdTlossはdTlossより大きい遅延は損失として解釈されるように、時間間隔を定義します。 {コメント：多くのアプリケーションでは、無限/損失として大きな遅延の治療が重要でないであろう。通常のRTTの数倍の後にのみ到着例えばTCPデータパケットは、同様に失われた可能性があります。}
As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence).
他のタイプP- *メトリックと同様に、詳細な方法論は、タイプP（例えば、プロトコル番号、UDP / TCPポート番号、サイズ、優先度）に依存するであろう。
The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework RFC [3] provides general guidance on this point, but we note here the following specifics related to periodic streams and delay metrics:
任意の具体的な測定方法の説明は、会計及びエラーまたは不確定性のさまざまなソースの分析を含むべきです。フレームワークRFCは、[3]この点について一般的なガイダンスを提供していますが、ここでは定期的な流れと遅延メトリックに関連する以下の仕様に注意してください。
+ Error due to variation of incT. The reasons for this can be uneven process scheduling, possibly due to CPU load.
+ INCTの変動によるエラー。この理由は、CPUの負荷が原因の可能性が不均一なプロセススケジューリング、することができます。
+ Errors or uncertainties due to uncertainties in the clocks of the MP(Src) and MP(Dst) measurement points.
+によるMP（SRC）及びMP（DST）測定点のクロックの不確実性へのエラーまたは不確定要素。
+ Errors or uncertainties due to the difference between 'wire time' and 'host time'.
+エラーまたは「線時間」と「ホスト時間」との間の差に起因する不確実性。
The uncertainty in a measurement of one-way delay is related, in part, to uncertainties in the clocks of MP(Src) and MP(Dst). In the following, we refer to the clock used to measure when the packet was measured at MP(Src) as the MP(Src) clock and we refer to the clock used to measure when the packet was received at MP(Dst) as the MP(Dst) clock. Alluding to the notions of synchronization, accuracy, resolution, and skew, we note the following:
一方向遅延の測定における不確実性は、部分的に、MP（SRC）及びMP（DST）のクロックの不確実性に、関連しています。以下では、我々は、パケットがMP（SRC）クロックとしてMP（SRC）で測定したときに測定するために使用されると我々はクロックを参照し、パケットが（DST）MPで受信されたときに測定するために使用されるクロックを参照します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）クロックがTsynch先MP（DST）クロックのであればMP（SRC）クロックとMP（DST）クロックはTsynchの同期誤差を持っていることを言います。 [I] TSTAMP（SRC） - 私たちは正確Tsynchの値を知っていればこのように、我々は、TSTAMP（DST）[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）とResMP（DST）などのMP（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（トン）| <= 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（SRC）[I] Tsynch（T）+/-（ResMP（SRC）+ ResMP（DST））によってオフになる - 一緒にこれらのアイテムを取る、我々は、ナイーブ計算TSTAMP（DST）[i]のことに注意してください。 Esynch（t）の概念を使用して、我々はこれらのクロックに関連した問題がEsynch（T）+ Rsourceで+をRdestの総不確実性を導入することに注意してください。総クロックに関連する不確実性のこの推定値は、任意の測定実装の誤差/不確実性分析に含まれるべきです。
We would like to measure the time between when a packet is measured and time-stamped at MP(Src) and when it arrives and is time-stamped at MP(Dst); we refer to these as "wire times." However, if timestamps are applied by software on Src and Dst, then this software can only directly measure the time between when Src generates the packet just prior to sending the test packet and when Dst has started to process the packet after having received the test packet; we refer to these two points as "host times".
私たちは、パケットが測定され、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.
程度に、しかし、ワイヤ時間とホスト時間差が不確定であることを、この不確実性は、所定の測定方法の分析において考慮されなければなりません。我々はHsourceでSrcホスト上のMP（SRC）のワイヤ時間とホスト時間との差の不確かさの上限を示し、同様にDstのホスト上でホスト時間差及びMPのワイヤ時間Hdestを定義します（DST）。私たちは、その後、これらの問題がHsource + Hdestの総不確実性を導入することに注意してください。総ワイヤ対宿主不確実性のこの推定値は、任意の測定実装の誤差/不確実性分析に含まれるべきです。
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）時間の少なくとも95パーセントに - （E真値）が最小で、結合した（「E」）が報告された値が範囲内にあるように見出されるべきです。私たちは、測定のためのキャリブレーションエラー「E」と呼びます。これは、測定器によって生成される値が再現されている度合いを表します。すなわち、30ミリ秒の実際の遅延は、30ミリ秒として報告される方法密接にあります。 {コメント：95パーセントは、（1）いくつかの信頼レベルは、任意の物理的特性を測定する際に見出される異常値を除去することができることが望ましいように簡単に要約起因[4]で説明した理由のために選ばれました。 （2）独立した実装の結果を比較することができるように、特定の信頼レベルが指定されなければなりません。}
From the discussion in the previous two sections, the error in measurements could be bounded by determining all the individual uncertainties, and adding them together to form:
前の二つのセクションでの議論からは、測定の誤差はすべての個々の不確実性を判定することによって囲ますることができ、フォームにそれらを一緒に追加します：
Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest
Esynch（T）+ ResMP（SRC）+ ResMP（DST）+ Hsource + Hdest
However, reasonable bounds on both the clock-related uncertainty captured by the first three terms and the host-related uncertainty captured by the last two terms should be possible by careful design techniques and calibrating the instruments using a known, isolated, network in a lab.
しかし、最初の3つの項と最後の二つの用語によって捕捉ホスト関連の不確実性によって捕捉両方のクロック関連の不確実性に合理的な範囲は、慎重な設計技術によって可能とすべきである実験室で知られている、単離された、ネットワークを使用して機器を較正します。
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は、バックツーバック高速シリアルリンクまたは単離されたLANセグメントを有する2台の機器を接続することによって境界付けすることができます。この場合、反復測定は、同一の一方向遅延を測定しています。
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.5thパーセンタイルの範囲だろう。校正誤差「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.
ランダム誤差は、測定負荷の関数であることに注意してください。例えば、多くのパス一つ器によって測定される場合、これは、（測定値を記録する、例えば）割り込み、プロセススケジューリング、およびディスクI / Oを増加させる可能性があるすべてが測定シングルトンにランダム誤差を増大させることができます。したがって、系統的エラーを見つけるために最小の負荷測定に加えて、較正測定は、機器がフィールドに表示されるのと同じ測定負荷で行われるべきです。
We wish to reiterate that this statistical treatment refers to the calibration of the instrument; it is used to "calibrate the meter stick" and say how well the meter stick reflects reality.
私たちは、この統計的な治療は、機器のキャリブレーションを参照していることをあらためて表明したいです。 「メータースティックのキャリブレーション」とメータースティックが現実を反映してどれだけ言って使用されています。
The nominal interval between packets, incT, can vary during either active or passive measurements. In passive measurement, packet headers may include a timestamp applied prior to most of the protocol stack, and the actual sending time may vary due to processor scheduling. For example, H.323 systems are required to have packets ready for the network stack within 5 ms of their ideal time. There may be additional variation from the network between the Src and the
パケット間の公称間隔、INCTは、能動的または受動的のいずれかで測定中に変化することができます。受動的測定において、パケットヘッダは、従来のプロトコル・スタックのほとんどに適用されるタイムスタンプ、及びプロセッサ・スケジューリングのために変化し得る実際の送信時間を含むことができます。例えば、H.323システムは、その理想的な時間の5ミリ秒内のネットワークスタックの準備ができて、パケットが要求されています。 Srcとの間のネットワークからの追加の変動があるかもしれません
MP(Src). Active measurement systems may encounter similar errors, but to a lesser extent. These errors must be accounted for in some types of analysis.
MP（SRC）。能動的測定システムは、同様のエラーが発生したが、より少ない程度にしてもよいです。これらのエラーは、分析のいくつかのタイプに計上しなければなりません。
The calibration and context in which the method is used MUST be carefully considered, and SHOULD always be reported along with metric results. We next present five items to consider: the Type-P of test packets, the threshold of delay equivalent to loss, error calibration, the path traversed by the test packets, and background conditions at Src, Dst, and the intervening networks during a sample. This list is not exhaustive; any additional information that could be useful in interpreting applications of the metrics should also be reported.
この方法を用いたキャリブレーションとコンテキストが注意深く考慮されなければならない、と常にメトリック結果とともに報告します。我々考慮すべき次存在5つの項目：タイプPテストパケットの、試料中のSrc、Dstの、及び介在するネットワークにおける損失、誤差校正、試験パケットによって横断経路、背景条件に相当する遅延のしきい値。このリストは網羅的なものではありません。メトリックの用途を解釈するのに有用である可能性のある追加の情報も報告されるべきです。
As noted in the Framework document [3], the value of a metric may depend on the type of IP packets used to make the measurement, or "type-P". The value of Type-P-One-way-Periodic-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes. The exact Type-P used to make the measurements MUST be reported.
フレームワーク文書[3]で述べたように、メトリックの値が測定、または「タイプ-P」を作製するために使用されるIPパケットの種類に依存してもよいです。タイプP-一方向周期的ディレイの値は変更することができれば、特別な処置（例えば、IP precedenceまたはRSVP）変更するためのプロトコル（UDPまたはTCP）ポート番号、サイズ、または構成は。正確なタイプ-Pは、測定値が報告されなければならない作るために使用されます。
In addition, the threshold for delay equivalent to loss (or methodology to determine this threshold) MUST be reported.
また、（このしきい値を決定するために、または方法）の損失に相当する遅延の閾値を報告しなければなりません。
+ If the systematic error can be determined, it SHOULD be removed from the measured values. + You SHOULD also report the calibration error, e, such that the true value is the reported value plus or minus e, with 95% confidence (see the last section.) + If possible, the conditions under which a test packet with finite delay is reported as lost due to resource exhaustion on the measurement instrument SHOULD be reported.
+系統誤差を決定することができる場合には、測定値から除去されるべきです。 +また、真の値は、95％の信頼有限の遅延で（最後のセクションを参照してください。）+可能であれば、条件は下のテストパケットと、報告された値のプラスまたはマイナス電子であるように、電子、キャリブレーションエラーを報告する必要があります測定器の上に枯渇資源に失われたと報告されるべきであると報告されています。
The path traversed by the packets SHOULD be reported, if possible. In general, it is impractical to know the precise path a given packet takes through the network. The precise path may be known for certain Type-P packets on short or stable paths. If Type-P includes the record route (or loose-source route) option in the IP header, and the path is short enough, and all routers on the path support record (or loose-source) route, then the path will be precisely recorded.
可能な場合は、パケットが通過するパスは、報告する必要があります。一般に、与えられたパケットがネットワークを介してかかる正確なパスを知ることは非現実的です。正確なパスは、短いまたは安定した経路上の特定のタイプPのパケットのために知られてもよいです。タイプ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へ従って二つの別々の経路）を選択することができた場合、例えば、使用される最初のリンクは、貴重なコンテキストです。 {コメント：例えば、一の商業設定で一のNAP上のSrcは、いくつかの異なるバックボーンネットワークのいずれかによって別のNAP上のDstに達することができます。}
Fig.1 illustrates measurements on multiple protocol levels that are relevant to this memo. The user's focus is on transport quality evaluation from the application point of view. However, to properly separate the quality contribution of the operating system and codec on packet voice, for example, it is beneficial to be able to measure quality at the IP level [6]. Link layer monitoring provides a way of accounting for link layer characteristics such as bit error rates.
図1は、このメモに関連する複数のプロトコルレベルの測定を示します。ユーザーの焦点は、アプリケーションの観点から、輸送品質評価です。しかし、適切にパケット音声上のオペレーティングシステムおよびコーデックの品質寄与を分離するために、例えば、それはIPレベルでの品質を測定できることが有益である[6]。リンク層のモニタリングは、ビット誤り率などのリンクレイヤ特性の会計方法を提供します。
---------------
| application |
---------------
| transport | <--
---------------
| network | <--
---------------
| link | <--
---------------
| physical |
---------------
Fig. 1: Different possibilities for performing measurements: a protocol view. Above, "application" refers to all layers above L4 and is not used in the OSI sense.
図1：測定を実行するための異なる可能性：プロトコル・ビュー。上記、「アプリケーション」とは、L4上の全ての層を意味し、OSIの意味で使用されていません。
In general, the results of measurements may be influenced by individual application requirements/responses related to the following issues:
一般に、測定の結果は、以下の問題に関連した個々のアプリケーションの要求/応答によって影響され得ます。
+ Lost packets: Applications may have varying tolerance to lost packets. Another consideration is the distribution of lost packets (i.e. random or bursty).
+ロストパケット：アプリケーションは、失われたパケットに対する耐性を変化させている可能性があります。別の考慮事項は、（すなわち、ランダムまたはバースト）失われたパケットの分布です。
+ Long delays: Many applications will consider packets delayed longer than a certain value to be equivalent to lost packets (i.e. real time applications). + Duplicate packets: Some applications may be perturbed if duplicate packets are received. + Reordering: Some applications may be perturbed if packets arrive out of sequence. This may be in addition to the possibility of exceeding the "long" delay threshold as a result of being out of sequence. + Corrupt packet header: Most applications will probably treat a packet with a corrupt header as equivalent to a lost packet. + Corrupt packet payload: Some applications (e.g. digital voice codecs) may accept corrupt packet payload. In some cases, the packet payload may contain application specific forward error correction (FEC) that can compensate for some level of corruption. + Spurious packet: Dst may receive spurious packets (i.e. packets that are not sent by the Src as part of the metric). Many applications may be perturbed by spurious packets.
+ロング遅れ：多くのアプリケーションは、失われたパケット（すなわち、リアルタイムアプリケーション）に相当すると長く一定値以上遅れたパケットを検討します。 +重複パケット：重複したパケットを受信している場合、一部のアプリケーションでは、摂動することができます。 +並べ替え：パケットが順序が狂って到着した場合、一部のアプリケーションは摂動することができます。これは、順序が狂っているの結果として「長い」遅延しきい値を超える可能性に加えてもよいです。 +破損パケットヘッダ：ほとんどのアプリケーションは、おそらく失われたパケットと同等に壊れたヘッダを持つパケットを扱います。 +破損パケットペイロード：一部のアプリケーション（例えばデジタル音声コーデック）が破損パケットペイロードを受け入れることができます。いくつかのケースでは、パケットのペイロードは、腐敗のいくつかのレベルを補償することができるアプリケーション固有の前方誤り訂正（FEC）を含んでいてもよいです。 +スプリアスパケット：DSTがスプリアスパケット（メトリックの一部としてSrcによって送信されていない、すなわちパケット）を受信することができます。多くのアプリケーションでは、偽のパケットによって摂動することができます。
Depending, e.g., on the observed protocol level, some issues listed above may be indistinguishable from others by the application, it may be important to preserve the distinction for the operators of Src, Dst, and/or the intermediate network(s).
例えば、観測されたプロトコルレベルで、上に挙げたいくつかの問題は、アプリケーションによって他と区別できないかもしれ応じて、Src、Dstの、及び/又は中間ネットワーク（単数または複数）のオペレータのための区別を維持するために重要であり得ます。
This sampling method provides a way to perform measurements irrespective of the possible QoS mechanisms utilized in the IP network. As an example, for a QoS mechanism without hard guarantees, measurements may be used to ascertain that the "best" class gets the service that has been promised for the traffic class in question. Moreover, an operator could study the quality of a cheap, low-guarantee service implemented using possible slack bandwidth in other classes. Such measurements could be made either in studying the feasibility of a new service, or on a regular basis.
このサンプリング方法にかかわらず、IPネットワークで利用可能なQoSメカニズムの測定を実行する方法を提供します。例として、ハード保証なしのQoSメカニズムのために、測定値が「最良」のクラスが問題のトラフィッククラスに約束されたサービスを受けることを確認するために使用することができます。また、安い、低保証サービスの品質を調べることができ、オペレータは、他のクラスで可能たるみの帯域幅を使用して実装しました。このような測定は、新たなサービスの実現可能性を研究する上で、または定期的にどちらか作ることができます。
IP delivery service measurements have been discussed within the International Telecommunications Union (ITU). A framework for IP service level measurements (with references to the framework for IP performance [3]) that is intended to be suitable for service planning has been approved as I.380 [7]. ITU-T Recommendation I.380 covers abstract definitions of performance metrics. This memo describes a method that is useful, both for service planning and end-user testing purposes, in both active and passive measurements.
IP配信サービスの測定は、国際電気通信連合（ITU）の中に議論されています。サービス計画のために適切であることが意図されている（IP性能のためのフレームワークへの参照との[3]）IPサービスレベルの測定のためのフレームワークは、[7] I.380として承認されています。 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）との間の測定結果は、測定（例えば、<1ミリ秒の一般的な誤差マージン目標内、SrcとDstの間の測定の場合と同じでなければならないということである。失われた数パケット）と同じです。これが不可能な場合、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.
例えば - - 全二重ボイスオーバーIP（VoIP）の呼び出しを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）との間の中間の測定点を有することも可能であり、それは、この文書の範囲外です。
In the interests of specifying metrics that are as generally applicable as possible, application-level measurements based on one-way delays are used in the example metrics. The implication of application-level measurement for bi-directional applications, such as interactive multimedia conferencing, is discussed below.
一般的に適用可能としてある指標を特定の利益のために、一方向遅延に基づいて、アプリケーションレベルの測定は、例えばメトリックに使用されています。そのようなインタラクティブマルチメディア会議などの双方向アプリケーション用のアプリケーションレベルの測定の意味は、以下に説明されます。
Performing a single one-way measurement only yields information on network behavior in one direction. Moreover, the stream at the network transport level does not emulate accurately a full-duplex multimedia connection.
シングル一方向の測定を実行すると、一方向にのみネットワーク動作についての情報が得られます。また、ネットワーク・トランスポート・レベルでの流れを正確に全二重のマルチメディア接続をエミュレートしません。
Paired one way delay refers to two multimedia streams: Src to Dst and Dst to Src for the same Src and Dst. By way of example, for some applications, the delay performance of each one way path is more important than the round trip delay. This is the case for delay-limited signals such as VoIP. Possible reasons for the difference between one-way delays is different routing of streams from Src to Dst vs. Dst to Src.
同じSrcとDstのSRCにDstのとdstへのSrc：一対の一方向遅延は、2つのマルチメディアストリームを指します。一例として、いくつかのアプリケーションのために、それぞれ一方通行のパスの遅延性能は、ラウンドトリップ遅延よりも重要です。これは、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が120msの平均遅延を有しているDSTのsrcは、30ミリ秒の平均遅延を有していることを示してもよいです。往復遅延測定に、この例では150msの遅延の平均のようになります。非対称性の知識がなければ、私たちは、両端にアプリケーションが100ms以上の平均遅延に持って問題を欠場することがあります。
Moreover, paired one way delay measurement emulates a full-duplex VoIP call more accurately than a single one-way measurement only.
また、一方向遅延測定は、単一の一方向の測定よりも正確に、全二重VoIPコールをエミュレートペア。
From the point of view of periodic multimedia streams, round-trip measurements have two advantages: they avoid the need of host clock synchronization and they allow for a simulation of full-duplex communication. The former aspect means that a measurement is easily performed, since no special equipment or NTP setup is needed. The latter property means that measurement streams are transmitted in both directions. Thus, the measurement provides information on quality of service as experienced by two-way applications.
定期的なマルチメディアストリームの観点から、往復の測定値は、2つの利点があります：彼らは、ホストクロック同期の必要性を回避し、彼らは、全二重通信のシミュレーションを可能とします。かつての側面は、特別な機器やNTPのセットアップを必要としないため、測定が簡単に行われることを意味しています。後者の特性は、測定ストリームを両方向に送信されることを意味します。双方向アプリケーションが経験するようにこのように、測定は、サービスの品質に関する情報を提供します。
The downsides of round-trip measurement are the need for more bandwidth than a one-way test and more complex accounting of packet loss. Moreover, the stream that is returning towards the original sender may be more bursty than the one on the first "leg" of the round-trip journey. The last issue, however, means in practice that the returning stream may experience worse QoS than the out-going one, and the performance estimates thus obtained are pessimistic ones. The possibility of asymmetric routing and queuing must be taken into account during an analysis of the results.
往復測定の欠点は、一方向のテストより多くの帯域幅やパケット損失のより複雑な会計処理が必要です。また、元の送信者に向けて帰国されたストリームは、往復の旅の最初の「足」の1以上のバースト的かもしれません。最後の問題は、しかし、戻っストリームがアウトに行く1より悪いQoSを経験すること、そしてこのようにして得られたパフォーマンスの推定値は悲観的なものであることを実際に意味しています。非対称ルーティングとキューイングの可能性は、結果の分析中に考慮されなければなりません。
Note that with suitable arrangements, round-trip measurements may be performed using paired one way measurements.
適切な構成を用いて、ラウンドトリップ測定は一対の一方向の測定を用いて行われてもよいことに留意されたいです。
Some statistics may be particularly relevant to applications simulated by periodic streams, such as the range of delay values recorded during the sample.
いくつかの統計は、サンプル中に記録された遅延値の範囲のような周期的な流れによってシミュレートアプリケーション、特に関連し得ます。
For example, a sample metric generates 100 packets at MP(Src) with the following measurements at MP(Dst):
例えば、サンプルメトリックはMP（DST）で次の測定値とMP（SRC）で100個のパケットを生成します。
+ 80 packets received with delay [i] <= 20 ms + 8 packets received with delay [i] > 20 ms + 5 packets received with corrupt packet headers + 4 packets from MP(Src) with no matching packet recorded at MP(Dst) (effectively lost) + 3 packets received with corrupt packet payload and delay [i] <= 20 ms + 2 packets that duplicate one of the 80 packets received correctly as indicated in the first item
+ 80個のパケットが遅れて受信された[I] <= + 8つのパケットが遅れて受信された20のMS [I]> 5つのパケットがMPで記録該当するパケットとMP（SRC）から破損パケットヘッダ+ 4つのパケットで受信+ 20ミリ秒（DST ）（効果的に失われた）+ 3パケットが破損パケットペイロードで受信遅延最初の項目に示されているように[I] <= 80個のパケットのいずれかを複製する20ミリ秒+ 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%.
それらは以下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％です。
There may be value in running multiple tests using this method to collect a "sample of samples". For example, it may be more appropriate to simulate 1,000 two-minute VoIP calls rather than a single 2,000 minute call. When considering a collection of multiple samples, issues like the interval between samples (e.g. minutes, hours), composition of samples (e.g. equal Tf-T0 duration, different packet sizes), and network considerations (e.g. run different samples over different intervening link-host combinations) should be taken into account. For items like the interval between samples, the usage pattern for the application of interest should be considered.
「サンプルのサンプル」を収集するためにこの方法を使用して、複数のテストを実行中に値が存在してもよいです。例えば、千2分のVoIPコールではなく、単一の2000分の通話をシミュレートするために、より適切かもしれません。 （複数のサンプル、サンプル間の間隔のような問題（例えば分、時間）、サンプルの組成（例えば等しいTF-T0の期間、異なるパケットサイズ）、およびネットワークの考慮事項の収集を検討する場合例えば、異なる介在リンク - 上の異なるサンプルを実行しますホストの組み合わせ）が考慮されるべきです。サンプル間の間隔のような項目については、関心のあるアプリケーションの使用パターンを考慮すべきです。
When computing statistics for multiple samples, more general statistics (e.g. median, percentile, etc.) may have relevance with a larger number of packets.
複数のサンプルの統計を計算するとき、より一般的な統計（たとえば、中央値、パーセンタイルなど）はパケットのより大きな数の関連性を有していてもよいです。
In many cases, the results may be influenced by conditions at Src, Dst, and/or any intervening networks. Factors that may affect the results include: traffic levels and/or bursts during the sample, link and/or host failures, etc. Information about the background conditions may only be available by external means (e.g. phone calls, television) and may only become available days after samples are taken.
多くの場合、結果は、Src、Dstの条件で、および/または任意の介在するネットワークによって影響され得ます。結果に影響を与える可能性がある要因には、背景条件についてサンプル、リンクおよび/またはホスト障害時のトラフィックレベルおよび/またはバーストなどの情報のみを外部手段（例えば、電話、テレビ）で利用できるだけになることがありサンプル後の利用可能日が取られます。
For interactive multimedia sessions, end-to-end delay is an important factor. Too large a delay reduces the quality of the multimedia session as perceived by the participants. One approach for managing end-to-end delays on an Internet path involving heterogeneous link layer technologies is to use per-domain delay quotas (e.g. 50 ms for a particular IP domain). However, this scheme has clear inefficiencies, and can over-constrain the problem of achieving some end-to-end delay objective. A more flexible implementation ought to address issues like the possibility of asymmetric delays on paths, and sensitivity of an application to delay variations in a given domain. There are several alternatives as to the delay statistic one ought to use in managing end-to-end QoS. This question, although very interesting, is not within the scope of this memo and is not discussed further here.
インタラクティブなマルチメディアセッションでは、エンド・ツー・エンドの遅延は重要な要因です。参加者によって知覚される大きすぎる遅延は、マルチメディアセッションの品質を低減します。ヘテロジニアスリンク層技術を含むインターネットパス上のエンドツーエンド遅延を管理するための一つのアプローチは、ドメインごとの遅延割当量（特定のIPドメインの例えば50ミリ秒）を使用することです。しかし、この方式は、明確な非効率性を持っており、いくつかのエンドツーエンド遅延の目的を達成するための問題を過剰制約することができます。より柔軟な実装では、特定のドメインの変化を遅延させるために非対称の経路上の遅延、およびアプリケーションの感度の可能性のような問題に対処するべきです。 1は、エンドツーエンドのQoSを管理する際に使用するべき遅延統計についてのいくつかの選択肢があります。この質問は、非常に興味深いが、このメモの範囲内ではない、ここでさらに議論されていません。
This method generates a periodic stream of packets from one host (Src) to another host (Dst) through intervening networks. This method could be abused for denial of service attacks directed at Dst and/or the intervening network(s).
この方法は、介在するネットワークを介して別のホスト（DST）への1つのホスト（SRC）からのパケットの定期的なストリームを生成します。この方法は、Dstのおよび/または介在するネットワーク（複数可）に向けたサービス拒否攻撃のために悪用される可能性があります。
Administrators of Src, Dst, and the intervening network(s) should establish bilateral or multi-lateral agreements regarding the timing, size, and frequency of collection of sample metrics. Use of this method in excess of the terms agreed between the participants may be cause for immediate rejection, discard of packets, or other escalation procedures defined between the affected parties.
Src、Dstの、及び介在するネットワーク（複数可）の管理者は、サンプル・メトリックの収集のタイミング、サイズ、および頻度に関する両側またはマルチラテラル合意を確立すべきです。参加者の間で合意した条件を超えて、この方法を使用すると、即座に拒否の原因、パケットの破棄、または影響を受けた当事者間で定義されている他のエスカレーション手順かもしれません。
Active use of this method generates packets for a sample, rather than taking samples based on user data, and does not threaten user data confidentiality. Passive measurement must restrict attention to the headers of interest. Since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep this information safe and confidential.
この方法を積極的に使用することは、むしろ、ユーザデータに基づいてサンプルを取るよりも、サンプルのためのパケットを生成し、ユーザデータの機密性を脅かすものではありません。パッシブ測定は、関心のヘッダに注意を制限する必要があります。ユーザペイロードが一時的に長さ分析のために格納することができるので、適切な予防措置は、安全で機密情報を保持するために注意しなければなりません。
It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at Dst and/or the intervening networks, it is possible to change the processing of the packets (e.g. increasing or decreasing delay) that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement.
パケットの特定のパケット又はストリームは、試料の一部であることを識別することが可能です。 Dstのでその知識及び/又は介在ネットワークでは、測定された性能を歪めるかもしれない（例えば、増加または減少遅延）パケットの処理を変更することができます。また、サンプルのメトリックの一部であるように思われる追加のパケットを生成することも可能です。これらの追加のパケットはサンプル測定の結果を混乱させる可能性が高いです。
To discourage the kind of interference mentioned above, packet interference checks, such as cryptographic hash, MAY be used.
このような暗号ハッシュのようなパケット干渉チェックを、上記干渉の種類を阻止するために使用することができます。
Since this method and metric do not define a protocol or well-known values, there are no IANA considerations in this memo.
この方法及びメトリックプロトコルまたは既知の値を定義しないので、このメモにはIANA問題は存在しません。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[3]パクソン、V.、Almes、G.、Mahdavi、J.とM.マティス、 "IPパフォーマンス・メトリックのためのフレームワークを"、RFC 2330、1998年5月。
[4] Almes, G., Kalidindi, S. and M. Zekauskas, "A one-way delay metric for IPPM", RFC 2679, September 1999.
[4] Almes、G.、Kalidindi、S.及びM. Zekauskas、 "IPPMための一方向遅延メトリック"、RFC 2679、1999年9月。
[5] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[5]デミチェリス、C.およびP. Chimento、 "IPパフォーマンス・メトリックのためのIPパケット遅延変動メトリック（IPPM）"、RFC 3393、2002年11月。
[6] "End-to-end Quality of Service in TIPHON systems; Part 5: Quality of Service (QoS) measurement methodologies", ETSI TS 101 329-5 V1.1.2, January 2002.
[6]「エンド・ツー・エンドのTIPHONシステムにおけるサービスの品質;パート5：サービス品質（QoS）の測定方法」、ETSI TS 101 329から5 V1.1.2、2002年1月。
[7] International Telecommunications Union, "Internet protocol data communication service _ IP packet transfer and availability performance parameters", Telecommunications Sector Recommendation I.380 (re-numbered Y.1540), February 1999.
[7]国際電気通信連合、「インターネットプロトコルデータ通信サービス_ IPパケットの転送および可用性のパフォーマンスパラメータ」、電気通信セクター勧告I.380（再番号Y.1540）、1999年2月。
[8] Almes, G., Kalidindi, S. and M. Zekauskas, "A round-trip delay metric for IPPM", RFC 2681, September 1999.
[8] Almes、G.、Kalidindi、S.及びM. Zekauskas、 "IPPMのラウンドトリップ遅延メトリック"、RFC 2681、1999年9月。
The authors wish to thank the chairs of the IPPM WG (Matt Zekauskas and Merike Kaeo) for comments that have made the present document more clear and focused. Howard Stanislevic and Will Leland have also presented useful comments and questions. We also gratefully acknowledge Henk Uijterwaal's continued challenge to develop the motivation for this method. The authors have built on the substantial foundation laid by the authors of the framework for IP performance [3].
著者は現在ドキュメントがより明確になると集中してきたコメントにIPPM WGのいす（マットZekauskasとMerike Kaeoのを）感謝したいです。ハワードStanislevicとウィルリーランドにも有益なコメントや質問を提示しています。また、感謝して、この方法のためのモチベーションを開発するヘンクUijterwaalの継続的な挑戦を認めます。著者は、IP性能[3]のためのフレームワークの作者によって敷設かなりの基盤の上に構築されてきました。
Vilho Raisanen Nokia Networks P.O. Box 300 FIN-00045 Nokia Group Finland
Vilho Raisanenノキア・ネットワーク私書箱ボックス300 FIN-00045 Nokiaのグループフィンランド
Phone: +358 7180 8000 Fax: +358 9 4376 6852 EMail: Vilho.Raisanen@nokia.com
電話：+358 7180 8000ファックス：+358 9 4376 6852 Eメール：Vilho.Raisanen@nokia.com
Glenn Grotefeld Motorola, Inc. 1501 W. Shure Drive, MS 2F1 Arlington Heights, IL 60004 USA
グレンGrotefeldモトローラ社1501 W.シュアードライブ、MS 2F1アーリントンハイツ、IL 60004 USA
Phone: +1 847 435-0730 Fax: +1 847 632-6800 EMail: g.grotefeld@motorola.com
電話：+1 847 435-0730ファックス：+1 847 632-6800 Eメール：g.grotefeld@motorola.com
Al Morton AT&T Labs Room D3 - 3C06 200 Laurel Ave. South Middletown, NJ 07748 USA
アルモートンAT＆T LabsのルームD3 - 3C06 200ローレルアベニュー。南ミドルタウン、NJ 07748 USA
Phone: +1 732 420 1571 Fax: +1 732 368 1192 EMail: acmorton@att.com
電話：+1 732 420 1571ファックス：+1 732 368 1192 Eメール：acmorton@att.com
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 Editor機能のための基金は現在、インターネット協会によって提供されます。