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 Video CDN Qlty#1 HTTP request (Qlty#1) Qlty#2 Qlty#3 Video segment (Qlty#1) Qlty#4 Cache 3

Downgraded Throughput § HTTP streaming is build upon TCP § Sawtooth pattern traffic § Short segment duration 8 HTTP Request Rate (Reqs/s) no-push 7 § live latency 6 § High network adaptability 5 § User abandonment behaviors lead to less waste of 4 network resources 3 2 § request explosion 1 0 0 1 2 3 4 5 6 7 8 Segment Duration (s) 4

Video Streaming enhanced by HTTP/2 2080 × 2080 - logo-kid.com Cable TV Users 1:0 “Goal” HTTP Streaming Users 5

K-Push Request Request Response Response Push HTTP 1.1 HTTP/2 Client Server Client Server Client Server … … … … … (a) No-Push (b) All-Push (c) K-Push 6

Demo Live Event Playback ~18.7 sec Regular Approach ~3.7 sec Our Approach 7

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 8 § One request for k+1 segments HTTP Request Rate (Reqs/s) no-push k-push (k=9) 7 6 5 § More practical than the pipeline solution 4 3 § Less requests are delivered via network and 2 are processed on servers 1 § The knowledge of future segment URLs are not required 0 0 1 2 3 4 5 6 7 8 Segment Duration (s) 8

Analyze K-Push Adaptive Push Evaluate 9

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 push cycle (k = 2) Lead segment data transmission playback buffer RTT 10

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

Experimental Results § Request overhead is caused by two dimensions § Request number § Round trip time 20ms 20ms 1000 1000 300ms 300ms 500ms 500ms Avg. Bit Rate (kbps) Avg. Bit Rate (kbps) 800 800 600 600 400 400 200 200 0 0 k=0 k=1 k=4 k=9 k=0 k=1 k=4 k=9 Segment duration of 1s Segment duration of 2s § Playback bandwidth is defined as the effective bandwidth to deliver video payload § Increasing k substantially improves the playback bandwidth 12

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

Adaptive Push

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 1 0.8 0.6 CDF 0.4 0.2 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 User watching portion 15

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

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

Evaluation

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

Playback Bandwidth § Progressive download the experimental video § Playback bandwidth is derived by dividing the overall downloaded segment size by the time consumed 800 20ms 20ms Playback Bandwidth (kbps) Playback Bandwidth (kbps) 1200 300ms 700 300ms 500ms 500ms 1000 600 Bandwidth Bandwidth 500 800 400 600 300 400 200 200 100 0 0 no-push 9-push a-push-agg a-push-mod a-push-con no-push 9-push a-push-agg a-push-mod a-push-con 560 kbps actual bandwidth 880 kbps actual bandwidth § Adaptive-push outperforms regular HTTP/1.1 streaming, approaching k-push 20

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 20ms-con 20ms-con 16 16 20ms-mod 20ms-mod 20ms-agg 20ms-agg 300ms-con 300ms-con 14 14 300ms-mod 300ms-mod 300ms-agg 300ms-agg 500ms-con 500ms-con Push Number k Push Number k 12 12 500ms-mod 500ms-mod 500ms-agg 500ms-agg 10 10 8 8 6 6 4 4 2 2 0 0 0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140 Video Progress (s) Video Progress (s) 560 kbps actual bandwidth 880 kbps actual bandwidth 21

Network Adaptability Results § 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

Over-pushed Simulation § Apple HLS trace collected at client side § Simulator implemented in perl from Vuclip § Requests are sent only if previous § 07/15/2015 ~ 08/31/2015 downloaded segments are watched § ~ 12 million video sessions § Requested bitrate is determined by the measured playback bandwidth of last push cycle 23

Over-pushed Content 1 1 0.8 0.8 0.6 0.6 CDF CDF 0.4 0.4 20ms-con 20ms-con 20ms-mod 20ms-mod 0.2 20ms-agg 0.2 20ms-agg 500ms-con 500ms-con 500ms-mod 500ms-mod 500ms-agg 500ms-agg no-push no-push k-push k-push 0 0 0 2 4 6 8 10 12 14 16 0 2 4 6 8 10 12 14 16 18 Over-pushed Video Length (s) Over-pushed Video Length (s) 880 kbps actual bandwidth 540 kbps actual bandwidth 24

1 2 3 Evaluated K-Push Adaptive Push Evaluated adaptive push diminishing returns, Dynamic Scaling of Good Trade off network adaptability, Number of Segments between K-push and and the over-push Pushed HTTP 1.1 problem Conclusion 25

Questions ?