A Hybrid Caching Strategyfor Streaming Media Files

Jussara M.Almeia, Derek L.Eager, Mary K. VernonDepartment of Computer Science,

University of Wisconsin-Madison, USAUniversity of Saskatchewan, Canana

2006.3.23SNU, OSLAB

Speaker : Kim Jungkuk

SNU, OSLAB

Table of Contents

Introduction Background

Current Caching Policies Caching Policy Comparison Improving Current Policy

Pooled RBC LFU/IC Experimental Results

Conclusion Future Work

SNU, OSLAB

Introduction

Evaluate several policies for caching streaming media files at proxy servers LFU, RBC, Interval Caching, etc.

Compare LFU to RBC Pooled RBC improved in 4 parts, compared to RBC

Suggest a new hybrid LFU/IC policy (maybe best for VOD-like workloads) much simpler to implement than (Pooled) RBC performs better than ordinary LFU not compared with LRU yet

SNU, OSLAB

Introduction

Characteristics of Streaming media files video files are big

most of cached content needs to be stored on disks both disk cache & main memory buffering need to be

managed well real time media file transfer require a significant

amount of disk & network i/o bandwidth for a long time. effective caching algorithm needed not to interfere current streaming services disk bandwidth utilization is important to save new

contents partial file caching is also important (for various client workloads, e.g., VOD searching)

SNU, OSLAB

Introduction

Parallel work considers a proxy cache distributed among N servers in which each

video is partitioned into N blocks for load balancing purpose

use a set of client request traces

to compare several hierarchical

file/block-level caching policies, including LFU, FIFO, LRU-k

SNU, OSLAB

LFU caching policy

simply caches the (partial) files to have highest access frequency

key open questions data granularity

using the granularity of the data request issued by clients. measuring separately layer by layer

current access freq. estimation (at actual system) ref. counts with an aging mechanism ref. counts by weighting the fraction of the file accessed the mean time b/w requests

overall consumption each policy knows access frequency perfectly

SNU, OSLAB

Interval Caching Policy

caching partial video streams in main memory Interval : deleted when the second client

receives it Run : deleted when a later client

receives it

SNU, OSLAB

RBC (Resource Based Caching) utilizing the limited resource, either disk

space and disk bandwidth characterizes each file object by

its space and bandwidth requirement caching gain measure (read client request * bit rate)

intuitive goal to maximize the disk bandwidth leads to optimal policy performance (that is, estimation accuracy & system not

bandwidth-constrained) caches a mixture of intervals & full files

SNU, OSLAB

RBC (Resource Based Caching) Caching Procedure

Step1 : using Table 2a to select the granularity of file (interval, run, full file)

Step2 : using table 3 to decides if the entity selected in step 1 should be cached

manages 2 ranked list of cached entities Space goodness list Bandwidth goodness list to keep bandwidth & space utilization equal using step1

when choosing the granularity of the entity to cache cf.)to use step1 (Table2.b) in Pooled RBC (choose entity max.

Gspace)

SNU, OSLAB

RBC (Resource Based Caching) Parameters used in RBC (Tbl. 1)

SNU, OSLAB

RBC (Resource Based Caching)

RBC Step 1 (Tbl. 2) Select granularity of entity

a) original RBC

b) proposed simplified step 1

RBC Step 2 (Tbl. 3) Caching Decision for entity

SNU, OSLAB

Caching Policy Comparison

Primary metric byte hit ratio

the fraction of the total bytes delivered that are delivered from the cache (cf.) hit ratio

System Assumptions The proxy server has sufficient network i/o

bandwidth for streaming data from its memory and disk

SNU, OSLAB

Caching Policy Comparison

System Assumptions a fixed number of files, n, each access is independent fixed access frequencies skewed as defined by a Zipf-like dist

ribution with parameter θ (i.e., Pi=P(access file i) =C/i(1- θ)) (for videos & web content) all files have the same size & same delivery rate (r) each client requests the entire file, thus the delivery time T is

same for all. client request arrivals are Poisson, with request rate λ (web pr

oxy) files are placed on several disks for load balancing

SNU, OSLAB

Caching Policy Comparison

System workload Parameters Cache size ( C )

a fraction of the total file data. captures T & r (uniform file duration T, uniform file streaming rate r) ranges from 0 to 1

total client request arrival rate (N) average # of client requests that arrive during the avg. time it

takes to stream a file to a single client. related to total bandwidth (sufficient b/w for deliver all

request?) normally 100 to a few thousands

total disk bandwidth (B) r * S^ , where S^ is the average # of active streams that are

needed to deliver the data that is cached by the LFU policy.

SNU, OSLAB

Caching Policy Comparison perf. comparison of RBC & LFU (n=100)

insensitive to arrival rate N sensitive to B & C LFU > RBC only on red circle

SNU, OSLAB

Caching Policy Comparison

Impact of system parameters

insensitive to number of files, n (C=10%, N=40)

SNU, OSLAB

Caching Policy Comparison Avg. fraction of each file cached by RBC (N=450, n=100, C=0.25)

RBC doesn’t allow unused b/w that is currently allocated to one file to be used to serve a request to another file

RBC only caches a file if there is enough unallocated disk b/w so, RBC caches fewer files than LFU.

SNU, OSLAB

Caching Policy Comparison

Space & Bandwidth Utilization

SNU, OSLAB

Improving RBC and LFU

Pooled RBC bandwidth pool

enables full files to share bandwidth allocation whenever a new full file is added to the cache, its b/w allocation is added to the b/w pool when request, new stream from b/w pool is assigned. when finished, b/w is returned to the pool. uses Tbl.2.b simplified step 1. to select granularity. if no more steam from b/w pool, forward req. to

remote server rather trying to evict entity. allow intervals to remain in cache when file is

evicted.

SNU, OSLAB

Improving RBC and LFU

Perf. of pooled RBC & LFU (N=450,n=100)

SNU, OSLAB

Improving RBC and LFU

Hybrid LFU/IC Disk Caching improve perf. by storing intervals in a small, separat

e cache, either in main memory or in a small fraction of the available disk space

LFU/ICmem, Pooled RBC/ICmem better perf. than ordinary LFU & Pooled RBC

LFU/ICdisk if a file becomes suddenly very popular, interval caching ca

n be used to serve some requests from the proxy while enough info. becomes available

to decide to cache the entire file in the LFU disk cache

SNU, OSLAB

Improving RBC and LFU

Perf. of Hybrid RBC&LFU w/ ICmem (M=0.25%)

SNU, OSLAB

Improving RBC and LFU

Perf. of Hybrid LFU/ICdisk (s=5%)

if s=10%, hurts performance for cache size C > 0.8

SNU, OSLAB

Conclusions

RBC > LFU if excess disk bandwidth and cache size is small. In other cases, LFU > RBC.

Pooled RBC has 4 improvements to RBC. sharing of allocated bandwidth among the cached files improvement in bandwidth deficient and balanced

system. but, (Pooled) RBC share a complex implementation

and high time complexity Hybrid LFU/IC policy shows better performance

with Interval caching done in a separate small cache, either in main memory or on disk

SNU, OSLAB

Future Work

Evaluating caching policies using workload traces from client request logs for various VOD servers.

Workload trace include an unknown and dynamically changing set of file access frequency

Practical method of estimating file access freq.

Comparing LFU/IC to LRU-k policy