Internet DRAFT - draft-huang-dispatch-hybrid-video-delivery
draft-huang-dispatch-hybrid-video-delivery
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,
<http://www.rfc-editor.org/info/rfc2119>.
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]
