Network Working Group G. Zorn
Internet-Draft Network Zen
Intended status: Standards Track R. Schott
Expires: April 15, 2012 Deutsche Telekom
Q. Wu
R. Huang
Huawei
October 13, 2011

RTCP XR for Summary Statistics Metrics Reporting
draft-zorn-xrblock-rtcp-xr-al-stat-03

Abstract

This document defines three RTCP XR Report Blocks and associated SDP parameters that allows the reporting of loss, duplication and discard summary statistics metrics for use in a range of RTP applications.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 15, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.


Table of Contents

1. Introduction

RFC 3611 [RFC3611] defines seven report block formats for network management and quality monitoring. However, some of these metrics are mostly for multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring and not widely applicable to other applications, e.g., video quality monitoring. This document focuses on specifying new additional report block types used to convey loss, duplication and discard summary statistics that are generically designed for use in audio and video services.

The metrics belong to both the class of application layer metrics and transport layer metrics defined in [MONARCH] (work in progress).

1.1. Applicability

The Report Blocks defined in this document can be applied to any real-time applications that convey loss, duplication and discard summary statistics.

2. Terminology

2.1. Standards Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

In addition, the following terms are defined:

Picture Type


Picture types used in the different video algorithms compose of the key-frame and the Derivation frame. Key-frame is also called a reference frame and used as a reference for predicting other pictures. It is coded without prediction from other pictures. The Derivation frame is derived from Key-frame using prediction from the reference frame.

3. Transport Layer Metrics

3.1. Burst/Gap Loss Summsary Statistics Block

The metrics described here are intended to be used as described in this section, in conjunction with information from the Measurement Information block (which MUST be present in the same RTCP packet as the Burst/Gap Loss block) and also with the metric "cumulative number of packets lost" provided in standard RTCP [RFC3550].

3.1.1. Report Block Structure

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=TBD    |I|    rsv.     |        block length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SSRC of Source                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Burst Loss Rate        |         Gap Loss Rate         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.2. Definition of Fields in Loss Summary Statistics Block

block type (BT): 8 bits


Burst/Gap Loss Summsary Statistics Block is identified by the constant <BGLSS>.

Interval Metric flag (I): 1 bit


This field is used to indicate whether the metrics block is an Interval or a Cumulative report,

reserved: 7 bits


This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.

block length: 16 bits


The constant 2, in accordance with the definition of this field in Section 3 of RFC 3611 [RFC3611].

SSRC of source: 32 bits


As defined in Section 4.1 of RFC3611 [RFC3611].

Burst Loss Rate: 16 bits


The fraction of packets lost during bursts since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing Packets Discarded in Bursts by Total Packets expected in Bursts as follows:

Packets Loss in Bursts / Total Packets expected in Bursts

Gap Loss Rate: 16 bits


The fraction of packets lost during gaps since the beginning of reception expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the difference between number of packets lost and Packets lost in Bursts by the difference between Packets Expected and Total Packets expected in Bursts as follows:

(number of packets lost - Packets Lost in Bursts) / (Packets Expected - Total Packets expected in Bursts)

where "number of packets lost" is obtained from standard RTCP [RFC3550] and Packets Expected is calculated as the difference between "extended last sequence number" and "extended first sequence number" (Interval or Cumulative) provided in the Measurement Identity and Information block [MEASIDENT].

Note that if the metric is to be calculated on an Interval basis, a difference must be taken between the current and preceding values of "cumulative number of packets lost" in RTCP, to obtain the "number of packets lost" for the reporting interval.

3.2. Burst/Gap Discard Summary Statistics Block

The metrics described here are intended to be used as described in this section, in conjunction with information from the Measurement Identity block (which MUST be present in the same RTCP packet as the Burst/Gap Discard block) and also with the metric "number of packets discarded" provided in the RTCP XR Discard Block [DISCARD]. The RTCP XR Discard Block SHOULD be sent if the Burst/Gap Discard block is sent, but the converse does not apply.

3.2.1. Report Block Structure

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=TBD    |I|     Rsv.    |        block length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          SSRC of Source                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Burst Discard Rate   |        Gap Discard Rate       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Burst duration Mean     |    Burst duration Varianc     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.2. Definition of Fields in Discard Summary Statistics Block

block type (BT): 8 bits


Burst/Gap Discard Summary Statistics Block is identified by the constant <BGDSS>.

reserved: 8 bits


This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.

Interval Metric flag (I): 1 bit


This field is used to indicate whether the metrics block is an Interval or a Cumulative report,

reserved: 7 bits


This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.

block length: 16 bits


The constant 3, in accordance with the definition of this field in Section 3 of RFC 3611 [RFC3611].

SSRC of source: 32 bits


As defined in Section 4.1 of RFC3611 [RFC3611].

Burst Discard Rate: 16 bits


The fraction of packets discarded during bursts since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing Packets Discarded in Bursts by Total Packets expected in Bursts as follows:

Packets Discarded in Bursts / Total Packets expected in Bursts

Gap Discard Rate: 16 bits


The fraction of packets discarded during gaps since the beginning of reception expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the difference between number of packets discarded and Packets Discarded in Bursts by the difference between Packets Expected and Total Packets expected in Bursts as follows:

(number of packets discarded - Packets Discarded in Bursts) / (Packets Expected - Total Packets expected in Bursts)

where "number of packets discarded" is obtained from the RTCP XR Discard Block [DISCARD] and Packets Expected is calculated as the difference between "extended last sequence number" and "extended first sequence number" (Interval or Cumulative) provided in the Measurement Information block [MEASIDENT].
Burst duration Mean:16bits


The mean burst duration is obtained as the quotient:

mean = Sum of Burst Durations / Number of Bursts

where " Sum of Burst Durations " and “Number of Bursts”is obtained from the RTCP XR Burst/Gap Discard Block.

Burst Duration Variance:16bits


The variance of the burst duration is obtained using the standard result:

var = ( Sum of Squares of Burst Durations - Number of Bursts * mean^2 ) / (Number of Bursts - 1)

where " Sum of Squares of Burst Durations " and “Number of Bursts”is obtained from the RTCP XR Burst/Gap Discard Block.

4. Application Layer Metrics

4.1. Application Layer Loss/Duplication Statistics Summary Block

This block reports statistics beyond the information carried in the Statistics Summary Report Block RTCP packet specified in the section 4.6 of RFC 3611 [RFC3611]. Information is recorded about lost frames ,duplicated frames, lost partial frames. Such information can be useful for network management and video quality monitoring.

4.1.1. Report Block Structure

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     BT=TBD    | |T|P|   rsv.  |        block length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        SSRC of Source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          begin_seq            |             end_seq           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Number of frames expected                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      lost_full_frames                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          dup_frames                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      lost_partial_frames                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.2. Definition of Fields in Loss/Duplication Summary Statistics Block

Block type (BT): 8 bits


Application Layer Loss/Duplication Statistics Summary Bloc is identified by the constant <ALDSS>.

Picture type indicator (T): 1 bit


Picture types used in the different video algorithms compose of key-frame and derivation frame. This field is used to indicate the frame type to be reported. Bits set to 0 if the lost_frames field or dup_frames field contain a key_frame report or reference frame report, 1 if the lost_frames field and dup_frames field contain other derivation frame report.

P: 1 bit


Bit set to 1 if the partial_lost_frames field or the partial_dup_ frames field contains a report, 0 otherwise.

Rsv.: 6 bits


This field is reserved for future definition. In the absence of such a definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver.

Block length: 16 bits


The constant 6, in accordance with the definition of this field in Section 3 of RFC 3611 [RFC3611].

SSRC of source: 32 bits


As defined in Section 4.1 of RFC3611 [RFC3611].

begin_seq: 16 bits


As defined in Section 4.1 of RFC 3611 [RFC3611].

end_seq: 16 bits


As defined in Section 4.1 of RFC 3611 [RFC3611].

number of frames expected:32bits


A count of the number of frames expected, estimated if necessary. If no frames have been received then this count shall be set to Zero.

lost_full_frames: 32 bits


If one frame is completely lost, this frame is regarded as one lost full_frame. The lost_full_frames is equivalent to the number of lost_full_frames in the above sequence number interval.

dup_frames: 32 bits


Number of dup_frames in the above sequence number interval.

lost_partial_frames: 32 bits


If one frame is partially lost, this frame is regarded as one lost fractional frame. The lost_partial_frames is equivalent to the number of lost_partial_frames in the above sequence number interval.

5. SDP Signaling

[RFC3611] defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used without prior signaling.

This section augments the SDP [RFC4566] attribute "rtcp-xr" defined in [RFC3611] by providing three additional value of "xr-format" to signal the use of the report block defined in this document.

     rtcp-xr-attrib =  "a=rtcp-xr:"
                       [xr-format *(SP xr-format)] CRLF
           xr-format =
                       / burst-gap-loss-stat
                       / burst-gap-discard-stat
                       / application-loss-dup-stat

Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description and the full syntax of the "rtcp-xr" attribute.

6. IANA Considerations

New block types for RTCP XR are subject to IANA registration. For general guidelines on IANA considerations for RTCP XR, refer to[RFC3611] .

6.1. New RTCP XR Block Type values

    
      Name:       BGLSS
      Long Name:  Burst/Gap Loss Summsary Statistics Block
      Value       <BGLSS>
      Reference:  Section 5.1

      Name:       BGDSS
      Long Name:  Burst/Gap Discard Summary Statistics Block
      Value       <BGDSS>
      Reference:  Section 5.2

      Name:       ALDSS
      Long Name:  Application Layer Loss/Duplication Statistics Summary
      Value       <ALDSS>
      Reference:  Section 6.1

This document assigns three new block type value in the RTCP XR Block Type Registry:

6.2. New RTCP XR SDP Parameters

 *  " burst-gap-loss-stat "
 *  " burst-gap-discard-stat "
 *  "application-loss-dup-stat "

This document also registers three new SDP [RFC4566] parameters for the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry:

6.3. Contact information for registrations

The contact information for the registrations is:

    Glen Zorn
    Network Zen
    227/358 Thanon Sanphawut
    Bang Na, Bangkok  10110
    Thailand

7. Security Considerations

The new RTCP XR report blocks proposed in this document introduces no new security considerations beyond those described in [RFC3611].

8. Acknowledgements

The authors would like to thank Bill Ver Steeg, David R Oran, Ali Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang Hu for their valuable comments and suggestions on this document.

9. References

9.1. Normative References

[I-D.ietf-avt-rtp-svc] Wenger, S, Wang, Y, Schierl, T and A Eleftheriadis, "RTP Payload Format for Scalable Video Coding", Internet-Draft draft-ietf-avt-rtp-svc-27, February 2011.
[RFC2250] Hoffman, D., Fernando, G., Goyal, V. and M.R. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[RFC3611] Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002.
[MEASIDENT] Wu, Q., "Measurement Identity and information Reporting using SDES item and XR Block ", ID draft-ietf-xrblock-rtcp-xr-meas-identity-01, October 2011.
[DISCARD] Hunt, G., "RTCP XR Report Block for Discard metric Reporting ", ID draft-ietf-rtcp-xr-discard-02, May 2009.

9.2. Informative References

[DSLF] Rahrer, T.R., Fiandra, and Wright, "Triple-play Services Quality of Experience (QoE) Requirements", DSL Forum Technical Report TR-126, December 2006.
[MONARCH] Wu, Q., "Monitoring Architectures for RTP", ID draft-ietf-avtcore-monarch-00, April 2011.
[PMOL] Clark, A., "Framework for Performance Metric Development", ID draft-ietf-pmol-metrics-framework-08, January 2011.

Appendix A. Change Log

This document is separated from draft-wu-xrblock-rtcp-xr-quality-monitoring-01 with a few editorial changes and focuses on loss,duplication, discard, and summary statistics metrics.

Authors' Addresses

Glen Zorn Network Zen 77/440 Soi Phoomjit, Rama IV Road Phra Khanong, Khlong Toie Bangkok, 10110 Thailand Phone: +66 (0) 87 502 4274 EMail: gwz@net-zen.net
Roland Schott Deutsche Telekom Deutsche-Telekom-Allee 7 Darmstadt, 64295 Germany EMail: Roland.Schott@telekom.de
Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China EMail: sunseawq@huawei.com
Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing, 210012 China EMail: Rachel@huawei.com