PopCap: popularity oriented proxy caching for peer ... - CiteSeerX

Front. Comput. Sci. China 2010, 4(4): 500–515 DOI 10.1007/s11704-010-0347-1

RESEARCH ARTICLE

PopCap: popularity oriented proxy caching for peer-assisted Internet video-on-demand streaming services Ye TIAN (✉), Bangchuan LIU, Zhenhua HE Anhui Province Key Laboratory on High Performance Computing and Application, School of Computer Science and Technology, University of Science and Technology of China, Hefei 230027, China

© Higher Education Press and Springer-Verlag Berlin Heidelberg 2010

Abstract With the success of Internet video-on-demand (VoD) streaming services, the bandwidth required and the financial cost incurred by the host of the video server becoming extremely large. Peer-to-peer (P2P) networks and proxies are two common ways for reducing the server workload. In this paper, we consider a peer-assisted Internet VoD system with proxies deployed at domain gateways. We formally present the video caching problem with the objectives of reducing the video server workload and avoiding inter-domain traffic, and we obtain its optimal solution. Inspired by theoretical analysis, we develop a practical protocol named PopCap for Internet VoD services. Compared with previous work, PopCap does not require additional infrastructure support, is inexpensive, and able to cope well with the characteristic workloads of Internet VoD services. From simulationbased experiments driven by real-world data sets from YouTube, we find that PopCap can effectively reduce the video server workload, therefore provides a superior performance regarding the video server’s traffic reduction. Keywords Internet video-on-demand (VoD), peer-topeer (P2P), caching, algorithm/protocol design and analysis

Received March 22, 2010; accepted August 8, 2010 E-mail: [email protected] 1) http://www.youtube.com/ 2) http://www.tudou.com/ 3) http://www.youku.com

1

Introduction

With the advent of Web 2.0 technologies, interactive information sharing using audio and video instead of mere plain text is becoming increasingly popular on the Internet today. Among the newly emerging Web 2.0 applications, Internet video-on-demand (VoD) streaming services, such as YouTube1), and the China-based Tudou2) and Youku3), have attracted millions of users. Unlike the traditional IPlayer VoD [1] and the recently popular Peer-to-peer (P2P) VoD [2], in Internet VoD, videos are contributed by users, and people can upload, view, tag, and comment on the videos. Because of its openness and interactivity, Internet VoD has rapidly become very popular since its inception; for example, it was reported in 2006 that each day there were more than 65000 new videos uploaded on YouTube, and the site was receiving 100 million video views per day [3]. It is also estimated that in 2007 YouTube consumed bandwidth equivalent to that of the entire Internet in the year 2000 [4]. With its extraordinary large video collection and number of user views, Internet VoD is far from an online cinema. For such a large system, how to efficiently and inexpensively deliver videos to users becomes a very challenging problem. Currently nearly all the existing Internet VoD systems adopt a client-server architecture, where all the videos are streamed by the video server (server cluster or content distribution networks (CDN)) to each user, thus the bandwidth required and cost incurred is very large. In

Ye TIAN et al. Proxy caching for peer-assisted Internet VoD

2008 for example, YouTube is estimated to have paid approximately one million US dollars per day for bandwidth alone [5]. Obviously, it is economical and technical beneficial if the traffic from the video server can be reduced. Recently, some researchers have proposed the use of P2P networks (e.g., [6]), where peers cache their downloaded videos and help distribute them for Internet VoD services. However, due to the special features of Internet VoD service, technologies that are widely used in P2P VoD streaming (e.g., PPLive [2]) may not work well in the context of Internet VoD. On the other hand, in traditional VoD services, proxies have been widely used (e.g., [7,8]). In this paper, we consider combining the two methods, and propose a protocol for peer-assisted Internet VoD services with proxies. In this work, we first examine the characteristics of Internet VoD’s workload by investigating real-world data sets obtained from YouTube. We find that in Internet VoD, there exists an extreme imbalance in the distribution of video popularity, and that a majority of the videos are very short. We then formally present the video caching problem of the Internet VoD system that combines proxies and P2P networks, with the objectives of reducing video server workload and avoiding inter-domain traffic. We show that for such a problem, an optimal solution exists. With awareness of the characteristic workload of Internet VoD services and using theoretical analysis, we design PopCap, a practical protocol for proxies and peers in P2P networks to both independently and collaboratively cache videos. In the PopCap protocol, videos are cached in proxies in a proactive manner, while on peers, we use blocking as well as evicting to cope with the extremely imbalanced video popularity, therefore we enable the peers to avoid globally excessive or inadequate caching of video. Unlike many P2P-based caching systems such as PROP [8], PopCap does not rely on a DHT (distributed hash table)-based overlay, therefore can cope well with the characteristics of Internet VoD , while unlike traditional Internet VoD systems, PopCap exploits the resources of individual peers, thus extensively reducing server workload. Compared with existing solutions we find that PopCap is more practical and inexpensive, which makes it suitable for deployment for Internet VoD services. From simulation-based experiments driven by real-world YouTube data sets, we find that the PopCap protocol can effectively reduce video server workload by making better use of the caching spaces on both proxies and peers, 1) http://video.msn.com/

501

moreover, its smart update mechanism (see section 6.5) provides the flexibility to further reduce the overall bandwidth cost of video servers. Section 2 discusses related work. Section 3 describes the architecture of our peer-assisted Internet VoD system. In Section 4, the characteristics of Internet VoD services are analyzed using real-world data sets. In Section 5, we formally present the video caching problem, obtain its optimal solution, and discuss the implications. We subsequently propose the PopCap protocol in Section 6 and in Section 7 we investigate the performance of PopCap and compare it with other solutions. Finally, we conclude this work in Section 8.

2

Related work

Thanks to the great commercial success and influence of Internet VoD, much work has been done on this subject. In [9], YouTube and a popular Korean Internet VoD service are studied; the authors analyze many aspects of the service including the life-cycle of the videos and the relationship of life to video requests. They also show that server workload can be greatly reduced if some P2P assistance is available. In [6], traces from the MSN video service1) are investigated, and using a simple analytical model, it is shown that the traffic on the video server can be dramatically reduced if a P2P network assists in the distribution of the videos: even if a strong locality rule is applied for the P2P network. In [10], by examining data obtained from YouTube, patterns of social networks are observed between the videos. Following these observations, the authors propose a novel P2P-assisted video delivery framework that explores the clustering of video social networks in order to improve playback quality and reduce server workload. In [11], the network traffic caused by campus users downloading videos from YouTube is investigated; the authors point out that using intelligent exploitation of metadata, better video caching strategies can be developed. Besides Internet VoD, on-demand video streaming using P2P techniques has also become very popular in recent years. Examples include P2Cast [12], P2VoD [13] and DSL [14]. P2Cast and P2VoD investigate a tree-based overlay structure to organize the peers, while DSL presents a dynamic skip list overlay to enable the VCR operation. Cui et al. propose oStream, which extends

502

Front. Comput. Sci. China 2010, 4(4): 500–515

application multicast to support VoD with buffers on peers [15]. Tian et al. consider a probabilistic caching mechanism, running on the clients, to reduce the video server workload [16]. Deploying dedicated proxies in order to reduce video server workload and provide a better quality streaming service has been studied for a long time in traditional VoD services. In [7], the conflict between hit ratio and proxy jitter in the design of proxy caching strategy is investigated, and a new proxy system named Hyper Proxy is proposed. In [17], a cooperative proxy-client caching system is proposed, where the low cost of P2P networks and robustness of a dedicated proxy are combined. In a recent work [18], the caching problem for peers in a P2P assisted VoD system is investigated, and an algorithm with the features of proportional partial admission and eviction of video segments is proposed. In [8], the authors consider a VoD service combining both proxies and P2P networks, they propose a system named PROP to cache and distribute the videos in a reliable and scalable manner. Our work is different from previous works in that we jointly consider proxies and peer caching in the context of an Internet VoD service. By combining proxies with P2P networks, critical issues such as peer-proxy collaboration must be addressed, and the characteristic Internet VoD workload also needs to be addressed when developing system protocols. In particular, because of the special characteristics of the workload, techniques that are widely used in ordinary P2P VoD systems must be carefully reexamined before being applied.

3

System architecture

In this paper, we consider a peer-assisted Internet VoD system with proxies. In such a system there are three components: (a) the server, which at a minimum, consists of: a web server, an index server, and a video server (server cluster or CDN); (b) the client-system which requests and downloads the videos; and (c) the proxy which is deployed at the gateway of a domain and streams the cached video to clients residing in the same domain. In addition, clients form a self-organized P2P overlay network, in which each of them is both a peer and independently maintains a video cache. Generally, the server is maintained by the video service provider (VSP) such as YouTube, the proxy can be run by the VSP, ISP, or local service provider such as university campus services,

and the peers are autonomous ordinary end-systems. A demonstration of the system architecture is shown in Fig. 1.

Fig. 1 System architecture for peer-assisted Internet VoD with proxy caching

In a peer-assisted Internet VoD system, a peer caches the videos it has downloaded. Peers independently manage their local cache. When a peer joins or leaves the system, or a video replica is cached or gets evicted, the peer reports to the index server. In Fig. 1 we depict the process of requesting a video; when a peer requests a video, for example, by clicking the URL of the video served by the website on the VSP, if a proxy is available for the domain of the peer, the gateway redirects the request to the proxy (step 1). The proxy provides the video to the peer if it has cached a replica and has enough outgoing bandwidth (step 2). If there is no proxy or the proxy is unable to stream the video, the request is then sent to the index server (step 3), which returns a list containing some other peers on the P2P network that currently have this video cached (step 4). The peer then requests and downloads the video from some of these peers in a P2P manner, e.g., swarming [19] (step 5). Finally, in the case that there is no peer which has cached this video, or none of the index server returned peers can provide the video for any reason, such as poor network conditions or stale information on the index server, the requesting peer directly streams the video from the video server (step 6). From this procedure, we can see that by deploying a proxy, some inter-domain traffic can be avoided, since both P2P sharing and direct downloading from the video server incur traffics out of the domain. Moreover, the proxy and the P2P network can reduce the workload on the video server. Clearly, to effectively achieve these objectives, the proxy and the P2P network should cache the videos in a smart and cooperative way. In the following sections, we will investigate this problem from a theoretical and practical stand point.

Ye TIAN et al. Proxy caching for peer-assisted Internet VoD

4

Characterizing Internet VoD

Before analyzing the video caching problem, we first investigate some characteristics of Internet VoD services. Two public data sets, that have been collected by crawling YouTube, are used for our investigation [9,10]. From the data set in [9], we use the sci data set which contains 252255 videos. For the data in [10], we choose the data set collected on March 16th, 2007 containing 42628 videos: hereby referred to as the 0316 data set. We first examine the popularity of the videos in Internet VoD. In Fig. 2, we plot the view times against their ranks for all the videos in the sci and 0316 data sets. Note that in the Fig. 2, the curves are plotted on a log-log scale. In recent years, many works consider the video access pattern to follow a Zipf distribution, [8] and [20], or some other Zipf-like distributions, such Zipf with exponential cutoff [9] and Mandelbrot-Zipf [18]; on the other hand, a recent work reveals that popularity of the videos is more likely to follow a stretched exponential distribution [21].

503

In our work, we do not try to fit the video access data from the data sets to theoretical models, but focus on the fundamental features of the data. That is, we find from the figures that an extreme imbalance exits in the distribution of video popularity. For example, in the sci data set, the most popular video gets viewed 2537904 times, while the mean and the median view times in this data set are 2140 and 186 respectively. For the 0316 data set, the maximum, mean and median values are 2755993, 5405, and 838 respectively. Another feature of Internet VoD services we are interested is the video length. In [10], it is reported that a majority of the videos on YouTube are no longer than 700 seconds; by examining the data sets, we find that the mean video lengths for sci and 0316 are 143 and 205 seconds, respectively. In summary, by examining the YouTube data sets, we find that: 1) there exists an extreme imbalance regarding the distribution of video popularity; 2) compared with traditional VoD, videos in Internet VoD are very short. The two features of Internet VoD services impose a great challenge for applying P2P network-based technologies on Internet VoD, for the following reasons: First of all, with very short videos, peers will perform operations such as video request, cache update, and cache announcement very frequently, this incurs a great workload on the P2P overlay; Second, with imbalanced video popularity, the workload on a DHT-based overlay will also be imbalanced. For example, the peer that manages the key of the most popularly video will have a much higher workload compared to other peers.

5

Analyzing video caching in Internet VoD

In this section, we formally present the video caching problem for a peer-assisted Internet VoD system and theoretically analyze it. 5.1

Fig. 2 Popularity of the videos in (a) sci data set and (b) 0316 data set

Video caching problem

In our theoretical analysis, we consider a peer-assisted Internet VoD system with a collection of M videos, which are ranked in descending order of their popularity; there are N online peers. For simplicity, we assume that all videos are of equal-size. Each peer, can cache up to c videos, while the proxy, can cache C (C >> c) videos. Each video, i, may be cached by the proxy, and also may be cached by a number of online peers. We use ci (ci = 0, 1) to denote whether or not video i is cached by the proxy, that

504

Front. Comput. Sci. China 2010, 4(4): 500–515

is, if cached, ci = 1, and ci = 0 if not cached. We use ni (N≥ni≥0) to denote the number of the peers that currently cache the video. For all M videos, a vector N ¼ fn1 ,n2 ,:::,nM g is used to denote the caching status of the P2P network and a vector C ¼ fc1 ,c2 ,:::,cM g is used to denote the proxy caching decision. In our analysis, we assume that the proxy has sufficient out-going bandwidth and never fails, thus when a video is cached by the proxy, the proxy can stream to any requesting peer. On the other hand, peers in the P2P network are different. A peer may fail, or it may evict the video to make room for a new video replica, and worse, the index server that stores the video caching status may have stale information. Moreover, even for a peer that has the video cached, the network conditions may be poor between the peer and the requesting peer. To accommodate these concerns, in our analysis we simply use a probability, p, to denote the probability that a peer, which the index server determines is able to serve a particular video, is able to provide the video. Obviously with such unreliable peers, the probability that video i cannot be served by the P2P network is ð1 – pÞni . Let l be the total video request rate from the N online peers, then the rate of the requests that goes to the video XM lpi ð1 – ci Þð1 – pÞni , here server can be expressed as i¼1 pi stands for the popularity of video i. If we define XM ðn,cÞ ¼ p ð1 – ci Þð1 – pÞni as the ratio of the i¼1 i workload on the video server, then the video caching problem for the peer-assisted Internet VoD with proxy can be expressed as XM p ð1 – ci Þð1 – pÞni , Minimize  ðn,cÞ ¼ i¼1 i s:t:

ci ¼ 0,1; i ¼ 1,2,:::,M , ni ³0; i ¼ 1,2,:::,M , XM c ¼ C, i¼1 i XM n ¼ N  c: i¼1 i

5.2

(1)

Optimal solution and its implications

We first consider the case that no proxy is deployed. For this case, the problem in Eq. (1) can be rephrased as XM p ð1 – pÞni , Minimize  ðnÞ ¼ i¼1 i (2) XM s:t: n ¼ N  c: i¼1 i For this problem, we have the following result.

Theorem 1 For the video caching problem in Eq. (2), the optimal solution n is Q log M N log pi j¼1 pj  þ : (3) ni ¼ c – M logð1 – pÞ M logð1 – pÞ Proof　First of all, for ni in Eq. (3), it is easy to see that XM  n ¼ Nc, suggesting that Eq. (3) is a feasible i¼1 i solution. Furthermore, for any i and j, i ≠ j, we have 



pi ð1 – pÞni ¼ pj ð1 – pÞnj : We now prove that the solution in Eq. (3) is the local optimum. To show this, we consider another solution í í n# ¼ fní 1,n2 ,:::,nM g, where for a particular i and j (i ≠ j), í   ni ¼ ni þ 1 and ní j ¼ nj – 1, and for any k (k ≠ i, j),   ní k ¼ nk . By taking n# and n into the objective function ðnÞ in Eq. (2) respectively, we have í

í



ðn# Þ – ðn Þ ¼pi ð1 – pÞni þ pj ð1 – pÞnj – pi ð1 – pÞni 

– pj ð1 – pÞnj 

¼pi ð1 – pÞni ðð1 – pÞ – 1Þ   1 nj þ pj ð1 – pÞ –1 , 1–p 



since pi ð1 – pÞni ¼ pj ð1 – pÞnj , we can see that    1  n i – 2 > 0, ðn# Þ – ðn Þ ¼ pi ð1 – pÞ ð1 – pÞ þ 1–p for any p > 0. In other words, n is the local optimum. Finally, note that the objective function ðnÞ is convex and the constraint is affine, thus the problem in Eq. (2) is actually a convex optimization problem. It is well-known that for such a problem, any local optima is globally optimal [22], therefore Eq. (3) is the optimum solution for the video caching problem without proxy in Eq. (2). We then consider the video caching problem in Eq. (1) when a proxy is deployed, for this problem, we have the following result. Theorem 2 For the video caching problem in Eq. (1), the optimal solution is 8(  > > ni ¼ 0, 1£i£C, > > >  > ðlog pi – log pj Þ < Nc > j¼Cþ1  > > ni ¼ – ,C þ 1£i£M , > > ðM – CÞlogð1 – pÞ > :> :  M –C ci ¼ 0: (4)

Ye TIAN et al. Proxy caching for peer-assisted Internet VoD

Proof　We first show that for any solution of c, the proxy selects any C videos from the M videos to cache, the optimal solution of n is 8  if   ci ¼ 1, ni ¼ 0, > > > > > Nc log pi <  ni ¼ – logð1 – pÞ M – C Q > > > log j,cj ¼0 pj > > : , if   ci ¼ 0: þ ðM – CÞlogð1 – pÞ To show this, note that for any video, say video i, when it is cached by the proxy, ci ¼ 1, lpi ð1 – ci Þð1 – pÞni ¼ 0 regardless of the value of ni. So for this video, the proxy will serve all the requests, and it is not necessary for the P2P network to cache any replicas, i.e., ni ¼ 0. Now with C videos being cached by the proxy, M – C videos with ci = 0 are for the P2P network to cache. According to Theorem 1, for these videos, the optimal solution is Q log j,cj ¼0 pj Nc log pi  – ni ¼ þ : M – C logð1 – pÞ ðM – CÞlogð1 – pÞ We next show that with n , the optimal solution for c is ( ci ¼ 1, 1£i£C, ci ¼ 0,

C þ 1£i£M:

We prove this result in the following; by taking n into the objective function ðn,cÞ, we can see that X  pi ð1 – pÞni ðn,cÞ ¼ i,ci ¼0

¼ðM

Nc – CÞð1 – pÞ M – C

Y

! pi

1 M –C

:

i,ci ¼0

To minimize ðn,cÞ, we only need to minimize Y p . Obviously, the best way is to set ci = 0 for i,c ¼0 i i

the M – C least popular videos. In other others, the proxy caches the C most popular videos. Therefore we have proved the theorem. In our problem formulation in Eq. (1), we only consider the objective of minimizing the video server workload (i.e., minimizing ρ), but do not consider the objective of avoiding the inter-domain traffic. However, we can see that the solution obtained in Eq. (4) also achieves this objective. As both the direct downloading from the video server and using the P2P network incurs inter-domain traffic, clearly the most requested videos should be cached by the proxy to avoid the inter-domain traffic to the greatest extent, as shown in Eq. (4).

505

In a practical peer-assisted Internet VoD system, clearly it is infeasible to obtain the values of the parameters pi, p, N, therefore we cannot apply the solution in Eq. (4) directly. However, some insight can be obtained from Eq. (4). First of all, note that in the optimal solution, the proxy only caches the C most popular videos, and peers do not cache any replicas of them. This observation suggests that in a practical system, the proxy must be able to identify these popular videos and peers must be able to avoid caching these videos. Second, we note that for videos that are not cached by proxy, a proper number of replicas should be cached by peers in the P2P network, in particular, the difference between the number of replicas of video i and video j should be proportional to log pi – log pj . This observation suggests that if we know how to cache one video, say video k, then for any specific video, in principle we will know how to cache it by using video k as a benchmark. 5.3

Numerical evaluation

Finally, we numerically evaluate the effectiveness of our solution for peer-assisted Internet VoD. For video popularity, we use the data of the first 20000 videos obtained from the YouTube sci data set as shown in Fig. 2. We calculate the minimized workload ratios on the video server by applying the optimal solution from the objective function in Eq. (2). For other parameters, we let N = 2000, p = 0.8, C = 1000, and c = 5 as the default. We first investigate the influence of the proxy cache size. For varying proxy cache sizes, C, we plot the video server ratio, ρ, against C in Fig. 3(a). From the figure one can see that by enlarging the cache size, the server workload is reduced because more videos are served by the proxy. Moreover, we can see that the curve is almost linear, which means if the cost for larger storage is less than for the cost for extra network traffic, it is more economically beneficial for an ISP or VSP to pay for the proxy storage than for bandwidth. We also consider the influence of the peer cache size by varying c and plot the video server ratio ρ against c in Fig. 3(b). From the figure we can see that when c is increased from a small value, ρ decreases dramatically, and when c is large, ρ approaches zero. This observation indicates that P2P networking is promising for the Internet VoD service, thus it is very important to encourage the peers, which are usually selfish, to contribute their local storage to the P2P network. We calculate the server workload ratio ρ under varying

506

Front. Comput. Sci. China 2010, 4(4): 500–515

Fig. 3 Video server’s workload ratio ρ under optimal proxy and peer caching with (a) varying proxy cache size C, (b) varying peer cache size c, and (c) varying peer reliability p

peer reliability values of p and plot ρ against p in Fig. 3(c). From the figure we can see that even under the moderate peer cache size, increasing p can dramatically decrease ρ and reduce the server’s workload, therefore it is essential to make timely updates to the index server and eliminate the stale information.

6

PopCap protocol

Motivated by the theoretical analysis, in this section, we consider under the real-world Internet VoD environment, how to design a practical protocol for the proxy and the peers in a P2P network to independently and cooperatively cache videos. 6.1

Feasibility of P2P technologies

As shown in Section 4, we have observed two features of Internet VoD by examining real-world data sets: 1) extremely imbalanced video popularity; 2) very short video length. The former incurs a load balancing issue on P2P networks, especially DHT-based overlays, while the latter causes a great increase of workload. Because of these observations, before designing the protocol, it is necessary for us to examine the feasibility of the P2P technologies that are successfully applied in ordinary P2P VoD systems under the context of Internet VoD. It is noted that nearly all the existing P2P VoD systems rely on two essential technologies: a swarming overlay technology and DHT-based overlay technology, where the former is used to distributed the video data and the latter is applied for resource lookup and management. In previous efforts of applying P2P networks on the Internet VoD service, P2P swarming technology has been proven to work well. For example, NetTube [10] applies a swarming protocol similar to the one used in

CoolStreaming [23] to enable a peer-assisted Internet VoD streaming. Meanwhile, there is very little effort of applying DHT-based overlays upon Internet VoD. On the other hand, recently a P2P assisted VoD system named PROP has been proposed [8], where a DHT-based overlay is used for assisting peers and the proxy to make video caching decisions. Therefore, it is necessary to examine the applicability of DHT-based overlay technology under the context of Internet VoD. We consider a peer-assisted Internet VoD system similarly to PROP [8], equipped with a DHT-based overlay. In such a system, when a user finished viewing a video, which has a typical length of 3 min, then it may keep the video in its local cache and evict some cached videos to make room, in this case, it must look up the peers that manage the keys of the new cached video and the evicted cached videos on the DHT overlay to make the updates. After that, if the peer requests another video to view, it also must look up the peer that manages the video’s key on the DHT overlay to locate the peers that have this video cached. Note that for each DHT lookup, O(logN) message deliveries are introduced on the overlay, so on average a peer will send or forward 3  log2N DHT lookup messages every 3 min. Suppose that each lookup message is 20 bytes, then for a moderate system containing 5000 peers, on average the bandwidth used for DHT lookup on a peer is 33bps, which is no longer negligible. Moreover, recall that the popularity of the videos in Internet VoD is extremely imbalanced, which causes an similar imbalance of the workload on the DHTbased overlay. Suppose that the workload scales with the same rule as the popularity, then by applying the data in sci the bandwidth used for DHT lookup on the peer with the heaviest workload will be 39Kbps, which is totally unacceptable. In addition, unlike the transport of video data, DHT lookups have much more stringent

Ye TIAN et al. Proxy caching for peer-assisted Internet VoD

requirements on acceptable delay, and the heavy and imbalanced DHT lookup workload on peers further reduces the efficiency of a DHT-based overlay. In summary, we find that under the context of the Internet VoD service, DHT-based overlay is not feasible, this makes the systems that rely on DHT (e.g., PROP) no longer suitable for Internet VoD, and forces us to seek approaches which could cope with the features of Internet VoD to practically solve the video caching problem. Following we present PopCap, a practical protocol for the proxy and the peers in a P2P network to independently and cooperatively cache videos under a Internet VoD service. 6.2

Metadata collecting and estimation

In PopCap, we use the video server, the proxy, and the peers to collect metadata, the metadata collected will be used for assisting the proxy and individual peers to make their caching decisions. Specifically, for each video, i, the video server measures the following metrics: r ● ni : total number of the times video i has been requested, e.g., through a click on the VSP’s website r ● ti : the last time video i was requested s ● ni : total number of the times that video i is served bythe video server s ● ti : the last time that video i was served by the video server ● ai : the time that video i was added to Internet VoD service ● si : video i’s size in bytes While on the proxy, following metrics are collected: p ● ni : total number of the times that video i is served by the proxy; p ● ti : the last time that video i was served by the proxy; ● di: total bytes of video i that are served by the proxy. Each peer, say peer j, also keeps the following information for each video replica it currently keeps in its local cache: a ● ti : the time that this video replica is added into the peer’s local cache. Note that under the current Internet VoD system architecture, the video server, proxy, and peers only need use a few counters and time stamps to obtain these metadata. It is not necessary to build a DHT overlay to collect this information. In addition to the metrics measured directly in the Internet VoD system, two other metrics are estimated. Specifically, for each video, we use the method proposed

507

in [8] to estimate its popularity, that is, for video i, its popularity is estimated as  r  ni 1 , (5) , Pi ¼ min r ti – ai t – tir nri is the tir – ai long-term request rate of this video since the video was 1 is added, t – tir is the time since the last request, and t – tir an approximation of the video’s recent request rate. The proxy also calculates the usefulness of proxy caching for each video as the following  p  ni t – tir Proxy (6) ¼ max r , p : Ui ni t – ti where t is the current time. In the expression,

npi is the long-term ratio of the video uploaded by nri t – tir the proxy, and is the likeliness that this video will be t – tip served by the proxy on the next request. Here

6.3

Proxy cache strategy

The optimal solution in Eq. (4) shows that for a peerassisted Internet VoD system, the proxy should cache the most popular videos. However, in our analysis it is assumed that all the videos are equally sized. Clearly this assumption is impractical. Given two equally popular videos, the smaller one is preferred to be cached as caching space is limited. If a smaller video is cached, it means that the proxy has more space to cache other videos. For example, caching two 50 MB videos where each has 100 hits means that 200 requests are served by the proxy at a cost of 100 MB. But caching one 100 M video with 100 hits only serves 100 requests. However, to reduce the server workload, for equally popular videos, caching a large one is preferred. Moreover, in Internet VoD, it is possible that a user does not download the entire video, but only downloads a part of it. Obviously, the videos that are downloaded with a larger portion should also be preferred. In the PopCap protocol, we will consider the three factors in making the caching decisions, that is: 1) the video’s popularity; 2) the video’s size; and 3) proportion of the video that is actually downloaded, in making the caching decisions. For updating video caches on the proxy, periodically the proxy calculates Pi and Ui for all the videos and solves the following problem:

508

Front. Comput. Sci. China 2010, 4(4): 500–515

    1 di gðsi Þh p , Minimize  P ð1 – ci Þf i¼1 i ni  si si (7) s:t: ci ¼ 0,1; i ¼ 1,2,:::,M , XM s c £C: i¼1 i i XM

In the problem, M is the total number of the videos under consideration, C is the proxy’s cache size. ci (ci = 0, 1) is the label on whether or not video i should be cached     1 di by the proxy. For f , g(si), and h p , they si ni  si represent the proxy’s preference on video size and the likelihood that the video is will be downloaded by users   1 1 For simplicity, in PopCap we let f ¼ , g(si) = si, si si   di di ¼ p . Clearly for the problem in and h p ni  si ni  si Eq. (7), the videos with the largest weights for (1 – ci) in the objective function should be cached. Therefore, in the PopCap proxy cache strategy, for each video, the proxy calculates a weight as d Wi ¼ Pi p i , ni  si

(8)

and selects the videos with the largest weights to cache, until the cache is full. In PopCap, the proxy periodically determines which videos should be cached, then it requests missing videos from the video server and discards the videos that should no longer be cached. 6.4

Peer cache strategy

For PopCap’s peer cache strategy, usually there are two approaches for a peer to set up an order in caching videos: blocking and eviction. For blocking, when a video is downloaded to play, the peer does not necessarily store the video into its local cache, but only caches it with a certain probability; while in eviction, every video is associated with a priority, when a new video needs to be cached, the peer evicts its cached videos based on their priorities. The benefit of blocking is that peers need not cache the less preferred videos, however, it takes longer for a peer to update its cache as not all the downloaded videos enter into cache. For eviction, the benefit is that all the downloaded videos are cached, however, for very popular videos that have been downloaded very frequently, it is very difficult to reduce the numbers of replicas even if low priorities are assigned. In our peer caching algorithm, we

combine the two approaches: we block popular videos that are likely to be cached by the proxy with a high blocking probability, while cached videos are evicted according to their priorities. Specifically, for each video, i, we use the usefulness of the proxy as its blocking probability, i.e., Pbi ¼ UiProxy :

(9)

In PopCap, the number of the replicas cached by peers should follow the optimal distribution as shown in Eq. (4). To achieve this objective, we carefully control the lifetime of peer cached video replicas. Specifically, for the evicting priority, we periodically use the proxy calculate a time to cache (TTCi) for each video as TTCi ¼

logPi – logPmin , Pi

(10)

where Pi is video i’s estimated popularity as in Eq. (5), and Pmin is the minimum popularity for all the videos under consideration. When a peer needs to cache a new video, it calculate the priorities for all the videos it has cached as Pri ¼ TTCi – ðt – tia Þ,

(11)

where t is the current time. The TTC metric indicates how long a video replica should be cached by the P2P network. From Theorem 2 we known that the number of the video replicas on their popularity is in logarithm, then if the number of cached replicas for the least popular video is zero, there should be logPi – logPmin replicas for video i. Since Pi is also the request rate for the video, according to Little’s law [24], logPi – logPmin , which the time that a replica is cached is Pi is the replica’s time to cache. PopCap’s peer cache strategy works as follows: when a peer has downloaded video i, it queries the proxy for the video i's blocking probability Pbi, and caches the video with a probability of (1 – Pbi). When there is no room for the new video, the peer queries the proxy for TTCs of all its cached videos, and calculates their priorities. Then the peer chooses the one with the smallest priority and evicts iteratively, until the newly downloaded video can be cached. Finally, we compare PopCap’s peer cache update strategy with the one used in PROP [8], where a eviction-based mechanism is proposed. In PROP, a utility function is calculated by every peer on each video, and for very popular videos and unpopular videos, their utility function values are small while the values for the videos of

Ye TIAN et al. Proxy caching for peer-assisted Internet VoD

moderate popularity are relatively large. Peers use the videos’ utility function values as the priorities for ordering prior to eviction. However, in PROP, information of exact number of video replicas cached by the P2P network is required, this is collected by a DHT-based overlay. In PopCap, such information is not available as the protocol does not rely on a DHT overlay. In addition, the continuous-valued utility function cannot effectively prevent peers from caching the videos that are already cached by the proxy. For example, suppose that a proxy can cache up to C videos, then for the Cth and C + 1th video, regarding the popularity, the utility function will assign values without a large difference, therefore peers cannot differentiate between them when making caching decisions. However, according to our optimal solution in Eq. (4), peers’ caching decisions on the two videos should be very different. By blocking a video with the blocking probability Pbi, peers can directly use the proxy’s caching decisions to make their own decisions. In our experimental study in Section 7, we will see that PopCap can better prevent peers from caching very popular videos. 6.5

Smart update mechanism

Finally, the timing of the protocol execution is arranged as the following: after every interval of T (T is a suitably long period of time, e.g., a week or a month), the proxy calculates Pi, UiProxy , and TTCi for each video. The proxy updates the values of Pbi and TTCi for each video at the times of T, 3T, 5T, …, and the proxy calculates Pi and Wi and updates its cache at the times of 2T, 4T, 6T, … In this way, the proxy and the peers update their caches asynchronously: the proxy updates its cache after the peers apply new blocking probabilities and priorities for an interval of T, while the new blocking probabilities and priorities are calculated after the proxy has updated its cached videos and has run for a time of T. In other words, the proxy and the peers give each other time to learn and update their caches based on each other’s least recent caching decisions. Furthermore, to reduce the traffic on the video server caused by the proxy cache updating, it is not necessary for the proxy to update at every scheduled time: the proxy can skip some of them. Specifically, after each update the proxy calculates the significance of the changes as SIG ¼ T 

M X ðsi  Wi  bi Þ, i¼1

where

( bi ¼

509

1, ci ðnowÞ – ci ðprevÞ ¼ 1, 0, otherwise:

Here, bi, is the label on whether or not video i is newly cached by the proxy, and SIG is an estimation of the benefit of updating the proxy cache. The proxy compares the SIG with the total traffic served by the video server during the recent interval of T as TRAF. Specifically, with a given threshold, if SIG < threshold  TRAF, the proxy doubles the update interval, e.g., from 2T to 4T, or from 4T to 8T, ..., etc; and if SIG > threshold  TRAF, the proxy halves the interval, until the interval becomes 2T. We refer to this mechanism as smart update of the proxy in the PopCap protocol.

7

Performance evaluation

In this section, we examine the effectiveness of the proposed PopCap protocol and compare it with existing solutions. An event-driven simulator is developed using C ++ for this purpose, and we use the YouTube sci and 0316 data sets, [9] and [10], as the video collection of the simulated Internet VoD system in our experiments. However, for the sci data set, only the most popular 20000 videos are used. In our simulation, time is divided into rounds. During a round, peers request videos according to their popularity, and download them from the proxy, the P2P network or the video server according to the Internet VoD protocol. For simplicity, we use the video length as the size of the video. For the videos on YouTube, the average video length is 185 seconds and we set the default proxy cache size to 2000 times the average video length, and set the default peer cache size to 5 times of the average video length. We also set the default total number of the online peers to 2000. We compare PopCap with PROP [8], which is a protocol for P2P-assisted proxies for large scaled VoD services. In PROP, a proxy caches the most popular videos according to the estimated popularity, and clients update their cached video replicas based on popularity. In PROP, a DHT overlay is organized by the clients, and for each video, there is a corresponding peer on the DHT network that stores the information on clients that currently cache each video, as well as the number of replicas currently cached by the P2P network. Although using the DHT technique to find a list of peers that is good enough for

510

Front. Comput. Sci. China 2010, 4(4): 500–515

locating a specific resource, and is commonly used in many P2P VoD systems, providing an accurate number of peers that currently cache the video is not easy, especially for Internet VoD. For example, when a client has finished playing a video, the peer may cache this video and evicts one or more previously cached videos, and the peer must report these events to the corresponding peers on the DHT network. As the average video length on YouTube is only 185 seconds and there are usually a large number of online users, there should also be a correspondingly large number of reports issued frequently by users of the system. Moreover, as the number of routing hops for a single report is O(logN) [25], when N is large, the delay of the peer reports becomes non-trivial. In other words, for Internet VoD using DHT techniques to obtain the accurate numbers of video replicas is impractical, and expensive. However, in PopCap, we do not need to know the accurate number of video replicas currently cached by the P2P network, rather, we only rely on information that can be easily collected as previously discussed in Section 5. In our simulation, we assume that accurate data is available on video replica numbers for PROP. 7.1

Reduction on server’s workload

In our first experiment, we compare PopCap with PROP and a simple caching protocol where both proxy and peers cache popular videos and perform cache updates using a least recently used (LRU) strategy, we call this PopLRU. We begin with the proxy randomly caching a number of videos, and the system evolves as the proxy and the peers update their caches. Periodically, we measure the traffic on the video server in serving videos to clients in the cases that the proxy and the P2P network fail to provide the video. We also measure the traffic caused by the proxy updating its cache. Figs. 4(a) and (b) shows how the two traffic patterns evolve with time under the different protocols. As exact file size are unavailable, we use total length of the files served by the server and downloaded by the proxy to indicate the server workload and the traffic coursed by proxy update, respectively. We can see from the Fig. 4(a) that of the three protocols, the traffic on the video server under PopCap is the smallest, while PROP outperforms the PopLRU strategy, which conforms to [8]. From Fig. 4(b), we can see that PopCap also has the smallest traffic caused by proxy updating, but the difference is not particularly significant. From Fig. 4 one can see that both PopCap and PROP have higher performance than the naive protocol of PopLRU, in the

Fig. 4 Distribution of (a) video server load and (b) proxy update traffic against time

remainder part of this section, we only focus on PopCap and PROP. We investigate how the videos are cached by the proxy and peers under the different protocols. During the simulation, each time the proxy is updated, for each video we record: 1) whether or not the video is cached, “1” if the video is cached, otherwise “0”; and 2) the number of peers that have this video cached. We refer to the record at the time of a proxy update as a snapshot. We record 50 consecutive snapshots, and by averaging these snapshots we can obtain the caching status of the video. Figs. 5 and 6 show the caching status of the 20000 videos under PopCap and PROP, where the x axis is the index of the videos, ordered according to popularity. For proxy caching, from Fig. 5 we can see that both PopCap and PROP can identify and cache the popular videos, however, in PopCap, we consider popularity as well as the probability of the video being actually streamed. In Fig. 6, one can see that peers under PopCap are able to avoid caching very popular videos, as these videos are more likely to be cached by the proxy, while under PROP, although low utility is assigned to very popular videos, peers still cache them, as these videos are requested frequently by peers; eviction alone cannot effectively

Ye TIAN et al. Proxy caching for peer-assisted Internet VoD

511

Fig. 5 Proxy caching status of the first 20000 videos in the sci data set under (a) PopCap and (b) PROP

Fig. 6 Peer caching status of the first 20000 videos in the sci data set under (a) PopCap and (b) PROP

reduce the number of replicas on the P2P network. To examine the effectiveness of the PopCap protocol in exploiting the proxy cache, we vary the proxy cache size and investigate the system performance, and compare it with the performance of PROP. We use both the YouTube sci and 0316 data sets in this experiment, and for the latter data set, all 42628 videos are used. The experimental results using the sci data set are shown in Fig. 7(a) and the results using the 0316 data set are in Fig. 7(b). From the two figures, one can see that when the proxy cache size is small, PROP outperforms PopCap. This is because when the benefit of proxy caching is not significant, by using the accurate information on the number of video replicas cached by the P2P network, PROP can make a better use of the peers’ cache space than PopCap. However, with the increase of the proxy cache size, PopCap outperforms PROP. This is because PopCap makes better use of the proxy cache than PROP, and more importantly, peers under PopCap can cooperate better with the proxy by avoiding caching videos that are also likely to be cached

by the proxy. We next consider the influence of peer cache size. In this experiment we also use the YouTube 20000 most popular video in the sci data set and the 0316 data set for simulation. Fig. 8 shows the traffic of the video server serving videos to clients across a range of peer cache sizes. Note a peer cache size of zero means that no peerassistance is used for Internet VoD, and when the peer cache size is 185 seconds we mean the case that users only share their currently playing video. From Fig. 8, we can see that PopCap has a better performance than PROP, but when the peer cache size is increased, the benefit becomes smaller. Compared with the PROP peer caching algorithm, peers under PopCap is benefit from the blocking by avoiding caching very popular videos, wheras PROP exploits the accurate information of the video replica number, which is assumed to be available in our experiment, therefore the advantage of PopCap over PROP is diminished when the peer cache size is large enough. To validate this point we also compare PopCap

512

Front. Comput. Sci. China 2010, 4(4): 500–515

Fig. 7 Video server’s uploading traffic under varying proxy cache size under PopCap and PROP, using (a) the sci data set, and (b) the 0316 data set

with a protocol where the proxy updates its cache using the PopCap algorithm while peers apply the PROP algorithm. In Fig. 8 we can see that first of all the difference between PopCap and the new protocol is not significant, indicating that without using the costly information of the video replica number, the performance of the PopCap’s peer algorithm is very close to the one of PROP. By carefully examining the figures, we can see that when the peer cache size is not very large, the PopCap algorithm is better than the PROP as peers under PopCap is able to avoiding caching the videos that are likely to be cached by the proxy, but when the cache is large enough, PROP algorithm is better as the costy information of the accurate video replica number is exploited. For such a large scale information service as Internet VoD, scalability is a very important property. To investigate how scalable the Internet VoD service is under different protocols, we vary the number of online peers and study system performance. In Fig. 9, we plot the load on the video server and proxy under different protocols when there are a varying number of online peers. We use the 20000 videos from the sci data set in this

Fig. 8 Video server load under varying peer cache sizes for PopCap, PROP, and PopCap proxy + PROP peer, using (a) the sci data set, and (b) the 0316 data set

experiment. From Fig. 9(a) one can see that with more and more users in the VoD service, the workload on the video server is increased, but thanks to the P2P network, the increase is non linear. Fig. 9(a) also shows that PopCap has a smaller workload on the video server than that of PROP at all times. In Fig. 9(b) we can see that PopCap also has a lower traffic load caused by proxy updates. 7.2

Effectiveness of smart update

In our previous experiments we have not enabled PopCap proxy’s smart update mechanism. In our final experiment we investigate the benefits of this mechanism. We use the sci data set in this experiment, and to emulate the dynamic scenario of the Internet VoD service, we randomly select 10000 videos for the system at the beginning of the experiment. During each interval, 50 randomly selected videos from those which remain are added until all videos are in the system. We vary the threshold parameter for doubling the proxy update interval, from Section 5, and perform the simulation. We plot the total video server load along side the traffic on the video server caused by the

Ye TIAN et al. Proxy caching for peer-assisted Internet VoD

513

Although for the requests of the ordinary clients and for the updating of the proxy, videos are downloaded from the video server, the cost for unit bandwidth may be different. For example, some ISPs apply different rates for traffic at peak times. The traffic caused by the user video requests is more likely to occur during peak time and the proxy could thus update during the off-peak times. Another example is that VSP may rent a CDN to update the proxies but users download directly from the server. When the unit bandwidth cost for the server/clients traffic and the server/proxy traffic is different, we examine the effects of the smart update mechanism from an economic stand point. We calculate the total bandwidth cost of the video server using the following expression cost ¼ ðserver↔ clientsÞ þ ratio  ðserver↔ proxyÞ,

Fig. 9 (a) Server Load and (b) proxy’s update traffic of peerassisted Internet VoD using PopCap and PROP under different system size

proxy updating in Fig. 10. From the figure, one can see that when the threshold is increased, the video server must serve more clients as the proxy is less sensitive to the changes of the video set and its popularity, but the traffic caused by proxy updating becomes lighter, as the proxy updates in a more lazy fashion.

Fig. 10 Video server load and proxy update load with varying threshold values for smart update

where ratio is the ratio of the cost for the unit “server↔clients” bandwidth (i.e., traffic between sever and clients) and the one of the “server↔proxy” bandwidth (i.e. traffic between server and proxy). We plot the overall cost under different thresholds applying varying ratios in Fig. 11. From the figure we can see that when the traffic cost ratio is getting larger, or proxy updating is not cheap, it is more economic beneficial to apply a larger threshold, that is, the proxy should updates more “lazily.” However, note that the threshold should not be too large, as suggested by the 6th curve in the figure, where the curve is above the 4th and 5th curves under all the cost ratios. This is because for a too large threshold, the proxy somewhat fails to capture the videos’ popularity dynamics.

Fig. 11 Overall bandwidth cost of the video server using PopCap’s “smart update” mechanism under different threshold and unit bandwidth cost ratio

514

8

Front. Comput. Sci. China 2010, 4(4): 500–515

Conclusion

7. Chen S, Shen B, Wee S, Zhang X. Segment-based streaming media proxy: Modeling and optimization. IEEE Transactions on Multi-

In this paper, we consider the newly emerging Internet video-on-demand streaming service and the problem of how to collaboratively use a proxy and a P2P network to cache and distribute the videos and reduce the workload on the video server. We have used two real-world data sets from YouTube to study the characteristics of the Internet VoD service. We have formally presented the video caching problem and obtained an optimal solution. Inspired by the modeling analysis, we have designed PopCap, a practical and inexpensive protocol for a proxy and peers in a P2P network to independently cache videos and cooperatively reduce the video server workload. Compared to existing solutions, PopCap requires less infrastructure support, incurs a smaller overhead, and is easier and more practical for deployment for an Internet VoD service. Finally, through experiments based on simulation using real-world data sets, we show that compared with existing solution, PopCap has a better performance regarding the reduction in traffic of the video server and proxy. Acknowledgements This work was supported by the Specialized Research Fund for the Doctoral Program of Higher Education of China (20093402120020), and the Fundamental Research Funds for the Central Universities (WK0110000007).

media, 2006, 8(2): 243–256 8. Guo L, Chen S, Zhang X. Design and evaluation of a scalable and reliable P2P assisted proxy for on-demand streaming media delivery. IEEE Transactions on Knowledge and Data Engineering, 2006, 18(5): 669–682 9. Cha M, Kwak H, Rodriguez P, Ahn Y Y, Moon S. I tube, you tube, everybody tubes: Analyzing the world’s largest user generated content video system. In: Proceedings of IMC’07, San Diego, CA, USA, Oct. 2007 10. Cheng X, Liu J. Nettube: Exploring social networks for peer-topeer short video sharing. In: Proceedings of IEEE INFOCOM’09, Rio de Janeiro, Brazil, Apr. 2009 11. Gill P, Arlitt M, Li Z, Mahanti A. Youtube traffic characterization: A view from the edge. In: Proceedings of IMC’07, San Diego, CA, USA, Oct. 2007 12. Guo Y, Suh K, Kurose J, and Towsley D. P2cast: Peer-to-peer patching scheme for vod service. In: Proceedings of WWW’03, Budapest, Hungary, May 2003 13. Do T T, Hua K A, Tantaoui M A. P2vod: Peer-to-peer patching scheme for vod service. In: Proceedings of IEEE ICC’04, Paris, France, Jun. 2004 14. Wang D, Liu J. A dynamic skip list based overlay for on-demand media streaming with vcr interactions. IEEE Transactions on Parallel and Distributed Systems, 2008, 19(4): 503–514 15. Cui Y, Li B, Nahrstedt K. oStream: Asynchronous streaming

References

multicast in application-layer overlay networks. IEEE Journal on Selected Areas in Communications, 2004, 22(1): 91–106

1. Almeroth K C, Ammar M H. The use of multicast delivery to

16. Tian Y, Wu D, Ng K W. A novel caching mechanism for peer-to-

provide a scalable and interactive video-on-demand service. IEEE

peer based media-on-demand streaming. Journal of Systems

Journal on Selected Areas in Communications, 1996, 14(6): 1110–

Architecture, 2008, 54(1–2): 55–69

1122

17. Ip A T S, Liu J, Lui J C S. Copacc: An architecture of cooperative

2. Huang Y, Fu T Z J, Chiu D M, Lui J C S, Huang C. Challenges,

proxy-client caching system for on-demand media streaming. IEEE

design and analysis of a large-scale P2P-vod system. In:

Transactions on Parallel and Distributed Systems, 2007, 18(1): 70–

Proceedings of ACM SIGCOMM’08, Seattle, Aug. 2008

83

3. USA Today, 2010. YouTube serves up 100 million videos a day

18. Hefeeda M, Saleh O. Traffic modeling and proportional partial

online. http://www.usatoday.com/tech/news/2006-07-16- youtube-

caching for peer-to-peer systems. IEEE/ACM Transactions on

views-x.htm

Networking, 2008, 16(6): 1447–1460

4. Carter L, 2010. Web could collapse as video demand soars. http://

19. Annapureddy S, Guha S, Gkantsidis C, Gunawardena D,

www.telegraph.co.uk/news/uknews/1584230/Webcould- collapse-

Rodriguez P. Exploring vod in P2P swarming systems. In:

as-video-demand-soars.html

Proceedings of IEEE INFOCOM’07, Anchorage, USA, 2007

5. Yen Y-W, 2010. YouTube looks for the money clip. http://techland.

20. Yu H, Zheng D, Zhao B Y, Zheng W. Understanding user behavior

blogs.fortune.cnn.com/2008/03/25/youtubelooks- for-the-money-

in large scale video-on-demand systems. In: Proceedings of

clip/

EuroSys’06, Leuven, Belgium, Apr. 2006

6. Huang C, Li J, Ross K W. Can internet video-on-demand be

21. Guo L, Tan E, Chen S, Xiao Z, Zhang X. The stretched exponential

profitable? In: Proceedings of ACM SIGCOMM’07, Kyoto, Japan,

distribution of internet media access patterns. In: Proceedings of

Aug. 2007

ACM Symposium on Principles of Distributed Computing

Ye TIAN et al. Proxy caching for peer-assisted Internet VoD

(PODC’08), Toronto, Canada, Aug. 2008 22. Hindi H. A tutorial on convex optimization. In: Proceedings of

515

24. Gross D, Harris C M. Fundamentals of Queueing Theory. 2nd ed. New York: John Wiley & Sons, Inc., 1985

2004 American Control Conference, Boston, MA, USA, Jun. 2004

25. Stoica I, Morris R, Karger D, Kasashoek M F, Balakrishnan H.

23. Zhang X, Liu J, Li B, Peter Yum T S. Donet/coolstreaming: A data-

Chord: A scalable peer-to-peer lookup service for internet

driven overlay network for live media streaming. In: Proceedings of

applications. In: Proceedings of ACM SIGMCOMM’01, San

IEEE INFOCOM’05, Miami, FL, USA, Mar. 2005

Diego, CA, USA, Aug. 2001