Internet Streaming Media Delivery: Delving into Internet Streaming Media Delivery: A Quality and Resource Utilization Perspective Lei Guo1, Enhua Tan1, Songqing Chen2, Zhen Xiao3, Oliver Spatchcheck4, and Xiaodong Zhang1

Multimedia on the Internet Internet video traffic is doubling every 3 to 4 months (IBLNEWS, comScore) Youtube nearly doubled its traffic in May 100 million video streams were served per day in July, 2006 by Alexa Internet X 400% from May to Oct

Pseudo Streaming HTTP Flash based Short video: 3min Web server Flash based Short video: 3min High cost: 1-1.5 million$ a month RTMP: streaming flash video HTTP X 1 hours

Streaming Media CDN Streaming server Akamai, LimeLight Networks

Streaming Media Merits Challenges Research and techniques Thousands of concurrent streams Flexible response to network congestion Efficient bandwidth utilization High quality to end users Challenges Lack of QoS on the Internet Diverse network connection of users Research and techniques Effective utilization of server and Internet resources Protocol rollover, Fast Streaming, MBR and rate adaptation In 2000, 9,000 narrowband and 2,400 broadband video streams on a single physical server

Limits of Existing Measurements Few studies on the quality and mechanism of streaming media delivery Coarse granularity studies on access pattern and user behaviors Small scaled experiments in lab environment Unknown on the state of the art of Internet streaming delivery Unknown on the resource utilization of modern streaming services Challenge of streaming quality studies Server logs are not enough Packet level analysis is difficult: reconstruct TCP flow to get streaming protocol header

Our Objective and Methodology Understand modern streaming techniques The delivery quality and resource utilization Collect a large streaming media workload From thousands of home users and business users Hosted by a large ISP (Gigascope) RTSP, RTP/RTCP, MMS, RDT packet headers instead of server logs Analyze commonly used streaming techniques Protocol rollover Fast Streaming MBR encoding and rate adaptation

Outline Traffic overview Protocol rollover Fast Streaming Rate adaptation Conclusion

Traffic Overview User communities Media hosting services Home users in a cable network Business users hosted by a big ISP Have different access patterns Media hosting services Self-hosting Third-party hosting

Which is more popular: audio or video? Business users access more audio than home users

On-demand media: File length Audio Video pop songs (3-5 min) music Previews (30 sec) Business users tend to access longer audio/video files

On-demand media: Playback duration Audio Video pop songs music previews Business users tend to play audio/video longer

Live media: Playback duration Audio Video Business users tend to access live audio/video longer

Media hosting services Self-hosting: yahoo.com, aol.com, wbr.com Third-party hosting: akamai.com. LimeLight Networks, fplive.net CDN/MDN are widely used

Outline Traffic overview Protocol rollover Fast Streaming Rate adaptation Conclusion

Protocol Rollover X X Streaming server Media player RTSP/UDP RTSP/TCP Embed RTSP commands in HTTP packets HTTP/TCP Traffic volume: UDP: 23% TCP: 77% HTTP: rare

Protocol rollover time Startup latency = protocol rollover time + transport setup time + startup buffering time Windows media service RealNetworks media service TCP will be used even UDP is supported Protocol rollover increases user startup time significantly Content provider: use URL modifier to specify protocol in the meta file rtspt://xxx.xxx.com:/xxx.wmv (TCP) >70% rtspu://xxx.xxx.com:/xxx.wmv (UDP) rarely

Outline Traffic overview Protocol rollover Fast Streaming Rate adaptation Conclusion

Fast Streaming Fast Streaming: deliver media data “faster” than its encoding rate Fast start: fill the initial buffer Fast cache: optional Fast recovery Fast reconnect Always TCP-based 60% 40% Back

Media objects delivered with Fast Cache File length Encoding rate Fast Cache is more widely used for media files with longer length and higher encoding rate

Bandwidth Utilization PLAY RTSP/1.0 Bandwidth: 1.12 Mbps Speed: 20.5 RTSP /1.0 200 OK Speed: 5 Fast Cache Normal TCP streaming

Fast Cache smooth bandwidth fluctuation Rebuffer ratio = rebuffer time / play time Fast Cache Normal TCP

Fast Cache produces extra traffic Early termination: most streaming sessions only request the initial part of a media object Normal TCP: < 5% oversupplied Fast Cache: > 55% oversupplied

Server response time DESCRIBE foo.wmv RTSP/1.0 SRT handshake RTT sniffer RTSP /1.0 200 OK SDP Third party media service Self-hosting media service > 40% 20 ms

Some CDNs/MDNs do not support Fast Cache at all Server Load Windows Server 2003 Win XP Windows media load simulator Ethernet … Server log 1 X 4 X 1 X 4 X Some CDNs/MDNs do not support Fast Cache at all Link Bandwidth CPU

Effectiveness of resource over-utilization Fast Cache is TCP-based Only feasible when bandwidth is large enough Less possibility of congestion in this case Encoding rate: 200 – 320 K bps Bandwidth: > 500 Kbps Fast Cache: not resource-efficient

Outline Traffic overview Protocol rollover Fast Streaming Rate adaptation Conclusion

Rate Adaptation Windows: Intelligent streaming Multiple-bit-rate encoding 96Kbps 128Kbps 320Kbps … 1.128Mbps Stream switch Windows: Intelligent streaming RealNetworks: SureStream Stream thinning: deliver key frame only Video cancellation: play audio only

42% on-demand video are MBR encoded Maximum streams in a video: 20 MBR encoding on-demand audio audio stream in video objects live audio video stream in video objects 42% on-demand video are MBR encoded Maximum streams in a video: 20

Stream switch is often not smooth Play-out buffer Streaming switch latency Low quality duration 40% 30 sec 60% 3 sec Stream switch is often not smooth

Fast Cache and stream switch Do not work with each other: stream switch is disabled in Fast Cache When network congestion occurs … fill play-out buffer playing buffering playing buffering playing buffering time 5 sec Like pseudo streaming When rebuffer occurs

Streaming quality and playback duration Home user business user >100 sec 88% Longer duration sessions have higher prob. of quality degradation Business user workload has more quality degradation due to the longer playback time

Coordinating caching and rate adaptation Fast Cache: aggressively buffer data in advance Over-utilize CPU and bandwidth resources Neither performance effective nor cost-efficient Rate adaptation: conservatively switch to lower bit rate stream Switch handoff latency Coordinated Streaming high rate stream low rate stream Lower bound Prevent switch latency Upper bound Prevent aggressive buffering

Conclusion Quality of Internet streaming Often unsatisfactory Need to improve Modern streaming media services Over-utilize CPU and bandwidth resources Not a desirable way to improve quality Coordinated Streaming Combine merits of both caching and rate adaptation Simple but effective

Thank you!

Traffic Overview Different access patterns in user communities Not due to the business related media traffic: both are news and entertainment sites Working environment affects access pattern Media hosting services Self-hosting Third-party hosting

Streaming quality summary The quality of media streaming on the Internet leaves much to be improved

Stream thinning (play key frames only) Thinning interval Smooth play Key frame play + Stream thinning duration 30 sec 70%