The RFC Archive
 The RFC Archive   RFC 7509   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 7509



Last modified on Wednesday, May 13th, 2015

Permanent link to RFC 7509
Search GitHub Wiki for RFC 7509
Show other RFCs mentioning RFC 7509







Internet Engineering Task Force (IETF)                          R. Huang
Request for Comments: 7509                                        Huawei
Category: Standards Track                                     V. Singh
ISSN: 2070-1721                                         Aalto University
                                                                May 2015


            RTP Control Protocol (RTCP) Extended Report (XR)
                   for Post-Repair Loss Count Metrics

 Abstract

   This document defines an RTP Control Protocol (RTCP) Extended Report
   (XR) block that allows reporting of a post-repair loss count metric
   for a range of RTP applications.  In addition, another metric,
   repaired loss count, is also introduced in this report block for
   calculating the pre-repair loss count when needed, so that the RTP
   sender or a third-party entity is able to evaluate the effectiveness
   of the repair methods used by the system.

 Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/RFC 7509.

 Copyright Notice

   Copyright (c) 2015 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.



Singh & Huang                Standards Track                 PAGE 1 top


RFC 7509 Post-Repair Non-RLE Loss Count May 2015 Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................3 3. Post-Repair Loss Count Metrics Report Block .....................3 3.1. Report Block Structure .....................................4 3.2. Example Usage ..............................................5 4. SDP Signaling ...................................................6 4.1. SDP rtcp-xr-attrib Attribute Extension .....................6 4.2. Offer/Answer Usage .........................................7 5. Security Considerations .........................................7 6. IANA Considerations .............................................7 6.1. New RTCP XR Block Type Value ...............................7 6.2. New RTCP XR SDP Parameter ..................................7 6.3. Contact Information for Registrations ......................7 7. References ......................................................8 7.1. Normative References .......................................8 7.2. Informative References .....................................9 Appendix A. Metrics Represented Using the Template from RFC 6390 ..10 Acknowledgments ...................................................11 Authors' Addresses ................................................11 1. Introduction RTCP Sender Reports (SRs) / Receiver Reports (RRs) [RFC 3550] contain some rough statistics about the data received from the particular source indicated in that block. One of them is the cumulative number of packets lost, which is called the pre-repair loss metric in this document. This metric conveys information regarding the total number of RTP data packets that have been lost since the beginning of the RTP session. However, this metric is measured on the media stream before any loss- repair mechanism, e.g., retransmission [RFC 4588] or Forward Error Correction (FEC) [RFC 5109], is applied. Using a repair mechanism usually results in recovering some or all of the lost packets. The recovery process does not reduce the values reported by the two loss metrics in RTCP RR [RFC 3550] -- namely, the fraction lost and the cumulative loss. Hence, the sending endpoint cannot infer the performance of the repair mechanism based on the aforementioned metrics in [RFC 3550]. Consequently, [RFC 5725] specifies a post-repair loss Run-Length Encoding (RLE) XR report block to address this issue. The sending endpoint is able to infer which packets were repaired from the RLE report block, but the reporting overhead for the packet-by-packet report block is higher compared to other report blocks. Singh & Huang Standards Track PAGE 2 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 When applications use multiple XR blocks, the endpoints may require more concise reporting to save bandwidth. This document defines a new XR block type to augment those defined in [RFC 3611] and complement the report block defined in [RFC 5725] for use in a range of RTP applications. This new block type reports the post-repair loss count metric, which records the number of primary source RTP packets that are still lost after applying one or more loss-repair mechanisms. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count during this range, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system. The metrics defined in this document are packet level rather than slice/picture level; this means the partial recovery of a packet will not be regarded as a repaired packet. The metrics defined in this document belong to the class of transport-related metrics defined in [RFC 6792] and are specified in accordance with the guidelines in [RFC 6390] and [RFC 6792]. These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms. 2. Terminology 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 [KEYWORDS]. primary source RTP packet: The original RTP packet sent from the RTP sender for the first time. A lost primary source RTP packet may be repaired by some other RTP packets used in repair mechanisms like FEC or retransmission. 3. Post-Repair Loss Count Metrics Report Block This block reports the number of packets lost after applying repair mechanisms (e.g., FEC). It complements the RTCP XR metrics defined in [RFC 5725]. As noted in [RFC 5725], ambiguity may occur when comparing this metric with a pre-repair loss metric reported in an RTCP SR/RR, i.e., some packets were not repaired in the current RTCP interval, but they may be repaired later. Therefore, this block uses a begin sequence number and an end sequence number to explicitly indicate the actual sequence number range reported by this RTCP XR. Accordingly, only packets that have no further chance of being repaired and that have been repaired are included in this report block. Singh & Huang Standards Track PAGE 3 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 3.1. Report Block Structure The Post-Repair Loss Count Metrics Report Block has the following format: 0 1 2 3 4 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=33 | Reserved | Block length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Post-repair loss count | Repaired loss count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Block Type (BT): 8 bits A Post-Repair Loss Count Metrics Report Block is identified by the constant 33. Reserved: 8 bits These bits are reserved for future use. They MUST be set to zero by senders and ignored by receivers (see Section 4.2 of [RFC 6709]). Block length: 16 bits This field is in accordance with the definition in [RFC 3611]. In this report block, it MUST be set to 4. The block MUST be discarded if the block length is set to a different value. SSRC of source: 32 bits As defined in Section 4.1 of [RFC 3611]. begin_seq: 16 bits The first sequence number that this block reports on. It can remain fixed when calculating metrics over several RTCP reporting intervals. end_seq: 16 bits The last sequence number that this block reports on plus one. Singh & Huang Standards Track PAGE 4 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 Post-repair loss count: 16 bits Total number of packets finally lost after applying one or more loss-repair methods, e.g., FEC and/or retransmission, during the actual sequence number range indicated by begin_seq and end_seq. This metric MUST NOT count the lost packets for which repair might still be possible. Note that this metric MUST measure only primary source RTP packets. Repaired loss count: 16 bits Total number of packets fully repaired after applying one or more loss-repair methods, e.g., FEC and/or retransmission, during the actual sequence number range indicated by begin_seq and end_seq. Note that this metric MUST measure only primary source RTP packets. 3.2 Example Usage The metrics defined in this report block are all measured at the RTP receiver. However, the receiving endpoint can report the metrics in two different ways: 1) Cumulative report In this case, implementations may set begin_seq to the first packet in the RTP session, and it will remain fixed across all reports. Hence, the "Post-repair loss count" and "Repaired loss count", respectively, will correspond to "Cumulative post-repair loss count" and "Cumulative repaired loss count" in this case. These cumulative metrics when combined with the cumulative loss metrics reported in an RTCP RR (pre-repair) assist in calculating the "Still-to-be-repaired lost packets": Still-to-be-repaired lost packets = Cumulative number of packets lost - Cumulative post-repair loss count - Cumulative repaired loss count 2) Interval report Some implementations may align the begin_seq and end_seq number with the highest sequence numbers of consecutive RTCP RRs (RTCP interval). This is NOT RECOMMENDED as packets that are not yet repaired in this current RTCP interval and may be repaired in the subsequent intervals will not be reported. An interval report is illustrated in the following example: Singh & Huang Standards Track PAGE 5 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 Interval A: The extended highest sequence number received in RTCP RR is 20. Begin_seq is 10 and end_seq is 20. Interval B: The extended highest sequence number received in RTCP RR is 30. Begin_seq is 20 and end_seq is 30. If packets 17 and 19 are lost and not yet repaired in interval A and subsequently repaired in interval B, they will not be reported because their sequence numbers do not belong in interval B. Therefore, if implementations want these packets to be reported as repaired, they MUST NOT align the begin_seq and end_seq to the RTCP intervals. Alternatively, implementations may choose the begin_seq and end_seq numbers that cover several RTCP intervals. Additionally, the reported range of sequence numbers may overlap with the previous report blocks, so that the packets that were not yet repaired in one interval, but were subsequently repaired or deemed unrepairable, were reported in subsequent intervals. In this case, the "Cumulative number of packets lost" cannot be easily compared with the post-repair metrics. However, the sending endpoint can calculate the efficiency of the error resilience algorithm using the post-repair and repaired loss count, respectively. 4. SDP Signaling [RFC 3611] defines the use of SDP (Session Description Protocol) for signaling the use of RTCP XR blocks. However, XR blocks MAY be used without prior signaling (see Section 5 of [RFC 3611]). 4.1. SDP rtcp-xr-attrib Attribute Extension This session augments the SDP attribute "rtcp-xr" defined in Section 5.1 of [RFC 3611] by providing an additional value of "xr-format" to signal the use of the report block defined in this document. The ABNF [RFC 5234] syntax is as follows. xr-format =/ xr-prlr-block xr-prlr-block = "post-repair-loss-count" Singh & Huang Standards Track PAGE 6 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 4.2. Offer/Answer Usage When SDP is used in offer/answer context, the SDP Offer/Answer usage defined in [RFC 3611] for the unilateral "rtcp-xr" attribute parameters applies. For detailed usage of Offer/Answer for unilateral parameters, refer to Section 5.2 of [RFC 3611]. 5. Security Considerations This proposed RTCP XR block introduces no new security considerations beyond those described in [RFC 3611]. This block does not provide per-packet statistics, so the risk to confidentiality documented in Section 7, paragraph 3 of [RFC 3611] does not apply. An attacker may put incorrect information in the Post-Repair Loss Count reports, which will affect the performance of loss-repair mechanisms. Implementers should consider the guidance in [RFC 7202] for using appropriate security mechanisms, i.e., where security is a concern, the implementation should apply encryption and authentication to the report block. For example, this can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [RFC 3711]; an appropriate combination of the two profiles (an "SAVPF") is specified in [RFC 5124]. However, other mechanisms also exist (documented in [RFC 7201]) and might be more suitable. 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 [RFC 3611]. 6.1. New RTCP XR Block Type Value This document assigns the block type value 33 in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" to the "Post-Repair Loss Count Metrics Report Block". 6.2. New RTCP XR SDP Parameter This document also registers a new parameter "post-repair-loss-count" in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry". 6.3. Contact Information for Registrations The contact information for the registrations is: RAI Area Directors <rai-ads@ietf.org> Singh & Huang Standards Track PAGE 7 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 7. References 7.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC 2119, March 1997, <http://www.rfc-editor.org/info/RFC 2119>. [RFC 3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC 3550, July 2003, <http://www.rfc-editor.org/info/RFC 3550>. [RFC 3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC 3611, November 2003, <http://www.rfc-editor.org/info/RFC 3611>. [RFC 3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC 3711, March 2004, <http://www.rfc-editor.org/info/RFC 3711>. [RFC 5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC 5124, February 2008, <http://www.rfc-editor.org/info/RFC 5124>. [RFC 5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC 5234, January 2008, <http://www.rfc-editor.org/info/RFC 5234>. [RFC 5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, DOI 10.17487/RFC 5725, February 2010, <http://www.rfc-editor.org/info/RFC 5725>. Singh & Huang Standards Track PAGE 8 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 7.2. Informative References [RFC 4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC 4588, July 2006, <http://www.rfc-editor.org/info/RFC 4588>. [RFC 5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC 5109, December 2007, <http://www.rfc-editor.org/info/RFC 5109>. [RFC 6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC 6390, October 2011, <http://www.rfc-editor.org/info/RFC 6390>. [RFC 6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC 6709, September 2012, <http://www.rfc-editor.org/info/RFC 6709>. [RFC 6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, DOI 10.17487/RFC 6792, November 2012, <http://www.rfc-editor.org/info/RFC 6792>. [RFC 7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC 7201, April 2014, <http://www.rfc-editor.org/info/RFC 7201>. [RFC 7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC 7202, April 2014, <http://www.rfc-editor.org/info/RFC 7202>. Singh & Huang Standards Track PAGE 9 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 Appendix A. Metrics Represented Using the Template from RFC 6390 a. Post-Repair RTP Packet Loss Count Metric * Metric Name: Post-Repair RTP Packet Loss Count Metric. * Metric Description: Total number of RTP packets still lost after loss-repair methods are applied. * Method of Measurement or Calculation: See the "Post-repair loss count" definition in Section 3.1. It is directly measured and must be measured for the primary source RTP packets with no further chance of repair. * Units of Measurement: This metric is expressed as a 16-bit unsigned integer value giving the number of RTP packets. * Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream. * Measurement Timing: This metric relies on the sequence number interval to determine measurement timing. See the Cumulative and Interval reports defined in Section 3.2. * Use and Applications: These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms. See Section 1 for details. * Reporting Model: See RFC 3611. b. Repaired RTP Packet Loss Count Metric * Metric Name: Repaired RTP Packet Count Metric. * Metric Description: The number of RTP packets lost but repaired after applying loss-repair methods. * Method of Measurement or Calculation: See the "Repaired loss count" in Section 3.1. It is directly measured and must be measured for the primary source RTP packets with no further chance of repair. * Units of Measurement: This metric is expressed as a 16-bit unsigned integer value giving the number of RTP packets. * Measurement Point(s) with Potential Measurement Domain: It is measured at the receiving end of the RTP stream. Singh & Huang Standards Track PAGE 10 top

RFC 7509 Post-Repair Non-RLE Loss Count May 2015 * Measurement Timing: This metric relies on the sequence number interval to determine measurement timing. See the Cumulative and Interval reports defined in Section 3.2. * Use and Applications: These metrics are applicable to any RTP application, especially those that use loss-repair mechanisms. See Section 1 for details. * Reporting Model: See RFC 3611. Acknowledgments The authors would like to thank Roni Even, Colin Perkins, and Qin Wu for giving valuable comments and suggestions. Authors' Addresses Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China EMail: rachel.huang@huawei.com Varun Singh Aalto University School of Electrical Engineering Otakaari 5 A Espoo, FIN 02150 Finland EMail: varun@comnet.tkk.fi URI: http://www.netlab.tkk.fi/~varun/ Singh & Huang Standards Track PAGE 11 top

RFC TOTAL SIZE: 23350 bytes PUBLICATION DATE: Wednesday, May 13th, 2015 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 7509: The IETF Trust, Wednesday, May 13th, 2015
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement