1 / 20

Adaptive Video Streaming over ICN

Adaptive Video Streaming over ICN. d raft-video-streaming-over-ICN-01.txt presented by Cedric Westphal. Author/ Email: Author's name/Author's email Version: V1.0(20YYMMDD). Video & ICN. Video streaming is an increasing share of Internet traffic

conlan
Download Presentation

Adaptive Video Streaming over ICN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Adaptive Video Streaming over ICN draft-video-streaming-over-ICN-01.txt presented by Cedric Westphal • Author/ Email: Author's name/Author's email • Version: V1.0(20YYMMDD)

  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?

  3. 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

  4. What’s new from -00 to -01?

  5. 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

  6. 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?

  7. 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 architectures Similar 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?

  8. Peer to Peer adaptive Video Streaming (P2PVS) over ICN Preliminary thoughts Slide credit: Andrea Detti

  9. 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

  10. PPSP plain architecture 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 Tracker messages Tracker protocol (PPSP-TP) TCP/UDP Peer Peer messages Peer protocol (PPSPP) TCP/UDP Slide credit: Andrea Detti

  11. Support PPSP messages exchange through ICN GETs, e.g. by uniquely naming each message Support PPSP unsolicited message sendings, e.g. by optimized polling of ICN GETs PPSP architecture on top of a ICN Tracker ICN GETs Tracker protocol (PPSP-TP) Peer Peer ICN GETs Peer protocol (PPSPP) ICN GETs Slide credit: Andrea Detti

  12. 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) Slide credit: Andrea Detti

  13. IPTV AytacAzgin, Huawei

  14. 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

  15. 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

  16. 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

  17. 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

  18. Future Research Challenges

  19. Future Research Challenges Currently 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.

  20. DASC & DRM

More Related