[要約] RFC 6673は、往復遅延パケットロスメトリクスに関する標準化された手法を提供する。その目的は、ネットワークのパフォーマンスを評価し、パケットロスの問題を特定することである。
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 6673 AT&T Labs
Category: Standards Track August 2012
ISSN: 2070-1721
Round-Trip Packet Loss Metrics
ラウンドトリップパケット損失メトリック
Abstract
概要
Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.
多くのユーザーアプリケーション（およびそれらを可能にするトランスポートプロトコル）では、双方向通信が必要です。この機能を評価し、テストシステムを簡素化するために、実際には頻繁に往復損失測定が行われます。 RFC 5357で指定されている双方向アクティブ測定プロトコルは、インターネットの往復損失測定機能を確立します。ただし、現在、RFC 2330フレームワークに従って指定された往復パケット損失メトリックはありません。
This memo adds round-trip loss to the set of IP Performance Metrics (IPPM).
このメモは、一連のIPパフォーマンスメトリック（IPPM）に往復損失を追加します。
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/rfc6673.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6673で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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 ....................................................3
1.1. Motivation .................................................4
1.2. Requirements Language ......................................5
2. Scope ...........................................................5
3. Common Specifications for Round-Trip Metrics ....................5
3.1. Name: Type-P-* .............................................5
3.2. Metric Parameters ..........................................5
3.3. Metric Definition ..........................................6
3.4. Metric Units ...............................................6
4. A Singleton Round-Trip Loss Metric ..............................7
4.1. Name: Type-P-Round-trip-Loss ...............................7
4.2. Metric Parameters ..........................................7
4.3. Definition and Metric Units ................................7
4.4. Discussion and Other Details ...............................8
5. A Sample Round-Trip Loss Metric .................................9
5.1. Name: Type-P-Round-trip-Loss-<Sample>-Stream ...............9
5.2. Metric Parameters ..........................................9
5.3. Definition and Metric Units ................................9
5.4. Discussion and Other Details ..............................10
6. Round-Trip Loss Statistic ......................................10
6.1. Type-P-Round-trip-Loss-<Sample>-Ratio .....................10
7. Round-Trip Testing and One-Way Reporting .......................11
8. Measurement Considerations and Calibration .....................11
9. Security Considerations ........................................12
9.1. Denial-of-Service Attacks .................................12
9.2. User Data Confidentiality .................................12
9.3. Interference with the Metrics .............................12
10. IANA Considerations ...........................................13
11. Acknowledgements ..............................................13
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................14
This memo defines a metric to quantify an IP network's ability to transfer packets in both directions from one host to another host. Two-way communication is almost always needed; thus, failure to transfer a packet in either direction constitutes a round-trip packet loss.
このメモは、あるホストから別のホストへ両方向にパケットを転送するIPネットワークの能力を定量化するためのメトリックを定義します。ほとんどの場合、双方向通信が必要です。したがって、どちらの方向にもパケットを転送できないと、往復のパケット損失になります。
This memo defines a metric for round-trip packet loss on Internet paths. It builds on the notions and conventions introduced in the IP Performance Metrics (IPPM) framework [RFC2330]. Also, the specifications of the one-way packet loss metric for IPPM [RFC2680] and the round-trip delay metric for IPPM [RFC2681] are frequently referenced and modified to match the round-trip circumstances addressed here. However, this memo assumes that the reader is familiar with the references; thus, it does not repeat material as was done in [RFC2681].
このメモは、インターネットパスでの往復パケット損失のメトリックを定義します。これは、IP Performance Metrics（IPPM）フレームワーク[RFC2330]で導入された概念と規則に基づいています。また、IPPM [RFC2680]の片方向パケット損失メトリックおよびIPPM [RFC2681]のラウンドトリップ遅延メトリックの仕様は、ここで説明するラウンドトリップ環境に一致するように頻繁に参照および変更されます。ただし、このメモは読者が参考文献に精通していることを前提としています。したがって、[RFC2681]で行われたように材料を繰り返すことはありません。
This memo uses the terms "two-way" and "round-trip" synonymously.
このメモでは、「双方向」と「往復」という用語を同義語として使用しています。
Many user applications and the transport protocols that make them possible require two-way communications. For example, the TCP SYN->, <-SYN-ACK, ACK-> three-way handshake attempted billions of times each day cannot be completed without two-way connectivity in a near-simultaneous time interval. Thus, measurements of Internet round-trip packet loss performance provide a basis to infer application performance more easily.
多くのユーザーアプリケーションとそれを可能にするトランスポートプロトコルには、双方向通信が必要です。たとえば、TCP SYN->、<-SYN-ACK、ACK->が毎日数十億回試行された3ウェイハンドシェイクは、ほぼ同時の時間間隔で双方向接続がなければ完了できません。したがって、インターネット往復パケット損失パフォーマンスの測定は、アプリケーションのパフォーマンスをより簡単に推測するための基礎を提供します。
Measurement system designers have also recognized advantages of system simplicity when one host simply echoes or reflects test packets to the sender. Round-trip packet loss measurements are frequently conducted and reported in practice. The ubiquitous "ping" tools allow the measurement of round-trip packet loss and delay but usually require ICMP Echo-Request/Reply support, and ICMP packets may encounter exceptional treatment on the measurement path (see Section 2.6 of [RFC2681]). The Two-Way Active Measurement Protocol (TWAMP) specified in [RFC5357] establishes a round-trip packet loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the [RFC2330] framework.
また、測定システムの設計者は、1つのホストがテストパケットを送信者に単にエコーまたは反射する場合のシステムの単純さの利点を認識しています。往復パケット損失測定は頻繁に行われ、実際に報告されます。ユビキタスな「ping」ツールを使用すると、往復のパケット損失と遅延を測定できますが、通常はICMPエコー要求/応答のサポートが必要です。ICMPパケットは、測定パスで例外的な扱いを受ける場合があります（[RFC2681]のセクション2.6を参照）。 [RFC5357]で指定されている双方向アクティブ測定プロトコル（TWAMP）は、インターネットの往復パケット損失測定機能を確立します。ただし、現在[RFC2330]フレームワークに従って指定された往復パケット損失メトリックはありません。
[RFC2681] indicates that round-trip measurements may sometimes encounter "asymmetric" paths. When loss is observed using a round-trip measurement, there is often a desire to ascertain which of the two directional paths "lost" the packet. Under some circumstances, it is possible to make this inference. The round-trip measurement method raises a few complications when interpreting the embedded one-way results, and the user should be aware of them.
[RFC2681]は、ラウンドトリップ測定で「非対称」パスが発生する場合があることを示しています。往復測定を使用して損失が観測された場合、2つの方向パスのどちらがパケットを「損失」したかを確認したい場合がよくあります。状況によっては、この推論を行うことが可能です。ラウンドトリップ測定方法は、埋め込まれた一方向の結果を解釈するときにいくつかの複雑化を引き起こし、ユーザーはそれらに注意する必要があります。
[RFC2681] also points out that loss measurement conducted sequentially in both directions of a path and reported as a round-trip result may be exactly the desired metric. On the other hand, it may be difficult to derive the state of round-trip packet loss from one-way measurements conducted in each direction unless a method to match the appropriate one-way measurements has been pre-arranged.
[RFC2681]はまた、パスの両方向で順次行われ、往復の結果として報告される損失測定は、正確に望ましいメトリックになる可能性があることも指摘しています。一方、適切な一方向の測定値と一致する方法が事前に準備されていないと、各方向で行われた一方向の測定値から往復パケット損失の状態を導き出すことが難しい場合があります。
Finally, many measurement systems report statistics on a conditional delay distribution, where the condition is packet arrival at the destination. This condition is encouraged in [RFC3393], [RFC5481], and [RFC6703]. As a result, lost packets need to be reported separately, according to a standardized metric. This memo defines such a metric.
最後に、多くの測定システムは、条件付き遅延分布に関する統計を報告します。条件は、宛先へのパケット到着です。この状態は、[RFC3393]、[RFC5481]、および[RFC6703]で推奨されています。その結果、標準化されたメトリックに従って、失われたパケットを個別に報告する必要があります。このメモは、そのようなメトリックを定義します。
See Section 1.1 of [RFC2680] for additional motivation of the packet loss metric.
パケット損失測定基準のさらなる動機については、[RFC2680]のセクション1.1を参照してください。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This memo defines a round-trip packet loss metric using the conventions of the IPPM framework [RFC2330].
このメモは、IPPMフレームワーク[RFC2330]の規則を使用して、往復のパケット損失メトリックを定義します。
The memo defines a singleton metric, a sample metric, and a statistic, as per [RFC2330]. The [RFC2330] framework is for active measurement methods. Although this metric MAY be applicable in passive measurement as well, discussion of additional considerations for the passive scenario are beyond the normative scope of this memo.
[RFC2330]に従って、メモはシングルトンメトリック、サンプルメトリック、および統計を定義します。 [RFC2330]フレームワークは、アクティブな測定方法のためのものです。このメトリックはパッシブ測定にも適用できる場合がありますが、パッシブシナリオの追加の考慮事項の説明は、このメモの規範的な範囲を超えています。
The memo also investigates the topic of one-way loss inference from a two-way measurement and lists some key considerations.
このメモは、双方向測定からの一方向損失の推論のトピックも調査し、いくつかの重要な考慮事項を示しています。
To reduce the redundant information presented in the detailed metrics sections that follow, this section presents the specifications that are common to two or more metrics. The section is organized using the same subsections as the individual metrics, to simplify comparisons.
以下の詳細なメトリックセクションで示される冗長な情報を減らすために、このセクションでは、2つ以上のメトリックに共通の仕様を示します。このセクションは、比較を簡単にするために、個々のメトリックと同じサブセクションを使用して編成されています。
All metrics use the Type-P convention as described in [RFC2330]. The rest of the name is unique to each metric.
[RFC2330]で説明されているように、すべてのメトリックはType-P規則を使用します。名前の残りの部分は、各メトリックに固有です。
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 (start of test interval) o Tf, a time (end of test interval)
o T、時間（テスト間隔の開始）o Tf、時間（テスト間隔の終了）
o lambda, a rate in reciprocal seconds (for Poisson Streams)
o ラムダ、秒単位のレート（ポアソンストリームの場合）
o incT, the nominal duration of inter-packet interval, first bit to first bit (for Periodic Streams)
o incT、パケット間間隔の公称期間、最初のビットから最初のビット（定期的なストリームの場合）
o T0, a time that MUST be selected at random from the interval [T, T+dT] to start generating packets and taking measurements (for Periodic Streams)
o T0、間隔[T、T + dT]からランダムに選択する必要がある時間。パケットの生成と測定を開始します（定期的なストリームの場合）。
o TstampSrc, the wire time of the packet as measured at MP(Src) as it leaves for Dst.
o TstampSrc、MP（Src）で測定されたパケットのワイヤ時間。
o TstampDst, the wire time of the packet as measured at MP(Dst), assigned to packets that arrive within a "reasonable" time (less than Tmax).
o TstampDst。MP（Dst）で測定されたパケットのワイヤ時間で、「妥当な」時間（Tmax未満）で到着するパケットに割り当てられます。
o Tmax, a maximum waiting time for packets to arrive at Src, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost).
o パケットがSrcに到着するまでの最大待機時間であるTmaxは、破棄された（失われた）パケットからの長い遅延のあるパケットを明確にするために十分に長く設定します。
o M, the total number of packets sent between T0 and Tf
o M、T0とTfの間で送信されたパケットの総数
o N, the total number of packets received at Dst (sent between T0 and Tf)
o N、Dstで受信されたパケットの総数（T0とTfの間で送信）
o Type-P, as defined in [RFC2330], which includes any field that may affect a packet's treatment as it traverses the network
o [RFC2330]で定義されているType-P。パケットがネットワークを通過するときにパケットの処理に影響を与える可能性のあるフィールドが含まれます。
This section is specific to each metric.
このセクションは、各メトリックに固有です。
The metric units are logical (1 or 0) when describing a single packet's loss performance, where a 0 indicates successful packet transmission and a 1 indicates packet loss.
単一のパケットの損失パフォーマンスを表す場合、メトリック単位は論理的（1または0）です。0はパケット送信の成功を示し、1はパケット損失を示します。
Units of time are as specified in [RFC2330].
時間の単位は[RFC2330]で指定されたとおりです。
Other units used are defined in the associated section where needed (e.g., Section 6.1 in the case of Type-P-Round-trip-Loss-<Sample>-Ratio).
使用される他の単位は、必要に応じて関連するセクションで定義されます（たとえば、Type-P-Round-trip-Loss- <Sample> -Ratioの場合はセクション6.1）。
See Section 3.2.
セクション3.2を参照してください。
Type-P-Round-trip-Loss SHALL be represented by the binary logical values (or their equivalents) when the following conditions are met:
Type-P-Round-trip-Lossは、以下の条件が満たされた場合に、バイナリ論理値（または同等の値）で表されるものとします（SHALL）。
Type-P-Round-trip-Loss = 0:
Type-P-Round-trip-Loss = 0：
o Src sent the first bit of a Type-P packet to Dst at wire-time TstampSrc,
o SrcはType-Pパケットの最初のビットをワイヤタイムTstampSrcでDstに送信しました。
o that Dst received that packet,
o そのDstがそのパケットを受信し、
o the Dst sent a Type-P packet back to the Src as quickly as possible (certainly less than Tmax, and fast enough for the intended purpose), and
o DstがType-Pパケットをできるだけ早くSrcに送り返しました（確かにTmax未満で、意図した目的に十分な速さ）。
o that Src received the last bit of the reflected packet prior to wire-time TstampSrc + Tmax.
o SrcがワイヤタイムTstampSrc + Tmaxの前に反射パケットの最後のビットを受信したこと。
Type-P-Round-trip-Loss = 1:
Type-P-Round-trip-Loss = 1：
o Src sent the first bit of a Type-P packet to Dst at wire-time TstampSrc,
o SrcはType-Pパケットの最初のビットをワイヤタイムTstampSrcでDstに送信しました。
o that Src did not receive the last bit of the reflected packet before the waiting time lapsed at TstampSrc + Tmax.
o TstampSrc + Tmaxで待機時間が経過する前に、Srcが反射パケットの最後のビットを受信しなかった。
Possible causes for the Loss = 1 outcome are as follows:
損失= 1の結果の考えられる原因は次のとおりです。
o the Dst did not receive that packet,
o Dstはそのパケットを受信しませんでした。
o the Dst did not send a Type-P packet back to the Src, or
o DstがType-PパケットをSrcに返送しなかった、または
o the Src did not receive a reflected Type-P packet sent from the Dst.
o Srcは、Dstから送信された反映されたType-Pパケットを受信しませんでした。
Following the precedent of Section 2.4 of [RFC2681], we make the simplifying assertion that round-trip loss measured between two hosts is equal regardless of the host that originates the test:
[RFC2681]のセクション2.4の前例に従って、2つのホスト間で測定された往復損失は、テストを開始したホストに関係なく等しいという簡単な主張を行います。
Type-P-Round-trip-Loss(Src->Dst->Src) =
Type-P-Round-trip-Loss(Dst->Src->Dst)
(and agree with the rationale presented there -- that the ambiguity introduced is a small price to pay for measurement efficiency).
（そしてそこに提示された理論的根拠に同意します-導入された曖昧さは測定効率に支払うための小さな代償です）。
Therefore, each singleton can be represented by pairs of elements as follows:
したがって、各シングルトンは次のように要素のペアで表すことができます。
o TstampSrc, the wire time of the packet at the Src (beginning the round-trip journey).
o TstampSrc、Srcでのパケットのワイヤタイム（往復の旅の始まり）。
o L, either zero or one (or some logical equivalent), where L=1 indicates loss and L=0 indicates successful round-trip arrival prior to TstampSrc + Tmax.
o L、ゼロまたは1（または論理的に同等）のいずれか。L= 1は損失を示し、L = 0はTstampSrc + Tmaxの前に往復が成功したことを示します。
See [RFC2680] and [RFC2681] for extensive discussion, methods of measurement, errors and uncertainties, and other fundamental considerations that need not be repeated here.
広範な議論、測定方法、エラーと不確実性、およびここで繰り返す必要のないその他の基本的な考慮事項については、[RFC2680]および[RFC2681]を参照してください。
We add the following guidance regarding the responder process to "send a Type-P packet back to the Src as quickly as possible".
レスポンダプロセスに関する次のガイダンスを追加して、「Type-Pパケットをできるだけ早くSrcに送り返す」ようにします。
A response that was not generated within Tmax is inadequate for any realistic test, and the Src will discard such responses. A responder that serves typical round-trip packet loss testing (which is relevant to higher-layer application performance) SHOULD produce a response in 1 second or less. A responder that is unable to satisfy this requirement SHOULD log the fact so that an operator can adjust the load and priorities as necessary. Analysis of responder timestamps [RFC5357] that finds responses are not generated in a timely fashion SHOULD result in operator notification, and the operator SHOULD suspend tests to the responder, since it may be overloaded. Additional measurement considerations are described in Section 8 below.
Tmax内で生成されなかった応答は、現実的なテストには不十分であり、Srcはそのような応答を破棄します。一般的な往復パケット損失テスト（上位層のアプリケーションパフォーマンスに関連する）を提供するレスポンダは、1秒以内に応答を生成する必要があります（SHOULD）。この要件を満たせないレスポンダは、オペレータが必要に応じて負荷と優先度を調整できるように、事実をログに記録する必要があります。応答がタイムリーに生成されていないことがわかるレスポンダタイムスタンプの分析[RFC5357]は、オペレーターに通知する必要があり（SHOULD）、オペレーターは過負荷になる可能性があるため、レスポンダーへのテストを一時停止する必要があります（SHOULD）。測定に関するその他の考慮事項については、以下のセクション8で説明します。
Given the singleton metric Type-P-Round-trip-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 TstampSrc. This can be done in several ways, including the following:
シングルトンメトリックType-P-Round-trip-Lossを考慮して、このようなシングルトンの特定のサンプルを1つ定義します。サンプルのアイデアは、パラメーターSrc、Dst、およびType-Pの特定のバインディングを選択し、パラメーターTstampSrcの値のサンプルを定義することです。これは、以下を含むいくつかの方法で実行できます。
1. Poisson: a pseudo-random Poisson process of rate lambda, whose values fall between T and Tf. The time interval between successive values of TstampSrc will then average 1/lambda, as per Section 11.1.1 of [RFC2330].
1. ポアソン：レートラムダの擬似ランダムポアソンプロセス。値はTとTfの間にあります。 [RFC2330]のセクション11.1.1に従って、TstampSrcの連続する値の間の時間間隔は平均して1 /ラムダになります。
2. Periodic: a periodic stream process with pseudo-random start time T0 between T and dT, and nominal inter-packet interval incT, as per [RFC3432].
2. 定期的：[RFC3432]のように、TとdTの間の擬似ランダム開始時間T0、および公称パケット間間隔incTを持つ定期的なストリームプロセス。
In the metric name, the variable <Sample> SHALL be replaced with the process used to define the sample, using one of the above processes (or another sample process meeting the criteria in Section 11.1 of [RFC2330], the details of which MUST be reported with the results if used).
メトリック名で、変数<Sample>は、上記のプロセスのいずれか（または[RFC2330]のセクション11.1の基準を満たす別のサンプルプロセス）を使用して、サンプルの定義に使用されたプロセスに置き換える必要があります（SHALL）。使用した場合は結果とともに報告されます）。
See Section 3.2.
セクション3.2を参照してください。
Given one of the methods for defining the test interval -- the sample of times (TstampSrc) and other metric parameters -- we obtain a sequence of Type-P-Round-trip-Loss singletons as defined in Section 4.3.
テスト間隔を定義する方法の1つ（時間のサンプル（TstampSrc）およびその他のメトリックパラメーター）を指定すると、セクション4.3で定義されているType-P-Round-trip-Lossシングルトンのシーケンスが取得されます。
Type-P-Round-trip-Loss-<Sample>-Stream SHALL be a sequence of pairs with elements as follows:
Type-P-Round-trip-Loss- <Sample> -Streamは、次のような要素を持つペアのシーケンスである必要があります。
o TstampSrc, as above
o 上記のTstampSrc
o L, either zero or one (or some logical equivalent), where L=1 indicates loss and L=0 indicates successful round-trip arrival prior to TstampSrc + Tmax
o L、ゼロまたは1（または論理的に同等のもの）のいずれか。L= 1は損失を示し、L = 0はTstampSrc + Tmaxの前に往復が成功したことを示します。
and where <Sample> SHALL be replaced with "Poisson", "Periodic", or an appropriate term to designate another sample method as described in Section 5 above.
また、<Sample>は、上記のセクション5で説明した別のサンプルメソッドを指定するために、「Poisson」、「Periodic」、または適切な用語で置き換える必要があります（SHALL）。
See [RFC2680] and [RFC2681] for extensive discussion, methods of measurement, errors and uncertainties, and other fundamental considerations that need not be repeated here. However, when these references were approved, the packet reordering metrics in [RFC4737] had not yet been defined, nor had reordering been addressed in IPPM methodologies.
広範な議論、測定方法、エラーと不確実性、およびここで繰り返す必要のないその他の基本的な考慮事項については、[RFC2680]および[RFC2681]を参照してください。ただし、これらの参照が承認されたとき、[RFC4737]のパケット順序変更メトリックはまだ定義されておらず、IPPM方法論で順序変更も扱われていませんでした。
[RFC4737] defines packets that arrive "late" with respect to their sending order as reordered -- for example, when packets arrive with sequence numbers 4, 7, 5, 6, then packets 5 and 6 are reordered, and they are obviously not lost because they have arrived within some reasonable waiting time threshold. The presence of reordering on a round-trip path has several likely effects on the measurement.
[RFC4737]は、送信順序に関して「遅れて」到着するパケットを再配列として定義します。たとえば、パケットがシーケンス番号4、7、5、6で到着すると、パケット5と6は再配列されますが、それらは明らかに彼らはいくつかの合理的な待機時間のしきい値内に到着したために失われました。往復パスに並べ替えが存在すると、測定に影響を与える可能性があります。
1. Methods of measurement should continue to wait the specified time for packets and avoid prematurely declaring round-trip packet loss when a sequence gap or error is observed.
1. 測定方法は、パケットの指定された時間待機し続け、シーケンスのギャップまたはエラーが観察されたときに、往復のパケット損失を時期尚早に宣言しないようにする必要があります。
2. The time distribution of the singletons in the sample has been significantly changed.
2. サンプル内のシングルトンの時間分布が大幅に変更されました。
3. Either the original packet stream or the reflected packet stream experienced path instability, and the original conditions may no longer be present.
3. 元のパケットストリームまたは反射されたパケットストリームのいずれかでパスが不安定になり、元の状態がなくなっている可能性があります。
Measurement implementations MUST address the possibility of packet reordering and avoid related errors in their processes.
測定の実装は、パケットの並べ替えの可能性に対処し、プロセスでの関連エラーを回避する必要があります。
This section gives the primary and overall statistic for loss performance. Additional statistics and metrics originally prepared for one-way loss MAY also be applicable.
このセクションでは、損失パフォーマンスの主な統計と全体的な統計を示します。一方向損失のために最初に準備された追加の統計およびメトリックも適用される場合があります。
Given a Type-P-Round-trip-Loss-<Sample>-Stream, the average of all the logical values, L, in the stream is the Type-P-Round-trip-Loss-<Sample>-Ratio. This ratio is in units of lost packets per round-trip transmissions actually attempted.
Type-P-Round-trip-Loss- <Sample> -Streamの場合、ストリーム内のすべての論理値Lの平均はType-P-Round-trip-Loss- <Sample> -Ratioです。この比率は、実際に試行された往復伝送あたりの損失パケットの単位です。
In addition, the Type-P-Round-trip-Loss-<Sample>-Ratio is undefined if the sample is empty.
さらに、サンプルが空の場合、Type-P-Round-trip-Loss- <Sample> -Ratioは未定義です。
This section raises considerations for results collected using a round-trip measurement architecture, such as in TWAMP [RFC5357].
このセクションでは、TWAMP [RFC5357]などのラウンドトリップ測定アーキテクチャを使用して収集された結果に関する考慮事項を取り上げます。
The sampling process for the reverse path (Dst->Src) is a conditional process that depends on successful packet arrival at the Dst and correct operation at the Dst to generate the reflected packet. Therefore, the sampling process for the reverse path will be significantly affected when appreciable loss occurs on the Src->Dst path, making an attempt to assess the reverse path performance invalid (for loss or possibly any metric).
リバースパスのサンプリングプロセス（Dst-> Src）は、Dstでのパケットの正常な到着と、Dstでの正常な動作に依存して、反射パケットを生成する条件付きプロセスです。したがって、Src-> Dstパスでかなりの損失が発生すると、リバースパスのサンプリングプロセスが大きく影響を受け、リバースパスのパフォーマンスを（損失またはおそらくメトリックに対して）無効に評価しようとします。
Further, the sampling times for the reverse path (Dst->Src) are a random process that depends on the original sample times (TstampSrc), the one-way delay for successful packet arrival at the Dst, and time taken at the Dst to generate the reflected packet. Therefore, the sampling process for the reverse path will be significantly affected when appreciable delay variation occurs on the Src->Dst path, making an attempt to assess the reverse path performance invalid (for loss or possibly any metric).
さらに、リバースパスのサンプリング時間（Dst-> Src）はランダムなプロセスであり、元のサンプル時間（TstampSrc）、Dstにパケットが正常に到着する一方向の遅延、およびDstから反射されたパケットを生成します。したがって、Src-> Dstパスでかなりの遅延変動が発生すると、リバースパスのサンプリングプロセスが大幅に影響を受け、リバースパスのパフォーマンスを（損失またはおそらくメトリックに対して）無効に評価しようとします。
As discussed above in Section 5.4, packet reordering is always a possibility. In addition to the severe delay variation that usually accompanies it, reordering on the Src->Dst path will cause a misalignment of sequence numbers applied at the Dst when compared to the sender numbers. Measurement implementations MUST address this possible outcome.
上記のセクション5.4で説明したように、パケットの並べ替えは常に可能です。通常それに伴う重大な遅延変動に加えて、Src-> Dstパスでの並べ替えは、送信者番号と比較したときに、Dstで適用されるシーケンス番号の不整合を引き起こします。測定の実装は、この起こり得る結果に対処しなければなりません。
Prior to conducting this measurement, the participating hosts MUST be configured to send and receive test packets of the chosen Type-P. Standard measurement protocols are capable of this task [RFC5357], but any reliable method is sufficient (e.g., if the issues with ICMP discussed in Section 2.6 of [RFC2681] can be alleviated, and the requirements of Sections 4.3 and 4.4 above are met, then ICMP could be used).
この測定を実行する前に、選択したタイプPのテストパケットを送受信するように参加ホストを構成する必要があります。標準の測定プロトコルでこのタスクを実行できますが[RFC5357]、信頼できる方法で十分です（たとえば、[RFC2681]のセクション2.6で説明されているICMPの問題を緩和でき、上記のセクション4.3および4.4の要件が満たされている場合、その後、ICMPを使用できます）。
Two key features of the host that receives test packets and returns them to the originating host are described in Section 4.2 of [RFC5357]. Every received test packet MUST result in a responding packet, and the response MUST be generated as quickly as possible. This implies that interface buffers will be serviced promptly and that buffer discards will be extremely rare. These features of the measurement equipment MUST be calibrated according to Section 3.7.3 of [RFC2679] when operating under a representative measurement load (as defined by the user). Both unexpected test packet discards, and the systematic and random errors and uncertainties, MUST be recorded.
[RFC5357]のセクション4.2に、テストパケットを受信して元のホストに返すホストの2つの主要な機能が説明されています。受信したすべてのテストパケットは応答パケットになる必要があり、応答は可能な限り迅速に生成される必要があります。これは、インターフェイスバッファが迅速に処理され、バッファ廃棄が非常にまれであることを意味します。測定機器のこれらの機能は、（ユーザーが定義した）代表的な測定負荷の下で動作する場合、[RFC2679]のセクション3.7.3に従って較正する必要があります。予期しないテストパケット廃棄、および系統的エラーとランダムエラー、および不確実性の両方を記録する必要があります。
We note that Section 4.2.1 of [RFC5357] specifies a method to collect all four significant timestamps needed to describe a packet's round-trip delay [RFC2681] and remove the processing time incurred at the responding host. This information supports the measurement of the corresponding one-way delays encountered on the round-trip path, which can identify path asymmetry or unexpected processing time at the responding host.
[RFC5357]のセクション4.2.1は、パケットの往復遅延[RFC2681]を記述するために必要な4つの重要なタイムスタンプすべてを収集し、応答ホストで発生した処理時間を削除する方法を指定していることに注意してください。この情報は、ラウンドトリップパスで発生した対応する一方向の遅延の測定をサポートします。これにより、応答ホストでのパスの非対称または予期しない処理時間を特定できます。
This metric requires a stream of packets sent from one host (source) to another host (destination) through intervening networks, and back. This method could be abused for denial-of-service attacks directed at the destination and/or the intervening network(s).
このメトリックには、あるネットワーク（送信元）から別のホスト（宛先）に、介在するネットワークを経由して送信されるパケットのストリームが必要です。この方法は、宛先および/または介在するネットワークへのサービス拒否攻撃に悪用される可能性があります。
Administrators of source, destination, and intervening network(s) should establish bilateral or multilateral agreements regarding the timing, size, and frequency of collection of sample metrics. Use of this method in excess of the terms agreed upon by the participants may be cause for immediate rejection or discard of packets, or other escalation procedures as defined between the affected parties.
送信元、宛先、および介在するネットワークの管理者は、サンプルメトリックの収集のタイミング、サイズ、および頻度に関して、二国間または多国間の合意を確立する必要があります。参加者が合意した条件を超えてこの方法を使用すると、パケットの即時拒否または破棄、または影響を受ける当事者間で定義されたその他のエスカレーション手順が発生する可能性があります。
Active use of this method generates packets for a sample, rather than taking samples based on user data, and does not threaten user data confidentiality. Passive measurement must restrict attention to the headers of interest. Since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep this information safe and confidential. In most cases, a hashing function will produce a value suitable for payload comparisons.
この方法を積極的に使用すると、ユーザーデータに基づいてサンプルを取得するのではなく、サンプルのパケットを生成し、ユーザーデータの機密性を脅かしません。パッシブ測定では、関心のあるヘッダーへの注意を制限する必要があります。ユーザーペイロードは長さ分析のために一時的に保存される場合があるため、この情報を安全かつ機密に保つために適切な予防策を講じる必要があります。ほとんどの場合、ハッシュ関数はペイロードの比較に適した値を生成します。
It may be possible to identify that a certain packet or stream of packets is part of a sample. With that knowledge at the destination and/or the intervening networks, it is possible to change the processing of the packets (e.g., increasing or decreasing delay) in a way that may distort the measured performance. It may also be possible to generate additional packets that appear to be part of the sample metric. These additional packets are likely to perturb the results of the sample measurement.
特定のパケットまたはパケットのストリームがサンプルの一部であることを識別できる場合があります。宛先および／または介在ネットワークにおけるその知識を用いて、測定された性能を歪める可能性がある方法で、パケットの処理を変更する（例えば、遅延を増加または減少させる）ことが可能である。サンプルメトリックの一部であると思われる追加のパケットを生成することも可能です。これらの追加パケットは、サンプル測定の結果を混乱させる可能性があります。
Authentication or encryption techniques, such as digital signatures, MAY be used where appropriate to guard against injected traffic attacks. [RFC5357] includes both authentication and encryption features.
デジタル署名などの認証または暗号化技術は、注入されたトラフィック攻撃から保護するために適切な場所で使用できます。 [RFC5357]には、認証機能と暗号化機能の両方が含まれています。
Metrics previously defined in the IETF were registered in the IANA IPPM Metrics Registry; however, this process was discontinued when the registry structure was found to be inadequate, and the registry was declared obsolete [RFC6248].
以前にIETFで定義されたメトリックは、IANA IPPMメトリックレジストリに登録されました。しかし、レジストリの構造が不十分であることが判明し、レジストリが廃止されたと宣言された場合、このプロセスは中止されました[RFC6248]。
Although the metrics in this document may be considered for some form of registration in the future, no IANA action is requested at this time.
このドキュメントのメトリックは、将来のある種の登録のために検討される可能性がありますが、現時点ではIANAのアクションは要求されていません。
The author thanks Tiziano Ionta for his careful review of this memo, primarily resulting in the development of measurement considerations using TWAMP [RFC5357] as an example method. The reviews of Adrian Farrel and Benoit Claise also contributed to the clarity of the memo.
著者は、このメモを注意深くレビューしてくれたTiziano Iontaに感謝します。その結果、主にTWAMP [RFC5357]をメソッドの例として使用した測定の考慮事項が開発されました。エイドリアン・ファレルとブノワ・クレイズのレビューもメモの明快さに貢献しました。
[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月。
[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、「Framework for IP Performance Metrics」、RFC 2330、1998年5月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月。
[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月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393]デミケリス、CおよびP.キメント、「IPパフォーマンスメトリックのIPパケット遅延変動メトリック（IPPM）」、RFC 3393、2002年11月。
[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月。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.
[RFC4737] Morton、A.、Ciavattone、L.、Ramachandran、G.、Shalunov、S。、およびJ. Perser、「Packet Reordering Metrics」、RFC 4737、2006年11月。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、2008年10月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481] Morton、A。およびB. Claise、「Packet Delay Variation Applicability Statement」、RFC 5481、2009年3月。
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 2011.
[RFC6248] Morton、A。、「RFC 4148およびIP Performance Metrics（IPPM）Registry of Metricsは廃止されました」、RFC 6248、2011年4月。
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, August 2012.
[RFC6703] Morton、A.、Ramachandran、G。、およびG. Maguluri、「Reporting IP Network Performance Metrics：Different Points of View」、RFC 6703、2012年8月。
Author's Address
著者のアドレス
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA
Al Morton AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748 USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/