draft-ietf-avtcore-monarch-08.txt   draft-ietf-avtcore-monarch-09.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: June 1, 2012 Unaffiliated Expires: July 15, 2012 Unaffiliated
P. Arden P. Arden
BT BT
November 29, 2011 January 12, 2012
Monitoring Architectures for RTP Monitoring Architectures for RTP
draft-ietf-avtcore-monarch-08.txt draft-ietf-avtcore-monarch-09.txt
Abstract Abstract
This memo proposes an architecture for extending RTCP with a new RTCP This memo proposes an architecture for extending RTCP with a new RTCP
XR (RFC3611) block type to report new metrics regarding media XR (RFC3611) block type to report new metrics regarding media
transmission or reception quality, following RTCP guideline transmission or reception quality, following RTCP guideline
established in RFC5968. This memo suggests that a new block should established in RFC5968. This memo suggests that a new block should
contain a single metric or a small number of metrics relevant to a contain a single metric or a small number of metrics relevant to a
single parameter of interest or concern, rather than containing a single parameter of interest or concern, rather than containing a
number of metrics which attempt to provide full coverage of all those number of metrics which attempt to provide full coverage of all those
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 June 1, 2012. This Internet-Draft will expire on July 15, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 6 3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 6
3.1. RTCP Metric Block Report and associated parameters . . . . 8 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. RTCP Metric Block Report and associated parameters . . . . 8
3.3. RTP Sender/Receiver entities located in network nodes . . 9
4. Issues with reporting metric block using RTCP XR extension . . 10 4. Issues with reporting metric block using RTCP XR extension . . 10
5. Guideline for reporting metric block using RTCP XR . . . . . . 12 5. Guideline for reporting metric block using RTCP XR . . . . . . 12
5.1. Using single metrics blocks . . . . . . . . . . . . . . . 12 5.1. Using single metrics blocks . . . . . . . . . . . . . . . 12
5.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 12 5.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 12
5.3. Reducing Measurement information repetition . . . . . . . 13 5.3. Reducing Measurement information repetition . . . . . . . 13
5.4. Expanding the RTCP XR block namespace . . . . . . . . . . 13 5.4. Expanding the RTCP XR block namespace . . . . . . . . . . 13
6. An example of a metric block . . . . . . . . . . . . . . . . . 14 6. An example of a metric block . . . . . . . . . . . . . . . . . 15
7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 15 7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 16
7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 15 7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 16
7.2. Applicability to Translators . . . . . . . . . . . . . . . 16 7.2. Applicability to Translators . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
11. Informative References . . . . . . . . . . . . . . . . . . . . 20 11. Informative References . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23
A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 22 A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 23
A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 22 A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 23
A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 22 A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 23
A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 23 A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 24
A.5. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 23 A.5. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 24
A.6. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 23 A.6. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 24
A.7. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 24 A.7. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 25
A.8. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 24 A.8. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 A.9. draft-ietf-avtcore-monarch-08 . . . . . . . . . . . . . . 25
A.10. draft-ietf-avtcore-monarch-09 . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
As more users and subscribers rely on real time application services, As more users and subscribers rely on real time application services,
uncertainties in the performance and availability of these services uncertainties in the performance and availability of these services
are driving the need to support new standard methods for gathering are driving the need to support new standard methods for gathering
performance metrics from RTP applications. These rapidly emerging performance metrics from RTP applications. These rapidly emerging
standards, such as RTCP XR [RFC3611] and other RTCP extension to standards, such as RTCP XR [RFC3611] and other RTCP extension to
Sender Reports (SR), Receiver Reports (RR) [RFC3550] are being Sender Reports (SR), Receiver Reports (RR) [RFC3550] are being
developed for the purpose of collecting and reporting performance developed for the purpose of collecting and reporting performance
skipping to change at page 4, line 21 skipping to change at page 4, line 21
Transport level metrics Transport level metrics
A set of metrics which characterise the three transport A set of metrics which characterise the three transport
impairments of packet loss, packet delay, and packet delay impairments of packet loss, packet delay, and packet delay
variation. These metrics should be usable by any application variation. These metrics should be usable by any application
which uses RTP transport. which uses RTP transport.
Application level metrics Application level metrics
Metrics relating to QoE related parameters. These metrics are Metrics relating to application specific parameters or QoE related
measured at the application level and focus on quality of content parameters. Application specific parameters are measured at the
rather than network parameters. One example of such metrics is application level and focus on quality of content rather than
the QoE Metric specified in QoE metric reporting Block [MQ]. network performance. QoE related parameters reflect the end-to-
end performance at the services level and is ususally measured at
the user endpoint. One example of such metrics is the QoE Metric
specified in QoE metric reporting Block [MQ].
End System metrics End System metrics
Metrics relating to the way a terminal deals with transport Metrics relating to the way a terminal deals with transport
impairments affecting the incident RTP stream. These may include impairments affecting the incident RTP stream. These may include
de-jitter buffering, packet loss concealment, and the use of de-jitter buffering, packet loss concealment, and the use of
redundant streams (if any) for correction of error or loss. redundant streams (if any) for correction of error or loss.
Direct metrics Direct metrics
skipping to change at page 6, line 7 skipping to change at page 6, line 7
measurements measurements
Sampled metrics Sampled metrics
It is referred to as the metrics of which the reported values only It is referred to as the metrics of which the reported values only
apply to the value of a continuously measured or calculated that apply to the value of a continuously measured or calculated that
has been sampled at end of the interval. has been sampled at end of the interval.
3. RTP monitoring architecture 3. RTP monitoring architecture
3.1. Overview
The RTP monitoring architecture comprises the following two key The RTP monitoring architecture comprises the following two key
functional components shown below: functional components shown below:
o Monitor o Monitor
o Metric Block Structure o Metric Block Structure
Monitor is the functional component defined in the Real-time Monitor is the functional component defined in the Real-time
Transport Protocol (RTP) [RFC3550] that acts as a source of Transport Protocol (RTP) [RFC3550] that acts as a source of
information gathered for monitoring purposes. It may gather such information gathered for monitoring purposes. It may gather such
skipping to change at page 6, line 45 skipping to change at page 6, line 47
or formulated as or formulated as
o The Interval metrics o The Interval metrics
o or cumulative metrics o or cumulative metrics
o or sampled metrics. o or sampled metrics.
Both the RTCP or RTCP XR can be extended to convey these metrics. Both the RTCP or RTCP XR can be extended to convey these metrics.
The details on transport protocols for metric blocks are described in The details on transport protocols for metric blocks are described in
Section 3.1. Section 3.2.
+-------------------+ +-------------------+
| RTP Sender | +----------+ | RTP Sender | +----------+
| +-----------+ | |Management| | +-----------+ | |Management|
---------------->| Monitor |---------5------->| System | ---------------->| Monitor |---------5------->| System |
| | | | | | | | | | | | | |
| | +-----------+ | +----------+ | | +-----------+ | +----------+
| |+-----------------+| | |+-----------------+|
| ||Application || --------------| | ||Application || --------------|
| ||-Streaming video || | | | ||-Streaming video || | |
skipping to change at page 8, line 9 skipping to change at page 8, line 9
1. RTP communication between real time applications. 1. RTP communication between real time applications.
2. Application level metrics collection. 2. Application level metrics collection.
3. Transport level metrics collection. 3. Transport level metrics collection.
4. End System metrics collection. 4. End System metrics collection.
5. Reporting Session- metrics transmitted over specified interfaces. 5. Reporting Session- metrics transmitted over specified interfaces.
3.1. RTCP Metric Block Report and associated parameters 3.2. RTCP Metric Block Report and associated parameters
The basic RTCP Reception Report (RR) [RFC3550] conveys reception The basic RTCP Reception Report (RR) [RFC3550] conveys reception
statistics (i.e., transport level statistics) in metric block report statistics (i.e., transport level statistics) in metric block report
format for multiple RTP media streams including format for multiple RTP media streams including
o the fraction of packet lost since the last report o the fraction of packet lost since the last report
o the cumulative number of packets lost o the cumulative number of packets lost
o the highest sequence number received o the highest sequence number received
skipping to change at page 8, line 49 skipping to change at page 8, line 49
send RTCP Metric reports more frequently. For example, the Audio/ send RTCP Metric reports more frequently. For example, the Audio/
Video Profile with Feedback [RFC4585] extends the standard A/V Video Profile with Feedback [RFC4585] extends the standard A/V
Profile [RFC3551] to allow RTCP reports to be sent early provided Profile [RFC3551] to allow RTCP reports to be sent early provided
RTCP bandwidth allocation is respected. The following are four use RTCP bandwidth allocation is respected. The following are four use
cases but are not limited to: cases but are not limited to:
o RTCP NACK is used to provide feedback on the RTP sequence number o RTCP NACK is used to provide feedback on the RTP sequence number
of the lost packets [RFC4585]. of the lost packets [RFC4585].
o RTCP is extended to convey requests for full intra-coded frames or o RTCP is extended to convey requests for full intra-coded frames or
select the reference picture, and signalchanges in the desired select the reference picture, and signal changes in the desired
temporal/spatial trade-off and maximum media bit rate [RFC5104]. temporal/spatial trade-off and maximum media bit rate [RFC5104].
o RTCP or RTCP XR is extended to provide feedback on ECN statistics o RTCP or RTCP XR is extended to provide feedback on ECN statistics
information [ECN]. information [ECN].
o RTCP XR is extended to provide feedback on multicast acquisition o RTCP XR is extended to provide feedback on multicast acquisition
statistics information and parameters [RFC6332]. statistics information and parameters [RFC6332].
3.3. RTP Sender/Receiver entities located in network nodes
The location of the RTP Sender/Receiver entities may impact a set of
meaningful metrics. For instance, application level metrics for QoE
related performance parameters are usually measured at the user
device in the home network. However in some cases, given the factors
("measurement point location", "measurement model location",
"awareness of content information" etc) taken into account, such
metrics may be measured in a network node instead of a user device.
4. Issues with reporting metric block using RTCP XR extension 4. Issues with reporting metric block using RTCP XR extension
Issues that have come up in the past with reporting metric block Issues that have come up in the past with reporting metric block
using RTCP XR extensions include (but are probably not limited to) using RTCP XR extensions include (but are probably not limited to)
the following: the following:
o Using large block. A single report block or metric is designed to o Using large block. A single report block or metric is designed to
contain a large number of parameters in different classes for a contain a large number of parameters in different classes for a
specific application. For example, the RTCP Extended Reports specific application. For example, the RTCP Extended Reports
(XRs) [RFC3611] defines seven report block formats for network (XRs) [RFC3611] defines seven report block formats for network
skipping to change at page 10, line 34 skipping to change at page 10, line 34
RTP Protocol [RFC3550] is an example of existing tool that allows RTP Protocol [RFC3550] is an example of existing tool that allows
to bind an SSRC that may change to a fixed source name in one RTP to bind an SSRC that may change to a fixed source name in one RTP
session. It may be also fixed across multiple RTP sessions from session. It may be also fixed across multiple RTP sessions from
the same source. However there may be situations where RTCP the same source. However there may be situations where RTCP
reports are sent to other participating endpoints using non-RTP reports are sent to other participating endpoints using non-RTP
protocol in a session. For example, as described in the SIP RTCP protocol in a session. For example, as described in the SIP RTCP
Summary Report Protocol [RFC6035], the data contained in RTCP XR Summary Report Protocol [RFC6035], the data contained in RTCP XR
VoIP metrics reports [RFC3611] are forwarded to a central VoIP metrics reports [RFC3611] are forwarded to a central
collection server systems using SIP. In such case, there is a collection server systems using SIP. In such case, there is a
large portfolio of quality parameters that can be associated with large portfolio of quality parameters that can be associated with
real time application,e.g., VOIP application, but only a minimal real time application, e.g., VOIP application, but only a minimal
number of parameters are included on the RTCP-XR reports. number of parameters are included on the RTCP-XR reports.
Therefore correlation between RTCP XR and non-RTP data should be Therefore correlation between RTCP XR and non-RTP data should be
concerned if administration or management systems need to rely on concerned if administration or management systems need to rely on
the mapping RTCP statistics to non-RTCP measurements to conducts the mapping RTCP statistics to non-RTCP measurements to conducts
data analysis and creates alerts to the users. Without such data analysis and creates alerts to the users. Without such
correlation, it is hard to provide accurate measures of real time correlation, it is hard to provide accurate measures of real time
application quality with a minimal number of parameters included application quality with a minimal number of parameters included
on the RTCP-XR reports in such case. on the RTCP-XR reports in such case.
o Measurement Information duplication. Measurement information o Measurement Information duplication. Measurement information
provides information relevant to a measurement reported in one or provides information relevant to a measurement reported in one or
more other block types. For example we may set a metric interval more other block types. For example we may set a metric interval
for the session and monitor RTP packets within one or several for the session and monitor RTP packets within one or several
consecutive metric interval. In such case, the extra meaurement consecutive metric interval. In such case, the extra measurement
information (e.g., extended sequence number of 1st packet, information (e.g., extended sequence number of 1st packet,
measurement period) may be expected. However if we put such extra measurement period) may be expected. However if we put such extra
measurement information into each metric block, there may be measurement information into each metric block, there may be
situations where an RTCP XR packet containing multiple metric situations where an RTCP XR packet containing multiple metric
blocks, reports on the same streams from the same source. In blocks, reports on the same streams from the same source. In
other words, duplicated data for the measurement is provided other words, duplicated data for the measurement is provided
multiple times, once in every metric block. Though this design multiple times, once in every metric block. Though this design
ensures immunity to packet loss, it may bring more packetization ensures immunity to packet loss, it may bring more packetization
complexity and the processing overhead is not completely trivial complexity and the processing overhead is not completely trivial
in some cases. Therefore compromise between processing overhead in some cases. Therefore compromise between processing overhead
skipping to change at page 13, line 29 skipping to change at page 13, line 29
5.3. Reducing Measurement information repetition 5.3. Reducing Measurement information repetition
When multiple metric blocks are carried in one RTCP XR packet, When multiple metric blocks are carried in one RTCP XR packet,
reporting on the same stream from the same source for the same time reporting on the same stream from the same source for the same time
period, RTCP should use the SSRC to identify and correlate the period, RTCP should use the SSRC to identify and correlate the
multiple metric blocks between metric blocks. This memo proposes to multiple metric blocks between metric blocks. This memo proposes to
define a new XR Block that will be used to convey the common time define a new XR Block that will be used to convey the common time
period and the number of packets sent during this period [MI]. If period and the number of packets sent during this period [MI]. If
the measurement interval for a metric is different from the RTCP the measurement interval for a metric is different from the RTCP
reporting interval, then this measurement duration in the [MI] SHOULD reporting interval, then this measurement duration in the [MI] SHOULD
be used to specify the interval. In order to reduce measurement be used to specify the interval. When there may be multiple
information repetition in one RTCP XR compound packet containing measurements information blocks with the same SSRC in one RTCP XR
multiple metric blocks, the measurement information shall be sent compound packet, the measurement information block should be put in
before the related metric blocks that are from the same reporting order and followed by all the metric blocks associated with this
interval. Note that for packet loss robustness if the report blocks measurement information block. New RTCP XR metric blocks that rely
for the same interval span over more than one RTCP packet then each on the Measurement information block [MI] MUST specify the response
must have the measurement identity information even if though they in case the new RTCP XR metric block is received without an
will be the same. associated measurement information block; in most cases, it is
expected that the correct response is to discard the received metric.
In order to reduce measurement information repetition in one RTCP XR
compound packet containing multiple metric blocks, the measurement
information shall be sent before the related metric blocks that are
from the same reporting interval. Note that for packet loss
robustness if the report blocks for the same interval span over more
than one RTCP packet then each must have the measurement identity
information even if though they will be the same.
5.4. Expanding the RTCP XR block namespace 5.4. Expanding the RTCP XR block namespace
The consumption of XR block code points isn't a major issue. However The consumption of XR block code points isn't a major issue. However
if XR block codes points is really close to run out of space, it if XR block codes points is really close to run out of space, it
might be desirable to define new fields in the XR report block or might be desirable to define new fields in the XR report block or
define one XR block type for vendor-specific extensions, with an define one XR block type for vendor-specific extensions, with an
enterprise number included to identify the vendor making the enterprise number included to identify the vendor making the
extension. extension.
skipping to change at page 25, line 5 skipping to change at page 25, line 22
A.8. draft-ietf-avtcore-monarch-07 A.8. 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-08
The following are the major changes compared to 07:
o Editorial change to the reference.
A.10. draft-ietf-avtcore-monarch-09
The following are the major changes compared to 07:
o Rephrase application level metric definition.
o Add one new section to clarify where to measure QoE related
parameters.
o Add text in section 5.3 to clarify the failure case when
measurement interval is not sent.
o Add text in section 5.3 to clarify how to deal with multiple
measurements information blocks carried in the same packet.
Authors' Addresses Authors' Addresses
Qin Wu (editor) Qin Wu (editor)
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: sunseawq@huawei.com Email: sunseawq@huawei.com
 End of changes. 17 change blocks. 
41 lines changed or deleted 89 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/