idnits 2.17.1 draft-begen-mmusic-fec-grouping-issues-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 486. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 (February 14, 2008) is 5887 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-01 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 4756 (Obsoleted by RFC 5956) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Begen 3 Internet-Draft Cisco Systems 4 Intended status: Informational February 14, 2008 5 Expires: August 17, 2008 7 FEC Grouping Issues in Session Description Protocol 8 draft-begen-mmusic-fec-grouping-issues-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 17, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The Session Description Protocol (SDP) currently supports grouping 42 media lines. SDP also has semantics defined for grouping the 43 associated source and Forward Error Correction (FEC)-based repair 44 flows. However, the existing specifications have strict requirements 45 that severely limit the use of the new features that are currently 46 under development in the FECFRAME WG. These new features will allow 47 applications to use FEC in a more flexible way but they require 48 changes in the current specifications. This document provides a list 49 of the required changes and discusses potential approaches to make 50 these changes. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 56 3. FEC Framework Requirements and Issues with the Existing 57 Specifications . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Source and Repair Flow Association . . . . . . . . . . . . 5 59 3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6 60 3.3. Support for Prioritization . . . . . . . . . . . . . . . . 6 61 4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. New Grouping Attribute . . . . . . . . . . . . . . . . . . 7 63 4.2. New Grouping Semantics . . . . . . . . . . . . . . . . . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Intellectual Property and Copyright Statements . . . . . . . . . . 12 73 1. Introduction 75 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 76 framework for using Forward Error Correction (FEC) codes in 77 multimedia applications that stream audio, video or other types of 78 multimedia content. 80 Any application that needs a reliable transmission over an unreliable 81 packet network has to cope with the packet losses. FEC is an 82 effective approach that provides reliable transmission particularly 83 in multicast and broadcast applications where the feedback from the 84 receiver(s) is potentially limited. 86 In a nutshell, FEC groups source packets into blocks and applies 87 protection to generate a desired number of repair packets. These 88 repair packets may be sent on demand or independently of any receiver 89 feedback. The choice depends on the FEC scheme or the Content 90 Delivery Protocol used by the application, the error characteristics 91 of the underlying network, the transport scheme (e.g., unicast, 92 multicast, and broadcast), and the application. At the receiver 93 side, lost packets can be recovered by erasure decoding provided that 94 a sufficient number of source and repair packets are received. 96 For example, one of the most basic FEC schemes is the parity codes, 97 where an XOR operation is applied to a group of packets (i.e., source 98 block) to generate a single repair packet. At the receiver side, 99 this scheme achieves a full recovery if only one packet is lost 100 within the source block and the repair packet is received. There are 101 various other ways of generating repair packets, possibly with 102 different error-recovery capabilities. 104 The FEC Framework specification states that source and repair packets 105 MUST be carried in different streams, which are referred to as the 106 source and repair flows, respectively. At the receiver side, the 107 receivers should know which flows are the source flows and which 108 flows are the repair flows. The receivers should also know the exact 109 association of the source and repair flows so that they can use the 110 correct data to repair the original content in case there is a packet 111 loss. Currently, [RFC3388] and [RFC4756] are used for this purpose. 113 In order to provide applications more flexibility, the FEC Framework 114 [I-D.ietf-fecframe-framework] allows a source flow to be protected by 115 multiple FEC schemes, each of which requires an instance of the FEC 116 Framework. Thus, multiple instances of the FEC Framework MAY exist 117 at the sender and the receiver(s). Furthermore, within a single FEC 118 Framework instance, multiple source flows MAY be grouped and 119 protected by one or more repair flows. 121 A basic example scenario is shown in Figure 1. Here, source flow S1 122 is protected by repair flow R1. Also, source flows S1 and S2 are 123 grouped and protected together by repair flow R2. 125 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 126 | S1: Source Flow |--------| R1: Repair Flow 127 +---| 128 | | S2: Source Flow 129 | 130 +______________________________| FEC FRAMEWORK INSTANCE #2 131 | R2: Repair Flow 133 Figure 1: Example scenario with two FEC Framework instances where R1 134 protects S1, and R2 protects the group of S1 and S2 136 Grouping source flows before applying FEC protection enables us to 137 achieve a better coding performance. As a typical scenario, suppose 138 that source flow S1 and S2 in Figure 1 correspond to the base and 139 enhancement layers in a layered video content, respectively. Repair 140 flow R2 protects the combination of the base and enhancement layer 141 for the receivers who receive both layers, and repair flow R1 142 protects the base layer only, for the receivers who want the base 143 layer only, or who receive both layers but prefer FEC protection for 144 the base layer only due to a bandwidth and/or processing-power 145 limitation. 147 Using multiple FEC Framework instances for a single source flow 148 provides flexibility to the receivers. An example scenario is 149 sketched in Figure 2. Different instances may offer repair flows 150 that are generated by different FEC schemes and receivers choose 151 receiving the appropriate repair flow(s) that they can support and 152 decode. Alternatively, different instances (whether they use the 153 same FEC scheme or not) may use larger and smaller source block 154 sizes, which accommodate the receivers that have looser and tighter 155 latency requirements, respectively. In addition, different instances 156 may also provide FEC protection at different redundancy levels. This 157 is particularly useful in multicast scenarios where different 158 receivers might experience different packet loss rates and each 159 receiver can choose the repair flow that is tailored to its needs. 161 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 162 S3: Source Flow |---------| R3: Repair Flow 163 | 164 |---------| FEC FRAMEWORK INSTANCE #2 165 | R4: Repair Flow 167 Figure 2: Example scenario with two FEC Framework instances, each 168 with a single repair flow protecting the same source flow S3 170 To summarize, the FEC Framework supports the following: 172 1. A source flow MAY be protected by multiple different FEC schemes. 174 2. An FEC scheme MAY generate multiple repair flows. 176 3. Source flows MAY be grouped prior to FEC protection. That is, 177 one or more repair flows MAY protect a group of source flows. 179 Unfortunately, the existing specifications ([RFC3388] and [RFC4756]) 180 have strict requirements that severely limit the use of the 181 flexibility that the FEC Framework provides. In Section 3, we 182 describe what is needed by the FEC Framework and the issues with the 183 existing specifications. In Section 4, we propose two solution 184 approaches. The goal of this document is to start discussions around 185 this topic and motivate the MMUSIC WG to come up with a solution that 186 will address the issues raised here. 188 2. Requirements Notation 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 3. FEC Framework Requirements and Issues with the Existing 195 Specifications 197 3.1. Source and Repair Flow Association 199 Currently, the 'group' attribute and the FEC grouping semantics 200 defined in [RFC3388] and [RFC4756], respectively, are used to 201 associate source and repair flows together. 203 The 'group' attribute is used to group multiple repair flows with one 204 or more source flows. However, [RFC3388] prohibits an "m" line 205 identified by its 'mid' attribute from appearing in more than one 206 "a=group" line using the same semantics. This limitation prevents us 207 from indicating specific associations between the source and repair 208 flows by using an "a=group:FEC" line per FEC Framework instance. For 209 example, for the scenario sketched in Figure 1, [RFC3388] mandates us 210 to write 212 a=group:FEC S1 S2 R1 R2 214 Clearly, this "a=group:FEC" line does not say anything specific about 215 which repair flows are protecting which source flows. Note that 216 source and repair flows are identified by their payload formats 217 and/or other descriptors [I-D.ietf-fecframe-sdp-elements]. 219 3.2. Support for Additivity 221 The FEC Framework also supports additive repair flows. Additivity 222 among the repair flows means that multiple repair flows may be 223 decoded jointly to improve the recovery chances of the missing 224 packets in a single or the same set of source flows. Additive repair 225 flows can be generated by the same FEC scheme or different FEC 226 schemes. 228 For example, in Figure 4, repair flows R5 and R6 may be additive 229 within the FEC Framework instance #1. Alternatively, all three 230 repair flows R5, R6 and R7 could be additive, too. 232 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 233 S4: Source Flow |---------| R5: Repair Flow 234 | | R6: Repair Flow 235 | 236 |---------| FEC FRAMEWORK INSTANCE #2 237 | R7: Repair Flow 239 Figure 4: Example scenario with two FEC Framework instances, where 240 two repair flows in the first instance and a single repair flow in 241 the second instance protect the same source flow S4 243 Currently, there is no SDP semantics for indicating additivity among 244 the repair flows. 246 3.3. Support for Prioritization 248 When there are multiple repair flows protecting a single or the same 249 set of source flows, the sender MAY assign different levels of 250 priority to each repair flow. The sender uses prioritization to let 251 the receivers know in which order the receivers MUST receive and 252 decode the repair flows [I-D.ietf-fecframe-sdp-elements]. Note that 253 the repair flows that are assigned a priority level may be additive 254 or non-additive. 256 A possible scenario where prioritization can be used is that the 257 sender generates two repair flows and sends them in two separate 258 multicast groups. It might be highly desirable to keep all the 259 receivers in the same multicast group to save from the network 260 traffic. The sender can achieve this by assigning a higher priority 261 to one of the repair flows. Another scenario is where one of the 262 repair flows is more expensive in terms of complexity, cost, etc. and 263 the sender wants every receiver to use the less expensive repair flow 264 first. This is again possible by using prioritization. For example, 265 in Figure 4, the sender MAY assign a higher priority to repair flow 266 R5 and a lower priority to repair flow R6. 268 Currently, there is no SDP semantics for indicating the priority 269 levels of the individual flows that are grouped in an "a=group" line. 270 Instead, within the FEC Framework, the priority of a repair flow is 271 described with the optional parameter 'flow-priority' in the "a=fec- 272 repair-flow" line [I-D.ietf-fecframe-sdp-elements], which is used to 273 describe the individual repair flows. However, there might be other 274 benefits of defining more general semantics for flow prioritization 275 in SDP that can be used by other applications and frameworks besides 276 FEC Framework. 278 4. Solution Approaches 280 There are two main solution approaches. 282 4.1. New Grouping Attribute 284 We can define a new grouping attribute that does not have the 285 limitations that [RFC3388] has. Since we do not obsolete [RFC3388], 286 applications using the existing grouping attribute ("a=group") will 287 not be affected and the existing grouping semantics can be used 288 without any complications. Furthermore, any application that does 289 not understand the new grouping attribute MUST ignore it [RFC4566]. 290 This will avoid any backward compatibility issue. 292 Let the new grouping attribute be "gengroup". For the scenario 293 sketched in Figure 1, we can write 294 v=0 295 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 296 s=FEC Grouping Examples - New Grouping Attribute 297 t=0 0 298 a=gengroup:FEC S1 R1 299 a=gengroup:FEC S1 S2 R2 300 m=video 30000 RTP/AVP 100 301 c=IN IP4 224.1.1.1/127 302 a=rtpmap:100 MP2T/90000 303 a=fec-source-flow: id=0 304 a=mid:S1 305 m=video 30000 RTP/AVP 101 306 c=IN IP4 224.1.1.2/127 307 a=rtpmap:101 MP2T/90000 308 a=fec-source-flow: id=1 309 a=mid:S2 310 m=video 30000 RTP/AVP 110 311 c=IN IP4 224.1.2.1/127 312 a=rtpmap:110 parityfec/90000 313 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 314 a=repair-window: 200 ms 315 a=mid:R1 316 m=video 30000 RTP/AVP 111 317 c=IN IP4 224.1.2.2/127 318 a=rtpmap:111 parityfec/90000 319 a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX 320 a=repair-window: 400 ms 321 a=mid:R2 323 which provides the complete association information. For the 324 definitions of the SDP descriptors specific to the FEC Framework, 325 refer to [I-D.ietf-fecframe-sdp-elements]. 327 For the additivity and prioritization issues, let us consider the 328 scenario sketched in Figure 4. Suppose that repair flows R5 and R6 329 are additive but repair flow R7 is not additive with any of the other 330 repair flows. In this case, we can write 332 a=gengroup:FEC S4 R5 R6 333 a=gengroup:FEC S4 R7 335 If none of the repair flows were additive, we could have written 337 a=gengroup:FEC S4 R5 338 a=gengroup:FEC S4 R6 339 a=gengroup:FEC S4 R7 341 If the sender wants to assign priority levels to the repair flows, 342 the priority order may be indicated with the order of the 'mid' 343 values of the repair flows. However, this approach is potentially 344 prone to errors and SHOULD be evaluated carefully whether it covers 345 the corner cases or not. 347 4.2. New Grouping Semantics 349 We can define a new grouping semantics for FEC that does not inherit 350 some of the requirements imposed by [RFC3388]. In particular, the 351 new grouping semantics should ignore the requirement of having the 352 same 'mid' value at most one "a=group" line using the same semantics. 354 Let the new grouping semantics be "genFEC". For the scenario 355 sketched in Figure 1, we can write 357 v=0 358 o=ali 1122334455 1122334466 IN IP4 fec.rocks.com 359 s=FEC Grouping Examples - New Grouping Semantics 360 t=0 0 361 a=group:genFEC S1 R1 362 a=group:genFEC S1 S2 R2 363 m=video 30000 RTP/AVP 100 364 c=IN IP4 224.1.1.1/127 365 a=rtpmap:100 MP2T/90000 366 a=fec-source-flow: id=0 367 a=mid:S1 368 m=video 30000 RTP/AVP 101 369 c=IN IP4 224.1.1.2/127 370 a=rtpmap:101 MP2T/90000 371 a=fec-source-flow: id=1 372 a=mid:S2 373 m=video 30000 RTP/AVP 110 374 c=IN IP4 224.1.2.1/127 375 a=rtpmap:110 parityfec/90000 376 a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X 377 a=repair-window: 200 ms 378 a=mid:R1 379 m=video 30000 RTP/AVP 111 380 c=IN IP4 224.1.2.2/127 381 a=rtpmap:111 parityfec/90000 382 a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX 383 a=repair-window: 400 ms 384 a=mid:R2 386 Similar to the SDP examples given in Section 4.1, the additive repair 387 flows may be listed in the same "a=group:genFEC" line and non- 388 additive repair flows may be listed in separate "a=group:genFEC" 389 lines. The priorities of the repair flows may be signaled by the 390 same approach that was described in Section 4.1. However, a similar 391 careful consideration SHOULD be given to check the corner cases, one 392 example being the case when priorities are assigned to a mix of 393 cross-instance additive and non-additive repair flows. 395 5. Security Considerations 397 There are no security considerations. 399 6. IANA Considerations 401 There are no IANA considerations. 403 7. Acknowledgments 405 The author would like to thank the FEC Framework Design Team, Dan 406 Wing and Flemming Andreasen for their inputs, suggestions and 407 contributions. 409 8. References 411 8.1. Normative References 413 [I-D.ietf-fecframe-framework] 414 Watson, M., "Forward Error Correction (FEC) Framework", 415 draft-ietf-fecframe-framework-01 (work in progress), 416 November 2007. 418 [I-D.ietf-fecframe-sdp-elements] 419 Begen, A., "SDP Elements for FEC Framework", 420 draft-ietf-fecframe-sdp-elements-00 (work in progress), 421 February 2008. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 427 Description Protocol", RFC 4566, July 2006. 429 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 430 Schulzrinne, "Grouping of Media Lines in the Session 431 Description Protocol (SDP)", RFC 3388, December 2002. 433 8.2. Informative References 435 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 436 Session Description Protocol", RFC 4756, November 2006. 438 Author's Address 440 Ali Begen 441 Cisco Systems 442 170 West Tasman Drive 443 San Jose, CA 95134 444 USA 446 Email: abegen@cisco.com 448 Full Copyright Statement 450 Copyright (C) The IETF Trust (2008). 452 This document is subject to the rights, licenses and restrictions 453 contained in BCP 78, and except as set forth therein, the authors 454 retain all their rights. 456 This document and the information contained herein are provided on an 457 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 458 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 459 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 460 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 461 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 462 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 464 Intellectual Property 466 The IETF takes no position regarding the validity or scope of any 467 Intellectual Property Rights or other rights that might be claimed to 468 pertain to the implementation or use of the technology described in 469 this document or the extent to which any license under such rights 470 might or might not be available; nor does it represent that it has 471 made any independent effort to identify any such rights. Information 472 on the procedures with respect to rights in RFC documents can be 473 found in BCP 78 and BCP 79. 475 Copies of IPR disclosures made to the IETF Secretariat and any 476 assurances of licenses to be made available, or the result of an 477 attempt made to obtain a general license or permission for the use of 478 such proprietary rights by implementers or users of this 479 specification can be obtained from the IETF on-line IPR repository at 480 http://www.ietf.org/ipr. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 this standard. Please address the information to the IETF at 486 ietf-ipr@ietf.org. 488 Acknowledgment 490 Funding for the RFC Editor function is provided by the IETF 491 Administrative Support Activity (IASA).