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
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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:
绩效标准的制定至少有三个阶段。详情如下:
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]定义了支持IP语音（VoIP）和其他设备（如IP电话和手机）上运行的应用程序的实时体验质量（QoE）报告的协议。
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]或流控制传输协议（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.
与“考虑新协议和协议扩展的运行和管理指南”[RFC5706]类似，这是IETF运行理事会的参考文件，本文件应作为性能指标理事会成员新性能指标审查的一部分参考。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
绩效指标委员会应由绩效社区的专家组成，可能从IP绩效指标（IPPM）、基准管理方法（BMWG）和其他层绩效指标（PMOL）工作组中选择。
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".
体验质量（QoE）的定义类似于[E.800]的ITU“客户/用户体验/感知的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有两个主要组成部分：定量和定性。定量组件可能受完整的端到端系统影响（包括用户设备和网络基础设施）。
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响应时间、解析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的其他成员互动。然而，本文件并不打算取代在该领域已有特许工作的工作组内的现有工作方法。
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.
该过程并不旨在管理现有IETF工作组中的性能度量开发，这些工作组主要关注度量开发，如IPPM和BMWG工作组。然而，本指南文件可能对这些活动有用，并可在适当情况下适用。一个典型的例子是使用IP流信息导出（IPFIX）协议[RFC5101]和特定IPFIX信息元素[RFC5102]导出性能指标的开发，这将受益于本文档中的框架。
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.
建议性能度量名称在为协议层和上下文定义的度量集合中是唯一的。虽然严格的唯一性可能无法实现（参见IPPM注册中心[RFC6248]了解IANA度量注册中心未能提供足够的特异性的示例），但必须寻求广泛的审查以避免命名重叠。请注意，性能度量委员会可以帮助您为IANA度量注册唯一命名提供建议。性能度量名称可以是描述性的。
(ii) Metric Description
（二）公制说明
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.
某些计算方法可能需要丢弃收集的某些数据（由于异常值），以便使测量参数有意义。一个例子是burstable账单，它对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
（四）计量单位
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).
性能度量定义应讨论性能度量值可能如何变化，具体取决于选择的测量点。例如，在用户代理客户端（UAC）或用户代理服务器（UAS）处，SIP请求[RFC3261]与最终响应之间的时间可以显著不同。
In some cases, the measurement requires multiple measurement points: all measurement points SHOULD be defined, including the measurement domain(s).
在某些情况下，测量需要多个测量点：应定义所有测量点，包括测量域。
(vi) Measurement Timing
（六）测量时间
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
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.
具有潜在测量域的测量点：此度量在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%.
测量时间：此指标可在广泛的时间间隔内使用。使用超过一小时的时间间隔可能会防止检测到由于网络负载的时间变化而导致的该度量值的变化。定时间隔的持续时间变化不应超过+/-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]将度量结果组织为三个相关概念：
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工作组是否使用术语名称。更多详情，请参考RFC 2330[RFC2330]第11节。
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.
建议书应以互联网草稿的形式编制，描述绩效指标，并尽可能符合上述资格要求。提案应为相应协议制定工作组章程的可交付成果。因此，该工作组应在绩效指标董事会讨论之前对提案进行审查。该过程的这一方面包括对提议的性能指标需求的评估，以及对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.
当考虑指定协议性能指标的互联网草案时，性能指标委员会应向相关协议开发工作组提供指导。必须有足够数量的具有专业知识的个人愿意就草案进行咨询。如果相关工作组得出结论，仍应征求关键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.
在某些情况下，在相关协议工作组会议期间进行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.
作者要感谢Al Morton、Dan Romascanu、Daryl Malas和Loki Jorgenson的评论和贡献，以及Aamer Akhter、Yaakov Stein、Carsten Schmoll和Jan Novak的评论。
[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 46562006年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.电子模型：用于输电规划的计算模型”，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标准推进测试”，正在进行的工作，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.，“传输控制协议”，标准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：会话启动协议”，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，“中间箱通信架构和框架”，RFC 33032002年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 35502003年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控制协议扩展报告（RTCP XR）”，RFC 36112003年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 47102006年10月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年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]Quitek，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 54742009年3月。
[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 54812009年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 58352010年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 58532010年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流信息导出（IPFIX）调解：问题陈述”，RFC 59822010年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，“语音质量报告的会话启动协议事件包”，RFC 60352010年11月。
[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, January 2011.
[RFC6049]Morton，A.和E.Stephan，“度量的空间构成”，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]Kobayashi，A.，Claise，B.，Muenz，G.，和K.Ishibashi，“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]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，美国佐治亚州德卢斯280套房30097
EMail: alan.d.clark@telchemy.com
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
Phone: +32 2 704 5622
EMail: bclaise@cisco.com