Peer Assisted Video Streaming With Supply-Demand-Based Cache Optimization

494 IEEE TRANSACTIONS ON MULTIMEDIA, VOL. 11, NO. 3, APRIL 2009

Peer Assisted Video Streaming WithSupply-Demand-Based Cache Optimization

Ulas C. Kozat, Member, IEEE, Öztan Harmancı, Member, IEEE, Sandeep Kanumuri, Member, IEEE,Mehmet Umut Demircin, Member, IEEE, and M. Reha Civanlar, Fellow, IEEE

Abstract—In this paper, we consider a hybrid P2P video on-de-mand architecture that utilizes both the server and the peer re-sources for efficient transmission of popular videos. In our systemarchitecture, each peer dedicates some cache space to store a par-ticular segment of a video file as well as some of its upload band-width to serve the cached segment to other peers. Peers join thesystem and issue a streaming request to a control server. Controlserver directs the peers to streaming servers or to other peers whohave the desired video segments. Control server also decides whichpeer should cache which video segment. Our main contribution inthis paper is to determine the proper caching strategies at peerssuch that we minimize the average load on the streaming servers.

To minimize the server load, we pose the caching problemas a supply-demand-based utility optimization problem. By ex-ploiting the inherent structure of a typical on-demand streamingapplication as well as the availability of a global view on thecurrent supply-demand at the control server, we demonstratehow the system performance can be significantly improved overthe brute-force caching decisions. In our analysis, we mainlyconsider three caching mechanisms. In the first mechanism (cacheprefetching), a segment is prefetched to a given peer for cachingpurposes upon peer’s arrival to the system regardless of whetherthat segment is currently demanded by that peer or not. In thesecond mechanism (opportunistic cache update), a peer has theoption of replacing the segment that is currently in its cache withthe last segment that it finished streaming. In the third mecha-nism, we combine both mechanisms as a hybrid caching strategy.In particular, we find that a dynamic-programming (DP)-basedutility maximization solution using only the cache update methodperforms significantly better in reducing the server load. Fur-thermore, our findings suggest that even less sophisticated cacheupdate solutions can perform almost as good as prefetchingstrategies in interesting regions of operation.

Index Terms—Cache optimization, content distribution net-works (CDN), peer-to-peer (P2P), streaming, supply-demand,video-on-demand (VoD).

I. INTRODUCTION

P EER-TO-PEER (P2P) streaming has gained significant at-tention in recent years and there are already on-demand as

well as live streaming applications deployed over the current In-ternet using broadband connections [1]–[9]. The main promiseof the P2P solutions is that they provide cheaper and more scal-able content distribution services. However, pure P2P streamingsolutions are also more fragile due to the churn and relatively

Manuscript received May 09, 2008; revised October 08, 2008. First publishedFebruary 13, 2009; current version published March 18, 2009. The associate ed-itor coordinating the review of this manuscript and approving it for publicationwas Prof. Thinh Nguyen.

The authors are with the DoCoMo USA Labs, Palo Alto, CA 94304(e-mail:[email protected]; [email protected]; [email protected]; [email protected]; [email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TMM.2009.2012918

frequent node failures. They also suffer from connection set-updelays. More recently, hybrid P2P architectures are proposedwhere content distribution networks (CDN) and P2P techniquesare brought together to take advantage of the individual benefitsof each solution (i.e., to combine the system stability/reliabilityand quality of service (QoS) advantages of CDN with the costand service scalability advantages of P2P) [10], [11].

In this paper, similar to [10] and [11], we also consider ahybrid P2P architecture for video-on-demand (VoD) streamingthat utilizes both media server and peer resources for videodistribution. In our architecture, each video file served by thesystem is divided into separate segments. Peers join and main-tain a streaming session through a central control server. Eachpeer dedicates some local cache and upload bandwidth in orderto serve a particular segment to other peers. Peers issue theirrequests for the segments they demand to the control server.Therefore, control server is fully aware of peer population, eachpeer’s individual demand, and progress of the streaming oper-ation. Based on this information, control server determines andenforces a caching policy that dictates which peer is to cachewhich video segment at what time intervals. Thus, control serveralso knows the current overall P2P service capacity (i.e., P2Psupply) for each segment. Upon receiving a peer request, con-trol server finds a list of locations where that peer can downloadthe requested segment. When there is enough available P2P ser-vice capacity for the requested segment, these locations are pri-marily the peers currently caching the requested segment. Anycapacity deficit for a segment (i.e., negative supply-demand dif-ference) on P2P side is supplemented by media servers.

Unlike the caching policies that use heuristic approaches suchas caching and serving the last played segment [7], [12], theinitial segments [13], the rarest segment [14], the most popularsegment [15], or random, statistical, and round-robin cachingby prefetching future data [16]–[18], in this paper, we proposecaching policies based on a utility function that try to mini-mize the overall server load at each caching decision by usingthe current prediction on future supply-demand deficit of eachvideo segment. In contrast to non-real time content delivery,video streaming has to conform with certain QoS objectivessuch as low playback delays and minimal pauses during thestreaming. For this reason, Bittorrent-like [19] random deliveryof different segments of the video stream is not a reasonableoperation and in many video streaming solutions, peers streamin a very structured/deterministic fashion: peers start receivingthe stream from the first video segment toward the last one.1For long enough video streams that consist of many segments,it becomes possible to accurately estimate the future demand of

1Our model also captures the case where peers start watching from an arbi-trary segment.

1520-9210/$25.00 © 2009 IEEE

KOZAT et al.: PEER ASSISTED VIDEO STREAMING WITH SUPPLY-DEMAND-BASED CACHE OPTIMIZATION 495

such peers who are already in the system by using the peers’ cur-rent demand and average download rate. Notice that there mightbe random fluctuations in demand due to many factors such asrandom arrivals and random departures of peers in the future,fluctuations in the streaming rate, random segment skips (e.g.,if fast forwarding is allowed), etc. However, when the video islong enough, the network is mostly stable, and most peers areconforming to the normal streaming operation, we have a goodestimate of the overall future demand. Accordingly, we can min-imize the average load on the servers by properly arbitrating thecaching decisions at each peer and matching the supply of eachsegment to its demand inside the P2P network. To this end, weformulate various utility maximization problems with differentconstraints on the caching decisions. Each constraint representsa different trade-off between pre-roll delay/bandwidth, commu-nication overhead, computational complexity, and performance.We define the utility of a caching decision in terms of the max-imum reduction it induces on the overall supply-demand deficit(or equivalently on the overall server load, since the deficit ispatched by media servers) within a given time horizon.

In the utility maximization problem, we investigate mainlythree caching strategies. The first caching strategy prefetches asegment to a given peer upon its arrival to the system regard-less of whether that peer currently demands the same segmentor not. The peer caches and serves this prefetched segment untilit departs from the system. The second caching strategy makesopportunistic cache update decisions, where peers are allowedto discard the currently cached segment and instead cache andserve the most recent segment they just finished downloadingfor playback. We further consider two different cases within thisstrategy: 1) We take into account future caching opportunitiesthat arises during the normal course of the streaming process(referred to as DP, since it can be formulated as a dynamic pro-gramming problem). 2) We assume that no other caching oppor-tunities will be available later (referred to as static optimal—SOapproach).2 The third caching strategy is a hybrid scheme thatprefetches a segment to a peer upon its arrival, but also allowsfor opportunistic cache update using the newly downloaded seg-ments.

Our main findings suggest that dynamic programming (DP)approach performs significantly better than the other investi-gated methods in minimizing the server load. It turns out thatsimple heuristics such as always caching the most recent seg-ment and caching randomly are far from being optimal. We alsoobserve that prefetching alone does not perform better than ahybrid strategy that opportunistically overwrites the prefetchedcache. Quite interestingly, we further find out that purely op-portunistic strategies, which are suboptimal but computationallymore efficient with respect to the DP approach, perform verycomparable with the prefetching-based solutions over the inter-esting region of operation.

The rest of the paper is organized as follows. In Section II,we present the details of our system model and assumptions. InSection III, we introduce the constraints on the caching poli-cies and formally define our utility optimization problem. InSection IV, we present our simulation results and main findings.In Section V, we discuss possible extensions and improvements

2As it will be clear later on, SO approach is itself a limited search in the setof feasible caching decisions and DP approach exhausts all the feasible cachingdecisions (which, as we will show, can be done in polynomial time).

Fig. 1. High level view of system architecture and streaming operations.

over the current work. In Section VI, we provide a more detailedoverview of related works in the context of cache optimization.Finally, we conclude in Section VII.

II. SYSTEM MODEL AND ASSUMPTIONS

The streaming architecture considered in this paper consistsof control servers, media servers, and peers who demand videocontent. Our system model targets VoD streaming with peersthat consume a particular video file in an asynchronous fashionby arriving into the system and demanding the video at arbitrarytimes. Fig. 1 depicts the high level view of a typical streamingservice over this hybrid P2P architecture.

We assume that each video file is divided into consec-utive segments. Without loss of generality, media servers areassumed to have all segments of a given file. On the otherhand, peers dedicate only a cache space of one segment longto serve other peers. Thus, they can cache and serve one seg-ment at any given time.3 The rationale behind this assumptionis as follows. Firstly, requiring peers commit a very large cachememory would degrade the other concurrent tasks their oper-ating systems have to handle. Ideally, P2P application shouldhave minimal impact on other applications running on the samedevice. Secondly, peers can have quite heterogeneous resourcesand designing/optimizing a system over the whole space is adaunting task. Constraining the peers to cache a single segmentmakes the optimization problem tractable, while still allowingfor substantial performance gains. Finally, single segment con-straint adds further protection against DRM concerns. Nonethe-less, segment size (and so the cache size) is assumed to be largeenough to sustain a smooth streaming operation by averagingout the time variations and burstiness in the upload and down-load rates.

In addition to the cache space, each peer also commits part ofits upload capacity to serve the cached segment to other peers.We refer to this committed bandwidth as upload bandwidth orupload rate throughout the paper and differentiate it from theactual upload link capacity.

In our model, only a single control server is needed to servea single VoD session. Further scalability can be achieved byadding more control servers, each serving different video files.In our setting, we also constrain peers to cache and serve onlythe video session they are participating in. Therefore, we prevent

3We can relax this assumption under some mild conditions on the rate allo-cation. See Section V for more detailed discussion on this subject.


any bandwidth waste due to downloading segments from unde-sired videos. Keeping these in mind, for the rest of the paper, weconcentrate on one video file only; it should be noted howeverthat the extension to multiple video files is straightforward fromthe discussion above. Accordingly, each peer sends its requestfor the desired segment of the video to the control server that isin charge of this video file (e.g., peer Q in Fig. 1). Control serverresponds back with a set of locations from where the peer canstart streaming the segment. As long as there exists spare ca-pacity among the peers who currently cache the requested seg-ment (i.e., P2P supply), control server provides a supply list thatconsists of a subset of these peers and individual streaming ratesfrom each peer in the list. The sum of these individual streamingrates can be less than or equal to the streaming rate of the seg-ment. Whenever there is not enough P2P supply to match thestreaming rate, the lacking supply/capacity is provided from themedia servers. For instance, in Fig. 1, segment is not cachedanywhere, thus peers A and X stream from the media servers.Control server always provides one or more media servers in ad-dition to the supplying peer list. When a peer in the supply listprematurely departs during the streaming operation, receivingpeer contacts one of the media servers to replace the departingpeer. Again referring to Fig. 1, if peer A leaves, than peer B goesto one of the provided media servers to stream the rest of .

As it will be explicit in the problem formulation sections, weconsider only the edges (i.e., the links that connect the peers tothe network) as bottleneck links. In terms of link capacities, thisis indeed typical of both wired and wireless networks. More-over, the peers themselves commit upload bandwidths strictlyless than the uplink capacity further exacerbating the bottleneckconditions. The receiving peers monitor the download rate fromeach uploading peer and report the qualities to the control serverwhen sending request for the next segment. Based on these re-ports and segment request times, the control server can keeptrack of the actual upload and download rates of each peer andtake the deviations from the committed upload/download ratesinto account.

A. Obtaining Demand and Supply Curves

Our goal in this paper is to minimize the average bandwidthusage from the media servers. This objective increases the ser-vice scalability of the system and reduces the operational costs.Since the servers are used only when the peer demand for a seg-ment exceeds the peer supply of the same segment, this objec-tive is equivalent to maximally utilizing the peer resources bymatching the peer supply to the peer demand. To be precise, de-mand for a particular segment at time is the sum of streamingrates of all peers downloading at time . Similarly, peer supplyof the same segment at time is the sum of the committed up-load rates from all peers who are caching segment at time .

For the sake of clarity, we assume that peers download eachsegment at the same rate , which is also set to be equal to theplayback rate . The actual download capacity of peer (de-noted as ) must then be larger than or equal to . We alsodenote the upload bandwidth peer commits to the system as

. The upload rate can be smaller or larger than the streamingrate. In a typical video on-demand streaming operation, a newlyjoined peer starts streaming from the first segment. Once the

Fig. 2. Evolution of demand curve over time for each user depends on the userarrival time and the streaming rate. At a given time �, one can determine theoverall demand for each segment.

peer receives the whole segment, it continues streaming with thenext segment until the end of video content. Therefore, giventhe peer’s arrival time into the system and the streaming rate,the control server can identify how the demand for a particularsegment evolves for typical users. Fig. 2 depicts the situationfor arbitrary arrival times with . To further simplify theamount of bookkeeping and the notation in the problem formu-lation, we consider a discrete-time system, where the time unitis equal to the duration of time it takes to download a wholesegment (i.e., one epoch). In the discrete model, peers join thesystem at the beginning of each time epoch. It is important toemphasize here that it is straightforward to define the supply-de-mand formulation in continuous-time as well (see Section V forfurther discussion).4

We denote the demand for segment at time epoch as. The demand can be further decoupled into 1) a de-

terministic and 2) a stochastic component. The deterministicportion [denoted as ] captures the typical operationand assumes peers stream continuously with no interruptionsuntil the end of the video content. Notice that in a typical opera-tion, when a peer is interested in segment in time epoch

, it will finish receiving at the end of time epochand will demand the next segment in the next time

epoch . Therefore, we can express in a recursivefashion as

with initial conditions

where is the current time epoch and is the demand during. The stochastic portion [denoted as ] on the other

hand captures any unexpected fluctuations in demand due tofuture node arrivals, early node departures, any interruptions in

4Another critical point is that playback delay is not coupled in our formula-tion with the completion of the initial segment download. Each peer can locallydecide during the download of the initial segment when to start playing backdepending on the current buffer occupancy and the regularity of the downloadrate. This decision is orthogonal to the problem considered here.


the streaming operation, etc. Accordingly, we can express thetotal average demand for segment during time epoch as

(1)

and , since the control server is assumedto perfectly keep track of the current demand.

Unlike demand, our system has control over the video supplyfrom peers (simply referred to as supply hereon). The currentsupply of segment is completely determined by thetotal upload bandwidth of the peers that have cached the thsegment. We will assume that a peer can start serving a seg-ment if and only if it already cached that whole segment. Inthe supply computation, we also assume that peers depart thesystem as soon as they complete receiving the whole video.Formally, if denotes the set of peers who have alreadycached segment before time epoch starts and who are still inthe system during , then the supply can be written as

. Although we assume control over the segmentcached at each peer in each time epoch, we have to consideradditional system constraints to figure out the feasibility of apeer caching a particular segment at the desired time epoch.We postpone the details of the system constraints consideredin this work until Section III. It is also noteworthy to state herethat even if a caching decision is executable, peers might leavethe system prematurely or the streaming operation can be in-terrupted. Similar to the demand curve, such practical eventswould cause random fluctuations in the supply curve. Thus, thesystem should implement a good enough signaling protocol formonitoring the system state, reassess the future demand, and re-calculate the supply decisions. In the rest of the paper, we willassume that such a mechanism is in place and that the controlserver has perfect knowledge of the current demand and supply.Further, we assume that the peers can reach other peers and startstreaming from them at a given bandwidth in a seamless fashion.Nevertheless, the system can be trivially modified to take theconnection setup delays and imperfections into account as de-scribed later in the discussion section.

III. CACHING TECHNIQUES AND SUPPLY-DEMAND-BASED

UTILITY OPTIMIZATION

In this section, we describe the three main mechanisms thatwe consider for supply-demand-based utility optimization. Asalready mentioned in the previous section, the feasibility of acaching decision depends on additional system constraints. Inwhat follows, we also present the details of different constraintsthat are dictated by the introduced mechanisms.

A. Cache Prefetching

In cache prefetching, regardless of which segment a givenpeer is streaming, the system can prefetch any segment of thevideo to the peer for caching purposes. The prefetching of asegment can be done from other peers or media servers. Al-though one can design a system where prefetching is allowedat any time during the lifetime of a peer in the system, in prac-tice such a system is harder to manage and may result in a

heavy-weight system where prefetching traffic might incur sig-nificant load on the system. To avoid such complications, weconsider prefetching only when a new peer joins the system andsends a request to download the first segment of a video file. Thesystem first prefetches a segment to the new peer, and then thepeer proceeds with the streaming operation from the first seg-ment. This incurs additional playback delay, equal to one epoch.If cache prefetching is used alone, each peer keeps and servesthe prefetched segment in its cache until it departs the system.

The main question in cache prefetching is which segmentamong the segments should be prefetched to a newcomer.The simplest strategy is to prefetch segments in a round-robinfashion, i.e., the first incoming peer caches the first segment,the second incoming peer caches the second segment, and soon. After the last segment is prefetched, system restarts cachingfrom the first segment. Round-robin prefetching thereforeevenly distributes the segments onto peer caches. Anotherstrategy is to use prefetching in order to randomize the segmentdistribution according to a steady-state distribution, which canmodel the demand. However, the streaming operation is highlystructured and whenever the deterministic portion is dominant,we can more intelligently control the supply by mainly relyingon this dominant term.

Suppose peer joins the system before time epoch . Then,a segment is prefetched first during time epoch , afterwhich the peer starts streaming during and at the sametime starts serving .5 We define the utility of serving

over a time horizon of ( here can vary between 1 and, since peer will depart after finishing streaming all seg-

ments) epochs as

(2)

where and are the demand and supply estimates, respec-tively. is an operator defined as

.

Notice that the term in the summation captures how much ser-vice capacity of peer can be actually utilized at any time in-terval. If the demand is below the P2P supply for segment attime epoch , prefetching will not reduce the load of mediaservers. If the demand is above the P2P supply, but below theupload bandwidth of then only the lacking supply is goingto be served by and hence ’s utility becomes

. If the supply deficiency at any epoch is above the up-load bandwidth of , then can add to the P2P service capacity(or supply) by at most .

Prefetching adds a streaming delay of one segment downloadtime, but has the advantage of caching any segment on the newpeers in an out of order fashion. Specifically, we select suchthat and . We can fur-ther optimize the utility with respect to time horizon . Asincreases, our estimates on supply and demand potentially mayget worse. Thus, in the performance evaluation section we pay

5In the paper, unless otherwise specified, we reserve � to refer to �th epochafter the current epoch � .


special attention to the sensitivity of different caching strategieson when we use (2) [and (3) as defined later] in the process.

For estimating , we have several options available de-pending on how much we know about the statistics of ar-rival and departure rates, as well as the other imperfectionsin the system. In a completely blind estimation, we pick

, which can be recursively computed aspresented in the previous section using the initial conditions

. In cases where we know the average arrivalrate into the system in each epoch, we can also use this rateto model the stochastic term partially. In other words, we canset the stochastic portion of the demand

and

Accordingly, we can useas our demand estimate instead. If we know the distribution ofthe arrival process and we also fix the supply estimate, a betterapproach is to compute the expected value of the utility, i.e.,

, and pick the segment that maximizes this utility.This however might be overly expensive and intractable forlarge values. The nonlinearity of utility function also addsonto the complexity. Note however, if we can approximate theutility function as a linear function of ,optimizing becomes equivalent to replacing thedemand with its expected value as we do above.6

For estimating in a prefetching scenario, we assume that allthe existing users in the system keep supplying the same seg-ment in the time horizon for which (2) is computed for newlyjoined peer . In cases where , we account for the userswho leave the system within the time-horizon due to the com-pletion of their streaming operations. In other words, a departedpeer’s contribution to the supply curve for its cached segmentis removed for the time intervals that occur after the departureevent. In cases where is captured by the average arrival rate,we compute as if no one departed from the system. Thesenuances are necessary to keep the average number of suppliersand the demanders in the system to be the same for unbiasedsupply-demand estimation.

B. Opportunistic Cache Update

Different than cache prefetching, in this method, we uti-lize the caching opportunities that arise during the normalstreaming operation. By doing so, we also avoid additional de-lays that would be caused by the prefetching duration in cacheprefetching. To be more specific, whenever peer completelyreceives segment , it has the option of keeping the segmentalready in its cache (say , which can be any of the segmentsdownloaded earlier), or replacing the current segment in the

6To see this, suppose �� . Then,��

� � �� , where in the second term�� for � � �, �� , and �� , when there are no random departures.

cache with (i.e., make until the next decision point).Accordingly, we can make caching decisions for each userafter the complete download of each segment. Going back toour example in Fig. 1, in the time epoch shown in the figure,peer A has in its cache and is currently downloading .When is downloaded, A has to know whether it shouldkeep and continue serving or replace it with . The controlserver signals that decision ahead of time to A using the mostrecent supply and demand estimates. In case of peer B, after itcompletes the streaming of , since there is no other segmentin its cache, the decision is trivial and B caches to serve otherpeers in the later epochs. When a peer just enters the system,its cache is assumed to be empty in our setting.7

Similar to the cache prefetching case, our objective is to op-timize the utility of caching decisions over a time-horizon of

epochs. Different than prefetching scenario, however, we donot need to cache the same segment in all epochs. Instead, wecan express the utility optimization over a sequence or path ofcaching decisions of length . Suppose peer has in its cacheand downloading segment during current time epoch . Wedefine a caching path of length as a sequence of cached seg-ments starting with what is cached at and ending with whatis cached at .

Fig. 3 shows feasible caching decisions for . Notice thaton the trellis not all the paths are feasible. For example, at point

, if the peer decides not to cache which is to be down-loaded by the end of , peer will not have the opportunity tocache later on. We show the eligible transitions by verticalarrows with feasible starting points as black dots. Indeed, oncewe enumerate all the feasible paths of length , we can see thatthere are , i.e., exponential number of, feasible paths. To seethat, it suffices to observe that at every decision point (i.e., atthe end of fully downloading the next video segment) we havetwo choices: either we keep the same cache or we overwrite itwith what we just downloaded. For instance, in Fig. 3, at theend of time epoch for a time horizon of 1, we have two op-tions/paths available: or . For time-horizon of , onthe other hand, we have 16 feasible paths, all of which are enu-merated on the right hand side of Fig. 3. To clarify notation, the4-tuple sequences show what can be potentially cached at timeepochs through with the leftmost value showing the seg-ment cached at .

To formally state the optimization problem, we denote theset of all feasible caching paths of length as , and thesegment index set defines a caching path

in . Then the utility of correspondingto caching segments is given by

(3)

Whenever a peer is about to complete downloading a segment,the control server recomputes the optimum caching path

for the peer where is the minimumof system parameter and the remaining lifetime of the peer in

7It is possible to have interruptions in the streaming and when a peer tries toreconnect, it might indeed have a segment in its cache and demanding a segmentin the middle of the video stream. Once a peer rejoins, it is straight forward tomodify the supply and demand estimates at the control server during the recon-nection cycle.


Fig. 3. In opportunistic cache update, the caching decisions are constrained bythe streaming operation. The figure depicts all possible decision paths that canoccur in the next four time epochs when the system is in time epoch � andcaching � .

the system. If the caching decision results in a change with re-spect to the previously computed path, then the peer is informedabout the new caching path.

Although the number of all feasible paths is of exponen-tial complexity in , we can solve the utility optimizationproblem in polynomial time using DP. To see why the problemat hand is a DP problem, observe that the optimum path

among all the paths in which cross anintermediate point can be divided into two subpaths: paththat starts with and ends with and path that starts with

and ends up with . Since the utility function is additive,then itself must be the optimum path among all the pathsthat end with and itself also must be the optimum pathamong all the paths that start with . Otherwise, it is trivial toprove that is not optimum. Again referring to Fig. 3, at timeepoch , the peer can be caching one ofdistinct segments (specifically any of the segments in the set

). At the end of , the peer can continuecaching the same segment (corresponding to distinctpaths) or can make a transition to . Note that there arepossible transitions to and only one of them is optimum.Hence, at each step only one path survives among the ones whoend up at . Therefore, at each step we need to checksubpaths. After we complete downloading and reachat epoch , we have surviving paths among which weneed to find the one that maximizes (3). If we count the overallnumber of subpaths and the final surviving paths, we have apath complexity of

as opposed to the exponential complexity of the exhaustivesearch in the feasible set. We refer to this opportunistic cacheupdate mechanism that looks for the optimum path of lengthas the DP solution.

Although we have a quadratic-time polynomial solution tofind the optimum path in the sense of (3), it might be still timeconsuming for large values and with many users in the system.As a simpler mechanism, we also look at the case when theutility is computed as if the caching is static and the peer isgoing to serve the same cache until the end of time-horizon orits lifetime, whichever comes first. Hence, we limit our searchto the two paths: (i.e., we keepcaching what we have been caching in the last time epoch)and (i.e., we replace the cur-rent cache with the just downloaded segment and cache/servefor the next steps). This method is referred to as static op-timal (SO) solution. The rationale behind limiting SO to thesetwo paths but not others is simple: we already have andavailable at the peer by the end of the current epoch while theother segments are to be received yet. This allows us to con-trast two approaches, one taking future caching opportunitiesinto account (i.e., DP) and the other oblivious to these futureopportunities (i.e., SO), against each other.

Estimations of and are done in the same fashion as cacheprefetching. The only difference is that in DP, the supply esti-mate is time-varying. This is due to the fact that although thesupply estimate fixes the caching decisions already done forthe other peers as in cache prefetching and in SO, these de-cisions correspond to paths which potentially imposes time-varying caches within the lifetime of the fixed peers.

C. Hybrid Caching

Hybrid caching combines cache prefetching and oppor-tunistic cache update together. Therefore, when a peer firstjoins the system, it prefetches a segment in the first time epoch.In addition, as the peer starts streaming the media it is allowedto compare the utility of the recently completed segment withwhatever is already cached. If the last downloaded segment hasbetter utility over the system specified time-horizon, then thecache is overwritten regardless of whether it is prefetched ornot.

In Section IV, we present a detailed evaluation of all threecaching strategies as well as some other commonly used cachingstrategies under various settings.

IV. PERFORMANCE EVALUATIONS

Our goal in the performance evaluation is to first understandwhether sophisticated techniques based on supply-demand esti-mates really improve the system performance, and if so, underwhat conditions. Secondly, we would like to understand themain trade-offs in optimizing the utility of peer resources.

We have experimented with several caching schemes. Foropportunistic cache update schemes, we have considered oursupply demand-based SO and DP methods. We also looked intosimple non-opportunistic (nonetheless popular in the literature[7], [12]) strategies such as playbacked last time (PL in short)that enforces caching of the last fully downloaded segmentat each peer, random cache update (RND in short), as wellas caching the earliest segment (referred to as FS since thisamounts to always caching the first segment in our experi-ments).8 For prefetching schemes, first, we have considered

8Note that FS uses P2P resources to distribute only the first segment. Whenthere are no early departures, every segment is demanded at the same rate in thelong run, hence the reduction in server load is marginal for large � .


the strategy that optimizes the utility defined in (2). Due tothe fact that the prefetched segment is not overwritten andprefetching logic is similar to the SO method (with differentcaching constraints), we denote the utility-based prefetchingas no change—static optimal . We also consideredround robin and random prefetching techniques, which arereferred to as and in the plot legends,respectively. For hybrid mechanisms, we have mainly investi-gated combination of SO with round robin prefetching and SOprefetching, referred to as and , respectively,in the results. Other possible combinations, which however wedo not include in this paper, are to use DP with RR and SOprefetching.

In all of the simulation results presented in this section, weuse a video of length 60 segments unless otherwise specified.We use the same streaming rate across all peers. We haveexperimented extensively with various upload and downloadratios as well as arrival/departure rates. We have also investi-gated both homogeneous and heterogeneous upload rates. Inthe homogeneous upload rates, all peers are assumed to havethe same upload rate, whereas in the heterogeneous case, eachpeer randomly picks an upload rate in the interval(i.e., ). The time unit in the results is thetime it takes to download one segment and it is constant acrossall users. Unless otherwise specified, we use Poisson arrivalprocesses and users remain in the system until they stream thewhole video file (i.e., all 60 segments). An arrival rate of usersper unit time then corresponds to average number of usersstreaming the same video at the same time. In the simulations,we assumed that when peers join, they start to watch from thebeginning of a video.

In Fig. 4, we plot the average server load (normalized withrespect to the overall load on the system) as a function of thearrival rate. In all the relevant figures, we present the resultsfor the homogeneous upload rates at the top and the results forthe heterogeneous upload rates at the bottom. For this partic-ular result, the average upload bandwidth is set equal to thestreaming rate. We found similar results when we fixed the up-load bandwidth as fractions and multiples of the streaming rate.One can immediately see that DP outperforms the rest of thestrategies at all arrival rates and the gains become more signif-icant at higher arrival rates. As expected, FS brings only mar-ginal benefit to reduce the server load. PL, RND, and

heuristics, on the other hand, perform similar to each otherwith significantly worse results compared to all other strate-gies. We see that the remaining approaches (i.e., ,

, SO, , ) are grouped together.For instance at arrival rate users per unit time and forhomogeneous upload rates, when DP is used, only 10% of theoverall load is served by media servers and the remaining 90%is served by other peers streaming the same media. At the samearrival rate, PL results in 30% load on the servers (i.e., 3-foldmore capacity usage) and rest of the schemes generate around20% load on the servers (i.e., 2-fold more capacity usage). It isworth pointing out that prefetching-only and

as well as the cache update-only SO are outperformed bythe hybrid approaches and . Interestingly,cache update-only SO, which is of very low complexity, out-performed (though marginally) the prefetching-only strategiesexcept for the high arrival rates (e.g., ). The optimum

Fig. 4. Normalized server load as a function of arrival rate � for (a) homoge-neous and (b) heterogeneous upload bandwidths.

cache update-only strategy (i.e., DP) however outperforms boththe hybrid and prefetching-only strategies. We also see that het-erogeneous upload rates (although the average upload rate isthe same) do perform relatively worse than the homogeneouscase. This deterioration is mainly due to the fact that in the ho-mogeneous case the particular setting of upload rates and thestreaming rate do not waste any bandwidth, while when the up-load rates are randomly selected as in the heterogeneous casethere always remains unutilized peer bandwidth. Nevertheless,the relative performances of each scheme are the same as in thehomogeneous case.

Another expected observation from Fig. 4 is that the averageserver load ratio to the overall load does not increase as the ar-rival rate increases since there are more peers in the system in-creasing the P2P supply opportunities and hence the load shareof P2P delivery. To give a sense of how the actual server load isincreasing as the arrival rate increases, we also plot non-normal-ized average server load in Fig. 5. The figure shows a better sep-aration between different schemes and the gains of DP is more


Fig. 5. Non-normalized server load as a function of arrival rate � for (a) ho-mogeneous and (b) heterogeneous upload bandwidths.

pronounced when the server load is measured in terms of theactual number of concurrent sessions that need to be supportedby the servers. We omit the results for FS since its performanceis already established to be inferior.

In the plots for SO, , and , we use atime-horizon of four while DP uses a time-horizon equal tothe peer’s remaining lifetime. These time-horizon choices aredue to the fact that they are almost the optimum parameterselection for each of these strategies. Moreover, we must em-phasize that in the estimation of and , we found marginalperformance differences when we use blind estimation [i.e.,

] versus modeling the stochastic termby the average arrival rate . Unless otherwise specified, weuse blind estimation for DP and we model the stochastic term

for SO. The main reason why we do quite well with blindestimation may be that we perform caching decisions oftenenough (which rectifies any deviation between the estimatesand the actual supply/demand processes) and there is enoughdeterminism in the system so that estimation errors do not accu-mulate over time and drift, if any, is limited. In Fig. 6, we showthe impact of time-horizon and the impact of demand/supplyestimation at and (or for theheterogeneous upload rates). The DP solution starts achievingsignificantly better performance as the time horizon gets longerand then it saturates, even slightly deteriorates. Nevertheless,the maximum time horizon (e.g., the peer lifetime in thesystem) is almost as good as the optimum point. We shouldnote that the optimum points are not fixed and they tend tochange as the system settings such as arrival rates, upload rates,random events, etc. However, why we see a plateau at aroundtime-horizon of 10 and deterioration afterwards is mainly dueto random events (in this case the arrival process) that can bemore easily accounted for by shorter horizon optimization andmore frequent re-optimization. The result also suggests that ifthe complexity of DP is an issue, one can use relativelyshorter time-horizons and yet get closer to the best perfor-mance. The SO scheme however enjoys better performance ataround . We plot SO by using two different estimationmethods as described above and in the previous section. Asseen in the plot, the difference is marginal. This figure clearlyshows that under the same blind estimation, SO leads to asignificantly suboptimal search with respect to the DP solution.The difference between the homogeneous and heterogeneousupload rates are again not in the main trends, but at the nominalvalues. The worse performance of heterogeneous case is asbefore due to the lack of sufficiently large user population toattain enough spatial averaging and under-utilized peer supplywhen it exceeds the demand.

In Fig. 7, for fixed arrival rate , we plot the impact ofupload rate (and mean upload rate in the case of heterogeneousupload rates) on the average server load. Quite intuitively, themore upload rate peers can offer, the less media servers need toprovide. However, upload rate itself is not the only limit on thesupply, but what is cached is also critical. Our evaluations sug-gest that for large enough upload rates and enough number ofactive peers in the system, round robin prefetching becomes thebest strategy under homogeneous rate setting. Indeed it sufficesto have only a few peers caching each segment to match most ofthe demand. In heterogeneous case, becomes the beststrategy at high upload rates. We mainly attribute this to the factthat does not take upload rates into account whereas

does. However, the performance differences are quitemarginal. DP performs the best up to a threshold and then levelsoff. One reason why DP cannot perform as well under a high up-load rate regime is that opportunistic cache update is constrainedin terms of what can be supplied. For instance, no matter howlarge the upload bandwidth is, since the peers are assumed toleave the system as soon as they finish streaming the last seg-ment, the last segment is never cached and it is always suppliedby the media servers. Similarly, out-of-order caching is also notfeasible with opportunistic cache update approaches. Moreover,in these strategies, a peer provides supply for at most timeunits while in prefetching a peer can supply for time units.Quite consistently, PL, RND, schemes become the


Fig. 6. Performance dependence of utility optimization on the length of thetime horizon for (a) homogeneous and (b) heterogeneous upload bandwidths.

worst strategies (ignoring FS), which is an indicator that theseschemes cannot really match the demand distribution nor takeadvantage of the short-term deterministic behaviors at least forPoisson arrival processes. We also observe that randomizationgives a little bit edge over PL under heterogeneous upload rates.

So far, we have considered only homogeneous Poisson ar-rival processes with deterministic service time in the system.Such homogeneous processes lead to quite stable steady statedistributions and provided enough upload bandwidth, a simplestrategy such as round-robin prefetching might work sufficientlywell. However, in practice, we do not have such homogeneousstationary processes all the time, e.g., flash crowds being one ofthe many possible reasons for this. We therefore also define a

Fig. 7. Normalized server load as a function of�� for (a) homogeneousand (b) heterogeneous upload bandwidths at arrival rate � of 1 user per segmentduration.

nonhomogeneous setting that can capture flash-crowd type dis-turbances in the demand curves. In this nonhomogeneous settingwe add two processes. The first process is the Poisson arrivalwith rate as before. The second process occurs every timeunits and lasts for units of time. During the units, peersarrive at a rate , rather than , following another Poissonprocess. In Fig. 8, we show the impact of on the averageserver load when and . We see that DP consis-tently outperforms the other schemes. What is most remarkableis that how prefetching-only strategies suffer substantially in aflash crowd scenario. , , andall deteriorate as increases whereas all the other strategiesameliorate. The performance of PL and RND get better than the


Fig. 8. Performance against the flash crowds for (a) homogeneous and (b) het-erogeneous upload bandwidths.

prefetching-only schemes. PL outperforms RND more signifi-cantly for larger . suffers mainly due to the fact thatit cannot properly estimate the demand stemming from the flashcrowd and there are no mechanisms as in the hybrid and oppor-tunistic cache update approaches to correct the demand/supplyestimations during the streaming operation. looksmore robust than , but the performance is substan-tially worse than the hybrid and opportunistic cache update ap-proaches. is least sensitive to the change in flashcrowd arrival rate, but its performance is also one of the worstones. The main findings are the same for both heterogeneousand homogeneous upload bandwidths.

Fig. 9. Performance dependence on the length of the time horizon for randomdepartures.

Another point we have paid particular attention to is the im-pact of random departures on the normalized server load tosimulate the effect of peers leaving the system early withoutstreaming the entire video. We show our main results in Figs. 9and 10. The number of departures in a given time epoch ismodeled as a Poisson random variable with rate denoting therandom departure rate. The actual departed users are then se-lected in a uniformly random fashion across the users who arealready in the system. It is to be noted that the users/peers whofinished streaming the video would always depart whether theyare selected or not. Different than earlier results, we presentDP with the full time-horizon (i.e., ) as well aswith shorter time horizon of . Random departures areexpected to have more dramatic impact on larger time-horizonsupply-demand predictions than random arrivals. Fig. 9 showsthe dependence on the length of time-horizon of DP and SOfor , (homogeneous peer upload bandwidths),and a relatively a large departure rate . Since randomdepartures in this set-up skew the demand toward earlier seg-ments, SO with blind estimation do not provision as good forsuch a skew than SO that uses arrival rate as an estimate of fu-ture demand which biases optimization also toward earlier seg-ments. The more dramatic impact however is observed on DPwhich bases its optimization on future caching opportunities.As seen in the figure, DP initially improves substantially asincreases since early departures have more limited impact insmaller time horizons, but then performance gets worse aftercrossing a threshold and stabilizes at a substantially worse op-erating point. Having said that, DP continues to outperform SOat each value.

Since time-horizon has more impact on the DP performance,in Fig. 10, we plot DP performance both with full time-horizonand . Note that is not necessarily the optimumpoint of operation, but it looks like a good compromise in ourexperiments when is highly varying between 0 and 0.5. Asseen in Fig. 10, the normalized average server load increases as


Fig. 10. Normalized server load as a function of early random departure rate �for (a) homogeneous and (b) heterogeneous upload bandwidths.

the random departure rate increases for both homogeneous andheterogeneous peer upload bandwidths, which is inline with ourinitial expectation. We observe that DP and are moresensitive than the SO and hybrid strategies. Nonetheless, DP stilloutperforms all other methods over a large range of departurerates. PL, RND, and again falls behind with greatmargins. Our experiments with other combinations of andgenerated consistent results with our observations summarizedhere.

We conducted more experiments to see the relation betweenthe segment size and average server load. In these experiments,we kept the video duration and the number of arrivals per videoduration the same, while changing the number of segments

(in other words the segment size).9 More segmentation meansless cache requirement in general and less playback delay forthe prefetching methods. We also expect that when there arevery few segments, SO and DP do not have much optimizationleverage (e.g., in the extreme when the video file is one seg-ment, there is no optimization). Fig. 11 plots the normalizedserver load as a function of when the average number ofconcurrent users is 60 (at the top) and 600 (at the bottom).Prefetching techniques trivially obtain the best result whenthere is one segment. However, this comes at the expense ofa playback delay that is equal to the whole video duration.More interesting behavior occurs at larger as depicted inthe figures. Except for and , all themethods have minima occurring at sufficiently large M (i.e.,at sufficiently small segment size). The minima points and thecurvatures around them are highly dependent on the averageload on the system. Our overall observation suggests that aslong as the demand per segment (or equivalently per segmentarrival rate) is sufficiently high, more segments lead to betterperformance for opportunistic cache update mechanisms aswell as PL and RND. DP gets the most benefit at relativelylarger M values, but when the per segment arrival rate gets toosmall, its performance also gets impaired.

We summarize our overall findings in Table I on severaldifferent aspects. In the table, the unit for both prefetch delayand download time is given in terms of segment duration. Thecomplexity and signaling overhead are presented as valuesper user and per download. Thus, to find the computationalload and signaling overhead of the control server in terms ofoperations per second and messages per second, they must bescaled by (total number of users)/(video duration in seconds).All the methods considered in the paper substantially takeadvantage of the peer resources. Having said that, we observedthat DP achieved the best improvement under more constrainedscenarios. Unlike prefetching and hybrid methods, DP does notsuffer from prefetching delay incurred on top of the streamingoperation. The complexity is higher than the other strategies,but it is manageable in polynomial time. As far as the quadraticcomputational complexity (in time horizon) is not a problem, itis clearly a better choice than the other prefetching, hybrid, andlow complexity opportunistic cache update solutions. Althoughthe signaling overhead (i.e., the number of control messagessent from the control server to a peer to inform the cachedecisions) is definitely an issue in comparison with prefetchingschemes, the overhead figure of corresponds to theworst case scenario where the caching decision for the peerchanges at every decision instance. Remember that is thenumber of segments. If the video is 60 min long and ,every minute a control message in the order of 100 bytes is sentout to indicate which segment to cache, which is negligible incomparison to the payload traffic.10 If the original path com-puted as the optimum remains the optimum, then one control

9Since in our previous results� was fixed, expressing arrival rate in numberof users per video segment duration versus per video duration did not matter.However, now the segment size is variable and fixing per segment arrival ratewould lead to different loads on the system as � varies. To keep the systemload the same, we fix the arrival rate per video duration.

10Although it takes one bit to represent whether the peer should swap thecache or not, other protocol headers (e.g., transport and IP) as well as extrapiggybacked information in typical system implementations constitute much ofthe message length.


TABLE ISUMMARY COMPARISON OF DIFFERENT CACHING SCHEMES

Fig. 11. Impact of segment size on the server load for homogeneous uploadbandwidths with the arrival rates of (a) 60 users/video-duration and (b) 600users/video-duration.

signal becomes indeed sufficient. Another critical point hereis that most of the control messages (caching messages) andmaintenance messages (e.g., failure notifications, streamingrate reports about sending peers, etc.) can be piggybacked onthe request-respond messages exchanged before each segment

download operation. In terms of complexity and overheads, thebest strategies are PL and RND. However, their performancesare not nearly as close to the other schemes. The prefetchingonly with round-robin strategy seems to have advantages interms of the signaling overhead and computational complexity,but it performs well only under less constrained scenariosand with a naturally matching demand process that evenlydistributes the demand over the segments in the steady state.The hybrid methods performed better than the pure strategiesin many cases, but the gains are also marginal in many of thescenarios as opposed to the gains provided by DP.

V. DISCUSSION

In this paper, we have several simplifying assumptions andit is possible to relax most of them in the problem formula-tion. The major assumption in this paper is to use a discretemodel and a synchronous clock across the peers. Once we knowthe approximate start times and streaming rate of each peer,we can change the summations into integral equations to com-pute the utility of caching a particular segment and we makethe caching decisions ahead of time. The main problems occurwhen we start introducing more practical system constraints intothe picture such as signaling delays as well as variations in thestreaming rate. We expect that methods like round robin or SOprefetching and PL method would not be very much impacteddue to their static nature or supply-demand indifference. For dy-namic caching methods where we observe the most significantreductions in the server load, one needs to take the necessaryprecautions as summarized next.

One way of mitigating the signaling delay and streamingdelay jitter in the system is to choose the segment size muchlarger than the signaling delay and streaming delay jitter inthe system. Even if large round trip time (RTT) delays withmultiple message exchanges are considered, under conservativeconditions the signaling delays and jitters might be in theorder of a second and hundreds of milliseconds, respectively[20], whereas the segment size can be picked in the order ofminutes. Another possibility in a practical system setting isto slightly over-provision the cache space such that there is asoft replacement of the current cache with the new one. Thisbecomes especially beneficial if a peer were in the middle of itsstreaming operation and the sending peer would suddenly stopserving the segment of interest since the cache were replaced.With the soft replacement, the sending peer can continueserving until it receives a streaming request for the new cache.In a similar vein, the peers can request download rates slightlyfaster than the playback rate to compensate for the signalingdelays in handing off to new upload peers and/or media servers.Since the control server knows the approximate time instanceswhere some peers will swap the cache and stop serving theformerly cached segment, it can notify the downloading peer


when responding to the initial segment request ahead of time.Another practice is to explicitly take the signaling delays intoaccount (as we already implicitly do in cache prefetching)and also compute the utility ahead of time by considering thesignaling delays explicitly in the computation.

In our system model, we also have not considered the possi-bility of continuous-time chaining in our supply-demand formu-lation, where a peer can start serving a segment before the seg-ment is fully recovered and the cache is cyclically overwritten asnew bytes are coming in from the same or latter segment. Thisallows peers who join the system within a segment duration toform a chain (i.e., parent node continuously streams to its childfrom its cache and child node keeps the same parent node untilits parent leaves), a great advantage to handle the flash-crowds.Two main problems with chaining are that it is more fragile thanthe pull-based mesh structure we use in our system and it alsoerases the cache boundaries complicating the utility computa-tions. One method of incorporating the continuous chaining inour model is to treat a chain as one node where only the leafof the chain caches as before, contributing to the supply, andonly the head of the chain contributes to the demand. When anyparent node in the chain leaves, the chain partitions into twochains. The immediate child of the departing peer sends a re-quest to the control server adding to the demand in order to con-tinue streaming and serving to the rest of the chain. The parentof the departing node becomes the leaf node of another chainand it joins to the supply computation.

Another assumption we made in our system model is to limitthe cache space to one segment. It is possible to extend ourproblem formulation to multiple segments, where each peer cancache different number of segments, by a priori fixing the rateallocation rules. Suppose peer has enough cache space tostore segments. Then, we can divide the cache space topartitions, each caching a unique segment. We can also dividepeer’s upload capacity into components such that

, where is fixed and allocated to the th partition.Such a partitioning allows us to treat peer as virtual peerseach capable of caching one segment (e.g., ) from its own par-tition (say ) and uploading at rate . When a new segmentis downloaded by peer , it is indeed downloaded by all vir-tual peers. Accordingly, the control server can make a cachingdecision for each virtual peer one by one as if they were sepa-rate physical peers. Note that we allow different virtual peers tocache the same segment simultaneously as a result of the utilityoptimization depending on the supply-demand deficits of eachsegment.

VI. RELATED WORK

There is a lot of previous work on cache optimization incommunication networks mainly in the context of web caching[21]–[26] and content delivery networks (CDN) [27]–[30]. Inthe web caching literature, most of the papers formulate theirproblem in terms of optimized prefetching strategy to maximizehit ratio, to minimize the page/object retrieval delay, and/or tominimize network cost by modeling and utilizing page accesspatterns of a large set of users. The popularity distribution orutility of a page among the users served by an edge proxy or theaccess patterns (e.g., the sequence of page accesses by one ora group of users at a particular site or across the sites) that canlead to good predictions about future web requests constitute

the typical side information used in the optimization processes[24]. In CDN literature, there has been a special focus on mediadelivery with limited proxy storage. Minimizing the playbackdelay as well as smoothing or load balancing the network trafficover longer periods are targeted [28]–[30]. The popularity ofdifferent files, recent access events, and distance of a particularsegment from the start of the video are commonly used in cachemanagement. We provide more details on a few most related pa-pers to our own that incorporate client side cache optimizationbelow.

In [15], authors consider a hybrid P2P architecture wherepeers stream from servers and other peers. Peers optimize thelocal cache space which is used for storing segments from thesame or different video files. Each segment is assigned a priorityindex based on the sum cost of receiving that segment from otherpeers and its demand frequency. The cost of receiving a segmentis in turn defined as a function of supplying peers’ bandwidth,availability, and load. This heuristic approach requires substan-tial maintenance complexity and does not take into account thecases where demand and future supply opportunities can be pre-dicted approximately. The approach does not necessarily matchthe supply to the demand as well.

In [17], authors consider a P2P VoD system similar to ours,where each peer has a limited storage to cache and serveone or more segments. Peers try to get a requested segmentfrom another peer, and if there is not enough peer supply,they resort to the media servers. Peers request the segmentsin subsequent order in a normal operation, but they are alsoallowed to randomly skip to another segment following a Mar-kovian model. Each peer uses some of its download capacityto prefetch segments to be cached and served to other peers.The selection process is randomized such that the segmentswhich have relatively higher supply deficit are more likely tobe downloaded. Since the architecture lacks a control server,the supply and demand estimates of each segment and associ-ated prefetching probabilities are computed and updated in adistributed fashion. If the supply deficit of a cached segment ischanged beyond a certain threshold, another segment is pickedwith the new probabilities and prefetched to the peer. Theconsidered system is closest to our prefetching strategy, butprefetching is repeated during a user’s lifetime depending onhow the current supply and demand estimates are evolving. Itsprobabilistic notion would work well only when there are largenumber of users in the system with respect to the number ofsegments and if the system is stationary. In contrast, we relyon the predictive behavior of users and in addition we examinethe caching opportunities that will emerge in the normal courseof the streaming operation. Furthermore, we explicitly con-sider the committed upload rates by the peers into the supplycomputation.

In another related work [18], authors use joint histogramsof segment popularity across users to devise good prefetchingstrategies to users for supporting random seek operations. Thefocus is not on providing a supply for other peers, but instead onpresenting a model for random seek operation and minimizingthe delay in accessing the desired segments via prefetching themost likely portions of the video before the next seek opera-tion. As an interesting approach, authors tie their optimizationproblem into a quantization problem which refines itself dynam-ically. Similar to our case, users are assumed to be cache limited.


However, their model assumes abundance of bandwidth for theprefetching operation.

VII. CONCLUSION

We have proposed supply-demand-based cache optimiza-tion under various system constraints over a hybrid P2P VoDstreaming architecture that combines P2P delivery and con-tent distribution networks (CDN). In this architecture, eachstreaming peer dedicates some of its upload bandwidth andcache space to the system for serving the same video to otherpeers. Thus, the peers in the proposed system can stream avideo content both from the media servers of CDN and fromthe other peers in the system. An entity called control server 1)monitors the peer states to keep track of the overall supply-de-mand curves for each segment of the video file and 2) dictatesthe caching decisions at the peers to match the future supply(i.e., estimate of it) to the future demand (i.e., estimate of it)using a utility-based approach.

We defined different caching strategies, namely cacheprefetching, opportunistic cache update, and hybrid cachingschemes to capture different system constraints and trade-offs.For cache prefetching, we focused on round robin, random,and utility-based prefetching. For opportunistic cache update,we proposed two methods namely DP and SO. Since they arecommonly used in the literature, we also looked into heuristicssuch as random, last segment, and earlier segment caching.For hybrid strategies, we combined round robin (RR) andutility-based prefetching with the SO solution.

Our overall evaluations suggest that DP solution outper-formed all the other lower complexity schemes except for thecases where peers are less constrained in terms of local re-sources (e.g., upload bandwidth). The benefits of utility-basedoptimization in opportunistic cache update and hybrid schemeswere most emphasized when the system was under morestress, e.g., higher arrival rates and flash-crowd scenarios. Weobserved that DP solution was performing close to optimumfor longer time-horizons under low random churn rates. Underhigh churn rates, however, we found that further optimizationis possible by using shorter time-horizons. On the other hand,SO solution had its best performance for time-horizons thatwere relatively much shorter than that of DP. We also observedthat random departures which are not taken into account in thesupply estimates deteriorate the system performance for all theschemes considered, while DP and round-robin prefetchingturned out to be the most sensitive ones. Nonetheless, DPcontinued to dominate the performance even at considerablyhigh departure rates.

For utility-based prefetching with static caching (i.e.,), one drawback is that when the utility is optimized for the

short-run, the longer-term utility opportunities are lost and viceversa. They are also more susceptible to the dynamic changes inthe supply and demand. Therefore, prefetching-only strategies,even with supply-demand utility optimization, were not iden-tified as proper solutions. Moreover, they add to the streamingdelay due to the prefetching cycle. Opportunistic cache updateand hybrid methods on the other hand provide enough oppor-tunities to adapt against the long-term estimation errors as wellas they can achieve a better balance between the short-term andlong-term gains.

The analysis put forth in this paper is a first step in assessingthe benefits of a hybrid P2P VoD streaming architecture. Itfocuses on and investigates one important aspect in a verylarge design space. Our ongoing work comprises a real-timetest-bed implementation of our hybrid streaming architecturewith cache optimization and deployment over PlanetLab [31],and expanding the problem setting such that the constraints ofthe network topology that interconnects peers and servers arealso taken into account.

REFERENCES

[1] B. Li and H. Yin, “Peer-to-peer live video streaming on the internet: Is-sues, existing approaches, and challenges,” IEEE Commun. Mag., vol.45, no. 6, pp. 94–99, Jun. 2007.

[2] Y. Tang, J.-G. Luo, Q. Zhang, M. Zhang, and S.-Q. Yang, “DeployingP2P networks for large-scale live video-streaming service,” IEEECoummun. Mag., vol. 45, no. 6, pp. 100–106, Jun. 2007.

[3] D. Jurca, J. Chakareski, J.-P. Wagner, and P. Frossard, “Enabling adap-tive video streaming in P2P systems,” IEEE Commun. Mag., vol. 45,no. 6, pp. 108–114, Jun. 2007.

[4] C. Dana, D. Li, D. Harrison, and C.-N. Chuah, “BASS: bittorrentassisted streaming system for video-on-demand,” in Proc. IEEE 7thWorkshop on Multimedia Signal Processing, 2005, pp. 1–4.

[5] M. Zhang, J.-G. Luo, L. Zhao, and S.-Q. Yang, “A peer-to-peer networkfor live media streaming using a push-pull approach,” in Proc. ACMMULTIMEDIA ’05, 2005, pp. 287–290.

[6] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum, “Coolstreaming/DONet: Adata-driven overlay network for live media streaming,” in Proc. IEEEINFOCOM, Mar. 2005.

[7] T. Do, A. Hua, and M. Tantaoui, “P2VoD: Providing fault tolerantvideo-on-demand streaming in peer-to-peer environment,” in Proc.IEEE Int. Conf. Communications, Jun. 2004, vol. 3, pp. 1467–1472.

[8] L. Pinho, E. Ishikawa, and C. Amorim, “GloVE: A distributed environ-ment for low cost scalable VoD systems,” in Proc. 14th Symp. Com-puter Architecture and High Performance Computing (SBAC-PAD),2002, pp. 117–124.

[9] C. MacCarthaigh, Joost Network Architecture, 7th UK Network Op-erators’ Forum, 2007. [Online]. Available: http://www.uknof.org.uk/uknof7/MacCarthaigh-Joost.pdf.

[10] E. Setton and J. Apostolopoulos, “Towards quality of service forpeer-to-peer video multicast,” in Proc. Int. Conf. Image Processing(ICIP), Oct. 2007.

[11] R. Johari and S. Shakkottai, “Revenue management for content de-livery,” in Proc. 45th Allerton Conf., Sep. 2007.

[12] E. Ishikawa and C. L. d. Amorim, “Cooperative video caching forinteractive and scalable VoD systems,” in Proc. 1st Int. Conf. Net-working—Part 2 (ICN ’01), 2001, pp. 776–785.

[13] M. Guo, M. Ammar, and E. Zegura, “Cooperative patching: Aclient based P2P architecture for supporting continuous live videostreaming,” in Proc. IEEE Int. Conf. Computers, Communication andNetworks (IC3N), Oct. 2004.

[14] S. Annapureddy, S. Guha, C. Gkantsidis, D. Gunawardena, and P. Ro-driguez, “Exploring VoD in P2P swarming systems,” in Proc. IEEEInfocom 2007, May 2007.

[15] P. H. Guo, Y. Yang, and X. Y. Li, “A P2P streaming service archi-tecture with distributed caching,” J. Zhejiang Univ., vol. 8, no. 4, pp.605–614, Apr. 2007.

[16] S. Annapureddy, C. Gkantsidis, and P. Rodriguez, “Providingvideo-on-demand using peer-to-peer networks,” in Proc. InternetProtocol TeleVision (IPTV) Workshop (WWW ’06), Edinburgh, U.K.,May 2006.

[17] W. Yiu, X. Jin, and S. Chan, “VMesh: Distributed segment storagefor peer-to-peer interactive video streaming,” IEEE J. Select. AreasCommun., vol. 25, no. 9, pp. 1717–1731, Dec. 2007.

[18] C. Zheng, G. Shen, and S. Li, “Distributed prefetching scheme forrandom seek support in peer-to-peer streaming applications,” in Proc.Workshop on Advances in Peer-to-Peer Multimedia Streaming, ACMMultimedia 2005, Singapore, Nov. 2005.

[19] B. Cohen, “Incentives build robustness in BitTorrent,” in Proc. 1stWorkshop the Economics of Peer-to-Peer Systems, Jun. 2003.

[20] U. C. Kozat, Y. Gwon, and R. Jain, “An overlay server system(OSS) platform for multiplayer online games,” in Proc. IEEEGlobecom-2006, San Francisco, CA, Nov. 2006.


[21] C. Bouras, A. Konidaris, and D. Kostoulas, Predictive Prefetching onthe Web and Its Potential Impact in the Wide Area, 2004.

[22] D. Starobinski and D. N. C. Tse, “Probabilistic methods for webcaching,” Perform. Eval., vol. 46, no. 2-3, pp. 125–137, 2001.

[23] T. Palpanas and A. Mendelzon, “Web prefetching using partial matchprediction,” in Proc. 4th Int. Web Caching Workshop, 1999.

[24] J. Wang, “A survey of Web caching schemes for the Internet,” ACMComput. Commun. Rev., vol. 25, no. 9, pp. 36–46, 1999.

[25] P. Cao and S. Irani, “Cost-aware WWW proxy caching algorithms,” inProc. 1997 Usenix Symp. Internet Technologies and Systems (USITS-97), Monterey, CA, 1997.

[26] V. N. Padmanabhan and J. C. Mogul, “Using predictive prefetching toimprove world-wide web latency,” in Proc. ACM SIGCOMM ’96 Conf.,Stanford Univ., Stanford, CA, 1996.

[27] W. Kun-Lung, P. S. Yu, and J. L. Wolf, “Segmentation of multimediastreams for proxy caching,” IEEE Trans. Multimedia, vol. 6, no. 5, pp.770–780, Oct. 2004.

[28] J. Shodong, A. Bestavros, and A. Iyengar, “Accelerating internetstreaming media delivery using network-aware partial caching,” inProc. 22nd Int. Conf. Distributed Computing Systems, 2002, pp.153–160.

[29] S. Sen, J. Rexford, and D. F. Towsley, “Proxy prefix caching for multi-media streams,” in Proc. IEEE INFOCOM, Apr. 1999, pp. 1310–1319.

[30] S. Chan and F. Tobagi, Caching Schemes for Distributed Video Ser-vices, 1999.

[31] Planetlab Consortium. [Online]. Available: http://www.planet-lab.org/.

Ulas C. Kozat (S’97–M’04) received the B.S. degreein electrical and electronics engineering from BilkentUniversity, Ankara, Turkey, and the M.S. degree inelectrical engineering from the George WashingtonUniversity, Washington, DC, in 1997 and 1999,respectively. He received the Ph.D. degree in 2004from the Department of Electrical and ComputerEngineering at the University of Maryland, CollegePark.

He has conducted research under the Institute forSystems Research (ISR) and Center for Hybrid and

Satellite Networks (CSHCN) at the same university. He worked at HRL Labora-tories and Telcordia Technologies Applied Research as a research intern. SinceMay 2004, he has been with DoCoMo USA Labs, Palo Alto, CA, where he iscurrently serving as Senior Researcher and Project Manager. He has been con-ducting research in the broad areas of wireless communications and communi-cation networks.

Öztan Harmanci (S’03–M’06) received the B.S.degree in electrical and electronics engineering fromBilkent University, Ankara, Turkey, in 2000; theM.S. degree in electrical and computer engineeringfrom Georgia Institute of Technology, Atlanta, in2001; and the Ph.D. degree in electrical and com-puter engineering from the University of Rochester,Rochester, NY, in 2006.

He was with DoCoMo USA Labs, Palo Alto, CA,from December 2007 to February 2008. He is cur-rently with Anvato, Inc. His research interests are in

the area of image and video processing and watermarking, media communica-tion over lossy networks, and content tracking and identification.

Dr. Harmanci is a member of the IEEE Signal Processing Society.

Sandeep Kanumuri (S’04–M’07) received theB.Tech. degree in electrical engineering from theIndian Institute of Technology, Madras, India, in2002 and the M.S. and Ph.D. degrees in electricaland computer engineering from University of Cal-ifornia-San Diego (UCSD), La Jolla, in 2004 and2006, respectively.

He is currently a Research Engineer at DoCoMoUSA Labs, Palo Alto, CA. During the summer of2003, he was a Visiting Researcher at AT&T Labs,Florham Park, NJ. During the summer of 2005, he

worked in the MediaFLO division of Qualcomm, San Diego, CA. He workson research problems related to the compression, distribution, post-processing,and quality estimation of images and video.

Mehmet Umut Demircin (S’02–M’08) received theB.S. degree in electrical and electronics engineeringin 2001 from Bilkent University, Ankara, Turkey,and the M.S. and Ph.D. degrees in electrical andcomputer engineering in 2004 and 2008, respec-tively, from Georgia Institute of Technology, Atlanta.

His research areas include video coding and videostreaming over wireless and peer-to-peer networks.He was a summer intern in Sharp Laboratories ofAmerica, Camas, WA, in 2004 and 2005 and inDoCoMo USA Labs, Palo Alto, CA, in 2007. He is

currently employed in the Texas Instruments DSP Solutions R&D Center as amember of the technical staff.

M. Reha Civanlar (F’05) received the B.S. and M.S.degrees in electrical and electronic engineering fromMiddle East Technical University (METU), Turkey,in 1979 and 1981 respectively, and the Ph.D. degreein electrical and computer engineering from NorthCarolina State University (NCSU), Raleigh, in 1984.

He joined Ozyegin University, Istanbul, Turkey, asFounding Dean of School of Engineering in 2008.Before, he was a Vice President and Director of Net-work and Media Lab in DoCoMo USA Labs, PaloAlto, CA, since 2006. He was a Visiting Professor

of Computer Engineering at Koc University, Istanbul, from 2002 to 2006. Hewas also leading a multinational European Union-supported Research Project onthree-dimensional television (3DTV) transport and advising several communi-cations companies. He is serving at the advisory boards of Argela TechnologiesInc., on multimedia systems and Vidyo Inc., on multipoint videoconferencing.Prior to these, he was a video communications researcher in Visual Commu-nications Research Department at AT&T Labs-Research starting from 1991.He became a department head in 1999. Prior to that, he was at Pixel MachinesDepartment, Bell Laboratories, where he worked on parallel architectures andalgorithms for image and volume processing and scientific visualization. Hiscareer started as a researcher in the Center for Communications and Signal Pro-cessing of NCSU, where he worked on image processing. He has numerous pub-lications, several key contributions to international multimedia communicationsstandards, and over 40 patents either granted or pending. His current researchinterests include packet video systems, networked video and multimedia appli-cations with a particular emphasis on the Internet and wireless systems, videocompression, 3DTV, and next generation Internet.

Dr. Civanlar is a recipient of the 1985 Senior Award of the ASSP societyof IEEE. He is a Fulbright scholar and a member of Sigma Xi. He servedas an editor for the IEEE TRANSACTIONS ON COMMUNICATIONS, the IEEETRANSACTIONS ON MULTIMEDIA, and the Journal of Applied Signal Processing.He is currently an editor for Image Communications. He served as a memberof MMSP and MDSP Technical Committees of the Signal Processing Societyof IEEE.

Documents

Peer Assisted Video Streaming With Supply-Demand-Based Cache Optimization