[要約] RFC 7680は、IPパフォーマンスメトリックス（IPPM）のための片方向の損失メトリックを定義しています。このRFCの目的は、ネットワークのパフォーマンスを評価するための標準的な方法を提供することです。
Internet Engineering Task Force (IETF) G. Almes
Request for Comments: 7680 Texas A&M
STD: 82 S. Kalidindi
Obsoletes: 2680 Ixia
Category: Standards Track M. Zekauskas
ISSN: 2070-1721 Internet2
A. Morton, Ed.
AT&T Labs
January 2016
A One-Way Loss Metric for IP Performance Metrics (IPPM)
IPパフォーマンスメトリック（IPPM）のための一方向損失メトリック
Abstract
概要
This memo defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete.
このメモは、インターネットパス間でのパケットの一方向損失のメトリックを定義します。これは、IP Performance Metrics（IPPM）フレームワークドキュメントRFC 2330で導入および説明されている概念に基づいています。読者はそのドキュメントに精通していると想定されます。このメモはRFC 2680を時代遅れにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7680.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7680で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. General Issues regarding Time . . . . . . . . . . . . . . 6
2. A Singleton Definition for One-Way Packet Loss . . . . . . . 7
2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7
2.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Errors and Uncertainties . . . . . . . . . . . . . . . . 10
2.8. Reporting the Metric . . . . . . . . . . . . . . . . . . 11
2.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 11
2.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 11
2.8.3. Calibration Results . . . . . . . . . . . . . . . . . 11
2.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 12
3. A Definition for Samples of One-Way Packet Loss . . . . . . . 12
3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 13
3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13
3.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 14
3.7. Errors and Uncertainties . . . . . . . . . . . . . . . . 15
3.8. Reporting the Metric . . . . . . . . . . . . . . . . . . 15
4. Some Statistics Definitions for One-Way Packet Loss . . . . . 15
4.1. Type-P-One-way-Packet-Loss-Ratio . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Changes from RFC 2680 . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
This memo defines a metric for one-way packet loss across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, [RFC2330]; the reader is assumed to be familiar with that document and its recent update [RFC7312].
このメモは、インターネットパスでの一方向のパケット損失のメトリックを定義します。これは、IPPMフレームワークドキュメント[RFC2330]で導入および説明されている概念に基づいています。読者は、そのドキュメントとその最新の更新[RFC7312]に精通していると想定されます。
This memo is intended to be parallel in structure to a companion document for One-way Delay ("A One-Way Delay Metric for IP Performance Metrics (IPPM)") [RFC7679]; the reader is assumed to be familiar with that document.
このメモは、一方向の遅延（ "IPパフォーマンスメトリック（IPPM）の片方向の遅延メトリック"）[RFC7679]の関連ドキュメントと構造が並行することを目的としています。読者はそのドキュメントに精通していると想定されます。
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]. Although [RFC2119] 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.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。 [RFC2119]はプロトコルを念頭に置いて作成されましたが、この文書では同様の理由でキーワードを使用しています。これらは、2つの異なる実装からの測定結果が比較可能であることを確認し、実装がネットワークに影響を与える可能性がある場合に注意するために使用されます。
Whenever a technical term from the IPPM Framework document is first used in this memo, it will be tagged with a trailing asterisk. For example, "term*" indicates that "term" is defined in the Framework document.
このメモでIPPMフレームワークドキュメントの技術用語が最初に使用される場合は常に、末尾のアスタリスクでタグ付けされます。たとえば、「term *」は、「term」がフレームワークドキュメントで定義されていることを示します。
The structure of the memo is as follows:
メモの構造は次のとおりです。
o A 'singleton*' analytic metric, called Type-P-One-way-Packet-Loss, is introduced to measure a single observation of packet transmission or loss.
o Type-P-One-way-Packet-Lossと呼ばれる「singleton *」分析メトリックは、パケットの送信または損失の単一の観測値を測定するために導入されています。
o Using this singleton metric, a 'sample*' called Type-P-One-way-Packet-Loss-Poisson-Stream is introduced to measure a sequence of singleton transmissions and/or losses measured at times taken from a Poisson process, as defined in Section 11.1.1 of [RFC2330].
o このシングルトンメトリックを使用して、Type-P-One-way-Packet-Loss-Poisson-Streamと呼ばれる「サンプル*」が導入され、定義されているように、ポアソンプロセスから取得された時間に測定されたシングルトン伝送および/または損失のシーケンスを測定します[RFC2330]のセクション11.1.1。
o Using this sample, several 'statistics*' of the sample will be defined and discussed.
o このサンプルを使用して、サンプルのいくつかの「統計*」を定義して説明します。
This progression from singleton to sample to statistics, with clear separation among them, is important.
シングルトンからサンプル、統計、そしてそれらの間の明確な分離を伴うこの進行は重要です。
Understanding one-way packet loss of Type-P* packets from a source host* to a destination host is useful for several reasons:
送信元ホスト*から宛先ホストへのType-P *パケットの一方向パケット損失を理解すると、いくつかの理由で役立ちます。
o Some applications do not perform well (or at all) if end-to-end loss between hosts is large relative to some threshold value.
o 一部のアプリケーションは、ホスト間のエンドツーエンドの損失がいくつかのしきい値と比較して大きい場合、うまく機能しない（またはまったく機能しない）。
o Excessive packet loss may make it difficult to support certain real-time applications (where the precise threshold of "excessive" depends on the application).
o 過度のパケット損失は、特定のリアルタイムアプリケーションのサポートを困難にする場合があります（「過剰」の正確なしきい値はアプリケーションによって異なります）。
o The larger the value of packet loss, the more difficult it is for transport-layer protocols to sustain high bandwidths.
o パケット損失の値が大きいほど、トランスポート層プロトコルが高帯域幅を維持することが困難になります。
o The sensitivity of real-time applications and of transport-layer protocols to loss become especially important when very large delay-bandwidth products must be supported.
o リアルタイムアプリケーションとトランスポート層プロトコルの損失に対する感度は、非常に大きな遅延帯域幅製品をサポートする必要がある場合に特に重要になります。
The measurement of one-way loss instead of round-trip loss is motivated by the following factors:
往復損失ではなく一方向損失の測定は、次の要因によって動機付けられます。
o In today's Internet, the path from a source to a destination may be different than the path from the destination back to the source ("asymmetric paths"), such that different sequences of routers are used for the forward and reverse paths. Therefore, round-trip measurements actually measure the performance of two distinct paths together. Measuring each path independently highlights the performance difference between the two paths that may traverse different Internet service providers and even radically different types of networks (for example, research versus commodity networks, or networks with asymmetric link capacities, or wireless versus wireline access).
o 今日のインターネットでは、送信元から宛先へのパスは、宛先から送信元へのパスとは異なる場合があり（ "非対称パス"）、ルーターの異なるシーケンスがフォワードパスとリバースパスに使用されます。したがって、往復測定では、実際には2つの異なるパスのパフォーマンスを一緒に測定します。各パスを個別に測定すると、異なるインターネットサービスプロバイダー、さらには根本的に異なるタイプのネットワーク（たとえば、研究ネットワークとコモディティネットワーク、または非対称リンクキャパシティのあるネットワーク、またはワイヤレスアクセスと有線アクセス）を通過する2つのパス間のパフォーマンスの違いが明らかになります。
o Even when the two paths are symmetric, they may have radically different performance characteristics due to asymmetric queuing.
o 2つのパスが対称である場合でも、非対称キューイングにより、パフォーマンス特性が根本的に異なる場合があります。
o Performance of an application may depend mostly on the performance in one direction. For example, a TCP-based communication will experience reduced throughput if congestion occurs in one direction of its communication. Troubleshooting may be simplified if the congested direction of TCP transmission can be identified.
o アプリケーションのパフォーマンスは、主に一方向のパフォーマンスに依存する場合があります。たとえば、TCPベースの通信では、通信の一方向で輻輳が発生するとスループットが低下します。 TCP送信の輻輳方向を特定できれば、トラブルシューティングが簡略化される可能性があります。
o In networks in which quality of service (QoS) is enabled, provisioning in one direction may be radically different than provisioning in the reverse direction and thus the QoS guarantees differ. Measuring the paths independently allows the verification of both guarantees.
o サービス品質（QoS）が有効になっているネットワークでは、一方向のプロビジョニングが逆方向のプロビジョニングとは根本的に異なり、QoS保証が異なります。パスを個別に測定すると、両方の保証を検証できます。
It is outside the scope of this document to say precisely how loss metrics would be applied to specific problems.
特定の問題に損失指標をどのように適用するかを正確に述べることは、このドキュメントの範囲外です。
{Comment: The terminology below differs from that defined by ITU-T documents (e.g., G.810, "Definitions and terminology for synchronization networks" and I.356, "B-ISDN ATM layer cell transfer performance") but is consistent with the IPPM Framework document. In general, these differences derive from the different backgrounds; the ITU-T documents historically have a telephony origin, while the authors of this document (and the Framework document) have a computer systems background. Although the terms defined below have no direct equivalent in the ITU-T definitions, after our definitions we will provide a rough mapping. However, note one potential confusion: our definition of "clock" is the computer operating systems definition denoting a time-of-day clock, while the ITU-T definition of clock denotes a frequency reference.}
{コメント：以下の用語は、ITU-Tドキュメントで定義されている用語とは異なります（たとえば、G.810、「同期ネットワークの定義と用語」およびI.356、「B-ISDN ATMレイヤーのセル転送パフォーマンス」）。 IPPMフレームワークドキュメント。一般に、これらの違いはさまざまな背景に由来します。 ITU-Tドキュメントは歴史的にテレフォニーを起源としていますが、このドキュメント（およびフレームワークドキュメント）の作成者はコンピュータシステムのバックグラウンドを持っています。以下で定義されている用語には、ITU-Tの定義に直接対応する用語はありませんが、定義の後に大まかなマッピングを示します。ただし、1つの混乱が生じる可能性があることに注意してください。「クロック」の定義はコンピューターのオペレーティングシステムの定義であり、時計のITU-T定義は周波数基準を示しています。}
Whenever a time (i.e., a moment in history) is mentioned here, it is understood to be measured in seconds (and fractions) relative to UTC.
ここで時刻（つまり、履歴の瞬間）が言及されている場合は常に、UTCに対して秒（および分数）で測定されると理解されています。
As described more fully in the Framework document, there are four distinct, but related notions of clock uncertainty:
フレームワークドキュメントでより完全に説明されているように、クロックの不確実性について、4つの異なるが関連する概念があります。
synchronization*
同期*
measures the extent to which two clocks agree on what time it is. For example, the clock on one host might be 5.4 msec ahead of the clock on a second host. {Comment: A rough ITU-T equivalent is "time error".}
2つのクロックが現在の時刻について合意する程度を測定します。たとえば、1つのホストのクロックは、2番目のホストのクロックより5.4ミリ秒進んでいる可能性があります。 {コメント：ITU-Tの大まかな同等物は「時間エラー」です。}
accuracy*
正確さ*
measures the extent to which a given clock agrees with UTC. For example, the clock on a host might be 27.1 msec behind UTC. {Comment: A rough ITU-T equivalent is "time error from UTC".}
特定のクロックがUTCと一致する程度を測定します。たとえば、ホストのクロックはUTCより27.1ミリ秒遅れている可能性があります。 {コメント：ITU-Tに相当するものは、「UTCからの時間エラー」です。}
resolution*
解決*
is a specification of the smallest unit by which the clock's time is updated. It gives a lower bound on the clock's uncertainty. For example, the clock on an old Unix host might tick only once every 10 msec and thus have a resolution of only 10 msec. {Comment: A very rough ITU-T equivalent is "sampling period".} skew*
時計の時刻を更新する最小単位の仕様です。それは時計の不確実性に下限を与えます。たとえば、古いUnixホストのクロックは、10ミリ秒ごとに1度だけ刻むため、分解能は10ミリ秒しかありません。 {コメント：非常に大まかなITU-Tに相当するものは、「サンプリング期間」です。}スキュー*
measures the change of accuracy, or of synchronization, with time. For example, the clock on a given host might gain 1.3 msec per hour and thus be 27.1 msec behind UTC at one time and only 25.8 msec an hour later. In this case, we say that the clock of the given host has a skew of 1.3 msec per hour relative to UTC, which threatens accuracy. We might also speak of the skew of one clock relative to another clock, which threatens synchronization. {Comment: A rough ITU-T equivalent is "time drift".}
精度または同期の変化を時間とともに測定します。たとえば、特定のホストのクロックは1時間あたり1.3ミリ秒増加する可能性があるため、一度にUTCより27.1ミリ秒遅れ、1時間後には25.8ミリ秒しか遅れない場合があります。この場合、指定されたホストのクロックは、UTCと比較して1時間あたり1.3ミリ秒のスキューを持っていると言い、精度を脅かしています。また、同期を脅かす、あるクロックと別のクロックとの相対的なスキューについても説明します。 {コメント：ITU-Tに相当するものは「時間ドリフト」です。}
Type-P-One-way-Packet-Loss
Type-P-One-way-Packet-Loss
o Src, the IP address of a host
o Src、ホストのIPアドレス
o Dst, the IP address of a host
o Dst、ホストのIPアドレス
o T, a time
o T、時間
o Tmax, a loss threshold waiting time
o Tmax、損失しきい値待機時間
The value of a Type-P-One-way-Packet-Loss is either a zero (signifying successful transmission of the packet) or a one (signifying loss).
Type-P-One-way-Packet-Lossの値は、0（パケットの正常な送信を示す）または1（損失を示す）のいずれかです。
>>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 0<< means that Src sent the first bit of a Type-P packet to Dst at wire time* T and that Dst received that packet.
>> TでのSrcからDstへの* Type-P-One-way-Packet-Loss *は0 <<は、SrcがType-Pパケットの最初のビットをワイヤタイム* TでDstに送信し、そのDstが受信したことを意味しますそのパケット。
>>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 1<< means that Src sent the first bit of a Type-P packet to Dst at wire time T and that Dst did not receive that packet (within the loss threshold waiting time, Tmax).
>> TでのSrcからDstへの* Type-P-One-way-Packet-Loss *が1 <<は、SrcがType-Pパケットの最初のビットをワイヤ時間TでDstに送信し、Dstは送信しなかったことを意味しますそのパケットを受信します（損失しきい値待機時間Tmax内）。
Thus, Type-P-One-way-Packet-Loss is 0 exactly when Type-P-One-way-Delay is a finite value, and it is 1 exactly when Type-P-One-way-Delay is undefined.
したがって、Type-P-One-way-Delayが有限値の場合、Type-P-One-way-Packet-Lossは0であり、Type-P-One-way-Delayが未定義の場合は1です。
The following issues are likely to come up in practice:
実際には次の問題が発生する可能性があります。
o A given methodology will have to include a way to distinguish between a packet loss and a very large (but finite) delay. As noted by Mahdavi and Paxson [RFC2678], simple upper bounds (such as the 255-second theoretical upper bound on the lifetimes of IP packets [RFC791]) could be used, but good engineering, including an understanding of packet lifetimes, will be needed in practice. {Comment: Note that, for many applications of these metrics, there may be no harm in treating a large delay as packet loss. An audio playback packet, for example, that arrives only after the playback point may as well have been lost. See Section 4.1.1 of [RFC6703] for examination of unusual packet delays and application performance estimation.}
o 特定の方法論には、パケット損失と非常に大きな（ただし有限の）遅延を区別する方法を含める必要があります。 MahdaviとPaxson [RFC2678]によって指摘されているように、単純な上限（IPパケット[RFC791]の有効期間の255秒の理論上の上限など）を使用できますが、パケットの有効期間の理解を含む優れたエンジニアリングが使用されます。実際に必要です。 {コメント：これらのメトリックの多くのアプリケーションでは、大きな遅延をパケット損失として処理しても害がないことに注意してください。たとえば、再生ポイントの後にのみ到着するオーディオ再生パケットも失われた可能性があります。異常なパケット遅延の調査とアプリケーションパフォーマンスの見積もりについては、[RFC6703]のセクション4.1.1を参照してください。}
o If the packet arrives but is corrupted, then it is counted as lost. {Comment: One is tempted to count the packet as received since corruption and packet loss are related but distinct phenomena. If the IP header is corrupted, however, one cannot be sure about the source or destination IP addresses and is thus on shaky grounds about knowing that the corrupted received packet corresponds to a given sent test packet. Similarly, if other parts of the packet needed by the methodology to know that the corrupted received packet corresponds to a given sent test packet, then such a packet would have to be counted as lost. It would be inconsistent to count packets with corrupted methodology-specific fields as lost, and not to count packets with other corrupted aspects in the same category.} Section 15 of [RFC2330] defines the "standard-formed" packet that is applicable to all metrics. Note that at this time the definition of standard-formed packets only applies to IPv4 (see also [IPPM-UPDATES]).
o パケットが到着しても破損している場合は、失われたと見なされます。 {コメント：破損とパケット損失は関連しているが別個の現象であるため、パケットを受信したものとして数えたくなります。ただし、IPヘッダーが破損している場合は、送信元または宛先のIPアドレスを確認できないため、破損した受信パケットが特定の送信済みテストパケットに対応していることがわかりません。同様に、破損した受信パケットが特定の送信済みテストパケットに対応していることを確認するために方法論で必要なパケットの他の部分がある場合、そのようなパケットは損失としてカウントされる必要があります。破損した方法論固有のフィールドを持つパケットを失われたものとしてカウントし、同じカテゴリの他の破損した側面を持つパケットをカウントしないことは一貫していません。} [RFC2330]のセクション15は、すべてに適用できる「標準形式」のパケットを定義していますメトリック。現時点では、標準形式のパケットの定義はIPv4にのみ適用されることに注意してください（[IPPM-UPDATES]も参照）。
o If the packet is duplicated along the path (or paths) so that multiple non-corrupt copies arrive at the destination, then the packet is counted as received.
o パケットがパスに沿って複製され、破損していない複数のコピーが宛先に到着する場合、パケットは受信されたものとしてカウントされます。
o If the packet is fragmented and if, for whatever reason, reassembly does not occur, then the packet will be deemed lost.
o パケットが断片化されていて、何らかの理由で再構成が行われない場合、パケットは失われたと見なされます。
As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, Differentiated Services (DS) Field [RFC2780]).
他のType-P- *メトリックと同様に、詳細な方法はType-Pに依存します（プロトコル番号、UDP / TCPポート番号、サイズ、Differentiated Services（DS）フィールド[RFC2780]など）。
Generally, for a given Type-P, one possible methodology would proceed as follows:
一般に、特定のタイプPの場合、1つの可能な方法論は次のように進行します。
o Arrange 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).
o SrcとDstが互いに同期するクロックを持つように調整します。同期の程度は方法論のパラメーターであり、損失を決定するために使用されるしきい値に依存します（以下を参照）。
o At the Src host, select Src and Dst IP addresses and form a test packet of Type-P with these addresses.
o Srcホストで、SrcおよびDst IPアドレスを選択し、これらのアドレスでType-Pのテストパケットを形成します。
o At the Dst host, arrange to receive the packet.
o Dstホストで、パケットを受信するように手配します。
o At the Src host, place a timestamp in the prepared Type-P packet, and send it towards Dst (ideally minimizing time before sending).
o Srcホストで、準備されたType-Pパケットにタイムスタンプを入れ、Dstに送信します（送信前に時間を最小限に抑えることが理想的です）。
o If the packet arrives within a reasonable period of time, the one-way packet loss is taken to be zero (and take a timestamp as soon as possible upon the receipt of the packet).
o パケットが妥当な時間内に到着した場合、一方向のパケット損失はゼロになります（そして、パケットの受信時にできるだけ早くタイムスタンプを取得します）。
o If the packet fails to arrive within a reasonable period of time, Tmax, the one-way packet loss is taken to be one. Note that the threshold of "reasonable" here is a parameter of the metric.
o パケットが妥当な期間Tmax内に到着しない場合、一方向のパケット損失は1と見なされます。ここで「妥当」のしきい値は、メトリックのパラメーターであることに注意してください。
{Comment: The definition of reasonable is intentionally vague and is intended to indicate a value "Th" so large that any value in the closed interval [Th-delta, Th+delta] is an equivalent threshold for loss. Here, delta encompasses all error in clock synchronization and timestamp acquisition and assignment along the measured path. If there is a single value, Tmax, after which the packet must be counted as lost, then we reintroduce the need for a degree of clock synchronization similar to that needed for one-way delay, and virtually all practical measurement systems combine methods for delay and loss. Therefore, if a measure of packet loss parameterized by a specific non-huge "reasonable" time-out value is needed, one can always measure one-way delay and see what percentage of packets from a given stream exceed a given time-out value. This point is examined in detail in [RFC6703], including analysis preferences to assign undefined delay to packets that fail to arrive with the difficulties emerging from the informal "infinite delay" assignment, and an estimation of an upper bound on waiting time for packets in transit. Further, enforcing a specific constant waiting time on stored singletons of one-way delay is compliant with this specification and may allow the results to serve more than one reporting audience.}
{コメント：合理的なの定義は意図的にあいまいであり、閉じた間隔[Th-delta、Th + delta]の値が損失の同等のしきい値になるほど大きい値「Th」を示すことを目的としています。ここで、デルタは、測定されたパスに沿ったクロック同期およびタイムスタンプの取得と割り当てにおけるすべてのエラーを含みます。単一の値Tmaxがあり、その後パケットが失われたものとしてカウントされる必要がある場合、一方向の遅延に必要なものと同様のある程度のクロック同期の必要性を再導入し、事実上すべての実用的な測定システムが遅延の方法を組み合わせるそして損失。したがって、特定の非合理的な「妥当な」タイムアウト値によってパラメーター化されたパケット損失の測定が必要な場合、常に一方向の遅延を測定し、特定のストリームからのパケットの何パーセントが特定のタイムアウト値を超えるかを確認できます。 。この点は[RFC6703]で詳細に検討されており、非公式の「無限遅延」割り当てから生じた困難で到着できないパケットに未定義の遅延を割り当てるための分析設定、およびパケットの待機時間の上限の推定を含みます。トランジット。さらに、格納された一方向遅延のシングルトンに特定の一定の待機時間を適用することは、この仕様に準拠しており、結果が複数のレポート対象ユーザーにサービスを提供できる場合があります。}
Issues such as the packet format, the means by which Dst knows when to expect the test packet, and the means by which Src and Dst are synchronized are outside the scope of this document. {Comment: We plan to document the implementation techniques of our work in much more detail elsewhere; we encourage others to do so as well.}
パケット形式、Dstがテストパケットを予期するタイミングを知る手段、SrcとDstを同期する手段などの問題は、このドキュメントの範囲外です。 {コメント：私たちは、作業の実装技術を他の場所でより詳細に文書化する予定です。他の人にもそうすることをお勧めします。}
The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework document provides general guidance on this point.
特定の測定方法の説明には、誤差や不確実性のさまざまな原因の説明と分析を含める必要があります。フレームワークドキュメントは、この点に関する一般的なガイダンスを提供します。
For loss, there are three sources of error:
損失の場合、エラーには次の3つの原因があります。
o synchronization between clocks on Src and Dst.
o SrcとDstのクロック間の同期。
o the packet-loss threshold (which is related to the synchronization between clocks).
o パケット損失しきい値（これは、クロック間の同期に関連しています）。
o resource limits in the network interface or software on the receiving instrument.
o 受信機器のネットワークインターフェイスまたはソフトウェアのリソース制限。
The first two sources are interrelated and could result in a test packet with finite delay being reported as lost. Type-P-One-way-Packet-Loss is 1 if the test packet does not arrive, or if it does arrive and the difference between the Src timestamp and the Dst timestamp is greater than the "reasonable period of time" or loss threshold. If the clocks are not sufficiently synchronized, the loss threshold may not be "reasonable" - the packet may take much less time to arrive than its Src timestamp indicates. Similarly, if the loss threshold is set too low, then many packets may be counted as lost. The loss threshold must be high enough and the clocks synchronized well enough so that a packet that arrives is rarely counted as lost. (See the discussions in the previous two sections.)
最初の2つのソースは相互に関連しており、テストパケットが失われたと報告される有限の遅延が生じる可能性があります。 Type-P-One-way-Packet-Lossは、テストパケットが到着しない場合、または到着し、SrcタイムスタンプとDstタイムスタンプの差が「妥当な期間」または損失しきい値より大きい場合。クロックが十分に同期されていない場合、損失しきい値は「妥当」ではない可能性があります。パケットの到着にかかる時間は、Srcタイムスタンプが示すよりもはるかに短い場合があります。同様に、損失しきい値の設定が低すぎると、多くのパケットが損失としてカウントされる可能性があります。損失しきい値は十分に高く、クロックが十分に同期されている必要があります。これにより、到着したパケットが失われたものとしてカウントされることはほとんどありません。 （前の2つのセクションの説明を参照してください。）
Since the sensitivity of packet-loss measurement alone to lack of clock synchronization is less than for delay, we refer the reader to the treatment of synchronization errors in the "One-way Delay Metric for IPPM" [RFC2330] for more details.
クロック同期の欠如に対するパケット損失測定のみの感度は遅延よりも低いため、詳細については、「IPPMの片方向遅延メトリック」[RFC2330]の同期エラーの扱いを参照してください。
The last source of error, resource limits, cause the packet to be dropped by the measurement instrument and counted as lost when in fact the network delivered the packet in reasonable time.
エラーの最後の原因であるリソース制限により、測定機器によってパケットがドロップされ、実際にネットワークが妥当な時間内にパケットを配信したときに、パケットが失われたと見なされます。
The measurement instruments should be calibrated such that the loss threshold is reasonable for application of the metrics and the clocks are synchronized enough so the loss threshold remains reasonable.
測定器は、損失しきい値がメトリックの適用に適しており、クロックが十分に同期されているため、損失しきい値が妥当なままであるように調整する必要があります。
In addition, the instruments should be checked to ensure that the possibility a packet arrives at the network interface but is lost due to congestion on the interface or to other resource exhaustion (e.g., buffers) on the instrument is low.
さらに、機器をチェックして、パケットがネットワークインターフェイスに到着する可能性があるが、インターフェイスの輻輳または機器上の他のリソースの枯渇（バッファーなど）によってパケットが失われる可能性が低いことを確認する必要があります。
The calibration and context in which the metric is measured MUST be carefully considered and SHOULD always be reported along with metric results. We now present four items to consider: Type-P of the test packets, the loss threshold, instrument calibration, and the path traversed by the test packets. This list is not exhaustive; any additional information that could be useful in interpreting applications of the metrics should also be reported (see [RFC6703] for extensive discussion of reporting considerations for different audiences).
メトリックが測定されるキャリブレーションとコンテキストは慎重に検討する必要があり、メトリック結果とともに常に報告する必要があります。ここで、考慮する4つの項目を示します。テストパケットのタイプP、損失しきい値、機器のキャリブレーション、およびテストパケットが通過するパスです。このリストは完全ではありません。メトリックのアプリケーションの解釈に役立つ可能性のある追加情報も報告する必要があります（さまざまな対象者のレポートに関する考慮事項の詳細については、[RFC6703]を参照してください）。
As noted in Section 13 of the Framework document [RFC2330], the value of the metric may depend on the type of IP packets used to make the measurement, or "Type-P". The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP DS Field [RFC2780], Explicit Congestion Notification (ECN) [RFC3168], or RSVP) changes. Additional packet distinctions identified in future extensions of the Type-P definition will apply. The exact Type-P used to make the measurements MUST be accurately reported.
フレームワークドキュメント[RFC2330]のセクション13に記載されているように、メトリックの値は、測定に使用されるIPパケットのタイプ、つまり「Type-P」に依存する場合があります。 Type-P-One-way-Delayの値は、プロトコル（UDPまたはTCP）、ポート番号、サイズ、または特別な処理（IP DSフィールド[RFC2780]、明示的輻輳通知（ECN）[ RFC3168]、またはRSVP）の変更。 Type-P定義の将来の拡張で識別される追加のパケットの区別が適用されます。測定に使用された正確なType-Pは正確に報告されなければなりません。
The threshold, Tmax, between a large finite delay and loss (or other methodology to distinguish between finite delay and loss) MUST be reported.
大きな有限の遅延と損失の間のしきい値Tmax（または有限の遅延と損失を区別するための他の方法論）を報告する必要があります。
The degree of synchronization between the Src and Dst clocks MUST be reported. If possible, a test packet that arrives at the Dst network interface and is reported as lost due to resource exhaustion on Dst SHOULD be reported.
SrcクロックとDstクロック間の同期の程度を報告する必要があります。可能であれば、Dstネットワークインターフェイスに到着し、Dstのリソース枯渇により失われたと報告されたテストパケットを報告する必要があります（SHOULD）。
Finally, the path traversed by the packet SHOULD be reported, if possible. In general, it is impractical to know the precise path a given packet takes through the network. The precise path may be known for certain Type-P on short or stable paths. If Type-P includes the record route (or loose-source route) option in the IP header, and the path is short enough, and all routers* on the path support record (or loose-source) route, then the path will be precisely recorded. This is impractical because the route must be short enough, many routers do not support (or are not configured for) record route, and use of this feature would often artificially worsen the performance observed by removing the packet from common-case processing. However, partial information is still valuable context. For example, if a host can choose between two links* (and hence, two separate routes from Src to Dst), then the initial link used is valuable context. {Comment: Backbone path selection services come and go. A historical example was Merit's NetNow setup, where a Src on one Network Access Point (NAP) can reach a Dst on another NAP by either of several different backbone networks.}
最後に、可能であれば、パケットが通過するパスを報告する必要があります（SHOULD）。一般に、特定のパケットがネットワークを通過する正確なパスを知ることは実際的ではありません。正確なパスは、短いパスまたは安定したパスの特定のType-Pで既知である場合があります。 Type-PがIPヘッダーにレコードルート（またはルーズソースルート）オプションを含み、パスが十分に短く、パス上のすべてのルーター*がレコード（またはルーズソース）ルートをサポートしている場合、パスは正確に記録されます。ルートは十分に短い必要があり、多くのルーターはレコードルートをサポートしていない（または構成されていない）ため、これは実用的ではありません。また、この機能を使用すると、一般的なケースの処理からパケットを削除することで観察されるパフォーマンスが人為的に悪化することがよくあります。ただし、部分的な情報は依然として貴重なコンテキストです。たとえば、ホストが2つのリンク*（したがって、SrcからDstへの2つの別々のルート）から選択できる場合、使用される初期リンクは重要なコンテキストです。 {コメント：バックボーンパス選択サービスは行き来しています。歴史的な例はMeritのNetNowセットアップであり、1つのネットワークアクセスポイント（NAP）上のSrcが、いくつかの異なるバックボーンネットワークのいずれかによって別のNAP上のDstに到達できます。}
Given the singleton metric Type-P-One-way-Packet-Loss, we now define one particular sample of such singletons. The idea of the sample is to select a particular binding of the parameters Src, Dst, and Type-P, then define a sample of values of parameter T. The means for defining the values of T is to select a beginning time T0, a final time Tf, and an average rate lambda, then define a pseudorandom Poisson process of rate lambda, whose values fall between T0 and Tf. The time interval between successive values of T will then average 1/ lambda.
シングルトンメトリックType-P-One-way-Packet-Lossを考慮して、このようなシングルトンの特定のサンプルを1つ定義します。サンプルのアイデアは、パラメーターSrc、Dst、およびType-Pの特定のバインディングを選択し、パラメーターTの値のサンプルを定義することです。Tの値を定義する手段は、開始時間T0、最終時間Tf、および平均レートラムダは、レートラムダの疑似ランダムポアソンプロセスを定義します。その値はT0とTfの間にあります。 Tの連続する値の間の時間間隔は、平均して1 /ラムダになります。
Note that Poisson sampling is only one way of defining a sample. Poisson has the advantage of limiting bias, but other methods of sampling will be appropriate for different situations. For example, a truncated Poisson distribution may be needed to avoid reactive network state changes during intervals of inactivity, see Section 4.6 of [RFC7312]. Sometimes the goal is sampling with a known bias, and [RFC3432] describes a method for periodic sampling with random start times.
ポアソンサンプリングは、サンプルを定義する唯一の方法であることに注意してください。ポアソンにはバイアスを制限するという利点がありますが、他のサンプリング方法がさまざまな状況に適しています。たとえば、非アクティブな間隔でのリアクティブなネットワーク状態の変化を回避するために、切り捨てられたポアソン分布が必要になる場合があります。[RFC7312]のセクション4.6を参照してください。時々、目的は既知のバイアスでのサンプリングであり、[RFC3432]はランダムな開始時間で定期的にサンプリングする方法を説明しています。
Type-P-One-way-Packet-Loss-Poisson-Stream
Type-P-One-way-Packet-Loss-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 T0, a time
o T0、時間
o Tf, a time
o Tf、時間
o Tmax, a loss threshold waiting time
o Tmax、損失しきい値待機時間
o lambda, a rate in reciprocal seconds
o ラムダ、秒単位のレート
A sequence of pairs; the elements of each pair are:
ペアのシーケンス。各ペアの要素は次のとおりです。
o T, a time, and
o T、時間、そして
o L, either a zero or a one.
o L、ゼロまたは1。
The values of T in the sequence are monotonic increasing. Note that T would be a valid parameter to Type-P-One-way-Packet-Loss and that L would be a valid value of Type-P-One-way-Packet-Loss.
シーケンスのTの値は単調増加です。 TはType-P-One-way-Packet-Lossに対する有効なパラメーターであり、LはType-P-One-way-Packet-Lossの有効な値であることに注意してください。
Given T0, Tf, and lambda, we compute a pseudorandom Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of the selected times in this process, we obtain one value of Type-P-One-way-Delay. The value of the sample is the sequence made up of the resulting <time, loss> pairs. If there are no such pairs, the sequence is of length zero and the sample is said to be empty.
T0、Tf、およびラムダが指定されている場合、平均到着率ラムダでT0以前に始まり、Tf以降で終了する疑似ランダムポアソンプロセスを計算します。次に、Ｔ０以上かつＴｆ以下のこれらの時間値が選択される。このプロセスで選択された各時間で、Type-P-One-way-Delayの1つの値を取得します。サンプルの値は、結果の<time、loss>ペアで構成されるシーケンスです。そのようなペアがない場合、シーケンスは長さがゼロであり、サンプルは空であるといいます。
The reader should be familiar with the in-depth discussion of Poisson sampling in the Framework document [RFC2330], which includes methods to compute and verify the pseudorandom Poisson process.
読者は、フレームワークドキュメント[RFC2330]のポアソンサンプリングの詳細な説明に精通している必要があります。これには、疑似ランダムポアソンプロセスを計算および検証する方法が含まれています。
We specifically do not constrain the value of lambda except to note the extremes. If the rate is too large, then the measurement traffic will perturb the network and itself cause congestion. If the rate is too small, then you might not capture interesting network behavior. {Comment: We expect to document our experiences with, and suggestions for, lambda elsewhere, culminating in a "Best Current Practice" document.}
極端に注意する場合を除いて、ラムダの値を特に制約しません。レートが大きすぎると、測定トラフィックがネットワークを混乱させ、それ自体が輻輳を引き起こします。レートが小さすぎると、興味深いネットワーク動作をキャプチャできない可能性があります。 {コメント：他の場所でのラムダでの経験と提案を文書化し、「ベストカレントプラクティス」文書で最高潮に達することを期待しています。}
Since a pseudorandom number sequence is employed, the sequence of times, and hence the value of the sample, is not fully specified. Pseudorandom number generators of good quality will be needed to achieve the desired qualities.
疑似乱数シーケンスが使用されるため、時間のシーケンス、つまりサンプルの値は完全には指定されていません。望ましい品質を実現するには、良質の疑似乱数ジェネレータが必要です。
The sample is defined in terms of a Poisson process both to avoid the effects of self-synchronization and also capture a sample that is statistically as unbiased as possible. The Poisson process is used to schedule the loss measurements. The test packets will generally not arrive at Dst according to a Poisson distribution, since they are influenced by the network. Time-slotted links described in Section 3.4 [RFC7312] can greatly modify the sample characteristics. The main concern is that unbiased packet streams with randomized inter-packet time intervals will be converted to some new distribution after encountering a time-slotted link, possibly with strong periodic characteristics instead.
サンプルは、自己同期の影響を回避し、統計的に可能な限り偏りのないサンプルをキャプチャするために、ポアソンプロセスの観点から定義されています。ポアソンプロセスは、損失測定をスケジュールするために使用されます。テストパケットは、ネットワークの影響を受けるため、ポアソン分布に従ってDstに到着しません。セクション3.4 [RFC7312]で説明されているタイムスロットリンクは、サンプルの特性を大幅に変更する可能性があります。主な懸念は、ランダムなパケット間時間間隔を持つ不偏パケットストリームが、タイムスロットリンクに遭遇した後、おそらく代わりに強力な周期的特性を持つ何らかの新しい分布に変換されることです。
{Comment: there is, of course, no claim that real Internet traffic arrives according to a Poisson arrival process.
{コメント：もちろん、実際のインターネットトラフィックがポアソン到着プロセスに従って到着するという主張はありません。
It is important to note that, in contrast to this metric, loss ratios observed by transport connections do not reflect unbiased samples. For example, TCP transmissions both (1) occur in bursts, which can induce loss due to the burst volume that would not otherwise have been observed, and (2) adapt their transmission rate in an attempt to minimize the loss ratio observed by the connection.}
このメトリックとは対照的に、トランスポート接続によって観測された損失率は、偏りのないサンプルを反映していないことに注意することが重要です。たとえば、TCP送信は両方とも（1）バーストで発生し、それがなければ観測されなかったであろうバーストボリュームが原因で損失を引き起こす可能性があり、（2）接続によって観測された損失率を最小化するために送信レートを適応させる。}
All the singleton Type-P-One-way-Packet-Loss metrics in the sequence will have the same values of Src, Dst, and Type-P.
シーケンス内のすべてのシングルトンType-P-One-way-Packet-Lossメトリックは、Src、Dst、およびType-Pの同じ値を持ちます。
Note also that, given one sample that runs from T0 to Tf, and given new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the subsequence of the given sample whose time values fall between T0' and Tf' are also a valid Type-P-One-way-Packet-Loss-Poisson-Stream sample.
また、T0からTfまでの1つのサンプルが与えられ、T0 <= T0 '<= Tf' <= Tfとなるような新しい時間値T0 'およびTf'が与えられた場合、与えられたサンプルのサブシーケンスで、時間値はT0 'とTf'も有効なType-P-One-way-Packet-Loss-Poisson-Streamサンプルです。
The methodologies follow directly from:
方法論は次のとおりです。
o the selection of specific times using the specified Poisson arrival process, and
o 指定されたポアソン到着プロセスを使用した特定の時間の選択、および
o the methodologies discussion already given for the singleton Type-P-One-way-Packet-Loss metric.
o シングルトンType-P-One-way-Packet-Lossメトリックについてすでに説明した方法論の説明。
Care must be given to correctly handle out-of-order arrival of test packets; it is possible that the Src could send one test packet at TS[i], then send a second one (later) at TS[i+1] while the Dst could receive the second test packet at TR[i+1], and then receive the first one (later) at TR[i]. Metrics for reordering may be found in [RFC4737].
テストパケットの順不同の到着を正しく処理するように注意する必要があります。 SrcがTS [i]で1つのテストパケットを送信し、次にTS [i + 1]で（後で）2つ目を送信し、DstがTR [i + 1]で2つ目のテストパケットを受信できる可能性があります。次に、最初の（後で）TR [i]で受け取ります。並べ替えの指標は[RFC4737]にあります。
In addition to sources of errors and uncertainties associated with methods employed to measure the singleton values that make up the sample, care must be given to analyze the accuracy of the Poisson arrival process of the wire times of the sending of the test packets. Problems with this process could be caused by several things, including problems with the pseudorandom number techniques used to generate the Poisson arrival process. The Framework document shows how to use the Anderson-Darling test to verify the accuracy of the Poisson process over small time frames. {Comment: The goal is to ensure that the test packets are sent "close enough" to a Poisson schedule and avoid periodic behavior.}
サンプルを構成するシングルトン値を測定するために採用された方法に関連するエラーと不確実性の原因に加えて、テストパケットの送信のワイヤ時間のポアソン到着プロセスの精度を分析するように注意する必要があります。このプロセスの問題は、ポアソン到着プロセスの生成に使用される疑似乱数手法の問題など、いくつかの原因で発生する可能性があります。フレームワークドキュメントは、アンダーソンダーリングテストを使用して、短い時間枠でのポアソンプロセスの精度を検証する方法を示しています。 {コメント：目標は、テストパケットがポアソンスケジュールに「十分近づいて」送信され、定期的な動作を回避することを保証することです。
The calibration and context for the underlying singletons MUST be reported along with the stream (see "Reporting the Metric" (Section 2.8) for Type-P-One-way-Packet-Loss).
基になるシングルトンの調整とコンテキストは、ストリームと共に報告する必要があります（Type-P-One-way-Packet-Lossについては、「メトリックの報告」（セクション2.8）を参照してください）。
Given the sample metric Type-P-One-way-Packet-Loss-Poisson-Stream, we now offer several statistics of that sample. These statistics are offered mostly to be illustrative of what could be done. See [RFC6703] for additional discussion of statistics that are relevant to different audiences.
サンプルメトリックのType-P-One-way-Packet-Loss-Poisson-Streamを考慮して、そのサンプルのいくつかの統計を提供します。これらの統計は、主に何ができるかを示すために提供されています。さまざまな対象者に関連する統計の詳細については、[RFC6703]を参照してください。
Given a Type-P-One-way-Packet-Loss-Poisson-Stream, the average of all the L values in the stream is the ratio of losses to total packets in the stream. In addition, the Type-P-One-way-Packet-Loss-Ratio is undefined if the sample is empty.
Type-P-One-way-Packet-Loss-Poisson-Streamが与えられた場合、ストリーム内のすべてのL値の平均は、ストリーム内の合計パケットに対する損失の比率です。さらに、サンプルが空の場合、Type-P-One-way-Packet-Loss-Ratioは未定義です。
For example, suppose we take a sample and the results are as follows:
たとえば、サンプルを取り、結果が次のようであるとします。
Stream1 = <
<T1, 0>
<T1、0>
<T2, 0>
<T2、0>
<T3, 1>
<Tz、1>
<T4, 0>
<Tch、0>
<T5, 0>
<T5、0>
>
＞
Then, the average of loss results would be 0.2, the loss ratio.
すると、損失の結果の平均は、損失率である0.2になります。
Note that, since healthy Internet paths should be operating at loss ratios below 1% (particularly if high delay-bandwidth products are to be sustained), the sample sizes needed might be larger than one would like. Thus, for example, if one wants to discriminate between various fractions of 1% over one-minute periods, then several hundred samples per minute might be needed. This would result in larger values of lambda than one would ordinarily want.
健全なインターネットパスは1％未満の損失率で動作する必要があるため（特に、高遅延帯域幅の製品を維持する必要がある場合）、必要なサンプルサイズが必要以上に大きくなる可能性があることに注意してください。したがって、たとえば、1分間に1％のさまざまな割合を区別したい場合、1分あたり数百のサンプルが必要になることがあります。これにより、ラムダの値が通常よりも大きくなります。
Note that although the loss threshold should be set such that any errors in loss are not significant, if the possibility that a packet that arrived is counted as lost due to resource exhaustion is significant compared to the loss ratio of interest, Type-P-One-way-Packet-Loss-Ratio will be meaningless.
損失のしきい値は、損失のエラーがそれほど大きくないように設定する必要がありますが、到着したパケットがリソースの枯渇のために失われたものとしてカウントされる可能性が、関心のある損失率に比べて大きい場合は、Type-P-One -way-Packet-Loss-Ratioは無意味になります。
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 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
セキュリティ上の懸念には2つのタイプがあります。測定によって引き起こされる潜在的な危害と、測定に対する潜在的な危害です。測定はアクティブであり、ネットワークにパケットを注入するため、害を及ぼす可能性があります。測定パラメーターが慎重に選択されて、測定が測定するネットワークに少量の追加トラフィックを注入するようにする必要があります。彼らが注入した場合
"too much" traffic, they can skew the results of the measurement and in extreme cases cause congestion and denial of service.
トラフィックが「多すぎる」と、測定結果が歪む可能性があり、極端な場合には、輻輳やサービス拒否が発生します。
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 ratio 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.
測定トラフィックに「通常の」トラフィックとは異なる優先順位を与えるルーターや、人工的な測定トラフィックを注入する攻撃者によって、測定自体が損なわれる可能性があります。ルーターが測定トラフィックを認識して個別に処理できる場合、測定は実際のユーザートラフィックを反映しません。攻撃者が正当と認められる人工的なトラフィックを注入すると、損失率は人工的に低下します。したがって、測定方法には、測定トラフィックが「通常の」トラフィックと区別される可能性を減らすための適切な手法を含める必要があります（SHOULD）。デジタル署名などの認証技術は、注入されたトラフィック攻撃を防ぐために適切な場所で使用できます。
When considering privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques that are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. We refer the reader to the privacy considerations described in the Large Scale Measurement of Broadband Performance (LMAP) Framework [RFC7594], which covers active and passive techniques.
測定に関与する人々またはトラフィックが測定される人々のプライバシーを考慮する場合、この作業範囲内のアクティブな手法を使用すると、潜在的なオブザーバーが入手できる機密情報が大幅に減少します。測定目的でのユーザートラフィックの受動的な観察は、多くのプライバシー問題を引き起こします。アクティブおよびパッシブ技術をカバーするブロードバンドパフォーマンスの大規模測定（LMAP）フレームワーク[RFC7594]で説明されているプライバシーに関する考慮事項を読者に紹介します。
Collecting measurements or using measurement results for reconnaissance to assist in subsequent system attacks is quite common. Access to measurement results or control of the measurement systems to perform reconnaissance should be guarded against. See Section 7 of [RFC7594] (the Security Considerations section of the LMAP Framework) for system requirements that help to avoid measurement system compromise.
Collecting measurements or using measurement results for reconnaissance to assist in subsequent system attacks is quite common. Access to measurement results or control of the measurement systems to perform reconnaissance should be guarded against. See Section 7 of [RFC7594] (the Security Considerations section of the LMAP Framework) for system requirements that help to avoid measurement system compromise.
The text above constitutes a revision to RFC 2680, which is now an Internet Standard.
上記のテキストは、現在インターネット標準となっているRFC 2680の改訂版です。
[RFC7290] provides the test plan and results supporting [RFC2680] advancement along the Standards Track, according to the process in [RFC6576]. The conclusions of [RFC7290] list four minor modifications for inclusion:
[RFC7290]は、[RFC6576]のプロセスに従って、標準トラックに沿った[RFC2680]の進歩をサポートするテスト計画と結果を提供します。 [RFC7290]の結論には、含めるための4つのマイナーな変更がリストされています。
1. Section 6.2.3 of [RFC7290] asserts that the assumption of post-processing to enforce a constant waiting time threshold is compliant and that the text of the RFC should be revised slightly to include this point. The applicability of post-processing was added in the last list item of Section 2.6, above.
1. [RFC7290]のセクション6.2.3は、一定の待機時間のしきい値を適用するための後処理の前提が準拠していること、およびこの点を含むようにRFCのテキストを少し修正する必要があることを主張しています。後処理の適用可能性は、上記のセクション2.6の最後のリスト項目に追加されました。
2. Section 6.5 of [RFC7290] indicates that the Type-P-One-way-Packet-Loss-Average statistic is more commonly called a Packet Loss Ratio, so it is renamed in this document (this small discrepancy does not affect candidacy for advancement). The renaming was implemented in Section 4.1, above.
2. [RFC7290]のセクション6.5は、Type-P-One-way-Packet-Loss-Average統計がより一般的にはパケット損失率と呼ばれることを示しているため、このドキュメントでは名前が変更されています（この小さな差異は、進歩の候補には影響しません） 。名前の変更は、上記のセクション4.1で実装されました。
3. The IETF has reached consensus on guidance for reporting metrics in [RFC6703], and the memo is referenced this document to incorporate recent experience where appropriate. This reference was added in the last list item of Section 2.6, in Section 2.8, and in Section 4 above.
3. IETFは、[RFC6703]のメトリックを報告するためのガイダンスについてコンセンサスに達し、メモはこのドキュメントを参照して、必要に応じて最近の経験を組み込んでいます。この参照は、2.6節の最後のリスト項目、2.8節、および上記の4節に追加されました。
4. There are currently two errata with status "Verified" (EID 1528) and "Held for Document Update" (EID 3186) for [RFC2680], and these minor revisions were incorporated in Sections 1 and 2.7.
4. 現在、[確認済み]（EID 1528）と[ドキュメント更新の保留]（EID 3186）の[RFC2680]には2つのエラッタがあり、これらのマイナーリビジョンはセクション1と2.7に組み込まれています。
A number of updates to the [RFC2680] text have been implemented in the text to reference key IPPM RFCs that were approved after [RFC2680] (see Sections 3 and 3.6, above) and to address comments on the IPPM mailing list describing current conditions and experience.
[RFC2680]テキストに対する多くの更新がテキストに実装され、[RFC2680]の後に承認された主要なIPPM RFCを参照し（上記のセクション3および3.6を参照）、現在の状況と経験。
1. Near the end of Section 1.1, there is an update of a network example using ATM, a clarification of TCP's affect on queue occupation, and discussion of the importance of one-way delay measurement.
1. セクション1.1の終わり近くに、ATMを使用したネットワークの例の更新、キューの占有に対するTCPの影響の明確化、および一方向の遅延測定の重要性の議論があります。
2. Clarification of the definition of "resolution" in Section 1.2.
2. セクション1.2の「解像度」の定義の明確化。
3. Explicit inclusion of the maximum waiting time input parameter in Sections 2.2, 2.4, and 3.2, reflecting recognition of this parameter in more recent RFCs and ITU-T Recommendation Y.1540.
3. セクション2.2、2.4、および3.2に最大待機時間の入力パラメーターを明示的に含めること。これは、このパラメーターが最近のRFCおよびITU-T勧告Y.1540で認識されたことを反映しています。
4. Addition of a reference to RFC 6703 in the discussion of packet lifetime and application timeouts in Section 2.5.
4. セクション2.5のパケットライフタイムとアプリケーションタイムアウトの説明におけるRFC 6703への参照の追加。
5. Replaced "precedence" with updated terminology (DS Field) in Sections 2.6 and 2.8.1 (with reference).
5. セクション2.6および2.8.1（参照付き）の「優先順位」を更新された用語（DSフィールド）に置き換えました。
6. Added parenthetical guidance on minimizing the interval between timestamp placement to send time or reception time in Section 2.6. Also, the text now recognizes the timestamp acquisition process and that practical systems measure both delay and loss (thus requiring the max waiting time parameter).
6. セクション2.6に、タイムスタンプを配置して送信時刻または受信時刻を配置する間隔を最小限にするための括弧付きガイダンスを追加しました。また、テキストはタイムスタンプ取得プロセスを認識し、その実用的なシステムは遅延と損失の両方を測定します（したがって、最大待機時間パラメーターが必要です）。
7. Added a reference to RFC 3432 regarding periodic sampling alongside Poisson sampling in Section 3 and also noted that a truncated Poisson distribution may be needed with modern networks as described in the IPPM Framework update [RFC7312].
7. セクション3で、ポアソンサンプリングに加えて定期的なサンプリングに関するRFC 3432への参照を追加し、IPPMフレームワークの更新[RFC7312]で説明されているように、最新のネットワークでは切り捨てられたポアソン分布が必要になる場合があることにも言及しました。
8. Recognition that time-slotted links described in [RFC7312] can greatly modify the sample characteristics, in Section 3.5.
8. [RFC7312]で説明されているタイムスロットリンクは、セクション3.5のサンプル特性を大幅に変更できることを認識してください。
9. Added a reference to RFC 4737 regarding reordering metrics in the related discussion of Section 3.6, "Methodologies".
9. セクション3.6、「方法論」の関連ディスカッションで、メトリックの並べ替えに関するRFC 4737への参照を追加しました。
10. Expanded and updated the material on privacy and added cautions on use of measurements for reconnaissance in Section 5, "Security Considerations".
10. プライバシーに関する資料を拡張および更新し、セクション5「セキュリティに関する考慮事項」に偵察のための測定値の使用に関する注意を追加しました。
Section 5.4.4 of [RFC6390] suggests a common template for performance metrics partially derived from previous IPPM and Benchmarking Methodology Working Group (BMWG) RFCs, but it also contains some new items. All of the normative parts of [RFC6390] are covered, but not quite in the same section names or orientation. Several of the informative parts are covered. Maintaining the familiar outline of IPPM literature has value and minimizes unnecessary differences between this revised RFC and current/future IPPM RFCs.
[RFC6390]のセクション5.4.4は、以前のIPPMおよびBenchmarking Methodology Working Group（BMWG）RFCから部分的に派生したパフォーマンスメトリックの共通テンプレートを提案していますが、いくつかの新しい項目も含まれています。 [RFC6390]のすべての規範的な部分がカバーされていますが、同じセクション名や方向性には含まれていません。有益な部分のいくつかがカバーされています。 IPPM文献の親しみやすい概要を維持することには価値があり、この改訂されたRFCと現在/将来のIPPM RFCの間の不要な違いを最小限に抑えます。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<http：//www.rfc -editor.org/info/rfc2330>。
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, DOI 10.17487/RFC2678, September 1999, <http://www.rfc-editor.org/info/rfc2678>.
[RFC2678] Mahdavi、J。およびV. Paxson、「接続性を測定するためのIPPMメトリック」、RFC 2678、DOI 10.17487 / RFC2678、1999年9月、<http://www.rfc-editor.org/info/rfc2678>。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, DOI 10.17487/RFC2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>.
[RFC2680] Almes、G.、Kalidindi、S.、M。Zekauskas、「A IP-way Packet Loss Metric for IPPM」、RFC 2680、DOI 10.17487 / RFC2680、1999年9月、<http：//www.rfc- editor.org/info/rfc2680>。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <http://www.rfc-editor.org/info/rfc2780>.
[RFC2780] Bradner、S.およびV. Paxson、「IANA Allocation Allocation Guidelines for Values in the Internet Protocol and Related Headers」、BCP 37、RFC 2780、DOI 10.17487 / RFC2780、2000年3月、<http：//www.rfc- editor.org/info/rfc2780>。
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, DOI 10.17487/RFC3432, November 2002, <http://www.rfc-editor.org/info/rfc3432>.
[RFC3432] Raisanen、V.、Grotefeld、G。、およびA. Morton、「定期的なストリームを使用したネットワークパフォーマンス測定」、RFC 3432、DOI 10.17487 / RFC3432、2002年11月、<http://www.rfc-editor.org / info / rfc3432>。
[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, <http://www.rfc-editor.org/info/rfc6576>.
[RFC6576] Geib、R.、Ed。、Morton、A.、Fardid、R。、およびA. Steinmitz、「IP Performance Metrics（IPPM）Standard Advancement Testing」、BCP 176、RFC 6576、DOI 10.17487 / RFC6576、March 2012、<http://www.rfc-editor.org/info/rfc6576>。
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, <http://www.rfc-editor.org/info/rfc7312>.
[RFC7312] Fabini、J。およびA. Morton、「Advanced Performance Streaming and Sampling Framework for IP Performance Metrics（IPPM）」、RFC 7312、DOI 10.17487 / RFC7312、2014年8月、<http://www.rfc-editor.org / info / rfc7312>。
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-editor.org/info/rfc7679>.
[RFC7679] Almes、G.、Kalidindi、S.、Zekauskas、M。、およびA. Morton、編、「IPパフォーマンスメトリック（IPPM）に対する一方向の遅延メトリック」、STD 81、RFC 7679、DOI 10.17487 / RFC7679、2016年1月、<http://www.rfc-editor.org/info/rfc7679>。
[IPPM-UPDATES] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "Updates for IPPM's Active Metric Framework: Packets of Type-P and Standard-Formed Packets", Work in Progress, draft-morton-ippm-2330-stdform-typep-02, December 2015.
[IPPM-UPDATES] Morton、A.、Fabini、J.、Elkins、N.、Ackermann、M。、およびV. Hegde、「IPPMのアクティブメトリックフレームワークの更新：タイプPのパケットと標準形式のパケット」、 Work in Progress、draft-morton-ippm-2330-stdform-typep-02、2015年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <http://www.rfc-editor.org/info/rfc4737>.
[RFC4737] Morton、A.、Ciavattone、L.、Ramachandran、G.、Shalunov、S。、およびJ. Perser、「Packet Reordering Metrics」、RFC 4737、DOI 10.17487 / RFC4737、2006年11月、<http：// www.rfc-editor.org/info/rfc4737>。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.
[RFC6390]クラークA.およびB.クレイズ、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、DOI 10.17487 / RFC6390、2011年10月、<http://www.rfc-editor.org/info / rfc6390>。
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, DOI 10.17487/RFC6703, August 2012, <http://www.rfc-editor.org/info/rfc6703>.
[RFC6703] Morton、A.、Ramachandran、G。、およびG. Maguluri、「Reporting IP Network Performance Metrics：Different Points of View」、RFC 6703、DOI 10.17487 / RFC6703、2012年8月、<http：//www.rfc -editor.org/info/rfc6703>。
[RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test Plan and Results for Advancing RFC 2680 on the Standards Track", RFC 7290, DOI 10.17487/RFC7290, July 2014, <http://www.rfc-editor.org/info/rfc7290>.
[RFC7290] Ciavattone、L.、Geib、R.、Morton、A。、およびM. Wieser、「Standard PlanでRFC 2680を進めるためのテスト計画と結果」、RFC 7290、DOI 10.17487 / RFC7290、2014年7月、< http://www.rfc-editor.org/info/rfc7290>。
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <http://www.rfc-editor.org/info/rfc7594>.
[RFC7594] Eardley、P.、Morton、A.、Bagnulo、M.、Burbridge、T.、Aitken、P。、およびA. Akhter、「ブロードバンドパフォーマンスの大規模測定（LMAP）のフレームワーク」、RFC 7594、DOI 10.17487 / RFC7594、2015年9月、<http://www.rfc-editor.org/info/rfc7594>。
Acknowledgements
謝辞
For [RFC2680], thanks are due to Matt Mathis for encouraging this work and for calling attention on so many occasions to the significance of packet loss. Thanks are due also to Vern Paxson for his valuable comments on early drafts and to Garry Couch and Will Leland for several useful suggestions.
[RFC2680]に対して、この作業を奨励し、パケット損失の重要性について非常に多くの機会に注意を喚起してくれたMatt Mathisに感謝します。初期ドラフトに関する貴重なコメントを提供してくれたVern Paxsonと、いくつかの有用な提案をしてくれたGarry CouchとWill Lelandにも感謝します。
For this document, thanks to Joachim Fabini, Ruediger Geib, Nalini Elkins, and Barry Constantine for sharing their measurement experience as part of their careful reviews. Brian Carpenter and Scott Bradner provided useful feedback at IETF Last Call.
このドキュメントについて、慎重なレビューの一環として測定の経験を共有してくれたJoachim Fabini、Ruediger Geib、Nalini Elkins、Barry Constantineに感謝します。 Brian CarpenterとScott BradnerがIETF Last Callで有益なフィードバックを提供しました。
Authors' Addresses
著者のアドレス
Guy Almes Texas A&M
ガイアルメステキサスA＆M
Email: almes@acm.org
Sunil Kalidindi Ixia
スニルカリディンディイクシア
Email: skalidindi@ixiacom.com
Matt Zekauskas Internet2
Matt Zekauskas Internet2
Email: matt@internet2.edu
Al Morton (editor) AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States
Al Morton（編集者）AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748アメリカ合衆国
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com
URI: http://home.comcast.net/~acmacm/