AVT Working Group J. Devadoss Internet-Draft J. Ott Intended status: Informational Helsinki University of Technology Expires: April 30, 2009 I. Curcio Nokia October 27, 2008 Real-time Transport Control Protocol (RTCP) in Overlay Multicast draft-ott-avt-rtcp-overlay-multicast-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30, 2009. Abstract The Real-time Transport Control Protocol(RTCP) is designed to operate along with Real-time Transport Protocol(RTP) in unicast, single- source multicast and any-source multicast environments. With the availability of overlay multicast, the suitability of RTCP in such an environment need to be analyzed. The applicability of the existing RTCP reporting architectures in an overlay multicast environment is investigated and the new features that may be required are discussed in this document. Devadoss, et al. Expires April 30, 2009 [Page 1] Internet-Draft RTCP in Overlay Multicast October 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overlay Multicast . . . . . . . . . . . . . . . . . . . . . . 4 4. Classifying feedback reporting mechanism . . . . . . . . . . . 5 5. Applicability of RTCP reporting as defined in RFC 3550 . . . . 6 6. Applicability of RTCP with unicast feedback target . . . . . . 7 7. Desirable features of RTCP in overlay . . . . . . . . . . . . 7 8. An example explaining the issues . . . . . . . . . . . . . . . 8 9. Some Questions . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Devadoss, et al. Expires April 30, 2009 [Page 2] Internet-Draft RTCP in Overlay Multicast October 2008 1. Introduction RTP [RFC3550] provides transport mechanisms suitable for unicast, any-source multicast and single-source multicast. RTP is used to carry audio and video streams together with the RTP control porotocl to provide periodic feedback about the media streams received in a specific duration. The RTCP reporting interval is defined as part of the RTCP and depends on the number of participants, type of participants(sender or receiver) and the operating environment of the session(point to point or multicast). The RFC3550 [RFC3550] specifies the maximum RTCP bandwidth to be 5% of the media bit rate. In point to point sessions, each participant gets a equal share of 2.5% of the media bit rate to be used for RTCP. In multicast (including any-source multicast and source-specific multicast) sessions, the senders usually share 25% of the allocated RTCP bandwidth and the receivers share the remaining 75% of the RTCP bandwidth. The RTCP bandwidth share may be modified using RFC 3556 [RFC3556], but will generally be kep small to avoid impact the media streams. In a multicast session, the RTCP reports are multicast so that each participant can receive the RTCP reports from every other participant and thus obtain a "global" view of the multicast session. This, however, requires multicast connectivity between all peers and thus cannot be applied to Source-specific Multicast (SSM) [RFC3569]. Specific RTCP extensions were developed for SSM [I-D.ietf-avt-rtcpssm] introducing a mechanism of RTCP reporting where the RTCP reports are unicast to a feedback target. This mechanism is specifically applicable in scenarios where many-to-many group communication is not available or not desired or a sender- controlled summarized reporting is desired. RTCP reports are unicast to a feedback target specified during initialization or inside RTCP reports. The RTCP reporting interval calculation specified in RTCP Extension for SSM uses the same mechanisms as specified in RFC3550 [RFC3550]; the distribution source may RTCP RSI reports to control the rate at which RTCP reports are generated by the received. The aforementioned rules for bandwidth modifications apply as well. Recent interest in overlay multicasting---to substitute for the lack of native IP any-source multicast---motivates also carrying RTP-based media streams in such environments. In overlay multicast, the participants create virtual unicast links over which media streams are relplicated and forwarded, thus creating the illusion of IP multicast. Depending on the abstraction chosen for such an overlay, the RTP/RTCP entities using it may or may not be aware of the hop-by- hop forwarding of the packets: Devadoss, et al. Expires April 30, 2009 [Page 3] Internet-Draft RTCP in Overlay Multicast October 2008 If they are not, regular any-source multicast operation of RTP and RTCP as per RFC 3550 is a workable, yet possibly not optimal solution. If RTP entities are aware of the forwarding process, additional RTCP reporting and aggregation mechanisms may be applied and the existing RTCP reporting mechanisms need to be investigated for their applicability in overlay multicast In either case, in an overlay mulicast environment, using RTP to transport media streams will be straightforward, In this document, we take a very first stab at reviewing the RTCP reporting mechanism specified in RFC3550 [RFC3550] and the RTCP Extension for SSM to find its applicability in the overlay multicast environment. We also discuss on the specific characteristics of the overlay multicast and the type of reporting that is desired on such environments. The next revision of this document will also take the roles of RTP mixers and translators into consideration. This document complements the RTP topologies overview [RFC5117]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. The terminology defined in RTP [RFC3550], the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], and the RTCP Extension for SSM(add in reference), apply. For the time being, in this document, by overlay multicast we refer to a multicast overlay offering media distribution from a single source, analoguous to SSM. 3. Overlay Multicast In overlay multicast, the media streams are multicast over an network of virtual links that is constructued using mechanisms in line with the requirements of the application using the overlay. The construction and maintenance of the overlay involves mechanisms for bootstrapping the new participant to the overlay, routing, pro- active/reactive repair, improving scalability and recovery from loss of a forwarding node or a virtual link. In this document, these Devadoss, et al. Expires April 30, 2009 [Page 4] Internet-Draft RTCP in Overlay Multicast October 2008 mechanisms are further referred to as overlay operation. As the overlay network is formed by the participating nodes, the loss of a participating node brings change in the network structure. So, there is an inherent instability in the overlay multicast which are addressed by the overlay operation. In overlay multicast, the participating nodes can use mechanisms for providing error resilience and congection control that can proactively adapt or reactively repair the media streams depending on the receiver metrics reported by the nodes below its hierarchy. In this document, the error resilience mechanisms together with congestion control techniques are further referred to as media operation. The media operation depends on the metrics (reported reception quality) reported by the participants. The overlay operation can depend on different types of metrics and may also include the media quality metrics like round trip time, observed packet loss, jitter etc. As the overlay operation depends on the application using the overlay, there can be significant overlap with the metrics used by media operation. Using RTP in overlay multicast does not require any change to its specification. Every participating node that receives the RTP packet replicates the packet and sends down the distribution tree. RTCP SR follows the same path as RTP, so it does not bring in changes with its use in overlay multicast. In the case of RTCP RR, it reports the receiver's perceived media quality and it carries significant data based on which the algorithms of media and/or overlay operation can operate. The multicast overlay maintenance mechanisms may operate entirely independent of RTCP reporting, they may choose to leverage parts of the RTCP reporting, or they may rely entirely on RTCP. In this document, we are concerned about the operation of RTCP reporting in such an environment and we do not take (at this point) any position on the way the overlay operates. 4. Classifying feedback reporting mechanism Any feedback reporting mechanism in a session with n participants can be classified into one of the following categories. o (i) 1 to 1 reporting o (ii) 1 to n reporting o (iii) 1 to m reporting (m < n, every node reports to m nodes) An example of '1 to 1' reporting is RTCP in SSM with unicast feedback target (and, of course, in case of point-to-point sessions). An Devadoss, et al. Expires April 30, 2009 [Page 5] Internet-Draft RTCP in Overlay Multicast October 2008 example of '1 to n' reporting is RTCP in multicast mode as specifed in RFC 3550. In further secitons, we shall look into an example of each of the type and their applicability to the overlay multicast. 5. Applicability of RTCP reporting as defined in RFC 3550 If this reporting mechanism is to be used in an overlay multicast, then the RTCP reports are replicated and forwarded on all (virtual) links except the incoming (virtual) link. It is a form of '1 to n' reporting, where all participants get a copy of the RTCP report sent by every other participant. Now, let us look at the effectiveness of this reporting model in the overlay multicast environment. With the increase in number of receivers, the RTCP reporting interval increases. The larger the reporting interval, the fewer the options available for media operation. For example, with 'x' number of participants, it can be possible to do retransmission based on an RTCP report indicating a lost packet. But with the increasing number of participants (say n*x), the interval gets bigger by n times leading to fewer options of error repair mechanisms. In IP multicast, the error resilience mechanisms like adaptive FEC, retransmission can be performed only by the source or one designated participant/observer. But in the case of overlay multicast, there are more options available to deploy these mechanisms at intermediary nodes which become an inherent part of the forwarding tree. Furthermore, the importance of overlay operation increases with increasing number of participants: the larger the number of nodes, the greater the importance of overlay operation in maintaining stability i.e., the importance of the reports that influence the quality of the overlay operation grows. The proportional relationship of number of nodes with the RTCP reporting interval was designed to limit the bandwidth consumed by the RTCP and provide scalability so as to evolve as a multicast session with many number of participants. With the reducing number of reports per time unit the quality of the overlay is reduced due to reduced effectiveness of media and overlay operation. In contrast to any-source multicast, however, the RTCP reports sent by a particular are not automatically received by all other nodes. Instead, the RTCP reports travel along the virtual links formed between participating nodes. This may be used to limit their spread and may allow for mechanisms improving overall efficiency of RTCP reporting. Thus, while the total number of participants in an RTP session limits the RTCP bandwidth consumption within 5% of the media session, this limit may not need to be applied the total consumption across the entire overlay multicast, but be maintained in local regions only. Devadoss, et al. Expires April 30, 2009 [Page 6] Internet-Draft RTCP in Overlay Multicast October 2008 The precise mapping to RTP mixers and translators is yet to be defined. 6. Applicability of RTCP with unicast feedback target If RTCP/SSM reporting mechanism is to be used in an overlay multicast, then the RTCP RR reports are unicast to a designated node that is either within or outside the overlay multicast. It is a form of '1 to 1' reporting and here we discuss on its applicability in the overlay multicast. RTCP/SSM defines the use of a single distribution source in conjunction with one or more feedback targets. If multiple feedback targets are to be used, their respective setup and coordination is outside the scope of the RTSP/SSM specification. Conceptually, however, the RTCP/SSM mechanisms support the idea of hierarchical report aggregation and forwarding, even though the RTP media as well as the RTCP sender reporting distribution paths are supposed to use SSM multicasting at the IP layer. This notion of RTCP aggregation would need to become more explicit, but could provide a first basis for realizing overlay multicast. Overlay multicast also provides explicit support for using intermediary (participating nodes in the distribution tree) media error resilience mechanisms. Stepwise RTCP aggregation would also make the necessary feedback information available to the individual intermediate nodes and could thus provide the hook for invoking repair mechanisms. The (kind of) centralized reporting and centralized decision making in RTCP/SSM would need to be expanded to allow for more flexible media and/or overlay operation and, in particular, would need to cover the assignment and maintenance of feedback targets as regular part of the overlay operation. An interesting issue is whether this source-specific type of operation could be expanded later towards multi-source operation in order to support any-source multicast overlays as well. While RTCP/ SSM seems to be a promising starting point, this latter step is left for further study. 7. Desirable features of RTCP in overlay The following list is an initial set of desirable functions for overlay operation: Devadoss, et al. Expires April 30, 2009 [Page 7] Internet-Draft RTCP in Overlay Multicast October 2008 o Need for a mechanism of RTCP reporting, where the reporting interval is decoupled from the number of participants in the media session. But still the original reason behind this linkage (limiting the RTCP bandwidth consumption) can be maintained through other suitable mechanisms. In essence, fine-granular RTCP reporting could be confined to subgroups while the global bandwidth limitation is still maintained. o Overlay multicast brings in the option to use media operation at intermediate nodes. With more frequent reporting, their effectiveness increases. So, to increase the reporting frequency and at the same time limit the bandwidth consumption, a RTCP RR reporting mechanism that provides the feature of '1 to m'(n > m, n - number of participants in the session) reporting is needed. By choosing a small m, the RTCP RR reporting frequency can be increased as it is directed only to a small subset of participating nodes. Such subset reporting could be carried out at a single hierarchy level inside an overlay multicast or across multiple such levels. o Media operation should be able to leverage the additionally available reporting information to optimize performance (for error control, possibly congestion control, etc.) o Overlay operation can be either centralized or distributed. For example, the decisions related to overlay operations can be made only by a single node for the whole network or can be distributed to many groups, with each groups making the decisions depending on the collected metrics. In the later form of overlay operation, the availability of '1 to m' reporting provides timely and more precise information for the algorithms used in the overlay operation. As each group can act independent from the other groups, there may not be a need for reporting across the groups but there may be a need for a higher reporting frequency within the group. 8. An example explaining the issues We take the below example for explaining the desired form of RTCP reporting in overlay multicast. Devadoss, et al. Expires April 30, 2009 [Page 8] Internet-Draft RTCP in Overlay Multicast October 2008 o(0) -Media source / \ / \ / \ o(1) o(2) /|\ /|\ / | \ / | \ o o o o o o (3)(4)(5) (6)(7)(8) Figure 1: A sample overlay multicast topology In the above figure, the nodes {1, 3, 4 and 5} and {2, 6, 7 and 8} are considered as a group with node 1 and 2 acting as their respective group leaders. The overlay operation involves changing the group leader based on the metrics reported by the participating nodes. In this form overlay network, the media operation can also be performed by nodes other than source(for example nodes 1 and 2). In the above example, the nodes {1, 3, 4 and 5} are more interested in RTCP reports from the nodes within their group rather than in the RTCP reports from {6 or 7 or 8}. So, if RTCP reporting interval is to be proportional to the number of participants in the session, then the individual groups see reduced reporting due to the increase in the number of participants. This reduces the effectiveness of both media and overlay operation. 9. Some Questions o Do the existing RTP entities suffice or need new ones be introduced? For example, should an RTP Forwarder be defined as an entity performing functions of intermediate nodes? o How are the individual regions (if any) for fine-grained reporting to be modeled? Should they form separate RTP sessions or be just a part of the (single) regular session? o Should RTCP flow only along the established multicast distribution tree (it may have to for NAT traversal reasons) or should more complex forms of reporting be supported? o How will distribution along multiple trees be addressed? o So far, we only worry about making RTP and RTCP work. Should the overlay operation be considered at all? As a minimum, the overlay operation could tap into information provided by RTCP anyway; as an intermediate step, RTCP could be expanded modestly to support certain types of overlay operation; at the other end of the spectrum, the overlay operation could rely on RTCP alone. Devadoss, et al. Expires April 30, 2009 [Page 9] Internet-Draft RTCP in Overlay Multicast October 2008 10. Security Considerations TBD. 11. IANA Considerations There are no specific IANA action necessary for this document. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [I-D.ietf-avt-rtcpssm] Ott, J., "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 (work in progress), January 2008. Devadoss, et al. Expires April 30, 2009 [Page 10] Internet-Draft RTCP in Overlay Multicast October 2008 Authors' Addresses Jegadish Devadoss Helsinki University of Technology Otakaari 5 A Espoo, FIN 02150 Finland Email: jegadish@netlab.tkk.fi Joerg Ott Helsinki University of Technology Otakaari 5 A Espoo, FIN 02150 Finland Email: jo@netlab.hut.fi Igor D.D. Curcio Nokia P.O. Box 88 (Tieteenkatu 1) Tampere, FIN 33721 Finland Email: igor.curcio (at) nokia.com Devadoss, et al. Expires April 30, 2009 [Page 11] Internet-Draft RTCP in Overlay Multicast October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Devadoss, et al. Expires April 30, 2009 [Page 12]