Network Working Group H. Uijterwaal
Request for Comments: 5560 RIPE NCC
Category: Standards Track May 2009
A One-Way Packet Duplication Metric
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.
パケットが他のホストに送信されると、1は正常に送信されたパケットの正確に一つのコピーが目的地に到着することを期待しています。パケットが失われたか、または複数のコピーが到着いずれかであることが可能です。
In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams.
以前の研究では、パケットロスのメトリックが定義されました。このメトリックは、送信されたパケットが妥当な時間内にその宛先に到達しない場合を定量化します。パケットが送信されるが、複数のコピーが到着このメモでは、別の場合のメトリックが定義されます。文書はまた、ストリームの結果を要約する流れと方法について説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
1.2. Motivation .................................................4
2. A Singleton Definition for One-Way Packet Arrival Count .........4
2.1. Metric Name ................................................4
2.2. Metrics Parameters .........................................4
2.3. Metric Units ...............................................4
2.4. Definition .................................................4
2.5. Discussion .................................................5
2.6. Methodology ................................................6
2.7. Errors and Uncertainties ...................................6
2.8. Reporting the Metric .......................................6
3. A Singleton Definition for One-Way Packet Duplication ...........6
3.1. Metric Name ................................................6
3.2. Metrics Parameters .........................................7
3.3. Metric Units ...............................................7
3.4. Definition .................................................7
3.5. Discussion .................................................7
4. Definition for Samples for One-Way Packet Duplication ...........7
4.1. Poisson Streams ............................................7
4.1.1. Metric Name .........................................7
4.1.2. Metric Parameters ...................................8
4.1.3. Metric Units ........................................8
4.1.4. Definition ..........................................8
4.1.5. Methodology .........................................8
4.1.6. Errors and Uncertainties ............................8
4.1.7. Reporting the Metric ................................8
4.2. Periodic Streams ...........................................9
4.2.1. Metric Name .........................................9
4.2.2. Metric Parameters ...................................9
4.2.3. Metric Units ........................................9
4.2.4. Definition ..........................................9
4.2.5. Methodology .........................................9
4.2.6. Errors and uncertainties ............................9
4.2.7. Reporting the metric ...............................10
5. Some Statistics Definitions for One-Way Duplication ............10
5.1. Type-P-one-way-packet-duplication-fraction ................10
5.2. Type-P-one-way-replicated-packet-rate .....................10
5.3. Examples ..................................................11
6. Security Considerations ........................................12
7. IANA Considerations ............................................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
This document defines a metric for one-way packet duplication across Internet paths. It builds on the IP Performance Metrics (IPPM) Framework document [RFC2330]; the reader is assumed to be familiar with that document.
このドキュメントはインターネットパス間で一方向のパケット重複のためのメトリックを定義します。これは、IPパフォーマンス・メトリック（IPPM）フレームワークドキュメント[RFC2330]に基づいています。読者は、その文書に精通しているものとします。
This document follows the same structure as the document for one-way packet loss [RFC2680]; the reader is assumed to be familiar with that document as well.
この文書では、一方向のパケット損失[RFC2680]のための文書と同じ構造を以下。読者は、同様に、その文書に精通しているものとします。
The structure of this memo is as follows:
次のようにこのメモの構造は次のとおりです。
o First, a singleton metric, called Type-P-one-way-packet-arrival-count, is introduced to measure the number of arriving packets for each packet sent.
Oまず、タイプP-片道パケット到着カウントと呼ばれるメトリックシングルトンは、送られた各パケットの到着するパケットの数を測定するために導入されます。
o Then, a singleton metric, called Type-P-one-way-packet-duplication, is defined to describe a single instance of packet duplication.
Oそして、タイプP-一方向パケット複製と呼ばれるメトリックシングルトンは、パケットの複製の単一のインスタンスを記述するために定義されています。
o Next, this singleton metric is used to define samples, Type-P-one-way-Packet-Duplication-Poisson-Stream and Type-P-one-way-Packet-Duplication-Periodic-Stream. These are introduced to measure duplication in a series of packets sent with either Poisson-distributed [RFC2680] or periodic [RFC3432] intervals between the packets.
O次に、このシングルトンメトリックは、サンプルを定義するために使用され、タイプP-一方向-パケット複製-ポアソンストリームとTYPE-Pをワンウェイパケット複製周期ストリーム。これらは、ポアソン分布[RFC2680]またはパケット間の周期的な[RFC3432]の間隔のいずれかで送信されたパケットの直列重複を測定するために導入されます。
o Finally, statistics that summarize the properties of these samples are introduced.
O最後に、これらのサンプルの性質をまとめた統計が導入されています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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 the results of measurements from two different implementations are comparable and to note instances when an implementation could perturb the network.
RFC 2119を念頭にプロトコルで書かれていたが、キーワードは、同様の理由でこの文書で使用されています。これらは同等であり、実装がネットワークを乱すことができるときのインスタンスを注意するために、2つの異なる実装からの測定の結果を確実にするために使用されます。
When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.
パケットが他のホストに送信されると、1は正常に送信されたパケットの正確に一つのコピーが目的地に到着することを期待しています。パケットが失われたか、または複数のコピーが到着いずれかであることが可能です。
In earlier work, a metric for packet loss was defined [RFC2680]. This metric distinguishes between cases where the packet arrives and where the packet does not arrive within a reasonable time. In this memo, a metric for a third outcome is defined: a single packet is sent, but multiple copies arrive.
以前の研究では、パケットロスのためのメトリックは、[RFC2680]を定義しました。このメトリックは、パケットが到着すると、パケットが合理的な期間内に到着しない場合が区別されます。単一のパケットが送信されるが、複数のコピーが到着する：このメモでは、第三の結果のメトリックが定義されます。
As this document describes a case similar to the one discussed in [RFC2680], all considerations from that document on timing and accuracy apply.
このドキュメントは[RFC2680]で説明したものと同様の場合について説明したように、タイミング及び精度にその文書からのすべての考慮事項が当てはまります。
Type-P-one-way-packet-arrival-count
タイプ-P-片道パケット到着カウント
o src, the IP address of a host
OのSRC、ホストのIPアドレス
o dst, the IP address of a host
ホストのDST O、IPアドレス
o T, the wire time of a packet at the source
O T、元のパケットのワイヤ時間
o T0, the maximum waiting time for a packet to arrive at the destination.
O T0、パケットが宛先に到達するための最大待機時間。
An integer number.
整数。
Two packets are considered identical if and only if:
二つのパケットは、場合にのみ、同一とみなされます。
o Both contain identical information fields (see Section 2.5). The recipient thus could take either packet and use the data in an application. The other packet does not contain any additional information.
Oの両方が同一の情報フィールド（セクション2.5を参照）を含みます。受信者は、このようにどちらかのパケットを取得し、アプリケーション内のデータを使用することができます。他のパケットは、任意の追加情報が含まれていません。
o Both packets appear to have been sent by one and the same host, to one and the same destination. Hosts are identified by their IP addresses.
O両方のパケットは、同一の宛先に、一つの同じホストによって送信されてきたように見えます。ホストは、そのIPアドレスによって識別されます。
The value of a Type-P-one-way-packet-arrival-count is a positive integer number indicating the number of (uncorrupted and identical) copies received by dst in the interval [T, T+T0] for a packet sent by src at time T.
タイプP-一方向パケット到着カウントの値は、によって送信されたパケットのための間隔[T、T + T0]でDSTによって受信（破損していないと同一）のコピー数を示す正の整数であります時間TでSRC
If a packet is sent, but it is lost or does not arrive in the interval [T, T+T0], then the metric is undefined. Applications MAY report an "impossible" value (for example, -1) to indicate this condition instead of undefined.
パケットが送信され、それが失われた又は間隔[T、T + T0]に到着しない場合、メトリックは未定義です。アプリケーションは「不可能」の値を報告することがあり（例えば、-1）の代わりに、未定義のこの状態を示すために。
If a packet is fragmented during transport and if, for whatever reason, reassembly does not occur, then the packet will be deemed lost. It is thus not included in the Type-P-one-way-packet-arrival-count.
パケットが輸送中や何らかの理由で、再構築が発生していない、場合に断片化されている場合は、パケットが失われたものとみなされます。それは、このように、タイプP-片道パケット到着カウントに含まれません。
This metric counts the number of packets arriving for each packet sent. The time-out value T0 SHOULD be set to a value when the application could potentially still use the packet and would not discard it automatically.
このメトリックは、送信された各パケットのために到着するパケットの数をカウントします。アプリケーションが潜在的にまだパケットを使用することができますし、それを自動的に廃棄しないだろうというとき、タイムアウト値T0は値に設定する必要があります。
If this metric is used in parallel with the Packet Loss Metric [RFC2680], the value of T0 MUST be the same for both cases in order to keep the results comparable.
このメトリックは、パケット損失メトリック[RFC2680]と並行して使用される場合、T0の値は、同等の結果を維持するために、両方の場合で同じでなければなりません。
The metric only counts packets that are not corrupted during transmission and may have been resent automatically by lower layers or intermediate devices. Packets that were corrupted during transmission but, nevertheless, still arrived at dst are not counted.
メトリックは、送信中に破損していないと下部層または中間デバイスによって自動的に再送信された可能性がパケットをカウントします。送信中に破損したが、それにもかかわらず、まだDSTに到着したパケットはカウントされません。
Clocks do have to be synchronized between src and dst such that it is possible to uniquely and accurately determine the interval [T, T+T0] at both sides.
クロックは、一意かつ正確両側に間隔[T、T + T0]を決定することが可能であるように、SRCとDSTの間で同期されなければなりません。
If this metric is used in an active measurement system, the system MUST NOT send multiple packets with identical information fields in order to avoid that all packets will be declared duplicates. This metric can be used inside a passive measurement system as well, using packets generated by another source. However, if the source can send two identical packets within the interval [T, T+T0], this will be incorrectly labeled as a duplicate, resulting in a false positive. It is up to the implementor to estimate if this scenario is likely to happen and the rate of false positives that is acceptable.
このメトリックは、アクティブな測定システムで使用されている場合、システムはすべてのパケットが重複して宣言されることを避けるために、同一の情報フィールドを持つ複数のパケットを送ってはいけません。このメトリックは、他のソースによって生成されたパケットを使用して、同様に受動的測定システム内で使用することができます。ソースは、[T、T + T0]間隔内の2つの同一のパケットを送信することができる場合は、これは誤って偽陽性を生じる、重複として標識されます。それは、このシナリオが発生する可能性があると受け入れられる偽陽性の割合場合推定するのに実装次第です。
The definition of identical information fields is such that two packets are considered to be identical if they are sent from the same source and contain the same information. This does not necessarily mean that all bits in the packet are the same. For example, when a packet is replicated and the copies are transferred along different paths, the Time to Live (TTL) may be different. The implementation MUST specify which fields are compared when deciding whether or not two packets are identical.
同一の情報フィールドの定義は、それらが同じソースから送られてきたと同じ情報が含まれている場合、2つのパケットが同じであると考えられるようなものです。これは、必ずしもパケット内のすべてのビットが同じであることを意味するものではありません。パケットが複製され、コピーが異なる経路に沿って転送される場合、例えば、生存時間（TTL）が異なっていてもよいです。実装は、2つのパケットが同一であるか否かを決定する際に比較されるフィールドを指定しなければなりません。
In the case of IPv4, these will usually be: version, ihl, identification, src, dst, protocol, some or all upper-layer protocol data.
IPv4の場合において、これらは、通常、次のようになりますバージョン、IHL、識別、SRC、DST、プロトコル、一部またはすべての上位層プロトコルデータ。
In IPv6, these will usually be: version, next header, source, destination, some or all upper-layer protocol data
IPv6では、これらは、通常、次のようになりますバージョン、次ヘッダ、送信元、宛先、一部またはすべての上位層プロトコルデータ
Note that the use of the identification field is not present in non-fragmented IPv6 packets and may not be sufficient to distinguish packets from each even in IPv4, particularly at higher transmission speeds
識別フィールドの使用は、非断片化IPv6パケットに存在しないと特に高い伝送速度であってもIPv4のそれぞれからパケットを区別するのに十分ではないかもしれないことに注意してください
The basic technique to measure this metric follows the methodology described in Section 2.6 of [RFC2680] with one exception.
このメトリックを測定するための基本的な技術は、1つの例外を除いて、[RFC2680]のセクション2.6に記載の方法に従います。
[RFC2680] does not specify that the receiving host should be able to receive multiple copies of a single packet, as it only needs one copy to determine the metrics. Implementations for this metric should obviously be capable of receiving multiple copies.
[RFC2680]は、それが唯一のメトリックを決定するために、1つのコピーを必要とするように、受信ホストは、単一パケットの複数のコピーを受信することができなければならないことを指定しません。このメトリックの実装は明らかに複数のコピーを受信することが可能でなければなりません。
Refer to Section 2.7 of [RFC2680].
[RFC2680]のセクション2.7を参照してください。
Refer to Section 2.8 of [RFC2680].
[RFC2680]のセクション2.8を参照してください。
Type-P-one-way-packet-duplication
タイプP-1ウェイパケット重複
o src, the IP address of a host
OのSRC、ホストのIPアドレス
o dst, the IP address of a host
ホストのDST O、IPアドレス
o T, the wire time of a packet at the source
O T、元のパケットのワイヤ時間
o T0, the maximum waiting time for a packet to arrive at the destination.
O T0、パケットが宛先に到達するための最大待機時間。
An integer number.
整数。
The value of a Type-P-one-way-packet-duplication is a positive integer number indicating the number of (uncorrupted and identical) additional copies of an individual packet received by dst in the interval [T, T+T0] as sent by src at time T.
送信されたタイプP-一方向パケット複製の値は、区間[T、T + T0]でDSTによって受信された個々のパケットの（破損していないと同一の）追加コピーの数を示す正の整数であります時間Tのsrcで
If a packet is sent and only one copy arrives in the interval [T, T+T0], then the metric is 0. If no copy arrives in this interval, then the metric is undefined. Applications MAY report an "impossible" value (for example, -1) to indicate this condition.
パケットが送信され、唯一のコピーは、区間[T、T + T0]に到着している場合は何もコピーはこの区間では、メトリックが定義されていない到着しない場合、メトリックは0です。アプリケーションは、（例えば、-1）この状態を示すために「不可能」の値を報告することがあります。
This metric is equal to:
このメトリックは、以下に等しいです。
Type-P-one-way-packet-arrival-count - 1
タイプ-P-片道パケット到着カウント - 1
This metric is expected to be used for applications that need to know duplication for an individual packet. All considerations regarding methodology, errors, and reporting from the previous section apply.
このメトリックは、個々のパケットの重複を知っておく必要があるアプリケーションのために使用されることが期待されます。すべての方法論についての考察、エラー、前のセクションからの報告が適用されます。
Type-P-one-way-Packet-Duplication-Poisson-Stream
タイプP-1ウェイパケット複製・ポアソンストリーム
o src, the IP address of a host.
O SRC、ホストのIPアドレス。
o dst, the IP address of a host.
O DST、ホストのIPアドレス。
o Ts, a time.
O Tsと、時間。
o Tf, a time. Ts and Tf specify the time interval when packets can be sent for this stream.
O Tfは、時間。パケットはこのストリームのために送信することができたときにTsとTfは時間間隔を指定します。
o T0, the maximum waiting time for a packet to arrive at the destination.
O T0、パケットが宛先に到達するための最大待機時間。
o lambda, a rate in reciprocal seconds.
Oラムダ、相反秒率。
A sequence of pairs; the elements of each pair are:
ペアの配列;各対の要素は次のとおりです。
o T, a time
O T、時間
o Type-P-one-way-packet-arrival-count for the packet sent at T.
T.で送信されたパケットのためのO型-P-片道パケット到着カウント
Given Ts, Tf, and lambda, we compute a pseudo-random Poisson process beginning at or before Ts, with average-rate lambda, and ending at or after Tf. Those time values greater than or equal to Ts, and less than or equal to Tf are then selected. At each of the times in this process, we obtain the value of Type-P-one-way-packet-arrival-count. The value of the sample is the sequence made up of the resulting {time, duplication} pairs. If there are no such pairs, the sequence is of length zero, and the sample is said to be empty.
TsとTfは、ラムダを考えると、我々は、擬似ランダムポアソン過程の平均レートのラムダではTsで以前に開始する、とのTfで以降に終了を計算します。これらの時間は、より大きい又はTSに等しい値、および以下のTfに等しいが、選択されています。このプロセスの時間の各々で、我々は、Type-P-片道パケット到着-countの値を取得します。サンプルの値が得られた{時、重複}ペアからなる配列です。そのようなペアが存在しない場合、配列の長さはゼロであり、そしてサンプルが空であると言われています。
Refer to Section 3.6 of [RFC2680].
[RFC2680]のセクション3.6を参照。
Refer to Section 3.7 of [RFC2680].
[RFC2680]のセクション3.7を参照してください。
Refer to Section 3.8 of [RFC2680].
[RFC2680]のセクション3.8を参照。
Type-P-one-way-Packet-Duplication-Periodic-Stream
タイプP-1ウェイパケット複製・定期的なストリーム
o src, the IP address of a host.
O SRC、ホストのIPアドレス。
o dst, the IP address of a host.
O DST、ホストのIPアドレス。
o Ts, a time.
O Tsと、時間。
o Tf, a time. Ts and Tf specify the time interval when packets can be sent for this stream.
O Tfは、時間。パケットはこのストリームのために送信することができたときにTsとTfは時間間隔を指定します。
o T0, the maximum waiting time for a packet to arrive at the destination.
O T0、パケットが宛先に到達するための最大待機時間。
o lambda, a rate in reciprocal seconds.
Oラムダ、相反秒率。
A sequence of pairs; the elements of each pair are:
ペアの配列;各対の要素は次のとおりです。
o T, a time
O T、時間
o Type-P-one-way-packet-arrival-count for the packet sent at T.
T.で送信されたパケットのためのO型-P-片道パケット到着カウント
At time Ts, we start sending packets with a constant-rate lambda, until time Tf. For each packet sent, we obtain the value of Type-P-one-way-packet-arrival-count. The value of the sample is the sequence made up of the resulting {time, duplication} pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty.
時間Tsで、我々は時間Tfまで、一定の速度のラムダを持つパケットの送信を開始します。送信された各パケットのために、私たちはタイプP-片道パケット到着-countの値を取得します。サンプルの値が得られた{時、重複}ペアからなる配列です。そのようなペアが存在しない場合、配列の長さはゼロであり、試料は、空であると言われます。
Refer to Section 4.5 of [RFC3432].
[RFC3432]の4.5節を参照してください。
Refer to Section 4.6 of [RFC3432].
[RFC3432]のセクション4.6を参照。
Refer to Section 4.7 of [RFC3432].
[RFC3432]の4.7節を参照してください。
Note: the statistics described in this section can be used for both Type-P-one-way-Packet-Duplication-Poisson-Stream and Type-P-one-way-Packet-Duplication-Periodic-Stream. The application SHOULD report which sample was used as input.
注：このセクションで説明する統計は、Type-P-一方向-パケット複製-ポアソンストリームの両方とType-P-一方向-パケット複製周期ストリームのために使用することができます。アプリケーションは、入力として使用されたサンプルを報告しなければなりません。
This statistic gives the fraction of additional packets that arrived in a stream.
この統計は、ストリームに到着した追加パケットの割合を示します。
Given a Type-P-one-way-Packet-Duplication-Poisson-Stream, one first removes all values of Type-P-one-way-Packet-Duplication that are undefined. For the remaining pairs in the stream, one calculates: (Sum Type-P-one-way-packet-arrival-count/Number of pairs left) - 1 (In other words, (number of packets received)/(number of packets sent and not lost).)
タイプP-1ウェイパケット複製・ポアソン・ストリームを考えると、最初のものが定義されていないタイプ-P-1ウェイパケット重複のすべての値を削除します。ストリームの残りのペアについて、一方が計算：（左のペアの合計タイプP-一方向パケット到着カウント/番号） - パケットのすなわち1（、（パケットの数は、受信）/（数送信されません）失われました。）
The number can be expressed as a percentage.
数百分率として表すことができます。
Note: this statistic is the equivalent to the Y.1540 IPDR [Y1540].
注：この統計は、Y.1540 IPDR [Y1540]と等価です。
This statistic gives the fraction of packets that was duplicated (one or more times) in a stream.
この統計は、ストリームに（1回以上）複製されたパケットの割合を示します。
Given a Type-P-one-way-Packet-Duplication-Poisson-Stream, one first removes all values of Type-P-one-way-packet-arrival-count that are undefined. For the remaining pairs in the stream, one counts the number of pairs with Type-P-one-way-packet-arrival-count greater than 1. Then, one calculates the fraction of packets that meet this criterion as a fraction of the total. (In other words: (number of duplicated packets)/(number of packets sent and not lost).)
タイプP-1ウェイパケット複製・ポアソン・ストリームを考えると、最初のものが定義されていないタイプ-P-片道パケット到着カウントのすべての値を削除します。ストリームの残りのペアについて、一方は、次に1より大きいタイプP-一方向パケット到着カウント一つは合計の割合として、この基準を満たすパケットの割合を計算するとペアの数をカウント。 （言い換えれば、重複パケットの（数）/（送信されないパケットの数）が失われました。）
The number can be expressed as a percentage.
数百分率として表すことができます。
Note: this statistic is the equivalent of the Y.1540 RIPR [Y1540].
注意：この統計は、Y.1540 RIPR [Y1540]に相当します。
Consider a stream of 4 packets, sent as:
送ら4つのパケットの流れを考えてみます。
(1, 2, 3, 4)
（１、 ２、 ３、 ４）
and arriving as:
到着：
o Case 1: (1, 2, 3, 4)
お かせ １： （１、 ２、 ３、 ４）
o Case 2: (1, 1, 2, 2, 3, 3, 4, 4)
お かせ ２： （１、 １、 ２、 ２、 ３、 ３、 ４、 ４）
o Case 3: (1, 1, 1, 2, 2, 2, 3, 3, 3, 4, 4, 4)
お かせ ３： （１、 １、 １、 ２、 ２、 ２、 ３、 ３、 ３、 ４、 ４、 ４）
o Case 4: (1, 1, 1, 2, 3, 3, 3, 4)
お かせ ４： （１、 １、 １、 ２、 ３、 ３、 ３、 ４）
Case 1: No packets are duplicated in a stream, and both the Type-P-one-way-packet-duplication-fraction and the Type-P-one-way-packet-replicated-packet-rate are 0.
ケース1：なしパケットはストリーム内で重複しない、およびType-P-一方向パケット複製画分とType-P-一方向-パケット複製パケットレートの両方が0されています。
Case 2: Every packet is duplicated once, and the Type-P-one-way-packet-duplication-fraction is 100%. The Type-P-one-way-replicated-packet-rate is 100%, too.
ケース2：すべてのパケットが一度複製され、およびType-P-1ウェイパケット重複分率は100％です。タイプP-一方向-複製パケット・レートも、100％です。
Case 3: Every packet is duplicated twice, so the Type-P-one-way-packet-duplication-fraction is 200%. The Type-P-one-way-replicated-packet-rate is still 100%.
ケース3：すべてのパケットが二回重複しているので、タイプP-1ウェイパケット重複分率が200％です。タイプP-一方向-複製パケットレートは依然として100％です。
Case 4: Half the packets are duplicated twice and the other half are not duplicated. The Type-P-one-way-packet-duplication-fraction is again 100%, and this number does not show the difference with case 2. However, the Type-P-one-way-packet-replicated-packet-rate is 50% in this case and 100% in case 2.
ケース4：ハーフパケットが二回重複していると、他の半分は複製されません。タイプP-一方向パケット複製画分は再び100％であり、この数値は、Type-P-一方向-パケット複製パケットレートである、しかし、ケース2との違いを示しませんこの場合の50％とケース2で100％。
However, the Type-P-one-way-packet-duplication-rate will not show the difference between cases 2 and 3. For this, one has to look at the Type-P-one-way-packet-duplication-fraction.
しかし、タイプP-1ウェイパケット重複率は、このために例2と3の間の差を表示しません、1はタイプP--パケット重複分率一方向を見ています。
Finally, note that the order in which the packets arrived does not affect the results. For example, these variations of case 2:
最後に、パケットが到着する順番は結果に影響を与えないことに注意してください。例えば、ケース2のこれらの変化：
o Case 2a: (1, 1, 2, 2, 3, 3, 4, 4)
Oケース2A：（1、1、2、2、3、3、4、4）
o Case 2b: (1, 2, 3, 4, 1, 2, 3, 4)
Oケース2b：（1、2、3、4、1、2、3、4）
o Case 2c: (1, 2, 3, 4, 4, 3, 2, 1) (as well as any other permutation) all yield the same results for Type-P-one-way-packet-duplication-fraction and the Type-P-one-way-replicated-packet-rate.
Oケース2c：（1、2、3、4、4、3、2、1）（ならびに他の任意の順列）全てがタイプP-一方向パケット複製画分とのために同一の結果をもたらしますタイプ-P-片道-、複製パケットレート。
Conducting Internet measurements raises both security and privacy concerns. This memo does not specify an implementation of the metrics, so it does not directly affect the security of the Internet nor of applications that run on the Internet. However, implementations of these metrics must be mindful of security and privacy concerns.
インターネット測定を行うことは、両方のセキュリティとプライバシーの問題を提起します。このメモは、メトリックの実装を指定していないので、直接インターネットのも、インターネット上で動作するアプリケーションのセキュリティに影響を与えません。しかし、これらのメトリックの実装では、セキュリティとプライバシーの問題に留意する必要があります。
There are two types of security concerns: potential harm caused by the measurements and potential harm to the measurements. The measurements could cause harm because they are active, and they inject packets into the network. The measurement parameters MUST be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases, cause congestion and denial of service.
測定によって引き起こされる潜在的な害や測定に潜在的な危害：セキュリティ上の問題の2つのタイプがあります。彼らがアクティブであるため、測定値は害を引き起こす可能性があり、彼らはネットワークにパケットを注入します。測定は、彼らが測定ネットワークに追加トラフィックの些細な量を注入するように測定パラメータを慎重に選択しなければなりません。彼らは「あまりにも多くの」トラフィックを注入した場合、彼らはサービスの測定、および極端な場合には、原因の渋滞と拒否の結果を歪曲することができます。
The measurements themselves could be harmed by routers giving measurement traffic a different priority than "normal" traffic or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss rate will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability that measurement traffic can be distinguished from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks.
測定自体は、測定トラフィックに「正常な」トラフィックや人工的な測定トラフィックを注入することにより、攻撃者は異なる優先順位を与えるルータによって悪影響を受ける可能性があります。ルータは、測定トラフィックを認識し、個別に扱うことができた場合は、測定値は、実際のユーザトラフィックが反映されません。攻撃者は正当なものとして受け入れている人工的なトラフィックを注入した場合、損失率を人為的に低下させることになります。したがって、測定方法は、測定トラフィックが「正常な」トラフィックと区別することができる確率を低減するための適切な技術を含むべきです。そのようなデジタル署名などの認証技術は、注入されたトラフィックの攻撃を防ぐために適切な場合に使用することができます。
The privacy concerns of network measurement are limited by the active measurements described in this memo. Unlike passive measurements, there can be no release of existing user data.
ネットワーク測定のプライバシーの問題は、このメモに記載の活性測定によって制限されています。受動的な測定とは異なり、既存のユーザーデータのない解放はありえません。
IANA has registered the metrics defined in this document in the IP Performance Metrics (IPPM) Metrics Registry, see [RFC4148].
IANAは、IPパフォーマンス・メトリック（IPPM）メトリクスレジストリ、[RFC4148]を参照して、この文書で定義されたメトリックが登録されています。
The idea to write this document came up in a meeting with Al Morton, Stanislav Shalunov, Emile Stephan, and the author on the IPPM reporting document.
この文書を書くためのアイデアはアル・モートン、スタニスラフ・シャルノブ、エミール・ステファン、そしてIPPM報告書の執筆者との会合で思い付きました。
This document relies heavily on [RFC2680], and the author would like to thank the authors of that document for writing it.
この文書では、[RFC2680]に大きく依存している、と著者はそれを書くために、その文書の作成者に感謝したいと思います。
Finally, thanks are due to Lars Eggert, Al Morton, Martin Swany, and Matt Zekauskas for their comments.
最後に、おかげで彼らのコメントのためのラースエッゲルト、アル・モートン、マーティン・スワニー、そしてマット・Zekauskasに起因するものです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMための一方向パケット損失メトリック"、RFC 2680、1999年9月。
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002.
[RFC3432] Raisanen、V.、Grotefeld、G.、およびA.モートン、 "定期的なストリームとのネットワークパフォーマンスの測定"、RFC 3432、2002年11月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4148]ステファン、E.、 "IPパフォーマンス・メトリック（IPPM）メトリクスレジストリ"、BCP 108、RFC 4148、2005年8月。
[Y1540] "Y.1540 ITU-T Recommendation Y.1540 (2007), Internet protocol data communication service IP packet transfer and availability performance parameters.", 2007.
[Y1540] "Y.1540 ITU-T勧告Y.1540（2007）、インターネットプロトコルデータ通信サービスIPパケット転送と可用性性能パラメータ。"、2007。
Author's Address
著者のアドレス
Henk Uijterwaal RIPE NCC Singel 258 1016 AB Amsterdam The Netherlands
ヘンクUijterwaal RIPE NCCシンゲル258 1016 ABアムステルダムオランダ
Phone: +31 20 535 4444 EMail: henk@ripe.net
電話：+31 20 535 4444 Eメール：henk@ripe.net