draft-ietf-avtcore-monarch-02.txt   draft-ietf-avtcore-monarch-03.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 28, 2011 Unaffiliated Expires: December 18, 2011 Unaffiliated
P. Arden P. Arden
BT BT
May 27, 2011 June 16, 2011
Monitoring Architectures for RTP Monitoring Architectures for RTP
draft-ietf-avtcore-monarch-02.txt draft-ietf-avtcore-monarch-03.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, as proposed in RFC5968. This memo transmission or reception quality, as proposed in RFC5968. This memo
suggests that a new block should contain a single metric or a small suggests that a new block should contain a single metric or a small
number of metrics relevant to a single parameter of interest or number of metrics relevant to a single parameter of interest or
concern, rather than containing a number of metrics which attempt to concern, rather than containing a number of metrics which attempt to
provide full coverage of all those parameters of concern to a provide full coverage of all those parameters of concern to a
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 November 28, 2011. This Internet-Draft will expire on December 18, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . 5 3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 5
3.1. RTCP Metric Block Report and associated parameters . . . . 7 3.1. RTCP Metric Block Report and associated parameters . . . . 7
4. Issues with reporting metric block using RTCP XR extension . . 9 4. Issues with reporting metric block using RTCP XR extension . . 9
5. Guideline for reporting block format using RTCP XR . . . . . . 10 5. Guideline for reporting block format using RTCP XR . . . . . . 11
5.1. Using small blocks . . . . . . . . . . . . . . . . . . . . 10 5.1. Using small blocks . . . . . . . . . . . . . . . . . . . . 11
5.2. Sharing the identity information . . . . . . . . . . . . . 10 5.2. Reducing the identity information repetition . . . . . . . 11
5.3. Correlating identity information with the data . . . . . . 12 5.3. Correlating identity information with the non-RTP data . . 13
6. An example of a metric block . . . . . . . . . . . . . . . . . 13 6. An example of a metric block . . . . . . . . . . . . . . . . . 14
7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 14 7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 15
7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 14 7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 15
7.2. Applicability to Translators . . . . . . . . . . . . . . . 14 7.2. Applicability to Translators . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . . 19 11. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21
A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 20 A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 21
A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 20 A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 21
A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 20 A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 9, line 23 skipping to change at page 9, line 23
specific application. For example, RFC 3611 [RFC3611] defines specific application. For example, RFC 3611 [RFC3611] defines
seven report block formats for network management and quality seven report block formats for network management and quality
monitoring. However some of these block types defined in monitoring. However some of these block types defined in
[RFC3611] are only specifically designed for conveying multicast [RFC3611] are only specifically designed for conveying multicast
inference of network characteristics(MINC) or voice over IP (VoIP) inference of network characteristics(MINC) or voice over IP (VoIP)
monitoring. However different applications layered on RTP may monitoring. However different applications layered on RTP may
have some monitoring requirements in common, design large block have some monitoring requirements in common, design large block
only for specific applications may increase implementation cost only for specific applications may increase implementation cost
and minimize interoperability. and minimize interoperability.
o Identity Information duplication. There may be situations where o Identity Information duplication. Identity information is used to
an RTCP XR packet containing more than two metrics blocks, reports identify an instance of a metric block. The SSRC of the measured
on the same streams from the same source. In such case, each stream as part of the metric block is one example of Identity
metric block should have the same measurement identity, if each information. However in some cases, Identity information may be
metric block carry such duplicated data for the measurement,it not part of metric and include information more than one in the
leads to redundant information in this design since equivalent metric block,e.g., when we set a metric interval for the session
information is provided multiple times, once in *every* and monitor RTP packets within one or several consecutive metric
identification packet. Though this ensures immunity to packet interval, extra identity information is expected. In such case,
loss, the design bring more complexity and the overhead is not if we put such extra identity information into each metric block
completely trivial. or create standalone block containing extra identity information,
there may be situations where an RTCP XR packet containing more
than two metric blocks and other standalone block containing extra
identity information, reports on the same streams from the same
source. each block have the same identity information for
measurement, if each metric block carry such duplicated data for
the measurement, it leads to redundant information in this design
since equivalent information is provided multiple times, once in
*every* metric block and other block containing identity
information. Though this ensures immunity to packet loss, the
design bring more complexity and the overhead is not completely
trivial.
o Metric Blocks association. There may be situations where an RTCP o Correlating RTCP XR with the non-RTP data. There may be
XR packet containing four metrics blocks, reports on streams from situations where RTCP reports are sent to other participating
two sources. In such case, two identity blocks need to be added endpoints using non-RTP protocol in a session. For example, as
into the RTCP XR packet to correlate two sources if identity described in [RFC6035], the data contained in RTCP XR VoIP metrics
information is allowed separate from each metric block as one reports [RFC3611] are forwarded to a central collection server
independent block. However how to associate identity block with systems using SIP. In such case, there is a large portfolio of
relevant metric block data or other identity data is a problem, quality parameters that can be associated with real time
e.g., all identity blocks are following all the metric block or application,e.g., VOIP application, but only a minimal number of
vice versa make one receiving RTCP XR packet hard to distinguish parameters are included on the RTCP-XR reports. Therefore
from which metric block belong to which source. correlation between RTCP XR and non-RTP data should be concerned
if administration or management systems need to rely on the
mapping RTCP statistics to non-RTCP measurements to conducts data
analysis and creates alerts to the users. Without such
correlation, it is hardly to provide accurate measures of real
time application quality with a minimal number of parameters
included on the RTCP-XR reports in such case.
5. Guideline for reporting block format using RTCP XR 5. Guideline for reporting block format using RTCP XR
5.1. Using small blocks 5.1. Using small blocks
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)
skipping to change at page 10, line 40 skipping to change at page 11, line 40
To avoid this pitfall, this memo proposes the use of small RTCP XR To avoid this pitfall, this memo proposes the use of small RTCP XR
metrics blocks each containing a very small number of individual metrics blocks each containing a very small number of individual
metrics characterizing only one parameter of interest to an metrics characterizing only one parameter of interest to an
application running over RTP. For example, at the RTP transport application running over RTP. For example, at the RTP transport
layer, the parameter of interest might be packet delay variation, and layer, the parameter of interest might be packet delay variation, and
specifically the metric "IPDV" defined by [Y1540]. See Section 6 for specifically the metric "IPDV" defined by [Y1540]. See Section 6 for
architectural considerations for a metrics block, using as an example architectural considerations for a metrics block, using as an example
a metrics block to report packet delay variation. a metrics block to report packet delay variation.
5.2. Sharing the identity information 5.2. Reducing the identity information repetition
Any measurement must be identified. However if metrics are delivered
in small blocks there is a danger of inefficiency arising from
repeating this information in a number of metrics blocks within the
same RTCP packet, in cases where the same identification information
applies to multiple metrics blocks.
An instance of a metric must be identified using information which is Any measurement must be identified. For example, an instance of a
likely to include most of the following: metric must be identified using information which is likely to
include most of the following:
o the node at which it was measured, o the node at which it was measured,
o the source of the measured stream (for example, its CNAME), o the source of the measured stream (for example, its CNAME),
o the SSRC of the measured stream, o the SSRC of the measured stream,
o the sequence number of the first packet of the RTP session, o the sequence number of the first packet of the RTP session,
o the extended sequence numbers of the first packet of the current o the extended sequence numbers of the first packet of the current
measurement interval, and the last packet included in the measurement interval, and the last packet included in the
measurement, measurement,
o the duration of the most recent measurement interval and o the duration of the most recent measurement interval and
o the duration of the interval applicable to cumulative measurements o the duration of the interval applicable to cumulative measurements
(which may be the duration of the RTP session to date). (which may be the duration of the RTP session to date).
skipping to change at page 11, line 22 skipping to change at page 12, line 15
o the extended sequence numbers of the first packet of the current o the extended sequence numbers of the first packet of the current
measurement interval, and the last packet included in the measurement interval, and the last packet included in the
measurement, measurement,
o the duration of the most recent measurement interval and o the duration of the most recent measurement interval and
o the duration of the interval applicable to cumulative measurements o the duration of the interval applicable to cumulative measurements
(which may be the duration of the RTP session to date). (which may be the duration of the RTP session to date).
Note that this set of information may overlap with, but is more Note that this set of information (identity information) may overlap
extensive than, that in the union of similar information in RTCP RR with, but is more extensive than, that in the union of similar
packets. However we can not assume that RR information is always information in RTCP RR packets. However we can not assume that RR
present when XR is sent, since they may have different measurement information is always present when XR is sent, since they may have
intervals. Also the reason for the additional information carried in different measurement intervals. Also the reason for the additional
the XR is the perceived difficulty of "locating" the *start* of the information carried in the XR is the perceived difficulty of
RTP session (sequence number of 1st packet, duration of interval "locating" the *start* of the RTP session (sequence number of 1st
applicable to cumulative measurements) using only RR. However when packet, duration of interval applicable to cumulative measurements)
an RTCP XR packet containing more than two metrics blocks, reporting using only RR. Therefore this set of information can provide more
on the same streams from the same source, each metric block should detailed identity information relevant to the measurement report.
have the same measurement identity, if each metric block carry the However if such detailed identity information are all put into each
duplicated data for the measurement identity ,it leads to redundant metric and the metric are delivered in small blocks there is a danger
information in this design since equivalent information is provided of inefficiency arising from repeating this information in a number
multiple times, once in *every* identification packet. Though this of metrics blocks within the same RTCP packet, in cases where the
ensures immunity to packet loss, the design bring more complexity and same identification information applies to multiple metrics blocks.
the overhead is not completely trivial.
This section proposes an approach to minimise the inefficiency of This memo proposes an approach to minimise the inefficiency of
providing this identification information, assuming that an providing this identification information, assuming that an
architecture based on small blocks means that a typical RTCP packet architecture based on small blocks means that a typical RTCP packet
will contain more than one metrics block needing the same will contain more than one metrics block needing the same
identification. The choice of identification information to be identification. The choice of identification information to be
provided is discussed in [IDENTITY]. The approach is to define a provided is discussed in [IDENTITY]. The approach is to define a
stand-alone block containing only identification information within stand-alone block containing only identification information within
the scope of the containing RTCP XR packet. The "containing RTCP XR the scope of the containing RTCP XR packet. The "containing RTCP XR
packet" is defined here as the RTCP XR header with PT=XR=207 defined packet" is defined here as the RTCP XR header with PT=XR=207 defined
in Section 2 of [RFC3611] and the associated payload defined by the in Section 2 of [RFC3611] and the associated payload defined by the
length field of this RTCP XR header. The RTCP XR header itself length field of this RTCP XR header. The RTCP XR header itself
includes the SSRC of the node at which all of the contained metrics includes the SSRC of the node at which all of the contained metrics
were measured, hence this SSRC need not be repeated in the stand- were measured, hence this SSRC need not be repeated in the stand-
alone identification block. A single containing RTCP XR packet may alone identity block. A single RTCP XR packet containing multiple
contain multiple identification blocks limited by the range of the metric block may contain multiple identity blocks. Typically there
tag field. Typically there will be one identification block per will be one identity block per monitored source SSRC, but the use of
monitored source SSRC, but the use of more than one identification more than one identification block for a single monitored source SSRC
block for a single monitored source SSRC within a single containing within a single containing RTCP XR packet is not ruled out. In order
RTCP XR packet is not ruled out. In order to reduce overhead of the to further reduce identity information repeatition, This stand-alone
payload, This stand-alone block need only be exchanged occasionally, block is recommended to only be exchanged occasionally, for example
for example sent once at the start of a session. sent once at the start of a session.
5.3. Correlating identity information with the data 5.3. Correlating identity information with the non-RTP data
This section proposes an approach to facilitate the correlation of When more than one media transport protocols are used by one
the metrics report blocks with other session-related data or identity application to interconnected to the same session (in gateway),e.g.,
data, i.e., using correlation tag to associate identity information one RTCP XR Packet is sent to the participating endpoints using non-
with the data. RTP-based media transport in a VOIP session, one crucial factor lies
in how to handle their different identities that are corresponding to
different media transport.
For example, there will be zero or more metrics blocks dependent on This memo proposes an approach to facilitate the correlation of the
the same set of identity information. The dependence of an instance RTCP XR identity information with other session-related non-RTP data,
of a metrics block on such identity information can be established by i.e., using SSRC of source in the identity information as the
the metrics block's having the same numeric value of the tag field. correlation tag to associate identity information with the non-RTP-
based data.
Also there will be an identity data dependent on the same set of An example use case is for an participant endpoint may convey a call
identity information. If the set of identity information is formed identifier or a global call identifier associated with the XR block
as an independent block, then the dependence of an instance of a identity information and use SSRC of source in the identity
identity block on identity data can be established by the identity information as the correlation tag to the call identifier. A flow
block's having the tag field to indicate the relationship between measurement tool that is not call-aware then forward the subsequent
identity blocks and a specific application. An example use case is metric reports along with this correlation tag which is included in
for an endpoint may convey a call identifier or a global call the XR Block header to the network management. Network management
identifier associated with identity information. A flow measurement
tool that is not call-aware can then forward the metric reports along
with this correlation tag to network management. Network management
can then use this tag to correlate this report with other diagnostic can then use this tag to correlate this report with other diagnostic
information such as call detail records. information such as call detail records.
6. An example of a metric block 6. An example of a metric block
This section uses the example of an existing proposed metrics block This section uses the example of an existing proposed metrics block
to illustrate the application of the principles set out in to illustrate the application of the principles set out in
Section 5.1. Section 5.1.
The example [PDV] (work in progress) is a block to convey information The example [PDV] (work in progress) is a block to convey information
skipping to change at page 19, line 47 skipping to change at page 20, line 47
[RFC4585] Ott, J. and S. Wenger, "Extended RTP Profile for Real-time [RFC4585] Ott, J. and S. Wenger, "Extended RTP Profile for Real-time
Transport Control Protocol (RTCP)-Based Feedback (RTP/ Transport Control Protocol (RTCP)-Based Feedback (RTP/
AVPF)", RFC 4585, July 2006. AVPF)", RFC 4585, July 2006.
[RFC5117] Westerlund, M., "RTP Topologies", RFC 5117, January 2008. [RFC5117] Westerlund, M., "RTP Topologies", RFC 5117, January 2008.
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010. Control Protocol (RTCP)", RFC 5968, September 2010.
[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich,
"Session Initiation Protocol Event Package for Voice
Quality Reporting", RFC 6035, November 2010.
[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-00 A.1. draft-ietf-avtcore-monarch-00
skipping to change at page 22, line 5 skipping to change at page 22, line 8
application is out of scope of this draft. application is out of scope of this draft.
o Separeate identity information correlation from section 5.2 as new o Separeate 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.4. draft-ietf-avtcore-monarch-03
The following are the major changes compared to 01:
o Update bullet 2 in section 4 to explain the ill-effect of Identity
Information duplication.
o Update bullet 3 in section 4 to explain why Correlating RTCP XR
with the non-RTP data is needed.
o Update section 5.2 to focus on how to reduce the identity
information repetition
o Update section 5.3 to explain how to correlate identity
information with the non-RTP data
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. 19 change blocks. 
95 lines changed or deleted 126 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/