[要約] RFC 5560は、1つの方向にパケットの複製を行うメトリックについての要約です。このRFCの目的は、ネットワークのパフォーマンス測定とトラブルシューティングを支援するために、パケットの複製に関する情報を提供することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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つのホストから別のホストにパケットが送信されると、通常、送信されたパケットの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 まず、Type-P-One-Way-Packet-Arrival-Countと呼ばれるSingletonメトリックが導入され、送信される各パケットの到着パケットの数を測定します。
o Then, a singleton metric, called Type-P-one-way-packet-duplication, is defined to describe a single instance of packet duplication.
o 次に、パケットの重複の単一インスタンスを記述するために、タイプ-P-One-Way-Packet Duplicationと呼ばれるSingleton Metricが定義されています。
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-One-way-packet-packet-duplication-poisson-stream、およびType-p-one-waypacket-packet-packet-doplication-periodic-streamを定義するために使用されます。これらは、パケット間のポアソン分散[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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つのホストから別のホストにパケットが送信されると、通常、送信されたパケットの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]。このメトリックは、パケットが到着する場合とパケットが妥当な時間内に到着しない場合を区別します。このメモでは、3番目の結果のメトリックが定義されています。単一のパケットが送信されますが、複数のコピーが到着します。
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-One-Way-Packet-Arrival-Count
o src, the IP address of a host
o SRC、ホストのIPアドレス
o dst, the IP address of a host
o DST、ホストの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:
次の場合にのみ、2つのパケットが同一と見なされます。
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.
SRCが送信したパケットの間隔[T、T0]のDSTが受け取った（腐敗していない）コピーの数を示す、タイプ-P-One-Way-Packet-Arrival-Countの値は正の整数数です。時間Tで
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.
輸送中にパケットが断片化され、何らかの理由で再組み立てが発生しない場合、パケットは失われたとみなされます。したがって、タイプ-PONE-PACKET-ARRIVAL-COUNTには含まれていません。
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.
メトリックは、送信中に破損していないパケットのみをカウントし、下層または中間デバイスによって自動的にresしている可能性があります。送信中に破損したが、それでも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.
クロックは、SRCとDSTの間で同期する必要があり、両側で間隔[t、t0]を一意に正確に決定できるようにします。
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パケットには存在せず、特により高い伝送速度でも、それぞれからパケットを区別するには十分ではない可能性があることに注意してください。
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-One-Way-Packet-Duplication
o src, the IP address of a host
o SRC、ホストのIPアドレス
o dst, the IP address of a host
o DST、ホストの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-One-way-packet-Duplicationの値は、間隔[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.
パケットが送信され、1つのコピーのみが間隔[t、t0]に到着する場合、メトリックは0です。この間隔にコピーが到着しない場合、メトリックは未定義です。アプリケーションは、この状態を示すために「不可能な」価値（-1）を報告する場合があります。
This metric is equal to:
このメトリックは次のとおりです。
Type-P-one-way-packet-arrival-count - 1
Type-P-One-Way-Packet-Arrival-Count-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-One-Way-Packet-Duplication-Poisson-Stream
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.
o Tで送信されたパケットのタイプ-P-One-WayPacket-Arrival-Count。
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、およびLambdaを考慮して、TSまたは前に、平均レートラムダで、TFで終了するか、TSで終了する擬似ランダムポアソンプロセスを計算します。TS以上の時間値、およびTF以下の時間値が選択されます。このプロセスの各時間で、タイプ-P-One-Way-Packet-Arrival-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-One-Way-Packet-Duplication-Preiodic-Stream
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.
o Tで送信されたパケットのタイプ-P-One-WayPacket-Arrival-Count。
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-One-Way-Packet-Arrival-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.
注：このセクションで説明する統計は、タイプ-P-One-Way-Packet-Duplication-Poisson-StreamとType-P-one-waypacket-packet-packet-packet-doplication-periodic-streamの両方に使用できます。アプリケーションは、どのサンプルが入力として使用されたかを報告する必要があります。
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-One-Way-Packet-Duplication-Poisson-Streamを考えると、最初に定義されていないType-P-One-Way-Packet重複のすべての値を削除します。ストリーム内の残りのペアの場合、1つは次のことを計算します（合計-P-one-way-packet-arrival-count/neft lefted）-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-One-Way-Packet-Duplication-Poisson-Streamを考えると、最初に定義されていないType-P-One-Way-Packet-Arrival-Countのすべての値を削除します。ストリーム内の残りのペアの場合、タイプパケットパケットアリーバルカウントのペア数が1を超えています。次に、この基準を満たすパケットの割合を合計の割合として計算します。。（言い換えれば：（重複したパケットの数）/（紛失していないパケットの数）。）
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)
（1、2、3、4）
and arriving as:
そして到着：
o Case 1: (1, 2, 3, 4)
o ケース1：（1、2、3、4）
o Case 2: (1, 1, 2, 2, 3, 3, 4, 4)
o ケース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 ケース3：（1、1、1、2、2、2、3、3、3、4、4、4）
o Case 4: (1, 1, 1, 2, 3, 3, 3, 4)
o ケース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：ストリームで複製されたパケットはありません。また、タイプ-P-One-WayPacket-Duplication-FractionとType-P-One-Way-Packet-Replicated-Packet-Rateの両方が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：すべてのパケットが1回複製され、タイプ-P-ne-way-packet-duplication-fractionは100％です。Type-P-One-Way Replicated-Packet-Rateも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：すべてのパケットが2回複製されるため、タイプ-P-ne-way-packet-duplication-fractionは200％です。Type-P-One-Way複製パケットレートはまだ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：パケットの半分が2回複製され、残りの半分が複製されていません。タイプ-P-One-WayPacket-Duplication-Fractionは再び100％であり、この数値はケース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-One-way-packet-Duplication-rateでは、ケース2と3の違いは表示されません。これについては、タイプ-P-One-Packet-Duplication-Fraction-Fractionを調べる必要があります。
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）（およびその他の順列）はすべて、タイプ-PONE-PACKET-DUPLICATION-FRACTIONとタイプの同じ結果をもたらします-p-one-way-eplicated-packet-rate。
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レポート文書のAl Morton、Stanislav Shalunov、Emile Stephan、および著者との会議で登場しました。
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.
最後に、Lars Eggert、Al Morton、Martin Swany、Matt Zekauskasのコメントに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Morton、「定期的なストリームによるネットワークパフォーマンス測定」、RFC 3432、2002年11月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4148] Stephan、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
Henk Uijterwaal Ripe NCC Singel 258 1016 AB AMSTERDAM THE ONELLANDS
Phone: +31 20 535 4444
EMail: henk@ripe.net