idnits 2.17.1 draft-ott-avt-rtcp-overlay-multicast-02.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.ii 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 == Line 232 has weird spacing: '...ies and media...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 26, 2009) is 5294 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4585' is defined on line 523, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5117 (Obsoleted by RFC 7667) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-18 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT Working Group J. Devadoss 3 Internet-Draft J. Ott 4 Intended status: Informational Helsinki University of Technology 5 Expires: April 29, 2010 I. Curcio 6 Nokia 7 October 26, 2009 9 Real-time Transport Control Protocol (RTCP) in Overlay Multicast 10 draft-ott-avt-rtcp-overlay-multicast-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 April 29, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The Real-time Transport Control Protocol (RTCP) is designed to 49 operate along with Real-time Transport Protocol (RTP) in unicast, 50 single-source multicast and any-source multicast environments. With 51 the availability of overlay multicast and Application Layer Multicast 52 (ALM), the suitability of RTCP in such environments needs to be 53 analyzed. The applicability of the existing RTCP reporting 54 architectures in overlay multicast and ALM environments are 55 investigated and the new features that may be required are discussed 56 in this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Overlay Multicast . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Classifying feedback reporting mechanism . . . . . . . . . . . 6 64 5. Classifying overlay multicast topologies and 65 media/overlay operations . . . . . . . . . . . . . . . . . . . 6 66 6. RTP Entities in an overlay multicast network . . . . . . . . . 6 67 7. Applicability of RTCP reporting as defined in RFC 3550 . . . . 8 68 8. Applicability of RTCP with unicast feedback target . . . . . . 9 69 9. Desirable features of RTCP in overlay multicast . . . . . . . 10 70 10. An example explaining the issues . . . . . . . . . . . . . . . 11 71 11. Some Questions . . . . . . . . . . . . . . . . . . . . . . . . 11 72 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 14. Normative References . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 RTP [RFC3550] provides transport mechanisms suitable for unicast, 80 any-source multicast and single-source multicast. RTP is primarily 81 used to carry audio and video streams together with the RTP control 82 protocol to provide periodic feedback about the media streams 83 received in a specific time interval. The RTCP reporting interval is 84 defined as part of the RTCP and depends on the number of 85 participants, type of participants (sender or receiver) and the 86 operating environment of the session (point to point or multicast). 88 The RFC3550 [RFC3550] specifies the maximum RTCP bandwidth to be 5% 89 of the media bit rate. In point to point sessions, each participant 90 gets an equal share of 2.5% of the media bit rate to be used for 91 RTCP. In multicast (including any-source multicast and source- 92 specific multicast) sessions, the senders usually share 25% of the 93 allocated RTCP bandwidth and the receivers share the remaining 75% of 94 the RTCP bandwidth. The RTCP bandwidth share may be modified using 95 RFC 3556 [RFC3556], but will generally be kept small so as to have a 96 smooth media stream flow. 98 In a multicast session, the RTCP reports are multicast so that each 99 participant can receive the RTCP reports from every other participant 100 and thus obtain a "global" view of the multicast session. This, 101 however, requires multicast connectivity between all peers and thus 102 cannot be applied to Source-specific Multicast (SSM) [RFC3569]. 103 Specific RTCP extensions were developed for SSM 104 [I-D.ietf-avt-rtcpssm] introducing a mechanism of RTCP reporting 105 where the RTCP reports are unicast to a feedback target. This 106 mechanism is specifically applicable in scenarios where many-to-many 107 group communication is not available or not desired or a sender- 108 controlled summarized reporting is preferred. RTCP reports are 109 unicast to a feedback target specified during initialization or 110 inside RTCP reports. The RTCP reporting interval calculation 111 specified in RTCP Extension for SSM uses the same mechanisms as 112 specified in RFC3550 [RFC3550]; the distribution source may send RTCP 113 RSI reports to control the rate at which RTCP reports are generated 114 by the receivers. The aforementioned rules for bandwidth 115 modifications apply as well. 117 Recent interest in overlay multicasting and ALM---to substitute for 118 the lack of globally available native IP any-source multicast--- 119 motivates also carrying RTP-based media streams in such environments. 121 In ALM, the participating nodes form a distribution tree to forward 122 the data. ALM involves the use of different mechanisms to construct 123 and maintain the distribution tree. In overlay multicast, individual 124 multicast enabled networks are connected by virtual unicast links. 126 Overlay multicast involves mechanisms to construct optimal 127 interconnection of virtual links. An ALM can be viewed as a sub 128 class of overlay multicast, if the individual multicast enabled 129 networks have only one participating node. So, further in this 130 document, when we refer to overlay multicast it also includes ALM. 131 Depending on the abstraction chosen for the overlay multicast, the 132 RTP/RTCP entities using it may or may not be aware of the hop-by-hop 133 forwarding of the packets: 135 If they are not, regular any-source multicast operation of RTP and 136 RTCP as per RFC 3550 is a workable, yet possibly not optimal 137 solution. 139 If RTP entities are aware of the forwarding process, additional RTCP 140 reporting and aggregation mechanisms may be applied and the existing 141 RTCP reporting mechanisms need to be investigated for their 142 applicability in overlay multicast 144 In either case, in an overlay multicast environment, using RTP to 145 transport media streams will be straightforward, 147 In this document, we take a very first stab at reviewing the RTCP 148 reporting mechanism specified in RFC3550 [RFC3550] and the RTCP 149 Extension for SSM to find its applicability in the overlay multicast 150 environment. We also discuss on the specific characteristics of the 151 overlay multicast and the type of reporting that is desired on such 152 environments. This document also complements the RTP topologies 153 overview [RFC5117]. 155 2. Terminology 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 BCP 14, RFC 2119 160 [RFC2119] and indicate requirement levels for compliant 161 implementations. 163 The terminology defined in RTP [RFC3550], the RTP Profile for Audio 164 and Video Conferences with Minimal Control [RFC3551], and the RTCP 165 Extension for SSM [I-D.ietf-avt-rtcpssm], apply. 167 For the time being, in this document, by overlay multicast we refer 168 to a multicast overlay offering media distribution from a single 169 source, analogous to SSM. 171 3. Overlay Multicast 173 In overlay multicast, the media streams are multicast over an network 174 of virtual links that is constructed using mechanisms in line with 175 the requirements of the application using the overlay. The 176 construction and maintenance of the overlay involves mechanisms for 177 bootstrapping and connecting new participants to the overlay, 178 routing, pro-active/reactive repair, improving scalability and 179 recovery from loss of a forwarding node or a virtual link. In this 180 document, these mechanisms are further referred to as overlay 181 operation. As the overlay network is formed by the participating 182 nodes, the loss of a participating node brings change in the network 183 structure. So, there is an inherent instability in the overlay 184 multicast which are addressed by the overlay operation. 186 In overlay multicast, the participating nodes can use mechanisms for 187 providing error resilience and congestion control that can pro- 188 actively adapt or reactively repair the media streams depending on 189 the receiver metrics reported by the nodes below its hierarchy. In 190 this document, the error resilience mechanisms together with 191 congestion control techniques are further referred to as media 192 operation. 194 The media operation depends on the metrics (reported reception 195 quality) reported by the participants. The overlay operation can 196 depend on different types of metrics and may also include the media 197 quality metrics like round trip time, observed packet loss, jitter 198 etc. As the overlay operation depends on the application using the 199 overlay, there can be significant overlap with the metrics used by 200 media operation. 202 Using RTP in overlay multicast does not require any change to its 203 specification. Every participating node that receives the RTP packet 204 replicates the packet and sends down the distribution tree. RTCP SR 205 follows the same path as RTP, so it does not bring in changes with 206 its use in overlay multicast. In the case of RTCP RR, it reports the 207 receiver's perceived media quality and it carries significant data 208 based on which the algorithms of media and/or overlay operation can 209 operate. 211 The multicast overlay maintenance mechanisms may operate entirely 212 independent of RTCP reporting, they may choose to leverage parts of 213 the RTCP reporting, or they may rely entirely on RTCP. In this 214 document, we are concerned about the operation of RTCP reporting in 215 such an environment and we do not take (at this point) any position 216 on the way the overlay operates. 218 4. Classifying feedback reporting mechanism 220 Any feedback reporting mechanism in a session with n participants can 221 be classified into one of the following categories. 222 o (i) 1 to 1 reporting 223 o (ii) 1 to n reporting 224 o (iii) 1 to m reporting (m < n, every node reports to m nodes) 225 An example of '1 to 1' reporting is RTCP in SSM with unicast feedback 226 target (and, of course, in case of point-to-point sessions). An 227 example of '1 to n' reporting is RTCP in multicast mode as specified 228 in RFC 3550. In further sections, we shall be referring to these 229 mechanisms while discussing the applicability of a RTCP reporting 230 model. 232 5. Classifying overlay multicast topologies and media/overlay 233 operations 235 The effectiveness of a chosen RTCP reporting model, directly depends 236 on the type of overlay multicast topology, type of the media/overlay 237 operation and the number of participants in the session. So, when 238 considering the applicability of a RTCP reporting model, they need to 239 be evaluated against the every possible combinations of overlay 240 multicast topology, media and overlay operation. The overlay 241 multicast topologies can be broadly classified into two categories. 242 o (i) Overlay multicast, with no or very minimal overlay 243 operations(virtual links are statically configured) 244 o (ii) Overlay multicast, that relies on overlay operations to 245 dynamically configure distribution tree. 246 The overlay and media operations can be classified into two 247 categories. 248 o (i) Centralized: A single entity decides on the type of media/ 249 overlay operations. 250 o (ii) Distributed: At any instant more than one entity is 251 attempting to perform media/overlay operation. 253 6. RTP Entities in an overlay multicast network 255 The below figure represents a sample overlay multicast network. In 256 this section, we see how the RTP entities can be used to describe a 257 overlay multicast network. 259 o(0) -Media source 260 / \ 261 / \ 262 --------o(OMN1) o(OMN2) OMN -> Overlay Multicast Node 263 | IP |\\ /\ 264 |multicast||| / \ 265 |network ||| / \ 266 --------- || OMN5 OMN6 ___ OMN7 267 _____|| \ 268 / \ \___ OMN8 269 ---o(OMN3) \ (OMN4)---- 270 | IP | \o IP | 271 |multicast| |multicast| 272 |network | |network | 273 --------- --------- 275 Figure 1: A sample overlay multicast topology 277 Each OMN can be considered as an entity with an RTP translator, an 278 optional instance of RTCP feedback target, and an optional media 279 repair agent (media handler). The purpose of the translator is to 280 replicate and forward the streams to different network destinations. 281 The feedback target handles incoming RTCP reports, possibly 282 aggregating, and forwarding them. The media repair agent receives 283 RTP streams (possibly storing them temporarily), processes received 284 RTCP reports and may perform media repair, and generates RTCP 285 receiver reports. In the above figure, the translator in OMN1 286 receives the stream from media source and forwards it to three 287 different network clouds. 289 Role of RTP Translator in forwarding RTP streams: The RTP translator 290 in each OMN forwards the received RTP packets (from its parent node) 291 to all virtual links it is connected with. For example, RTP 292 translator in OMN1 forwards RTP packets to its RTP media handler, 293 OMN3, OMN4 and the IP multicast network it is connected with. 295 Role of RTP Translator in handling RTCP reports: When there is no 296 change to the media encoding, the RTP translator uses the straight 297 case of Replicate and Forward mechanism. 299 Replicate and Forward: The RTP translator replicates and forwards the 300 RTCP RR received from one virtual link to all other virtual links. 301 Below, we explain using OMN1 as example. The RTP translator in OMN1 302 receives RTCP RR from, 303 o the media handler (which is within the same node) 304 o the native multicast network 305 o OMN3 306 o OMN4 307 o parent OMN (which is forwarding the RTCP RRs received from the 308 other virtual links, it is connected with) 310 To explain the RTCP forwarding rules, we take an sample event where 311 the translator in OMN1 receives a RTCP RR from IP multicast network. 312 The event response shall be that, it is forwarded to the media 313 handler (within OMN1), OMN3, OMN4 and to the parent node (in the case 314 of OMN1, it is media source). In this way, all participating nodes 315 in the session shall receive RTCP RR from all other participating 316 nodes. 318 In the overlay multicast scenario, the RTP translator in an OMN can 319 be extended to do other operations like filtering and aggregating 320 RTCP reports. But to realize it, the scope and definitions of RTP 321 translator need to be analyzed to see if it has support for it. 323 7. Applicability of RTCP reporting as defined in RFC 3550 325 If this reporting mechanism is to be used in an overlay multicast, 326 then the RTP translator in each node replicates and forwards the RTCP 327 reports on all (virtual) links except the incoming (virtual) link. 328 It is a form of '1 to n' reporting, where all participants get a copy 329 of the RTCP report sent by every other participant. Now, let us look 330 at the effectiveness of this reporting model in the overlay multicast 331 environment. 333 With the increase in number of receivers, the RTCP reporting interval 334 increases. The larger the reporting interval, fewer the options 335 available for media operation. For example, with 'x' number of 336 participants, it can be possible to do retransmission based on an 337 RTCP report indicating a lost packet. But with the increasing number 338 of participants (say n*x), the interval gets bigger by n times 339 leading to fewer options of error repair mechanisms. In IP 340 multicast, the error resilience mechanisms like adaptive FEC, 341 retransmission can be performed only by the source or one designated 342 participant/observer. But in the case of overlay multicast, there 343 are more options available to deploy these mechanisms at intermediary 344 nodes which become an inherent part of the forwarding tree. 345 Furthermore, the importance of overlay operation increases with 346 increasing number of participants: the larger the number of nodes, 347 the greater the importance of overlay operation in maintaining 348 stability i.e., the importance of the reports that influence the 349 quality of the overlay operation grows. 351 The proportional relationship of number of nodes with the RTCP 352 reporting interval was designed to limit the bandwidth consumed by 353 the RTCP and provide scalability so as to evolve as a multicast 354 session with many number of participants. But in the overlay 355 multicast scenario, with the reducing number of reports per time unit 356 the quality of the overlay is reduced due to reduced effectiveness of 357 media and overlay operation. 359 In contrast to any-source multicast, however, the RTCP reports sent 360 by a particular node are not automatically received by all other 361 nodes. Instead, the RTCP reports travel along the virtual links 362 formed between participating nodes. This may be used to limit their 363 spread and may allow for mechanisms improving overall efficiency of 364 RTCP reporting. Thus, while the total number of participants in an 365 RTP session limits the RTCP bandwidth consumption within 5% of the 366 media session, this limit may not need to be applied the total 367 consumption across the entire overlay multicast, but be maintained in 368 local regions only. 370 8. Applicability of RTCP with unicast feedback target 372 If RTCP/SSM reporting mechanism is to be used in an overlay 373 multicast, then the RTCP RR reports are unicast to a designated node 374 that is either within or outside the overlay multicast. It is a form 375 of '1 to 1' reporting and here we discuss on its applicability in the 376 overlay multicast. 378 RTCP/SSM defines the use of a single distribution source in 379 conjunction with one or more feedback targets. If multiple feedback 380 targets are to be used, their respective setup and coordination is 381 outside the scope of the RTCP/SSM specification. Conceptually, 382 however, the RTCP/SSM mechanisms support the idea of hierarchical 383 report aggregation and forwarding, even though the RTP media as well 384 as the RTCP sender reporting distribution paths are supposed to use 385 SSM multicasting at the IP layer. This notion of RTCP aggregation 386 would need to become more explicit, but could provide a first basis 387 for realizing overlay multicast. 389 Overlay multicast also provides explicit support for using 390 intermediary (participating nodes in the distribution tree) media 391 error resilience mechanisms. Stepwise RTCP aggregation would also 392 make the necessary feedback information available to the individual 393 intermediate nodes and could thus provide the hook for invoking 394 repair mechanisms. 396 The (kind of) centralized reporting and centralized decision making 397 in RTCP/SSM would need to be expanded to allow for more flexible 398 media and/or overlay operation and, in particular, would need to 399 cover the assignment and maintenance of feedback targets as regular 400 part of the overlay operation. 402 An interesting issue is whether this source-specific type of 403 operation could be expanded later towards multi-source operation in 404 order to support any-source multicast overlays as well. While RTCP/ 405 SSM seems to be a promising starting point, this latter step is left 406 for further study. 408 9. Desirable features of RTCP in overlay multicast 410 The following list is an initial set of desirable functions for 411 media/overlay operation: 412 o Need for a mechanism of RTCP reporting, where the reporting 413 interval is decoupled from the number of participants in the media 414 session. But still the original reason behind this linkage 415 (limiting the RTCP bandwidth consumption) can be maintained 416 through other suitable mechanisms. In essence, fine-granular RTCP 417 reporting could be confined to subgroups while the global 418 bandwidth limitation is still maintained. 419 o Overlay multicast brings in the option to use media operation at 420 intermediate nodes. With more frequent reporting, their 421 effectiveness increases. So, to increase the reporting frequency 422 and at the same time limit the bandwidth consumption, a RTCP RR 423 reporting mechanism that provides the feature of '1 to m'(n > m, n 424 - number of participants in the session) reporting is needed. By 425 choosing a small m, the RTCP RR reporting frequency can be 426 increased as it is directed only to a small subset of 427 participating nodes. Such subset reporting could be carried out 428 at a single hierarchy level inside an overlay multicast or across 429 multiple such levels. 430 o Media operation should be able to leverage the additionally 431 available reporting information to optimize performance (for error 432 control, possibly congestion control, etc.) 433 o Overlay operation can be either centralized or distributed. For 434 example, the decisions related to overlay operations can be made 435 only by a single node for the whole network or can be distributed 436 to many groups, with each groups making the decisions depending on 437 the collected metrics. In the later form of overlay operation, 438 the availability of '1 to m' reporting provides timely and more 439 precise information for the algorithms used in the overlay 440 operation. As each group can act independent from the other 441 groups, there may not be a need for reporting across the groups 442 but there may be a need for a higher reporting frequency within 443 the group. 445 10. An example explaining the issues 447 We take the below example for explaining the desired form of RTCP 448 reporting in overlay multicast. 450 o(0) -Media source 451 / \ 452 / \ 453 / \ 454 o(1) o(2) 455 /|\ /|\ 456 / | \ / | \ 457 o o o o o o 458 (3)(4)(5) (6)(7)(8) 460 Figure 2: A sample overlay multicast topology 462 In the above figure, the nodes {1, 3, 4 and 5} and {2, 6, 7 and 8} 463 are considered as a group with node 1 and 2 acting as their 464 respective group leaders. The overlay operation involves changing 465 the group leader based on the metrics reported by the participating 466 nodes. In this form overlay network, the media operation can also be 467 performed by nodes other than source(for example nodes 1 and 2). 469 In the above example, the nodes {1, 3, 4 and 5} are more interested 470 in RTCP reports from the nodes within their group rather than in the 471 RTCP reports from {6 or 7 or 8}. So, if RTCP reporting interval is 472 to be proportional to the number of participants in the session, then 473 the individual groups see reduced reporting due to the increase in 474 the number of participants. This reduces the effectiveness of both 475 media and overlay operation. 477 The paper "Construction of an Efficient Overlay Multicast 478 Infrastructure for Real-time Applications" is an overlay multicast 479 solution, that dynamically re-arranges the distribution tree based on 480 the metrics reported(or measured with) 'm' other nodes. 481 (http://www.ieee-infocom.org/2003/papers/37_03.PDF) 483 11. Some Questions 485 o How are the individual regions (if any) for fine-grained reporting 486 to be modeled? Should they form separate RTP sessions or be just 487 a part of the (single) regular session? 488 o Do the existing RTP entities suffice or need new ones be 489 introduced? For example, should an RTP Forwarder be defined as an 490 entity performing functions of intermediate nodes? 492 o Should RTCP flow only along the established multicast distribution 493 tree (it may have to for NAT traversal reasons) or should more 494 complex forms of reporting be supported? 495 o How will distribution along multiple trees be addressed? 496 o Should the overlay operation be considered at all? As a minimum, 497 the overlay operation could tap into information provided by RTCP 498 anyway; as an intermediate step, RTCP could be expanded modestly 499 to support certain types of overlay operation; at the other end of 500 the spectrum, the overlay operation could rely on RTCP alone. 502 12. Security Considerations 504 TBD. 506 13. IANA Considerations 508 There are no specific IANA action necessary for this document. 510 14. Normative References 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, March 1997. 515 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 516 Jacobson, "RTP: A Transport Protocol for Real-Time 517 Applications", STD 64, RFC 3550, July 2003. 519 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 520 Video Conferences with Minimal Control", STD 65, RFC 3551, 521 July 2003. 523 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 524 "Extended RTP Profile for Real-time Transport Control 525 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 526 July 2006. 528 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 529 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 530 RFC 3556, July 2003. 532 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 533 January 2008. 535 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 536 Multicast (SSM)", RFC 3569, July 2003. 538 [I-D.ietf-avt-rtcpssm] 539 Schooler, E., Ott, J., and J. Chesterfield, "RTCP 540 Extensions for Single-Source Multicast Sessions with 541 Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in 542 progress), March 2009. 544 Authors' Addresses 546 Jegadish Devadoss 547 Helsinki University of Technology 548 Otakaari 5 A 549 Espoo, FIN 02150 550 Finland 552 Email: jegadish@netlab.tkk.fi 554 Joerg Ott 555 Helsinki University of Technology 556 Otakaari 5 A 557 Espoo, FIN 02150 558 Finland 560 Email: jo@netlab.hut.fi 562 Igor D.D. Curcio 563 Nokia 564 P.O. Box 1000 (Visiokatu 1) 565 Tampere, FIN 33721 566 Finland 568 Email: igor.curcio (at) nokia.com