1 analysis of multimedia workloads with implications for internet streaming lei guo 1, songqing chen...

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?