Mocha : A quality adaptive multimedia proxy cache for Internet streaming

Mocha: A Quality Adaptive Multimedia Proxy Cache for Internet Streaming

Reza Rejaie

AT&T Labs - Research Menlo Park, CA. 94025

[email protected]

Jussi Kangasharju

Institut Eurecom Sophia Antipolis, France

[email protected]

ABSTRACT

Multimedia proxy caching is a client-oriented solution for

large-scale delivery of high quality streams over heteroge-

neousnetworkssuchas theInternet. Existingsolutionsfor

multimedia proxycaching are unable to adjust quality of

cachedstreams. Thusthesesolutionseithercannotmaxi-

mizedeliveredqualityorexhibitpoor cachingeÆciency.

ThispaperpresentsthedesignandimplementationofMocha,

aquality adaptive multimediaproxy cache for layered en-

codedstreams. ThemaincontributionofMochaisitsability

to adjust quality of cached streams based on their popu-

larity and on the available bandwidth between proxyand

interested clients. Thus Mocha can signicantly improve

caching eÆciencywithout compromising delivered quality.

To perform quality adaptive caching, Mocha implements

ne-grainedreplacementandne-grainedprefetchingmecha-

nisms.WedescribeourprototypeimplementationofMocha

ontopofSquidand addressvariousdesignchallenges such

asmanaging partiallycachedstreams. Finally,wevalidate

ourimplementationandpresentsomeofourpreliminaryre-

sults.

1. INTRODUCTION

Most of today's Internet streaming applications have a

client-serverarchitecturewhereaserverpipelinesarequested

streamtoaclientthroughthenetwork. Theclient-serverar-

chitectureforInternetstreaminghastwomajorlimitations.

First,itdoesnotscaletoalargenumberofclientsbecause

streaming applications consume networkbandwidth along

thepathfromtheservertotheclientfortheentiresession.

Second,thequalityofpipelinedstreamislimitedtothebot-

tleneckbandwidthalongtheserver-clientpath.

To achieve scalability and deliverhigh quality streams,

multimediacontentshouldbemaintainedclosetointerested

clients. Proxy caching of multimedia streams is a client-

orientedsolutionthataddressesbothlimitationssimultane-

ously. Similar to Web proxy caching, caching of popular

streams at a proxy substantially reduces the load on the

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

NOSSDAV’01, June 25-27, 2001, Port Jefferson, New York, USA.

Copyright 2001 ACM 1-58113-370-7/01/0006 ...

5.00.

C1

C2 Proxy

Server

C3 100 Kbps

2 Mbps

500 Kbps

56 Kbps

Figure1: Multimedia ProxyCaching

network(andtheserver),whichinturnaccommodatesscal-

ability. Furthermore, since a proxyis located close to its

clients,itcaneectivelyavoidnetworkbottleneckandmax-

imize deliveredqualityandaccommodateclientbandwidth

heterogeneity. Theability toadjustthequalityofacached

streamisacrucialrequirementformultimediaproxycaching

mechanismsinheterogeneousnetworkssuchastheInternet

that has not been well-understood. To justify this claim,

consideraproxythathasthreeclientswithdierentband-

width(Figure1). Tomaximizedeliveredqualityofacached

streamsto allclients,theproxyshouldbeable toprovide

appropriate versions of stream s that can be pipelined to

each client. This implies that caching mechanisms should

be quality adaptive. There are two alternativesto achieve

qualityadaptivecaching: 1)Cachingdierentencodedver-

sionsofstreamswithdierentquality,or2)Cachinglayered

encodedversion ofstream swhere the appropriatequality

(i.e., numberoflayers) for eachclient is determinedbyits

bandwidth[1]. Layered encoding is an eÆcient and exi-

bleway toadjust quality ofcachedstreamswithoutlosing

cacheperformanceduetothefollowingreasons:1)Multime-

diastreamsareordersofmagnitudelargerthantypicalWeb

objects.Thuscachingmultipleversionsofeachstreamcould

signicantlyreduce cacheutilization; 2)Layeredorganiza-

tion provides an opportunity to improve delivered quality

ofacachedstreamon-the-ywherelowerlayersareplayed

backfromthecacheandhigherlayersaredeliveredfromthe

server.

Thereforethedesignofamultimediaproxycachingmech-

anismshouldaddresstwokeyissues:

1. Whichstreamsare suÆcientlypopulartobecached?

2. Whatistheappropriatequalityforeachcachedstream?

Therstissue inessenceisaWebcachereplacementprob-

lem. The second problem, however, addresses the notion

of qualityforcachedstreamsas anewdimensionindesign

of caching mechanism that does notexist in Webcaching

schemes. Ifamajorityof clientscanonlyaordto receive

alowqualityversionofstreams,theproxycancacheonly

the low quality (and thus smaller) version of the stream

toimprovecacheutilization. Toadaptively increaseorde-

crease quality of cachedstreams, the proxyshould imple-

mentne-grainedprefetching andne-grained replacement,

respectively. Furthermorethe servershouldprovideaccess

toaportionofalayeredencodedstream.

Most of the work on design and development of multi-

mediaproxycacheshas onlyfocusedontherstissue and

treatedmultimediastreams inanatomicfashionsimilarto

Webobjects. Theseapproaches could resultinpoor cache

utilization since multimedia streams are orders of magni-

tudelargerthantypicalWebobjects. Admittedly,thisisin

partdueto lackofsupportforlayeredencodedstreamsby

majorcontentproviders. Mostofthepreviousworkonmul-

timedia proxy caching address neither networkbandwidth

heterogeneitynortheneedforrateandqualityadaptation.

Therefore they are not suitable for the Internet. To the

bestof our knowledge, Mochais the rstquality adaptive

multimedia proxy cache. Design and evaluation of multi-

mediaproxycaches are stillimmatureincompare to Web

cachingschemes.JudgingbasedontheworkonWebcaching

schemes,designandevaluationofmultimediaproxycaching

mechanismsclearlyrequiresubstantiallymoreinvestigation.

This paper presents the design and implementation of

Mocha,amultimediaproxycacheforlayeredencodedstreams

ontop ofSquid[2]. Mocha's keycontribution is itsability

toperformqualityadaptivecaching. Mochacachespopular

streams and adaptively adjusts quality of cached streams

basedon bothstream popularity and available bandwidth

to interestedclients. Mochaleverages layered structureof

streams to implement ne-grained replacement and ne-

grained prefetching mechanisms. Therefore,Mochais able

tomaximizedeliveredquality foragroupofheterogeneous

clients without compromisingcache space utilization. We

addressthehighlevelarchitectureofMochaanddiscussthe

mainissuesandchallengesinthedesignofkeycomponents

ofthearchitecture.Wevalidateourprototypethroughvar-

iousexperiments, and present someof our preliminaryre-

sults.

Mocharequiresaclient-serverarchitecturethatsupports

layer-encodedstreaminginordertoadaptqualityofcached

streams.Mochacanalsomanagenon-layeredencodedstreams.

However,itcannotadjustqualityofcachedstreamsinthis

scenario. Wehaveprototypedamodularclient-serverarchi-

tecture[3]fordeliveryoflayeredencodedstreamasshownin

Figure2. ClientandserveruseRTSP[4]forsignaling. The

serverperformscongestioncontrol[5]todeterminefairshare

of bandwidth. Then a layered quality adaptation mech-

anism [6] matches the number of transmitted layers with

average bandwidth. Althoughweare interestedinunicast

streaming,weusedRTP[7]fordatapacketsandRTCPfor

ack packets. Eachlayeristransmitted throughaseparate

RTPsession. However,congestioncontroliscollectivelyper-

formedacrossall RTPsessions. Theclientreceivespackets

ofdierentlayersand rebuildsthestreaminareorganiza-

tionbuerbeforesendingthestreamtothedisplay.

The rest of this paper is organized as follows: Section

2 justies why we developed Mocha on top of Squid and

sketchesthe highlevelarchitectureofMochaby describing

itsrequestmanagement. Section3addresses designissues

Quality Adapt

Buffer Request Mang.

RTP Cong Control Acker RTP

Re-org.

Buffer

Display Client Mang.

RTSP Client

Internet

Ack Ack Ack Ack

data RTP Pkt

RTP Pkt

RTSP Server

Loss Repair

Decoder

Layered Enc.

Streams

Server Client

Figure 2: Client-serverArchitecture

and challenges for the keycomponents of Mocha. Section

5 briey reviews related work. In Section ??, we report

some preliminary experimental results. Finally, Section 6

concludesthepaperandaddressesourfuturedirections.

2. ARCHITECTURE

Mochawasdevelopedontopofopen-sourcecodeSquid[2].

Our main motivation was to leverage generic components

of Squid (such as requestprocessing, storage and memory

management, andgeneralutilityroutines for memoryallo-

cation and event handling) that can be reused for multi-

mediacachingwithlittle ornomodication. Forexample,

we took advantage of similarity inmessage processing be-

tweenHTTPandRTSP,andsimplyreplaceHTTProutines

withtheir RTSPcorrespondent. Thereforewe onlyneeded

toaddthosecomponentsthatarerequiredtocacheandre-

play layered encoded streams. This substantially reduced

ourprototypinganddebuggingphases. Obviously,building

on top of Squid introduced a few restrictions and limita-

tions. For example, we neededto extendstorage manage-

ment routines such that all layers of a cachedstream are

collectivelyviewedasasingleobjectbySquid. Moreimpor-

tantly,Squid'slesystemisprobablynotoptimizedtostore

multimediaobjects. Thusitislikelythatourcurrentimple-

mentationdoesnotscale toalargenumberofclients. For-

tunately,Squidhasamodularstructureandwecanreplace

its lesystem routines wheneverit becomes a bottleneck.

AnotherkeyrequirementforeÆcienthandlingofstreaming

objectsismanagementofdiskbandwidth. Weneedtoadd

suchamanagementmechanismtoachievehighperformance.

Placementandretrievalofmultimediastreamshavebeenex-

tensivelystudiedinthecontextofmultimediaservers(e.g.,

[8]). Ourgoalistostudytransportissuesforobjectmanage-

ment acrossthe Internetratherthanwell-understoodlocal

resourcemanagementissuesattheproxy.

Mochaappearsasaclientforaserverandasaserverfor

aclient. Figure3depictstheinternalarchitectureofMocha

as a combinationof aclientand a server. We explain the

functionalityofindividualcomponentsbydescribingrequest

managementinMocha.

2.1 Request Management

Quality Adapt

RTP Cong Control

Acker

Request Mang.

RTSP Client

Ack Ack Ack

Ack

data RTP Pkt

RTSP Server

Loss Repair Memory

Cache

Prefetching Mang.

Server Side Client Side

Data Packets

Data Packets RTSP

Messages

RTSP Messages

Figure3: InternalArchitecture of Mocha

nalingbetweenMochaandclientorserver. Uponarrivalofa

RTSP/SETUPrequestforastreams,RMcheckstheavail-

abilityofs inthecache,andoneofthefollowingscenarios

occurs:

CacheMiss:Ifsismissingfromthecache,RMrelays

all RTSP message in both directions between client

and original server (or another proxy depending on

conguration). Mocha alsorelays dataand acknowl-

edgment(ACK)packetsinbothdirectionsasshownin

Figure4Obviously,packetrelayingprocesswillintro-

duceadelaybutweexpectthedelaytobesmallunder

moderateloadontheproxy. Therefore,theserveref-

fectivelymeasureslossesandround-trip-time(RTT)of

the server-client connection, andadaptsitstransmis-

sionrateanddeliveredquality(i.e.,numberoflayers)

accordingly. This implies that on a cache miss, the

session is end-to-end and quality of the played back

stream is limited by the bottleneck bandwidth, i.e.,

proxy can not improve delivered quality on a miss.

Noticethattheoriginalservercansendeitherastored

or evenalive stream. Mochacaninterceptall trans-

mitteddatapacketsandcacheacopyofthedelivered

stream.

Cache Hit: Ifa copy of s is available inthe cache,

MochaactsasaserveranddirectlyrepliestoallRTSP

SETUP SETUP

OK

OK PLAY PLAY

OK OK

Data

Data Ack Ack

TEARDOWN TEARDOWN

OK OK

Server Mocha Client

Time Time Time

Figure 4: RTSP signaling and data delivery on a

SETUP

SETUP OK

OK PLAY

OK

OK

Data

Ack

Ack

TEARDOWN

OK

OK

Server Mocha Client

Data

PLAY/Range

Data OK

TEARDOWN

Time Time Time

Figure5: RTSPsignaling anddatadeliveryonahit

messagesasshowninFigure5. UponarrivalofPLAY

requestfromclient,Mochainitiatesdeliveryofcached

streamwhile performing rateand quality adaptation

basedon thestate of the proxy-client connection. If

the quality of the cached stream is lower than the

maximumdeliverablequalitytotheclient,prefetching

managerestablishesaprefetchingsessiontotheserver

toprefetchmissingpartsofanexistinglayeraswellas

higherlayersofrequested streamon-the-y. Thuson

acachehit,Mochashouldmanagebothplaybackand

prefetchingsessionssuchthatprefetchedsegmentsar-

rivebeforetheirplayouttimestobeproperlymerged

withplaybackstream. Fine-grainedprefetchingisdis-

cussedinmoredetailsinsubsection3.2.

3. MAIN COMPONENTS

In this section, we discuss the design and implementa-

tion of three key components that are unique in Mocha:

Object Management, Fine-grained Prefetching, and Fine-

grainedReplacement.

3.1 Object Management

MochacachesRTPpacketsinsteadoftheirrawpayload.

AlthoughcachingheaderofRTPpacketsreducescachespace

utilization,theproxydoesnotneedtodealwithvariouspay-

loadformatsandbecomes content-independent. Mochare-

liesonRTPsequencenumbertodetectmissingsegmentsof

alayer,andusesRTPtime-stamp(andmarkerbit)tostore

andplaybackRTPpacketsproperly. Mochacanalsomain-

tainafewwell-acceptedRTPprolestoproperlyinterpret

RTPheaderinformation.

Oneofthemainchallengesinthedesignofstorageman-

agementforMochawastostoreandaccesspartiallycached

layersofasinglestreameÆciently. SinceWebcaches store

or ush anobjectin anatomic fashion, we needed to ex-

tendSquid'sdatastructurestomaintaininformationabout

cached segments of all layers. Furthermore, all layers of

eachstreamshouldbecollectivelyviewedasasingleobject

bySquidinordertoreuseitsbasicobjectmanagementfea-

tures(e.g.,checkinghitormissscenarios). Squidmaintains

..

Store Entry

Chunk 1 Chunk 2 Chunk n

Memory Disk

Chunk Hdr Chunk Hdr Chunk Hdr

Pkt 1 Pkt 2 Pkt 3

Layer 0

Pkt 4 Link List L

0 Link List L

n

. . .

. . .

Figure6: Datastructuresforobjectmanagementin

Mocha

tioniskept. Figure6shows howweextendedSquid'sdata

structures to manage layered encoded streams in Mocha.

Packetsofeachlayerofacachedstreamarestoredinasep-

arate le. Each le contains a collection of chunks where

a chunk consists of a groupof contiguous packets. Loca-

tion of a packetin a chunk canbe easily calculated if all

packetshave thesamesize. Butinageneralcase, packets

canbe variable insize. To allow quick traversal within a

chunk,weinterleavedpointers to thenextpacketbetween

everytwopacketsineachchunk.Inordertoquicklylocate

aspecic chunk,Mochamaintainsa linkedlist inmemory

foreachlayerofanactivestreamthatisbeingplayedback.

Eachelementof thelinkedlist pointsto oneoragroupof

chunksondisk. Thus by traversing the linkedlist, Mocha

canrapidlyidentifythelocationofaspecicchunkondisk

and minimizedisk access. The bigger the chunk size, the

shorterthelinkedlist,butittakeslongertoreachaspecic

packetwithinachunk.

Mochatreatsachunkasaanatomicunit, i.e.,allpack-

ets of a chunk are cached or replaced together. When a

holeinsequencenumberisdetectedorN contiguouspack-

etsarrive,allthepreviouslyreceivedpacketsarecachedasa

chunk. Whilechunkscanhavevariablesizes,Mochalimits

themaximumnumberofpacketsinachunk(i.e.,N). When

amissingpacketarrivesduringprefetching,twosmalladja-

cent chunkscanbeconsolidated. Theinteractionsbetween

consolidationandne-grainedreplacementresultinasetof

pseudo-balancedchunks.

3.2 Fine-grained Prefetching

Mochaimplementsonlinene-grainedprefetchinginorder

toimprovethe deliveredqualityofacachedstream. When

thequality ofacachedstreamis lowerthanthemaximum

deliverablequalitytoaninterestedclient,Mochainitiatesa

connectiontotheserverandactsasaclient. Thenitsends

prefetching requestsfor missingpiecesofactivelayersthat

arelikely tobe neededduringtheplayback. Eachmissing

packetshouldbeprefetchedbeforeitsplayouttime. Since

theprefetchingsessioniscongestioncontrolled,theavailable

server-proxybandwidthisnotknownaprioriandcouldvary

intime. Theavailableprefetchingbandwidthshouldbeused

1 2

3 8 4 5 6 7 9

Time

Quality(layer)

T

t

δ

Quality of Cached Stream

Figure7: OnlinePrefetchingin Mocha

suchthat prefetching sessionremains looselysynchronized

withtheplaybacksession.

Toachievethis,wedevisedaslidingwindowapproachto

prefetching that is illustrated in Figure7. At time t dur-

ing playback, theprefetchingmanager examines awindow

of time in the future ([t+T, t+T +Æ]) to identify re-

quiredpacketsthataremissing. Ifrequiredsegmentsarein

thecache,theyarefetchedintothememorycachetoavoid

any potential delayduring disk access. At the sametime,

Mochasendsasingleprefetchingrequestwhichcontainsan

ordered listofall requiredbutmissingpacketsofthis win-

dow. Requestedpacketsare orderedbasedontheirimpor-

tance,i.e.,basedonlayernumberandwithinalayerbased

ontheirplayouttimeinaround-robinfashionasnumbered

inFigure7. Theserverdelivers requestedsegmentsinthe

speciedorderthroughacongestion-controlled connection.

Thus, in the absence of suÆcient prefetching bandwidth,

only the most important segments are delivered. After p

seconds,Mochaexaminesthenextprefetchingwindowand

sends another prefetching request to the server. To keep

playbackandprefetchingsessionlooselysynchronized,each

prefetching requestwill pre-emptany previous prefetching

request. Insummary,onlineprefetchinghasthreeparame-

ters, 1) Æ,Length of prefetching window, 2)T, look-ahead

distanceand3)p,slidingperiodwherepÆ.Ifp<Æ,there

is anoverlap between adjacent windows whichresults ina

moreconservativeuseofprefetchingbandwidth.

The \Range" header eld of RTSP PLAY method was

usedtoprefetchagroupofcontiguouspacketsofalayer. We

extendedthe\Range"headereldtocarrymultipleranges

of several layersina singleRTSP message. Anotherissue

wassequentialprocessingofRTSPPLAYrequests. Toallow

anewprefetchingrequesttopre-emptpreviousprefetching

requests,weintroducedanewtypeofRangeeldinRTSP

thatcanbeover-writtenbynewRangerequests.

BesidesthedatastructuresdescribedinSection3.1,Mocha

maintainsstatusofcachedpacketsofall layersofastream

inabitmap. The bitmapis usedtoimplementthe sliding

windowapproacheÆcientlybecausemissingpacketscanbe

identiedwithoutaccessingthe harddisk. Atanypoint of

time,onlybitmapsofactive streamsare keptinthemem-

ory. We plan to add ano-line prefetching mechanism to

Mocha.

3.2.1 Memory Caching

Squidhasabuilt-inmemorycacheontopofstoragethat

holdspopularobjectsinaLRUfashiontominimizediskac-

cess. Mochaleveraged thismemorycachewithsomemod-

the memory cache temporarily locks cached packets that

are fetchedfrom disk ahead of time as well as prefetched

packets from the serveruntil they are played out or their

playouttimesexpire. Thereforeatanypointoftimeawin-

dowoffetchedorprefetchedpacketsaremaintainedinthe

memorycache.

3.3 Replacement Policy

WemodiedSquidreplacementpolicytoimplementne-

grainedreplacementmechanism. Squidperiodicallyinvokes

replacementroutinesandiftheamountoftotalcacheddata

is higher than a congured high-water mark, a suÆcient

numberof leastpopular objects are evicted. Webasically

replacedthevictimselectionmechanism.

Inorderto implementne-grainedreplacement,weneed

todenene-grainedpopularity,i.e.,assignpopularityval-

uestopiecesofastream.Sincequalityofacachedstreamis

determinedbynumberofcachedlayers,Mochaassignspop-

ularity toindividuallayers. Popularity oflayeriof stream

sisdenedasfollows:

Pi(t)= P

t

x2[t ;t]

whit(x;i),

whit(x;i)=

PlayTime(x;i)

StreamLength(s)

where whit(i;x) is weighted hit of layer i during session

x. Weusedthecumulativevalueofwhitacrossallsessions

over a recent window of time ([t ..t]) as popularity of

a layer. This denition of popularity captures both level

ofinterestamongclientsandavailablebandwidthto inter-

estedclients[1]. Consequentlylowerlayersofanunpopular

streammightbeushedbeforehigherlayersofstreamsthat

are popular among high bandwidthclients. Furthermore,

thisdenitionguaranteesthatwithinasinglestream,pop-

ularitymonotonicallydecreaseswithlayernumber,i.e.,the

victimlayeris alwaysthehighestlayerofacachedstream.

Popularity of all cachedlayers are maintained in asorted

linkedlist, called popularity list. Thusavictimlayeris al-

ways at the end of the list. At the end of each session,

whitandpopularityofactive layersare updatedand their

locationinthepopularitylist ischangedaccordingly.

AlthoughMochakeeps track of popularity of individual

layers, replacement is performed at a per chunk basis to

achieve highcachespace utilization. Whenthe amountof

cached data exceeds the high water mark, Squid invokes

Mocha'sreplacementroutine. Theleastpopularlayerisse-

lectedasvictimandchunksofavictimlayerareushedfrom

theendtothebeginning,untiltotalamountofcacheddata

islessthanthehighwatermark. Theinteractionsbetween

ne-grained replacement and sliding window approach to

prefetchingsmoothoutqualityofcachedstreams.

ne-grainedreplacementcanpotentiallyresultinthrash-

ing where packets of a cachedlayeris ushed in orderto

make roomfor prefetchedpacketsof a higher layerof the

samestream. Topreventsuchbehavior, Mochaemploysa

simplelockingmechanism. Allactivelayersthatare being

playedbackarelockedfortheentiredurationofthesession.

4. EXPERIMENTS

We are currently validating our prototype implementa-

tion. Inthissection, webrieypresentsomeofourprelim-

inaryresultstoillustratethebasicfeaturesofMocha. Our

0 1000 2000 3000 4000 5000

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5

Number of requests

Number of cached layers

Stream 00 Stream 25 Stream 49 Stream 00 Stream 25 Stream 49

Figure8: Quality ofcachedstreams

widthof all layersis 6 Kbps. Stream lengthswerechosen

randomlywithintherangeof[30sec.. 180sec]. Wegenerate

a requestsequencewith 5000 requests and Zipf-like popu-

laritydistributionwithpropertemporallocality.Popularity

ofstreamsmonotonicallydecreaseswithstreamID,i.e.,s0

is the most popular. The cache size is 30% of the size of

data set. Thevalue ofpopularity windowis innite (=

1). We use the topologyin Figure1, and a client-server

architecturethatissimilartoFigure2.

First, we examine the behavior of ne-grained replace-

mentmechanismwhentheonlineprefetchingmechanismis

turned o. Weconductanexperiment withasingleclient

where proxy-client bandwidthis only24Kbps(i.e., 4 lay-

ers). Figure 8depictsvariationsinqualityof threecached

streams (s0,s25,s49) withminimum,moderateand maxi-

mumpopularity during the experiment, respectively. The

timeof eachrequestfor thesethreerepresentative streams

isalsoshownatthetopofFigure8. Thisgureclearlyillus-

tratestheimpactofstreampopularityondynamicsofcache

replacement.s

0

quicklybecomespopularandall4layersare

cachedfor the entireexperiment. s49 neverbecomes suÆ-

cientlypopulartostayinthecache,thusalllayersofs49are

always playedback from the serverand are removedfrom

the cacheafter ashortperiod. Afterseveralclose requests

fors25earlyintheexperiment(requestnumber<500),all

4layersofs25are cached. Thenitsqualityisgraduallyde-

gradedsinceotherstreamsbecomemorepopularthans

25 .

Sincethene-grainedprefetchingmechanismisturnedo,

higherlayersofs49arenotprefetchedevenwhenitbecomes

morepopularlaterintheexperiment.

Nextweturnedonthene-grainedprefetchingmechanism

toexamineitsinteractionswiththene-grainedreplacement

mechanisminthepresenceoftwoheterogeneousclientswith

36Kbpsand12Kbps bandwidth. Weuseasmallerdataset

with20streamswherestreamlengthsarechosenrandomly

withintherangeof[30sec.. 180sec]. Wegeneratearequest

sequence withZipf-like popularity distributionand proper

temporallocality.Toexaminetheeectofclientbandwidth,

70%oftotalrequestsforeachstreamareissuedbythehigh

bandwidthclient and the restare issued by thelowband-

0 200 400 600 800 1000 1200 0

1 2 3 4 5 6

Request number

Number of cached layers

Stream 000 Stream 012 Stream 019 019 − 2 layers 019 − 6 layers 012 − 2 layers 012 − 6 layers 000 − 2 layers 000 − 6 layers

Figure9: Quality ofcachedstreamsunder prefetching andheterogenous bandwidth

ure9depictsthevariationsinqualityofthreerepresentative

streams(s0, s12, s19) withminimum, moderateand maxi-

mum popularity during the experiment, respectively. The

timeofeachhighandlowbandwidthrequestforthesethree

representativestreams are shownat the topof this gure.

All 6 layers of the most popular stream (s

0

) are brought

into the cache at the beginningand stay in the cache for

therest of the experiment. All6 layersof the moderately

popularstreams12 arecachedaftertherstrequestfors12

from the high bandwidthclient. The following 2requests

fors12 fromthelowbandwidthclientwereservedfromthe

cache. Thenthetop4layersarereplacedsincetheyhavenot

beenrequested suÆciently. However, the lower2layersof

s12remaininthecachebecausethesetwolayersareplayed

inrequestsfrombothhighandlowbandwidthclients,and

thereforetheyaremorepopular. Similartothepreviousex-

periment,requiredlayersoftheunpopularstream(s

19 )are

always played back from the serverand stay in the cache

onlyforashortperiodoftimesincetheyarenotsuÆciently

popular. Therefore prefetching is never triggered for this

stream.

Figure 10shows average delivered quality of all streams

overtheentireexperimentas afunctionofstreamID.Ide-

ally,averagedeliveredqualityofeachstreamshouldmono-

tonically decrease with stream popularity. However, Fig-

ure 10 doesnot illustrate sucha characteristics. A closer

examination of our results revealed that this behavior is

caused by our LFU replacement algorithm. Thechoice of

=1impliesthatourreplacementalgorithmisavariant

oftheLeastFrequentlyUsed(LFU)algorithm. LFU-based

algorithmshavethewellknownanomalythattemporaldis-

tributionofrequestsplaysasignicant roleindetermining

thepopularitiesofthestreamsinthecache[9]. Alesspop-

ularstreamcanstayinthecacheforalong timeifalarge

numberofrequestsfor this stream arrivesearlyinthe ex-

periment. This suggeststhe use oflimited values forin

order to age the stream popularities with time similar to

LRUalgorithm. Wearecurrentlyinvestigatingthisissue.

5. RELATED WORK

Multimediaproxycachingisanewresearchareathathas

not been suÆcientlyexplored. During recent years, a few

commercial multimediaproxycaches have beendeveloped

[10, 11, 12]. Whilethereisnotechnicalinformation about

theseproducts,theyapparentlyconsistofaWebcachethat

isbundledwithamediaplayer. Therearenumerousworks

onproxycachingmechanismforWebobjects(e.g.,[13,14]).

However,duetothelargersizeofmultimediastreamscom-

paredtoWebobjectsandstreamingnatureofdelivery,ex-

istingproxycachingschemesseemtobeineÆcientformul-

timediastreams. TheMiddleManarchitecture[15]isacol-

lectionofcooperativeproxyserversthatcollectivelyactasa

videocacheforawell-provisionedlocalnetwork(e.g. Lan).

0 5 10 15 20 0

1 2 3 4 5 6

Stream popularity rank

Average number of cached layers

Figure10: Cachedstreamqualityasfunctionofpop-

ularity

canbereplacedatagranularity ofablock. Theyexamine

performance of the MiddleMan architecture withdierent

replacementpolicies.

A class of caching mechanisms for multimedia streams

proposedtocacheonlyselectedportionsofmultimediastreams

toimprovedeliveredquality. Clearly,thesesolutionsdonot

decreasetheloadontheserver(orthenetwork).Tosmooth

outtheplaybackofvariablebitratevideostreams,workin

[16]proposesatechniquecalled Videostaging. Theideais

to prefetch and store selected portion of video streams in

aproxytoreduceburstinessofthestreamduringtheplay-

back. Senetal. [17]alsopresentaprexcachingmechanism

to reduce startup latency. Workin [18] suggests caching

only selective frames of a media stream based onthe en-

codingpropertiesofthevideoandclientbuersizeinorder

toimproverobustnessagainstnetworkcongestion. Workin

[19]presentsacachingarchitectureformultimediastreams,

calledSOCCER.SOCCERconsistsofaself-organizingand

cooperative groupofproxies. Workin[20] describesdesign

and implementation issues of a single proxy in the SOC-

CERarchitecturethat implementsLRU replacement algo-

rithm. Theyfocus mostly onissues suchas segmentation

of multimediastreams and request aggregation. Work in

[21]studiesthelayeredvideocachingproblemusinganan-

alyticalrevenuemodelbasedonastochasticknapsack. The

authorsalsodevelopseveralheuristicstodecidewhichlayers

ofwhichstreamsshouldbestoredinthecachetomaximize

theaccruedrevenue.

Inthecontextofmediaservers,variouscachingstrategies

ofmultimediastreamsin mainmemoryhave beenstudied

inpriorwork[22,23]. Theidea is toreduce diskaccess by

groupingrequestsandretrievingasinglestreamtoservethe

entiregroup. Tewarietal. [24] present adisk-basedcache

replacement algorithm for heterogeneous datatype, called

ResourceBasedCaching(RBC).RBCconsiderstheimpact

ofresourcerequirementofeachstream(i.e.,bandwidthand

space)oncachereplacementalgorithmstomaximize. Work

in[25]furtherexamined theRBCalgorithmandpresented

ahybridLFU/intervalcachingstrategy.

Most of the previous work in this class treat multime-

dia streams similar to Web objects (i.e., perform atomic

mediaproxycaching. Morespecically,Mochacontributes

theideaofqualityadaptivecaching.

6. CONCLUSIONS AND FUTURE WORK

This paperdescribed the design and implementation of

a quality adaptive multimedia proxy cache, called Mocha.

Wejustiedtheneedforqualityadaptivecachingofmulti-

media streams over the Internet and argued that layered

encoding presents the most eÆcient approach to quality

adaptive caching of multimediastreams. Mocha performs

ne-grained prefetching mechanism and uses ne-grained

replacement mechanism to maximize both delivered qual-

itystorageeÆciencysimultaneously.WepresentedMocha's

architectureand keycomponentsofourprototypedimple-

mentation on top of Squid. Ourpreliminary results show

that Mocha can properly adapt the quality of a cached

streambased onitspopularity and onthe availableband-

width between the proxy and interested clients. We also

observedthatLFU-basedreplacementalgorithmsaresensi-

tivetotemporaldistributionofrequests.

Weplan to continuethis workin acouple ofdirections.

First,wearedeninganewevaluationmethodologyformul-

timedia caches. Thenotion ofdeliveredquality for cached

streamsrevealsthattraditionalperformanceevaluationmet-

rics(e.g., Bytehitratio)for Webcachingare neitherwell-

dened nor suÆcient for evaluation of multimedia proxy

caching mechanisms. Instead, performance evaluation of

multimediacachingmechanismsshouldbeexamined along

twodimensions1)overallqualityof deliveredstreams, and

2) ability of the cache inreducing the oered load to the

network.

Second, we use this evaluation methodology to conduct

exhaustive performance evaluation of ne-grained replace-

ment and ne-grainedprefetching mechanismsundermore

realisticworkloadandbackgroundnetworktraÆc. Wealso

needtoexaminesensitivityofne-grainedreplacementand

ne-grainedprefetchingmechanismsto theirmainparame-

ters. Wealsoplantocompareperformanceofourproposed

replacement algorithm withother proposed algorithmsfor

multimediacachesintheliterature. Weplantoexplorethe

eectivenessofo-lineprefetching.

Finally,weplantoincorporateutility(i.e.,importanceon

perceived quality) of individual layers in replacement and

prefetching mechanisms. Our current approach assumesa

linearutility functionwhere all layers resultinsimilarim-

provement inperceived quality. However, most of the ex-

isting layered encoded streams exhibita non-linear utility

(e.g., PSNR)behavior acrossdierentlayers. Thereplace-

mentandprefetchingmechanismshouldconsiderbothpop-

ularityandutilityofalayerinordertominimizetheloadon

thenetworkwhilemaximizingtheoveralldeliveredquality.

7. REFERENCES

[1] R.Rejaie,H.Yu,M.Handley,andD.Estrin,

\Multimediaproxycachingmechanismforquality

adaptivestreamingapplicationsintheinternet,"in

ProceedingsoftheIEEE INFOCOM,Tel-Aviv,Isreal,

Mar.2000.

[2] \Squidwebproxycache,"

http://www.squid-cache.org/.

[3] R.Rejaie,\Anend-to-endarchitectureforquality

SC/CS-TechReport-99-718,Dec.1999.

[4] H.Schulzrinne,A.Rao,andR.Lanphier,\RFC2326:

Realtimestreamingprotocol(RTSP),"Apr.1998.

[5] R.Rejaie,M.Handley,andD.Estrin,\RAP:An

end-to-endrate-basedcongestioncontrolmechanism

forrealtimestreamsintheInternet,"inProc.IEEE

Infocom,NewYork,NY.,Mar.1999.

[6] R.Rejaie,M.Handley,andD.Estrin,\Quality

adaptationforcongestioncontrolledplaybackvideo

overtheInternet,"inProceedingsoftheACM

SIGCOMM,Cambridge,MA.,Sept.1999.

[7] H.Schulzrinne,S.Casner,R.Frederick,and

V.Jacobson,\RFC1889: RTP:Atransportprotocol

forreal-timeapplications,"Jan.1996.

[8] S.Ghandeharizadeh,R.Zimmermann,W.Shi,

R.Rejaie,D.Ierardi,andT.Li,\Mitra: Acontinuous

mediaserver,"MultimediaToolsandApplications

journal,vol.5,no.1,July1997.

[9] A.Silberschatz,J.Peterson,andP.Galvin,Eds.,

OperatingSystem Concepts,AddisonWesley,1992.

[10] InktomiInc.,\Streamingmediacachingbrief,"1998.

[11] \InfolibriaMediaMall,"1999,

http://www.infolibria.com.

[12] \RealSystemProxy,"http://www.realnetworks.com/.

[13] P.CaoandS.Irani,\Cost-aware WWWproxy

cachingalgorithms," inProceedings oftheUSENIX

SymposiumonInternet Technologies andSystems,

Dec.1997,pp.193{206.

[14] S.Williams,M.Abrams,C.R.Standridge,

G.Abdulla,andE.A.Fox,\Removalpoliciesin

networkcachesforworld-widewebdocuments,"in

Proceedings oftheACMSIGCOMM,Stanford,CA.,

1996,pp.293{305.

[15] S.AcharyaandB.C.Smith,\Middleman: Avideo

cachingproxyserver,"inWorkshoponNetworkand

OperatingSystem Support forDigitalAudioand

Video,June2000.

[16] Y.Wang,Z.-L.Zhang,D.Du,andD.Su,\Anetwork

consciousapproachtoend-to-endvideodeliveryover

wideareanetworksusing proxyservers,"in

Proceedings oftheIEEEINFOCOM,Apr.1998.

[17] S.Sen,J.Rexford,andD.Towsley,\Proxyprex

cachingfor multimediastreams,"inProceedings ofthe

IEEEINFOCOM,1999.

[18] Z.MiaoandA.Ortega,\Proxycachingfor eÆcient

videoservicesovertheinternet,"in9thInternational

PacketVideoWorkshop(PVW'99),NewYork,Apr.

1999.

[19] M.Hofmann,E.Ng,K.Gue,S.Paul,andH.Zhang,

\Cachingtechniquesforstreamingmultimediaover

theinternet,"Tech.Rep.,BellLaboratories,Apr.

1999.

[20] E.Bommaiah,K.Guo,M. Hofmann,andS.Paul,

\Designandimplementationofacachingsystemfor

streamingmediaovertheInternet,"inIEEEReal

TimeTechnologyandApplicationsSymposium,June

2000.

[21] J.Kangasharju,F.Hartanto,M.Reisslein,andK.W.

Ross,\Distributing layeredencodedvideothrough

caches,"inProceedingsof IEEEInfocom,Anchorage,

[22] A.DanandD.Sitaram,\Multimediacaching

strategiesforheterogeneousapplicationandserver

environments,"inMultimedia ToolsandApplications,

1997,vol. 4,pp.279{312.

[23] M. Kamath,K.Ramamritham,andD.Towsley,

\Continuousmediasharinginmultimediadatabase

systems," inProceedingsof the4thInternational

Conference onDatabaseSystemsforAdvanced

Applications,Apr.1995.

[24] R.Tewari,H.Vin,A.Dan,andD.Sitaram,\Resource

basedcachingfor webservers,"inProceedings of

SPIE/ACMConference onMultimediaComputing

andNetworking, SanJose,CA.,1998.

[25] J.M.Almeida,D.L.Eager,andM.K.Vernon,\A

hybridcachingstrategyforstreamingmediales,"in

ProceedingsMultimedia ComputingandNetworking,

SanJose,CA.,Jan.2001.