SLIDE 1
Evaluating and Improving Push based Video Streaming with HTTP/2
Mengbai Xiao1, Vishy Swaminathan2, Sheng Wei2,3, Songqing Chen1
1George Mason Universty, 2Adobe Systems, 3University of Nebraska-Lincoln
HTTP Streaming
2
Evaluating and Improving Push based Video Streaming with HTTP/2 - - PowerPoint PPT Presentation
Evaluating and Improving Push based Video Streaming with HTTP/2 - - PowerPoint PPT Presentation
Evaluating and Improving Push based Video Streaming with HTTP/2 Mengbai Xiao 1 , Vishy Swaminathan 2 , Sheng Wei 2,3 , Songqing Chen 1 1 George Mason Universty, 2 Adobe Systems, 3 University of Nebraska-Lincoln HTTP Streaming 2 HTTP Streaming
SLIDE 2
SLIDE 3
HTTP Streaming
3
HTTP request (Qlty#1) Video segment (Qlty#1) Qlty#1 Qlty#2 Qlty#3 Qlty#4 Video CDN Cache
SLIDE 4
Downgraded Throughput
§ HTTP streaming is build upon TCP
§ Sawtooth pattern traffic
§ Short segment duration
§ live latency § High network adaptability § User abandonment behaviors lead to less waste of
network resources
§ request explosion
4
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
HTTP Request Rate (Reqs/s) Segment Duration (s)
no-push
SLIDE 5
Video Streaming enhanced by HTTP/2
5
Cable TV Users HTTP Streaming Users 1:0 “Goal”
2080 × 2080 - logo-kid.com
SLIDE 6
K-Push
6
Request Response Push Request Response
HTTP 1.1 HTTP/2
…
Client Server (b) All-Push
…
Client Server (a) No-Push Client Server …
…
…
(c) K-Push
SLIDE 7
Demo
7
Live Event
~18.7 sec
Playback
Regular Approach Our Approach
~3.7 sec
SLIDE 8
Server Push Mechanism and k-push
§ The server push mechanism is proposed in HTTP/2
§ HTTP servers speculativelypush back HTTP responses that the client does not request yet
§ K-push is a solution to relieve the request explosion problem
§ One request for k+1 segments
§ More practical than the pipeline solution
§ Less requests are delivered via network and
are processed on servers
§ The knowledge of future segment URLs are not required
8
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
HTTP Request Rate (Reqs/s) Segment Duration (s)
no-push k-push (k=9)
SLIDE 9
9
Adaptive Push Evaluate Analyze K-Push
SLIDE 10
K-push Model
§ K-push description
§ A push cycle consists of a HTTP request and k+1 HTTP responses § The lead segment of a push cycle is the first segment transmitted
§ Lead segment implies the bit rate level selected for the push cycle
10
playback buffer push cycle (k = 2) RTT data transmission Lead segment
SLIDE 11
Verification
§ Experimental parameters
§ Video length: 120s § Video qualities: 49 kbps, 217 kbps, 504 kbps,752 kbps § Number of segments pushed: 0, 1, 4, 9 § Bandwidth: 200 kbps, 560 kbps, 880 kbps § Round trip time: 20 milliseconds, 300 milliseconds, 500 milliseconds
§ The bandwidth is carefully capped to make quality switch reflect the streaming throughput
11
SLIDE 12
Experimental Results
§ Request overhead is caused by two dimensions
§ Request number § Round trip time
§ Playback bandwidth is defined as the effective bandwidth to deliver video payload
§ Increasing k substantially improves the playback bandwidth
12
200 400 600 800 1000 k=0 k=1 k=4 k=9
- Avg. Bit Rate (kbps)
20ms 300ms 500ms
Segment duration of 2s
200 400 600 800 1000 k=0 k=1 k=4 k=9
- Avg. Bit Rate (kbps)
20ms 300ms 500ms
Segment duration of 1s
SLIDE 13
Beyond Playback Bandwidth
§ Diminishing marginal returns with the increasing number of segments pushed § Network adaptability is not improved with reduced segment duration § Over-push problem
§ User may decide not to continue watching a video after checking the first few seconds
13
SLIDE 14
Adaptive Push
SLIDE 15
Adaptive-push Design
§ Adaptive-push features dynamically scaling the number of segments pushed in a video
session
§ A small k is selected for the first push cycle to alleviate over-push problem
§ A number of users stop watching the videos after checking the first few seconds
15
0.2 0.4 0.6 0.8 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
CDF User watching portion
SLIDE 16
Adaptive-push Design (Cont.)
§ The number of segments pushed is increased in various rates
§ When k is small, a high increment rate is preferred to improve the playback bandwidth § When k is large, a low increment rate or non-increment is more appropriate due to the diminishing
playback bandwidth improvement
§ The number of segments pushed is constraint by current buffer status
§ Long buffer length more efficiently absorbs network fluctuations
16
SLIDE 17
Implementation
§ The push directive is carried in the HTTP request header § PushDirective: k § Jetty HTTP/2 server § Jetty project § Video player: dash.js § Dynamically determined k § tc is used to manipulate bandwidth and RTT
17
SLIDE 18
Evaluation
SLIDE 19
Evaluation
§ Same experimental parameters as those in k-push analysis § Additional adaptive-push schemes
§ Aggressive/moderate/conservative bandwidth prediction (880/415/49 kbps) § Two increment rates: 2k, k+1
§ Increment rate is decreased if the playback bandwidth improvement is detected less than 10% § Increment of k is stopped if the playback bandwidth improvement is detected less than 2%
§ Evaluate playback bandwidth, network adaptability, and over-pushed content
19
SLIDE 20
Playback Bandwidth
§ Progressive download the experimental video
§ Playback bandwidth is derived by dividing the overall downloaded segment size by the time consumed
§ Adaptive-push outperforms regular HTTP/1.1 streaming, approaching k-push
20
100 200 300 400 500 600 700 800
no-push 9-push a-push-agg a-push-mod a-push-con
Playback Bandwidth (kbps)
20ms 300ms 500ms Bandwidth
560 kbps actual bandwidth
200 400 600 800 1000 1200
no-push 9-push a-push-agg a-push-mod a-push-con
Playback Bandwidth (kbps)
20ms 300ms 500ms Bandwidth
880 kbps actual bandwidth
SLIDE 21
K Variation
§ Two increment rates are observed in the figures § K is always low if small RTT is observed, which means little playback bandwidth
improvement when increasing k
§ Fluctuations occur when a large k is desired but the buffer length is low
21
2 4 6 8 10 12 14 16 20 40 60 80 100 120 140
Push Number k Video Progress (s)
20ms-con 20ms-mod 20ms-agg 300ms-con 300ms-mod 300ms-agg 500ms-con 500ms-mod 500ms-agg
560 kbps actual bandwidth 880 kbps actual bandwidth
2 4 6 8 10 12 14 16 20 40 60 80 100 120 140
Push Number k Video Progress (s)
20ms-con 20ms-mod 20ms-agg 300ms-con 300ms-mod 300ms-agg 500ms-con 500ms-mod 500ms-agg
SLIDE 22
Network Adaptability
§ Experimental parameters § Length: 5 minutes § buffer length: 30 seconds § Network condition varies every 30 seconds § Bandwidth: 480 kbps, 640 kbps, 800 kbps § RTT: 20 ms, 300 ms, 500 ms
22
Results
SLIDE 23
Over-pushed Simulation
§ Apple HLS trace collected at client side
from Vuclip
§ 07/15/2015 ~ 08/31/2015 § ~ 12 million video sessions
23
§ Simulator implemented in perl § Requests are sent only if previous
downloaded segments are watched
§ Requested bitrate is determined by the
measured playback bandwidth of last push cycle
SLIDE 24
Over-pushed Content
24
0.2 0.4 0.6 0.8 1 2 4 6 8 10 12 14 16 18
CDF Over-pushed Video Length (s)
20ms-con 20ms-mod 20ms-agg 500ms-con 500ms-mod 500ms-agg no-push k-push
540 kbps actual bandwidth
0.2 0.4 0.6 0.8 1 2 4 6 8 10 12 14 16
CDF Over-pushed Video Length (s)
20ms-con 20ms-mod 20ms-agg 500ms-con 500ms-mod 500ms-agg no-push k-push
880 kbps actual bandwidth
SLIDE 25
25
Dynamic Scaling of Number of Segments Pushed Good Trade off between K-push and HTTP 1.1
Evaluated adaptive push Adaptive Push Evaluated K-Push
diminishing returns, network adaptability, and the over-push problem
1 2 3
Conclusion
SLIDE 26