[要約] RFC 3357は、ネットワークの一方向のパケット損失パターンを評価するためのサンプルメトリックを提供しています。このRFCの目的は、ネットワークのパフォーマンスを評価し、問題を特定するための基準を提供することです。
Network Working Group R. Koodli
Request for Comments: 3357 Nokia Research Center
Category: Informational R. Ravikanth
Axiowave
August 2002
One-way Loss Pattern Sample Metrics
一元配置損失パターンサンプルメトリック
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
Using the base loss metric defined in RFC 2680, this document defines two derived metrics "loss distance" and "loss period", and the associated statistics that together capture loss patterns experienced by packet streams on the Internet. The Internet exhibits certain specific types of behavior (e.g., bursty packet loss) that can affect the performance seen by the users as well as the operators. The loss pattern or loss distribution is a key parameter that determines the performance observed by the users for certain real-time applications such as packet voice and video. For the same loss rate, two different loss distributions could potentially produce widely different perceptions of performance.
RFC 2680で定義された基本損失メトリックを使用して、このドキュメントでは、2つの派生メトリック「損失距離」と「損失期間」と、インターネット上のパケットストリームが経験した損失パターンを一緒にキャプチャする関連統計を定義します。インターネットは、ユーザーとオペレーターが見たパフォーマンスに影響を与える可能性のある特定の種類の動作（たとえば、バーストパケット損失など）を示しています。損失パターンまたは損失分布は、パケット音声やビデオなどの特定のリアルタイムアプリケーションに対してユーザーが観察するパフォーマンスを決定する重要なパラメーターです。同じ損失率について、2つの異なる損失分布は、パフォーマンスの広く異なる認識を生み出す可能性があります。
Table of Contents
目次
1. Introduction 3
2. Terminology 3
3. The Approach 3
4. Basic Definitions 4
5. Definitions for Samples of One-way Loss Distance, and One-way
Loss Period 5
5.1. Metric Names . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 5
5.1.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 5
5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5
5.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 5
5.3.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 5
5.3.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 5
5.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
5.4.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 6
5.4.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 6
5.4.3. Examples . . . . . . . . . . . . . . . . . . . . 6
5.5. Methodologies . . . . . . . . . . . . . . . . . . . . . . 7
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
5.7. Sampling Considerations . . . . . . . . . . . . . . . . . 8
5.8. Errors and Uncertainties . . . . . . . . . . . . . . . . 8
6. Statistics 9
6.1. Type-P-One-Way-Loss-Noticeable-Rate . . . . . . . . . . . 9
6.2. Type-P-One-Way-Loss-Period-Total . . . . . . . . . . . . 9
6.3. Type-P-One-Way-Loss-Period-Lengths . . . . . . . . . . . 10
6.4. Type-P-One-Way-Inter-Loss-Period-Lengths . . . . . . . . 10
6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations 11
7.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
7.2. Privacy / Confidentiality . . . . . . . . . . . . . . . . 12
7.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations 12
9. Acknowledgements 12
10. Normative References 12
11. Informative References 13
Authors' Addresses 14
Full Copyright Statement 15
In certain real-time applications (such as packet voice and video), the loss pattern or loss distribution is a key parameter that determines the performance observed by the users. For the same loss rate, two different loss distributions could potentially produce widely different perceptions of performance. The impact of loss pattern is also extremely important for non-real-time applications that use an adaptive protocol such as TCP. Refer to [4], [5], [6], [11] for evidence as to the importance and existence of loss burstiness and its effect on packet voice and video applications.
特定のリアルタイムアプリケーション（パケット音声やビデオなど）では、損失パターンまたは損失分布は、ユーザーが観察したパフォーマンスを決定する重要なパラメーターです。同じ損失率について、2つの異なる損失分布は、パフォーマンスの広く異なる認識を生み出す可能性があります。損失パターンの影響は、TCPなどの適応プロトコルを使用する非リアルタイムアプリケーションにとっても非常に重要です。[4]、[5]、[6]、[11]を参照して、損失の爆発の重要性と存在、およびパケット音声およびビデオアプリケーションへの影響についての証拠を参照してください。
Previously, the focus of the IPPM had been on specifying base metrics such as delay, loss and connectivity under the framework described in RFC 2330. However, specific Internet behaviors can also be captured under the umbrella of the IPPM framework, specifying new concepts while reusing existing guidelines as much as possible. In this document, we propose two derived metrics, called "loss distance" and "loss period", with associated statistics, to capture packet loss patterns. The loss period metric captures the frequency and length (burstiness) of loss once it starts, and the loss distance metric captures the spacing between the loss periods. It is important to note that these metrics are derived based on the base metric Type-P-One-Way-packet-Loss.
以前は、IPPMの焦点は、RFC 2330で説明されているフレームワークの下での遅延、損失、接続などの基本メトリックの指定にありました。ただし、特定のインターネット動作は、IPPMフレームワークの傘の下でもキャプチャでき、再利用中に新しい概念を指定します。既存のガイドラインは可能な限り。このドキュメントでは、パケット損失パターンをキャプチャするために、関連する統計を使用して「損失距離」と「損失期間」と呼ばれる2つの派生メトリックを提案します。損失期間のメトリックは、開始後の損失の頻度と長さ（バーテンシー）をキャプチャし、損失距離メトリックは損失期間間の間隔をキャプチャします。これらのメトリックは、ベースメトリックタイプ-P-ne-way-packet-lossに基づいて導出されていることに注意することが重要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
キーワード「必須」、「しない」、「必須」、「必須」、「しなければ」、「そうしない」、「そうする必要はない」、「そうでない」、「推奨」、「5月」、「オプション」、および「静かに無視する「この文書では、BCP 14、RFC 2119 [2]に記載されているように解釈されます。
This document closely follows the guidelines specified in [3]. Specifically, the concepts of singleton, sample, statistic, measurement principles, Type-P packets, as well as standard-formed packets all apply. However, since the document proposes to capture specific Internet behaviors, modifications to the sampling process MAY be needed. Indeed, this is mentioned in [1], where it is noted that alternate sampling procedures may be useful depending on specific circumstances. This document proposes that the specific behaviors be captured as "derived" metrics from the base metrics the behaviors are related to. The reasons for adopting this position are the following:
このドキュメントは、[3]で指定されたガイドラインに密接に従います。具体的には、シングルトン、サンプル、統計、測定原則、タイプPパケット、および標準形式のパケットのすべてがすべて適用されます。ただし、ドキュメントは特定のインターネット動作をキャプチャすることを提案しているため、サンプリングプロセスの変更が必要になる場合があります。実際、これは[1]で言及されており、代替サンプリング手順は特定の状況に応じて役立つ可能性があることが指摘されています。このドキュメントは、特定の動作が、動作が関連しているベースメトリックから「導出された」メトリックとしてキャプチャされることを提案しています。この立場を採用する理由は次のとおりです。
- it provides consistent usage of singleton metric definition for different behaviors (e.g., a single definition of packet loss is needed for capturing burst of losses, 'm out of n' losses etc.)
- さまざまな動作のシングルトンメトリック定義の一貫した使用法を提供します（たとえば、損失のバーストをキャプチャするためにはパケット損失の単一の定義が必要です。
- it allows re-use of the methodologies specified for the singleton metric with modifications whenever necessary
- シングルトンメトリックに指定された方法論を必要なときに変更して再利用できます
- it clearly separates few base metrics from many Internet behaviors
- それは明らかに多くのインターネット動作からいくつかのベースメトリックを分離します
Following the guidelines in [3], this translates to deriving sample metrics from the respective singletons. The process of deriving sample metrics from the singletons is specified in [3], [1], and others.
[3]のガイドラインに従って、これはそれぞれのシングルトンからサンプルメトリックを導き出すことにつながります。シングルトンからサンプルメトリックを導出するプロセスは、[3]、[1]などで指定されています。
In the following sections, we apply this approach to a particular Internet behavior, namely the packet loss process.
次のセクションでは、このアプローチを特定のインターネット動作、つまりパケット損失プロセスに適用します。
Sequence number: Consecutive packets in a time series sample are given sequence numbers that are consecutive integers. This document does not specify exactly how to associate sequence numbers with packets. The sequence numbers could be contained within test packets themselves, or they could be derived through post-processing of the sample.
シーケンス番号：時系列サンプルの連続したパケットには、連続した整数であるシーケンス番号が与えられます。このドキュメントでは、シーケンス番号をパケットに関連付ける方法を正確に指定していません。シーケンス番号は、テストパケット自体に含めることも、サンプルの後処理を通じて導出することもできます。
Bursty loss: The loss involving consecutive packets of a stream.
バースト損失：ストリームの連続したパケットを含む損失。
Loss Distance: The difference in sequence numbers of two successively lost packets which may or may not be separated by successfully received packets.
損失距離：正常に受信されたパケットによって分離されている場合と分離されていない場合がある2つの連続して失われたパケットのシーケンス番号の差。
Example: In a packet stream, the packet with sequence number 20 is considered lost, followed by the packet with sequence number 50. The loss distance is 30.
例：パケットストリームでは、シーケンス番号20のパケットが失われたと見なされ、続いてシーケンス番号50のパケットが続きます。損失距離は30です。
Loss period: Let P_i be the i'th packet. Define f(P_i) = 1 if P_i is
lost, 0 otherwise. Then, a loss period begins if
f(P_i) = 1 and f(P_(i-1)) = 0
Example: Consider the following sequence of lost (denoted by x) and received (denoted by r) packets.
例：次の失われたシーケンス（xで示されます）および受信（Rで示される）パケットのシーケンスを考慮してください。
r r r x r r x x x r x r r x x x
r r r x r r x x x r x r r x x x
Then, with `i' assigned as follows, 1 1 1 1 1 1 i: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
次に、「I」が次のように割り当てられています、1 1 1 1 1 1 i：0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
f(P_i) is,
f（p_i）は、
f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1
f（p_i）：0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1
and there are four loss periods in the above sequence beginning at P_3, P_6, P_10, and P_13.
また、上記のシーケンスには、P_3、P_6、P_10、およびP_13から始まる4つの損失期間があります。
Src, the IP address of a host
SRC、ホストのIPアドレス
Dst, the IP address of a host
DST、ホストのIPアドレス
T0, a time
T0、時間
Tf, a time
TF、時間
lambda, a rate of any sampling method chosen in reciprocal of seconds
Lambda、秒単位で選択されたサンプリング方法のレート
A sequence of pairs of the form <loss distance, loss>, where loss is derived from the sequence of <time, loss> in [1], and loss distance is either zero or a positive integer.
フォーム<損失距離、損失>のペアのシーケンス。ここで、損失は[1]の<時間、損失>のシーケンスから導き出され、損失距離はゼロまたは正の整数のいずれかです。
A sequence of pairs of the form <loss period, loss>, where loss is derived from the sequence of <time, loss> in [1], and loss period is an integer.
フォームのペア<損失期間、損失>。ここで、損失は[1]の<時間、損失>のシーケンス、および損失期間は整数です。
When a packet is considered lost (using the definition in [1]), we look at its sequence number and compare it with that of the previously lost packet. The difference is the loss distance between the lost packet and the previously lost packet. The sample would consist of <loss distance, loss> pairs. This definition assumes that sequence numbers of successive test packets increase monotonically by one. The loss distance associated with the very first packet loss is considered to be zero.
パケットが失われたと見なされると（[1]の定義を使用）、そのシーケンス番号を調べて、以前に紛失したパケットのシーケンスと比較します。違いは、失われたパケットと以前に失われたパケットの間の損失距離です。サンプルは、<損失距離、損失>ペアで構成されます。この定義は、連続したテストパケットのシーケンス数が単調に増加することを前提としています。最初のパケット損失に関連する損失距離は、ゼロと見なされます。
The sequence number of a test packet can be derived from the timeseries sample collected by performing the loss measurement according to the methodology in [1]. For example, if a loss sample consists of <T0,0>, <T1,0>, <T2,1>, <T3,0>, <T4,0>, the sequence numbers of the five test packets sent at T0, T1, T2, T3, and T4 can be 0, 1, 2, 3 and 4 respectively, or 100, 101, 102, 103 and 104 respectively, etc.
テストパケットのシーケンス番号は、[1]の方法論に従って損失測定を実行することにより収集されたTimeseriesサンプルから導き出すことができます。たとえば、損失サンプルが<t0,0>、<t1,0>、<t2,1>、<t3,0>、<t4,0>で構成されている場合、T0で送信された5つのテストパケットのシーケンス番号、T1、T2、T3、およびT4は、それぞれ0、1、2、3、および4、またはそれぞれ100、101、102、103、104である可能性があります。
We start a counter 'n' at an initial value of zero. This counter is incremented by one each time a lost packet satisfies the definition outlined in 4. The metric is defined as <loss period, loss> where "loss" is derived from the sequence of <time, loss> in Type-P-One-Way-Loss-Stream [1], and loss period is set to zero when "loss" is zero in Type-P-One-Way-Loss-Stream, and loss period is set to 'n' (above) when "loss" is one in Type-P-One-Way-Loss-Stream.
ゼロの初期値でカウンター「n」を開始します。このカウンターは、失われたパケットが4で概説されている定義を満たすたびに1つずつ増加します。メトリックは<損失期間、損失>として定義されます。ここで、「損失」は<時間、損失>のシーケンスから導き出されます。-way-loss-stream [1]、および「損失」がタイプ-p-ne-wayloss-loss-streamでゼロの場合、損失期間はゼロに設定され、損失期間は「n」（上記）に設定されます。損失 "は、タイプ-1ウェイロスストリームの1つです。
Essentially, when a packet is lost, the current value of "n" indicates the loss period to which this packet belongs. For a packet that is received successfully, the loss period is defined to be zero.
基本的に、パケットが失われると、「n」の現在の値は、このパケットが属する損失期間を示します。正常に受信されるパケットの場合、損失期間はゼロと定義されます。
Let the following set of pairs represent a Type-P-One-Way-Loss-Stream.
次のペアのセットを、タイプP-One-Way-Loss-Streamを表します。
{<T1,0>,<T2,1>,<T3,0>,<T4,0>,<T5,1>,<T6,0>,<T7,1>,<T8,0>,
<T9,1>,<T10,1>}
where T1, T2,..,T10 are in increasing order.
ここで、T1、T2、..、T10は順序で増加しています。
Packets sent at T2, T5, T7, T9, T10 are lost. The two derived metrics can be obtained from this sample as follows.
T2、T5、T7、T9、T10で送信されるパケットは失われます。2つの派生メトリックは、次のようにこのサンプルから取得できます。
(i) Type-P-One-Way-Loss-Distance-Stream:
(i) Type-P-One-Way-Loss-Distance-Stream：
Since packet 2 is the first lost packet, the associated loss distance is zero. For the next lost packet (packet 5), loss distance is 5-2 or 3. Similarly, for the remaining lost packets (packets 7, 9, and 10) their loss distances are 2, 2, and 1 respectively. Therefore, the Type-P-One-Way-Loss-Distance-Stream is:
パケット2は最初の紛失パケットであるため、関連する損失距離はゼロです。次の失われたパケット（パケット5）の場合、損失距離は5-2または3です。同様に、残りの失われたパケット（パケット7、9、および10）では、それぞれ2、2、および1です。したがって、タイプ-P-One-Way-Loss-Distance-Streamは次のとおりです。
{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}
(ii) The Type-P-One-Way-Loss-Period-Stream:
（ii）タイプ-P-One-Way-Loss-PreioD-Stream：
The packet 2 sets the counter 'n' to 1, which is incremented by one for packets 5, 7 and 9 according to the definition in 4. However, for packet 10, the counter remains at 4, again satisfying the definition in 4. Thus, the Type-P-One-Way-Loss-Period-Stream is:
パケット2はカウンター「n」を1に設定します。これは、4の定義に従ってパケット5、7、9の1つで増加します。ただし、パケット10の場合、カウンターは4のままで、再び4の定義を満たします。したがって、タイプ-P-One-Way-Loss-PreioD-Streamは次のとおりです。
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}
The same methodology outlined in [1] can be used to conduct the sample experiments. A synopsis is listed below.
[1]で概説されている同じ方法を使用して、サンプル実験を行うことができます。概要を以下に示します。
Generally, for a given Type-P, one possible methodology would proceed as follows:
一般に、特定のタイプ-Pについて、1つの可能な方法論が次のように進行します。
- Assume that Src and Dst have clocks that are synchronized with each other. The degree of synchronization is a parameter of the methodology, and depends on the threshold used to determine loss (see below).
- SRCとDSTには、互いに同期されるクロックがあると仮定します。同期の程度は方法論のパラメーターであり、損失を決定するために使用されるしきい値に依存します（以下を参照）。
- At the Src host, select Src and Dst IP addresses, and form a test packet of Type-P with these addresses.
- SRCホストで、SRCおよびDST IPアドレスを選択し、これらのアドレスを使用してType-Pのテストパケットを形成します。
- At the Dst host, arrange to receive the packet.
- DSTホストで、パケットを受け取るように手配します。
- At the Src host, place a timestamp in the prepared Type-P packet, and send it towards Dst.
- SRCホストで、準備されたタイプPパケットにタイムスタンプを置き、DSTに送信します。
- If the packet arrives within a reasonable period of time, the one-way packet-loss is taken to be zero.
- 合理的な期間内にパケットが到着した場合、一方向パケットロスはゼロと見なされます。
- If the packet fails to arrive within a reasonable period of time, the one-way packet-loss is taken to be one. Note that the threshold of "reasonable" here is a parameter of the methodology.
- パケットが合理的な期間内に到着しない場合、一方向パケットロスは1つになっています。ここにある「合理的」のしきい値は、方法論のパラメーターであることに注意してください。
The Loss-Distance-Stream metric allows one to study the separation between packet losses. This could be useful in determining a "spread factor" associated with the packet loss rate. In conjunction, the Loss-Period-Stream metric allows the study of loss burstiness for each occurrence of loss. A single loss period of length 'n' can account for a significant portion of the overall loss rate. Note that it is possible to measure distance between loss bursts separated by one or more successfully received packets. (Refer to Sections 6.4 and 6.5).
損失距離ストリームメトリックにより、パケット損失間の分離を調べることができます。これは、パケット損失率に関連する「スプレッドファクター」を決定するのに役立ちます。併せて、損失期間ストリームメトリックは、損失の発生ごとに損失の乱れの研究を可能にします。長さ「n」の単一の損失期間は、全体的な損失率のかなりの部分を占めることができます。1つ以上の正常に受信したパケットによって区切られた損失バースト間の距離を測定することが可能であることに注意してください。（セクション6.4および6.5を参照）。
The proposed metrics can be used independent of the particular sampling method used. We note that Poisson sampling may not yield appropriate values for these metrics for certain real-time applications such as voice over IP, as well as to TCP-based applications. For real-time applications, it may be more appropriate to use the ON-OFF [10] model, in which an ON period starts with a certain probability 'p', during which a certain number of packets are transmitted with mean 'lambda-on' according to geometric distribution and an OFF period starts with probability '1-p' and lasts for a period of time based on exponential distribution with rate 'lambda-off'.
提案されたメトリックは、使用される特定のサンプリング方法とは無関係に使用できます。Poissonサンプリングは、TCPベースのアプリケーションだけでなく、Voice over IPなどの特定のリアルタイムアプリケーションにこれらのメトリックに適切な値をもたらさない場合があることに注意してください。リアルタイムアプリケーションの場合、オンオフ[10]モデルを使用する方が適切かもしれません。このモデルでは、期間が特定の確率「P」から始まり、その間に平均 'lambda-で特定の数のパケットが送信されます。「幾何学的分布によると、オフ期間は確率「1-p」から始まり、レート「ラムダオフ」の指数分布に基づいてしばらく続きます。
For TCP-based applications, one may use the model proposed in [8]. See [9] for an application of the model.
TCPベースのアプリケーションでは、[8]で提案されているモデルを使用できます。モデルの適用については[9]を参照してください。
The measurement aspects, including the packet size, loss threshold, type of the test machine chosen etc, invariably influence the packet loss metric itself and hence the derived metrics described in this document. Thus, when making an assessment of the results pertaining to the metrics outlined in this document, attention must be paid to these matters. See [1] for a detailed consideration of errors and uncertainties regarding the measurement of base packet loss metric.
パケットサイズ、損失のしきい値、選択したテストマシンのタイプなどを含む測定の側面は、常にパケット損失メトリック自体に影響を与え、したがってこのドキュメントで説明されている派生メトリックに影響します。したがって、このドキュメントで概説されているメトリックに関連する結果を評価する場合、これらの問題に注意を払う必要があります。ベースパケット損失メトリックの測定に関するエラーと不確実性の詳細な検討については、[1]を参照してください。
Define loss of a packet to be "noticeable" [7] if the distance between the lost packet and the previously lost packet is no greater than delta, a positive integer, where delta is the "loss constraint".
失われたパケットと以前に紛失したパケットの間の距離が「顕著」である[7]であると定義します。
Example: Let delta = 99. Let us assume that packet 50 is lost followed by a bursty loss of length 3 starting from packet 125. All the three losses starting from packet 125 are noticeable.
例：デルタ= 99としましょう。パケット50が失われた後、パケット125から始まる長さ3のバースト損失が続くと仮定してください。パケット125から始まる3つの損失はすべて顕著であると仮定します。
Given a Type-P-One-Way-Loss-Distance-Stream, this statistic can be computed simply as the number of losses that violate some constraint delta, divided by the number of losses. (Alternatively, it can also be defined as the number of "noticeable losses" to the number of successfully received packets). This statistic is useful when the actual distance between successive losses is important. For example, many multimedia codecs can sustain losses by "concealing" the effect of loss by making use of past history information. Their ability to do so degrades with poor history resulting from losses separated by close distances. By choosing delta based on this sensitivity, one can measure how "noticeable" a loss might be for quality purposes. The noticeable loss requires a certain "spread factor" for losses in the timeseries. In the above example where loss constraint is equal to 99, a loss rate of one percent with a spread of 100 between losses (e.g., 100, 200, 300, 400, 500 out of 500 packets) may be more desirable for some applications compared to the same loss rate with a spread that violates the loss constraint (e.g., 100, 175, 275, 290, 400: losses occurring at 175 and 290 violate delta = 99).
タイプ-P-One-Way-Loss-Distance-Streamを考えると、この統計は、拘束力のあるデルタに違反する損失の数として、損失の数で割ったものとして計算できます。（あるいは、正常に受信したパケットの数に対する「顕著な損失」の数として定義することもできます）。この統計は、連続した損失間の実際の距離が重要な場合に役立ちます。たとえば、多くのマルチメディアコーデックは、過去の歴史情報を使用することにより、損失の影響を「隠す」ことにより、損失を維持できます。そうする能力は、距離が近い距離で区切られた損失に起因する貧弱な歴史で劣化します。この感度に基づいてデルタを選択することにより、質の高い目的のために損失がどれほど「顕著」であるかを測定できます。顕著な損失には、タイムズリーの損失に特定の「スプレッドファクター」が必要です。損失の制約が99に等しい上記の例では、損失の損失率が100％の損失率（例：100、200、300、400、500パケットのうち500個）の間で100個のスプレッドが比較されます。損失の制約に違反するスプレッドで同じ損失率（例：100、175、275、290、400：175および290で発生する損失がDelta = 99に違反）。
This represents the total number of loss periods, and can be derived from the loss period metric Type-P-One-Way-Loss-Period-Stream as follows:
これは、損失期間の総数を表し、次のように損失期間メトリックタイプ-P-ne-way-loss-period-streamから導き出すことができます。
Type-P-One-Way-Loss-Period-Total = maximum value of the first entry of the set of pairs, <loss period, loss>, representing the loss metric Type-P-One-Way-Loss-Period-Stream.
Type-P-One-Way-Loss-PerioD-Total =ペアのセットの最初のエントリの最大値<損失期間、損失>。。
Note that this statistic does not describe the duration of each loss period itself. If this statistic is large, it does not mean that the losses are more spread out than they are otherwise; one or more loss periods may include bursty losses. This statistic is generally useful in gathering first order approximation of loss spread.
この統計は、各損失期間自体の期間を記述していないことに注意してください。この統計が大きい場合、損失がそうでないよりも広がっているという意味ではありません。1つ以上の損失期間には、破裂した損失が含まれる場合があります。この統計は、一般に、損失拡散の一次近似を収集するのに役立ちます。
This statistic is a sequence of pairs <loss period, length>, with the "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total. Thus the total number of pairs in this statistic equals Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is obtained by counting the number of pairs, <loss period, loss>, in the metric Type-P-One-Way-Loss-Period-Stream which have their first entry equal to "loss period."
この統計は、1-Type-p-ne-way-loss-period-totalの範囲の「損失期間」エントリを持つ一連のペア<損失期間>です。したがって、この統計のペアの総数は、タイプ-P-ne-way-loss-period-totalに等しくなります。各ペアで、「長さ」は、最初のエントリが「損失期間」に等しいメトリックタイプ-P-ne-way-loss-loss-period-streamでペア数、<損失期間、損失>をカウントすることによって取得されます。。」
Since this statistic represents the number of packets lost in each loss period, it is an indicator of burstiness of each loss period. In conjunction with loss-period-total statistic, this statistic is generally useful in observing which loss periods are potentially more influential than others from a quality perspective.
この統計は、各損失期間に失われたパケットの数を表しているため、各損失期間の破裂の指標です。損失期間統計と併せて、この統計は一般に、どの損失期間が品質の観点から他の人よりも潜在的に影響力があるかを観察するのに役立ちます。
This statistic measures distance between successive loss periods. It takes the form of a set of pairs <loss period, inter-loss-period-length>, with the "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total, and "inter-loss-period-length" is the loss distance between the last packet considered lost in "loss period" 'i-1', and the first packet considered lost in "loss period" 'i', where 'i' ranges from 2 to Type-P-One-Way-Loss-Period-Total. The "inter-loss-period-length" associated with the first "loss period" is defined to be zero.
この統計は、連続した損失期間間の距離を測定します。ペアのセット<損失期間、損失期間長>、「損失期間」エントリは1-Type-p-way-loss-period-total、および "interの範囲の形をとります。-loss-period-length "は、「損失期間」で失われたと見なされる最後のパケット間の損失距離です。Type-P-ne-way-loss-period-totalに。最初の「損失期間」に関連付けられている「低下期間長」は、ゼロと定義されています。
This statistic allows one to consider, for example, two loss periods each of length greater than one (implying loss burst), but separated by a distance of 2 to belong to the same loss burst if such a consideration is deemed useful. When the Inter-Loss-Period-Length between two bursty loss periods is smaller, it could affect the loss concealing ability of multimedia codecs since there is relatively smaller history. When it is larger, an application may be able to rebuild its history which could dampen the effect of an impending loss (period).
この統計では、たとえば、長さのそれぞれが1より大きい（損失の破裂を暗示する）2つの損失期間を考慮することができますが、そのような考慮が有用であるとみなされる場合、同じ損失バーストに属する距離2の距離で分離されます。2つのバースト損失期間の間の損失期間内の長さが小さくなると、比較的小さい歴史があるため、マルチメディアコーデックの損失の隠蔽能力に影響を与える可能性があります。それが大きい場合、アプリケーションは、差し迫った損失（期間）の影響を弱める可能性のある歴史を再構築できる可能性があります。
We continue with the same example as in Section 5.4.3. The three statistics defined above will have the following values.
セクション5.4.3と同じ例を継続します。上記の3つの統計には、次の値があります。
- Let delta = 2. In Type-P-One-Way-Loss-Distance-Stream
- Delta = 2とします。タイプ-P-One-Way-Loss-Distance-Streamで
{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>},
{<0,0>、<0,1>、<0,0>、<0,0>、<3,1>、<0,0>、<2,1>、<0,0>、<2,1>、<1,1>}、
there are 3 loss distances that violate the delta of 2. Thus, Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable losses)/(number of total losses))
2のデルタに違反する3つの損失距離があります。したがって、Type-P-ane-way-loss-noticable-rate = 3/5（（顕著な損失の数）/（総損失の数））
- In Type-P-One-Way-Loss-Period-Stream
- タイプ-P-One-Way-Loss-PreioD-Streamで
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
{<0,0>、<1,1>、<0,0>、<0,0>、<2,1>、<0,0>、<3,1>、<0,0>、<4,1>、<4,1>}、
the largest of the first entry in the sequence of <loss period,loss> pairs is 4. Thus,
<損失期間、損失>ペアのシーケンスの最初のエントリの最大は4です。したがって、したがって、
Type-P-One-Way-Loss-Period-Total = 4
- In Type-P-One-Way-Loss-Period-Stream
- タイプ-P-One-Way-Loss-PreioD-Streamで
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
{<0,0>、<1,1>、<0,0>、<0,0>、<2,1>、<0,0>、<3,1>、<0,0>、<4,1>、<4,1>}、
the lengths of individual loss periods are 1, 1, 1 and 2 respectively. Thus,
個々の損失期間の長さは、それぞれ1、1、1、および2です。したがって、
Type-P-One-Way-Loss-Period-Lengths =
タイプ-P-One-Way-Loss-PreioD-Lengths =
{<1,1>,<2,1>,<3,1>,<4,2>}
- In Type-P-One-Way-Loss-Period-Stream
- タイプ-P-One-Way-Loss-PreioD-Streamで
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
{<0,0>、<1,1>、<0,0>、<0,0>、<2,1>、<0,0>、<3,1>、<0,0>、<4,1>、<4,1>}、
the loss periods 1 and 2 are separated by 3 (5-2), loss periods 2 and 3 are separated by 2 (7-5), and 3 and 4 are separated by 2 (9-7). Thus, Type-P-One-Way-Inter-Loss-Period-Lengths =
損失期間1と2は3（5-2）で区切られ、損失期間2と3は2（7-5）で分離され、3と4は2（9-7）で分離されます。したがって、型-p-one-way-inter-loss-period-lengths =
{<1,0>,<2,3>,<3,2>,<4,2>}
Conducting Internet measurements raises both security and privacy concerns. This document does not specify a particular implementation of metrics, so it does not directly affect the security of the Internet nor of applications which run on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns.
インターネット測定を実施すると、セキュリティとプライバシーの両方の懸念が高まります。このドキュメントでは、メトリックの特定の実装を指定していないため、インターネットやインターネット上で実行されるアプリケーションのセキュリティに直接影響しません。ただし、これらのメトリックの実装は、セキュリティとプライバシーの懸念に留意する必要があります。
The derived sample metrics in this document are based on the loss metric defined in RFC 2680 [1], and thus they inherit the security considerations of that document. The reader should consult [1] for a more detailed treatment of security considerations. Nevertheless, there are a few things to highlight.
このドキュメントの派生したサンプルメトリックは、RFC 2680 [1]で定義されている損失メトリックに基づいているため、そのドキュメントのセキュリティ上の考慮事項を継承します。読者は、セキュリティ上の考慮事項のより詳細な扱いについては[1]に相談する必要があります。それにもかかわらず、強調すべきことがいくつかあります。
The lambda specified in the Type-P-Loss-Distance-Stream and Type-P-Loss-Period-Stream controls the rate at which test packets are sent, and therefore if it is set inappropriately large, it could perturb the network under test, cause congestion, or at worst be a denial-of-service attack to the network under test. Legitimate measurements must have their parameters selected carefully in order to avoid interfering with normal traffic in the network.
タイプ-PロスダイスタンスストリームおよびタイプPロス期間ストリームで指定されたラムダは、テストパケットが送信される速度を制御するため、不適切に大きく設定されている場合、テスト中のネットワークを混乱させる可能性があります。、輻輳を引き起こすか、最悪の場合、テスト中のネットワークへのサービス拒否攻撃を行います。正当な測定では、ネットワーク内の通常のトラフィックへの干渉を避けるために、パラメーターを慎重に選択する必要があります。
Privacy of user data is not a concern, since the underlying metric is intended to be implemented using test packets that contain no user information. Even if packets contained user information, the derived metrics do not release data sent by the user.
ユーザーデータのプライバシーは、ユーザー情報を含むテストパケットを使用して実装することを目的としているため、ユーザーデータのプライバシーは懸念事項ではありません。パケットにユーザー情報が含まれていても、派生したメトリックはユーザーから送信されたデータをリリースしません。
Results could be perturbed by attempting to corrupt or disrupt the underlying stream, for example adding extra packets that look just like test packets. To ensure that test packets are valid and have not been altered during transit, packet authentication and integrity checks, such as a signed cryptographic hash, MAY be used.
たとえば、テストパケットのように見える追加のパケットを追加するなど、基礎となるストリームを破損または破壊しようとすることにより、結果が乱される可能性があります。テストパケットが有効であり、トランジット中に変更されていないことを確認するために、署名された暗号化ハッシュなどのパケット認証と整合性チェックを使用できます。
Since this document does not define a specific protocol, nor does it define any well-known values, there are no IANA considerations for this document.
このドキュメントは特定のプロトコルを定義しておらず、よく知られている値を定義していないため、このドキュメントにはIANAの考慮事項はありません。
Matt Zekauskas provided insightful feedback and the text for the Security Considerations section. Merike Kao helped revising the Security Considerations and the Abstract to conform with RFC guidelines. We thank both of them. Thanks to Guy Almes for encouraging the work, and Vern Paxson for the comments during the IETF meetings. Thanks to Steve Glass for making the presentation at the Oslo meeting.
Matt Zekauskasは、セキュリティ上の考慮事項セクションの洞察に富んだフィードバックとテキストを提供しました。メリケーは、セキュリティの考慮事項と抽象的なRFCガイドラインに準拠するための抽象の改訂を支援しました。私たちは彼らの両方に感謝します。IETFミーティング中のコメントについては、作品を奨励してくれたGuy AlmesとVern Paxsonに感謝します。オスロ会議でプレゼンテーションを行ってくれたSteve Glassに感謝します。
[1] Almes, G., Kalindindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[1] Almes、G.、Kalindindi、S。、およびM. Zekauskas、「IPPMの一元配置パケット損失メトリック」、RFC 2680、1999年9月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[3] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[4] J.-C. Bolot and A. vega Garcia, "The case for FEC-based error control for Packet Audio in the Internet", ACM Multimedia Systems, 1997.
[4] J.-C.BolotとA. Vega Garcia、「インターネットでのパケットオーディオのFECベースのエラーコントロールの場合」、ACM Multimedia Systems、1997。
[5] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, "Internet Packet Loss: Measurement and Implications for End-to-End QoS," Proceedings, International Conference on Parallel Processing, August 1998.
[5] M. S. Borella、D。Swider、S。Uludag、およびG. B. Brewster、「インターネットパケットの損失：測定とエンドツーエンドQoSの影響」、Proceedings、1998年8月並列処理に関する国際会議。
[6] M. Handley, "An examination of MBONE performance", Technical Report, USC/ISI, ISI/RR-97-450, July 1997
[6] M.ハンドリー、「Mbone Performanceの調査」、テクニカルレポート、USC/ISI、ISI/RR-97-450、1997年7月
[7] R. Koodli, "Scheduling Support for Multi-tier Quality of Service in Continuous Media Applications", PhD dissertation, Electrical and Computer Engineering Department, University of Massachusetts, Amherst, MA 01003, September 1997.
[7] R. Koodli、「継続的なメディアアプリケーションにおける多層サービス品質のスケジューリングサポート」、PhD論文、マサチューセッツ大学、マサチューセッツ州アマースト、マサチューセッツ州01003、1997年9月。
[8] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP throughput: a simple model and its empirical validation", in Proceedings of SIGCOMM'98, 1998.
[8] J. Padhye、V。Firoiu、J。Kurose、およびD. Towsley、「モデリングTCPスループット：シンプルモデルとその経験的検証」、SigComm'98、1998の議事録。
[9] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly rate adjustment protocol for continuous media flows over best-effort networks", short paper presentation in ACM SIGMETRICS'99. Available as Umass Computer Science tech report from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz
[9] J. Padhye、J。Kurose、D。Towsley、R。Koodli、「ベストエフォルトネットワーク上の継続的なメディアフローのTCPフレンドリーレート調整プロトコル」、ACM Sigmetrics'99での短い論文プレゼンテーション。ftp://gaia.cs.umass.edu/pub/padhye98-tcp-friendly-tr.ps.gzからUMass Computer Science Techレポートとして入手可能
[10] K. Sriram and W. Whitt, "Characterizing superposition arrival processes in packet multiplexers for voice and data", IEEE Journal on Selected Areas of Communication, pages 833-846, September 1986,
[10] K. Sriram and W. Whitt、「音声とデータのためのパケットマルチプレクサの重ね合わせ到着プロセスの特徴」、IEEEジャーナルの選択されたコミュニケーション領域、ページ833-846、1986年9月、
[11] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation in the MBONE multicast network", Proceedings of IEEE Global Internet, London, UK, November 1996.
[11] M. Yajnik、J。Kurose、およびD. Towsley、「Mboneマルチキャストネットワークにおけるパケット損失相関」、1996年11月、英国のロンドン、ロンドンのIEEEグローバルインターネットの議事録。
Authors' Addresses
著者のアドレス
Rajeev Koodli Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
Rajeev Koodli Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View、CA 94043 USA
Phone: +1-650 625-2359
Fax: +1 650 625-2502
EMail: rajeev.koodli@nokia.com
Rayadurgam Ravikanth Axiowave Networks Inc. 200 Nickerson Road Marlborough, MA 01752 USA
Rayadurgam Ravikanth Axiowave Networks Inc. 200 Nickerson Road Marlborough、MA 01752 USA
EMail: rravikanth@axiowave.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。