[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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, <http://www.eecs.berkeley.edu/Pubs/
              TechRpts/2000/6423.html>.


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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/