idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01.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, 2011) is 4515 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) == Unused Reference: 'RFC3551' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC5760' is defined on line 363, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-15) exists of draft-ietf-xrblock-rtcp-xr-discard-00 == Outdated reference: A later version (-14) exists of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-00 == Outdated reference: A later version (-10) exists of draft-ietf-xrblock-rtcp-xr-meas-identity-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XR Block Working Group J. Ott 3 Internet-Draft V. Singh 4 Intended status: Standards Track Aalto University 5 Expires: June 11, 2012 I. Curcio 6 Nokia Research Center 7 December 9, 2011 9 Real-time Transport Control Protocol (RTCP) Extension Report (XR) for 10 Run Length Encoding of Discarded Packets 11 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01.txt 13 Abstract 15 The Real-time Transport Control Protocol (RTCP) is used in 16 conjunction with the Real-time Transport Protocol (RTP) in to provide 17 a variety of short-term and long-term reception statistics. The 18 available reporting may include aggregate information across longer 19 periods of time as well as individual packet reporting. This 20 document specifies a per-packet report metric capturing individual 21 packets discarded from the jitter buffer after successful reception. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 11, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. XR Discard RLE Report Block . . . . . . . . . . . . . . . . . 4 60 4. XR Bytes Discarded Report Block . . . . . . . . . . . . . . . 5 61 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 6 63 5.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. XR Report Block Registration . . . . . . . . . . . . . . . 8 68 8.2. SDP Parameter Registration . . . . . . . . . . . . . . . . 8 69 8.3. Contact information for IANA registrations . . . . . . . . 9 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 72 A.1. changes in 73 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 . . . . 10 74 A.2. changes in 75 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 RTP [RFC3550] provides a transport for real-time media flows such as 81 audio and video together with the RTP control protocol which provides 82 periodic feedback about the media streams received in a specific 83 duration. In addition, RTCP can be used for timely feedback about 84 individual events to report (e.g., packet loss) [RFC4585]. Both 85 long-term and short-term feedback enable a sender to adapt its media 86 transmission and/or encoding dynamically to the observed path 87 characteristics. 89 RFC3611 [RFC3611] defines RTCP eXtension Reports as a detailed 90 reporting framework to provide more than just the coarse RR 91 statistics. The detailed reporting may enable a sender to react more 92 appropriately to the observed networking conditions as these can be 93 characterized better, albeit at the expense of extra overhead. 95 Among many other fields, RFC3611 specifies the Loss RLE block which 96 define runs of packets received and lost with the granularity of 97 individual packets. This can help both error recovery and path loss 98 characterization. In addition to lost packets, RFC3611 defines the 99 notion of "discarded" packets: packets that were received but dropped 100 from the jitter buffer because they were either too early (for 101 buffering) or too late (for playout). This metric is part of the 102 VoIP metrics report block even though it is not just applicable to 103 audio: it is specified as the fraction of discarded packets since the 104 beginning of the session. See section 4.7.1 of RFC3611 [RFC3611]. 106 Recently proposed extensions to the XR reporting suggest enhancing 107 this discard metric: 108 o Reporting the number of discarded packets during either the last 109 reporting interval or since the beginning of the session, as 110 indicated by a flag in the suggested XR report 111 [I-D.ietf-xrblock-rtcp-xr-discard]. 112 o Reporting gaps and bursts of discarded packets during the last 113 reporting interval or cumulatively since the beginning of the 114 session [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. 116 However, none of these metrics allow a receiver to report precisely 117 which packets were discarded. While this information could in theory 118 be derived from high-frequency reporting on the number of discarded 119 packets or from the gap/burst report, these two mechanisms do not 120 appear feasible: The former would require an unduly high amount of 121 reporting which still might not be sufficient due to the non- 122 deterministic scheduling of RTCP packets. The latter incur 123 significant complexity and reporting overhead and might still not 124 deliver the desired accuracy. 126 This document defines a discard report block following the idea of 127 the run-length encoding applied for lost and received packets in 128 RFC3611 [RFC3611]. 130 Complementary to or instead of the indication which packets were 131 lost, an XR block is defined to indicate the number of bytes lost, 132 per interval or for the duration of the session, similar to other XR 133 report blocks. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in BCP 14, RFC 2119 140 [RFC2119] and indicate requirement levels for compliant 141 implementations. 143 The terminology defined in RTP [RFC3550] and in the extensions for XR 144 reporting [RFC3611] applies. 146 3. XR Discard RLE Report Block 148 The XR Discard RLE report block uses the same format as specified for 149 the loss and duplicate report blocks in RFC3611 [RFC3611]. Figure 150 Figure 1 recaps the packet format. The fields "BT", "T", "block 151 length", "SSRC of source", "begin_seq", and "end_seq" SHALL have the 152 same semantics and representation as defined in RFC3611. The 153 "chunks" encoding the run length SHALL have the same representation 154 as in RFC3611, but encode discarded packets. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | BT=DRLE |rsvd |E| T | block length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | SSRC of source | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | begin_seq | end_seq | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | chunk 1 | chunk 2 | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 : ... : 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | chunk n-1 | chunk n | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: XR Discard Report Block 174 The 'E' bit is introduced to distinguish between packets discarded 175 due to early arrival and those discarded due to late arrival. The 176 'E' bit MUST be set to '1' if the chunks represent packets discarded 177 due to too early arrival and MUST be set to '0' otherwise. 179 In case both early and late discarded packets shall be reported, two 180 Discard RLE report blocks MUST be included; their sequence number 181 range MAY overlap, but individual packets MUST only be reported as 182 either early or late. Packets reported in both MUST be considered as 183 discarded without further information available, packets reported in 184 neither are considered to be properly received and not discarded. 186 Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP 187 RR as a compound RTCP packet. 189 4. XR Bytes Discarded Report Block 191 The XR Bytes Discarded report block uses the following format which 192 follows the model of the framework for performance metric development 193 [RFC6390]. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | BT=BDR | I | Tag |E|res| block length=2 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | SSRC of source | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | number of bytes discarded | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: XR Bytes Discarded Report Block 207 The Interval Metric flag (I) (2 bits) is used to indicate whether the 208 discard metric is Sampled, Interval, or a Cumulative metric, that is, 209 whether the reported value applies to the most recent measurement 210 interval duration between successive reports (I=10, the Interval 211 Duration) or to the accumulation period characteristic of cumulative 212 measurements (I=11, the Cumulative Duration) or is a sampled value 213 (I=01). 215 The 'E' bit is introduced to distinguish between packets discarded 216 due to early arrival and those discarded due to late arrival. The 217 'E' bit MUST be set to '1' if the chunks represent packets discarded 218 due to too early arrival and MUST be set to '0' otherwise. In case 219 both early and late discarded packets shall be reported, two Bytes 220 Discarded report blocks MUST be included. 222 The 'number of bytes discarded' is a 32-bit unsigned integer value 223 indicating the total number of bytes discarded (I=11), or the number 224 of bytes discarded since the last RTCP XR Bytes Discarded block was 225 sent (I=10), or bytes discarded in a measurement interval (I=01) 226 [I-D.ietf-xrblock-rtcp-xr-meas-identity]. 228 Bytes Discarded Report Blocks SHOULD be sent in conjunction with an 229 RTCP RR as a compound RTCP packet. 231 5. Protocol Operation 233 This section describes the behavior of the reporting (= receiver) RTP 234 node and the sender RTP node. 236 5.1. Reporting Node (Receiver) 238 Transmission of RTCP XR Discard RLE Reports is up to the discretion 239 of the receiver, as is the reporting granularity. However, it is 240 RECOMMENDED that the receiver signals all discarded packets using the 241 method defined in this document. If all packets over a reporting 242 period were lost, the receiver MAY use the Discard Report Block 243 [I-D.ietf-xrblock-rtcp-xr-discard] instead. In case of limited 244 available reporting bandwidth, it is up to the receiver whether or 245 not to include RTCP XR Discard RLE reports or not. 247 The receiver MAY send the Discard RLE Reports as part of the 248 regularly scheduled RTCP packets as per RFC3550. It MAY also include 249 Discard RLE Reports in immediate or early feedback packets as per 250 RFC4585. 252 5.2. Media Sender 254 The media sender MUST be prepared to operate without receiving any 255 Discard RLE reports. If Discard RLE reports are generated by the 256 receiver, the sender cannot rely on all these reports being received, 257 nor can the sender rely on a regular generation pattern from the 258 receiver side. 260 However, if the sender receives any RTCP reports but no Discard RLE 261 report blocks and is aware that the receiver supports Discard RLE 262 report blocks, it MAY assume that no packets were discarded at the 263 receiver. 265 6. SDP signaling 267 The report blocks specified in this document define extensions to 268 RTCP XR reporting. Whether or not this specific extended report is 269 sent is left to the discretion of the receiver. Its presence may 270 enable better operation of the sender since more detailed information 271 is available. Not providing this information will make the sender 272 rely on other RTCP report metrics. 274 A participant of a media session MAY use SDP to signal its support 275 for this attribute. In this case, the RTCP XR attribute as defined 276 in RFC3611 [RFC3611] MUST be used. The SDP RFC4566 [RFC4566] 277 attribute 'xr-format' defined in RFC3611 is augmented as described in 278 the following to indicate the discard metric. 280 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 281 CRLF ; defined in [RFC3611] 283 xr-format =/ xr-discard-rle 284 / xr-discard-bytes 286 xr-discard-rle = "discard-rle" 287 xr-discard-bytes = "discard-bytes" 289 The literal 'discard-rle' MUST be used to indicate support for the 290 Discard RLE Report Block defined in section Section 3, the literal 291 'discard-bytes' to indicate support for the Bytes Discarded Report 292 Block defined in section Section 4 294 For signaling support for the discard metric, the rules defined in 295 RFC3611 apply. Generally, senders and receivers SHOULD indicate this 296 capability if they support this metric and would like to use it in 297 the specific media session being signaled. The receiver MAY decide 298 not to send discard information unless it knows about the sender's 299 support to save on RTCP reporting bandwidth. 301 A participant in a media session MAY use the two report blocks 302 specified in this document without any explicit (SDP) signaling. 304 7. Security Considerations 306 The security considerations of RFC3550 [RFC3550], RFC3611 [RFC3611], 307 and RFC4585 [RFC4585] apply. Since this document offers only a more 308 precise reporting for an already existing metric, no further security 309 implications are foreseen. 311 8. IANA Considerations 313 New block types for RTCP XR are subject to IANA registration. For 314 general guidelines on IANA considerations for RTCP XR, refer to 315 RFC3611 [RFC3611]. 317 8.1. XR Report Block Registration 319 This document extends the IANA "RTCP XR Block Type Registry" by two 320 new values: DRLE and BDR. 322 [Note to RFC Editor: please replace DRLE and BDR with the IANA 323 provided RTCP XR block type for this block here and in the diagrams 324 above.] 326 8.2. SDP Parameter Registration 328 This document registers two new parameters for the Session 329 Description Protocol (SDP), "discard-rle" and "discard-bytes", in the 330 "RTCP XR SDP Parameters Registry". 332 8.3. Contact information for IANA registrations 334 Joerg Ott (jo@comnet.tkk.fi) 336 Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland. 338 9. Normative References 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 344 Jacobson, "RTP: A Transport Protocol for Real-Time 345 Applications", STD 64, RFC 3550, July 2003. 347 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 348 Video Conferences with Minimal Control", STD 65, RFC 3551, 349 July 2003. 351 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 352 "Extended RTP Profile for Real-time Transport Control 353 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 354 July 2006. 356 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 357 Description Protocol", RFC 4566, July 2006. 359 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 360 Protocol Extended Reports (RTCP XR)", RFC 3611, 361 November 2003. 363 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 364 Protocol (RTCP) Extensions for Single-Source Multicast 365 Sessions with Unicast Feedback", RFC 5760, February 2010. 367 [I-D.ietf-xrblock-rtcp-xr-discard] 368 Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report 369 Block for Discard metric Reporting", 370 draft-ietf-xrblock-rtcp-xr-discard-00 (work in progress), 371 October 2011. 373 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 374 Hunt, G., Clark, A., Huang, R., and W. Wu, "RTCP XR Report 375 Block for Burst/Gap Discard metric Reporting", 376 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-00 (work in 377 progress), October 2011. 379 [I-D.ietf-xrblock-rtcp-xr-meas-identity] 380 Hunt, G., Clark, A., and W. Wu, "Measurement Identity and 381 information Reporting using SDES item and XR Block", 382 draft-ietf-xrblock-rtcp-xr-meas-identity-01 (work in 383 progress), October 2011. 385 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 386 Performance Metric Development", BCP 170, RFC 6390, 387 October 2011. 389 Appendix A. Change Log 391 Note to the RFC-Editor: please remove this section prior to 392 publication as an RFC. 394 A.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 396 o Changed the interval flag from 1 to 2 bits in the discarded bytes 397 report. Also added the measurement identification tag to the 398 block. 399 o Added this section. 401 A.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 403 o Removed the measurement identification tag to the block. 405 Authors' Addresses 407 Joerg Ott 408 Aalto University 409 Otakaari 5 A 410 Espoo, FIN 02150 411 Finland 413 Email: jo@comnet.tkk.fi 414 Varun Singh 415 Aalto University 416 School of Science and Technology 417 Otakaari 5 A 418 Espoo, FIN 02150 419 Finland 421 Email: varun@comnet.tkk.fi 422 URI: http://www.netlab.tkk.fi/~varun/ 424 Igor D.D. Curcio 425 Nokia Research Center 426 P.O. Box 1000 (Visiokatu 1) 427 Tampere, FIN 33721 428 Finland 430 Email: igor.curcio@nokia.com