Hierarchically Clustered P2P Streaming System

Transcription

1 Hieachically Clusteed P2P Steaming System Chao Liang, Yang Guo, and Yong Liu Polytechnic Univesity Thomson Lab Booklyn, NY Pinceton, NJ Abstact Pee-to-pee video steaming has been gaining populaity. Howeve, it is still challenging to manage a p2p system efficiently to suppot high video playback ate. In this pape, we popose HCPS - Hieachically Clusteed P2P Steaming system that can suppot the steaming ate appoaching the optimum uppe bound with shot delay, yet is simple enough to be implemented in pactice. In HCPS, the pees ae gouped into clustes and a hieachy is fomed among clustes. By actively balancing the uploading capacities among clustes, and executing the pefect scheduling algoithm [1] within each cluste, the system esouce can be fully utilized. The simulation expeiments diven by the taces collected fom a eal p2p steaming system demonstate the effectiveness of HCPS. I. INTRODUCTION Video-ove-IP applications, e.g. Youtube [2], have ecently attacted a lots of uses on the Intenet. In addition to the taditional seve-client based o content distibution netwoks based solutions, Pee-to-Pee (P2P) video steaming solution utilizes the uploading bandwidth of end uses to distibute video content at low distibution cost. Seveal P2P based systems have been deployed to povide on-demand o ealtime video steaming ove the Intenet [3], [4], [5], [6]. Ou ecent measuement study [7], [8] on one popula P2P steaming system ecoded ove 200, 000 simultaneous uses watching a live boadcast of an event duing 2006 Chinese New Yea Eve. We expect to see moe P2P steaming systems and applications on the Intenet in nea futue. Accoding to the ovelay stuctue, P2P steaming systems can be boadly classified into two categoies: teebased and mesh-based. The tee-based appoach, such as ESM [3], has well oganized ovelay stuctue and typically distibutes video by actively pushing data fom a pee to its childen pees. One majo dawback of tee-based steaming systems is thei vulneability to pee chuns. A pee depatue will inteupt video delivey to all its descendant pees in the subtee ooted at the depated pee. In a mesh-based P2P steaming system, pees ae not confined to a static topology. Instead, the peeing elationship ae established/ton down based on the content availability and bandwidth availability on pees. A pee dynamically connect to a subset of andom pees in the system. Pees peiodically exchange infomation about thei data availability. Video chunk is pulled by a pee fom its neighbo who has aleady obtained that chunk. Thee ae a lot of mesh-based P2P steaming systems deployed ecently, such as CoolSteaming [4], PPLive [7]. Those systems ae vey obust to pee chuns. Howeve, the dynamic peeing elationships make the video distibution efficiency unpedictable. Consequently, uses suffe fom the video playback quality degadation, such as low video bit ates, long statup delays and fequent feezing. Ou measuement esults on PPLive [8] show that most pogams have bit ates aound 400bps and the stat-up delays fo a channel ange fom a few second to a few minutes. This makes them unsuitable fo pogams with high video bit ate and ealtime playback equiement. In this pape, we popose a novel P2P steaming achitectue that combines the best of tee-based and mesh-based systems to suppot high data ate video steaming with shot delays. The key to achieve this goal is to oganize pees in clustes such that the uploading bandwidth of pees can be efficiently utilized to edistibute video quickly to all pees. Due to bandwidth and content bottleneck [9], it is quite challenging to sustain high steaming ate fo all pees in a P2P steaming system. As studied in [1], the maximum video steaming ate in a P2P steaming system is detemined by the video souce seve s capacity, the numbe of the pees in the system, and the aggegate uploading capacity of all pees. A pefect scheduling algoithm is poposed to achieve the maximum steaming ate. In such a scheduling algoithm, each pee uploads the video content obtained diectly fom the seve to all othe pees in the system. To guaantee 100% uploading capacity utilization on all pees, diffeent pees download diffeent content fom the seve and the ate at which a pee downloads content fom the seve is popotional to its uploading capacity.

2 Figue 1 shows an example how the diffeent potions of data ae scheduled among thee heteogenous nodes with pefect scheduling algoithm. Thee ae thee pees in the system. The seve has capacity of 6. The upload capacities of a, b and c ae 2, 4 and 6 espectively. Suppose pees all have enough downloading capacity, the maximum video ate can be suppoted in the system is 6. To achieve that ate, the seve divides video chunks into goups of 6. a is esponsible fo uploading 1 chunk out of each goup while b and c ae esponsible fo upload 2 and 3 chunks within each goup. This way, all pees can download video at the maximum ate of 6. To implement S c a b Fig. 1. Pefect Scheduling Example such a pefect scheduling algoithm, each pee needs to maintain a connection and exchange video content with all othe pees in the system. In addition, the seve needs to split the video steam into multiple sub-steams with diffeent ates, one fo each pee. A eal P2P steaming system can easily have a few thousand of pees. With cuent opeating systems, it is unealistic fo a egula pee to maintain thousands of concuent connections. It is also challenging fo a seve to patition a video steam into thousands of sub-steams in ealtime. To addess this poblem, we popose HCPS - Hieachically Clusteed P2P Steaming system, to appoach the theoetical maximum video steaming ate with ealistic pee setting. In the poposed system, at the base level, all pees ae oganized into bandwidth-balanced clustes. Each cluste consists of a cluste head and a small numbe e.g , nomal pees. Cluste heads of all clustes fom a supe cluste at uppe level and etieve video fom the video souce seve in P2P fashion. Afte obtaining video at the uppe level, a cluste head acts as a local video souce seve fo nomal pees in its cluste at lowe level. Nomal pees within the same cluste collaboate accoding to the pefect scheduling algoithm to etieve video fom thei cluste head. In this new achitectue, the seve only distibutes video to cluste heads; a nomal pee only maintain connections to its neighbos in the same cluste; and a cluste head connects to both othe cluste heads and nomal pees in its own cluste. Two-level HCPS aleady has the ability to suppot a lage numbe of pees with mild equiement on the numbe of connections on the seve, cluste heads and nomal pees. By employing pefect scheduling at both uppe and lowe level, HCPS can appoach the theoetical steaming ate uppe bound. HCPS has mesh topologies at both levels, which makes it obust to pee chuns. Cluste heads play impotant ole in bidging the two levels. The depatue of a cluste head only affect a small numbe of pees in its cluste. As will be shown in Section II-B, HCPS cluste management mechanism ensues the quick ecovey fom cluste head depatues. In addition, in a basic configuation of HCPS, video data can each any pee within two hops. This lagely impove the delay pefomance upon nomal mesh-based solutions. The pape is oganized as follows. In Section II, we fist fomulate the maximal suppotable steaming ate poblem and deduce the pee clusteing stategy. Then we descibe in details the system achitectue and the pee management scheme. In Section III simulation esults ae pesented. In Section IV the conclusion and the futue wok ae included. II. HCPS: HIERARCHICALLY CLUSTERED P2P STREAMING SYSTEM As descibed in Section I, pefect scheduling achieves the maximum steaming ate by constucting a fully connected mesh among all paticipating pees and the souce. A pee then elays the eceived content fom the

3 souce to othe pees in the system. The tansmitting ate fom the souce to pee is calculated using max = min{u s, u s + n i=1 u i } (1) n whee u s efes to the upload bandwidth of seve and u i efes to the bandwidth of the ith node of total n nodes. Fo a p2p steaming system with a lage numbe of pees, the out-degee of pees becomes pohibitively lage. Hence the pefect scheduling algoithm does not scale well as the numbe of pees inceases. In this pape, we popose the hieachically clusteed p2p steaming (HCPS) scheme to addess the scalability issue faced by pefect scheduling algoithm. Instead of foming a single lage mesh, HCPS goups the pees into clustes. The numbe of pees in a cluste is elatively small so that the pefect scheduling can be successfully applied at the cluste level. One pee in a cluste is elected as the cluste head and woks as the souce fo this cluste. The cluste heads eceive the steaming content by joining anothe cluste that is one level above its own cluste in the system hieachy. Clustes fom a tee-like topology with clustes as vetices. The cluste heads seve as the links that connect two clustes. The steaming content is pushed fom the uppe-level clustes to the lowe-level clustes. S Cluste Heade Head Mapping 1 2 a1 a3 b1 b3 a1 a2 b2 b3 a3 b1 3 a2 b Fig Hieachically Clusteed P2P Steaming System 7 Figue 2 illustates a simple example of two-level HCPS hieachy. At the base level, pees ae gouped into small size clustes. The pees ae fully connected within a cluste. One pee is elected as the cluste head. At the top level, all cluste heads and the video seve foms two clustes. Video seve (souce) distibutes the content to all cluste heads using the pefect scheduling algoithm at the top level. At the base level, each cluste head acts as the video seve in its cluste and distibutes the downloaded video to othe pees in the same cluste, again, using the pefect scheduling algoithm. The numbe of connections on each nomal pee is bounded by the size of its cluste. Cluste heads additionally maintain connections in the uppe level cluste, i.e., the numbe of connections fo cluste heads could be doubled. Suppose that the cluste size is bounded by N max, and the souce can suppot up to N s top laye clustes. The two-laye HCPS system, as shown in Fig. 2, can accommodate up to N s (N max ) 2 pees. Assume N s = 10 and N max = 20, HCPS suppots up to 4,000 pee. The maximum numbe of connections a pee needs to maintain is 40 fo cluste head and 20 fo nomal pee, which is quite manageable. Moe pees can be accommodated by adding moe levels into the hieachy. A. Pee clusteing stategy The key question in designing HCPS is how to cluste the pees so that the suppotable steaming ate can be maximized. The maximum steaming ate, max, fo a given set of pees and the souce is detemined by Equation (1), and can be achieved using the pefect scheduling algoithm using fully connected mesh. The mesh constucted in HCPS is not fully connected, which may educe the maximum suppotable steaming ate. In the following, we investigate the pee clusteing stategies that would allow HCPS to suppot the steaming ate close to max. We fist fomulate the maximum suppotable steaming ate fo a given HCPS mesh topology as an optimization

4 poblem. We then discuss heuistic pee clusteing stategy that allows HCPS to have good suppotable steaming ate. 1) Maximal suppotable steaming ate fo a given mesh topology: Assume thee ae C clustes, N pees, and one souce in the HCPS mesh. Cluste c has V c pees, c, c [1, C]. Denote by u i the pee i s upload capacity. A pee can paticipate in a HCPS cluste eithe as a nomal pee o as a cluste head. Fo instance, in Fig. 2, pee a1 joins two clustes. It is the cluste head in cluste 3 and a nomal pee in cluste 1. Denote by u ic the amount of upload capacity of pee i contibuted to cluste c as a nomal pee, and by h ic the amount of upload capacity of pee i contibuted to cluste c as a cluste head. Hence u (a1)3 = 0, h (a1)3 0 since pee a1 is the head in cluste 3; and u (a1)1 0, h (a1)1 = 0 since pee a1 is a nomal pee in cluste 1. u (a1)c = h (a1)c = 0 fo all othe clustes since pee a1 is not thei membe. Futhe denote by u s the total souce upload capacity; and by u s c the amount of souce capacity used fo cluste c. Similaly, u s c = 0 if the souce does not paticipate in cluste c. If c max epesents the maximum steaming ate fo cluste c using pefect scheduling algoithm, the maximum suppotable steaming ate fo a given cluste-based HCPS mesh, HCP S, can be fomulated as following optimization poblem. subject to: HCP S = max c { max min [ max c c = 1, 2,..., C] } (2) {u ic,h ic,u s c} = min { N i=1 (u ic + h ic ) V c, N i=1 h ic + u s } c C (u ic + h ic ) u i (4) c=1 C u s c u s (5) c=1 whee Eqn. (3) is tue fo all c [1, C] and Eqn. (4) is tue all fo i [1, N]. The value of u ic, h ic, and u s c is detemined by the HCPS topology. The maximum suppotable steaming ate fo a given mesh topology is the the steaming ate that can be suppoted by all clustes. Since the cluste head paticipates in both uppe laye and lowe laye clustes and the souce s upload capacity is used by seveal top laye clustes, the suppotable steaming ate fo HCPS can be maximized by adjusting the allocation of clustes upload capacity and souce s upload capacity. This explains the Equation (2). The fist tem in Equation (3) epesents the aveage upload capacity pe pee in cluste c; and the second tem epesents the cluste head s upload capacity (note that cluste head can be eithe the souce seve o a pee). Since the maximum value of steaming ate at cluste c, c max is govened by the theoetical uppe bound (see Equation (1)), this leads to the Equation (3). Futhe, the amount of bandwidth allocated fo the uppe laye and low laye clustes must not supass its total upload capacity, which explains Equation (4). Finally, fo the souce, the total allocated upload capacity fo all clustes must not supass the souce s total upload capacity, which explains Equation (5). 2) Pee clusteing heuistics: The goal is to have a HCPS mesh topology that suppots the steaming ate close to the optimal ate max. In the following, we use numeical analysis to examine the majo factos that affects the HCPS s pefomance. Assume thee ae 400 pees with one souce node. The cluste size is set to be 20. The pees ae gouped into 20 base laye clustes and one top laye cluste fo cluste heads. The maximum suppotable steaming ate fo HCPS is computed accoding to the optimization poblem as fomulate in Equation (2). The pees upload capacity obeys the distibution as descibed in Table I. The distibution in Table I is fom the measuement study conducted in [10]. We fist assign bandwidth andomly to the 20 nodes of one cluste accoding to the bandwidth distibution, then copy the allocation to othe clustes. Hence all clustes have the homogeneous bandwidth allocation and the node with lagest upload bandwidth is selected as the cluste head. We solve the linea pogamming poblem. (3)

5 TABLE I BANDWIDTH DISTRIBUTION Uplink(kbps) Faction of nodes The solution shows that the value of HCP S is vey close to the theoetical uppe bound (> 99%). In contast, when each node has i.i.d. upload bandwidth accoding to the pobability distibution shown in Table I, HCP S only achieves oughly 60% of the theoetical uppe bound. In the fist scenaio, the clustes ae pefectly balanced (they ae actually the same); while in the second scenaio, they ae not. Accoding to Equation (2), the maximum suppotable steaming ate, HCP S, takes the minimum cluste steaming ate among all clustes. The cluste steaming ate (Equation (3)) is the minimum of cluste aveage upload capacity and the cluste head s ate. Intuitively, the pees should be divided into clustes with equal (simila) aveage upload capacity to avoid wasting esouces. Based on the above discussion, we popose following heuistics: The discepancy of individual clustes aveage upload capacity pe pee should be minimized. The cluste head s upload capacity should be as lage as possible. The cluste head s capacity allocated fo the base laye capacity has to be lage than the aveage upload capacity to avoid being the bottleneck. Futhemoe, the cluste head also joins the uppe laye cluste. Ideally, the cluste head s ate should be 2 HCP S. The numbe of pees in a cluste should be bounded fom the above by a elatively small numbe. The numbe of pees in a cluste detemines the out-degee of pees. A lage size cluste pohibits a cluste fom pefoming popely using pefect scheduling. Due to the pee dynamics, i.e., the pees join and leave the system all the time, HCPS mesh needs to be dynamically adjusted to have consistent high suppotable steaming ate. Below we descibe the dynamic pee management in HCPS that implements the above heuistics. B. Dynamic pee management HCPS system has a bootstap node whose task is to manage HCPS topology to balance the esouces among clustes. Meanwhile, a cluste head manages the pees in the cluste it belongs to. Due to the pee chun, the aveage upload capacity pe pee at cluste-level vaies ove time. Hence the suppotable steaming ates of clustes change and the system s suppotable steaming ate, HCP S, may decease. The bootstap node s task is to handle the new pee aival and pee depatue in such a way that HCP S is maintained at the highest possible level. In addition, because of the unpedictability of pee chun, the clustes steaming ates may still dift apat thus lowe down the system steaming ate. The bootstap node peiodically moves the pees aound to achieve good esouce balancing. Below we descibe thee key opeations in HCPS that handles the pee dynamics: pee join, pee depatue, and cluste e-balancing. 1) Pee join: Depending on the new aival s upload capacity compaed to the cuent HCP S, the new pee is classified into thee categoies: HPee(esouce ich pee) if u HCP S + δ, MPee(esouce medium pee) if HCP S δ < u < HCP S + δ, and LPee(esouce poo pee) othewise, whee u is new pee s upload capacity, and δ is a configuation paamete. Denote by N max the maximum numbe of nodes allowed by a cluste. All clustes whose numbe of pees is less than N max ae eligible to accept the new pee. If the upload capacity of the new pee, u, is geate than some eligible cluste heads upload capacity by a magin β, the pee is assigned to the cluste with the smallest cluste head upload capacity. The new pee is to eplace the oiginal cluste head, and the oiginal head becomes the nomal pee and stay in the cluste. If the new pee does not eplace any cluste head, it is assigned to a cluste accoding to the pee type. Specifically, the pee is assigned to the cluste with the minimum aveage upload capacity if the pee is HPee; the pee is assigned

6 to the cluste with the smallest numbe of pees if it is MPee; and the pee is assigned to the cluste with maximum aveage upload capacity if it is LPee. The idea behind this is to balance the upload esouces among clustes.the new pee is ediected to the coesponding cluste head, and bootstap node asks the cluste head to admit the new pee. In case the cluste is full afte the new pee joins, the cluste will split itself into two clustes and then infom the bootstap node. 2) Pee depatue: The handling of pee depatue is staight fowad. If the pee is a nomal pee, it infoms the cluste head of its depatue. The cluste head takes the pee off its cluste membe list, and infoms othe pees its depatue. In case the depating pee is the cluste head, the pee infoms the bootstap node its depatue. The bootstap node selects one pee fom existing pees in the cluste as the new cluste head. The eplacement pocess follows the same pocedue as we descibed in the above section. If a pee is cashed, the handling is the same fo the nomal pee. If the cluste head cashes, a pee in the cluste can infom the bootstap node. The bootstap node selects the pee with lagest upload capacity as the new cluste head. The bootstap node behaves as the cluste head, and let the selected pee to eplace itself to become the new cluste head. 3) Cluste e-balancing: The clustes may lose balance in tems of the numbe of pees and the amount of esouces in a cluste as the esult of pee chun. In HCPS, the bootstap node peiodically attempts to e-balance the clustes. At the end of an epoch, the bootstap node fist attempts to balance the cluste sizes. The clustes ae soted in the descending ode of cluste size. If the gap between the clustes with the lagest and the smallest numbe of pees is geate than the theshold = max{α N max, β N}, whee N is the aveage cluste size, these two clustes will be meged and then splitted into two balanced clustes. The above pocess continues until no clustes violates the condition. In the second phase of cluste e-balancing, the bootstap node ties to balance the esouces. The clustes ae soted in the descending ode of aveage upload capacity pe pee. If the aveage upload capacity diffeence of the clustes with highest and lowest upload capacity is geate than the theshold of θ u, whee u is the system aveage upload capacity, these two clustes will be meged and then splitted into two balanced clustes. 4) Cluste mege: The bootstap node infoms the two cluste heads the decision of mege, and indicate which cluste is to be meged. The meged cluste head un-egistes itself fom uppe laye cluste, and sends the membe list to the new cluste head. The new cluste head infoms all pees in the new cluste the membe list. Connections ae set up among pees. The new cluste head also e-calculates the sending ate using pefect scheduling. 5) Cluste split: The goal of cluste split is to divide the pees into two clustes that have oughly the simila numbe of pees and simila aveage upload capacity pe pee. The cuent cluste head manages the entie pocess. The cluste head sots the pees in the descending ode of upload capacity. The pee with the lagest upload capacity become the cluste head of the emeging new cluste. In the following ounds, two pees at the top of soted list ae taken out of the list. The one with the lage upload capacity is assigned to the cluste with smalle aggegate upload capacity; and the pee with smalle upload capacity is assigned to the cluste with lage aggegate upload capacity. The pocess continues until all pees ae assigned. If thee is only one pee in the last ound, then the pee is assigned to the cluste with moe aggegate upload capacity. Once the cluste membeship is decided, the new cluste head ceates the new cluste. It egistes itself into the uppe laye cluste, and then boadcasts the membe list to all pees. The cluste head computes the sending ate to each pee using the pefect scheduling. The oiginal cluste head also infoms the pees emaining in the cluste of the new membe list, and computes the new sending ate. C. System Delay Analysis The above pee dynamic management gives the HCPS self-adaptive ability to balance membe clustes in ode to achieve high steaming ate. We want to emphasize anothe inspiing meit of HCPS which is supeio to othe P2P steaming systems. Assume one node i needs to spend t s tansmission delay to delive one specified chunk to othe pee, then by pefect scheduling algoithm the last pee in the top level to eceive the data chunk will wait t p + N max t s time, whee t p is the popagation delay fom the seve to node i. Given the designed small numbe

7 N max and conventional popagation and tansmission delay, the delay in one cluste can be quite small. To the two-level HCPS system, the data chunk will encounte at most two such above pocesses to each all the pees of the system, because the pocess fo the nomal pee in the base level fetching data fom cluste head is simila as that of head fetching data fom seve. III. SIMULATION RESULTS In this section we use the tace-diven simulation to demonstate that HCPS is able to achieve the high suppotable steaming ate. A flow level simulato is developed to evaluate the system pefomance. The simulato models the dynamic pee management and peiodic cluste e-balancing exactly. Howeve, the data taffic is simulated at flow level. Such abstaction speeds up the simulation and still gives us accuate steaming ate of system. The simulation is diven by the tace collected fom the measuement study of PPLive, a lage scale p2p live steaming system [7]. We extact the infomation of pees aival and thei life time fom a one-day PPLive channel tace dumped at Apil 3, The upload capacity of pees ae assigned andomly accoding to the distibution of Table I. We choose the peiod of cluste e-balancing to be one minute and the seve upload capacity is set to be 2Mbps. Fig. 3 depicts the numbe of pees in the system ove the peiod of 24 hous. Pee chun is evident in this figue. The Node Degee Fig Time(h) One-day Degee Evolution of Popula Channel numbe of pees peaks aound 9:00AM-12:00PM when the system has moe than 200 concuent uses. 1) HCPS suppotable steaming ate: Fig. 4 plots the HCPS steaming ate vs. theoetical uppe bound using pefect scheduling algoithm duing the peak hou (9:00AM-12:00PM) with two e-balancing theshold settings. Both cuves of HCPS steaming ate follow the tend of pefect scheduling steaming ate closely. The oscillation of pefect scheduling steaming ate is due to the upload capacity change caused by pee chun. The oscillation of HCPS steaming ate is due to the following two easons: (i) the upload capacity change due to pee chun; and (ii) the esouce imbalance among HCPS clustes due to chun. While the fist facto is caused by the natue of p2p system, the second facto can be mitigated by adjusting the e-balancing configuation paametes. Fo instance, in Fig. 4(a), the e-balancing paametes (see Section II-B.3) ae set to be α = 0.2, β = 0.4 and θ = 0.4; while the paametes used in Fig. 4(b) ae α = 0.15, β = 0.3 and θ = 0.3. Tighte theshold helps HCPS to impove the steaming ate a little bit as shown in Fig. 4(b). Howeve, the tighte theshold inceases the e-balancing ovehead. In pactice, the paametes have to be caefully toned to stike the ight balance between management ovehead and system pefomance. To bette undestand the pesistent pefomance, Table II epots the aveage steaming ate ove a fou hou peiod duing the day. In the table, the e-balancing theshold setting of HCPS is the same as in Fig. 4(a), so ae the following simulation esults. The HCPS steaming ate is within 90% of the theoetical uppe bound all the time. 2) Pefomance in suppoting fixed ate steaming: Constant-bit-ate (CBS) coding is typically used in on-line steaming sevice. In this section, we examine how HCPS pefoms in suppoting CBS content. Fig. 5 depicts the faction of uses that can watch the content at the given ate. Almost all uses in HCPS can steam video up to

8 HCPS Pefect HCPS Pefect Playback Rate Playback Rate Time(m) Time(m) (a) α = 0.2, β = 0.4 and θ = 0.4 (b) α = 0.15, β = 0.3 and θ = 0.3 Fig. 4. Rate Evolution in Peak Time TABLE II AVERAGE RATE PER TIME ZONE Time Zone(h) Pefect(kbps) HCPS(kbps) kbps. With the cuent encoding technology, the on-line content uses steaming ate in the ange of 400 kbps to 800 kpbs. Hence HCPS is able to suppot most uses in this ange. As the steaming ate inceases futhe, less uses can sustain full ate. The faction of full-ate uses deceases quickly as shown in Fig. 5. This is because HCPS maximizes the steaming ate by balancing the suppotable steaming ate of individual clustes. Once the fixed steaming ate supasses HCPS suppotable ate, most of clustes steaming ates become smalle than the fixed ate, which explains the apid decease of numbe of uses that can suppot full ate. Howeve, the faction of content eceived by uses deceases moe gadually as shown in Fig. 6. Table III futhe gives the esults of aveage faction of eceived content fo diffeent CBS steaming ate using HCPS and pefect scheduling. Again, HCPS appoaches the pefomance of pefect scheduling algoithm. Above esults suggest that TABLE III AVERAGE RATIO UNDER DIFFERENT PLAYBACK RATE Fixed Playate(kbps) Pefect(%) HCPS(%) using advanced coding technique, such as laye coding o multiple-desciption coding, may be a good way to combat the tempoay lack of upload esouces in system. IV. CONCLUSIONS In this pape, we poposed hieachically clusteed p2p steaming (HCPS) famewok that is capable of fully utilizeing uses upload capacity and appoaching the maximum steaming ate allowed by the system. The small size of cluste enables the use of pefect scheduling algoithm; and the hieachy makes the accommodation of lage numbe of uses possible. We fomulate the maximum steaming ate in HCPS as an optimization poblem, and popose distibuted potocol to appoximate the optimal solution. As the esults fom tace-diven simulation demonstate, the aveage suppotable steaming ate by HCPS is within 10% of the maximum steaming ate. As to futue wok, we ae inteested in implementing HCPS and testing it out in the eal wold. We ae also looking into ways to futhe simplify the implementation of pefect scheduling algoithm.

9 Pecentage of Suppotable Nodes Fig. 5. Time(m) Pecentage of suppotable nodes in HCPS 1 Faction of Received Content Fig Time(m) Aveage faction of eceived content in HCPS REFERENCES [1] R. Kuma, Y. Liu, and K. Ross, Stochastic Fluid Theoy fo P2P Steaming Systems, in Poceedings of IEEE INFOCOM, [2] Youtube, Youtube Homepage, [3] Y.-H. Chu, S. G.Rao, and H. Zhang, A case fo end system multicast, in Poceedings of ACM SIGMETRICS, [4] X. Zhang, J. Liu, B. Li, and T.-S. P. Yum, DONet/CoolSteaming: A data-diven ovelay netwok fo live media steaming, in Poceedings of IEEE INFOCOM, [5] PPLive, PPLive Homepage, [6] PPSteam, PPSteam Homepage, [7] X. Hei, C. Liang, J. Liang, Y. Liu, and K.W.Ross, Insights into PPLive: A measuement study of a lage-scale P2P IPTV system, in Poc. Wokshop on Intenet Potocol TV (IPTV) sevices ove Wold Wide Web in conjunction with WWW2006, [8] X. Hei, C. Liang, J. Liang, Y. Liu, and K. Ross, A Measuement Study of a Lage-Scale P2P IPTV System, IEEE Tansactions on Multimedia, [9] C. Gkantsidis and P. R. Rodiguez, Netwok Coding fo Lage Scale Content Distibution, in Poceedings of IEEE INFOCOM, [10] C. H. Ashwin R. Bhaambe and V. N. Padmanabhan, Analyzing and Impoving a BitToent Netwok Pefomance Mechanisms, in Poceedings of IEEE INFOCOM, 2006.