SAMRG T. Li Internet-Draft Z. Sun Intended status: Standards Track H. Wang Expires: January 13, 2012 C. Jia NUDT July 12, 2011 P2MP Streaming Media Delivery Problem Statement draft-litao-p2mpsmd-problem-statement-01 Abstract Currently, more and more Internet streaming services are getting increasingly popular among users. Recent large-scale deployed delay- and loss-sensitive services, such as IPTV, impose stringent requirements to the streaming media delivery. Streaming media service providers and operators have been struggling to make the QoE of the subscribers at a satisfactory level. However, most of the existing P2MP streaming media delivery technologies, such as IP multicast, are far from ideal in the aspects of scalability, reliability and stability. This document presents the problem statements in point to multipoint streaming media delivery, explains why network awareness and policy-based routing control should be urgently addressed for the point to multipoint streaming media delivery mechanism and introduces what should be further considered in the future. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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 Li, et al. Expires January 13, 2012 [Page 1] Internet-Draft P2MP Streaming Media Delivery July 2011 material or to cite them other than as "work in progress." This Internet-Draft will expire on January 13, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Li, et al. Expires January 13, 2012 [Page 2] Internet-Draft P2MP Streaming Media Delivery July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement Scope . . . . . . . . . . . . . . . . . . . 5 4. Architecture Requirements . . . . . . . . . . . . . . . . . . 7 4.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 7 5. Why IETF Needs to Develop Solutions Instead of Relying on Existing Technologies? . . . . . . . . . . . . . . . . . . . . 7 5.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. RTP/RTCP Extensions of IP Multicast . . . . . . . . . . . 8 5.3. Overlay(CDN P2P) . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Li, et al. Expires January 13, 2012 [Page 3] Internet-Draft P2MP Streaming Media Delivery July 2011 1. Introduction Streaming traffic is among the fastest growing traffic on the Internet. As streaming media delivery has characteristics of long- live connection and high stable transmission rate, the Internet capacity is imposed with stringent requirements of high bandwidth, low delay and jitter, and low packet loss. The situation is further complicated by frequent load variations from the dynamic behavior of large asynchronous clients. The current Internet faces many challenges from the core to the edge, as its end-to-end design principle with best-effort service cannot be well suited for point to multipoint (P2MP) streaming media delivery application. From an ISP's perspective, the Internet bandwidths are relatively scarce and precious resources, especially in the core network. When end-to-end unicast technology is used for the streaming media delivery over the Internet, a separated point-to-point connection (e.g., UDP/TCP connections) is employed between the sender and each receiver. It leads to the poor use of the available bandwidth due to the multiple copies of streaming media object on the same link. It is desirable for ISP that an efficient P2MP delivery mechanism is established for delivering copies of the streaming media data to multiple recipients at different locations, in order to minimize the amount of the required network resources (usually in terms of bandwidth). From an end-user's perspective, quality of experience (QoE) is widely appreciated as an important subjective measurement for the streaming media delivery service, such as IPTV, VoD. Usually, the quality of service (QoS) metrics (such as network delay, jitter and packet loss), rather than QoE, is used for the objective measure of the streaming media delivery service. With the dramatic improvement in digital video quality (like High Definition) and the prevalence of streaming media applications, the Internet is facing with significant challenges in providing QoS insurance. It is essential to build an efficient P2MP streaming media delivery mechanism for an optimal end- user experience. The better the QoE is, the more likely the end- users subscribe streaming media service, which benefits both ISPs and the content providers. From a service provider's perspective, a service network requires efficient and low-cost deployment, maintenance and management. However, the existing distributed routing models and protocols for P2MP streaming media delivery cannot provide enough support to fulfill the above requirements. It is crucial for network fundamental infrastructure to provide efficient protocol and mechanisms, such that the service providers can rapidly and automatically monitor, detect and troubleshoot performance issues in Li, et al. Expires January 13, 2012 [Page 4] Internet-Draft P2MP Streaming Media Delivery July 2011 the service networks. The motivation of this document is to clarify the problems facing the P2MP streaming media delivery. 2. Terminology Qaulity of Experience (QoE): The overall acceptability of an application or service, as perceived subjectively by the end- user[ITU-TP]. Quality of Service (QoS): The collective effect of performance which determines the degree of satisfaction of a user of the service[ITU-T]. Streaming Media Service Provider(SMSP): A company that offers delivering streaming media services such as providing video content, improving network performance, and enhancing transmission quality, etc. 3. Problem Statement Scope There are a number of problems related to the P2MP streaming media delivery. The two major issues are listed below. (1) The difficulty of network state information (NSI) acquisition. Unpredictable behaviors of users present unusual challenges to the network delivering P2MP streaming media. The links and network elements (routers and switches) experience rapid and large-scale changes in bandwidth availability. Therefore, the congestion may occur frequently over time and space, which introduces delays and jitters to the flows of streaming media. That is adverse to the streaming media delivery due to its stringent demands on discontinuity-free and high stable transmission rate. Network-aware streaming media delivery is an attractive approach to mitigate the problems. It plays a very important role in delivering timely and accurate information for supporting well-founded adaption decisions in monitoring, diagnostics and failure restoration. However, the exact information about the current condition of the network is hard to obtain for adapting the resource demands for QoS. Some NSI can be derived from the transport level or directly from the application level. NSI acquisition at application level is widely accepted as it can be easily implemented and deployed. Transport- level NSI acquisition can provide more accurate end-to-end Li, et al. Expires January 13, 2012 [Page 5] Internet-Draft P2MP Streaming Media Delivery July 2011 information while brings less overhead to the network. And, sophisticated analysis is possible by using the network tomography techniques to infer the lower-layer network state. However, rapidly and accurately locating the problem to the particular network node/ link requires more network state information directly from the inside of the network. Some protocols in TCP/IP stack can implicitly gather the end-to-end network performance metrics only for support embedded control mechanism, such as TCP and RTP[RFC1889] [RFC3550]. Few of the protocols explicitly provide mechanisms, such as bandwidth and timestamp, for delivering the state information of network elements (such as routers, switches and links) to the application, which makes QoS assurance of the P2MP streaming media delivery difficult. (2) The difficulty of policy-based control Most of the P2MP streaming delivery systems employ pull-based service model based on IP multicast technology. In the model, the streaming data are transmitted along the delivery paths which are decided or calculated according to the distribution of users' requests. However, other service models, such as push-based and pull-and-push based, are also very useful in providing different featured services to the end-users. For example, the subscribed advertisements, video messages and news can be directly delivered to the specific end-users without explicit requests under push-based service model. The model improves initiative and flexibility of P2MP streaming media delivery service, and provides technical support for the implementation of value-added services. Pull-and-push based service model can be very helpful in reducing the delivery time derived from the dynamic changes of users' request. For example, in the of IPTV service the edge network, the channel zapping delay can be shortened, if the streaming data are pushed to some intermediate nodes before the users pull the content. The different service models, i.e., pull-based, push-based and pull- and-push based model, can provide different optimized characteristic to the P2MP delivery service of streaming media. And, it will be significant if different service models can be implemented as different policies for the P2MP streaming media delivery. However, the difficulty is that most of current delivery mechanisms, such as IP multicast, do not separate the policy from the mechanism. This lack of flexibility, for example, prevents ISP/SP that would ideally prefer to choose some service model, but not others, in transmitting media data. It is essential for a protocol/mechanism of P2MP streaming media delivery to provide simple, stable and common interface to enable policy-based control. In this case, a framework accommodating different service models and different delivery policy can be constructed. Li, et al. Expires January 13, 2012 [Page 6] Internet-Draft P2MP Streaming Media Delivery July 2011 4. Architecture Requirements 4.1. Scalability Scalability is one of the most critical issues in the deployment of P2MP streaming media delivery system. Many aspects of the system, such as routing protocols, including state information maintenance and address allocations, etc., should take the scalability into consideration [I-D.boudani-mpls-multicast-tree]. P2MP streaming media delivery suffers from the large number and stringent QoE requirement of end-users. Scalability can be evaluated not only in terms of the number of groups but also by the number of participants per group and by groups for which the set of participants changes often over time. A scalable P2MP streaming media delivery system should be simple to implement, robust, use minimal network overhead and consume minimal resources of routers/switches [Wong]. Usually, hierarchical architecture is a good design choice for tackling the scalability problem. 4.2. Incremental Deployment Incremental deployment is an important architectural attribution required by the P2MP streaming media delivery mechanisms. The cost of deployment, running, and maintaining can be largely reduced, if the efficient mechanism for P2MP streaming media delivery supports incremental deployment. That means, new schemes and solutions should not modify the original fundamental infrastructure, and the update or the substitution can proceed smoothly. New mechanisms/protocols are expected to coexist and integrate with existing protocols, such as IP multicast and RTP, while offering more flexible deployment options. 5. Why IETF Needs to Develop Solutions Instead of Relying on Existing Technologies? 5.1. IP Multicast IP multicast is the most effective technology to solve the bandwidth problem in streaming media transmission. It can reduce both network link cost and server bandwidth requirement for serving a large number of receivers simultaneously[Lao]. In IP multicast, the source sends only one copy of an addressed packet to a group of receivers to reduce the consumption of the network bandwidth. For P2MP distribution of data, Source Specific Multicast (SSM) [RFC4608] has been proposed to offer simplified unidirectional routing. When there is only one source of multimedia traffic, it is unnecessary to require the routing infrastructure to create either a full mesh of distribution trees or bidirectional connectivity among all group Li, et al. Expires January 13, 2012 [Page 7] Internet-Draft P2MP Streaming Media Delivery July 2011 members. Although the complete protocol architecture of IP multicast has already been constructed and standardized, it has not been widely deployed in the past years. One problem of IP multicast is the scalability. To support a large number of groups and users, routers in the network should keep all the states information of the active groups. The costs of maintaining the state information come in terms of memory at the routers, and processing of periodic control messages to maintain such state. The control message overhead and memory cost grow linearly with the number of multicast groups supported by the router. The second problem related the IP multicast technology is its lack of the supported features required of a robust commercial implementation[Diot] . The features include authentication and accounting, group management, security and network management, etc. 5.2. RTP/RTCP Extensions of IP Multicast Although SSM technology may simplify routing for P2MP streaming data delivery, unidirectional communication makes it impossible for the source and other members in the group to obtain feedback and control information[Chesterfield] . An extension of RTCP has been proposed to enable SSM that do not have many-to-many communication capability to receive RTP data streams and to continue to participate in the RTCP by using multicast in the source-to-receiver direction and unicast to send receiver's feedback to the source on the standard RTCP port[RFC5760] . RTP/RTCP's original target was multiparty multimedia conferencing in multicast networks. RTP is designed for data transmission and RTCP is for the distribution of feedback and control information. RTP/RTCP provides SSM the ability for supporting the monitoring and locating the fault in the network. By utilizing network tomography technology, RTCP can provide a wealth of data for QoE monitoring, network management and fault diagnosis purposes [ACBegen] [Begen] .On the Scalability of RTCP-Based Network Tomography for IPTV Services. However, these end-to-end network state information are often insufficient to accurately identify the particular fault router/switch or link. The collection, analysis and processing of the NSI required by network tomography technology make real-time fault location and fast failure recovery hard to be implemented. 5.3. Overlay(CDN P2P) Peer-to-peer (P2P) technology has been proposed for streaming media delivery aiming at the high cost of deployment and maintenance of the infrastructure-based approach [Kien]. P2P lets users end hosts forward video data to other users' end hosts in the downstream. The technology has the advantages of scalability and easy-to-development. It also can provide robust and resilient when the network failure occurs. However, P2P streams bring no profit to the ISPs and violate Li, et al. Expires January 13, 2012 [Page 8] Internet-Draft P2MP Streaming Media Delivery July 2011 the fairness principle for the business. ISP cannot benefit from offering service to the peers who wish to freely use network bandwidth resources. Moreover, the streaming media data delivery by P2P concerns the logic network rather than physical network states and topology. A packet may be sent on the same link more than once, which incurs inefficiency in utilizing the precious network resources. In CDN architecture, the content is first distributed to CDN servers which are pre-placed in many regions. CDN can provide reliable delivery and cost-effective scaling. It can also provide high security for the contents stored. However, CDN costs more and provides less scalability. The technology of hybrid CDN and P2P has been proposed for live streaming and VoD applications. The hybrid architecture is an effective way to reduce the cost of content distribution and guarantee the quality of transmission for P2MP streaming media service. However, hybrid CDN and P2P architecture requires dedicated dimensioning and design, as the different contribution policies, interrelated system parameters and their impacts on multiple performance metrics should be carefully determined for better performance. 6. Security Considerations This document has no additional requirement for security. 7. IANA Considerations This document has no additional requirement forIANA Considerations. 8. Acknowledgments We would like to thank Jigang Wu and Guozhi Song for their valuable suggestions. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Li, et al. Expires January 13, 2012 [Page 9] Internet-Draft P2MP Streaming Media Delivery July 2011 9.2. Informative References [ACBegen] Begen, A., Perkins, C., and J. Ott, "On the Use of RTP for Monitoring and Fault Isolation in IPTV". [Begen] Begen, A., Perkins, C., and J. Ott, "On the Scalability of RTCP-Based Network Tomography for IPTV Services", 3 2010. [Chesterfield] Chesterfield, J. and E. Schooler, "An Extensible RTCP Control Framework for Large Multimedia Distributions", In Proceedings of the 2nd IEEE International Symposium on Network Computing and Applications 2003, 3 2003. [Diot] Diot, C., Levine, B., and J. Lyles, "Deployment issues for the IP multicast service and architecture", IEEE Network 2000,14(1):78_8, 14(1):78_8 2000. [I-D.boudani-mpls-multicast-tree] Boudani, A., "An Effective Solution for Multicast Scalability:The MPLS Multicast Tree (MMT)", draft-boudani-mpls-multicast-tree-06 (work in progress), October 2004. [ITU-T] "Telephone Network and ISDN Quality of Service, Network Management and Traffic Engineering: Terms and Definitions Related to Quality of Service and Network Performance Including Dependability", ITU-T Recommendation E. 800, Aug 1994. [ITU-TP] "Appendix I to P.10/G.100: Definition of QoE", ITU-TP.10/ G. 100, Jan 2007. [Kien] Hua, K., Tantaoui, M., and W. Tavanapong, "Video delivery technologies for large-scale deployment of multimedia applications", 3 2004. [Lao] Lao, L., Cui, J., Gerla, M., and D. Maggiorim, "A Comparative Study of Multicast Protocols: Top, Bottom, or In the Middle?", In Proceedings of INFOCOM' 2006. [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Li, et al. Expires January 13, 2012 [Page 10] Internet-Draft P2MP Streaming Media Delivery July 2011 [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006. [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010. [Wong] Wong, T., Ed., "Multicast Forwarding and Application State Scalability in the Internet", phdthesis Wong:CSD-00-1114, December 2000, . Authors' Addresses Tao. Li NUDT 47 Yanwachi St Changsha, Hunan 410073 China Phone: +86-13487568531 Email: taoli.nudt@gmail.com Zhi Gang. Sun NUDT 47 Yanwachi St Changsha, Hunan 410073 China Phone: +86-13875903721 Email: sunzhigang@nudt.edu.cn Hui Wang NUDT 47 Yanwachi St Changsha, Hunan 410073 China Phone: +86-13467578342 Email: wanghuinudt@gmail.com Li, et al. Expires January 13, 2012 [Page 11] Internet-Draft P2MP Streaming Media Delivery July 2011 Chun Bo. Jia NUDT 47 Yanwachi St Changsha, Hunan 410073 China Phone: +86-13407318066 Email: jiachunbo1988@sina.com Li, et al. Expires January 13, 2012 [Page 12]