draft-ietf-avtcore-monarch-14.txt   draft-ietf-avtcore-monarch-15.txt 
Audio/Video Transport Working Group Q. Wu, Ed. Audio/Video Transport Working Group Q. Wu, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational G. Hunt Intended status: Informational G. Hunt
Expires: November 30, 2012 Unaffiliated Expires: December 21, 2012 Unaffiliated
P. Arden P. Arden
BT BT
May 29, 2012 June 19, 2012
Monitoring Architecture for RTP Guidelines for Use of the RTP Monitoring Framework
draft-ietf-avtcore-monarch-14.txt draft-ietf-avtcore-monarch-15.txt
Abstract Abstract
This memo proposes an architecture for extending RTP Control Protocol This memo proposes an extensible RTP monitoring framework for
(RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to extending RTP Control Protocol (RTCP) with a new RTCP Extended
report new metrics regarding media transmission or reception quality, Reports (XR) (RFC3611) block type to report new metrics regarding
following RTCP guidelines established in RFC5968. This memo suggests media transmission or reception quality, following RTCP guidelines
that a new block should contain a single metric or a small number of established in RFC5968. This memo suggests that a new block should
metrics relevant to a single parameter of interest or concern, rather contain a single metric or a small number of metrics relevant to a
than containing a number of metrics which attempt to provide full single parameter of interest or concern, rather than containing a
coverage of all those parameters of concern to a specific number of metrics which attempt to provide full coverage of all those
application. Applications may then "mix and match" to create a set parameters of concern to a specific application. Applications may
of blocks which covers their set of concerns. Where possible, a then "mix and match" to create a set of blocks which covers their set
specific block should be designed to be re-usable across more than of concerns. Where possible, a specific block should be designed to
one application, for example, for all of voice, streaming audio and be re-usable across more than one application, for example, for all
video. of voice, streaming audio and video.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2012. This Internet-Draft will expire on December 21, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 7 3. RTP Monitoring Framework . . . . . . . . . . . . . . . . . . . 7
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Overview of the RTP Monitoring Framework . . . . . . . . . 7
3.2. Location of RTP Monitors . . . . . . . . . . . . . . . . . 8 3.2. Location of RTP Monitors . . . . . . . . . . . . . . . . . 9
4. Issues with reporting metric block using RTCP XR extension . . 10 4. Issues with reporting metric block using RTCP XR extension . . 11
4.1. Using compound metrics block . . . . . . . . . . . . . . . 10 4.1. Using compound metrics block . . . . . . . . . . . . . . . 11
4.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 10 4.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 11
4.3. Measurement Information duplication . . . . . . . . . . . 10 4.3. Measurement Information duplication . . . . . . . . . . . 11
4.4. Consumption of XR block code points . . . . . . . . . . . 11 4.4. Consumption of XR block code points . . . . . . . . . . . 12
5. Guidelines for reporting metric block using RTCP XR . . . . . 12 5. Guidelines for reporting metric block using RTCP XR . . . . . 13
5.1. Contain the single metrics in the Metric Block . . . . . . 12 5.1. Contain the single metrics in the Metric Block . . . . . . 13
5.2. Include the payload type and format parameters in the 5.2. Include the payload type in the Metric Block . . . . . . . 13
Metric Block . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Use RTCP SDES to correlate XR reports with non-RTP data . 14
5.3. Use RTCP SDES to correlate XR reports with non-RTP data . 13
5.4. Reduce Measurement information repetition across 5.4. Reduce Measurement information repetition across
metric blocks . . . . . . . . . . . . . . . . . . . . . . 13 metric blocks . . . . . . . . . . . . . . . . . . . . . . 14
6. An example of a metric block . . . . . . . . . . . . . . . . . 15 6. An example of a metric block . . . . . . . . . . . . . . . . . 16
7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 16 7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 17
7.1. Applicability to Translators . . . . . . . . . . . . . . . 16 7.1. Applicability to Translators . . . . . . . . . . . . . . . 17
7.2. Applicability to MCU . . . . . . . . . . . . . . . . . . . 17 7.2. Applicability to MCU . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21
11. Informative References . . . . . . . . . . . . . . . . . . . . 21 11. Informative References . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24
A.1. draft-ietf-avtcore-monarch-14 . . . . . . . . . . . . . . 23 A.1. draft-ietf-avtcore-monarch-15 . . . . . . . . . . . . . . 24
A.2. draft-ietf-avtcore-monarch-13 . . . . . . . . . . . . . . 23 A.2. draft-ietf-avtcore-monarch-14 . . . . . . . . . . . . . . 24
A.3. draft-ietf-avtcore-monarch-12 . . . . . . . . . . . . . . 23 A.3. draft-ietf-avtcore-monarch-13 . . . . . . . . . . . . . . 24
A.4. draft-ietf-avtcore-monarch-11 . . . . . . . . . . . . . . 23 A.4. draft-ietf-avtcore-monarch-12 . . . . . . . . . . . . . . 24
A.5. draft-ietf-avtcore-monarch-10 . . . . . . . . . . . . . . 24 A.5. draft-ietf-avtcore-monarch-11 . . . . . . . . . . . . . . 25
A.6. draft-ietf-avtcore-monarch-09 . . . . . . . . . . . . . . 24 A.6. draft-ietf-avtcore-monarch-10 . . . . . . . . . . . . . . 25
A.7. draft-ietf-avtcore-monarch-08 . . . . . . . . . . . . . . 24 A.7. draft-ietf-avtcore-monarch-09 . . . . . . . . . . . . . . 25
A.8. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 24 A.8. draft-ietf-avtcore-monarch-08 . . . . . . . . . . . . . . 25
A.9. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 24 A.9. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 26
A.10. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 25 A.10. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 26
A.11. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 25 A.11. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 26
A.12. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 25 A.12. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 26
A.13. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 26 A.13. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 27
A.14. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 26 A.14. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 27
A.15. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 26 A.15. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 A.16. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Multimedia services using the Real-Time Protocol (RTP) are seeing Multimedia services using the Real-Time Protocol (RTP) are seeing
increased use. Standard methods for gathering RTP performance increased use. Standard methods for gathering RTP performance
metrics from these applications are needed to manage uncertainties in metrics from these applications are needed to manage uncertainties in
the behavior and availability of their services. Standards , such as the behavior and availability of their services. Standards , such as
RTP Control Protocol Extended Reports (RTCP XR)[RFC3611] and other RTP Control Protocol Extended Reports (RTCP XR)[RFC3611] and other
RTCP extension to Sender Reports (SR), Receiver Reports (RR) RTCP extension to Sender Reports (SR), Receiver Reports (RR)
[RFC3550] are being developed for the purpose of collecting and [RFC3550] are being developed for the purpose of collecting and
skipping to change at page 6, line 9 skipping to change at page 6, line 9
Metrics that are not measured directly but rather are derived by Metrics that are not measured directly but rather are derived by
algorithmically combining one or more measured metrics. An algorithmically combining one or more measured metrics. An
example is a metric derived based on direct metrics that have been example is a metric derived based on direct metrics that have been
measured. measured.
Interval metrics Interval metrics
Metrics measured over the course of a single reporting interval Metrics measured over the course of a single reporting interval
between two successive report blocks. This may be the most recent between two successive report blocks. This may be the most recent
RTCP reporting interval ( [RFC3550], section 6.2) or some other RTCP reporting interval ([RFC3550], section 6.2) or some other
interval signalled using an RTCP Measurement Information XR Block interval signalled using an RTCP Measurement Information XR Block
[MEASI]. An example interval metric is the count of the number of [MEASI]. An example interval metric is the count of the number of
RTP packets lost over the course of the last RTCP reporting RTP packets lost over the course of the last RTCP reporting
interval. interval.
Cumulative metrics Cumulative metrics
Metrics measured over several reporting intervals for accumulating Metrics measured over several reporting intervals for accumulating
statistics. The time period over which measurements are statistics. The time period over which measurements are
accumulated can be the complete RTP session, or some other accumulated can be the complete RTP session, or some other
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Metrics measured at a particular time instant and sampled from the Metrics measured at a particular time instant and sampled from the
values of a continuously measured or calculated metric within a values of a continuously measured or calculated metric within a
reporting interval (generally the value of some measurement as reporting interval (generally the value of some measurement as
taken at the end of the reporting interval). An example is the taken at the end of the reporting interval). An example is the
inter-arrival jitter reported in RTCP SR and RR packets, which is inter-arrival jitter reported in RTCP SR and RR packets, which is
continually updated as each RTP data packet arrives, but only continually updated as each RTP data packet arrives, but only
reported based on a snapshot of the value which is sampled at the reported based on a snapshot of the value which is sampled at the
instant the reporting interval ends. instant the reporting interval ends.
3. RTP monitoring architecture 3. RTP Monitoring Framework
There are many ways in which the performance of an RTP session can be There are many ways in which the performance of an RTP session can be
monitored. These include RTP-based mechanisms such as the RTP SNMP monitored. These include RTP-based mechanisms such as the RTP SNMP
MIB [RFC2959], or the SIP event package for RTCP summary reports MIB [RFC2959], or the SIP event package for RTCP summary reports
[RFC6035], or non-RTP mechanisms such as generic MIBs, NetFlow, [RFC6035], or non-RTP mechanisms such as generic MIBs, NetFlow,
IPFix, and so on. Together, these provide useful mechanisms for IPFix, and so on. Together, these provide useful mechanisms for
exporting data on the performance of an RTP session to non-RTP exporting data on the performance of an RTP session to non-RTP
network management systems. It is desirable to also perform in- network management systems. It is desirable to also perform in-
session monitoring of RTP performance. RTCP provides the means to do session monitoring of RTP performance. RTCP provides the means to do
this. In the following, we specify an architecture for using and this. In the following, we review the RTP Monitoring Framework, and
extending RTCP for monitoring RTP sessions. One major benefit of give guidance for using and extending RTCP for monitoring RTP
such architecture is ease of integration with other RTP/RTCP sessions. One major benefit of such framework is ease of integration
mechanisms. with other RTP/RTCP mechanisms.
3.1. Overview 3.1. Overview of the RTP Monitoring Framework
The RTP monitoring architecture comprises the following two key The RTP monitoring Framework comprises the following two key
functional components shown below: functional components shown below:
o RTP Monitor o RTP Monitor
o RTP Metric Block Structure o RTP Metric Block
RTP Monitor is the functional component defined in the Real-time RTP Monitor is the functional component defined in the Real-time
Transport Protocol [RFC3550] . It acts as a repository of Transport Protocol [RFC3550]. It acts as a repository of information
information gathered for monitoring purposes and exchanges such gathered for monitoring purposes.
information with the other RTP monitors using RTP Metric Blocks.
According to the definition of monitor in the RTP Protocol [RFC3550], According to the definition of monitor in the RTP Protocol [RFC3550],
the end system that runs an application program that sends or the end system that runs an application program that sends or
receives RTP data packets, an intermediate-system that forwards RTP receives RTP data packets, an intermediate-system that forwards RTP
packets to End-devices or a third party that observes the RTP and packets to End-devices or a third party that observes the RTP and
RTCP traffic but does not make itself visible to the RTP Session RTCP traffic but does not make itself visible to the RTP Session
participants can play the role of the RTP monitor within the RTP participants can play the role of the RTP monitor within the RTP
monitoring architecture. The third party RTP monitor should be monitoring Framework. As shown in Figure 1, the third party RTP
placed on the RTP/RTCP path between the sender, intermediate and the monitor can be a passive monitor that sees the RTP/RTCP stream pass
it, or a system that gets sent RTCP reports but not RTP and uses that
to collect information. The third party RTP monitor should be placed
on the RTP/RTCP path between the sender, intermediate and the
receiver. receiver.
The RTP monitor also exposes real time Application QoS/QoE metric The RTP Metric Block (MB) conveys real time Application QoS/QoE
information in the appropriate report block format (e.g.,RTCP XR or metric information and is used by the RTP monitor to exchange with
other non-RTP means) to the management system. Such information can other RTP monitors in the appropriate report block format. The
be formulated as various types of metrics, e.g., direct metrics/ information contained in the RTP MBs is collected by RTP monitors and
can be formulated as various types of metrics, e.g., direct metrics/
composed metrics or interval metrics/ cumulative metrics/sampled composed metrics or interval metrics/ cumulative metrics/sampled
metrics,etc. Both the RTCP or RTCP XR can be extended to convey metrics, etc. Both the RTCP or RTCP XR can be extended to transport
these metrics,e.g., the basic RTCP Reception Report (RR) [RFC3550] these metrics, e.g., the basic RTCP Reception Report (RR) [RFC3550]
that conveys reception statistics (i.e., transport level statistics) that conveys reception statistics (i.e., transport level statistics)
for multiple RTP media streams,the RTCP XRs [RFC3611] that supplement for multiple RTP media streams, the RTCP XRs [RFC3611] that
the existing RTCP packets and provide more detailed feedback on supplement the existing RTCP packets and provide more detailed
reception quality and RTCP NACK [RFC4585] that provides feedback on feedback on reception quality and RTCP NACK [RFC4585] that provides
the RTP sequence numbers for a subset of the lost packets or all the feedback on the RTP sequence numbers for a subset of the lost packets
currently lost packets. or all the currently lost packets. Ultimately the metric information
collected by RTP monitors within the RTP monitoring framework may go
to the network management tools beyond the RTP monitoring framework,
e.g., as shown Figure 1, the RTP monitors may export the metric
information derived from the RTP monitoring framework to the
management system using non-RTP means.
RTP may be used to multicast groups, both Any Source Multicast (ASM) +-------------------+
and Source Specific Multicast (SSM). These groups can be monitored | Management <-------------------------+
using RTCP. In the ASM case, the monitor is a member of the +-------------> System <--------------| |
multicast group and listens to RTCP XR reports from all members of | | | | |
the ASM group. In the SSM case, there is a unicast feedback target | +---------^---------+ | |
that receives RTCP feedback from receivers and distributes it to | | | |
other members of the SSM group (see figure 1 of [RFC5760] ). The | | | |
monitor will need to be co-located with the feedback target to +----------+ RTP/RTCP +Intermediary--+ RTP/RTCP +-------------+ |
receive all feedback from the receivers (this may also be an |RTP Sender| Stream | RTP System | Stream |RTP Receiver | |
intermediate system). In both ASM and SSM scenarios, receivers can |+-------+ |--------->| +-------+ |----------->| +-------+ | |
send RTCP XR reports to enhance the reception quality reporting. || | | | | RTP | | | | | | |
|| |<+-------------|Monitor|<---------------+--- | | |
|| | | MB | +-------+ | MB | | | | |
|| | | Report +--------------+ Report | | | | |
|| | | | | | | |
|| | | RTP/RTCP +------------+ | | | | |
|| RTP | | Stream | | | | RTP | | |
|| | |---------------------> Third Party| | | | | |
|| | | | RTP Monitor|-->| | | | |
||Monitor|<----------------------+ | || |Monitor| | |
|| | | MB +------------- || | | | |
|| | | Report || | | | |
|| | | || | | | |
|| | | RTCP +------------+ || | | | |
|| | | Stream | | || | | | |
|| | |---------------------> Third Party| || | | | |
|| | | | RTP Monitor--->| | | | |
|+-------+ | | | || +-------+ | |
| | +------------+ || | |
+----------+ |+-------------+ |
| |
+----------------+
Figure 1: RTP monitoring Framework
RTP may be used with multicast groups, both Any Source Multicast
(ASM) and Source Specific Multicast (SSM). These groups can be
monitored using RTCP. In the ASM case, the RTP monitor is a member
of the multicast group and listens to RTCP XR reports from all
members of the ASM group. In the SSM case, there is a unicast
feedback target that receives RTCP feedback from receivers and
distributes it to other members of the SSM group (see figure 1 of
[RFC5760] ). The RTP monitor will need to be co-located with the
feedback target to receive all feedback from the receivers (this may
also be an intermediate system). In both ASM and SSM scenarios,
receivers can send RTCP XR reports to enhance the reception quality
reporting.
3.2. Location of RTP Monitors 3.2. Location of RTP Monitors
There are several possible locations from where RTP sessions can be As shown in the Figure 1, there are several possible locations from
monitored. These include end-systems that terminate RTP sessions, where RTP sessions can be monitored. These include end-systems that
middleboxes that are an active part of an RTP session, and third- terminate RTP sessions, intermediate-systems that are an active part
party devices that passively monitor an RTP session. Not every RTP of an RTP session, and third-party devices that passively monitor an
sessions will include monitoring, and those sessions that are RTP session. Not every RTP sessions will include monitoring, and
monitored will not all include each type of monitor. The performance those sessions that are monitored will not all include each type of
metrics collected by RTP monitors can be divided into end system monitor. The performance metrics collected by RTP monitors can be
metrics, application level metrics, and transport level metrics. divided into end system metrics, application level metrics, and
Some of these metrics may be specific to the measurement point of the transport level metrics. Some of these metrics may be specific to
RTP monitor, or depend on where the RTP monitors are located in the the measurement point of the RTP monitor, or depend on where the RTP
network, while others are more general and can be collected in any monitors are located in the network, while others are more general
monitoring location. and can be collected in any monitoring location.
End-system monitoring is monitoring that is deployed on devices that End-system monitoring is monitoring that is deployed on devices that
terminate RTP flows. Flows can be terminated in user equipment, such terminate RTP flows. Flows can be terminated in user equipment, such
as phones, video conferencing systems, or IPTV set-top boxes. as phones, video conferencing systems, or IPTV set-top boxes.
Alternatively, they can be terminated in devices that gateway between Alternatively, they can be terminated in devices that gateway between
RTP and other transport protocols. Transport and end system metrics, RTP and other transport protocols. Transport and end system metrics,
application level metrics that don't reflect end to end user application level metrics that don't reflect end to end user
experience may be collected at all types of end system, but some experience may be collected at all types of end system, but some
application level metrics (i.e.,quality of experience (QoE) metrics) application level metrics (i.e.,quality of experience (QoE) metrics)
may only be applicable for user-facing end systems. may only be applicable for user-facing end systems.
RTP sessions can include middleboxes that are an active part of the RTP sessions can include intermediate-systems that are an active part
system. These middleboxes include RTP mixers and translators, MCUs, of the system. These intermediate-systems include RTP mixers and
retransmission servers, etc. If the middlebox establishes separate translators, MCUs, retransmission servers, etc. If the intermediate-
RTP sessions to the other participants, then it must act as an end system establishes separate RTP sessions to the other participants,
system in each of those separate RTP sessions for the purposes of then it must act as an end system in each of those separate RTP
monitoring. If a single RTP session traverses the middlebox, then sessions for the purposes of monitoring. If a single RTP session
the middlebox can be assigned an SSRC in that session which it can traverses the intermediate-system, then the intermediate-system can
use for it's reports. Transport level metrics may be collected at be assigned an SSRC in that session which it can use for it's
such middlebox. reports. Transport level metrics may be collected at such
intermediate-system.
Third-party monitors may be deployed that passively monitor RTP Third-party monitors may be deployed that passively monitor RTP
sessions for network management purposes. Third-party monitors often sessions for network management purposes. Third-party monitors often
do not send reports into the RTP session being monitored, but instead do not send reports into the RTP session being monitored, but instead
collect transport and end system metrics, application level metrics collect transport and end system metrics, application level metrics
that are reported via some network management application. In some that are reported via some network management application. In some
cases, however, third-party monitors can send reports to some or all cases, however, third-party monitors can send reports to some or all
participants in the session being monitored. For example, in a media participants in the session being monitored. For example, in a media
streaming scenario, third-party monitors may be deployed that streaming scenario, third-party monitors may be deployed that
passively monitor the session and send reception quality reports to passively monitor the session and send reception quality reports to
skipping to change at page 10, line 41 skipping to change at page 11, line 41
situations where RTCP reports are sent to other participating situations where RTCP reports are sent to other participating
endpoints using non-RTP protocol in a session. For example, as endpoints using non-RTP protocol in a session. For example, as
described in the SIP RTCP Summary Report Protocol [RFC6035], the data described in the SIP RTCP Summary Report Protocol [RFC6035], the data
contained in RTCP XR VoIP metrics reports [RFC3611] are forwarded to contained in RTCP XR VoIP metrics reports [RFC3611] are forwarded to
a central collection server systems using SIP. In such case, there a central collection server systems using SIP. In such case, there
is a large portfolio of quality parameters that can be associated is a large portfolio of quality parameters that can be associated
with real time application, e.g., VOIP application, but only a with real time application, e.g., VOIP application, but only a
minimal number of parameters are included on the RTCP-XR reports. minimal number of parameters are included on the RTCP-XR reports.
With these minimal number of RTCP statistics parameters mapped to With these minimal number of RTCP statistics parameters mapped to
non-RTCP measurements, it is hard to provide accurate measures of non-RTCP measurements, it is hard to provide accurate measures of
real time application quality,conduct detailed data analysis and real time application quality, conduct detailed data analysis and
creates alerts timly to the users. Therefore correlation between creates alerts timly to the users. Therefore correlation between
RTCP XR and non-RTP data should be provided. RTCP XR and non-RTP data should be provided.
4.3. Measurement Information duplication 4.3. Measurement Information duplication
We may set a measurement interval for the session and monitor RTP We may set a measurement interval for the session and monitor RTP
packets within one or several consecutive report intervals. In such packets within one or several consecutive report intervals. In such
case, the extra measurement information (e.g., extended sequence case, the extra measurement information (e.g., extended sequence
number of 1st packet, measurement period) may be expected. However number of 1st packet, measurement period) may be expected. However
if we put such extra measurement information into each metric block, if we put such extra measurement information into each metric block,
skipping to change at page 12, line 15 skipping to change at page 13, line 15
5. Guidelines for reporting metric block using RTCP XR 5. Guidelines for reporting metric block using RTCP XR
5.1. Contain the single metrics in the Metric Block 5.1. Contain the single metrics in the Metric Block
Different applications using RTP for media transport certainly have Different applications using RTP for media transport certainly have
differing requirements for metrics transported in RTCP to support differing requirements for metrics transported in RTCP to support
their operation. For many applications, the basic metrics for their operation. For many applications, the basic metrics for
transport impairments provided in RTCP SR and RR packets [RFC3550] transport impairments provided in RTCP SR and RR packets [RFC3550]
(together with source identification provided in RTCP SDES packets) (together with source identification provided in RTCP SDES packets)
are sufficient. For other applications additional metrics may be are sufficient. For other applications additional metrics may be
required or at least sufficiently useful to justify the overheads, required or at least sufficiently useful to justify the overhead,
both of processing in endpoints and of increased session bandwidth. both of processing in endpoints and of increased session bandwidth.
For example an IPTV application using Forward Error Correction (FEC) For example an IPTV application using Forward Error Correction (FEC)
might use either a metric of post-repair loss or a metric giving might use either a metric of post-repair loss or a metric giving
detailed information about pre-repair loss bursts to optimise payload detailed information about pre-repair loss bursts to optimise payload
bandwidth and the strength of FEC required for changing network bandwidth and the strength of FEC required for changing network
conditions. However there are many metrics available. It is likely conditions. However there are many metrics available. It is likely
that different applications or classes of applications will wish to that different applications or classes of applications will wish to
use different metrics. Any one application is likely to require use different metrics. Any one application is likely to require
metrics for more than one parameter but if this is the case, metrics for more than one parameter but if this is the case,
different applications will almost certainly require different different applications will almost certainly require different
skipping to change at page 12, line 45 skipping to change at page 13, line 45
parameter of interest might be packet delay variation, and parameter of interest might be packet delay variation, and
specifically the metric "IP Packet Delay Variation (IPDV)" defined by specifically the metric "IP Packet Delay Variation (IPDV)" defined by
[Y1540]. See Section 6 for architectural considerations for a [Y1540]. See Section 6 for architectural considerations for a
metrics block, using as an example a metrics block to report packet metrics block, using as an example a metrics block to report packet
delay variation. Further, it is appropriate to not only define delay variation. Further, it is appropriate to not only define
report blocks separately, but also to do so in separate documents report blocks separately, but also to do so in separate documents
where possible. This makes it easier to evolve the reports (i.e., to where possible. This makes it easier to evolve the reports (i.e., to
update each type of report block separately), and also makes it update each type of report block separately), and also makes it
easier to require compliance with a particular report block. easier to require compliance with a particular report block.
5.2. Include the payload type and format parameters in the Metric Block 5.2. Include the payload type in the Metric Block
There are some classes of metrics that can only be interpreted with There are some classes of metrics that can only be interpreted with
knowledge of the media codec that is being used (audio mean opinion knowledge of the media codec that is being used (audio mean opinion
scores (MOS) were the triggering example, but there may be others). scores (MOS) were the triggering example, but there may be others).
In such cases the correlation of RTCP XR with RTP data is needed. In such cases the correlation of RTCP XR with RTP data is needed.
Report blocks that require such correlation need to include the Report blocks that require such correlation need to include the
payload type of the reported media. In addition, it is necessary to payload type of the reported media. In addition, it is necessary to
signal the details and parameters of the payload format to which that signal the details and parameters of the payload format to which that
payload type is bound using some out-of-band means (e.g., as part of payload type is bound using some out-of-band means (e.g., as part of
an SDP offer/answer exchange). an SDP offer/answer exchange).
skipping to change at page 15, line 23 skipping to change at page 16, line 23
block should address only one parameter of interest. One simple block should address only one parameter of interest. One simple
metric of PDV is available in the RTCP RR packet as the "interarrival metric of PDV is available in the RTCP RR packet as the "interarrival
jitter" field. There are other PDV metrics with a certain similarity jitter" field. There are other PDV metrics with a certain similarity
in metric structure which may be more useful to certain applications. in metric structure which may be more useful to certain applications.
Two such metrics are the IPDV metric ([Y1540], [RFC3393]) and the Two such metrics are the IPDV metric ([Y1540], [RFC3393]) and the
mean absolute packet delay variation 2 (MAPDV2) metric [G1020]. Use mean absolute packet delay variation 2 (MAPDV2) metric [G1020]. Use
of these metrics is consistent with the principle in Section 5 of of these metrics is consistent with the principle in Section 5 of
RTCP guideline [RFC5968] that metrics should usually be defined RTCP guideline [RFC5968] that metrics should usually be defined
elsewhere, so that RTCP standards define only the transport of the elsewhere, so that RTCP standards define only the transport of the
metric rather than its nature. The purpose of this section is to metric rather than its nature. The purpose of this section is to
illustrate the architecture using the example of [PDV] rather than to illustrate the architectural consideration using the example of [PDV]
document the design of the PDV metrics block or to provide a tutorial rather than to document the design of the PDV metrics block or to
on PDV in general. provide a tutorial on PDV in general.
Given the availability of at least three metrics for PDV, there are Given the availability of at least three metrics for PDV, there are
design options for the allocation of metrics to RTCP XR blocks: design options for the allocation of metrics to RTCP XR blocks:
o provide an RTCP XR block per metric o provide an RTCP XR block per metric
o provide a single RTCP XR block which contains all three metrics o provide a single RTCP XR block which contains all three metrics
o provide a single RTCP block to convey any one of the three o provide a single RTCP block to convey any one of the three
metrics, together with a identifier to inform the receiving RTP metrics, together with a identifier to inform the receiving RTP
skipping to change at page 16, line 32 skipping to change at page 17, line 32
[RFC3550]. Provided this expectation is met, an RTP system using [RFC3550]. Provided this expectation is met, an RTP system using
RTCP XR is architecturally no different from an RTP system of the RTCP XR is architecturally no different from an RTP system of the
same class (end system, mixer, or translator) which does not use RTCP same class (end system, mixer, or translator) which does not use RTCP
XR. The second category relates to deployed system models used in XR. The second category relates to deployed system models used in
many H.323 [H323] video conferences. The topologies in this category many H.323 [H323] video conferences. The topologies in this category
are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such
topologies based on systems (e.g.,MCUs) do not behave according to topologies based on systems (e.g.,MCUs) do not behave according to
the RTP protocol [RFC3550]. the RTP protocol [RFC3550].
Considering the translator and MCU are two typical intermediate- Considering the translator and MCU are two typical intermediate-
systems in the two categories mentioned above, this document will systems in these two categories mentioned above, this document will
take them as two typical examples to explain how RTCP XR report works take them as two typical examples to explain how RTCP XR report works
in different RFC5117 topologies. in different RFC5117 topologies.
7.1. Applicability to Translators 7.1. Applicability to Translators
Section 7.2 of the RTP protocol [RFC3550] describes processing of Section 7.2 of the RTP protocol [RFC3550] describes processing of
RTCP by translators. RTCP XR is within the scope of the RTCP by translators. RTCP XR is within the scope of the
recommendations of the RTP protocol [RFC3550]. Some RTCP XR metrics recommendations of the RTP protocol [RFC3550]. Some RTCP XR metrics
blocks may usefully be measured at, and reported by, translators. As blocks may usefully be measured at, and reported by, translators. As
described in the RTP protocol [RFC3550] this creates a requirement described in the RTP protocol [RFC3550] this creates a requirement
skipping to change at page 23, line 10 skipping to change at page 24, line 10
Performance Metric Development", RFC 6390, October 2011. Performance Metric Development", RFC 6390, October 2011.
[Y1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and [Y1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and
availability performance parameters", November 2007. availability performance parameters", November 2007.
Appendix A. Change Log Appendix A. Change Log
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
A.1. draft-ietf-avtcore-monarch-14 A.1. draft-ietf-avtcore-monarch-15
The following are the major changes compared to 14:
o Add figure 1 in section 3 to describe RTP monitoring framework.
o Change the title as Guidelines for Use of the RTP Monitoring
Framework.
o Other editorial change to get in line with the title change in the
section 3.
A.2. draft-ietf-avtcore-monarch-14
The following are the major changes compared to 13: The following are the major changes compared to 13:
o Incorporate the key points in the section 3.2 into overview o Incorporate the key points in the section 3.2 into overview
section. section.
o Remove the figure 1 and use the description instead. o Remove the figure 1 and use the description instead.
o Add description in the section 3.3 to discuss the possible o Add description in the section 3.3 to discuss the possible
location of the monitors and the types of metric at that location. location of the monitors and the types of metric at that location.
o Add the description to make the definition of Interval metrics/ o Add the description to make the definition of Interval metrics/
cumulative metrics/sampled metrics clear. cumulative metrics/sampled metrics clear.
o Editorial Changes. o Editorial Changes.
A.2. draft-ietf-avtcore-monarch-13 A.3. draft-ietf-avtcore-monarch-13
The following are the major changes compared to 12: The following are the major changes compared to 12:
o Editorial Changes. o Editorial Changes.
A.3. draft-ietf-avtcore-monarch-12 A.4. draft-ietf-avtcore-monarch-12
The following are the major changes compared to 11: The following are the major changes compared to 11:
o Editorial Changes based on Charles' Comments. o Editorial Changes based on Charles' Comments.
o Reference update. o Reference update.
o Add one new section 5.2 to discuss Correlating RTCP XR with RTP o Add one new section 5.2 to discuss Correlating RTCP XR with RTP
data. data.
o Add text in section 5.1 to highlight it is more appropriate to o Add text in section 5.1 to highlight it is more appropriate to
define each block in a separate draft. define each block in a separate draft.
A.4. draft-ietf-avtcore-monarch-11 A.5. draft-ietf-avtcore-monarch-11
The following are the major changes compared to 10: The following are the major changes compared to 10:
o Editorial Changes. o Editorial Changes.
A.5. draft-ietf-avtcore-monarch-10 A.6. draft-ietf-avtcore-monarch-10
The following are the major changes compared to 09: The following are the major changes compared to 09:
o Discuss what exist already for monitoring in section 3.1. o Discuss what exist already for monitoring in section 3.1.
o Provide benefit using RTCP XR based monitoring in section 3.1. o Provide benefit using RTCP XR based monitoring in section 3.1.
o add one new paragraph in section 3.1 to describe how monitoring o add one new paragraph in section 3.1 to describe how monitoring
architecture is applied to ASM/SSM. architecture is applied to ASM/SSM.
o Other Editorial Changes. o Other Editorial Changes.
A.6. draft-ietf-avtcore-monarch-09 A.7. draft-ietf-avtcore-monarch-09
The following are the major changes compared to 07: The following are the major changes compared to 07:
o Rephrase application level metric definition. o Rephrase application level metric definition.
o Add one new section to clarify where to measure QoE related o Add one new section to clarify where to measure QoE related
parameters. parameters.
o Add text in section 5.3 to clarify the failure case when o Add text in section 5.3 to clarify the failure case when
measurement interval is not sent. measurement interval is not sent.
o Add text in section 5.3 to clarify how to deal with multiple o Add text in section 5.3 to clarify how to deal with multiple
measurements information blocks carried in the same packet. measurements information blocks carried in the same packet.
A.7. draft-ietf-avtcore-monarch-08 A.8. draft-ietf-avtcore-monarch-08
The following are the major changes compared to 07: The following are the major changes compared to 07:
o Editorial change to the reference. o Editorial change to the reference.
A.8. draft-ietf-avtcore-monarch-07 A.9. draft-ietf-avtcore-monarch-07
The following are the major changes compared to 06: The following are the major changes compared to 06:
o Clarify the XR block code points consumption issue in the section o Clarify the XR block code points consumption issue in the section
4 and new section 5.4. 4 and new section 5.4.
o Other editorial changes. o Other editorial changes.
A.9. draft-ietf-avtcore-monarch-06 A.10. draft-ietf-avtcore-monarch-06
The following are the major changes compared to 05: The following are the major changes compared to 05:
o Some editorial changes. o Some editorial changes.
A.10. draft-ietf-avtcore-monarch-05 A.11. draft-ietf-avtcore-monarch-05
The following are the major changes compared to 04: The following are the major changes compared to 04:
o Replace "chunk" with "new SDES item". o Replace "chunk" with "new SDES item".
o Add texts in security section to discussion potential security o Add texts in security section to discussion potential security
issues. issues.
o Add new sub-section 5.3 to discuss Reducing Measurement o Add new sub-section 5.3 to discuss Reducing Measurement
information repetition. information repetition.
o Other editorial changes. o Other editorial changes.
A.11. draft-ietf-avtcore-monarch-04 A.12. draft-ietf-avtcore-monarch-04
The following are the major changes compared to 03: The following are the major changes compared to 03:
o Update section 5.2 to clarify using SDES packet to carry o Update section 5.2 to clarify using SDES packet to carry
correlation information. correlation information.
o Remove section 5.3 since additional identity information goes to o Remove section 5.3 since additional identity information goes to
SDES packet and using SSRC to identify each block is standard RTP SDES packet and using SSRC to identify each block is standard RTP
feature. feature.
o Swap the last two paragraphs in the section 4 since identity o Swap the last two paragraphs in the section 4 since identity
information duplication can not been 100% avoided. information duplication can not been 100% avoided.
o Other editorial changes. o Other editorial changes.
A.12. draft-ietf-avtcore-monarch-03 A.13. draft-ietf-avtcore-monarch-03
The following are the major changes compared to 02: The following are the major changes compared to 02:
o Update bullet 2 in section 4 to explain the ill-effect of Identity o Update bullet 2 in section 4 to explain the ill-effect of Identity
Information duplication. Information duplication.
o Update bullet 3 in section 4 to explain why Correlating RTCP XR o Update bullet 3 in section 4 to explain why Correlating RTCP XR
with the non-RTP data is needed. with the non-RTP data is needed.
o Update section 5.2 to focus on how to reduce the identity o Update section 5.2 to focus on how to reduce the identity
information repetition information repetition
o Update section 5.3 to explain how to correlate identity o Update section 5.3 to explain how to correlate identity
information with the non-RTP data information with the non-RTP data
A.13. draft-ietf-avtcore-monarch-02 A.14. draft-ietf-avtcore-monarch-02
The following are the major changes compared to 01: The following are the major changes compared to 01:
o Deleting first paragraph of Section 1. o Deleting first paragraph of Section 1.
o Deleting Section 3.1, since the interaction with the management o Deleting Section 3.1, since the interaction with the management
application is out of scope of this draft. application is out of scope of this draft.
o Separate identity information correlation from section 5.2 as new o Separate identity information correlation from section 5.2 as new
section 5.3. section 5.3.
o Remove figure 2 and related text from section 5.2. o Remove figure 2 and related text from section 5.2.
o Editorial changes in the section 4 and the first paragraph of o Editorial changes in the section 4 and the first paragraph of
section 7. section 7.
A.14. draft-ietf-avtcore-monarch-01 A.15. draft-ietf-avtcore-monarch-01
The following are the major changes compared to 00: The following are the major changes compared to 00:
o Restructure the document by merging section 4 into section 3. o Restructure the document by merging section 4 into section 3.
o Remove section 4.1,section 5 that is out of scope of this o Remove section 4.1,section 5 that is out of scope of this
document. document.
o Remove the last bullet in section 6 and section 7.3 based on o Remove the last bullet in section 6 and section 7.3 based on
conclusion of last meeting. conclusion of last meeting.
skipping to change at page 26, line 44 skipping to change at page 28, line 12
o Update figure 1 and related text in section 3 according to the o Update figure 1 and related text in section 3 according to the
monitor definition in RFC3550. monitor definition in RFC3550.
o Revise section 9 to address monitor declaration issue. o Revise section 9 to address monitor declaration issue.
o Merge the first two bullet in section 6. o Merge the first two bullet in section 6.
o Add one new bullet to discuss metric block association in section o Add one new bullet to discuss metric block association in section
6. 6.
A.15. draft-ietf-avtcore-monarch-00 A.16. draft-ietf-avtcore-monarch-00
The following are the major changes compared to The following are the major changes compared to
draft-hunt-avtcore-monarch-02: draft-hunt-avtcore-monarch-02:
o Move Geoff Hunt and Philip Arden to acknowledgement section. o Move Geoff Hunt and Philip Arden to acknowledgement section.
Authors' Addresses Authors' Addresses
Qin Wu (editor) Qin Wu (editor)
Huawei Huawei
 End of changes. 41 change blocks. 
136 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/