The Dispatch Working Group R. Huang Internet-Draft H. Zheng Intended status: Informational R. Even Expires: January 4, 2018 Huawei July 03, 2017 Video Delivery in Hybrid Network draft-huang-dispatch-hybrid-video-delivery-00 Abstract The industry trend of delivering video service is moving towards all IP solutions. However, there exit multiple incompatible platforms for video distribution. This document explores the existing video delivery technologies and analyses the challenges of unifying those technologies. 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 material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2018. Copyright Notice Copyright (c) 2017 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 Huang, et al. Expires January 4, 2018 [Page 1] Internet-Draft Hybrid Video Delivery July 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Multi-platform for Video distribution . . . . . . . . . . . . 2 4. Looking into the Protocols . . . . . . . . . . . . . . . . . 3 5. Impact of Diversity on IP distribution . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Video content delivery is now the major bandwidth usage over the Internet. Globally, IP video traffic will be 82 percent of all IP traffic (both business and consumer) by 2020, up from 70 percent in 2015. 4K Ultra HD technology is by itself a very new trend in the overall electronics landscape, and the impact of it is growing month by month. More content is accessible, in more formats, on more devices, for more people than ever before. Content providers and broadcasters are embracing multi-platform to attract more audiences. For example, IPTV providers not just provide video services on fix network but also consider to start the services for mobile accessed users; Traditional broadcasters not just provide services over cable or satellite, but also consider to start the services over IP network. How to transmit video traffic efficiently over these mutli- platforms poses challenges to these service providers. This document explores the existing video delivery technologies and analyses these challenges. 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 RFC 2119 [RFC2119]. 3. Multi-platform for Video distribution The same content could be delivered in different networks including broadband, mobile, satellite, cable and terrestrial. And the receiving devices can be all kinds of STBs, mobile phones, tablets and PCs. This is shown in Figure 1. Huang, et al. Expires January 4, 2018 [Page 2] Internet-Draft Hybrid Video Delivery July 2017 Distributions other than IP: +---> Satellite/Terrestrial/Cable | | +---------+ | +---------+ +-----------+ | Video | ----+ | IP | ----------> | IP Mobile | ---+ | Sources | --------> | Headend | -----+ | Network | | +---------+ +---------+ | +-----------+ | | | | +-----------+ | To a proliferation +----> | IP Fixed | ---+ of user devices: | Network | | TV/STBs +-----------+ | Phones | Tablets <---------------------------+ Desktops Figure 1: Multi-platform Distribution for Video 4. Looking into the Protocols | File Mode | | Packet | | | | Mode | v v | | | | +--------------------------+ | | | Codecs | v v +--------------------------+ +--------------------------+ +---------------+ | ISOBMFF/MPEG-2 TS(M2TS) | | Codecs/M2TS | +--------------------------+ +---------------+ +-----------+ +------------+ +---------------+ | HTTP | | NORM/FLUTE | | RTP | +-----------+ +------------+ +---------------+ ^ ^ ^ ^ | | | | | Pull Mode | | Push Mode | Figure 2: Video Delivery Protocol Stacks Today, there exist many diverged video delivery protocol stacks, as listed in Figure 2. Looking bottom-up, from the angle of transmission methods, the protocol stacks can be categorized into two modes: "Pull Mode" and "Push Mode". In "Pull Mode", client takes the initiative and pulls content from server proactively. Typical "Pull Mode" methods include HTTP progressive download and HTTP Adaptive Huang, et al. Expires January 4, 2018 [Page 3] Internet-Draft Hybrid Video Delivery July 2017 Stream (e.g. HLS and DASH). On the other hand, "Push Mode" operations are more server oriented. After session has been established, server controls the delivery by intentionally pushing content to client. Typical "Pull Mode" transmissions include IPTV and other multicast based methods. Another way to look at the protocol stacks is from the top-down angle, regarding how media are prepared before transmission. Traditional media delivery utilizes "Packet Mode", in which media is packetized with regard to their internal structure, so the resulting packets are optimized for transport and more loss tolerant. An example is transporting H.264 encoded video directly over RTP. Unlike "Packet Mode", segmented media grows more popular as they are adopted by HTTP Adaptive Streaming. Segmented media are referred to as "File Mode" in Figure 2, for the fact that media segments are seen as plain files, and described by additional manifests. The divergence in the protocol stacks has brought several issues, as the bottom-up angle and the top-down angel do not align with each other ("File Mode" and "Push Mode" are overlapping): o "File Mode" is not quite suitable to be used in "Push Mode", as the transports lack timing information. o "File Mode" is very difficult to be converted into "Packet Mode", and thus cannot be transported using unreliable protocols such as RTP. The divergence increases the overall complexity of video delivery. The next section analyzes the impact introduced by the complexity. 5. Impact of Diversity on IP distribution Currently the IP Headend (as in Figure 1) is unduly complicated by the diversity on IP distribution, as illustrated below: Huang, et al. Expires January 4, 2018 [Page 4] Internet-Draft Hybrid Video Delivery July 2017 Video unicast Sources +---------+ (Pull Mode & Push Mode) -----------> | IP | -------------------------> | Headend | multicast (Push Mode) +----+----+ =========================> | +------------+-------------+ | | | Encoding Packaging Protection o MPEG-2 o M2TS o Access Control o H.264 o DASH o Digital Right Management o H.265 o HLS o Encryption Figure 3: Complicated IP Headend It is a tedious job for the IP Headend to encode the same content into different variants using different media profiles, prepare them in several types of packaging, and apply different protection mechanisms before the variants are served. The consequence is increased cost in design, deployment, test and operation. The situation is further complicated by the diversity of network delivery mechanisms and content forms. Unicast delivery supports "Pull Mode" and "Push Mode", whereas multicast delivery only supports "Push Mode". Each delivery mechanism uses different transport protocols and support different content forms. "Pull Mode" supports "File Mode" content, and "Push Mode" supports content in both "File Mode" and "Push Mode". "File Mode" content is usually served in "Pull mode". However, it can also be served in "Push Mode" by using reliable multicast technologies (e.g. FLUTE, NORM). Serving "File Mode" content with "Push Mode" delivery would increase delay, as the reliability mechanisms imply using retransmission to recover lost data. It has impact on applications that require low-delay transport, for example, live video or virtual reality. If an application can tolerate a level of packet loss, then it is possible for the application to transform content from "File Mode" into "Packet mode", and transfer more efficiently in "Push Mode". An example would be to transform HLS media segments of MPEG-2 TS format into RTP packets, and multicast those RTP packets carrying MPEG-2 TS content to endpoints. However, this is only possible if the application is authorized to access the content and do the transformation. It is usually not the case in real-life scenarios. In order to protect contents, such transformation is not allowed in delivery by content providers. Huang, et al. Expires January 4, 2018 [Page 5] Internet-Draft Hybrid Video Delivery July 2017 There have been efforts to provide convergence for this diversified situation. New media packaging formats such as MMT, CMAF are proposed by MPEG that can packetize the media in application layer. So the same packaged media content can support both "File Mode" and "Packet Mode". To support the new packaging formats, maybe a content agnostic transport protocol should be developed here in IETF. 6. Security Considerations TBD. 7. IANA Considerations None. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Rachel Huang Huawei Email: rachel.huang@huawei.com Hui Zheng Huawei Email: marvin.zhenghui@huawei.com Roni Even Huawei Email: roni.even@huawei.com Huang, et al. Expires January 4, 2018 [Page 6]