Video over ICNIRTF Interim Meeting

Boston, MA

Cedric Westphal

Draft focus

• Video composes most of the traffic in current network

• No signs for trend to abate: any new Internet architecture need to handle video

• Questions of the video draft:– Can current Internet mechanisms for video

distribution be adapted to an ICN?– Should new mechanisms be designed that are

native to ICN?

Draft-video

• 4th version of the draft: Berlin, London, Toronto, Honolulu

• After Toronto, official WG item• No seismic changes in last version, converging: same

contributors, roughly same length (32 pages to 35 pages, 10,704 words to 11,782)

• Updated to reflect discussion in IETF90• But new organization, new abstract, modified

ToC/organization, sharpened focus– Two new sections

ICN specific video mechanisms

• Open discussion in the RG• Start document– Input welcome!

• Today, some starting points:– Abstraction of ICN helpful for video distributions?– Specific CCN mechanisms?

ICN enables Store&Forward

• e2e rate adaptation achieves the minimum bandwidth

• ICN-specific/cache-aware mechanisms achieves wireless bandwidth capacity

server cache client

timeca

paci

tytime

capa

city

time

capa

city

e2e throughput

time

capa

city

ICN throughputFill cache

Draw from cache

Store&Forward

• Questions: how to adapt rate in this situation?• What is the proper rate adaptation

mechanism to avoid buffering events, rate variations while at the same time maximizing QoE for end user

• What are the mechanisms to insert cache awareness in the video stream?

QoE Maximizing Algorithm

• Estimate bandwidth on each link over the time window

• Compute rate selection which maximizes the QoE taking into account the bw constraints

• Output rate decision over time window

Results

Significant Improvement in QoE

• Questions: better trade-off to use cache space for this vs caching?

• How to estimate the bandwidth reliably?• How to scale it to large number of flow/rate

combinations?

Video Transport in ICN

• Video is a specific case of large file transfer• TCP e2e throughput governed by 1/RTT

• Store-and-Forward divides RTT when pipelining transmissions: replace

1/(RTTe+RTTc) with min(1/RTTe;1/RTTc)• But it decouples the rate adaptation which

works e2e as well!

Video Prefetching

• Video streaming exhibits strong daily patterns• Network prefetching allows to shift some of the video traffic load

to reduce peak bandwidth for network operators– 15-20% theoretical bandwidth saving with prefetching (assuming video length 60

minutes)– The marginal cost for the network operator to pre-fetch traffic is close to zero if

using empty capacity

• What rate selection mechanism to use?

Dash-Aware Video Stream Prefetching

• By utilizing the DASH manifest, the network computes available link resources and schedules the chunk dissemination to edge caches ahead of user requests

• Prerequisite– DASH segment URLs are used as data names– A controller is used to assign content to caches on

path and monitors network conditions• Prefetching tasks are assigned for a given period of time

(round)

Testbed Settings

Open vSwitch and VirtualBox Floodlight OpenFlow controllerVLC player with DASH plug-in

-Limited download buffer (20 seconds)

-Video quality adaptation by k-segment moving average

Three 200sec Videos from DASH data set-Video segment size: 2 seconds-Available video rates: 200Kbps, 250Kbps, 300Kbps, 400Kbps

Results: Quick Transition From Light To Heavy Network Load

Multi-source Video Streaming

• Multi-source rate adaptation mechanisms?• Network coding to sum the rates of multiple

client-cache paths?

Use of CCN semantics for Video Streaming

• Can the interest/data exchange be leveraged to enhance video stream?

• Can the network identify some interests as control packets (say, request for video manifest)?– Specific type of interest?– Can the manifest be used to populate FIBs?• Location of some copies of data objects

Examples/ideas for CCN

• Interest sets path for data– Back to the 90s!– Interest advertises the rate requested by the

client; router provisions resource a la RSVP?– Router “negotiate” rate on interest path• “Based on current congestion level, I can’t provide this

rate, but I can deliver that one”

Conclusions

• Abstractions of ICN well suited to enhance video distribution

• Transport needs to be rethought to take advantage of these abstractions

• QoS is dead, long live QoS• Contributions needed to ICN-specific video

document?– Especially standards related?