DHT Based Collaborative Multimedia Streaming and Caching Service *

Transcription

1 DHT Based Collaborative Multimedia Streaming and Caching Service * Zuoning Yin, Hai Jin Cluster and Grid Computing Lab Huazhong University of Science and Technology, Wuhan, , China hjin@hust.edu.cn Abstract Multimedia streaming and video on demand (VoD) services are among those hottest applications over the Internet. Traditional client/server pattern is stumbled due to the lack of scalability and limitation of service capacity. Peer-to-Peer paradigm has been introduced to solve these issues. The key idea is that peers not only receive multimedia stream but also serve multimedia data to others. In this paper, we present a novel scheme that builds a multimedia streaming and caching service on a distributed hash table (DHT) based overlay. We adopt DHT to establish a decentralized caching service. The location information of cached segments is distributed among different peers and the information about segments from the same video is organized into an applicationlevel multicast group. We also propose a cache replace algorithm on each peer. In our simulation, our design achieves good scalability with a low service reject rate. Besides, good load balance is also achieved as well as desired quality-of-service. 1. Introduction Multimedia streaming over Internet is challenging due to number of factors such as stringent requirements for bandwidth, latency, and quality-of-service. Intensive researches have been conducted from different perspectives to tackle these problems, such as source coding and channel coding, IP multicast and content delivery network (CDN). However these approaches all expose the deficiency in scalability. In order to scale well and remove the bottleneck effect, peer-to-peer paradigm has been introduced. In all the designs based on peer-to-peer patterns, peers not only receive multimedia stream but also serve cached multimedia data to others. However, those techniques differ in the actual design and implementation. Most of them are live streaming * This work is supported by National Science Foundation of China under grant No systems. For these systems, users watch the same content simultaneously and sequentially. The current playing position for each user is almost the same. However, there is another kind of peer-to-peer streaming systems, the peer-to-peer VoD systems. In this kind of systems, the using scenario is more complicated. Users may request different contents asynchronously and their current playing position may vary a lot. Moreover, users may not have a sequential watching behavior and they may jump forward or backward to watch their desired parts. This discrepancy makes the design of a peer-to-peer VoD system more difficult. There are two important problems need to be considered when designing such a system: In a peer-to-peer VoD system, peers request for multimedia data not only from server, but also from other peers. Hence there must be a search and locating mechanism to help peers find the data they need among other peers. Due to the asynchronous watching pattern and the interactive behavior (forward/backward, pause) of users, the range and the type of requested multimedia data are various and dynamic. Therefore there should be a sophisticated data dissemination strategy to distribute data properly on different peers. The motivation of this paper is to build a peer-topeer VoD service in a corporate LAN type environment, located in a single geographical region. Our design goal is to greatly amplify the service capacity by adopting the peer-to-peer paradigm and providing good quality-of-service at the same time. In our design, a VoD server and all the peers participating in the streaming are organized in a DHT based overlay. Videos are segmented and participant peers contribute their storage space to cache the received segments. The core part of the peer-to-peer VoD system is a distributed cache service which is responsible for the management and coordination of the index information of cached segments. Peers locate the requested multimedia data via the DHT search mechanism. After having located the data, we select desired supplier

2 according to a proximity principle to achieve good quality-of-service. Moreover, we propose a cache replacement algorithm which not only considers both inter-movie and intra-movie popularity, but also adapts to the dynamics of user s demand. On condition that each peer can only contribute limited cache space, the algorithm takes full use of limited cache space to cache more popular and more useful segments. To our knowledge, we are the first to adopt DHT into the design of a peer-to-peer VoD system and we hope our work can provide valuable information for others in the future design of such systems. The rest of our paper is organized as follows. Section 2 introduces some related works. In section 3, we describe the DHT based distributed caching service. In section 4, we discuss the locating and streaming processes. In section 5, we discuss the cache replacement algorithm. We come to the simulation in section 6. Finally, we conclude this paper and propose some future expectations in Section Related Works A peer-to-peer multimedia streaming and caching service is proposed in [1][2]. They cache video segments on participant peers. The core of their design is a centralized cache service to maintain the information about the peer clients, video segments they cached, and quality of connections. This approach is similar to Napster [3] which employs a centralized index server. However the centralized cache service is a new bottleneck and a single point of failure. A distributed streaming service on a Gnutella network is built in [4]. The flooding search mechanism is adopted to locate the requested multimedia data. The streaming processes use a many-to-one strategy to achieve good quality of service. However relying on the flooding search mechanism makes this method neither scalable nor efficient in a large size network. The many-to-one streaming method is also used in [5]. Moreover, an algorithm to amplify the system s total streaming capacity is proposed in [5]. In [6], a patching technique is used on an application-level multicast tree to save the network bandwidth. However the appropriate value of threshold is hard to choose. The small threshold gives low disruption rate, but a relatively small session size. While with a large threshold, the disruption rate will rise and view quality will drop. Moreover this design assumes that a number of stable users are watching the same movie simultaneously, which may not match the practical user behavior. We will compare our design with the patching method in Section 6. A similar design has been proposed in [12], but they focus on using DHT to solve the problem in web caching. Our scenario is different from theirs, therefore different issues should be considered. 3. Distributed Cache Service In our system, we assume that videos are segmented and all the peers have some storage space to cache the received segments. Therefore, in every peer cache, there are a number of segments. The cache service is responsible for storing the information where a certain segment locates and it is fully distributed without a central control point. Every peer can be a part of the whole service. The distributed cache service is built on a DHT based overlay. 3.1 DHT based Overlay DHT based overlay is quite prevalent in the research literature. It uses precise placement algorithms and specific routing protocols to search. Nodes are organized in a logic structure and every peer, file, item or the object are associated with a unique id generated by a hash function. The search is based on the matching of the unique id step by step. According to [7][8][9], the average search hop is about O(logN), where N is the size of the overlay. The search mechanism of DHT has following advantages: 1) the average search length is relative short; 2) the search is a deterministic search, which means that after the search operation, whether an object exists in the system is clearly known. This is no guarantee in an unstructured peer-to-peer overlay; 3) the search is neither a blind search nor enforced in a flooding pattern, so the message traffic can be reduced. In this paper, we use a Pastry-like [8] substrate as our overlay. Our assumption is that the participants in the multimedia streaming are organized in a DHT based overlay, a peer s join, leave, and the search operation should also be conformed to the DHT protocol. 3.2 The Roles of Peers In our system, the roles of the participant peers can be classified into three catalogs: Rendezvous Peers, Root, and ordinary peers. Among all the peers, Rendezvous Peers and Root are the core components of the distributed cache service. 1) Rendezvous Peer According to above discussion, videos are divided into segments. We also divide a video into a few parts, called Unit. Every Unit is made up of a number of segments. Each unit has a corresponding Rendezvous

3 Peer (RP). A RP is a peer whose id is closest to the hash result of the video s name and the Unit s location in the video. RP is responsible for preserving the location information of all the segments of its corresponding Unit. For instance, if the name of a movie is Star War and the Unit is the 5 th Unit in the movie, we compute the hash value of Star War 5 th. If the hash result is 1D356FA, a DHT search for 1D356FA is issued. According to the characteristics of DHT, we will definitely find a peer whose id is closest to 1D356FA in the id space after the search. This peer, assuming that its id is 1D356F2, is assigned to be the RP of the 5 th Unit of the movie. 2) Root Root is a peer responsible for preserving the global information of the peers that are watching the same movie simultaneously. It documents information such as the number of total audience. The assignment of Root is similar to that of RP. The difference is that the Root is a peer whose id is closest to the hash result of the movie name. Root is helpful in the process of cache replacement. 3) Ordinary Peers Ordinary peers are peers neither RP nor Root. 3.3 The Architecture A video is made up of a few Units. It also has the same amount of RPs. Besides it has a peer as its Root. The Root and RPs together constitute the distributed cache service. The architecture of the service has two primary features: 1) The Root and RPs are organized into a multicast group. A reverse path technique [10] is used to create the group. The multicast group is used to disseminate global information from the Root to RPs, which is designed for the cache replacement; 2) All the RPs of a video are also organized in a link list according to their temporal sequence within the playing time of that video. This design aims to reduce the search operation and locate the segments quickly. For instance, if a video clip M has 8 Units, then it has 8 RPs and a Root. The architecture is shown in Fig.1. Fig.1 also shows the actual location of the RPs in the id space of the DHT. For example, RP 3 is the peer with id 0D3 in the actual id space and the Root is the peer with id 9B5. Due to the characteristics of DHT, these RPs are evenly distributed over the id space with good load balance. Fig.1. Architecture of distributed cache service 4. Locating and Streaming Locating and streaming are two main processes in peer-to-peer VoD service. We propose a registration protocol to report the location information of segments to the corresponding RP and a search protocol to retrieve the location information of requested segments. After obtaining the information, a proximity principle is used to choose the desired suppliers. 4.1 Registration and Search Protocol The registration and the search operations are enforced via a location table. The location table is a key data structure of our system and deployed on every RP. The table consists of two parts: the top part and the bottom part. The top part is made up of m columns and n rows. The entry in the i th column and the j th row is the j th location of the i th segment of the associate Unit. In the bottom part, for every segment S i, there is a GRN i representing its global replica number. The entry called GRN 0 stands for the expected global replica number of all the segments in the Unit. The entry An i stands for the access number which records the total access to the associated Unit. Besides, there is an entry called NEXT_RP which is the pointer to the subsequent Unit in the temporal sequence. If a peer is the RPs of units from different videos simultaneously, it will have multiple location tables, one for each video. A typical location table of a

4 RP is shown in Fig.2. Fig.2. An example of location table As shown in Fig.2, the first segment in this Unit, S 1, has 5 candidate locations, they are Peer 213, Peer 10D..Peer 057, where 213 and 10D are the ids of peers. The value of GRN 1 is 5. S 3 has 3 candidate locations, so GRN 3 is 3. We also notice that NEXT_RP is pointing to the Peer 055. GRN 0 is 6, which means the expected global replica number of all the segments in the Unit. The An i with a value 204 means that 204 users had requested the segments in this Unit. When a peer caches some segments, it sends a registration message to the corresponding RP. Peer x RP: MSG_REG(S l, S u, Peer x ) S l is the starting segment of the cached segments and S u is the ending segment. Peer x is the peer that holds those segments. When RP receives this message, it updates the location table. First it adds the Peer x to the entry on the (GRN i +1) th row (l<=i<=u) and the i th column. Then it adds the GRN i by 1. When a peer requests for a certain segment, it first decides which Unit the segment is belonged to. Then it contacts the Unit corresponding RP, which is in fact a DHT search operation querying for the hash result of the video name and the Unit location in the video. After finding the RP, the peer sends a search message to it. Peer RP: MSG_SEARCH(S l ) This means that the peer is requesting for the segment starting from S l. When RP receives the search message, it sends the whole location table to the peer. This design aims to reduce the communication between ordinary peers and RP. Because when the peer continues to request the subsequent segments of that Unit in the near future, it need not contact the RP any more. If the peer continues watching the video, he may request the segment belonged to the next Unit. In this case, NEXT_RP will help the request peer find the next Unit RP faster without enforcing another DHT search. 4.2 Supplier Selection and Streaming When a peer gets the locations of requested segments, it selects desired suppliers for the segments. The selection is based on an IP to Landmark Database (ITLD), which stores the mapping from IP to landmark. ITLD is pre-built and integrated into the client-side software. Landmark is a network coordinate with a 128-bits integer encoded by 5-layers geometrical information: inter-country level, inter-isp (Internet Service Provider) level, WAN (Wide-Area Network) level, MAN (Metropolitan-Area Network) level, and LAN (Local-Area Network) level. For each level, the landmark value is generated by the corresponding geometrical or network (i.e. ISP) information, where the geometrical and network information can be configured by users themselves or obtained from some free IP-to-Geometrical-Address databases. According to the rule, the peers adjacent in landmark space are adjacent in physical network with a high probability. Then we just calculate the difference of the landmark value between the initial peer and the potential suppliers. A potential supplier that generates the minimum difference is chosen as the best supplier. This can be regarded as a static schedule strategy. Though the selection is based on the dynamic probing of the network status (bandwidth, delay), dynamic schedule approach is difficult to implement. After the peer has selected a supplier, it connects to the supplier directly. Usually the supplier caches not only that segment, but the subsequent ones. So the request peer need not switch to a new peer until the supplier does not have the requested segments any more. If the supplier does not have the requested segments, the peer looks up the location table retrieved from the RP. If the location information of requested segments is still on the RP, the peer will select a new supplier with those segments. If the requested segments are not within the RP, the peer will contact the successive RPs to find the desired supplier. In order to avoid the delay jitter, pre-fetching technique is used in our system. When the peer is playing the streaming data, the subsequent segments are pre-fetched. 4.3 Fault Tolerance and Availability The dynamic join or leave of peers will cause disturbance on the overlay. If a potential supplier in the location table fails, the subsequent access to this supplier may be ineffective. Then the first peer that detects the failure of the supplier is responsible for reporting this to the corresponding RP. The RP will then remove the failed supplier in the location table. If the peer which is a RP or the Root fails, the distributed cache service will be undermined. However, the DHT substrate usually has an inner repair mechanism that can reduce the suffered damage. Besides, we also have

5 our fault tolerant mechanism: a RP periodically transfers its states to k peers which are closest to it in the id space. So when the RP fails, according to the characteristics of DHT, one of the k closest peers will take its place automatically. Furthermore, with the multi-locations in the location table sent back by the RP, when the target peer of the segment fails, the user still has backups to choose. With the above mechanism, the negative effect can be minimized. 5. Cache Replacement Algorithm The key idea of the algorithm is based on GRN, which is affected by the size of audience Total, intramovie popularity r and inter-movie popularity R. A RP periodically reports the access number An to the Root. Hence the Root can calculate intra-movie popularity r like this: An i 0 ri = f 1, ri An i i where r 0 i is the intra-movie popularity calculated in the last period of time and f 1 is a prediction function. The inter-movie popularity R is maintained by the VoD server. The server periodically contacts the Roots of the current active videos to retrieve their Total. Then it calculates R like this: Total i 0 R i = f 2, R i Total i i where R 0 i is the inter-movie popularity calculated in the last period of time and f 2 is another prediction function. In Fig 2, there is an entry called GRN 0, which stands for the expected global replica number of the segment within the unit. We calculate GRN 0 as: ri Total i GRN = β 0 C avg where C avg is the average serving capacity of a peer and β is a constant. When a segment S i is ready to be cached, the peer contacts the associated RP of the segment. The RP checks its state, if GRN i >=GRN 0, the segment will not be cached. While if GRN i <GRN 0, the segment will be cached. If the cache is already full and a new segment comes, a victim will be selected and evicted out of cache. We use a modified Least-Recently-Used (LRU) algorithm to direct the cache replacement. To choose which segment to evict depends on both the use frequency and inter-movie popularity R, we have the following expression: R i w 1 +Fre(S i ) w 2 where w 1, w 2 are the weight constants, Fre() is the frequency function. We calculate the expression of all the segments in the cache and the segment with minimal value will be evicted out of cache. The Roots and the VoD server form a multicast group, thus the server can periodically broadcast the information of inter-movie popularity R to all Roots. In the same manner, a Root periodically broadcasts R and Total to its subordinate RPs in the multicast group. This algorithm can adapt to the dynamics of user s demand and take into account both inter-movie and intra-movie popularity. On condition that every peer can only contribute limited cache space, the algorithm takes full use of limited cache space to cache more popular and more different segments. 6. Simulation Experiments In order to test our DHT based peer-to-peer VoD service, we build up a simulation environment. The underlying network topology used in our experiments is generated by GT-ITM [11] in the Transit-Stub fashion. There are 500 nodes in our simulation. They are distributed in 2 transit networks and 20 stub domains. We assign link latencies of 150ms for intertransits domain links, 100ms for intra-transit domain links and 50ms for stub-transit links and 20ms for intra-stub links. The bandwidth of core links is set to 1Gbps and that of edge links is 100Mbps. We assume that the service request arrival rate is conformed to a Poisson distribution with parameter λ. The length of a video is T and each video has the same length as well as the bit rate. Hence we get the workload as λt. In our simulation, we use a normalized workload. Fig.3 shows the service reject rate in different situations. There are four situations: 1) unicast (C/S); 2) patching with a 5 minutes threshold; 3) patching with a 10 minutes threshold; and 4) DHT. With the increasing of the normalized workload, the service reject rate of unicast mode increases rapidly. The patching mode with a 5 minutes threshold has a higher service reject rate than that with a 10 minutes threshold. This is because longer threshold can admit more users in a single session, which reduces the service reject rate. The DHT mode is exempt from the limitation of threshold. So it yields the lowest service reject rate, which proves good scalability. Fig.4 shows the normalized load divergence in different situations. This metric gives us information about load balance of different peers. A low normalized load divergence stands for a good load balance. As shown in Fig.4, the DHT mode achieves

6 the best load balance. This is because in DHT the load is distributed evenly among all the peers in the id space. In patching mode, most load is distributed on the peers that are close to the root of the multicast tree. Therefore the load in patching method is relatively skewed. Fig.3. Service reject rate in different situations Fig.4. Normalized load divergence in different situations 7. Conclusion and Future Work Our DHT based collaborative multimedia streaming and caching service shows good scalability against the growth of workload. Moreover, it achieves desirable quality-of-service with low delay jitter. It also yields a nature load balance due to the characteristics of DHT. In the future, we will study the relationship between the cache size of peer and the overall system performance. Besides, we also plan to propose a more sophisticated cache replace algorithm in order to optimize the dissemination of the multimedia data. References [1] W. J. Jeon and K. Nahrstedt, Peer-to-Peer Multimedia Streaming and Caching Service, Proceedings of the IEEE International Conference on Multimedia and Expo (ICME 02), Vol.2, pp [2] W. J. Jeon and K. Nahrstedt, QoS-aware Middleware Support for Collaborative Multimedia Streaming and Caching Service, Microprocessors and Microsystems, Special Issue on QoS-enabed Multimedia Provisioning over the Internet, Elsevier Science, December, [3] Napter, [4] D. Jiang, Y. Dong, D. Xu, and B. Bhargava, Gnustream: A P2P Media Streaming System Prototype, Proceedings of the IEEE International Conference on Multimedia and Expo (ICME 03), July 2003, Vol.2, pp [5] D. Xu, M. Hefeeda, S. E. Hambrusch, and B. K. Bhargava, On Peer-to-Peer Media Streaming, Proceedings of the 22nd International Conference on Distributed Computing Systems (ICDCS'02), July 2-5, 2002, Vienna, Austria. [6] Y. Guo, K. Suh, J. Kurose, and D. Towsley, P 2 Cast: P2P Patching Scheme for VoD Service, Proceedings of the Twelfth International World Wide Web Conference (WWW 03), Budapest, Hungary, May [7] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, Chord: A scalable peer-to-peer lookup service for internet applications, Proc. of ACM SIGCOMM, San Diego, California, Aug [8] A. Rowstron and P. Druschel, Pastry: Scalable, Distributed Object Location and Routing for Largescale Peer-to-Peer Systems, Proceedings of International Conf. on Distributed Systems Platforms (Middleware), Heidelberg, Germany, Nov [9] C. G. Plaxton, R. Rajaraman, and A. W. Richa, Accessing Nearby Copies of Replicated Objects in a Distributed Environment, Theory of Computing Systems, 32: , [10] A. Rowstron, A.-M. Kermarrec, M. Castro, and P. Druschel, Scribe: The Design of a Large-scale Event Notification Infrastructure, Proceedings of the third International Workshop on Networked Group Communications, London, UK, Nov [11] E. Zegura, K. Calvert, and S. Bhattacharjee, How to Model an Internetwork, Proceedings of IEEE INFOCOM, April [12] S. Iyer, A. Rowstron, and P. Druschel, Squirrel: a Decentralized Peer-to-Peer Web Cache, Proceedings of the Twenty-First Annual ACM Symposium on Principles of Distributed Computing, California, USA, July 21-24, 2002.