Providing Hierarchical Lookup Service for P2P-VoD Systems · 5
4. DESIGN OF MEDIACOOP
In this section, we first address the importance of the end-to-end delay for P2P-VoD and give the
method of how to obtain the delay in Section 4.1. Then we present the finger tables utilizing the
distance of playpoint and IP prefix in Section 4.2. How to conduct lookup operation using the finger
table is shown in Section 4.3. Finally, in Section 4.4 we describe the maintenance of Mediacoop.
4.1 Exploit Network Properties
In real-time media systems, lower end-to-end delay leads to less waiting time and hence improves
the interactivity [Liu 2007; Noh et al. 2008; Ren et al. 2006]. Especially in VoD services, the user
interactivity frequently happens [Huang et al. 2008], and the large delay between peers results in
long response time. Therefore, the end-to-end delay is adopted to measure the network property of
supplying peers. One might argue how to get the exact value of the end-to-end delay, because it
varies with time. In practice, we only need to record the average delays for different candidates, and
choose the smaller ones as suppliers. So we do not require the exact value of the delay. Then the
question is how to get the end-to-end delay. The Internet is composed of many Autonomous Systems
(ASes). Peers within one AS are usually close to each other and inter-AS routing is specified by
Border Gateway Protocol (BGP). Thus, we only need to know the AS-AS delays or cluster level
delays and choose suppliers from those clusters whose delay is the least with the initiator. We use
the method proposed in [Ren et al. 2006] to construct the AS topology and obtain AS-AS delays.
A sketch of the method is briefly described as follows (cf. [Ren et al. 2006] for more details).
Firstly, we collect a large number of public BGP routing tables and BGP updates, such as those
from RouteViews [RouteViews 2010] and RIPERIS [RIPERIS 2010]. From these routing tables, we
build an AS graph and group IPs with the same longest prefix into one cluster. Then, we randomly
choose one IP out of each cluster as the cluster delegate. A delay measurement between each pair of
cluster delegates can be estimated by the tool King [Gummadi et al. 2002]. Finally, we obtain two
tables: (1) IP to cluster mapping table (ICMT); (2) Cluster to cluster delay table (CCDT). From
ICMT, a p eer can learn about its own cluster, and get the target clusters from CCDT, which has
the least delay with itself. Fig. 3 illustrates the work procedure of the delay detector, and Table
I shows a CCDT example in CoolFish [CoolFish 2011]. In Mediacoop, the delay detector program
runs and updates ICMT and CCDT all the time. When a peer joins the system, it gets ICMT and
CCDT from the probing server. In order to prevent frequent requests in normal lookup operations,
the peers will ask the server to update ICMT and CCDT at intervals. Now, the key problem is how
to organize these clusters to provide efficient lookup.
tool
( C C D T )
Cluster-Cluster delay table
( I C M T )
IP-Cluster mapping table
IPs in P2P network
BGP tables & updates
Fig. 3. Cluster (IP prefix) level delay detector. Using this detector we can get the global tables: ICMT and CCDT.
Table I. CCDT of CoolFish. Time: 15:00, 2/9/2009.
Delay from X to Y 159.226.40.* 202.127.200.* 210.72.15.* . . .
159.226.40.* 0 31(ms) 8(ms) . . .
202.127.200.* 31(ms) 0 58(ms) . . .
210.72.15.* 8(ms) 58(ms) 0 . . .
. . . . . . . . . . . . . . .
ACM Transactions on Multimedia Computing, Communications and Applications.