idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-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 (January 30, 2012) is 4464 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 366, but no explicit reference was found in the text == Unused Reference: 'RFC5760' is defined on line 382, 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: August 2, 2012 I. Curcio 6 Nokia Research Center 7 January 30, 2012 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-02.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 August 2, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 . . . . . . . . 8 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 A.3. changes in 77 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 RTP [RFC3550] provides a transport for real-time media flows such as 83 audio and video together with the RTP control protocol which provides 84 periodic feedback about the media streams received in a specific 85 duration. In addition, RTCP can be used for timely feedback about 86 individual events to report (e.g., packet loss) [RFC4585]. Both 87 long-term and short-term feedback enable a sender to adapt its media 88 transmission and/or encoding dynamically to the observed path 89 characteristics. 91 RFC3611 [RFC3611] defines RTCP eXtension Reports as a detailed 92 reporting framework to provide more than just the coarse RR 93 statistics. The detailed reporting may enable a sender to react more 94 appropriately to the observed networking conditions as these can be 95 characterized better, albeit at the expense of extra overhead. 97 Among many other fields, RFC3611 specifies the Loss RLE block which 98 define runs of packets received and lost with the granularity of 99 individual packets. This can help both error recovery and path loss 100 characterization. In addition to lost packets, RFC3611 defines the 101 notion of "discarded" packets: packets that were received but dropped 102 from the jitter buffer because they were either too early (for 103 buffering) or too late (for playout). This metric is part of the 104 VoIP metrics report block even though it is not just applicable to 105 audio: it is specified as the fraction of discarded packets since the 106 beginning of the session. See section 4.7.1 of RFC3611 [RFC3611]. 108 Recently proposed extensions to the XR reporting suggest enhancing 109 this discard metric: 110 o Reporting the number of discarded packets in a measurement 111 interval, i.e., during either the last reporting interval or since 112 the beginning of the session, as indicated by a flag in the 113 suggested XR report [I-D.ietf-xrblock-rtcp-xr-discard]. 114 o Reporting gaps and bursts of discarded packets during a 115 measurement interval, i.e., the last reporting interval or 116 cumulatively since the beginning of the session 117 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. 119 However, none of these metrics allow a receiver to report precisely 120 which packets were discarded. While this information could in theory 121 be derived from high-frequency reporting on the number of discarded 122 packets or from the gap/burst report, these two mechanisms do not 123 appear feasible: The former would require an unduly high amount of 124 reporting which still might not be sufficient due to the non- 125 deterministic scheduling of RTCP packets. The latter incur 126 significant complexity and reporting overhead and might still not 127 deliver the desired accuracy. 129 This document defines a discard report block following the idea of 130 the run-length encoding applied for lost and received packets in 131 RFC3611 [RFC3611]. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in BCP 14, RFC 2119 138 [RFC2119] and indicate requirement levels for compliant 139 implementations. 141 The terminology defined in RTP [RFC3550] and in the extensions for XR 142 reporting [RFC3611] applies. 144 3. XR Discard RLE Report Block 146 The XR Discard RLE report block uses the same format as specified for 147 the loss and duplicate report blocks in RFC3611 [RFC3611]. Figure 148 Figure 1 recaps the packet format. The fields "BT", "T", "block 149 length", "SSRC of source", "begin_seq", and "end_seq" SHALL have the 150 same semantics and representation as defined in RFC3611. The 151 "chunks" encoding the run length SHALL have the same representation 152 as in RFC3611, but encode discarded packets. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | BT=DRLE |rsvd |E| T | block length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | SSRC of source | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | begin_seq | end_seq | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | chunk 1 | chunk 2 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 : ... : 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | chunk n-1 | chunk n | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1: XR Discard Report Block 172 These reserved bits (2 bits) SHOULD be set to zero by receivers and 173 MUST be ignored by senders. 175 The 'E' bit is introduced to distinguish between packets discarded 176 due to early arrival and those discarded due to late arrival. The 177 'E' bit MUST be set to '1' if the chunks represent packets discarded 178 due to too early arrival and MUST be set to '0' otherwise. 180 In case both early and late discarded packets shall be reported, two 181 Discard RLE report blocks MUST be included; their sequence number 182 range MAY overlap, but individual packets MUST only be reported as 183 either early or late. Packets reported in both MUST be considered as 184 discarded without further information available, packets reported in 185 neither are considered to be properly received and not discarded. 187 Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP 188 RR as a compound RTCP packet. 190 4. XR Bytes Discarded Report Block 192 The XR Bytes Discarded report block uses the following format which 193 follows the model of the framework for performance metric development 194 [RFC6390]. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | BT=BDR | I |E|reserved | block length=2 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | SSRC of source | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | number of bytes discarded | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2: XR Bytes Discarded Report Block 208 The Interval Metric flag (I) (2 bits) is used to indicate whether the 209 discard metric is Sampled, Interval, or a Cumulative metric, that is, 210 whether the reported value applies to the most recent measurement 211 interval duration between successive reports (I=10, the Interval 212 Duration) or to the accumulation period characteristic of cumulative 213 measurements (I=11, the Cumulative Duration) or is a sampled value 214 (I=01). 216 The 'E' bit is introduced to distinguish between packets discarded 217 due to early arrival and those discarded due to late arrival. The 218 'E' bit MUST be set to '1' if the chunks represent packets discarded 219 due to too early arrival and MUST be set to '0' otherwise. In case 220 both early and late discarded packets shall be reported, two Bytes 221 Discarded report blocks MUST be included. 223 These reserved bits (5 bits) SHOULD be set to zero by receivers and 224 MUST be ignored by senders. 226 The 'number of bytes discarded' is a 32-bit unsigned integer value 227 indicating the total number of bytes discarded. 229 If the XR block is not preceded by a measurement identity block 230 [I-D.ietf-xrblock-rtcp-xr-meas-identity] then the value indicates the 231 bytes lost from from the start of the session (I=11), or the number 232 of bytes discarded since the last RTCP XR Bytes Discarded block was 233 received (I=10). 235 If the XR block follows a measurement identity block 236 [I-D.ietf-xrblock-rtcp-xr-meas-identity] in an RTCP RR packet then 237 the cumulative (I=11) and interval (I=10) correspond to the values in 238 the measurement block. 240 If the receiver sends the Bytes Discarded Report Block without the 241 measurement identity block then the discard block MUST be sent in 242 conjunction with an RTCP RR as a compound RTCP packet. 244 5. Protocol Operation 246 This section describes the behavior of the reporting (= receiver) RTP 247 node and the sender RTP node. 249 5.1. Reporting Node (Receiver) 251 Transmission of RTCP XR Discard RLE Reports is up to the discretion 252 of the receiver, as is the reporting granularity. However, it is 253 RECOMMENDED that the receiver signals all discarded packets using the 254 method defined in this document. If all packets over a reporting 255 period were lost, the receiver MAY use the Discard Report Block 256 [I-D.ietf-xrblock-rtcp-xr-discard] instead. In case of limited 257 available reporting bandwidth, it is up to the receiver whether or 258 not to include RTCP XR Discard RLE reports. 260 The receiver MAY send the Discard RLE Reports as part of the 261 regularly scheduled RTCP packets as per RFC3550. It MAY also include 262 Discard RLE Reports in immediate or early feedback packets as per 263 RFC4585. 265 5.2. Media Sender 267 The media sender MUST be prepared to operate without receiving any 268 Discard RLE reports. If Discard RLE reports are generated by the 269 receiver, the sender cannot rely on all these reports being received, 270 nor can the sender rely on a regular generation pattern from the 271 receiver side. 273 However, if the sender receives any RTCP reports but no Discard RLE 274 report blocks and is aware that the receiver supports Discard RLE 275 report blocks, it MAY assume that no packets were discarded at the 276 receiver. 278 The sender SHOULD accept the Bytes Discarded Report Block only if it 279 is received in a compound RTCP receiver report or if it is preceded 280 by a measurement identity block 281 [I-D.ietf-xrblock-rtcp-xr-meas-identity]. Under all other 282 circumstances it MUST ignore the block. 284 6. SDP signaling 286 The report blocks specified in this document define extensions to 287 RTCP XR reporting. Whether or not this specific extended report is 288 sent is left to the discretion of the receiver. Its presence may 289 enable better operation of the sender since more detailed information 290 is available. Not providing this information will make the sender 291 rely on other RTCP report metrics. 293 A participant of a media session MAY use SDP to signal its support 294 for this attribute. In this case, the RTCP XR attribute as defined 295 in RFC3611 [RFC3611] MUST be used. The SDP RFC4566 [RFC4566] 296 attribute 'xr-format' defined in RFC3611 is augmented as described in 297 the following to indicate the discard metric. 299 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 300 CRLF ; defined in [RFC3611] 302 xr-format =/ xr-discard-rle 303 / xr-discard-bytes 305 xr-discard-rle = "discard-rle" 306 xr-discard-bytes = "discard-bytes" 308 The literal 'discard-rle' MUST be used to indicate support for the 309 Discard RLE Report Block defined in section Section 3, the literal 310 'discard-bytes' to indicate support for the Bytes Discarded Report 311 Block defined in section Section 4 313 For signaling support for the discard metric, the rules defined in 314 RFC3611 apply. Generally, senders and receivers SHOULD indicate this 315 capability if they support this metric and would like to use it in 316 the specific media session being signaled. The receiver MAY decide 317 not to send discard information unless it knows about the sender's 318 support to save on RTCP reporting bandwidth. 320 A participant in a media session MAY use the two report blocks 321 specified in this document without any explicit (SDP) signaling. 323 7. Security Considerations 325 The security considerations of RFC3550 [RFC3550], RFC3611 [RFC3611], 326 and RFC4585 [RFC4585] apply. Since this document offers only a more 327 precise reporting for an already existing metric, no further security 328 implications are foreseen. 330 8. IANA Considerations 332 New block types for RTCP XR are subject to IANA registration. For 333 general guidelines on IANA considerations for RTCP XR, refer to 334 RFC3611 [RFC3611]. 336 8.1. XR Report Block Registration 338 This document extends the IANA "RTCP XR Block Type Registry" by two 339 new values: DRLE and BDR. 341 [Note to RFC Editor: please replace DRLE and BDR with the IANA 342 provided RTCP XR block type for this block here and in the diagrams 343 above.] 345 8.2. SDP Parameter Registration 347 This document registers two new parameters for the Session 348 Description Protocol (SDP), "discard-rle" and "discard-bytes", in the 349 "RTCP XR SDP Parameters Registry". 351 8.3. Contact information for IANA registrations 353 Joerg Ott (jo@comnet.tkk.fi) 355 Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland. 357 9. Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", BCP 14, RFC 2119, March 1997. 362 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 363 Jacobson, "RTP: A Transport Protocol for Real-Time 364 Applications", STD 64, RFC 3550, July 2003. 366 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 367 Video Conferences with Minimal Control", STD 65, RFC 3551, 368 July 2003. 370 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 371 "Extended RTP Profile for Real-time Transport Control 372 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 373 July 2006. 375 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 376 Description Protocol", RFC 4566, July 2006. 378 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 379 Protocol Extended Reports (RTCP XR)", RFC 3611, 380 November 2003. 382 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 383 Protocol (RTCP) Extensions for Single-Source Multicast 384 Sessions with Unicast Feedback", RFC 5760, February 2010. 386 [I-D.ietf-xrblock-rtcp-xr-discard] 387 Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report 388 Block for Discard metric Reporting", 389 draft-ietf-xrblock-rtcp-xr-discard-00 (work in progress), 390 October 2011. 392 [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] 393 Hunt, G., Clark, A., Huang, R., and W. Wu, "RTCP XR Report 394 Block for Burst/Gap Discard metric Reporting", 395 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-00 (work in 396 progress), October 2011. 398 [I-D.ietf-xrblock-rtcp-xr-meas-identity] 399 Hunt, G., Clark, A., and W. Wu, "Measurement Identity and 400 information Reporting using SDES item and XR Block", 401 draft-ietf-xrblock-rtcp-xr-meas-identity-01 (work in 402 progress), October 2011. 404 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 405 Performance Metric Development", BCP 170, RFC 6390, 406 October 2011. 408 Appendix A. Change Log 410 Note to the RFC-Editor: please remove this section prior to 411 publication as an RFC. 413 A.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 415 o Changed the interval flag from 1 to 2 bits in the discarded bytes 416 report. Also added the measurement identification tag to the 417 block. 418 o Added this section. 420 A.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 422 o Removed the measurement identification tag in the bytes discarded 423 block. 425 A.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 427 o Removed the extra Tag bits from the Discarded bytes XR block. 428 o Clarified use of measurement identity block in Section 4 and 5.2 430 Authors' Addresses 432 Joerg Ott 433 Aalto University 434 Otakaari 5 A 435 Espoo, FIN 02150 436 Finland 438 Email: jo@comnet.tkk.fi 440 Varun Singh 441 Aalto University 442 School of Science and Technology 443 Otakaari 5 A 444 Espoo, FIN 02150 445 Finland 447 Email: varun@comnet.tkk.fi 448 URI: http://www.netlab.tkk.fi/~varun/ 449 Igor D.D. Curcio 450 Nokia Research Center 451 P.O. Box 1000 (Visiokatu 1) 452 Tampere, FIN 33721 453 Finland 455 Email: igor.curcio@nokia.com