idnits 2.17.1 draft-ietf-avt-post-repair-rtcp-xr-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2009) is 5305 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft D. Hsu 4 Intended status: Standards Track M. Lague 5 Expires: April 18, 2010 Cisco Systems 6 October 15, 2009 8 Post-Repair Loss RLE Report Block Type for RTCP XR 9 draft-ietf-avt-post-repair-rtcp-xr-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 18, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document defines a new report block type within the framework of 58 RTP Control Protocol (RTCP) Extended Reports (XR). One of the 59 initial XR report block types is the Loss Run Length Encoding (RLE) 60 Report Block. This report conveys the information regarding the 61 individual Real-time Transport Protocol (RTP) packet receipt and loss 62 events experienced during the RTCP interval preceding the 63 transmission of the report. The new report, which is referred to as 64 the Post-repair Loss RLE Report, carries the information regarding 65 the remaining lost packets after all loss-repair methods are applied. 66 By comparing the RTP packet receipts/losses before and after the loss 67 repair is completed, one can determine the effectiveness of the loss- 68 repair methods in an aggregated fashion. This document also defines 69 the signaling of the Post-repair Loss RLE Report in the Session 70 Description Protocol (SDP). 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 76 3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . 5 77 4. Session Description Protocol Signaling . . . . . . . . . . . . 7 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 RTP Control Protocol (RTCP) is the out-of-band control protocol for 89 the applications that are using the Real-time Transport Protocol 90 (RTP) for media delivery and communications [RFC3550]. RTCP allows 91 the RTP entities to monitor the data delivery and provides them 92 minimal control functionality via sender and receiver reports as well 93 as other control packets. [RFC3611] expands the RTCP functionality 94 further by introducing the RTCP Extended Reports (XR). 96 One of the initial XR report block types defined in [RFC3611] is the 97 Loss Run Length Encoding (RLE) Report Block. This report conveys the 98 information regarding the individual RTP packet receipt and loss 99 events experienced during the RTCP interval preceding the 100 transmission of the report. However, the Loss RLE in an RTCP XR 101 report is usually collected only on the primary source stream before 102 any loss-repair method is applied. Once one or more loss-repair 103 methods, e.g., Forward Error Correction (FEC) [RFC5109] and/or 104 retransmission [RFC4588], are applied, some or all of the lost 105 packets on the primary source stream may be recovered. However, the 106 pre-repair Loss RLE cannot indicate which source packets were 107 recovered and which are still missing. Thus, the pre-repair Loss RLE 108 cannot specify how well the loss repair performed. 110 This issue can be addressed by generating an additional report block 111 (within the same or a different RTCP XR report), which reflects the 112 packet receipt/loss events after all loss-repair methods are applied. 113 This report block, which we refer to as the Post-repair Loss RLE, 114 indicates the remaining missing, i.e., unrepairable, source packets. 115 When the pre-repair and post-repair Loss RLEs are compared, the RTP 116 sender or another third party entity can evaluate the effectiveness 117 of the loss-repair methods in an aggregated fashion. To avoid any 118 ambiguity in the evaluation, it is RECOMMENDED that the post-repair 119 Loss RLE is generated for the source packets that have no further 120 chance of being repaired. If the loss-repair method(s) may still 121 recover one or more missing source packets, the post-repair Loss RLE 122 SHOULD NOT be sent until the loss-recovery process has been 123 completed. However, a potential ambiguity may result from sequence 124 number wrapping in the primary source stream. Thus, the post-repair 125 Loss RLE reports may not be delayed arbitrarily. In case of an 126 ambiguity in the incoming reports, it is the sender's or the 127 monitoring entity's responsibility to understand which packets the 128 post-repair Loss RLE report is related to. 130 Similar to the pre-repair Loss RLE, the post-repair Loss RLE conveys 131 the receipt/loss events at the packet level and considers partially 132 repaired packets as unrepaired. Thus, the methods that can partially 133 recover the missing data SHOULD NOT be evaluated based on the 134 information provided by the Post-repair Loss RLE Reports since such 135 information may underestimate the effectiveness of such methods. 137 Note that the idea of using pre-repair and post-repair Loss RLEs can 138 be further extended when multiple sequential loss-repair methods are 139 applied to the primary source stream. Reporting the Loss RLEs before 140 and after each loss-repair method can provide specific information 141 about the individual performances of these methods. However, it can 142 be a difficult task to quantify the specific contribution made by 143 each loss-repair method in hybrid systems, where different methods 144 collectively work together to repair the lost source packets. Thus, 145 in this specification we only consider reporting the Loss RLE after 146 all loss-repair methods are applied. 148 This document registers a new report block type to cover the post- 149 repair Loss RLE within the framework of RTCP XR. Applications that 150 are employing one or more loss-repair methods MAY use Post-repair 151 Loss RLE Reports for every packet they receive or for a set of 152 specific packets they have received. In other words, the coverage of 153 the post-repair Loss RLEs may or may not be contiguous. 155 2. Requirements Notation 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. Post-Repair Loss RLE Report Block 163 The Post-repair Loss RLE Report Block is similar to the existing Loss 164 RLE Report Block defined in [RFC3611]. The report format is shown in 165 Figure 1. Using the same structure for reporting both pre-repair and 166 post-repair Loss RLEs allows the implementations to compare the Loss 167 RLEs very efficiently. 169 0 1 2 3 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | BT=10 | rsvd. | T | block length | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | SSRC of source | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | begin_seq | end_seq | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | chunk 1 | chunk 2 | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 : ... : 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | chunk n-1 | chunk n | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1: Format for the post-repair loss RLE report block 187 o block type (BT): 8 bits 188 A Post-repair Loss RLE Report Block is identified by the constant 189 10. 191 o rsvd.: 4 bits 192 This field is reserved for future definition. In the absence of 193 such definition, the bits in this field MUST be set to zero and 194 MUST be ignored by the receiver. 196 o thinning (T): 4 bits 197 The amount of thinning performed on the sequence number space. 198 Only those packets with sequence numbers 0 mod 2^T are reported on 199 by this block. A value of 0 indicates that there is no thinning, 200 and all packets are reported on. The maximum thinning is one 201 packet in every 32,768 (amounting to two packets within each 16- 202 bit sequence space). 204 If thinning is desired, It is RECOMMENDED to use the same thinning 205 value in the pre-repair and post-repair Loss RLE reports. This 206 will allow easier report processing and correlation. However, 207 based on the specific needs of the application or the monitoring 208 entity, different values of thinning MAY be used for pre-repair 209 and post-repair Loss RLE reports. 211 o block length: 16 bits 212 The length of this report block, including the header, in 32-bit 213 words minus one. 215 o SSRC of source: 32 bits 216 The SSRC of the RTP data packet source being reported upon by this 217 report block. 219 o begin_seq: 16 bits 221 The first sequence number that this block reports on. 223 o end_seq: 16 bits 225 The last sequence number that this block reports on plus one. 227 o chunk i: 16 bits 228 There are three chunk types: run length, bit vector, and 229 terminating null, defined in [RFC3611] (Section 4). If the chunk 230 is all zeroes, then it is a terminating null chunk. Otherwise, 231 the left most bit of the chunk determines its type: 0 for run 232 length and 1 for bit vector. 234 Note that the sequence numbers that are included in the report refer 235 to the primary source stream. 237 When using post-repair Loss RLE reports, the amount of bandwidth 238 consumed by the detailed reports should be considered carefully. The 239 bandwidth usage rules as they are described in [RFC3611] apply to 240 post-repair Loss RLE reports as well. 242 4. Session Description Protocol Signaling 244 A new parameter is defined for the Post-repair Loss RLE Report Block 245 to be used with Session Description Protocol (SDP) [RFC4566] using 246 the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the 247 following syntax within the "rtcp-xr" attribute [RFC3611]: 249 rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF 251 xr-format =/ "post-repair-loss-rle" ["=" max-size] 253 max-size = 1*DIGIT ; maximum block size in octets 255 Figure 2 257 Refer to Section 5.1 of [RFC3611] for a detailed description and the 258 full syntax of the "rtcp-xr" attribute. 260 5. Security Considerations 262 The security considerations of [RFC3611] apply in this document as 263 well. Additional security considerations are briefly mentioned 264 below. 266 An attacker who monitors the regular pre-repair Loss RLE reports sent 267 by a group of receivers in the same multicast distribution network 268 may infer the network characteristics (Multicast Inference of Network 269 Characteristics). However, monitoring the post-repair Loss RLE 270 reports will not reveal any further information about the network. 271 Without the regular pre-repair Loss RLE reports, the post-repair ones 272 will not be any use to attackers. Even when used with the regular 273 pre-repair Loss RLE reports, the post-repair Loss RLE reports only 274 reveal the effectiveness of the repair process. However, this does 275 not enable any new attacks nor does it provide information to an 276 attacker that could not be similarly obtained by watching the RTP 277 packets fly by himself, performing the repair algorithms and 278 computing the desired output. 280 An attacker may interfere with the repair process for an RTP stream. 281 In that case, if the attacker is able to see the post-repair Loss 282 RLEs, the attacker may infer whether the attack is effective or not, 283 in which case the attacker may continue attacking or alter the 284 attack. In practice, however, this does not pose a security risk. 286 Similar to other RTCP XR reports, the post-repair Loss RLE reports 287 MAY be protected by using SRTP and SRTCP [RFC3711]. 289 6. IANA Considerations 291 New block types for RTCP XR are subject to IANA registration. For 292 general guidelines on IANA considerations for RTCP XR, refer to 293 [RFC3611]. 295 This document assigns the block type value 10 in the RTCP XR Block 296 Type Registry to "Post-repair Loss RLE Report Block." This document 297 also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for 298 the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. 300 The contact information for the registrations is: 302 Ali Begen 303 abegen@cisco.com 305 170 West Tasman Drive 306 San Jose, CA 95134 USA 308 7. Acknowledgments 310 The authors would like to thank the members of the VQE Team at Cisco 311 and Colin Perkins for their inputs and suggestions. 313 8. References 315 8.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 321 Jacobson, "RTP: A Transport Protocol for Real-Time 322 Applications", STD 64, RFC 3550, July 2003. 324 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 325 Protocol Extended Reports (RTCP XR)", RFC 3611, 326 November 2003. 328 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 329 Description Protocol", RFC 4566, July 2006. 331 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 332 Specifications: ABNF", STD 68, RFC 5234, January 2008. 334 8.2. Informative References 336 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 337 Correction", RFC 5109, December 2007. 339 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 340 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 341 July 2006. 343 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 344 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 345 RFC 3711, March 2004. 347 Authors' Addresses 349 Ali Begen 350 Cisco Systems 351 170 West Tasman Drive 352 San Jose, CA 95134 353 USA 355 Email: abegen@cisco.com 357 Dong Hsu 358 Cisco Systems 359 1414 Massachusetts Ave. 360 Boxborough, MA 01719 361 USA 363 Email: dohsu@cisco.com 365 Michael Lague 366 Cisco Systems 367 1414 Massachusetts Ave. 368 Boxborough, MA 01719 369 USA 371 Email: mlague@cisco.com