Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE

Slide 1

Slide 1 text

Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE JUNCHEN JIANG, VYAS SEKAR, HUI ZHANG PRESENTED BY TANGKAI

Slide 2

Slide 2 text

Table of Content  Introduction  BACKGROUND AND MOTIVATION  DESIGN  ANALYSIS OF FESTIVE  EVALUATION 2

Slide 3

Slide 3 text

Table of Content  Introduction  BACKGROUND AND MOTIVATION  DESIGN  ANALYSIS OF FESTIVE  EVALUATION 3

Slide 4

Slide 4 text

Introduction  Video traffic becomes the dominant share of Internet  Reason: is driven by technology trend  Customized connection-oriented video transport protocls(RTMP) ->  HTTP-based adaptive streaming protocols  Design of robust adaptive http streaming is not only important to video application but also for Internet  TCP congestion control -> to prevent “congestion collapse” 4

Slide 5

Slide 5 text

Introduction  Design of a robust adaptive video algorithm  Single -> multiple  Three (potentially conflicting) goals  Fairness  Efficiency  Stability 5

Slide 6

Slide 6 text

Introduction  State-of-art HTTP adaptive streaming protocols:  Smooth-Streaming [12], Netflix [8], Adobe OSMF [2], and Akamai HD [3]  Contribution  Chunk Scheduling  Bitrate Selection  Bandwidth Estimation 6

Slide 7

Slide 7 text

Introduction  DASH  Process  Pros:  HTTP  Web server/cache  Stateless  Parallel  Load balancing, tolerance 7

Slide 8

Slide 8 text

Table of Content  Introduction  BACKGROUND AND MOTIVATION  DESIGN  ANALYSIS OF FESTIVE  EVALUATION 8

Slide 9

Slide 9 text

Background & Motivation  Desired properties  The smaller the better  Inefficiency:  Unfairness:  Instability: 9

Slide 10

Slide 10 text

Background & Motivation  video adaptation vs. traditional TCP -> key difference  Protocol stack  Application layer within sandbox vs. trans layer  Driven  Receiver driven vs. sender driven  Granularity  Chunk level (~x00 KB) sec vs. Packet level (1536 bits ~1KB) ms  Rate Adaptation  Request lower bitrate vs. Delay transmission 10

Slide 11

Slide 11 text

Background & Motivation  Performance of today’s commercial players 11

Slide 12

Slide 12 text

Background & Motivation  Design Space  Protocol stack level  Trans layer; Joint Design  App-layer sandbox  Where in network  Server-side; in-network  Client-side  Coordinated vs. Decentralized?  Decentralized 12

Slide 13

Slide 13 text

Table of Content  Introduction  BACKGROUND AND MOTIVATION  DESIGN  ANALYSIS OF FESTIVE  OSMF-BASED IMPLEMENTATION  EVALUATION 13

Slide 14

Slide 14 text

Design  1. Schedule when the next chunk will be downloaded.  2. Select a suitable bitrate for the next chunk.  3. Estimate the network bandwidth. 14

Slide 15

Slide 15 text

Design  Chunk Scheduling  Immediate download:  Bandwidth-waste (user leave prematurely)  Preclude the option of switching up  N/A in live streaming  Suitable for initial ramp-up phase  Periodic download:  Keep a constant buffer 15

Slide 16

Slide 16 text

Design  Chunk Scheduling  Randomized scheduling  Randbuf uniformly at random from the range  Ensures that each player is not biased by its start time 16

Slide 17

Slide 17 text

Design  Bitrate Selection  Bias with stateless selection  stateless approaches as it only considers the estimated bandwidth without considering the current bitrate or whether it is ramping up or ramping down its bitrate.  Unfair <- dicrete bitrates 17

Slide 18

Slide 18 text

Design  Bitrate Selection  Proposed approach  compensate for the above bias so that the players can converge to a fair allocation irrespective of their current bitrates.  Our current design chooses option (2) and we simply keep the rate of decrease a constant function.  gradual switching strategy(qoe) 18

Slide 19

Slide 19 text

Design  Delayed Update two potentially conflicting goals: efficiency and fairness vs. stability  efficiency cost(lower the better) for  w is the estimated bandwidth and bref is the reference bitrate from the previous section. 19

Slide 20

Slide 20 text

Design  Delayed Update  stability cost  n denote the number of bitrate switches in the last k = 20 seconds.  using an exponential function of n is that score stability (b ref ) - score stability (b cur ) is monotonically increasing with n 20

Slide 21

Slide 21 text

Design  Bandwidth Estimation  smoothed value computed over the last several chunks rather than instantaneous throughput  harmonic mean rather than arithmetic mean  Robust to outlier 21

Slide 22

Slide 22 text

Design  The FESTIVE algorithm  Fair, Efficient, Stable, adaptive  harmonic bandwidth estimator  K = 20  stateful and delayed bitrate update  The randomized scheduler 22

Slide 23

Slide 23 text

Table of Content  Introduction  BACKGROUND AND MOTIVATION  DESIGN  ANALYSIS OF FESTIVE  EVALUATION 23

Slide 24

Slide 24 text

Analysis OF FESTIVE  Stateful bitrate selection 25 x y b b

Slide 25

Slide 25 text

Table of Content  Introduction  BACKGROUND AND MOTIVATION  DESIGN  ANALYSIS OF FESTIVE  EVALUATION 27

Slide 26

Slide 26 text

Evaluation  Compare performance of FESTIVE against (emulated) commercial players  Validate each component  Evaluate how critical each component is to the overall performance  Evaluate the robustness of FESTIVE as a function of bandwidth variability, number of players, and the set of available bitrates 28

Slide 27

Slide 27 text

Evaluation  Evaluation setup:  Difficult to run controlled experiments with real commercial player and to automating experiment  Trace-driven  A custom emulation framework to closely mimic each commercial player.  A conservative approximation: the lower bounds of unfairness, inefficiency and instability  employ a stateless bitrate selection algorithm  linear function of the throughput(previously) 29

Slide 28

Slide 28 text

Evaluation  Evaluation setup:  Flexible framework evaluate different algorithms for chunk scheduling, bitrate selection, and bandwidth estimation.  Java modules(~1000 lines)  Client – Bottleneck(dummynet) – server  Client decide bitrate when issue the request  Server generates a file on the fly when received request  350Kbps to 2750Kbps / 2 sec chunks 30

Slide 29

Slide 29 text

Comparison with Commercial Players 31  3 Player 3Mbps  Little worse than OSMF in efficiency  our FESTIVE parameters are customized for the chunk sizes and bitrate levels  Outperform the best SS  More player better

Slide 30

Slide 30 text

Component-wise Validation  Bandwidth estimator:  arithmetic mean, median, EWMA,9 and harmonic mean  observed throughput of the k = 20  the CDF of the prediction error 32

Slide 31

Slide 31 text

Component-wise Validation  Chunk scheduling:  stateless bitrate selection, instant update, harmonic bandwidth estimation  periodic chunk scheduling vs. randomized scheduling 33

Slide 32

Slide 32 text

Component-wise Validation  Chunk scheduling: 34

Slide 33

Slide 33 text

Component-wise Validation  Stateful bitrate selection:  fixed scheduler with stateless selection (baseline)  randomized scheduler with stateless selection  randomized scheduler with stateful selection 35

Slide 34

Slide 34 text

Component-wise Validation  Delayed Update:  Larger \alpha provides higher efficiency at the cost of stability  \alpha increases from 5 to 30 36

Slide 35

Slide 35 text

Component-wise Validation  Delayed Update: 37

Slide 36

Slide 36 text

Component-wise Validation  How critical is each component 38

Slide 37

Slide 37 text

Robustness  Number of concurrent players  2~30 player 10Mbps 39

Slide 38

Slide 38 text

Robustness  Bandwidth variability:  10 player, 10Mbps  Every 20 sec uniformly random 40

Slide 39

Slide 39 text

Robustness  Available bitrates:  We create a set of 10 available bitrate levels by  g controls the gap between the bitrates 41

Slide 40

Slide 40 text

Summary of main results  FESTIVE outperforms existing solutions in terms of fairness by 40%, stability by 50%, and efficiency by 10%.  Each component of FESTIVE works as predicted by our analysis and is necessary as they complement each other.  FESTIVE is robust against various number of players, bandwidth variability, and different available bitrate set. 42

Slide 41

Slide 41 text

Discussion  Heterogeneous algorithms:  2 player each for 8Mbps  More stable more efficient  TODO  Case  Friendliess 43

Slide 42

Slide 42 text

Discussion  Interaction with non-video traffic:  Wide-area effects:  More background traffic, less synchronization but many more players, multiple bottlenecks, interaction with router buffer sizing 44

Slide 43

Slide 43 text

Q&A Thank You 45