idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2014) is 3700 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4588' is mentioned on line 83, but not defined == Missing Reference: 'RFC5109' is mentioned on line 84, but not defined == Missing Reference: 'RFC2119' is mentioned on line 128, but not defined == Missing Reference: 'RFC6709' is mentioned on line 174, but not defined == Missing Reference: 'RFC3711' is mentioned on line 246, but not defined == Missing Reference: 'RFC5124' is mentioned on line 248, but not defined == Unused Reference: 'KEYWORDS' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 307, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 3611 ** Downref: Normative reference to an Proposed Standard RFC: RFC 5725 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Huang 3 Intended Status: Standard Huawei 4 Expires: September 4, 2014 V. Singh 5 Aalto University 6 March 3, 2014 8 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair 9 Loss Count Metrics 10 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-02 12 Abstract 14 This document defines an RTP Control Protocol (RTCP) Extended Report 15 (XR) Block that allows reporting of post-repair loss count metrics 16 for a range of RTP applications. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 59 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 5 61 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6 62 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 6 65 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7 66 6.3 Contact Information for registrations . . . . . . . . . . . 7 67 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 70 8.2 Informative References . . . . . . . . . . . . . . . . . . 7 71 Appendix A. Metrics Represented Using the Template from RFC 6390 . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1 Introduction 76 RTCP SR/RR [RFC3550] contains some rough statistics about the data 77 received from the particular source indicated in that block. One of 78 them is the cumulative number of packet lost, which is called pre- 79 repair loss metric in this document. This metric conveys information 80 regarding the total number of RTP data packets that have been lost 81 since the beginning of the RTP session. However, this metric is 82 measured on media stream before any loss repair mechanism, e.g., 83 retransmission [RFC4588] and Forward Error Correction (FEC) 84 [RFC5109], is applied. Using a repair mechanism usually results in 85 recovering some or all of the lost packets. Hence, the sending 86 endpoint cannot assess the performance of the repair mechanism by 87 observing the change in fraction loss and the cumulative loss 88 statistics from RTCP SR/RR [RFC3550]. Consequently, [RFC5725] 89 specifies a post-repair loss Run-length Encoding (RLE) XR report 90 block to address this issue. The sending endpoint is able to infer 91 which packets were repaired from the RLE report block, but at the 92 cost of higher overhead. When applications use multiple XR blocks, 93 the endpoints may require more concise reporting to save bandwidth. 95 This document defines a new XR block type to augment those defined in 96 [RFC3611] and complement the report block defined in [RFC5725] for 97 use in a range of RTP application. This new block type reports the 98 number of primary source RTP packets that are still lost after 99 applying one or more loss repair mechanisms. When comparing this 100 metric with pre-repair loss metric of RTCP SR/RR, ambiguity may occur 101 as noted in [RFC5725]: Some packets will not be repaired in current 102 RTCP interval. Thus it is RECOMMENDED that this report block should 103 be generated for those source packets that have no further chance of 104 being repaired. But a potential ambiguity may result from sequence 105 number range inconsistent. The sequence number range reported by RTCP 106 SR/RR may contain some sequence numbers of packets for which repair 107 might still be possible. To address this issue, we use begin sequence 108 number and end sequence number to explicitly indicate the actual 109 sequence number range that this RTCP XR report block reports on. In 110 addition, another metric, repaired loss count, is also introduced in 111 this report block for calculating the pre-repair loss count during 112 the this range, so that the RTP sender or a third-party entity is 113 able to evaluate the effectiveness of the repair methods used by the 114 system. Note that the metrics in this report block MUST NOT be 115 directly compared with the pre-repair loss metric of [RFC3550]. 117 The metrics defined in this document belongs to the class of 118 transport-related metrics defined in [RFC6792]. And it is in 119 accordance with the guidelines in [RFC6390] and [RFC6792]. These 120 metrics are applicable to any RTP application, especially those that 121 use loss repair mechanisms. 123 2 Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 primary source RTP packet: The original RTP packet sent from the RTP 130 sender for the first time. A lost primary source RTP packet may be 131 repaired by some other RTP packets used in repair mechanisms like FEC 132 or retransmission. 134 3 Post-Repair Loss Count Metrics Report Block 136 This block reports the number of packets lost after applying repair 137 mechanisms to complement the RTCP XR metrics defined in [RFC5725]. 138 This packet may be stacked with other RTCP packets to form compound 139 RTCP packets and share the average reporting interval calculated by 140 the RTCP method described in [RFC3550]. These metrics defined in this 141 report block are all interval metrics with an explicit sequence 142 number range to indicate the measurement timing and the measurement 143 of them is made at the RTP receiver. 145 The post-repair loss count metrics report block has the following 146 format: 148 0 1 2 3 4 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | BT=PRLR | Reserved | block length = 4 | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | SSRC of Source | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | begin_seq | end_seq | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | unrepaired loss count | repaired loss count | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: Format for the Post-Repair Loss Count Metrics Report 161 Block 163 Block Type (BT): 8 bits 165 A Post-Repair Loss Count Metrics Report Block is identified by the 166 constant PRLR. 168 [Note to RFC Editor: Please replace PRLR with the IANA provided 169 RTCP XR block type for this block.] 171 Reserved: 8 bits 173 These bits are reserved for future use. They MUST be set to zero 174 by senders and ignored by receivers (see [RFC6709], Section 4.2). 176 block length: 16 bits 178 This field is in accordance with the definition in [RFC3611]. In 179 this report block, it MUST be set to 4. The block MUST be 180 discarded if the block length is set to a different value. 182 SSRC of source: 32 bits 184 As defined in Section 4.1 of [RFC3611]. 186 begin_seq: 16 bits 188 The first sequence number that this block reports on. 190 end_seq: 16 bits 192 The last sequence number that this block reports on plus one. 194 unrepaired loss count: 16 bits 196 Total number of packets finally lost after one or more loss-repair 197 methods, e.g., FEC and/or retransmission, during this interval. 198 This metric MUST NOT count the lost packets for which repair might 199 still be possible. Note that this metric must be measured in the 200 primary source RTP packets. 202 repaired loss count: 16 bits 204 Total number of packets fully repaired after one or more loss- 205 repair methods, e.g., FEC and/or retransmission, during this 206 interval. Note that this metric must be measured in the primary 207 source RTP packets. 209 4 SDP Signaling 211 [RFC3611] defines the use of SDP (Session Description Protocol) for 212 signaling the use of RTCP XR blocks. However XR blocks MAY be used 213 without prior signaling (see section 5 of [RFC3611]). 215 4.1 SDP rtcp-xr-attrib Attribute Extension 217 This session augments the SDP attribute "rtcp-xr" defined in Section 218 5.1 of [RFC3611] by providing an additional value of "xr-format" to 219 signal the use of the report block defined in this document. 221 xr-format =/ xr-prlr-block 223 xr-prlr-block = "post-repair-loss-count" 225 4.2 Offer/Answer Usage 227 When SDP is used in offer-answer context, the SDP Offer/Answer usage 228 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 229 applies. For detailed usage of Offer/Answer for unilateral 230 parameter, refer to section 5.2 of [RFC3611]. 232 5 Security Considerations 234 It is believed that this RTCP XR block introduces no new security 235 considerations beyond those described in [RFC3611]. This block does 236 not provide per-packet statistics, so the risk to confidentially 237 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 239 An attacker may put incorrect information in the Post-Repair Loss 240 Count reports, which will be affect the performance of loss repair 241 mechanisms. Implementers should consider the guidance in [I-D.ietf- 242 avtcore-srtp-not-mandatory] for using appropriate security 243 mechanisms, i.e., where security is a concern, the implementation 244 should apply encryption and authentication to the report block. For 245 example, this can be achieved by using the AVPF profile together with 246 the Secure RTP profile as defined in [RFC3711]; an appropriate 247 combination of the two profiles (an "SAVPF") is specified in 248 [RFC5124]. However, other mechanisms also exist (documented in [I- 249 D.ietf-avtcore-rtp-security-options]) and might be more suitable. 251 6 IANA Considerations 253 New block types for RTCP XR are subject to IANA registration. For 254 general guidelines on IANA considerations for RTCP XR, refer to 255 [RFC3611]. 257 6.1 New RTCP XR Block Type value 259 This document assigns the block type value PRLR in the IANA "RTP 260 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 261 the "Post-Repair Loss Count Metrics Report Block". 263 [Note to RFC Editor: please replace PRLR with the IANA provided RTCP 264 XR block type for this block.] 266 6.2 New RTCP XR SDP Parameter 268 This document also registers a new parameter "post-repair-loss-count" 269 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 270 Description Protocol (SDP) Parameters Registry". 272 6.3 Contact Information for registrations 274 The following contact information is provided for all registrations 275 in this document: 277 Rachel Huang (rachel.huang@huawei.com) 279 101 Software Avenue, Yuhua District 280 Nanjing, Jiangsu 210012 281 China 283 7 Acknowledgments 285 The author would like to thank Roni Even and Colin Perkins for giving 286 valuable comments and suggestions. 288 8 References 290 8.1 Normative References 292 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 296 Jacobson, "RTP: A Transport Protocol for Real-Time 297 Applications", STD 64, RFC 3550, July 2003. 299 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 300 "RTP Control Protocol Extended Reports (RTCP XR)", 301 RFC 3611, November 2003. 303 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 304 Report Block Type for RTP Control Protocol (RTCP) Extended 305 Reports (XRs)", RFC 5725, February 2010. 307 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 308 Description Protocol", RFC 4566, July 2006. 310 8.2 Informative References 312 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 313 Performance Metric Development", BCP 170, RFC 6390, 314 October 2011. 316 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 317 RTP Monitoring Framework", RFC 6792, November 2012. 319 Appendix A. Metrics Represented Using the Template from RFC 6390 321 a. Unrepaired RTP Packet Loss Count Metric 323 * Metric Name: Unrepaired RTP Packet Loss Count Metric 325 * Metric Description: Total number of RTP packets still lost after 326 loss repair methods are applied 328 * Method of Measurement or Calculation: It must be measured for 329 the primary source RTP packets with no further chance of repair 331 * Units of Measurement: See section 3, unrepaired loss count 332 definition 334 * Measurement Point(s) with Potential Measurement Domain: See 335 section 3, 1st paragraph 337 * Measurement Timing: See Section 3, 1st paragraph, for 338 measurement timing 340 * Use and Applications: See Section 1 342 * Reporting Model: See RFC3611 344 b. Repaired RTP Packet Loss Count Metric 346 * Metric Name: Repaired RTP Packet Count Metric 348 * Metric Description: The number of RTP packets lost but repaired 349 after applying loss repair methods 351 * Method of Measurement or Calculation: It must be measured for 352 the primary source RTP packets with no further chance of repair 354 * Units of Measurement: See section 3, repaired loss count 355 definition 357 * Measurement Point(s) with Potential Measurement Domain: See 358 section 3, 1st paragraph 359 * Measurement Timing: See Section 3, 1st paragraph, for 360 measurement timing 362 * Use and Applications: See Section 1 364 * Reporting Model: See RFC3611 366 Authors' Addresses 368 Rachel Huang 369 Huawei 370 101 Software Avenue, Yuhua District 371 Nanjing 210012 372 China 374 EMail: rachel.huang@huawei.com 376 Varun Singh 377 Aalto University 378 School of Electrical Engineering 379 Otakaari 5 A 380 Espoo, FIN 02150 381 Finland 383 Email: varun@comnet.tkk.fi 384 URI: http://www.netlab.tkk.fi/~varun/