idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-00.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 (December 9, 2013) is 3788 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 166, but not defined == Missing Reference: 'RFC3711' is mentioned on line 240, but not defined == Missing Reference: 'RFC5124' is mentioned on line 242, but not defined == Unused Reference: 'KEYWORDS' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 301, 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: June 12, 2014 V. Singh 5 Aalto University 6 December 9, 2013 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-00 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) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 8 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. Consequently, [RFC5725] specifies a post-repair loss Run- 89 length Encoding (RLE) XR report block to address this issue. The 90 sending endpoint is able to infer which packets were repaired from 91 the RLE report block, but at the cost of higher overhead. When 92 applications use multiple XR blocks, the endpoints require more 93 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 RTP packets on the primary source stream that are still 99 lost after applying one or more loss repair mechanisms. When 100 comparing this metric with pre-repair loss metric of RTCP SR/RR, it 101 may bring ambiguity as noted in [RFC5725]: Some packets will not be 102 repaired in current RTCP interval. So in [RFC5725] it is suggested to 103 delay report block to wait for packets to be repaired. However, it is 104 not wise to delay this report block arbitrarily until those packets 105 have been fully repaired. Thus it is RECOMMENDED that this report 106 block should be generated for those source packets that have no 107 further chance of being repaired. But a potential ambiguity may 108 result from sequence number range inconsistent. To address this 109 issue, we use begin sequence number and end sequence number to 110 explicitly indicate the actual sequence number range that the report 111 block reports on. In addition, another metric, repaired loss count, 112 is also introduced in this report block for calculating the pre- 113 repair loss count during the this range. Note that the metrics in 114 this report block MUST NOT be directly compared with the pre-repair 115 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 3 Post-Repair Loss Count Metrics Report Block 131 This block describes the residual number of packets lost after 132 applying repair mechanisms. The report block is complementary to the 133 RTCP XR metrics defined in [RFC5725] as it uses a non-RLE format. 135 The post-repair loss count metrics report block has the following 136 format: 138 0 1 2 3 4 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | BT=PRLR | Reserved | block length = 4 | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | SSRC of Source | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | begin_seq | end_seq | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | unrepaired loss count | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | repaired loss count | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: Format for the Post-Repair Loss Count Metrics Report 153 Block 155 Block Type (BT): 8 bits 157 A Post-Repair Loss Count Metrics Report Block is identified by the 158 constant PRLR. 160 [Note to RFC Editor: Please replace PRLR with the IANA provided 161 RTCP XR block type for this block.] 163 Reserved: 8 bits 165 These bits are reserved for future use. They MUST be set to zero 166 by senders and ignored by receivers (see [RFC6709], Section 4.2). 168 block length: 16 bits 169 This field is in accordance with the definition in [RFC3611]. In 170 this report block, it MUST be set to 4. The block MUST be 171 discarded if the block length is set to a different value. 173 SSRC of source: 32 bits 175 As defined in Section 4.1 of [RFC3611]. 177 begin_seq: 16 bits 179 The sequence number of the first packet in the session or the 180 sequence number of the first packet fully repaired that this block 181 reports on. 183 end_seq: 16 bits 185 The sequence number of the last packet fully repaired that this 186 block reports on plus one. 188 unrepaired loss count: 32 bits 190 Total number of packets finally lost after one or more loss-repair 191 methods, e.g., FEC and/or retransmission, during this interval. 192 This metric MUST NOT count the lost packets that haven't finished 193 repairing. Note that this metric must be measured in the primary 194 source stream. 196 repaired loss count: 32 bits 198 Total number of packets fully repaired after one or more loss- 199 repair methods, e.g., FEC and/or retransmission, during this 200 interval. Note that this metric must be measured in the primary 201 source stream. 203 4 SDP Signaling 205 [RFC3611] defines the use of SDP (Session Description Protocol) for 206 signaling the use of RTCP XR blocks. However XR blocks MAY be used 207 without prior signaling (see section 5 of [RFC3611]). 209 4.1 SDP rtcp-xr-attrib Attribute Extension 211 This session augments the SDP attribute "rtcp-xr" defined in Section 212 5.1 of [RFC3611] by providing an additional value of "xr-format" to 213 signal the use of the report block defined in this document. 215 xr-format =/ xr-prlr-block 217 xr-prlr-block = "post-repair-loss-count" 219 4.2 Offer/Answer Usage 221 When SDP is used in offer-answer context, the SDP Offer/Answer usage 222 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 223 applies. For detailed usage of Offer/Answer for unilateral 224 parameter, refer to section 5.2 of [RFC3611]. 226 5 Security Considerations 228 It is believed that this RTCP XR block introduces no new security 229 considerations beyond those described in [RFC3611]. This block does 230 not provide per-packet statistics, so the risk to confidentially 231 documented in Section 7, paragraph 3 of [RFC3611] does not apply. 233 An attacker may put incorrect information in the Post-Repair Loss 234 Count reports, which will be affect the performance of loss repair 235 mechanisms. Implementers should consider the guidance in [I-D.ietf- 236 avtcore-srtp-not-mandatory] for using appropriate security 237 mechanisms, i.e., where security is a concern, the implementation 238 should apply encryption and authentication to the report block. For 239 example, this can be achieved by using the AVPF profile together with 240 the Secure RTP profile as defined in [RFC3711]; an appropriate 241 combination of the two profiles (an "SAVPF") is specified in 242 [RFC5124]. However, other mechanisms also exist (documented in [I- 243 D.ietf-avtcore-rtp-security-options]) and might be more suitable. 245 6 IANA Considerations 247 New block types for RTCP XR are subject to IANA registration. For 248 general guidelines on IANA considerations for RTCP XR, refer to 249 [RFC3611]. 251 6.1 New RTCP XR Block Type value 253 This document assigns the block type value PRLR in the IANA "RTP 254 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 255 the "Post-Repair Loss Count Metrics Report Block". 257 [Note to RFC Editor: please replace PRLR with the IANA provided RTCP 258 XR block type for this block.] 260 6.2 New RTCP XR SDP Parameter 262 This document also registers a new parameter "post-repair-loss-count" 263 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 264 Description Protocol (SDP) Parameters Registry". 266 6.3 Contact Information for registrations 268 The following contact information is provided for all registrations 269 in this document: 271 Rachel Huang (rachel.huang@huawei.com) 273 101 Software Avenue, Yuhua District 274 Nanjing, Jiangsu 210012 275 China 277 7 Acknowledgments 279 The author would like to thank Roni Even for giving valuable comments 280 and suggestions. 282 8 References 284 8.1 Normative References 286 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 290 Jacobson, "RTP: A Transport Protocol for Real-Time 291 Applications", STD 64, RFC 3550, July 2003. 293 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 294 "RTP Control Protocol Extended Reports (RTCP XR)", 295 RFC 3611, November 2003. 297 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 298 Report Block Type for RTP Control Protocol (RTCP) Extended 299 Reports (XRs)", RFC 5725, February 2010. 301 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 302 Description Protocol", RFC 4566, July 2006. 304 8.2 Informative References 306 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 307 Performance Metric Development", BCP 170, RFC 6390, 308 October 2011. 310 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 311 RTP Monitoring Framework", RFC 6792, November 2012. 313 Appendix A. Metrics Represented Using the Template from RFC 6390 315 a. Unrepaired RTP Packet Loss Count Metric 317 * Metric Name: Unrepaired RTP Packet Loss Count Metric 319 * Metric Description: Total number of RTP packets still lost after 320 loss repair methods are applied 322 * Method of Measurement or Calculation: It must be measured in the 323 primary source stream. It must be measured for the packets that 324 have no further chance of being repaired. 326 * Units of Measurement: See section 3, unrepaired loss count 327 definition. 329 * Measurement Point(s) with Potential Measurement Domain: See 330 section 3, 1st paragraph. 332 * Measurement Timing: See Section 4 for measurement timing. 334 * Use and Applications: See Section 1 336 * Reporting Model: See RFC3611. 338 b. Repaired RTP Packet Loss Count Metric 340 * Metric Name: Repaired RTP Packet Count Metric 341 * Metric Description: The number of RTP packets lost but repaired 342 after applying loss repair methods. 344 * Method of Measurement or Calculation: It must be measured in the 345 primary source stream. 347 * Units of Measurement: See section 3, repaired loss count 348 definition. 350 * Measurement Point(s) with Potential Measurement Domain: See 351 section 3, 1st paragraph. 353 * Measurement Timing: See Section 4 for measurement timing. 355 * Use and Applications: See Section 1 357 * Reporting Model: See RFC3611. 359 Authors' Addresses 361 Rachel Huang 362 Huawei 363 101 Software Avenue, Yuhua District 364 Nanjing 210012 365 China 367 EMail: rachel.huang@huawei.com 369 Varun Singh 370 Aalto University 371 School of Electrical Engineering 372 Otakaari 5 A 373 Espoo, FIN 02150 374 Finland 376 Email: varun@comnet.tkk.fi 377 URI: http://www.netlab.tkk.fi/~varun/