RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7509.
|
|
---|---|---|---|
Authors | Rachel Huang , Varun Singh | ||
Last updated | 2014-12-31 (Latest revision 2014-12-11) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
by Tom Taylor
Ready w/issues
OPSDIR Last Call review
by Tina Tsou
Has issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Dan Romascanu | ||
Shepherd write-up | Show Last changed 2014-12-02 | ||
IESG | IESG state | Became RFC 7509 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date |
(None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Alissa Cooper | ||
Send notices to | xrblock-chairs@tools.ietf.org, draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org, xrblock@ietf.org, "Dan Romascanu" <dromasca@avaya.com> | ||
IANA | IANA review state | IANA - Not OK |
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
INTERNET-DRAFT R. Huang Intended Status: Standards Track Huawei Expires: June 15, 2015 V. Singh Aalto University December 12, 2014 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07 Abstract This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows reporting of post-repair loss count metrics for a range of RTP applications. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 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 <Singh&Huang> Expires June 15, 2015 [Page 1] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 (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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 6 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7 6.3 Contact Information for registrations . . . . . . . . . . . 7 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 8.2 Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Metrics Represented Using the Template from RFC 6390 . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 <Singh&Huang> Expires June 15, 2015 [Page 2] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 1 Introduction RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contains 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 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 media stream before any loss repair mechanism, e.g., retransmission [RFC4588] and Forward Error Correction (FEC) [RFC5109], is applied. Using a repair mechanism usually results in recovering some or all of the lost packets. Hence, the sending endpoint cannot assess the performance of the repair mechanism by observing the change in fraction loss and the cumulative loss statistics from RTCP SR/RR [RFC3550]. Consequently, [RFC5725] 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 at the cost of higher overhead. 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 [RFC3611] and complement the report block defined in [RFC5725] for use in a range of RTP applications. This new block type reports the number of primary source RTP packets that are still lost after applying one or more loss repair mechanisms. The metrics defined in this document are packet level rather than slice/picture level, which means the partial recovery of a packet will not be regarded as a repaired packet. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre- repair loss count during the 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 belong to the class of transport-related metrics defined in [RFC6792] and are specified in accordance with the guidelines in [RFC6390] and [RFC6792]. 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 <Singh&Huang> Expires June 15, 2015 [Page 3] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 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 to complement the RTCP XR metrics defined in [RFC5725]. This packet may be stacked with other RTCP packets to form compound RTCP packets and share the average reporting interval calculated by the RTCP method described in [RFC3550]. When comparing this metric with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as noted in [RFC5725]: Some packets will not be repaired in the current RTCP interval. Thus it is RECOMMENDED that this report block should be generated only for those source packets that have no further chance of being repaired and not for any other packets. This block needs to specify its own measurement period to avoid ambiguity in calculating the post-repair loss count. The sequence number range reported by RTCP SR/RR may contain some sequence numbers of packets for which repair might still be possible. To avoid the ambiguity, we use begin sequence number and end sequence number to explicitly indicate the actual sequence number range that this RTCP XR report block reports on as the measurement timing. These metrics defined in this report block are all interval metrics and the measurement of them is made at the RTP receiver. The relationship between the metrics in this report block and the pre-repair loss metric of RTCP XR could be expressed in the following formula: cumulative number of packets lost = unrepaired loss count + repaired loss count + to be repaired lost packet "cumulative number of packets lost" is the metric from RTCP SR/RR. "unrepaired loss count" and "repaired loss count" are the metrics defined in this draft. 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=PRLR | Reserved | block length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <Singh&Huang> Expires June 15, 2015 [Page 4] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 | unrepaired loss count | repaired loss count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format for the Post-Repair Loss Count Metrics Report Block Block Type (BT): 8 bits A Post-Repair Loss Count Metrics Report Block is identified by the constant PRLR. [Note to RFC Editor: Please replace PRLR with the IANA provided RTCP XR block type for this block.] Reserved: 8 bits These bits are reserved for future use. They MUST be set to zero by senders and ignored by receivers (see [RFC6709], Section 4.2). block length: 16 bits This field is in accordance with the definition in [RFC3611]. 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 [RFC3611]. begin_seq: 16 bits The first sequence number that this block reports on. end_seq: 16 bits The last sequence number that this block reports on plus one. unrepaired loss count: 16 bits Total number of packets finally lost after one or more loss-repair methods, e.g., FEC and/or retransmission, during this interval. 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 one or more loss- <Singh&Huang> Expires June 15, 2015 [Page 5] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 repair methods, e.g., FEC and/or retransmission, during this interval. Note that this metric MUST measure only primary source RTP packets. <Singh&Huang> Expires June 15, 2015 [Page 6] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 4 SDP Signaling [RFC3611] 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 [RFC3611]). 4.1 SDP rtcp-xr-attrib Attribute Extension This session augments the SDP attribute "rtcp-xr" defined in Section 5.1 of [RFC3611] by providing an additional value of "xr-format" to signal the use of the report block defined in this document. xr-format =/ xr-prlr-block xr-prlr-block = "post-repair-loss-count" 4.2 Offer/Answer Usage When SDP is used in offer-answer context, the SDP Offer/Answer usage defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters applies. For detailed usage of Offer/Answer for unilateral parameters, refer to section 5.2 of [RFC3611]. 5 Security Considerations It is believed that this RTCP XR block introduces no new security considerations beyond those described in [RFC3611]. This block does not provide per-packet statistics, so the risk to confidentially documented in Section 7, paragraph 3 of [RFC3611] does not apply. An attacker may put incorrect information in the Post-Repair Loss Count reports, which will be affect the performance of loss repair mechanisms. Implementers should consider the guidance in [RFC7202] 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 [RFC3711]; an appropriate combination of the two profiles (an "SAVPF") is specified in [RFC5124]. However, other mechanisms also exist (documented in [RFC7201]) 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 [RFC3611]. 6.1 New RTCP XR Block Type value <Singh&Huang> Expires June 15, 2015 [Page 7] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 This document assigns the block type value PRLR in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" to the "Post-Repair Loss Count Metrics Report Block". [Note to RFC Editor: please replace PRLR with the IANA provided RTCP XR block type for this 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 registration is : RAI Area Directors <rai-ads@tools.ietf.org> 7 Acknowledgments The author would like to thank Roni Even, Colin Perkins, and Qin Wu for giving valuable comments and suggestions. 8 References 8.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error <Singh&Huang> Expires June 15, 2015 [Page 8] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 Correction", RFC 5109, December 2007. [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008. [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, February 2010. 8.2 Informative References [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011. [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012. [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, November 2012. [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP Sessions", RFC 7201, April 2014. [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, April 2014. Appendix A. Metrics Represented Using the Template from RFC 6390 a. Unrepaired RTP Packet Loss Count Metric * Metric Name: Unrepaired 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 section 3, Unrepaired RTP Packet Loss Count Metric definition. 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. * Measurement Point(s) with Potential Measurement Domain: It is <Singh&Huang> Expires June 15, 2015 [Page 9] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 measured at the receiving end of the RTP stream. * Measurement Timing: This metric relies on the sequence number interval to determine measurement timing. See Section 3, 1st paragraph, for details. * 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 RFC3611. 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 section 3, Repaired RTP Packet Loss Count Metric definition. 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. * 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 Section 3, 1st paragraph, for details. * 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 RFC3611. Authors' Addresses Rachel Huang Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China <Singh&Huang> Expires June 15, 2015 [Page 10] INTERNET DRAFT Post-Repair Non-RLE loss Count December 12, 2014 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> Expires June 15, 2015 [Page 11]