Internet Engineering Task Force (IETF) A. Clark
Request for Comments: 6390 Telchemy Incorporated
BCP: 170 B. Claise
Category: Best Current Practice Cisco Systems, Inc.
ISSN: 2070-1721 October 2011
Guidelines for Considering New Performance Metric Development
Abstract
抽象
This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services.
この文書では、フレームワークおよびIETF-指定されたプロトコルを介して伝送プロトコルやアプリケーションのパフォーマンス・メトリックを開発するためのプロセスについて説明します。これらのメトリックは、ライブネットワークとサービスのトラフィックを特徴付けるために使用することができます。
Status of This Memo
このメモのステータス
This memo documents an Internet Best Current Practice.
このメモはインターネット最も良い現在の練習を説明します。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、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/rfc6390.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6390で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Background and Motivation ..................................4
1.2. Organization of This Document ..............................5
2. Terminology .....................................................5
2.1. Requirements Language ......................................5
2.2. Performance Metrics Directorate ............................5
2.3. Quality of Service .........................................5
2.4. Quality of Experience ......................................6
2.5. Performance Metric .........................................6
3. Purpose and Scope ...............................................6
4. Relationship between QoS, QoE, and Application-Specific
Performance Metrics .............................................7
5. Performance Metrics Development .................................7
5.1. Identifying and Categorizing the Audience ..................7
5.2. Definitions of a Performance Metric ........................8
5.3. Computed Performance Metrics ...............................9
5.3.1. Composed Performance Metrics ........................9
5.3.2. Index ..............................................10
5.4. Performance Metric Specification ..........................10
5.4.1. Outline ............................................10
5.4.2. Normative Parts of Performance Metric Definition ...11
5.4.3. Informative Parts of Performance Metric
Definition .........................................13
5.4.4. Performance Metric Definition Template .............14
5.4.5. Example: Loss Rate .................................15
5.5. Dependencies ..............................................16
5.5.1. Timing Accuracy ....................................16
5.5.2. Dependencies of Performance Metric Definitions on
Related Events or Metrics ..........................16
5.5.3. Relationship between Performance Metric and
Lower-Layer Performance Metrics ....................17
5.5.4. Middlebox Presence .................................17
5.6. Organization of Results ...................................17
5.7. Parameters: The Variables of a Performance Metric .........18
6. Performance Metric Development Process .........................18
6.1. New Proposals for Performance Metrics .....................18
6.2. Reviewing Metrics .........................................19
6.3. Performance Metrics Directorate Interaction with
Other WGs .................................................19
6.4. Standards Track Performance Metrics .......................20
7. Security Considerations ........................................20
8. Acknowledgements ...............................................20
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................21
Many networking technologies, applications, or services are distributed in nature, and their performance may be impacted by IP impairments, server capacity, congestion, and other factors. It is important to measure the performance of applications and services to ensure that quality objectives are being met and to support problem diagnosis. Standardized metrics help ensure that performance measurement is implemented consistently, and they facilitate interpretation and comparison.
多くのネットワーク技術、アプリケーション、またはサービスは、自然界に分布しており、その性能はIP障害、サーバー容量、混雑、およびその他の要因によって影響を受ける可能性があります。品質目標が満たされていることを確認するために、問題の診断をサポートするためのアプリケーションやサービスのパフォーマンスを測定することが重要です。標準化されたメトリックは、パフォーマンス測定が一貫実装、そして、彼らは解釈や比較を容易にしていることを確認できます。
There are at least three phases in the development of performance standards. They are as follows:
性能基準の開発には少なくとも3つのフェーズがあります。それらは次の通りです：
During the development of metrics, it is often useful to define performance objectives and expected value ranges. This additional information is typically not part of the formal specification of the metric but does provide useful background for implementers and users of the metric.
メトリクスの開発中に、パフォーマンス目標と期待値の範囲を定義しておくと便利です。この追加情報は、通常、メトリックの正式な仕様の一部ではなく、実装と評価指標のユーザーのために有用な背景を提供します。
The intended audience for this document includes, but is not limited to, IETF participants who write Performance Metrics documents in the IETF, reviewers of such documents, and members of the Performance Metrics Directorate.
このドキュメントの対象読者は含まれていますが、パフォーマンス・メトリックのIETFの文書は、そのような書類の審査、およびパフォーマンス・メトリック総局のメンバーを書き、IETFの参加者に限定されるものではありません。
Previous IETF work related to the reporting of application Performance Metrics includes "Real-time Application Quality-of-Service Monitoring (RAQMON) Framework" [RFC4710]. This framework extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. Furthermore, "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611] and "Session Initiation Protocol Event Package for Voice Quality Reporting" [RFC6035] define protocols that support real-time Quality of Experience (QoE) reporting for Voice over IP (VoIP) and other applications running on devices such as IP phones and mobile handsets.
アプリケーションのパフォーマンス・メトリックの報告に係る前IETFの仕事は、「リアルタイムアプリケーションサービス品質のモニタリング（RAQMON）フレームワーク」[RFC4710]を含んでいます。このフレームワークは、リモートネットワークモニタリング（RMON）、IP電話、ポケットベル、インスタントメッセージングクライアント、携帯電話などのデバイス上で動作する様々なアプリケーションのリアルタイムのサービス品質（QoS）の監視を可能にする仕様の家族、そして様々なを拡張します他のハンドヘルドコンピューティングデバイス。さらに、[RFC6035]は経験のリアルタイムの品質ボイスオーバーIP用（ユーザ体感品質）の報告を（サポートするプロトコルを定義する「音声品質を報告するためのセッション開始プロトコルイベントパッケージ」[RFC3611]と「RTP制御プロトコルは、レポート（RTCP XR）の拡張しました」 VoIPの）と、IP電話や携帯電話などのデバイス上で実行されている他のアプリケーション。
The IETF is also actively involved in the development of reliable transport protocols, such as TCP [RFC0793] or the Stream Control Transmission Protocol (SCTP) [RFC4960], which would affect the relationship between IP performance and application performance.
IETFはまた、積極的にIPのパフォーマンスとアプリケーションのパフォーマンスとの関係に影響を与える可能性があり、TCPのような信頼性の高いトランスポートプロトコル、[RFC0793]またはストリーム制御伝送プロトコル（SCTP）[RFC4960]の開発に関与しています。
Thus, there is a gap in the currently chartered coverage of IETF Working Groups (WGs): development of Performance Metrics for protocols above and below the IP layer that can be used to characterize performance on live networks.
ライブネットワーク上の性能を特徴付けるために使用することができるIP層の上及び下のプロトコルのパフォーマンス・メトリックの開発：したがって、IETFワーキンググループ（のWG）の現在チャーターカバレッジのギャップがあります。
Similar to "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" [RFC5706], which is the reference document for the IETF Operations Directorate, this document should be consulted as part of the new Performance Metric review by the members of the Performance Metrics Directorate.
同様にIETF操作総局のための参考資料です[RFC5706]「の操作を考慮し、新しいプロトコルやプロトコル拡張の管理のためのガイドライン」、この文書では、パフォーマンスのメンバーによって新しいパフォーマンスメトリックの見直しの一環として、相談されるべきですメトリック総局。
This document is divided into two major sections beyond the "Purpose and Scope" section. The first is a definition and description of a Performance Metric and its key aspects. The second defines a process to develop these metrics that is applicable to the IETF environment.
この文書は、「目的と範囲」セクションを超えて二つの主要なセクションに分かれています。最初は、パフォーマンスメトリックとその主要な側面の定義と説明です。第二は、IETFの環境に適用可能であり、これらの指標を開発するプロセスを定義します。
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]に記載されているように解釈されます。
The Performance Metrics Directorate is a directorate that provides guidance for Performance Metrics development in the IETF.
パフォーマンス・メトリック総局は、IETFでのパフォーマンス・メトリック開発のためのガイダンスを提供総局です。
The Performance Metrics Directorate should be composed of experts in the performance community, potentially selected from the IP Performance Metrics (IPPM), Benchmarking Methodology (BMWG), and Performance Metrics for Other Layers (PMOL) WGs.
パフォーマンス・メトリック総局は、潜在的に他の層（ピコモル）のWGのためにIPパフォーマンス・メトリック（IPPM）、ベンチマーキング方法論（BMWG）、およびパフォーマンス・メトリックから選択、パフォーマンスのコミュニティの専門家で構成されなければなりません。
Quality of Service (QoS) is defined in a way similar to the ITU "Quality of Service (QoS)" section of [E.800], i.e., "Totality of characteristics of a telecommunications service that bear on its ability to satisfy stated and implied needs of the user of the service".
サービスの品質（QoS）は、ITU「サービスの品質（QoS）」は、記載を満足させるその能力に耐える電気通信サービスの特性の[E.800]、すなわち、「全体のセクションと同様に定義されており、サービスの利用者の暗黙のニーズ」。
Quality of Experience (QoE) is defined in a way similar to the ITU "QoS experienced/perceived by customer/user (QoSE)" section of [E.800], i.e., "a statement expressing the level of quality that customers/users believe they have experienced".
体感品質（QoEのは）[E.800]のセクション、すなわち、「品質のレベルを表現する声明ITU「顧客/ユーザー（QoSE）によって知覚経験のQoS /」に似た方法で定義された顧客/ユーザー」彼らが経験してきたと信じています。
NOTE 1 - The level of QoS experienced and/or perceived by the customer/user may be expressed by an opinion rating.
注1 - 顧客/ユーザーが経験および/または認知のQoSのレベルは意見の評価で表すことができます。
NOTE 2 - QoE has two main components: quantitative and qualitative. The quantitative component can be influenced by the complete end-to-end system effects (including user devices and network infrastructure).
注2 - のQoEは2つの主要コンポーネントがあります：定量的および定性的に。定量的な成分は、（ユーザ装置とネットワークインフラストラクチャを含む）完全なエンドツーエンドのシステムの影響によって影響され得ます。
NOTE 3 - The qualitative component can be influenced by user expectations, ambient conditions, psychological factors, application context, etc.
注3 - 質的コンポーネントは、ユーザの期待、周囲条件、心理的要因、アプリケーションコンテキスト、等によって影響され得ます
NOTE 4 - QoE may also be considered as QoS delivered, received, and interpreted by a user with the pertinent qualitative factors influencing his/her perception of the service.
注4 - たQoEはまた、配信のQoSとして受信考えられ、サービスの彼/彼女の知覚に影響を与える適切な定性的要因でユーザによって解釈されてもよいです。
A Performance Metric is a quantitative measure of performance, specific to an IETF-specified protocol or specific to an application transported over an IETF-specified protocol. Examples of Performance Metrics are the FTP response time for a complete file download, the DNS response time to resolve the IP address, a database logging time, etc.
パフォーマンスメトリックは、IETF指定プロトコルまたはIETF、指定されたプロトコルを介して転送アプリケーションに固有の特定の性能の定量的尺度です。パフォーマンス・メトリックの例としては、完全なファイルのダウンロードのためのFTPの応答時間があり、DNSの応答時間は、IPアドレス、データベース・ロギング時間などを解決するには
The purpose of this document is to define a framework and a process for developing Performance Metrics for protocols above and below the IP layer (such as IP-based applications that operate over reliable or datagram transport protocols). These metrics can be used to characterize traffic on live networks and services. As such, this document does not define any Performance Metrics.
この文書の目的は、フレームワークと上記と（例えば、信頼性やデータグラムトランスポートプロトコルで動作するIPベースのアプリケーションなど）IP層の下のプロトコルのパフォーマンス・メトリックを開発するためのプロセスを定義することです。これらのメトリックは、ライブネットワークとサービスのトラフィックを特徴付けるために使用することができます。そのため、このドキュメントはいかなるパフォーマンス・メトリックを定義していません。
The scope of this document covers guidelines for the Performance Metrics Directorate members for considering new Performance Metrics and suggests how the Performance Metrics Directorate will interact with the rest of the IETF. However, this document is not intended to supersede existing working methods within WGs that have existing chartered work in this area.
このドキュメントの範囲には、新しいパフォーマンス・メトリックを考慮するためにパフォーマンス・メトリック総局員のためのガイドラインをカバーし、パフォーマンス・メトリック総局は、IETFの残りの部分と相互作用する方法を提案します。しかし、この文書は、この分野でのチャーター作業を既存しているのWG内の既存の作業方法に取って代わることを意図していません。
This process is not intended to govern Performance Metric development in existing IETF WGs that are focused on metrics development, such as the IPPM and BMWG WGs. However, this guidelines document may be useful in these activities and MAY be applied where appropriate. A typical example is the development of Performance Metrics to be exported with the IP Flow Information eXport (IPFIX) protocol [RFC5101], with specific IPFIX information elements [RFC5102], which would benefit from the framework in this document.
このプロセスは、IPPMやBMWGのWGとしてメトリクスの開発に焦点を当てているIETFのWGを、既存のパフォーマンス・メトリックの開発を支配するものではありません。しかし、このガイドライン文書は、これらの活動に有用であるかもしれないと、適切な場合にも適用することができます。典型的な例は、この文書に記載されているフレームワークから恩恵を受ける特定IPFIX情報エレメント[RFC5102]を用いて、IPフロー情報エクスポート（IPFIX）プロトコル[RFC5101]でエクスポートするパフォーマンス・メトリックの開発です。
The framework in this document applies to Performance Metrics derived from both active and passive measurements.
この文書に記載されているフレームワークは、能動および受動の両方の測定から得パフォーマンス・メトリックに適用されます。
4. Relationship between QoS, QoE, and Application-Specific Performance Metrics
QoSの、ユーザ体感品質、およびアプリケーション固有のパフォーマンス・メトリックの間の関係4。
Network QoS deals with network and network protocol performance, while QoE deals with the assessment of a user's experience in the context of a task or a service. The topic of application-specific Performance Metrics includes the measurement of performance at layers between IP and the user. For example, network QoS metrics (packet loss, delay, and delay variation [RFC5481]) can be used to estimate application-specific Performance Metrics (de-jitter buffer size and RTP-layer packet loss), and then combined with other known aspects of a VoIP application (such as codec type) using an algorithm compliant with ITU-T P.564 [P.564] to estimate a Mean Opinion Score (MOS) [P.800]. However, the QoE for a particular VoIP user depends on the specific context, such as a casual conversation, a business conference call, or an emergency call. Finally, QoS and application-specific Performance Metrics are quantitative, while QoE is qualitative. Also, network QoS and application-specific Performance Metrics can be directly or indirectly evident to the user, while the QoE is directly evident.
ユーザ体感品質は、タスクやサービスのコンテキストにおけるユーザの経験の評価を扱っている間、ネットワークQoSは、ネットワークおよびネットワークプロトコルのパフォーマンスを扱っています。アプリケーション固有のパフォーマンス・メトリックのトピックは、IPとユーザとの間の層での性能の測定を含みます。例えば、ネットワークのQoSメトリック（パケットロス、遅延、および遅延変動[RFC5481]）他の公知の態様で、アプリケーション固有のパフォーマンス・メトリック（デジッタバッファサイズとRTP層パケット損失）を推定するために使用した後に組み合わせることができます準拠したアルゴリズムを使用して（例えばコーデックタイプなど）VoIPアプリケーションのITU-T P.564 [P.564]平均オピニオンスコア（MOS）[P.800]を推定します。しかし、特定のVoIPユーザーのQoEは、カジュアルな会話、ビジネス、会議通話、または緊急呼び出しなど、特定のコンテキストに依存します。ユーザ体感品質が定性的である一方、最後に、QoSおよびアプリケーション固有のパフォーマンス・メトリックは、定量的です。ユーザ体感品質を直接明らかであるが、また、ネットワークのQoSおよびアプリケーション固有のパフォーマンス・メトリックは、ユーザに直接または間接的に明らかであることができます。
This section provides key definitions and qualifications of Performance Metrics.
このセクションでは、パフォーマンス・メトリックのキー定義と資格を提供します。
Many of the aspects of metric definition and reporting, even the selection or determination of the essential metrics, depend on who will use the results, and for what purpose. For example, the metric description SHOULD include use cases and example reports that illustrate service quality monitoring and maintenance or identification and quantification of problems.
結果を使用する人に依存して、基本的なメトリクスのも、選択や決定、メトリックの定義と報告の側面の多くは、どのような目的のために。例えば、メトリックの説明はユースケースや問題のサービス品質の監視およびメンテナンスまたは同定および定量を示すサンプル・レポートを含むべきです。
All documents defining Performance Metrics SHOULD identify the primary audience and its associated requirements. The audience can influence both the definition of metrics and the methods of measurement.
パフォーマンス・メトリックを定義するすべての文書が主な対象とそれに関連する要件を特定する必要があります。観客は、メトリックの定義と測定方法の両方に影響を与えることができます。
The key areas of variation between different metric users include:
異なるメトリックユーザー間の変動の主要分野は次のとおりです。
o Suitability of passive measurements of live traffic or active measurements using dedicated traffic
専用のトラフィックを使用して、ライブトラフィックまたはアクティブな測定のパッシブ測定の入出力適合
o Measurement in laboratory environment or on a network of deployed devices
実験室の環境や展開のデバイスのネットワーク上のO測定
o Accuracy of the results
結果のO精度
o Access to measurement points and configuration information
測定ポイントへのアクセスおよび設定情報O
o Measurement topology (point-to-point, point-to-multipoint)
O計測のトポロジ（ポイントツーポイント、ポイントツーマルチポイント）
o Scale of the measurement system
測定システムのOスケール
o Measurements conducted on-demand or continuously
O測定は、オンデマンドまたは連続的に行います
o Required reporting formats and periods
O必須フォーマットとする報告期間
o Sampling criteria [RFC5474], such as systematic or probabilistic
このような体系的または確率としてOサンプリング基準[RFC5474]、
o Period (and duration) of measurement, as the live traffic can have patterns
Oライブトラフィックなどの測定の期間（デュレーションと）、パターンを持つことができます
A Performance Metric is a measure of an observable behavior of a networking technology, an application, or a service. Most of the time, the Performance Metric can be directly measured; however, sometimes, the Performance Metric value is computed. The process for determining the value of a metric may assume an implicit or explicit underlying statistical process; in this case, the Performance Metric is an estimate of a parameter of this process, assuming that the statistical process closely models the behavior of the system.
パフォーマンスメトリックは、ネットワーク技術、アプリケーション、またはサービスの観察可能な行動の尺度です。ほとんどの時間、パフォーマンスメトリックを直接測定することができます。しかし、時々、パフォーマンスメトリック値が計算されます。メトリックの値を決定するためのプロセスは、暗黙的または明示的な基礎となる統計的プロセスをとることができます。この場合には、パフォーマンスメトリックは、統計的プロセスが密接にモデルシステムの挙動を仮定すると、このプロセスのパラメータの推定値です。
A Performance Metric should serve some defined purposes. This may include the measurement of capacity, quantifying how bad some problems are, measurement of service level, problem diagnosis or location, and other such uses. A Performance Metric may also be an input to some other processes, for example, the computation of a composite Performance Metric or a model or simulation of a system. Tests of the "usefulness" of a Performance Metric include:
パフォーマンスメトリックは、いくつかの定義された目的を果たす必要があります。これはいくつかの問題は、サービス・レベル、問題の診断または場所、および他のこのような用途の測定であるか悪い定量、容量の測定を含むことができます。パフォーマンスメトリックはまた、例えば、複合パフォーマンスメトリックまたはシステムのモデルまたはシミュレーションの計算いくつかの他のプロセスに入力することができます。パフォーマンスメトリックの「有用性」のテストが含まれます：
(i) the degree to which its absence would cause significant loss of information on the behavior or performance of the application or system being measured
（ⅰ）その不在が測定されているアプリケーションやシステムの動作やパフォーマンス上の情報の重大な損失を引き起こす度合い
(ii) the correlation between the Performance Metric, the QoS, and the QoE delivered to the user (person or other application)
（ⅱ）パフォーマンスメトリック、QoS、およびQoEの間の相関は、ユーザー（個人または他のアプリケーション）に配信しました
(iii) the degree to which the Performance Metric is able to support the identification and location of problems affecting service quality
（iii）のパフォーマンス・メトリックがサービス品質に影響を与える問題の識別及び位置を支持することができる程度を
(iv) the requirement to develop policies (Service Level Agreement, and potentially Service Level Contract) based on the Performance Metric
（IV）の要件は、パフォーマンス・メトリックに基づいてポリシー（サービスレベル契約、および潜在的にサービスレベル契約）を開発します
For example, consider a distributed application operating over a network connection that is subject to packet loss. A Packet Loss Rate (PLR) Performance Metric is defined as the mean packet loss ratio over some time period. If the application performs poorly over network connections with a high packet loss ratio and always performs well when the packet loss ratio is zero, then the PLR Performance Metric is useful to some degree. Some applications are sensitive to short periods of high loss (bursty loss) and are relatively insensitive to isolated packet loss events; for this type of application, there would be very weak correlation between PLR and application performance. A "better" Performance Metric would consider both the packet loss ratio and the distribution of loss events. If application performance is degraded when the PLR exceeds some rate, then a useful Performance Metric may be a measure of the duration and frequency of periods during which the PLR exceeds that rate (as, for example, in RFC 3611).
例えば、パケット損失を受けるネットワーク接続上で動作する分散アプリケーションを考えます。パケット損失率（PLR）のパフォーマンスメトリックは、ある程度の時間をかけて平均パケット損失率と定義されます。アプリケーションが高いパケット損失率とのネットワーク接続を介して悪い行いやパケット損失率がゼロの場合、常に良好に動作する場合は、PLRパフォーマンスメトリックは、ある程度有効です。いくつかの用途は、高損失（バースト損失）の短い期間に敏感であり、単離されたパケット損失イベントに対して比較的鈍感です。このタイプのアプリケーションのために、PLRとアプリケーションのパフォーマンスの間に非常に弱い相関関係が存在することになります。 「より良い」パフォーマンスメトリックは、パケット損失率および損失事象の分布の両方を検討します。 PLRは、いくつかのレートを超えた場合に、アプリケーションのパフォーマンスが低下している場合には、有用なパフォーマンスメトリックは、PLRレート（例えば、としてRFC 3611で）ことを超えている期間の持続時間および周波数の測定値であってもよいです。
Some Performance Metrics may not be measured directly, but can be composed from base metrics that have been measured. A composed Performance Metric is derived from other metrics by applying a deterministic process or function (e.g., a composition function). The process may use metrics that are identical to the metric being composed, or metrics that are dissimilar, or some combination of both types. Usually, the base metrics have a limited scope in time or space, and they can be combined to estimate the performance of some larger entities.
いくつかのパフォーマンス・メトリックを直接測定することはないかもしれませんが、測定されたベースメトリクスから構成することができます。構成パフォーマンスメトリックは、決定論的プロセスまたは機能（例えば、組成物の機能）を適用することによって、他のメトリックに由来します。プロセスが構成されているメトリックと同一である指標、又は異種であるメトリクス、又は両方のタイプのいくつかの組み合わせを使用することができます。通常、ベースメトリックは、時間や空間に限定された範囲を持っている、と彼らはいくつかの大規模事業体の性能を評価するために組み合わせることができます。
Some examples of composed Performance Metrics and composed Performance Metric definitions are as follows:
次のように構成パフォーマンス・メトリックと合成パフォーマンスメトリックの定義のいくつかの例は以下のとおりです。
Spatial composition is defined as the composition of metrics of the same type with differing spatial domains [RFC5835] [RFC6049]. Ideally, for spatially composed metrics to be meaningful, the spatial domains should be non-overlapping and contiguous, and the composition operation should be mathematically appropriate for the type of metric.
空間的な組成物は、異なる空間領域[RFC5835]、[RFC6049]と同じタイプのメトリックの組成物として定義されます。空間的構成メトリックが有意義であるために、理想的には、空間的なドメインは、非重複および連続であるべきであり、組成物の操作は、メトリックのタイプの数学的に適切であるべきです。
Temporal composition is defined as the composition of sets of metrics of the same type with differing time spans [RFC5835]. For temporally composed metrics to be meaningful, the time spans should be non-overlapping and contiguous, and the composition operation should be mathematically appropriate for the type of metric.
時間的組成物は、異なるタイムスパン[RFC5835]と同じタイプのメトリックの組の組成物として定義されます。時間的構成メトリックが有意義であるために、時間スパンは、非重複および連続であるべきであり、組成物の操作は、メトリックのタイプの数学的に適切であるべきです。
Temporal aggregation is a summarization of metrics into a smaller number of metrics that relate to the total time span covered by the original metrics. An example would be to compute the minimum, maximum, and average values of a series of time-sampled values of a metric.
時間的な凝集は、元のメトリクスによってカバーされる合計時間スパンに関連指標の数が少ないにメトリックの要約です。例えば、最小、最大、およびメトリックの時間サンプル値の系列の平均値を計算することであろう。
In the context of flow records in IP Flow Information eXport (IPFIX), the IPFIX Mediation Framework [RFC6183], based on "IP Flow Information Export (IPFIX) Mediation: Problem Statement" [RFC5982], also discusses some aspects of the temporal and spatial composition.
IPフロー情報のエクスポート（IPFIX）でのフローレコードの文脈では、「IPフロー情報のエクスポート（IPFIX）調停：問題文」に基づき、IPFIXの仲介フレームワーク[RFC6183]、[RFC5982]は、また、時間のいくつかの側面を説明し、空間構成。
An index is a metric for which the output value range has been selected for convenience or clarity, and the behavior of which is selected to support ease of understanding, for example, the R Factor [G.107]. The deterministic function for an index is often developed after the index range and behavior have been determined.
インデックスは、出力値の範囲は便宜及び明確性のために選択されたメトリックであり、理解の容易性をサポートするために、選択された動作、例えば、R因子[G.107]。インデックス範囲と動作が決定された後、インデックスのための決定的関数は、多くの場合、開発されています。
A Performance Metric definition MUST have a normative part that defines what the metric is and how it is measured or computed, and it SHOULD have an informative part that describes the Performance Metric and its application.
パフォーマンスメトリックの定義は、メトリックが何であるかを定義し、それがどのように測定または計算された標準的な部分があり、それがパフォーマンスメトリックとその応用を説明する有益な部分を持っているべきです。
The normative part of a Performance Metric definition MUST define at least the following:
パフォーマンスメトリックの定義の標準的な部分では、少なくとも以下を定義する必要があります。
(i) Metric Name
（I）メトリック名
Performance Metric names are RECOMMENDED to be unique within the set of metrics being defined for the protocol layer and context. While strict uniqueness may not be attainable (see the IPPM registry [RFC6248] for an example of an IANA metric registry failing to provide sufficient specificity), broad review must be sought to avoid naming overlap. Note that the Performance Metrics Directorate can help with suggestions for IANA metric registration for unique naming. The Performance Metric name MAY be descriptive.
パフォーマンスメトリック名は、プロトコル層とコンテキストのために定義されたメトリックのセット内で一意であることが推奨されています。厳密な一意性が（十分な特異性を提供することができないIANAレジストリメトリックの例えばIPPMレジストリ[RFC6248]を参照）を達成できないかもしれないが、幅広いレビューは重複を避ける命名しようとしなければなりません。パフォーマンス・メトリック総局は、ユニークな命名のためのIANAメトリック登録のための提案を助けることができることに注意してください。パフォーマンスメトリック名が記述しているかもしれません。
(ii) Metric Description
（ii）のメトリックの説明
The Performance Metric description MUST explain what the metric is, what is being measured, and how this relates to the performance of the system being measured.
パフォーマンスメトリックの説明メトリックが測定されているものであり、これはシステムのパフォーマンスにどのように関連するかを測定しているかを説明しなければなりません。
(iii) Method of Measurement or Calculation
（iii）の測定方法又は計算を
The method of measurement or calculation MUST define what is being measured or computed and the specific algorithm to be used. Does the measurement involve active or only passive measurements? Terms such as "average" should be qualified (e.g., running average or average over some interval). Exception cases SHOULD also be defined with the appropriate handling method. For example, there are a number of commonly used metrics related to packet loss; these often don't define the criteria by which a packet is determined to be lost (versus very delayed) or how duplicate packets are handled. For example, if the average PLR during a time interval is reported, and a packet's arrival is delayed from one interval to the next, then was it "lost" during the interval during which it should have arrived or should it be counted as received?
測定または計算の方法は、測定又は計算され、特定のアルゴリズムが使用されているかを定義しなければなりません。測定は、アクティブまたはパッシブのみの測定を必要とするのか？そのような「平均」などの用語は、（例えば、いくつかの間隔の平均または平均実行）修飾されなければなりません。例外の場合も、適切な取り扱い方法を定義する必要があります。例えば、パケット損失に関連する一般的に使用される指標の数があります。これらは多くの場合、パケットが（非常に遅れに対して）失われたり重複パケットがどのように処理されて決定される基準を定義していません。例えば、時間間隔中の平均PLRが報告されている場合、パケットの到着は、それが到着している必要がありますまたは受信としてそれをカウントする必要があり、その間の間隔の間に、それは「失われた」と次の間隔から遅れていますか？
Some methods of calculation might require discarding some data collected (due to outliers) so as to make the measurement parameters meaningful. One example is burstable billing that sorts the 5-min samples and discards the top 5 percentile.
計算のいくつかの方法は、測定パラメータを有意義なものになるように（による外れ値に）収集したいくつかのデータを破棄しなければならない場合があります。一例では、5分間のサンプルをソートし、上位5パーセンタイルを廃棄する破断可能な請求です。
Some parameters linked to the method MAY also be reported, in order to fully interpret the Performance Metric, for example, the time interval, the load, the minimum packet loss, the potential measurement errors and their sources, the attainable accuracy of the metric (e.g., +/- 0.1), the method of calculation, etc.
方法にリンクされているいくつかのパラメータは、完全にパフォーマンスメトリック、例えば、時間間隔、負荷、最小パケット損失、電位測定誤差とそのソース、メトリックの達成可能な精度を（解釈するために、報告することができます例えば+/- 0.1）、計算方法、等
(iv) Units of Measurement
（IV）測定単位
The units of measurement MUST be clearly stated.
測定の単位が明確に記載しなければなりません。
(v) Measurement Point(s) with Potential Measurement Domain
（v）の電位測定ドメインと測定ポイント（複数可）
If the measurement is specific to a measurement point, this SHOULD be defined. The measurement domain MAY also be defined. Specifically, if measurement points are spread across domains, the measurement domain (intra-, inter-) is another factor to consider.
測定は、測定点に特異的である場合、これは定義されるべきです。測定ドメインも定義されるかもしれません。測定ポイントがドメインにまたがっている場合は具体的には、（イントラ、インター）測定領域は、考慮すべきもう一つの要因です。
The Performance Metric definition should discuss how the Performance Metric value might vary, depending on which measurement point is chosen. For example, the time between a SIP request [RFC3261] and the final response can be significantly different at the User Agent Client (UAC) or User Agent Server (UAS).
パフォーマンスメトリックの定義が選択された測定ポイントに応じて、パフォーマンスメトリック値が異なる場合がありますどのように議論する必要があります。例えば、SIPリクエスト[RFC3261]と最終的な応答の間の時間は、ユーザエージェントクライアント（UAC）またはユーザエージェントサーバ（UAS）で有意に異なっていてもよいです。
In some cases, the measurement requires multiple measurement points: all measurement points SHOULD be defined, including the measurement domain(s).
いくつかのケースでは、測定は、複数の測定点を必要とする：すべての測定点は、測定領域（単数または複数）を含む、定義されるべきです。
(vi) Measurement Timing
（VI）測定タイミング
The acceptable range of timing intervals or sampling intervals for a measurement, and the timing accuracy required for such intervals, MUST be specified. Short sampling intervals or frequent samples provide a rich source of information that can help assess application performance but may lead to excessive measurement data. Long measurement or sampling intervals reduce the amount of reported and collected data such that it may be insufficient to understand application performance or service quality, insofar as the measured quantity may vary significantly with time.
測定のための間隔またはサンプリング間隔のタイミングの許容範囲、及びそのような間隔のために必要なタイミング精度は、指定しなければなりません。短いサンプリング間隔または頻繁サンプルは、アプリケーションのパフォーマンスを評価することができますが、過度の測定データにつながる可能性の豊富な情報源を提供します。長い測定又はサンプリング間隔は、測定された量は時間とともに著しく変化することができる限り、アプリケーション性能やサービス品質を理解するために不十分であるように報告され、収集されたデータの量を減らします。
In the case of multiple measurement points, the potential requirement for synchronized clocks must be clearly specified. In the specific example of the IP delay variation application metric, the different aspects of synchronized clocks are discussed in [RFC5481].
複数の測定点の場合には、同期クロックのための潜在的な要件は、明確に指定しなければなりません。 IP遅延変動アプリケーションメトリックの具体例では、同期クロックの異なる態様は、[RFC5481]に記載されています。
The informative part of a Performance Metric specification is intended to support the implementation and use of the metric. This part SHOULD provide the following data:
パフォーマンスメトリック仕様の有益な部分は、メトリックの実装と使用をサポートすることを意図しています。この部分は、以下のデータを提供する必要があります。
(i) Implementation
（I）実施
The implementation description MAY be in the form of text, an algorithm, or example software. The objective of this part of the metric definition is to help implementers achieve consistent results.
インプリメンテーション記述は、テキスト、アルゴリズム、又は例えばソフトウェアの形であってもよいです。メトリック定義のこの部分の目的は、実装者は、一貫性のある結果を達成するのを助けるためにあります。
(ii) Verification
（ⅱ）検証
The Performance Metric definition SHOULD provide guidance on verification testing. This may be in the form of test vectors, a formal verification test method, or informal advice.
パフォーマンスメトリックの定義は、実証試験に関するガイダンスを提供する必要があります。これは、テストベクトル、フォーマル検証試験方法、または非公式のアドバイスの形であってもよいです。
(iii) Use and Applications
（ⅲ）利用とアプリケーション
The use and applications description is intended to help the "user" understand how, when, and where the metric can be applied, and what significance the value range for the metric may have. This MAY include a definition of the "typical" and "abnormal" range of the Performance Metric, if this was not apparent from the nature of the metric. The description MAY include information about the influence of extreme measurement values, i.e., if the Performance Metric is sensitive to outliers. The Use and Application section SHOULD also include the security implications in the description.
使用してアプリケーションの説明は、「ユーザー」どのように、いつ、どこでメトリックを適用することができ、およびメトリックの値の範囲はどのような意義を有していてもよく理解を支援するためのものです。このメトリックの性質から明らかでなかった場合、これは、パフォーマンスメトリックの「典型的」と「異常な」範囲の定義を含むかもしれません。パフォーマンスメトリックは、外れ値に対して敏感である場合の説明は、すなわち、極端な測定値の影響についての情報を含むことができます。使用してアプリケーションのセクションでは、説明にセキュリティの意味をも含むべきです。
For example:
例えば：
(a) it is fairly intuitive that a lower packet loss ratio would equate to better performance. However, the user may not know the significance of some given packet loss ratio.
（a）は、より低いパケット損失率は、より良いパフォーマンスに等しいであろうと、かなり直感的です。しかし、ユーザーは、いくつかの特定のパケット損失率の重要性を知らないかもしれません。
(b) the speech level of a telephone signal is commonly expressed in dBm0. If the user is presented with:
（b）は、電話信号の音声レベルは、一般dBm0でで発現されます。ユーザーがで提示されている場合：
Speech level = -7 dBm0
スピーチレベル= -7 dBm0で
this is not intuitively understandable, unless the user is a telephony expert. If the metric definition explains that the typical range is -18 to -28 dBm0, a value higher than -18 means the signal may be too high (loud), and less than -28 means that the signal may be too low (quiet), it is much easier to interpret the metric.
ユーザーは、電話の専門家でない限り、これは、直感的に理解できないです。メトリック定義は、典型的な範囲は-18 -28にdBm0で、であると説明した場合（静か）-18より高い値は、信号が（大音量）が高すぎる可能性があることを意味し、そして-28未満では、信号が低すぎる可能性があることを意味しますメトリックを解釈する方がはるかに簡単です。
(iv) Reporting Model
（ⅳ）レポートモデル
The reporting model definition is intended to make any relationship between the metric and the reporting model clear. There are often implied relationships between the method of reporting metrics and the metric itself; however, these are often not made apparent to the implementor. For example, if the metric is a short-term running average packet delay variation (e.g., the inter-arrival jitter in [RFC3550]) and this value is reported at intervals of 6-10 seconds, the resulting measurement may have limited accuracy when packet delay variation is non-stationary.
報告モデルの定義は、メトリックおよびレポートモデルの明確な間の一切の関係を作ることを意図しています。多くの場合、報告メトリックとメトリック自体の方法との間に関係があります暗示されています。しかし、これらは多くの場合、実装者には明らかにされていません。例えば、メトリックは、短期移動平均パケット遅延変動（[RFC3550]で、例えば、到着間ジッタ）である場合、この値は6~10秒の間隔で報告され、得られた測定値は、場合精度が限られていることができますパケット遅延変動は非定常です。
Normative
規範
o Metric Name
Oメトリック名
o Metric Description
Oメトリック説明
o Method of Measurement or Calculation
Oの測定方法又は計算
o Units of Measurement
測定のOユニット
o Measurement Point(s) with Potential Measurement Domain
電位測定ドメインと測定ポイント（S）O
o Measurement Timing
O測定タイミング
Informative
参考
o Implementation
Oの実装
o Verification
O検証
o Use and Applications
使用してアプリケーションO
o Reporting Model
Oレポートモデル
The example used is the loss rate metric as specified in RFC 3611 [RFC3611].
RFC 3611 [RFC3611]で指定されるように使用される例では、損失率メトリックです。
Metric Name: LossRate
メトリック名：LossRate
Metric Description: The fraction of RTP data packets from the source lost since the beginning of reception.
メトリック説明：受信の初め以来、失われたソースからのRTPデータパケットの割合。
Method of Measurement or Calculation: This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection, such as Forward Error Correction (FEC)) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part.
測定または計算の方法：この値は、パケットの総数（例えば、前方誤り訂正（FEC）のように、任意のエラー保護を適用することの効果の後に）失わ割ることによって計算される予想されたパケットの合計数によって、結果を乗算256による除算、（オーバーフローを回避するために）255の最大値を制限し、整数部をとります。
Units of Measurement: This metric is expressed as a fixed-point number with the binary point at the left edge of the field. For example, a metric value of 12 means a loss rate of approximately 5%.
測定単位：このメトリックは、フィールドの左端にバイナリ点を有する固定小数点数として表現されます。例えば、12のメトリック値は、約5％の損失率を意味します。
Measurement Point(s) with Potential Measurement Domain: This metric is made at the receiving end of the RTP stream sent during a Voice over IP call.
電位測定ドメインと測定点（S）：このメトリックは、ボイスオーバーIP通話中に送信されたRTPストリームの受信側で行われます。
Measurement Timing: This metric can be used over a wide range of time intervals. Using time intervals of longer than one hour may prevent the detection of variations in the value of this metric due to time-of-day changes in network load. Timing intervals should not vary in duration by more than +/- 2%.
測定タイミング：このメトリックは、時間間隔の広い範囲で使用することができます。 1時間以上の時間間隔を使用することにより、ネットワーク負荷の時刻変化にこのメトリックの値の変化の検出を防止することができます。タイミング間隔以上+/- 2％持続時間において変化しないはずです。
Implementation: The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard.
実装：重複パケットと廃棄されたパケットの数は、この計算に入らないでください。受信機が無制限のバッファを維持するために必要とすることはできませんので失われたとして、受信機は、後期到着するパケットを分類するかもしれません。損失をトリガ遅れの程度が破棄をトリガするものよりも有意に大きくなければなりません。
Verification: The metric value ranges between 0 and 255.
検証：メトリック値が0〜255の範囲です。
Use and Applications: This metric is useful for monitoring VoIP calls, more precisely, to detect the VoIP loss rate in the network. This loss rate, along with the rate of packets discarded due to jitter, has some effect on the quality of the voice stream.
使用してアプリケーション：このメトリックは、ネットワーク内のVoIP損失率を検出するために、より正確には、VoIPコールを監視するために有用です。この損失率は、ジッタが原因で廃棄されたパケットのレートとともに、音声ストリームの品質に何らかの影響を持っています。
Reporting Model: This metric needs to be associated with a defined time interval, which could be defined by fixed intervals or by a sliding window. In the context of RFC 3611, the metric is measured continuously from the start of the RTP stream, and the value of the metric is sampled and reported in RTCP XR VoIP Metrics reports.
モデルレポート：このメトリックは、一定の間隔によって、またはスライディングウィンドウによって定義することができる定義された時間間隔に関連付けられる必要があります。 RFC 3611の文脈では、メトリックは、RTPストリームの開始から連続的に測定され、メトリックの値をサンプリングし、RTCP XR VoIPのメトリクスに報告する報告されています。
This section introduces several Performance Metrics dependencies, which the Performance Metric designer should keep in mind during Performance Metric development. These dependencies, and any others not listed here, SHOULD be documented in the Performance Metric specifications.
このセクションでは、パフォーマンスメトリックの設計者は、パフォーマンスメトリックの開発時に心に留めておくべきいくつかのパフォーマンス・メトリックの依存関係を、紹介します。これらの依存関係、およびここに記載されていない他のものは、パフォーマンスメトリック仕様に文書化されなければなりません。
The accuracy of the timing of a measurement may affect the accuracy of the Performance Metric. This may not materially affect a sampled-value metric; however, it would affect an interval-based metric. Some metrics -- for example, the number of events per time interval -- would be directly affected; for example, a 10% variation in time interval would lead directly to a 10% variation in the measured value. Other metrics, such as the average packet loss ratio during some time interval, would be affected to a lesser extent.
測定のタイミングの精度は、パフォーマンスメトリックの精度に影響を与える可能性があります。これは、実質サンプリングされた値のメトリックに影響を与えないかもしれません。しかし、それは間隔ベースのメトリックに影響を与えるでしょう。いくつかの測定基準 - 例えば、時間間隔あたりのイベント数 - 直接影響を受けるであろう。例えば、時間間隔中の10％の変動は、測定値の10％の変化に直接つながります。そのようないくつかの時間間隔の間の平均パケット損失率のような他のメトリックが、より少ない程度に影響を受けることになります。
If it is necessary to correlate sampled values or intervals, then it is essential that the accuracy of sampling time and interval start/ stop times is sufficient for the application (for example, +/- 2%).
サンプル値または間隔を相関させる必要がある場合、サンプリング時間と間隔の開始/終了時刻の精度（例えば、±2％）アプリケーションのために十分であることが必須です。
5.5.2. Dependencies of Performance Metric Definitions on Related Events or Metrics
5.5.2. 関連イベントまたはメトリックのパフォーマンスメトリックの定義の依存関係
Performance Metric definitions may explicitly or implicitly rely on factors that may not be obvious. For example, the recognition of a packet as being "lost" relies on having some method of knowing the packet was actually lost (e.g., RTP sequence number), and some time threshold after which a non-received packet is declared lost. It is important that any such dependencies are recognized and incorporated into the metric definition.
パフォーマンスメトリックの定義は、明示的または暗黙的に明らかではないかもしれない要因に依拠することができます。例えば、「失われた」ものとしてパケットの認識が実際に失われたパケットを知る何らかの方法を有するに依存している（例えば、RTPシーケンス番号）、および非受信パケットが失われた宣言された後のある時間しきい値。そのような依存性が認識され、メトリックの定義に組み込まれていることが重要です。
5.5.3. Relationship between Performance Metric and Lower-Layer Performance Metrics
5.5.3. パフォーマンスメトリックと下層のパフォーマンス・メトリックの関係
Lower-layer Performance Metrics may be used to compute or infer the performance of higher-layer applications, potentially using an application performance model. The accuracy of this will depend on many factors, including:
下層パフォーマンス・メトリックは、潜在的にアプリケーションのパフォーマンス・モデルを使用して、上位層のアプリケーションの性能を計算又は推測するために使用することができます。これの精度はを含む多くの要因に依存します：
(i) The completeness of the set of metrics (i.e., are there metrics for all the input values to the application performance model?)
（I）のメトリックのセットの完全性（すなわち、全ての入力値のメトリックは、アプリケーション・パフォーマンス・モデルがありますか？）
(ii) Correlation between input variables (being measured) and application performance
（ii）の入力変数間の相関（測定される）と、アプリケーションのパフォーマンスを
(iii) Variability in the measured metrics and how this variability affects application performance
（iii）の測定指標で変動し、この変動は、アプリケーションのパフォーマンスにどのように影響しますか
Presence of a middlebox [RFC3303], e.g., proxy, network address translation (NAT), redirect server, session border controller (SBC) [RFC5853], and application layer gateway (ALG), may add variability to or restrict the scope of measurements of a metric. For example, an SBC that does not process RTP loopback packets may block or locally terminate this traffic rather than pass it through to its target.
ミドル[RFC3303]、例えば、プロキシ、ネットワークアドレス変換（NAT）の存在は、サーバ、セッションボーダーコントローラ（SBC）[RFC5853]、およびアプリケーション層ゲートウェイ（ALG）をリダイレクトする変動性を追加したり、測定値の範囲を制限することができますメトリックの。例えば、RTPループバックパケットを処理しないSBCは、ブロックまたはローカル終端このトラフィックではなくその標的にそれを通過することができます。
The IPPM Framework [RFC2330] organizes the results of metrics into three related notions:
IPPMフレームワーク[RFC2330]は3つの関連概念にメトリックの結果を整理します。
o singleton: an elementary instance, or "atomic" value.
Oシングルトン：基本インスタンス、または「アトミック」値。
o sample: a set of singletons with some common properties and some varying properties.
Oサンプル：いくつかの共通の特性といくつかの様々な特性を持つシングルトンのセット。
o statistic: a value derived from a sample through deterministic calculation, such as the mean.
O統計：そのような平均値として、決定論的計算により試料から得られた値。
Performance Metrics MAY use this organization for the results, with or without the term names used by the IPPM WG. Section 11 of RFC 2330 [RFC2330] should be consulted for further details.
パフォーマンス・メトリックは、またはIPPM WGで使用される用語名なしで、結果のためにこの組織を使用するかもしれません。 RFC 2330のセクション11 [RFC2330]は、さらに詳細のために相談する必要があります。
Metrics are completely defined when all options and input variables have been identified and considered. These variables are sometimes left unspecified in a metric definition, and their general name indicates that the user must set and report them with the results. Such variables are called "parameters" in the IPPM metric template. The scope of the metric, the time at which it was conducted, the length interval of the sliding-window measurement, the settings for timers, and the thresholds for counters are all examples of parameters.
すべてのオプションと入力変数が特定され、検討されているとき、メトリックは完全に定義されています。これらの変数は、時々、メトリックの定義に指定されていないままにされ、それらの一般的な名前は、ユーザーが設定した結果でそれらを報告しなければならないことを示しています。このような変数は、IPPMメトリックテンプレート中の「パラメータ」と呼ばれています。メトリックの範囲、それが行われた時刻、スライディングウィンドウの測定の長間隔、タイマーの設定、およびカウンタの閾値は、パラメータのすべての例です。
All documents defining Performance Metrics SHOULD identify all key parameters for each Performance Metric.
パフォーマンス・メトリックを定義するすべての文書は、それぞれのパフォーマンスメトリックのためのすべての重要なパラメータを特定する必要があります。
This process is intended to add more considerations to the processes for adopting new work as described in RFC 2026 [RFC2026] and RFC 2418 [RFC2418]. Note that new Performance Metrics work item proposals SHALL be approved using the existing IETF process. The following entry criteria will be considered for each proposal.
このプロセスは、RFC 2026 [RFC2026]およびRFC 2418 [RFC2418]で説明したように新しい仕事を採用するためのプロセスに多くの考慮事項を追加することを意図しています。新しいパフォーマンス・メトリックの作業項目の提案は、既存のIETFプロセスを使用して承認を得なければならないことに注意してください。次のエントリ基準は各提案のために考慮されます。
Proposals SHOULD be prepared as Internet-Drafts, describing the Performance Metric and conforming to the qualifications above as much as possible. Proposals SHOULD be deliverables of the corresponding protocol development WG charters. As such, the proposals SHOULD be vetted by that WG prior to discussion by the Performance Metrics Directorate. This aspect of the process includes an assessment of the need for the Performance Metric proposed and assessment of the support for its development in the IETF.
提案は、パフォーマンスメトリックを説明し、可能な限り上記の資格に準拠し、インターネットドラフトとして準備する必要があります。提案は、対応するプロトコル開発WGチャーターの成果であるべきです。そのため、提案はパフォーマンス・メトリック総局による事前協議へのWGによって吟味されるべきである（SHOULD）。プロセスのこの局面は、IETFでの開発のための支援のメトリックが提案されているパフォーマンスと評価の必要性の評価を含んでいます。
Proposals SHOULD include an assessment of interaction and/or overlap with work in other Standards Development Organizations (SDOs). Proposals SHOULD identify additional expertise that might be consulted.
提案は、相互作用の評価を含む、および/または他の標準開発機関（SDOの）での作業と重複すべきです。提案は相談されるかもしれない追加的な専門知識を特定する必要があります。
Proposals SHOULD specify the intended audience and users of the Performance Metrics. The development process encourages participation by members of the intended audience.
提案は、パフォーマンス・メトリックの対象読者やユーザーを指定する必要があります。開発プロセスは、意図した聴衆のメンバーの参加を奨励しています。
Proposals SHOULD identify any security and IANA requirements. Security issues could potentially involve revealing data identifying a user, or the potential misuse of active test tools. IANA considerations may involve the need for a Performance Metrics registry.
提案はすべてのセキュリティとIANA要件を特定する必要があります。セキュリティの問題は、潜在的ユーザー、またはアクティブなテストツールの誤用の可能性を特定する発現情報を必要とすることができます。 IANAの考慮事項は、パフォーマンス・メトリックのレジストリの必要性を伴うことがあります。
Each Performance Metric SHOULD be assessed according to the following list of qualifications:
各パフォーマンスメトリックは、資格の以下のリストに基づいて評価されるべきです：
o Are the performance metrics unambiguously defined?
Oパフォーマンスメトリックは、明確に定義されていますか？
o Are the units of measure specified?
O指定した測定単位はありますか？
o Does the metric clearly define the measurement interval where applicable?
Oメトリックは明らかに測定間隔適用を定義していますか？
o Are significant sources of measurement errors identified and discussed?
O測定誤差の大きな発生源が特定され、議論されていますか？
o Does the method of measurement ensure that results are repeatable?
O測定の方法は、結果が再現可能であることを確認していますか？
o Does the metric or method of measurement appear to be implementable (or offer evidence of a working implementation)?
oはメトリックまたは測定の方法は、実装可能（または作業実施の証拠を提供する）ように見えるのか？
o Are there any undocumented assumptions concerning the underlying process that would affect an implementation or interpretation of the metric?
Oメトリックの実装や解釈に影響を与える基本的なプロセスに関わるすべての文書化されていない仮定がありますか？
o Can the metric results be related to application performance or user experience, when such a relationship is of value?
Oメトリックの結果は、このような関係は価値があるときに、アプリケーションのパフォーマンスやユーザーエクスペリエンスに関連することはできますか？
o Is there an existing relationship to metrics defined elsewhere within the IETF or within other SDOs?
O IETF内またはその他のSDO内の他の場所に定義されたメトリックの既存の関係がありますか？
o Do the security considerations adequately address denial-of-service attacks, unwanted interference with the metric/ measurement, and user data confidentiality (when measuring live traffic)?
（ライブトラフィックを測定するとき）Oセキュリティの考慮事項が適切にサービス拒否攻撃、メトリック/測定と不要な干渉、およびユーザデータの機密性に対処しますか？
The Performance Metrics Directorate SHALL provide guidance to the related protocol development WG when considering an Internet-Draft that specifies Performance Metrics for a protocol. A sufficient number of individuals with expertise must be willing to consult on the draft. If the related WG has concluded, comments on the proposal should still be sought from key RFC authors and former chairs.
プロトコルのためのパフォーマンス・メトリックを指定するインターネットドラフトを検討する際にパフォーマンス・メトリック総局は、関連するプロトコルの開発WGへのガイダンスを提供しなければなりません。専門知識を持つ個人の十分な数の草案について協議して喜んでなければなりません。関連WGが終了した場合は、提案に関するコメントはまだキーRFCの作者と旧椅子から求めるべきです。
As with expert reviews performed by other directorates, a formal review is recommended by the time the document is reviewed by the Area Directors or an IETF Last Call is being conducted.
他総局によって行われる専門家のレビューと同じように、正式なレビューは、文書がエリアディレクターで審査されるか、IETFラストコールが行われている時間によって推奨されています。
Existing mailing lists SHOULD be used; however, a dedicated mailing list MAY be initiated if necessary to facilitate work on a draft.
既存のメーリングリストを使用すべきです。草案の作業を容易にするために、必要な場合は、専用のメーリングリストを開始することができます。
In some cases, it will be appropriate to have the IETF session discussion during the related protocol WG session, to maximize visibility of the effort to that WG and expand the review.
いくつかのケースでは、そのWGへの取り組みの可視性を最大化し、見直しを拡大するために、関連するプロトコルWGセッション中IETFセッションの議論を持つことが適切であろう。
The Performance Metrics Directorate will assist with the progression of RFCs along the Standards Track. See [IPPM-STANDARD-ADV-TESTING]. This may include the preparation of test plans to examine different implementations of the metrics to ensure that the metric definitions are clear and unambiguous (depending on the final form of the draft mentioned above).
パフォーマンス・メトリック総局は標準化過程に沿ってRFCの進行を支援します。 [IPPM-STANDARD-ADV-TESTING]を参照してください。これは、メトリックの定義は（上記案の最終的な形態に応じて）明確かつ明白であることを保証するために、メトリクスの異なる実装を検討するテストプランの準備を含んでいてもよいです。
In general, the existence of a framework for Performance Metric development does not constitute a security issue for the Internet. Performance Metric definitions, however, may introduce security issues, and this framework recommends that persons defining Performance Metrics should identify any such risk factors.
一般的には、パフォーマンスメトリックの開発のためのフレームワークが存在することは、インターネットのセキュリティ問題を構成するものではありません。パフォーマンスメトリックの定義は、しかし、セキュリティ上の問題を導入することができる、そしてこのフレームワークは、パフォーマンス・メトリックを定義する者は、そのようなリスク要因を特定しなければならないことをお勧めします。
The security considerations that apply to any active measurement of live networks are relevant here. See [RFC4656].
ライブネットワークの任意のアクティブな測定に適用するセキュリティ上の考慮事項はここでは関係しています。 [RFC4656]を参照してください。
The security considerations that apply to any passive measurement of specific packets in live networks are relevant here as well. See the security considerations in [RFC5475].
ライブネットワーク内の特定のパケットのいずれかの受動的測定に適用されるセキュリティ上の考慮事項はここにも関連しています。 [RFC5475]のセキュリティの考慮事項を参照してください。
The authors would like to thank Al Morton, Dan Romascanu, Daryl Malas, and Loki Jorgenson for their comments and contributions, and Aamer Akhter, Yaakov Stein, Carsten Schmoll, and Jan Novak for their reviews.
作者は彼らのレビューのためにアル・モートン、ダンRomascanu、ダリル・マラス、とロキJorgenson彼らのコメントと貢献のため、およびAamer Akhter、Yaakovのスタイン、カールステンSchmoll、とJanノバックに感謝したいと思います。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418]ブラドナーの、S.、 "IETFワーキンググループガイドラインと手順"、BCP 25、RFC 2418、1998年9月。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656] Shalunov、S.、Teitelbaum、B.、カープ、A.、BOOTE、J.、およびM. Zekauskas、 "ワンウェイアクティブな測定プロトコル（OWAMP）"、RFC 4656、2006年9月。
[E.800] "ITU-T Recommendation E.800. E SERIES: OVERALL NETWORK OPERATION, TELEPHONE SERVICE, SERVICE OPERATION AND HUMAN FACTORS", September 2008.
[E.800] "ITU-T勧告E.800 Eシリーズ：ネットワーク全体の動作、電話サービス、サービスの操作とヒューマンファクター"、2008年9月。
[G.107] "ITU-T Recommendation G.107. The E-model: a computational model for use in transmission planning", April 2009.
[G.107] "ITU-T勧告G.107 E-モデル：伝送計画で使用するための計算モデル"、2009年4月。
[IPPM-STANDARD-ADV-TESTING] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, "IPPM standard advancement testing", Work in Progress, June 2011.
[IPPM-STANDARD-ADV-TESTING] Geib、R.、エド。、モートン、A.、Fardid、R.、およびA. Steinmitz、 "IPPM標準前進テスト"、進歩、2011年6月での作業。
[P.564] "ITU-T Recommendation P.564. Conformance Testing for Voice over IP Transmission Quality Assessment Models", November 2007.
[P.564] "ITU-T勧告P.564。IP伝送品質評価モデル、ボイスオーバーのための適合性試験"、2007年11月。
[P.800] "ITU-T Recommendation P.800. Methods for subjective determination of transmission quality", August 1996.
[P.800] "ITU-T勧告P.800。伝送品質の主観的な決定のための方法"、1996年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "IPパフォーマンス・メトリックのためのフレームワーク"、RFC 2330、1998年5月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC3303] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]フリードマン、T.、エド。、カセレス、R.、エド。、およびA.クラーク、エド。、 "RTP制御プロトコルの拡張レポート（RTCP XR）"、RFC 3611、2003年11月。
[RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) Framework", RFC 4710, October 2006.
[RFC4710] Siddiqui著、A.、Romascanu、D.、およびE. Golovinsky、 "リアルタイムアプリケーションサービス品質のモニタリング（RAQMON）フレームワーク"、RFC 4710、2006年10月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、エド。、RFC 5101、2008年1月 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様"。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474]ダフィールド、N.編、Chiou、D.、Claise、B.、グリーンバーグ、A.、Grossglauser、M.、およびJ. Rexfordの、 "パケット選択及び報告のための枠組み"、RFC 5474年3月2009。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、モリーナ、M.、ダッフィールド、N.、ニッコリーニ、S.、およびF. Raspall、 "IPパケットの選択のためのサンプリングとフィルタリング技術"、RFC 5475、2009年3月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481]モートン、A.およびB. Claise、 "パケット遅延変動の適用に関する声明"、RFC 5481、2009年3月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]ハリントン、D.、RFC 5706、2009年11月「新しいプロトコルやプロトコル拡張の運用と管理を考えるためのガイドライン」。
[RFC5835] Morton, A., Ed., and S. Van den Berghe, Ed., "Framework for Metric Composition", RFC 5835, April 2010.
[RFC5835]モートン、A.編、及びS.ヴァンデンベルグフ編、 "メトリック組成物のためのフレームワーク"、RFC 5835、2010年4月。
[RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、編、カマリロ、G.、ペンフィールド、R.、Hawrylyshen、A.、およびM. Bhatiaは、 "セッション開始プロトコル（SIP）セッションボーダーコントロール（SBC）デプロイメントの要件"、RFC 5853、2010年4月。
[RFC5982] Kobayashi, A., Ed., and B. Claise, Ed., "IP Flow Information Export (IPFIX) Mediation: Problem Statement", RFC 5982, August 2010.
。。[RFC5982]小林、A.、エド、およびB. Claise、エド、 "IPフロー情報のエクスポート（IPFIX）調停：問題文"、RFC 5982、2010年8月。
[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Event Package for Voice Quality Reporting", RFC 6035, November 2010.
[RFC6035]ペンドルトン、A.、クラーク、A.、ジョンストン、A.、およびH. Sinnreich、 "音声品質報告のためのセッション開始プロトコルイベントパッケージ"、RFC 6035、2010年11月。
[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, January 2011.
[RFC6049]モートン、A.及びE.ステファン、 "メトリックの空間構成"、RFC 6049、2011年1月。
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
[RFC6183]小林、A.、Claise、B.、Muenz、G.、及びK.石橋、 "IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク"、RFC 6183、2011年4月。
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 2011.
[RFC6248]モートン、A.、 "RFC 4148およびIPパフォーマンス・メトリック（IPPM）メトリクスのレジストリは廃止されています"、RFC 6248、2011年4月。
Authors' Addresses
著者のアドレス
Alan Clark Telchemy Incorporated 2905 Premiere Parkway, Suite 280 Duluth, Georgia 30097 USA
アラン・クラークTelchemy株式会社2905プレミアパークウェイ、スイート280ダルース、ジョージア州30097 USA
EMail: alan.d.clark@telchemy.com
メールアドレス：alan.d.clark@telchemy.com
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium
ブノワClaiseシスコシステムズ、株式会社デKleetlaan 6aはB1のディーゲム1831ベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
電話：+32 2 704 5622 Eメール：bclaise@cisco.com