[要約] RFC 6390は、新しいパフォーマンスメトリックの開発を考慮するためのガイドラインです。その目的は、ネットワークパフォーマンスの評価において新しいメトリックの開発を支援し、標準化プロセスを促進することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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つのフェーズがあります。彼らは次のとおりです：
1. Definition of a Performance Metric and its units of measure
1. パフォーマンスメトリックとその測定単位の定義
2. Specification of a method of measurement
2. 測定方法の仕様
3. Specification of the reporting format
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）監視を可能にします他のハンドヘルドコンピューティングデバイス。さらに、「RTPコントロールプロトコル拡張レポート（RTCP XR）」[RFC3611]および「音声品質レポートのセッション開始プロトコルイベントパッケージ」[RFC6035]は、音声上の音声のリアルタイムエクスペリエンスエクスペリエンス（QOE）レポートをサポートするプロトコルを定義します（QOE）を定義します（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は、TCP [RFC0793]やStream Control Transmission Protocol（SCTP）[RFC4960]などの信頼できる輸送プロトコルの開発にも積極的に関与しており、IPパフォーマンスとアプリケーションパフォーマンスの関係に影響します。
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.
したがって、IETFワーキンググループ（WGS）の現在チャーターされたカバレッジにはギャップがあります。ライブネットワークのパフォーマンスを特徴付けるために使用できるIPレイヤーの上および下のプロトコルのパフォーマンスメトリックの開発。
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.
このドキュメントは、「目的と範囲」セクションを超えた2つの主要なセクションに分かれています。1つ目は、パフォーマンスメトリックとその重要な側面の定義と説明です。2番目は、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.
Performance Metrics Directorateは、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.
パフォーマンスメトリック局は、IPパフォーマンスメトリック（IPPM）、ベンチマーク方法（BMWG）、および他のレイヤー（PMOL）WGSのパフォーマンスメトリックから選択される可能性があるパフォーマンスコミュニティの専門家で構成される必要があります。
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）は、[E.800]のITU「品質（QOS）」セクション、つまり「明記された満足度のある通信サービスの特性の全体的な特性と同様の方法で定義されます。サービスのユーザーの暗黙のニーズ」。
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".
Experience of Experience（QOE）は、[customer/user/user（qose）が経験/知覚されたqos（qose）のセクション、つまり、顧客/ユーザーが品質のレベルを表すステートメントを表す声明に似た方法で定義されます。彼らが経験したと信じている」。
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は、サービスに対する認識に影響を与える適切な定性的要因を持つユーザーが配信、受信、および解釈とみなすと見なされる場合があります。
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応答時間、IPアドレスを解決するためのDNS応答時間、データベースロギング時間などです。
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の残りの部分とどのように対話するかを提案します。ただし、このドキュメントは、この分野で既存のチャーター作業を行っているWGS内の既存の作業方法に優先することを意図したものではありません。
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 WGSなどのメトリック開発に焦点を当てた既存のIETF WGSのパフォーマンスメトリック開発を管理するものではありません。ただし、このガイドラインドキュメントはこれらのアクティビティで役立つ場合があり、必要に応じて適用される場合があります。典型的な例は、特定の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
4. QoS、QOE、およびアプリケーション固有のパフォーマンスメトリックの関係
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はネットワークおよびネットワークプロトコルのパフォーマンスを扱い、QOEはタスクまたはサービスのコンテキストでのユーザーのエクスペリエンスの評価を扱います。アプリケーション固有のパフォーマンスメトリックのトピックには、IPとユーザー間のレイヤーでのパフォーマンスの測定が含まれます。たとえば、ネットワークQoSメトリック（パケット損失、遅延、および遅延変動[RFC5481]）を使用して、アプリケーション固有のパフォーマンスメトリック（デジターバッファサイズとRTP層パケット損失）を推定し、他の既知の側面と組み合わせて組み合わせることができます。 ITU-T P.564 [p.564]に準拠したアルゴリズムを使用したVoIPアプリケーション（コーデックタイプなど）の平均意見スコア（MOS）[P.800]を推定します。ただし、特定のVOIPユーザーのQOEは、カジュアルな会話、ビジネス電話の呼び出し、緊急電話など、特定のコンテキストに依存します。最後に、QoSとアプリケーション固有のパフォーマンスメトリックは定量的ですが、QOEは定性的です。また、ネットワークQosとアプリケーション固有のパフォーマンスメトリックは、ユーザーにとって直接的または間接的に明白になる可能性がありますが、QOEは直接明白です。
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 専用トラフィックを使用したライブトラフィックまたはアクティブ測定のパッシブ測定の適合性
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
(i) その不在が、測定されているアプリケーションまたはシステムの動作またはパフォーマンスに関する情報の大幅な損失を引き起こす程度
(ii) the correlation between the Performance Metric, the QoS, and the QoE delivered to the user (person or other application)
（ii）パフォーマンスメトリック、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）調停：問題ステートメント」[RFC5982]に基づいて、IPFIX調停フレームワーク[RFC6183]は、時間的および時間的および時間のいくつかの側面についても議論しています。空間構成。
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.
計算のいくつかの方法では、測定パラメーターを意味のあるものにするために、収集されたデータを（外れ値のため）破棄する必要がある場合があります。1つの例は、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.
測定が測定ポイントに固有の場合、これを定義する必要があります。測定ドメインも定義できます。具体的には、測定ポイントがドメイン全体に広がっている場合、測定ドメイン（内部、inter-）が考慮すべきもう1つの要因です。
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
（ii）検証
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
（iii）使用およびアプリケーション
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
（iv）レポートモデル
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
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.
潜在的な測定ドメインを備えた測定ポイント：このメトリックは、Voice Over 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 Metricsレポートでサンプリングおよび報告されます。
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 Singleton：小学校のインスタンス、または「原子」値。
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 [RFC2330]のセクション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によって審査されるべきです。プロセスのこの側面には、パフォーマンスメトリックの必要性の必要性の評価と、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セッション中にIETFセッションのディスカッションを行い、そのWGへの努力の可視性を最大化し、レビューを拡大することが適切です。
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テスト]を参照してください。これには、メトリックの定義が明確で明確であることを確認するために、メトリックのさまざまな実装を調べるためのテスト計画の準備が含まれます（上記のドラフトの最終形式に応じて）。
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.
著者は、コメントと貢献について、アル・モートン、ダン・ロマスカヌ、ダリル・マラス、ロキ・ジョルゲンソンに感謝したいと思います。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418] Bradner、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.、Karp、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-Model：伝送計画での使用のための計算モデル」、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.、ed。、Morton、A.、Fardid、R。、およびA. Steinmitz、「IPPM Standard Advancement Testing」、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] Postel、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] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、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.、Frederick、R。、およびV. Jacobson、「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] Friedman、T.、Ed。、Caceres、R.、ed。、およびA. Clark、ed。、「RTP Control Protocol拡張レポート（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] Stewart、R.、ed。、「Stream Control Transmission Protocol」、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.、ed。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[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.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「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] Duffield、N.、Ed。、Chiou、D.、Claise、B.、Greenberg、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.、Molina、M.、Duffield、N.、Niccolini、S。、およびF. Raspall、「IPパケット選択のためのサンプリングとフィルタリング技術」、RFC 5475、2009年3月。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009.
[RFC5481] Morton、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] Harrington、D。、「新しいプロトコルとプロトコル拡張の運用と管理を検討するためのガイドライン」、RFC 5706、2009年11月。
[RFC5835] Morton, A., Ed., and S. Van den Berghe, Ed., "Framework for Metric Composition", RFC 5835, April 2010.
[RFC5835] Morton、A.、ed。、およびS. van den Berghe、ed。、「メトリック組成のフレームワーク」、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.、Ed。、Camarillo、G.、Penfield、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] Kobayashi、A.、ed。、およびB. Claise、ed。、「IP Flow Information Export（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] Pendleton、A.、Clark、A.、Johnston、A.、およびH. Sinnreich、「Voice Quality Reportingのセッション開始プロトコルイベントパッケージ」、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. Ishibashi、「IP Flow Information Export（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] Morton、A。、「RFC 4148およびIPパフォーマンスメトリック（IPPM）メトリックのレジストリは時代遅れです」、RFC 6248、2011年4月。
Authors' Addresses
著者のアドレス
Alan Clark Telchemy Incorporated 2905 Premiere Parkway, Suite 280 Duluth, Georgia 30097 USA
Alan Clark Telchemy Incorporated 2905 Premiere Parkway、Suite 280 Duluth、Georgia 30097 USA
EMail: alan.d.clark@telchemy.com
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium
Benoit Claise Cisco Systems、Inc。de Kleetlaan 6a B1 Diegem 1831ベルギー
Phone: +32 2 704 5622
EMail: bclaise@cisco.com