1
Analysis of Multimedia Workloads with Analysis of Multimedia Workloads with Implications for Internet StreamingImplications for Internet Streaming
Lei Guo1, Songqing Chen2, Zhen Xiao3, and Xiaodong Zhang1
Presented by: Zhen Xiao
1College of William and Mary2George Mason University
3AT&T Labs – Research
The 14th International World Wide Web Conference
2
Multimedia: Downloading
Web Server
Web Browser
MediaPlayer
HTTP
file
Long start-up latencyPotential waste of traffic
3
Multimedia: Pseudo Streaming
Web Browser
MediaPlayer
Web Server
HTTP
also called progressive downloading or progressive playback
4
Multimedia: Streaming
Web Server
Web Browser
MediaPlayer
HTTP
metafile
Streaming Server
RTSP/MMS/HTTP
RTP/RTCP
5
Goals and Objectives
• How is multimedia content delivery doing in practice? – Streaming has many advantages over downloading for
multimedia traffic– But what percentage of multimedia traffic is delivered via
streaming?
• What are the implications of different content delivery methods for multimedia traffic?– bandwidth efficiency, playback quality, etc.– Can we quantify the actual benefits of a streaming service?
• What can we do to improve the current content delivery practice for multimedia traffic?
6
Existing Work
• Streaming/Web sites– A small number of popular servers – No study on large number of Web sites
• Clients– Educational [USITS01][NOSSDAV01] or enterprise environments
[NOSSDAV02]– Very few study on commercial workloads
• Data Sources– Pre-stored video objects [MMCN98], server logs [NOSSDAV02]– No flow level information
• Focuses– Object popularity and sharing patterns, client interactivity
[WWW01][ICDCS05]– Few on content delivery methods
7
Our Contributions
• Analyze two large commercial multimedia workloads– Much larger scale– More detailed information (e.g., byte counters)– Focus on multimedia delivery methods, bandwidth efficiency,
playback quality
• Design and simulation of the AutoStream system– Provide streaming service for standard Web servers– Share the cost of streaming service among content providers
8
Outline
• Background
• Trace Collection and Processing
• Workload Analysis
• AutoStream
• Conclusions and future work
9
Trace Collection
• Two packet level media workloads collected with the Gigascope appliance– Server Workload: a large number of commercial Web sties
hosted by a major ISP (a Web server farm)– Client Workload: a large group of home users connected to the
Internet via a well-known cable company (cable clients)– The two workloads are independent!– 24 hour duration: 06/15/2004 8pm – 06/16/2004 8pm
• We collected:– The first IP packets of all HTTP requests and responses– The first IP packets of all RTSP and MMS control messages– Byte counters: the number of bytes transferred through each
TCP/UDP connection per second– All HTTP based P2P traffic were carefully filtered out
10
Traffic Overview
• Total data size: 100GB in gzip format• Server workload
– 1,095,984 media requests/response pairs– 4,498 unique server IPs, 79,309 unique client IPs
• Client workload– 579,693 media requests/response pairs– 13,110 unique server IPs, 7,906 unique client IPs
11
Trace Processing
• Downloading– User-AgentUser-Agent in HTTP request is a Web browser– Content-TypeContent-Type in HTTP response is audioaudio or videovideo– application/multipartapplication/multipart: based on 34 most popular suffixes
for media files (e.g. .mp3.mp3, .mpeg.mpeg, etc.)
• Pseudo streaming– Subtle differences from downloading– User-AgentUser-Agent in HTTP request corresponds to a media player
• Most streaming uses RTSP and MMS– HTTP based streaming is very small
12
Trace Processing (Cont’d)
• Processing– Decoded most popular media formats: Windows, Real, and
QuickTime– Extracted URL, media encoding rate, and playback time.– Requested traffic: Content-LengthContent-Length in HTTP response or
media length and encoding rate extracted from RTSP/MMS messages
– Transferred traffic: actually transferred data based on byte counters.
13
Outline
• Background
• Trace Collection and Processing
• Workload Analysis
• AutoStream
• Conclusions and future work
14
Multimedia Delivery Methods
Delivery Method Request Number Requested Traffic Transferred Traffic
Downloading 60,415 (87.7%) 55.02GB (53.4%) 19.89GB (63.0%)
Pseudo Streaming 6,637 (9.6%) 30.81GB (29.9%) 8.79GB (27.9%)
Streaming 1,831 (2.7%) 17.17GB (16.7%) 2.88GB (9.1%)
Server Workload
Delivery Method Request Number Requested Traffic Transferred Traffic
Downloading 58,086 (64.7%) 93.37GB (37.5%) 46.18GB (58.1%)
Pseudo Streaming 22,272 (24.8%) 72.02GB (28.9%) 18.44GB (23.2%)
Streaming 9,422 (10.5%) 83.69GB (33.6%) 14.81GB (18.6%)
Client Workload
15
Object Size: Server Workload
% Connections % Traffic
Media traffic is always dominated by large objects
16
Object Size: Client Workload
% Connections % Traffic
17
Early Terminated Connections
% Connections % Traffic
Compared with downloading, clients using pseudo streaming tend to abort more and early, and hence cause less traffic.
18
Client access duration in streaming
Server Workload Client Workload
11%
44%
20%
35%
Compared with downloading and pseudo streaming, clients using streaming are much more likely to terminate their access to an object earlier.
19
Bandwidth EfficiencyDefinition: The percentage of requested traffic that was actually transferred.
20
Rate Mismatch in Pseudo Streaming
Server Workload Client Workload
• Downloading rate: averaging the transferred bytes over the data transmission time.• Streaming rate: average object encoding rate
Rate mismatch in pseudo streaming is common, which can cause the client to experience frequent delays in order to refill its buffer.
21
Advantages of Streaming• Rate adaptation
– Transcoding– Multiple-Bit-Rate Encoding
• Intelligent Streaming from Microsoft• SureStream from Real Networks
– Frame thinning
• Prioritized retransmissions– UDP based streaming
• Server workload: RTSP: 10.4%, MMS: 23.5%• Client workload: RTSP: 26.8%, MMS: 21.5%
– Only re-send lost packets that can arrive in time for the playback
• Support for interactive operations– Pause, fast forward, rewind, etc.
22
Summary of Findings
We found• Streaming is the most efficient approach for multimedia delivery.
but• Most multimedia traffic is delivered via downloading.
Why is streaming not widely used?• Streaming has associated expenses• Benefits not obvious
AutoStreamAutoStream• Share the cost of streaming among content providers• Try streaming before you buy
23
Outline
• Background
• Trace Collection and Processing
• Workload Analysis
• AutoStream
• Conclusions and future work
24
AutoStream Overview
AutoStream
Server Farm
Client
Existing Web servers can provide real streaming service!
HTTP
HTTP
HTTP
RTSP/MMS/HTTP
RTP/RTCP
Try before you buy!
server
server
25
AutoStream Architecture
Client
Request Handler
Virtual Streaming Engine
WindowsMedia
StreamingEngine
Prefix Cache Engine
RealMedia
StreamingEngine
QuickTimeMedia
StreamingEngine
Streaming Media Converter
26
Evaluation
• Trace driven simulation using the server workload– On-demand cache with initial segments only. Cache cleaned
hourly– When converting non-streaming traffic into streaming, assume
the same access patterns as existing streaming traffic– When the available bandwidth to a client is lower than the
encoding rate of the media, transcode the media into an appropriate lower encoding rate
• Metrics– Traffic reduction due to changes in access patterns
• Benefit of prefix caching is not included
– Start-up latency reduction for downloading traffic
27
Traffic Reduction
AutoStream reduces downloading traffic by 78% and pseudo streaming traffic by 72%. Without transcoding, the reductions are 56% and 43%.
28
Start-up Latency Reduction
63% sessions previously experiencing start up delays no longer do after AutoStream
29
Outline
• Background
• Trace Collection and Processing
• Workload Analysis
• AutoStream
• Conclusions and future work
30
Conclusions and Future Work
• We found that streaming has many benefits for delivering multimedia traffic, but only limited deployment.
• We proposed AutoStream, a system to bridge the gap between the potential and practice in multimedia delivery.
• Lesson learned – always do reality check– Don’t assume “If a technology is good, it’ll be used.”
• Future work– Multimedia delivery in peer-to-peer systems– Streaming delivery quality on the Internet
31
Thank you!
Questions?
Top Related