Adaptive Video Streaming over ICN

www.huawei.com

Security Level:

HUAWEI TECHNOLOGIES CO., LTD.

Adaptive Video Streaming over ICNdraft-video-streaming-over-ICN-01.txt

presented by Cedric Westphal

Author/ Email: Author's name/Author's emailVersion: V1.0(20YYMMDD)

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential 2

Video & ICN Video streaming is an increasing share of

Internet traffic 90% in 2017; Netflix consumes already over 1/3 of prime

time web traffic Information-Centric Networks: a new

architecture for content delivery Video IS content

Both adaptive video streaming and ICN attempt to solve the bandwidth scarcity, but in different ways:

Video streaming: By adapting demand to network conditions;

ICN: By making traffic demands local Are these compatible?


What’s new from -00 to -01?

Significant evolution Version 00 was to start defining the problem Generated interest from many people, discussed

in Berlin, now a group work item


What’s new from -00 to -01?


What’s new from -00 to -01? Expanded the document to other forms of video

streaming beyond DASH, incl layered coding. Considered P2P video streaming Considered IPTV requirements Expanded the DASH over CCN discussion to

include testbed and open source tools Added a section on research challenges, incl

wireless environments and DRM.

Right now, in a gathering phase, not in a filtering phase


From -00 to -01 to what? Purpose of document is to generate discussion Define the issues arising from running current

video streaming over ICN Have we identified the relevant challenges? Some of the sections start going into solutions

Maybe this can be put together into a different documents later on

Focus this document onto the video challenges as an informational RFC

Current focus has been to run existing video streaming services onto ICN -> should the goal be to design an ICN specific video streaming solution?


Layered Encoding More of a place holder at this time: should we consider

other streaming mechanisms beyond DASH? Advantage of layered approach: facilitate multicast,

which is native to ICN architecturesSimilar issues: what to cache (which layer? Where?)

Cache base layer first? Cache enhancement layers if room only? Cache enhancement layers of popular contents?

How to name? Naming syntax for each layer? How to update the MPD?

How to request content 1 interest = multiple layers? Does this violate some principles? Does

client decide which layers to request? Synchronization issues?

Get all layers within the same time frame?


Peer to Peer adaptive Video Streaming (P2PVS) over ICN

Preliminary thoughts

Slide credit: Andrea Detti


Towards Pull/Mesh model

P2PVS solutions can be roughly classified in two classes: Push/Tree based

One overlay multicast three per quality layer Pull/Mesh based

BitTorrent like Pull/Mesh solutions seems the more promising candidate

for the ICN deployment, since most of ICN approach provides a pull-based API

Peer to Peer Streaming Protocol (PPSP) working group is also proposing a Pull/Mesh based architecture

PPSP over ICN Slide credit: Andrea Detti


PPSP plain architecture

Tracker

Peer Peer

Tracker protocol(PPSP-TP)

Peer protocol(PPSPP)

TCP/UDP

TCP/UDP

messages

messages

Peers exchange messages with tracker (e.g. to obtain peer lists) by using the Tracker protocol Peers exchange messages each other to request and upload video chunk, or to advertize available chunks by using the Peer protocol



PPSP architecture on top of a ICN

Tracker

Peer Peer

Tracker protocol(PPSP-TP)

Peer protocol(PPSPP)

ICN GETs

ICN GETs

ICN GETs

Support PPSP messages exchange through ICN GETs, e.g. by uniquely naming each messageSupport PPSP unsolicited message sendings, e.g. by optimized polling of ICN GETs



Possible Pro and Cons Pro:

In network caching may boost performance/quality by reducing the load on the low uplink bandwidth of peer (e.g. due to ADSL)

…. Cons:

to fetch a content X from a peer P the routing plane should knows that content X is available on peer P. Availability of contents on peers has an impact on global ICN routing plane. Scalability? Security?

The availability of different quality layers may reduce cache hit probability “if” these layers are independent, like in H264 AVC

Scalable Video Coding (H264 SVC) may be better since quality layers are not independent. Video chunks fetched by a low rate user are also useful for an high rate user. (Not true in case of H264 AVC)



IPTV

Aytac Azgin, Huawei


Service Quality Assurance for IPTV

IPTV refers to “delivery of broadcast quality content over Internet”, and is associated with strict service quality requirements, such as, (channel change) latency and error recovery

Perceived latency during channel change needs to be small, preferably less than 500ms

Current solutions include, utilizing dedicated servers to deliver unicast catch-up streams, connecting to other peers that subscribe to the same session, simultaneously connecting to multiple session streams

Mean time between artifacts needs to be large enough to envelop the whole session, e.g., 2-4hours

Current solutions include, proactive FEC based recovery techniques (through joining additional FEC streams), or reactive ARQ based recovery techniques (through requests made towards dedicated servers, or other peers)

Delivery of IPTV service over IP has been studied extensively, with many practical implementations to date


Supporting IPTV Service Delivery in Information Centric Networks

Emerging technologies combined with shifting consumer interests towards higher quality content, such as Full-HD or Ultra-HD, with capable mobile devices, will significantly increase the burden on service providers

Information Centric Networking can effectively address these emerging problems through its host-centric approach and many of its features, such as in-network caching or session-less multicast

Multicast sessions are established inherently, on-the-fly, with aggregated requests

ICN allows for quick recovery from packet losses with the help of in-network caching

Peer cooperation is enabled by-default Challenges still exist to support the service quality

requirements for IPTV using ICN such as messaging overhead, cache control, and accurate access to content


Challenges to Deliver IPTV over ICN (1) How do we handle the increase in messaging overhead?

With ICN we have a pull-based architecture that support flow-balance using request-response match

Increasing video quality requirements leads to an increase in the number of requests, and session diversity limits the level of request aggregation

What is the optimal request size to support flow balance while being responsive enough to changes in network state?

How do we set and control the caching requirements? IPTV content expires at a rapid rate and content needs to be flushed out

from the in-network caches frequently, and caching policies need to be intelligent enough to determine what/when to remove quickly


Challenges to Deliver IPTV over ICN (2)

How do we set and control the caching requirements? We need a common naming convention to help the content routers make

consistent decisions Content expiry decisions need to take into account system state, hence,

be adaptive to network load and user demands How can we support client-side features such as rewind (that allows

access to earlier content) with minimal delay without having access to content locally?

How do we ensure the accuracy of the received content? Quick access to valid session information is required to acquire up-to-date

session content How can we achieve this if content routers do not cooperate? Stale data and short-term caches introduce additional delay and may

trigger frequent pause events


Future Research Challenges


Future Research ChallengesCurrently listed: Development of a generic video services (and obviously

content) interface allowing the definition and mapping of their requirements (and characteristics) into the current capabilities of the network;

How to define a scalable mechanism allowing either the video application at the terminal, or some kind of network management entity, to adapt the video content in a dynamic way;

How to develop the previous research items using intrinsic ICN mechanisms (i.e., naming and strategy layers);

Leverage intelligent pre-caching of content to prevent stalls and poor quality phases, which lead to bad Quality of Experience of the user.


DASC & DRM

Documents

Adaptive Video Streaming over ICN