idnits 2.17.1 draft-ietf-avt-post-repair-rtcp-xr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 351. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5661 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 (==), 7 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 30, 2009 Cisco Systems 6 October 27, 2008 8 Post-Repair Loss RLE Report Block Type for RTCP XR 9 draft-ietf-avt-post-repair-rtcp-xr-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 30, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines a new report block type within the framework of 43 RTP Control Protocol (RTCP) Extended Reports (XR). One of the 44 initial XR report block types is the Loss Run Length Encoding (RLE) 45 Report Block. This report conveys the information regarding the 46 individual Real-time Transport Protocol (RTP) packet receipt and loss 47 events experienced during the RTCP interval preceding the 48 transmission of the report. The new report, which is referred to as 49 the Post-repair Loss RLE Report, carries the information regarding 50 the remaining lost packets after all loss-repair methods are applied. 51 By comparing the RTP packet receipts/losses before and after the loss 52 repair is completed, one can determine the effectiveness of the loss- 53 repair methods in an aggregated fashion. This document also defines 54 the signaling of the Post-repair Loss RLE Report in the Session 55 Description Protocol (SDP). 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4 61 3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . . 4 62 4. Session Description Protocol Signaling . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 72 1. Introduction 74 RTP Control Protocol (RTCP) is the out-of-band control protocol for 75 the applications that are using the Real-time Transport Protocol 76 (RTP) for media delivery and communications [RFC3550]. RTCP allows 77 the RTP entities to monitor the data delivery and provides them 78 minimal control functionality via sender and receiver reports as well 79 as other control packets. [RFC3611] expands the RTCP functionality 80 further by introducing the RTCP Extended Reports (XR). 82 One of the initial XR report block types defined in [RFC3611] is the 83 Loss Run Length Encoding (RLE) Report Block. This report conveys the 84 information regarding the individual RTP packet receipt and loss 85 events experienced during the RTCP interval preceding the 86 transmission of the report. However, the Loss RLE in an RTCP XR 87 report is usually collected only on the primary source stream before 88 any loss-repair method is applied. Once one or more loss-repair 89 methods, e.g., Forward Error Correction (FEC) [RFC5109] and/or 90 retransmission [RFC4588], are applied, some or all of the lost 91 packets on the primary source stream may be recovered. However, the 92 pre-repair Loss RLE cannot indicate which source packets were 93 recovered and which are still missing. Thus, the pre-repair Loss RLE 94 cannot specify how well the loss repair performed. 96 This issue can be addressed by generating an additional report block 97 (within the same or a different RTCP XR report), which reflects the 98 packet receipt/loss events after all loss-repair methods are applied. 99 This report block, which we refer to as the Post-repair Loss RLE, 100 indicates the remaining missing, i.e., unrepairable, source packets. 101 When the pre-repair and post-repair Loss RLEs are compared, the RTP 102 sender or another third party entity can evaluate the effectiveness 103 of the loss-repair methods in an aggregated fashion. To avoid any 104 ambiguity in the evaluation, it is RECOMMENDED that the post-repair 105 Loss RLE is generated for the source packets that have no further 106 chance of being repaired. If the loss-repair method(s) may still 107 recover one or more missing source packets, the post-repair Loss RLE 108 SHOULD NOT be sent until the loss-recovery process has been 109 completed. 111 Similar to the pre-repair Loss RLE, the post-repair Loss RLE conveys 112 the receipt/loss events at the packet level and considers partially 113 repaired packets as unrepaired. Thus, the methods that can partially 114 recover the missing data SHOULD NOT be evaluated based on the 115 information provided by the Post-repair Loss RLE Reports since such 116 information may underestimate the effectiveness of such methods. 118 Note that the idea of using pre-repair and post-repair Loss RLEs can 119 be further extended when multiple sequential loss-repair methods are 120 applied to the primary source stream. Reporting the Loss RLEs before 121 and after each loss-repair method can provide specific information 122 about the individual performances of these methods. However, it can 123 be a difficult task to quantify the specific contribution made by 124 each loss-repair method in hybrid systems, where different methods 125 collectively work together to repair the lost source packets. Thus, 126 in this specification we only consider reporting the Loss RLE after 127 all loss-repair methods are applied. 129 This document registers a new report block type to cover the post- 130 repair Loss RLE within the framework of RTCP XR. Applications that 131 are employing one or more loss-repair methods MAY use Post-repair 132 Loss RLE Reports for every packet they receive or for a set of 133 specific packets they have received. In other words, the coverage of 134 the post-repair Loss RLEs may or may not be contiguous. 136 2. Requirements Notation 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Post-Repair Loss RLE Report Block 144 The Post-repair Loss RLE Report Block is similar to the existing Loss 145 RLE Report Block defined in [RFC3611]. The report format is shown in 146 Figure 1. Using the same structure for reporting both pre-repair and 147 post-repair Loss RLEs allows the implementations to compare the Loss 148 RLEs very efficiently. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | BT=10 | rsvd. | T | block length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | SSRC of source | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | begin_seq | end_seq | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | chunk 1 | chunk 2 | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 : ... : 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | chunk n-1 | chunk n | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1: Format for the post-repair loss RLE report block 168 o block type (BT): 8 bits 169 A Post-repair Loss RLE Report Block is identified by the constant 170 10. 172 o rsvd.: 4 bits 173 This field is reserved for future definition. In the absence of 174 such definition, the bits in this field MUST be set to zero and 175 MUST be ignored by the receiver. 177 o thinning (T): 4 bits 178 The amount of thinning performed on the sequence number space. 179 Only those packets with sequence numbers 0 mod 2^T are reported on 180 by this block. A value of 0 indicates that there is no thinning, 181 and all packets are reported on. The maximum thinning is one 182 packet in every 32,768 (amounting to two packets within each 16- 183 bit sequence space). 185 o block length: 16 bits 186 The length of this report block, including the header, in 32-bit 187 words minus one. 189 o SSRC of source: 32 bits 191 The SSRC of the RTP data packet source being reported upon by this 192 report block. 194 o begin_seq: 16 bits 196 The first sequence number that this block reports on. 198 o end_seq: 16 bits 200 The last sequence number that this block reports on plus one. 202 o chunk i: 16 bits 203 There are three chunk types: run length, bit vector, and 204 terminating null, defined in [RFC3611] (Section 4). If the chunk 205 is all zeroes, then it is a terminating null chunk. Otherwise, 206 the left most bit of the chunk determines its type: 0 for run 207 length and 1 for bit vector. 209 Note that the sequence numbers that are included in the report refer 210 to the primary source stream. 212 4. Session Description Protocol Signaling 214 A new parameter is defined for the Post-repair Loss RLE Report Block 215 to be used with Session Description Protocol (SDP) [RFC4566]. It has 216 the following syntax within the "rtcp-xr" attribute: 218 rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF 220 xr-format = "post-repair-loss-rle" ["=" max-size] 222 max-size = 1*DIGIT ; maximum block size in octets 223 DIGIT = %x30-39 224 CRLF = %d13.10 226 Figure 2 228 Refer to Section 5.1 of [RFC3611] for a detailed description and the 229 full syntax of the "rtcp-xr" attribute. 231 5. Security Considerations 233 The security considerations of [RFC3611] apply in this document as 234 well. 236 6. IANA Considerations 238 New block types for RTCP XR are subject to IANA registration. For 239 general guidelines on IANA considerations for RTCP XR, refer to 240 [RFC3611]. 242 This document assigns the block type value 10 in the RTCP XR Block 243 Type Registry to "Post-repair Loss RLE Report Block." This document 244 also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for 245 the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. 247 The contact information for the registrations is: 249 Ali Begen 250 abegen@cisco.com 252 170 West Tasman Drive 253 San Jose, CA 95134 USA 255 7. Acknowledgments 257 The authors would like to thank the members of the VQE Team at Cisco 258 and Colin Perkins for their inputs and suggestions. 260 8. References 262 8.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 268 Jacobson, "RTP: A Transport Protocol for Real-Time 269 Applications", STD 64, RFC 3550, July 2003. 271 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 272 Protocol Extended Reports (RTCP XR)", RFC 3611, 273 November 2003. 275 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 276 Description Protocol", RFC 4566, July 2006. 278 8.2. Informative References 280 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 281 Correction", RFC 5109, December 2007. 283 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 284 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 285 July 2006. 287 Authors' Addresses 289 Ali Begen 290 Cisco Systems 291 170 West Tasman Drive 292 San Jose, CA 95134 293 USA 295 Email: abegen@cisco.com 297 Dong Hsu 298 Cisco Systems 299 1414 Massachusetts Ave. 300 Boxborough, MA 01719 301 USA 303 Email: dohsu@cisco.com 305 Michael Lague 306 Cisco Systems 307 1414 Massachusetts Ave. 308 Boxborough, MA 01719 309 USA 311 Email: mlague@cisco.com 313 Full Copyright Statement 315 Copyright (C) The IETF Trust (2008). 317 This document is subject to the rights, licenses and restrictions 318 contained in BCP 78, and except as set forth therein, the authors 319 retain all their rights. 321 This document and the information contained herein are provided on an 322 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 323 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 324 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 325 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 326 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 327 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 329 Intellectual Property 331 The IETF takes no position regarding the validity or scope of any 332 Intellectual Property Rights or other rights that might be claimed to 333 pertain to the implementation or use of the technology described in 334 this document or the extent to which any license under such rights 335 might or might not be available; nor does it represent that it has 336 made any independent effort to identify any such rights. Information 337 on the procedures with respect to rights in RFC documents can be 338 found in BCP 78 and BCP 79. 340 Copies of IPR disclosures made to the IETF Secretariat and any 341 assurances of licenses to be made available, or the result of an 342 attempt made to obtain a general license or permission for the use of 343 such proprietary rights by implementers or users of this 344 specification can be obtained from the IETF on-line IPR repository at 345 http://www.ietf.org/ipr. 347 The IETF invites any interested party to bring to its attention any 348 copyrights, patents or patent applications, or other proprietary 349 rights that may cover technology that may be required to implement 350 this standard. Please address the information to the IETF at 351 ietf-ipr@ietf.org. 353 Acknowledgment 355 Funding for the RFC Editor function is provided by the IETF 356 Administrative Support Activity (IASA).