Multi-Criteria Optimization of Content Delivery within the Future Media Internet

Multi-Criteria Optimization of Content Delivery for the
Future Media Internet
Ph.D Jury:
- Daniel NÉGRU (Academic Advisor)
- Baptiste DE MEERLER (Industrial Advisor)
- Hermann HELLWAGNER (Reviewer)
- François TAIANI (Reviewer)
- Jordi MONGAY BATTALA (Examiner)
- Laurent RÉVEILLÈRE (Examiner)
- Christian TIMMERER (Examiner)
- Yiping CHEN (Examiner)
Defended on : 21-11-2017
Joachim BRUNEAU-QUEYREIX

Ph.D Defence - 21/11/2017 Joachim Bruneau-Queyreix 2
Future Media Internet:
Context aware Content aware
• Network status
• Device capabilities
• Available resources
• Content consumption
• Live Content
• VoD Content
• User Generated Content
• Live Conferencing
• Interactive Content
Today’s Media Internet:
• More users every day
• Demand for better Quality of Experience (QoE) in
constant increase
• More devices and terminals
• Enormous demand for content consumption
 Network congestion
 Scalability issues
Introduction Background Challenges MS-Stream MATHIAS PMS
Conclusion &
Perspectives
0
15
30
45
60
75
90
105
120
2015 2016 2017 2018 2019 2020
Traffic(ExaBytes/month)
Video
File Sharing
Web, email
Network infrastructures cannot follow-up with the ever
increasing users’ demand
Consumer Internet traffic forecast (2015-2020) - Cisco VNI

End-Users
Conclusion &
Perspectives
Content Providers
Network Providers
Content Delivery
Technological Enablers
Over-the-Top (OTT) Content Delivery Value Chain

Content Delivery Networks Peer-to-peer
• High reliability
• High deployment and maintenance cost
• Self-scaling properties
• Lack of control, Unreliable
Ex: Akamai, Amazon CloudFront, CloudFlare Ex: Strem.io, PPLive
Conclusion &
Perspectives
Origin Server
OTT Media delivery solutions: CDN and P2P
Cache server
Cache server
Cache serverCache server
Cache server

Hybrid P2P/CDN infrastructure
Origin Server
Cache Server
Cache Server
Cache Server
Cache Server
Cache Server
Conclusion &
Perspectives
High reliability and reduced scalability costs
Ex: Xunlei Kankan [Zhang et al 2015]
Zhang, G., Liu, W., Hei, X. and Cheng, W., 2015. Unreeling Xunlei Kankan: understanding hybrid CDN-P2P video-on-demand streaming. IEEE Transactions on
Multi- media, 17(2):229–242.

2010: DASH
1993:
RTP, RTCP, RTSP
1990:
HTTP Download
HTTP Progressive Download
1996: RTMP
2006: HTTP adaptive bitrate
streaming by Move Networks
Several proprietary HTTP Adaptive
Streaming (HAS) solutions*TCP-based protocol *UDP-based protocol
Conclusion &
Perspectives
Video streaming techniques – A bit of history

Content Server
time
Bitrate(quality)
Bandwidth
time
time
DownloadedBitrate
• Avoids video freezing events
• Adapts content quality to network status
• Enables low deployment cost and smooth integration into existing infra (CDNs,
Clouds, etc.)
Conclusion &
Perspectives
DASH: DynamicAdaptive Streaming over HTTP

High reliability
Over-The-Top streaming
solutions (CDNs, Cloud)
Improved QoE
potential
HAS-based streaming
solutions
Ph.D Defence - 21/11/2017 8
Conclusion &
Perspectives
Joachim Bruneau-Queyreix

High reliability
Improved QoE
potential
HAS-based streaming
solutions
CDN and HAS
based streaming
Ph.D Defence - 21/11/2017 9
Conclusion &
Perspectives
[Adhikari et al, 2012]
Adhikari, V. K. et al., 2012. Unreeling netflix: Understanding and improving multi-CDN delivery. IEEE INFOCOM

High reliability
Reduced scalability
costs
P2P solutions
Improved QoE
potential
HAS-based streaming
solutions
CDN and HAS
based streaming
Ph.D Defence - 21/11/2017 10
Conclusion &
Perspectives

High reliability
Reduced scalability
costs
P2P solutions
Improved QoE
potential
HAS-based streaming
solutions
CDN and HAS
based streaming
Hybrid
P2P/CDN
solution
Ph.D Defence - 21/11/2017 11
Conclusion &
Perspectives
[Zhang et al, 2015]
Zhang, G., Liu, W., Hei, X. and Cheng, W., 2015. Unreeling Xunlei Kankan: understanding hybrid CDN-P2P video-on-demand streaming. IEEE Transactions on
Multi- media, 17(2):229–242.

High reliability
Reduced scalability
costs
P2P solutions
Improved QoE
potential
HAS-based streaming
solutions
CDN and HAS
based streaming
Adaptive P2P
streaming
solutions
Hybrid
P2P/CDN
solution
Ph.D Defence - 21/11/2017 12
Conclusion &
Perspectives
[Jurca et al, 2007]
[Merani et al, 2016]
- Merani, M. and Natali, L., 2016. Adaptive streaming in P2P live video systems: A distributed rate control approach. ACM Transactions on Multimedia Computing, Com-
munications, and Applications (TOMM), 12(3):46
- Jurca, D. and Frossard, P., 2007. Video Packet Selection and Scheduling for Multipath Streaming. IEEE Transactions on Multimedia, 9(3):629–641.

High reliability
Reduced scalability
costs
P2P solutions
Improved QoE
potential
HAS-based streaming
solutions
CDN and HAS
based streaming
Adaptive P2P
streaming
solutions
Hybrid
P2P/CDN
solution
MS-Stream
(+MATHIAS)
PMS
Ph.D Defence - 21/11/2017 13
Conclusion &
Perspectives
MS-Stream: Relying
on the utilization of
multiple servers
simultaneously
MATHIAS: Exploiting multiple
distributed resources for each client
PMS: More efficient
utilization of
resources

MS-Stream: Multiple-Source Streaming
over HTTP
A pragmatic evolving streaming solution targeting QoE increase by
relying on the simultaneous usage of multiple servers
Related publications: [IEEE ICC2016], [IEEE Multimedia2017], [IEEE CCNC2017]

Content Server
time
Bitrate(quality)
Bandwidth
time
time
Bitrate
Server overload ? Network path overload  User’s “rage”
You need more than one server!
Conclusion &
Perspectives
DASH: DynamicAdaptive Streaming over HTTP
• Avoids video freezing events
• Adapts content quality to network status
• Enables low deployment cost and smooth integration into existing infra (CDNs,
Clouds, etc.)

Content Delivery
(simultaneous use of multiple servers)
1200 Kbps
Up to a 2000kbps visual quality
Content Delivery
(One server to one client)
1200 Kbps
Up to a 1200kbps visual quality
Content Provider
Content Ingestion
Content Replication
CDN Provider
Resource environment
Control and Management Content Replication
Resource environment
Control and Management
Content Provider
Content Ingestion
Resource Provider
(Clouds, Set-Top-Boxes,
CDNs, ISPs)
The proposed multiple-source streaming over HTTP
approach
Conclusion &
Perspectives
Any content source participates to the streaming up to its upload capacity
Uni-source adaptive streaming solution Multi-source adaptive streaming solution

2 Mbps
Up to a 4 Mbps
quality
Sub-segment delivery3
2Sub-segment composition
4 Sub-segment aggregation + Display
5 Adaptation
Multiple-Source Streaming over HTTP (MS-Stream)
(i) The obtained visual quality increases as servers join the streaming session
(ii) If any server leaves the session, the video playback continuity is insured
Conclusion &
Perspectives

18
Multiple Description Coding
• Classic Encoding:
Ph.D Defence - 21/11/2017 Joachim Bruneau-Queyreix
MDC
Encoder
Output File 1 (i.e. Description #1 OR sub-segment #1)
Output File 2 (i.e. Description #2 OR sub-segment #2)
.YUV
Video
Encoder
Input Video File (90GB)
Output File (900MB,
degraded yet acceptable quality)
.YUV .h264
Encoding info (Bitrate, QP param, entropy coder)
• Multiple Description Encoding:
*M. Kazemi, S. Shirmohammadi, and K. H. Sadeghi, “A review of multiple description coding techniques for error-resilient video delivery,”
Multimedia Systems, vol. 20, no. 3, pp. 283–309, 2013.
Standard-compliant?
Low complexity?
Redundancy/Data overhead tunability?
High possible number of descriptions?
Conclusion &
Perspectives

19
Video coding
Ph.D Defence - 21/11/2017 Joachim Bruneau-Queyreix
I P ... I B B PP
Group Of
Pictures #1
GoPs #2
...P P
GOP
#1GOP
GOP
GOP
GOP
GoP
Video stream
One video segment
Time GOP
GOP
GOP
GoP
...
Conclusion &
Perspectives

• Pre-decoding sub-segment aggregation
Any
Standard
Decoder
Sub-Segment Aggregation
Reconstructed
video sequence
Output File
OUTPUT.YUV
s1
s3
s2
• Post-encoding sub-segment composition
The proposed Multiple Description Coding scheme
Sub-segment
composer at
MS-Stream
server
Content qualities available at
MS-Stream server
Time
Time
GOP
#1GOP
GOP
GOP
GOP
GoPs
GOP
#1GOP
GOP
GOP
GOP
GoPs...
Sub-segment 2
GOPGOP
GOP
GOP
GOP
GOPs
Sub-segment 3
GOP
#1GOP
GOP
GOP
GOP
GOPs
Sub-segment 1
GOP
GOP
GOP
GOP
GOP
GoPs
✔ Video codec standard compliant
✔ Low complexity
✔ Redundancy/Data overhead tunability
✔ High possible number of descriptions
High bitrate GoPsGoPs
Redundant
bitrate GoPs
GoPs
Conclusion &
Perspectives

DASH client/server architecture
b Kbps
HTTP
Server
DASH
Storage
HTTP Client
Standard Decoder
Adaptation
Engine
DASH Client
b Kbps
Segment request
DASH Server
Conclusion &
Perspectives

22Ph.D Defence - 21/11/2017 Joachim Bruneau-Queyreix
MS-Stream system
Conclusion &
Perspectives
MS-Stream Servers
HTTP Client
Sub-segment
aggregator
Standard Decoder
Adaptation
Engine
MS-Stream Client
a kbps
b kbps
c kbps
MS-Stream
HTTP API
DASH
Storage
Sub-segment
composer
MS-Stream
HTTP API
DASH
Storage
Sub-segment
composer
MS-Stream
HTTP API
DASH
Storage
Sub-
segment
composer

Evolution
• A multiple-source adaptive streaming solution over HTTP
• Potential to increase QoE for end-users
Complexity of available resources
• How much bandwidth consumption overhead (from redundant GoPs)?
• Optimal number of used servers?
• Adaptation to heterogeneous paths/servers’ capacities?
• Late sub-segment deliveries?
Content
Server
Content
Server
Content
Server
?
...
...
Conclusion &
Perspectives

MATHIAS: Multiple-source and Adaptive
sTreamIng AlgorithmS
A set of heuristics to tackle multiple-source adaptive streaming content
consumption
Related publications: [IEEE ICME2017], [IEEE CCNC2017-demo]

MATHIAS: a two-phase adaptation algorithm (client-side)
Merge and
display
Sub-segment scheduling &
Adaptation to path
heterogeneity
Prior-download adaptation decisions In-download adaptation
In-segment
download
adaptation
Server #1
Server #...
Server #M
(optional)
Inputs for next segment download:
buffer level, server throughput estimations
Overhead selection
+ Bitrate adaptation Selected content bitrate
Manifest
file
Objectives: • A target visual content quality at Y Mbps
• A maximum percentage of bandwidth consumption overhead Omax
Bandwidth bottleneck
estimation
+ Server adaptation
List of servers to be used
Throughput estimation
Conclusion &
Perspectives
Remaining issues:
1) How much bandwidth consumption overhead (from redundant GoPs)?
2) Optimal number of used servers?
3) Adaptation to heterogeneous paths/servers’ capacity?
4) Late requests?

Percentageof
Overhead(%)
Buffer Occupancy Level (sec)
ε σ
Omin
Omax
0
Objective: A maximum percentage of bandwidth consumption overhead Omax
Dynamically adjusting the
overhead for each segment
Buffer-based bandwidth overhead adaptation (1/4)
GOP
#1
GOP
GOP
GOP
GOP
GoPs
Null bitrate GoPsGoPsHigh bitrate GoPsGoPs Redundant and low bitrate GoPsGoPs
Sub-segment
composer at
MS-Stream
server
Content qualities
available at MS-
Stream server Time Example of possible sub-
segment including GoPs
with no payload
Conclusion &
Perspectives
A more flexible sub-segment composition Redundant
GoPs
necessary ?

Conclusion &
Perspectives
Objective: Target visual content quality at Y Mbps
Two steps:
1. Determining bandwidth bottleneck location (client-side, server-side)
2. Adjusting the number of considered servers
Adaptation of the number of used servers (2/4)
Additive-Increase
Multiplicative-
Decrease (AIMD)
server adaptation
Download two
video segments
Bandwidth
bottleneck location
estimation
Monitor impact of server adaptation on global
throughput and per-server throughput
Limited throughput?
Bottleneck at server-side  Increase number of servers
Bottleneck at client-side  Halve the number of servers

Adaptation to paths’ capacity heterogeneity (3/4)
Conclusion &
Perspectives
How many GoPs from each server ?  Use of the considered servers in proportion to
their observed throughput capacities
??
?

Feedback control loop for in-segment download adaptation (4/4)
Download next segment
Downloads
finished?
In-segment
download
adaptation?
Perform adaptation rules
SleepTrue
False
False
True
Conclusion &
Perspectives
Rules’ objectives: maintain the buffer occupancy level in its zone
- Terminate late requests and prevent video stalls
- Hand the estimated late requests over the best performing server
Percentageof
bandwidthoverhead Buffer Occupancy Level bufLeveln (sec)
ε σ
Omin
Omax
0
Late sub-segment
deliveries?

Evaluations

0
2
4
6
8
10
12
14
16
18
0 5 10 15 20 25 30 35 40 45 50 55
Mbps
Segment Index
aggregated thoughput
video bitrate
redundant data
0
2
4
6
8
10
12
14
16
18
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
Trhoughput(Mbps)
Segment Index
Server 7
Server 9
Server 8
Server 10
Server 6
Server 5
Server 3
Server 4
Server 2
Server 1
Server
bottleneck
Client
bottleneck
Unknown
bottleneck
Server
bottleneck
Throughput limitation at
server-side
Throughput
limitation at
client-side
Testbed:
• 10 servers
• 2.5 Mbps per server
• One client (implemented in
the dash.js player from
DASH-IF*)
• Controlled environment
*http://dashif.org
0
2
4
6
8
10
12
14
16
18
20
22
24
0
10
20
30
40
50
60
0 50 100 150 200 250 300
Percentageofoverhead
Bufferlevelinseconds
5me (sec)
Buffer level
ε
σ
overhead
rule (ii)
rule (iii)
rule (ii)
rule (i)
%

MS-Stream (+MATHIAS) QoE evaluation
• 10 available servers in labs/end-users’ homes in France, Poland, Greece, Romania
• 8 available qualities (1,2,3,4,5,6,7,8Mbps) • A target quality at 8 Mbps
• Redundant bitrate at 200kbps • Bandwidth overhead set to 10% maximum
• A 10-min video • 50 runs per experiment (100 hours of streaming)
Evaluated streaming
application
Global available
throughput
Number of clients Number of available
servers
Throughput per
server
DASH 20 Mbps 2 1 20 Mbps
MS-Stream (+MATHIAS) 20 Mbps 2 10 2 Mbps
Evaluated streaming
application
Mean
Bitrate
(Mbps)
Quality
changes
Video
freezing
events
Start-up
delay
(sec)
Bandwidth
overhead
Average used
servers
DASH 6.87 10.32 7.22 4.11 0% 1
MS-Stream (+MATHIAS) 7.78 4.69 0.29 1.56 6.43% 7.68
Conclusion &
Perspectives

PMS: Quality and scale adaptive hybrid
P2P/Multi-Server solution for live-
streaming
A pragmatic evolving streaming solution targeting QoE increase by
relying on the simultaneous usage of multiple servers
Related publications: [ICME/DASH-IF Grand-challenge2017], [ACM MM2017-demo], [ACM
TOMM(submitted)]

Content
servers
Data flow
Control flow
Management
Services
Up to a 4 Mbps
quality
2 Mbps
P2P overlays
#Qmax
#i
#1
Trackers
The proposed multi-overlay hybrid P2P/Multi-Server
(PMS) architecture
Each overlay #i is composed of peers
currently consuming and re-emitting the
quality #i only
Conclusion &
Perspectives
Trackers evaluate the “health” of the
system and of each overlay with several
global indicators
Peers report local system metrics
(throughput, received data, sent data)
to the trackers

Inputs for segment n=n+1
(buffer level, throughput estimation, etc...)
PMS quality
adaptation
PMS scale
adaptation
Sub-segment
scheduling
P2P in-
segment
adaptation
Peer #1
Peer #...
Peer #K
X% of data from servers
at selected bitrate bi
1-X% of data from peers
at bitrate bi
Tracker and P2P
communications
Merge
and
display
Sub-segment
scheduling
Overhead selection
Bottleneck estimation
+ Server Adaptation
In-segment
download
adaptation
Server
#1
Server
#...
Server
#M
(optional)List of servers to be used
Selected content bitrate
MATHIAS
Manifest File
Decision flow
Control flow
Content requests
Content delivery
Multi-ServerMulti-Peer
(optional)
Conclusion &
Perspectives
The proposed PMS consumption algorithm
Selected bitrate bi
In-download adaptationPrior-download adaptation decisions

PMS distributed quality adaptation
Conclusion &
Perspectives
Retrieve global
indicators
Compute local
indicators
Overlay
migration
decision
Overlay capacity
Quality delivery efficiency
Content
servers
Which
overlay?
P2P overlays
#Qmax
#i
#1
Trackers
?
?
?
Throughput from servers
Throughput from peers
Migration decision for next segment download in order
to preserve the good functioning of all overlays Next video bitrate

PMS distributed scale adaptation
Conclusion &
Perspectives
Probabilistic approach for GoPs delivery assignation to peers  lowering P2P communications for real-time constraint applications
Retrieve global
indicators
Adjusting
percentage of
GoPs
requested to
the servers
Global P2P efficiency
Compute local
indicators
Local P2P capacity
• X% of GoPs to be requested
from the servers
• 1-X% from the peers
Slowly moving towards an increase of the peers’
capacity utilization without ceding on the QoE gains
Content
servers
Servers? Peers ?
Both ?
P2P overlays
#Qmax
#i
#1
Trackers
How many
GoPs ?
How many
GoPs ?
Probability to assigned the delivery of GoPs c to peer k:

Evaluations

Evaluations
• 15 servers with 25 Mbps upload throughput capacity
• 2 applications (PMS and 1 re-implemented research
paper)
• 1, 2, 4, 6 Mbps content quality
• 300 peers (Paris, Roubaix, Versailles, Bordeaux)
• 150 peers for the first 15 minutes, 150 more peers at
the 16th minute
Conclusion &
Perspectives
Application Consumption and adaptation features
PMS-AQAS MS-Stream + MATHIAS + Adaptive-Quality +
Adaptive-Scale
P2P-DASH
[Merani et al,
2016]
The server is used at 4 times the rate of the
consumed video qualities for the entire
streaming system
Evaluated parameters
• Rebuffering events
• Quality changes
• Mean bitrate
• Percentage data coming from
the servers
Merani, M. and Natali, L., 2016. Adaptive streaming in P2P live video systems: A distributed rate control approach. ACM Transactions on Multimedia Computing, Com-
munications, and Applications (TOMM), 12(3):46

Results
Application Mean bitrate Rebuffering events (per
minute)
Quality
changes (per
minute)
% of data
from servers
% of data
from P2P
PMS-AQAS ~6Mbps <0.1 <0.3 ~45% ~55%
P2P-DASH 2.55 ~2.5 2.15 <1% >99%
Application Mean bitrate Rebuffering events (per
minute)
Quality
changes (per
minute)
% of data
from servers
% of data
from P2P
PMS-AQAS ~6Mbps <0.1 <0.3 ~24% ~76%
P2P-DASH 4.1 Mbps ~2.3 2.19 <1% >99%
Results before flash crowd (per-client results)
Results after flash crowd (per-client results)
Conclusion &
Perspectives

Conclusion and perspectives
Conclusion &
Perspectives
MS-Stream
MATHIAS
PMS
IoT streaming
Social Networks of Objects
Omnidirectional video streaming
Framework for
multiple-server
HAS
QoE and scalability
increase
QoE increase

Thank you for your attention!
Time for a Q&A session
Demo available at http://msstream.net

Multi-Criteria Optimization of Content Delivery within the Future Media Internet

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Multi-Criteria Optimization of Content Delivery within the Future Media Internet

Ähnlich wie Multi-Criteria Optimization of Content Delivery within the Future Media Internet (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Multi-Criteria Optimization of Content Delivery within the Future Media Internet