idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11.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 == Line 228 has weird spacing: '...ctively will ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 19, 2015) is 3347 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 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: Standards Track Huawei 4 Expires: August 23, 2015 V. Singh 5 Aalto University 6 February 19, 2015 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-11 12 Abstract 14 This document defines an RTP Control Protocol (RTCP) Extended Report 15 (XR) Block that allows reporting of post-repair loss count metric for 16 a range of RTP applications. In addition, another metric, repaired 17 loss count, is also introduced in this report block for calculating 18 the pre-repair loss count when needed so that the RTP sender or a 19 third-party entity is able to evaluate the effectiveness of the 20 repair methods used by the system. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 63 3.1 Report Block Structure . . . . . . . . . . . . . . . . . . 4 64 3.2 Example Usage . . . . . . . . . . . . . . . . . . . . . . . 5 65 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 7 67 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 7 68 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7 71 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 8 72 6.3 Contact Information for registrations . . . . . . . . . . . 8 73 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 76 8.2 Informative References . . . . . . . . . . . . . . . . . . 9 77 Appendix A. Metrics Represented Using the Template from RFC 6390 . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1 Introduction 82 RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contain some 83 rough statistics about the data received from the particular source 84 indicated in that block. One of them is the cumulative number of 85 packets lost, which is called pre-repair loss metric in this 86 document. This metric conveys information regarding the total number 87 of RTP data packets that have been lost since the beginning of the 88 RTP session. 90 However, this metric is measured on media stream before any loss 91 repair mechanism, e.g., retransmission [RFC4588] or Forward Error 92 Correction (FEC) [RFC5109], is applied. Using a repair mechanism 93 usually results in recovering some or all of the lost packets. Hence, 94 the sending endpoint cannot assess the performance of the repair 95 mechanism by observing the change in fraction loss and the cumulative 96 loss statistics from RTCP SR/RR [RFC3550]. 98 Consequently, [RFC5725] specifies a post-repair loss Run-length 99 Encoding (RLE) XR report block to address this issue. The sending 100 endpoint is able to infer which packets were repaired from the RLE 101 report block, but the reporting overhead for the packet-by-packet 102 report block is higher compared to other report blocks. 104 When applications use multiple XR blocks, the endpoints may require 105 more concise reporting to save bandwidth. This document defines a new 106 XR block type to augment those defined in [RFC3611] and complement 107 the report block defined in [RFC5725] for use in a range of RTP 108 applications. This new block type reports the post-repair loss count 109 metric which records the number of primary source RTP packets that 110 are still lost after applying one or more loss repair mechanisms. In 111 addition, another metric, repaired loss count, is also introduced in 112 this report block for calculating the pre-repair loss count during 113 this range, so that the RTP sender or a third-party entity is able to 114 evaluate the effectiveness of the repair methods used by the system. 115 The metrics defined in this document are packet level rather than 116 slice/picture level, which means the partial recovery of a packet 117 will not be regarded as a repaired packet. 119 The metrics defined in this document belong to the class of 120 transport-related metrics defined in [RFC6792] and are specified in 121 accordance with the guidelines in [RFC6390] and [RFC6792]. These 122 metrics are applicable to any RTP application, especially those that 123 use loss repair mechanisms. 125 2 Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [KEYWORDS]. 131 primary source RTP packet: The original RTP packet sent from the RTP 132 sender for the first time. A lost primary source RTP packet may be 133 repaired by some other RTP packets used in repair mechanisms like FEC 134 or retransmission. 136 3 Post-Repair Loss Count Metrics Report Block 138 This block reports the number of packets lost after applying repair 139 mechanisms (e.g., FEC). It complements the RTCP XR metrics defined 140 in [RFC5725]. As noted in [RFC5725], ambiguity may occur when 141 comparing this metric with pre-repair loss metric reported in an RTCP 142 SR/RR, i.e., some packets were not repaired in the current RTCP 143 interval, but they may be repaired later. Therefore, this block uses 144 a begin sequence number and an end sequence number to explicitly 145 indicate the actual sequence number range reported by this RTCP XR. 146 Accordingly, only packets that have no further chance of being 147 repaired and that have been repaired are included in this report 148 block. 150 3.1 Report Block Structure 152 The post-repair loss count metrics report block has the following 153 format: 155 0 1 2 3 4 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | BT=PRLR | Reserved | block length = 4 | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | SSRC of Source | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | begin_seq | end_seq | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | post-repair loss count | repaired loss count | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Block Type (BT): 8 bits 169 A Post-Repair Loss Count Metrics Report Block is identified by the 170 constant PRLR. 172 [Note to RFC Editor: Please replace PRLR with the IANA provided 173 RTCP XR block type for this block.] 175 Reserved: 8 bits 177 These bits are reserved for future use. They MUST be set to zero 178 by senders and ignored by receivers (see [RFC6709], Section 4.2). 180 block length: 16 bits 182 This field is in accordance with the definition in [RFC3611]. In 183 this report block, it MUST be set to 4. The block MUST be 184 discarded if the block length is set to a different value. 186 SSRC of source: 32 bits 188 As defined in Section 4.1 of [RFC3611]. 190 begin_seq: 16 bits 192 The first sequence number that this block reports on. It can 193 remain fixed when calculating metrics over several RTCP reporting 194 intervals. 196 end_seq: 16 bits 198 The last sequence number that this block reports on plus one. 200 post-repair loss count: 16 bits 202 Total number of packets finally lost after applying one or more 203 loss-repair methods, e.g., FEC and/or retransmission, during the 204 actual sequence number range indicated by begin_seq and end_seq. 205 This metric MUST NOT count the lost packets for which repair might 206 still be possible. Note that this metric MUST measure only primary 207 source RTP packets. 209 repaired loss count: 16 bits 211 Total number of packets fully repaired after applying one or more 212 loss-repair methods, e.g., FEC and/or retransmission, during the 213 actual sequence number range indicated by begin_seq and end_seq. 214 Note that this metric MUST measure only primary source RTP 215 packets. 217 3.2 Example Usage 219 The metrics defined in this report block are all measured at the RTP 220 receiver. However, the receiving endpoint can report the metrics in 221 two different ways: 223 1. Cumulative report 225 In this case, implementations may set begin_seq to the first packet 226 in the RTP session and it will remain fixed across all reports. 227 Hence, the "post-repair loss count" and "repaired loss count", 228 respectively will correspond to "cumulative post-repair loss count" 229 and "cumulative repaired loss count" in this case. These cumulative 230 metrics when combined with the cumulative loss metrics reported in an 231 RTCP RR (pre-repair) assists in calculating the still to be repaired 232 lost packets: 234 still to be repaired lost packet = cumulative number of packets 235 lost - cumulative post-repair loss count - cumulative repaired 236 loss count 238 2. Interval report 240 Some implementations may align the begin_seq and end_seq number with 241 the highest sequence numbers of consecutive RTCP RRs (RTCP interval). 242 This is NOT RECOMMENDED as packets that are not yet repaired in this 243 current RTCP interval and may be repaired in the subsequent intervals 244 will not be reported. It is illustrated in the following example: 246 Interval A: The extended highest sequence number received in RTCP 247 RR is 20. Begin_seq is 10 and end_seq is 20. 249 Interval B: The extended highest sequence number received in RTCP 250 RR is 30. Begin_seq is 20 and end_seq is 30. 252 If packets 17 and 19 are lost and not yet repaired in interval A and 253 subsequently repaired in interval B, they will not then be reported 254 because their sequence numbers do not belong in the interval B. 255 Therefore, if implementations want these packets to be reported as 256 repaired, they MUST NOT align the begin_seq and end_seq to the RTCP 257 intervals. 259 Alternatively, implementations may choose the begin_seq and end_seq 260 numbers that cover several RTCP intervals. Additionally, the reported 261 range of sequence numbers may overlap with the previous report 262 blocks, so that the packets that were not yet repaired in one 263 interval but were subsequently repaired or deemed unrepairable were 264 reported in subsequent intervals. 266 In this case, the "cumulative number of packets lost" cannot be 267 easily compared with the post-repair metrics. However, the sending 268 endpoint can calculate the efficiency of the error resilience 269 algorithm using the post-repair and repaired lost count, 270 respectively. 272 4 SDP Signaling 274 [RFC3611] defines the use of SDP (Session Description Protocol) for 275 signaling the use of RTCP XR blocks. However XR blocks MAY be used 276 without prior signaling (see section 5 of [RFC3611]). 278 4.1 SDP rtcp-xr-attrib Attribute Extension 280 This session augments the SDP attribute "rtcp-xr" defined in Section 281 5.1 of [RFC3611] by providing an additional value of "xr-format" to 282 signal the use of the report block defined in this document. 284 xr-format =/ xr-prlr-block 286 xr-prlr-block = "post-repair-loss-count" 288 4.2 Offer/Answer Usage 290 When SDP is used in offer-answer context, the SDP Offer/Answer usage 291 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 292 applies. For detailed usage of Offer/Answer for unilateral 293 parameters, refer to section 5.2 of [RFC3611]. 295 5 Security Considerations 297 This proposed RTCP XR block introduces no new security considerations 298 beyond those described in [RFC3611]. This block does not provide per- 299 packet statistics, so the risk to confidentiality documented in 300 Section 7, paragraph 3 of [RFC3611] does not apply. 302 An attacker may put incorrect information in the Post-Repair Loss 303 Count reports, which will be affect the performance of loss repair 304 mechanisms. Implementers should consider the guidance in [RFC7202] 305 for using appropriate security mechanisms, i.e., where security is a 306 concern, the implementation should apply encryption and 307 authentication to the report block. For example, this can be achieved 308 by using the AVPF profile together with the Secure RTP profile as 309 defined in [RFC3711]; an appropriate combination of the two profiles 310 (an "SAVPF") is specified in [RFC5124]. However, other mechanisms 311 also exist (documented in [RFC7201]) and might be more suitable. 313 6 IANA Considerations 315 New block types for RTCP XR are subject to IANA registration. For 316 general guidelines on IANA considerations for RTCP XR, refer to 317 [RFC3611]. 319 6.1 New RTCP XR Block Type value 320 This document assigns the block type value PRLR in the IANA "RTP 321 Control Protocol Extended Reports (RTCP XR) Block Type Registry" to 322 the "Post-Repair Loss Count Metrics Report Block". 324 [Note to RFC Editor: please replace PRLR with the IANA provided RTCP 325 XR block type for this block.] 327 6.2 New RTCP XR SDP Parameter 329 This document also registers a new parameter "post-repair-loss-count" 330 in the "RTP Control Protocol Extended Reports (RTCP XR) Session 331 Description Protocol (SDP) Parameters Registry". 333 6.3 Contact Information for registrations 335 The contact information for the registration is : 337 RAI Area Directors 339 7 Acknowledgments 341 The author would like to thank Roni Even, Colin Perkins, and Qin Wu 342 for giving valuable comments and suggestions. 344 8 References 346 8.1 Normative References 348 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 352 Jacobson, "RTP: A Transport Protocol for Real-Time 353 Applications", STD 64, RFC 3550, July 2003. 355 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 356 "RTP Control Protocol Extended Reports (RTCP XR)", 357 RFC 3611, November 2003. 359 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 360 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 361 RFC 3711, March 2004. 363 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 364 Real-time Transport Control Protocol (RTCP)-Based Feedback 365 (RTP/SAVPF)", RFC 5124, February 2008. 367 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 368 Report Block Type for RTP Control Protocol (RTCP) Extended 369 Reports (XRs)", RFC 5725, February 2010. 371 8.2 Informative References 373 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 374 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 375 July 2006. 377 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 378 Correction", RFC 5109, December 2007. 380 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 381 Performance Metric Development", BCP 170, RFC 6390, 382 October 2011. 384 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 385 Considerations for Protocol Extensions", RFC6709, 386 September 2012. 388 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 389 RTP Monitoring Framework", RFC 6792, November 2012. 391 [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP 392 Sessions", RFC 7201, April 2014. 394 [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP 395 Framework: Why RTP Does Not Mandate a Single Media 396 Security Solution", RFC 7202, April 2014. 398 Appendix A. Metrics Represented Using the Template from RFC 6390 400 a. Post-Repair RTP Packet Loss Count Metric 402 * Metric Name: Post-Repair RTP Packet Loss Count Metric. 404 * Metric Description: Total number of RTP packets still lost after 405 loss repair methods are applied 407 * Method of Measurement or Calculation: See section 3.1, Post- 408 Repair RTP Packet Loss Count Metric definition. It is directly 409 measured and must be measured for the primary source RTP packets 410 with no further chance of repair. 412 * Units of Measurement: This metric is expressed as a 16-bit 413 unsigned integer value giving the number of RTP packets. 415 * Measurement Point(s) with Potential Measurement Domain: It is 416 measured at the receiving end of the RTP stream. 418 * Measurement Timing: This metric relies on the sequence number 419 interval to determine measurement timing. See Section 3, 3rd 420 paragraph, for details. 422 * Use and Applications: These metrics are applicable to any RTP 423 application, especially those that use loss repair mechanisms. See 424 Section 1 for details. 426 * Reporting Model: See RFC3611. 428 b. Repaired RTP Packet Loss Count Metric 430 * Metric Name: Repaired RTP Packet Count Metric. 432 * Metric Description: The number of RTP packets lost but repaired 433 after applying loss repair methods 435 * Method of Measurement or Calculation: See section 3.1, Repaired 436 RTP Packet Loss Count Metric definition. It is directly measured 437 and must be measured for the primary source RTP packets with no 438 further chance of repair. 440 * Units of Measurement: This metric is expressed as a 16-bit 441 unsigned integer value giving the number of RTP packets. 443 * Measurement Point(s) with Potential Measurement Domain: It is 444 measured at the receiving end of the RTP stream. 446 * Measurement Timing: This metric relies on the sequence number 447 interval to determine measurement timing. See Section 3, 3rd 448 paragraph, for details. 450 * Use and Applications: These metrics are applicable to any RTP 451 application, especially those that use loss repair mechanisms. See 452 Section 1 for details. 454 * Reporting Model: See RFC3611. 456 Authors' Addresses 458 Rachel Huang 459 Huawei 460 101 Software Avenue, Yuhua District 461 Nanjing 210012 462 China 464 EMail: rachel.huang@huawei.com 466 Varun Singh 467 Aalto University 468 School of Electrical Engineering 469 Otakaari 5 A 470 Espoo, FIN 02150 471 Finland 473 Email: varun@comnet.tkk.fi 474 URI: http://www.netlab.tkk.fi/~varun/