AngelCast: Cloud-based Peer-Assisted Live Streaming Using Optimized Multi-Tree Construction

Transcription

1 AngelCast: Cloud-based Peer-Assisted Live Streaming Using Optimized Multi-Tree Constrution Raymond Sweha Boston University Vathe Ishakian Boston University Azer Bestavros Boston University ABSTRACT Inreasingly, ommerial ontent providers (CPs) offer streaming and IPTV solutions that leverage an underlying peerto-peer (P2P) stream distribution arhiteture. The use of P2P protools promises signifiant salability and ost savings by leveraging the loal resoures of lients speifially, uplink apaity. A major limitation of P2P live streaming is that playout rates are onstrained by the uplink apaities of lients, whih are typially muh lower than downlink apaities, thus limiting the quality of the delivered stream. Thus, to leverage P2P arhitetures without sarifiing the quality of the delivered stream, CPs must ommit additional resoures to omplement those available through lients. In this paper, we propose a loud-based servie AngelCast that enables CPs to elastially omplement P2P streaming as needed. By subsribing to AngelCast, a CP is able to deploy extra resoures ( angels ), on-demand from the loud, to maintain a desirable stream (bit-rate) quality. Angels need not download the whole stream (they are not leahers ), nor are they in possession of it (they are not seeders ). Rather, angels only relay (download one and upload as many times as needed) the minimal possible fration of the stream that is neessary to ahieve the desirable stream quality, while maximally utilizing available lient resoures. We provide a lower bound on the minimum amount of angel apaity needed to maintain a ertain bit-rate to all lients, and develop a fluid model onstrution that ahieves this lower bound. Realizing the limitations of the fluid model onstrution namely, suseptibility to potentially arbitrary start-up delays and signifiant degradation due to hurn we present a pratial multi-tree onstrution that aptures the spirit of the optimal onstrution, while avoiding its limitations. In partiular, our AngelCast protool ahieves near optimal performane (ompared to the fluidmodel onstrution) while ensuring a low startup delay by maintaining a logarithmi-length path between any lient This researh was supported in part by NSF awards # , # , # , # , and # Permission to make digital or hard opies of all or part of this work for personal or lassroom use is granted without fee provided that opies are not made or distributed for profit or ommerial advantage and that opies bear this notie and the full itation on the first page. To opy otherwise, to republish, to post on servers or to redistribute to lists, requires prior speifi permission and/or a fee. MMSys 12, February 22-24, 2012, Chapel Hill, North Carolina, USA. Copyright 2012 ACM /12/02...$ and the provider, and while graefully dealing with hurn by adopting a flexible membership management approah. We present the blueprints of a prototype implementation of AngelCast, along with experimental results onfirming the feasibility and performane potential of our AngelCast servie when deployed on Emulab and PlanetLab. 1. INTRODUCTION Streaming high-quality (HQ) video ontent over the Internet is beoming a standard expetation of lients, posing signifiantly different hallenges for today s ontent providers (CPs) suh as Netflix, Hulu, or IPTV, ompared to the hallenges assoiated with the best-effort delivery of low-quality streaming through CPs suh as YouTube and Faebook. For example, Netflix reported last year that it is delivering streams at rates between 1.4Mbps and 2.8Mbps [8]. Motivation and Sope: To be able to deliver streams with a high bit-rate, ontent providers resort to Content Delivery Networks (CDNs) to deliver their ontent. Those CDN s, in turn, started to tap into lient upload bandwidth through the use of P2P arhitetures to alleviate some of their own osts. Examples of peer-assisted ontent distribution systems inlude Akamai s Netsession [1], Otoshape Infinite Edge [2], Pando [3], and BitTorrent DNA [4]. The problem with pure P2P arhitetures is that the urrent offerings by ISPs provide signifiantly higher download rate than upload rate. For example, Verizon FiOS offers three pakages, 15/5 Mbps downlink/uplink apaity, 25/25 Mbps, and 50/20 Mbps. Comast Xfinity offers 50/10, 22/5, 16/2, or 12/2 Mbps. Those examples illustrate an inherent shortoming in pure P2P systems: The persistent gap between the average downlink and the average uplink apaity of peers reates a persistent gap between the lients expetation in terms of download rate and what the uplink apaities of their peers allows. This gap an be overlooked in typial P2P file sharing or VoD when some peers linger in the swarm after finishing downloading, thus allowing other lients to utilize them as seeders. In the ase of live streaming, due to its real-time ontinuing nature, lients at any point in time will have signifiantly higher average download bandwidth than their average uplink apaity. To deal with this, proposed peer-assisted streaming systems rely on dediated provider servers (or seeders in P2P jargon), whih must download the live stream first before uploading it to lients. Paper Contributions: In this paper we propose a loudbased live stream-aeleration servie, AngelCast. By subsribing to AngelCast, a CP is assured that its lients would be able to download the stream at the desired rate with-

2 out interruptions, while maximally leveraging the benefits from P2P delivery. AngelCast ahieves this by (1) enlisting speial servers from the loud, alled angels, 1 whih an supplement the gap between the average lient uplink apaity and the desirable stream bit-rate. Angels are more effiient than seeders as they do not download the whole stream, but rather they download only the minimum fration of the stream that enables them to fully utilize their upload bandwidth. In our arhiteture, the apaity that otherwise would have been wasted in downloading the full live stream to the servers an be hannelled to help the lients diretly; (2) horeographing the onnetivity between nodes (lients and angels) to form optimized end-system multi-trees for peers to exhange stream ontent; and (3) handling lients dynami arrival and departure. We present theoretial results that establish the minimum amount of angel apaity needed to allow all lients to download at a desirable rate, as a funtion of their downlink/uplink apaities. We show that this lower bound is tight by horeographing the onnetivity of nodes in suh a way that the optimal bound is ahieved under a fluid model. A good live streaming system would also minimize the start-up delay needed to assure ontinued servie. We prove that the start-up delay is zero under the fluid model, but that the optimal onstrution leads to a start-up delay that is linear in the number of lients when relaxing the fluid model assumption. Moreover, an optimal onstrution may require building a full mesh between lients (with no bound on node degrees). These reasons lead us to develop a more pratial approah that utilizes almost the minimal amount of angel apaity (predited under the fluid model), while also ensuring that the start-up delay is logarithmi in the number of lients. Our pratial approah relies on dividing the stream into substreams, eah of whih is disseminated along a separate tree. To download the stream, eah lient subsribes to all the substreams, whereas angels subsribe only to one substream, allowing them to upload at full apaity while not wasting too muh upload bandwidth in downloading the whole live stream. The idea of splitting the stream into substreams was proposed in prior work, most notably in SplitStream [10] and [17]. In the related work setion, we disuss what we learned from those proposed tehniques, and how we avoided some of their shortomings. Another limitation of the fluid (optimal) horeography is that it does not onsider issues of hurn due to node arrival and departures. We address this limitation by inorporating membership management apabilities that ensure uninterrupted servie with minimum startup delay. We ahieve this by ensuring that the trees used in our onstrution are well balaned, and by avoiding degenerate ases. Our loudbased servie provides a registrar that ollets information about lients, making fast membership management deisions that ensure smooth streaming. We disuss the arhiteture of our proposed AngelCast system, and evaluate a prototype implementation against SopCast [5] a ommonly use P2P streaming lient. The experimental results arried out on Emulab and PlanetLab show the utility of angels and the effetiveness of our horeographed live stream distribution. The remainder of this paper is organized as follows: In 1 We introdued the notion of angels in prior work [27], where angels were used for a different objetive namely to minimize the bulk download time for a fixed group of lients. Setion 2, we present the theoretial model that bounds the minimum amount of angel upload bandwidth needed to deliver the stream to all lients with the required bit-rate. We also present an optimal fluid onstrution that ahieves that bound and ompute the start-up delay assoiated with it. We onlude that setion by highlighting the effetiveness of using angels over using seeders for live streaming. In Setion 3, we present our pratial onstrution that avoids the impratialities of the optimal onstrution by relaxing the fluid assumption and bounding the node degree. In Setion 4, we present our AngelCast servie arhiteture inluding the membership management tehniques and the design of our protool. In Setion 5, we experimentally evaluate our AngelCast prototype against SopCast in Emulab and PlanetLab. In Setion 6, we review the related work. We onlude in Setion 7 with a summary of results and diretions for future researh. 2. THEORETICAL BOUNDS We adopt the Uplink Sharing Model (USM) presented by Mundinger in [18], wherein eah lient is defined solely by its uplink and downlink apaities. The lient is free to divide its uplink/downlink apaity arbitrarily among the other nodes as long as the aggregate upload/download rates do not exeed the uplink/downlink apaity. Hereafter, we use the term fluid model to refer to the use of the Uplink Sharing Model along with the ability to infinitesimally divide link apaities. The provider P is the originator of the live stream, it has an uplink apaity of u(p ). The set of lients subsribed to the live stream is C of size = C. Eah lient i C has an uplink apaity of u( i) and downlink apaity of d( i). We denote the lients aggregate uplink apaity by u(c) = i C u(i). The aggregate angels uplink apaity is u(a). We assume that the stream playout rate r is onstant. 2 Eah lient j should be able to download fresh live ontent with a rate x j = i C A P xij greater than the playout rate r, where x ij is the rate between nodes i and j. By definition the provider s upload bandwidth is not less than the playout rate u(p ) r, otherwise the provider annot upload the live stream. Also, it is fair to assume that the downlink apaity of all lients is greater than the playout rate d( i) r i C, otherwise those lients will not be able to play the live stream at the desirable playout rate. 2.1 Optimal Angel Alloation In this subsetion, we derive the minimum amount of angel uplink apaity needed in order for all lients to reeive the live stream with rate r. First, we provide a lower bound on the angel uplink apaity, then find an optimal fluid alloation sheme ahieving this bound. Theorem 1. The minimum angel uplink apaity needed for all lients to reeive the stream at a presribed playout rate r is: u(a) 2 u(p )+u(c) (r ) 1 2 It is reommended to use CBR for live streaming. But in the ase of variable bit-rate enoding (VBR), we an use the optimal smoothing tehnique to ahieve a onstant bit-rate (CBR) [25].

3 Proof. For a lient to reeive the stream live, its download rate should equal the playout rate. Thus, the slowest lient should reeive ontent with rate not less than r; min j C{x j} r. Beause the average is always greater than the minimum, the average download rate should exeed r as j C well; if min j C{x j} r then x j r. First, let us onsider the ase of no angels. The uplink sharing model ditates that the aggregate downlink apaity annot exeed the aggregate uplink apaity in the swarm: u(p ) + u(c) i C xi. To optimally utilize u(a) of the uplink apaity of the angels, an angel must download fresh data with a rate of at least u(a)/ then upload it to all lients. Thus, in ase of using angels, we have: u(p ) + u(c) + u(a) x i + u(a) u(p ) + u(c) + u(a) u(a) 2 i C i C xi r Rearranging this inequality allows us to derive the angel uplink apaity needed to ahieve the presribed playout rate r. u(a) ( 2 u(p ) + u(c) ) (r ) 1 Not surprisingly, the bound in Theroem 1 suggests that the apaity of needed angels grows linearly with the number of lients and with the defiit between the playout rate and the lient share of the provider and lients uplink apaities. Theorem 2. All lients an ahieve the playout rate r when: u(a) = 2 u(p )+u(c) (r ) 1 Proof. We prove that the lower bound on the minimum angel uplink apaity is ahievable by onstrution. Using a fluid model, we horeograph the transfer rates between nodes so as to ahieve a download rate that equals the playout rate for all lients. The set of Equations 1 has those rates. The provider sends data to lient i with rate x P i. The lient i in turn forwards this data to other lients j C with rate x ij. The provider sends data to the angel with rate x P A, the angel relays this data to the lients immediately. x P i = u(i) 1 + δ i C x P A = u(a) x ij = u(i) i C, i j 1 where δ = u(p ) r 0 (1) 1 These rates guarantee that eah lient reeives data at rate r without violating the uplink apaity onstraint of any node. The aggregate download rate for lient j (from all soures) will be x j = x P j + x Aj + i C,i j x ij = u(j) 1 + δ + u(a) + u( i) 1 i C,i j = u(c) 1 + u(p ) r u(p ) + u(c) (r ) 1 = r (2) The upload rate of eah lient, i, will not exeed its uplink apaity as ( 1) u( i)/( 1) = u( i). The same an be said about the angels: u(a)/ = u(a). Also, the aggregate upload rate from the provider will not exeed its apaity: x P A + j C x P j = ( u(j) 1 + δ) + 1 j C 2 1 u(p ) + u(c) (r ) = u(p ) (3) To ensure that eah lient reeives non-dupliate data. The provider sends unique data to the angels. As for the lients, eah lient reeives unique data with rate u( i)/( 1) and the same data with rate δ to all lients. Figure 1 illustrates two examples of the optimal onstrution. The left side of Figure 1 is an example with three lients whose uplink apaities are suffiient to ahieve a playout rate of r, thus there is no need for angels. Eah lient splits its uplink apaity between the other two lients. The provider sends data to lients with a rate that equals half their uplink apaity plus δ. The δ part of the upload rate is idential, in terms of its ontent, to all lients, while the other part is unique, ensuring the uniqueness of data disseminated. On the right side of Figure 1 is an example where the uplink apaity of the provider and the two lients is not enough to seure a playout rate r. Thus, an angel is needed. Here, the angel downloads from the provider and uploads to the lients. Eah lient downloads from the provider and uploads some of what it reeives from the provider to the other lients (and angels do not download from lients). Figure 1: Illustrative examples of the optimal onstrution: 3 lients not in need of any angels (left) and 2 lients in need of one angel (right). 2.2 Startup Delay In this setion, we study the effet of paketization on startup delay. Assume that the unit of transfer is of size ψ. In the fluid model, ψ approahes zero. In a pratial setting, eah node annot forward a paket to another node before it finishes reeiving it. Theorem 3. Using the optimal onstrution in Theorem 2, the startup delay, D, is: D = ψ r + ψ ( 1) min i C u( i ) Proof. The proof is by onstrution. The delay until all lients reeive a ertain paket onsists of two parts; the first is the delay until a lient reeives this paket from the

4 provider ψ/r and the seond is the delay until it forwards the paket to all the other 1 lients. The lient that is forwarding the paket to all the other lients an be the one with the smallest uplink apaity, thus we divide the amount of data needed to be sent, ψ ( 1), by the minimum uplink apaity min i C u( i). Therefore, if the goal of the system is for all lients to enjoy an uninterrupted servie, eah lient should fill a buffer of size B before starting the playout, where: ψ ( 1) B = r D = ψ + r min i C u( i). This result suggests that the startup delay grows linearly with the paket size ψ and with the number of lients. Under the fluid model assumption, this is not onsequential beause ψ = 0, resulting in a startup delay of zero as, lim ψ 0 D = 0. In pratial settings however, ψ 0 e.g., it ould be the MTU of a TCP paket 1, 400 Bytes. In suh ases, the optimal onstrution may result in signifiant startup delays for large number of lients. In Setion 3, we propose a dissemination strategy that ahieves the desired download rate using minimum angels apaity while keeping the startup delay under a reasonable (logarithmi) bound. 2.3 Impliations on the Role of Angels The premise behind this work is that there is a signifiant gap between the lients uplink and downlink apaities offered by ISPs. The promised higher download bandwidth enourages ontent providers to stream at an ever-inreasing rate. Pure P2P tehnology helps alleviate the ost on ontent providers by utilizing the lients uplink apaity. To bridge this gap, many peer-assisted file-based streaming onstrutions were proposed. Ours is the first to realize that it is more effiient for the added resoures to download a fration of the live stream instead of its entirety. Figure 2 illustrates the eosystem of our angel-based ontent aeleration arhiteture. In this eosystem, the aggregate downloaded data equals the aggregate uploaded data. The lient uplink apaity annot math the download rate of many streams. Thus, we need to add agents to this eosystem that produe more than they onsume. Angels provide that by downloading a fration of the stream instead of onsuming the already sare resoure of upload bandwidth by downloading unneessary ontent. In live streaming, ontent providers do not Figure 2: Our proposed eosystem; lients download more than they an upload, and angels download as little as possible. have the luxury of uploading the ontent to many servers beforehand. Thus, those servers will ompete over the upload bandwidth with lients. In a peer-assisted streaming mehanism, like the one presented in [17], the system relies on more server apaity to stream at a higher stream rate not supported by the lients uplink apaity. Figure 3 shows a numerial analysis of the performane of angels against servers in a hypothetial setting. It ompares the number of angels, eah with uplink apaity ten, versus the number of servers, eah with uplink apaity ten too, (on the y-axis) needed to ahieve a streaming rate (on the x-axis). The results are shown for a family of urves with varying lients ratios of uplink-to-playout rates ranging from 3:10 to 9:10. The streaming rate (x-axis) varies between 1 and 9. There are 100 subsribed lients and the number of lients an angel an onnet with onurrently is 40. The formula to ompute how many servers we need is r (1 ratio) u(a) r and the formula for the number of angels is r k (1 ratio) u(a)(k 1). The growth in the number of angels is linear with the stream rate. However, if we use servers, the growth is superlinear. For example, when the streaming rate is 9 and the server upload apaity is 10 we need, nine-tenth of a server apaity is wasted in uploading the stream to another server (90% overhead). The graphs ompare different values for the ratio between the uplink apaity to the playout rate. The greater the gap, the more angels/servers the system will need. Clearly, angels are signifiantly more effiient than servers, espeially when the stream playout rate is large. Number of needed Angels/Servers Servers 3:10 Servers 5:10 Servers 9:10 Angels 3:10 Angels 5:10 Angels 9: Streaming Rate Figure 3: The number of angels versus the number of servers needed to ahieve a ertain playout rate for 100 lients. Figure 4 shows the maximum number of lients that an download at a ertain rate given the number of available angels/servers. We fix the ratio between the uplink rate and stream playout rate to 1:2. At low stream rates, a few high-apaity angels/servers an support many lients. As the stream rate inreases, the number of lients satisfied by the servie dereases. Again, the angels are more effiient as they are able to serve more lients onsuming the same amount or resoures. 3. A PRACTICAL CONSTRUCTION The optimal onstrution in Theorem 2 requires eah lient to onnet to all other lients. This leads to operational

5 MAximum Number of Clients Servers, stream rate= 1 Servers, stream rate= 5 Servers, stream rate= 9 Angels, stream rate= 1 Angels, stream rate= 5 Angels, stream rate= Number of Angels/Servers Figure 4: The number of lients that an be supported by a fixed number of angels or servers. hallenges and a start-up delay that grows linearly with the number of lients. To mitigate those problems we developed a new dissemination mehanism that onstrains the node degree of eah lient to k, i.e., eah lients an ommuniate with at most k lients at any point in time. We all this onstrution AngelCast. 3.1 Bounding the Angel Uplink Capaity The limit on the node degree influenes angel effetiveness inversely. Ideally, an angel would download a small fration of the stream and would upload it to all lients. Under a bounded-degree assumption, it is intuitive that we would need more angel apaity. Lower Bound on Angel Capaity Theorem 4. The minimum angel uplink apaity needed for all the lients to download at the playout rate, when eah node is onstrained to onnet to only k other nodes, is: u(a) k u(p )+u(c) (r ) k 1 Proof. Similar to the proof of Theorem 1, in order to optimally utilize u(a) of angel uplink apaity, an angel must download data at a rate of at least u(a) then upload it to a k maximum of k lients, given that k. On the one hand, forwarding the same data to more than k lients simultaneously would violate the out-degree onstraint, and on the other hand, forwarding the same data to more than k lients on stages would result in the reeption of stale and out of stream data to some lients. Also, tearing down onnetions and building new ones frequently and systematially would result in performane degradation due to the nature of the transport protools. To ensure that the aggregate uplink apaity is more than the aggregate download rate: u(p ) + u(c) + u(a) x i + u(a) k u(p ) + u(c) + u(a) u(a) k i C T hus : u(a) ( k k 1 i C xi r u(p ) + u(c) ) (r ) For small swarms, when k, the bounded-degree onstraint is never reahed, thus the bound on the angels uplink apaity does not hange. Even when > k and k is relatively large, we would not need signifiantly larger angel apaity as /( 1) k/(k 1) 1. For example if k = 100 the overhead due to onstraining the out-degree is around 1% even when the number of lients is extremely large. Constrution Under a Bounded-Degree Assumption The optimal onstrution used in Theorem 2 assumes the ability of eah lient to onnet to all other lients simultaneously. In the remainder of this setion, we develop a pratial onstrution under the onstraint of limited node degree, k, where eah node an ommuniate with only k other nodes at any point in time. Our onstrution divides the stream into m substreams. We disseminate eah substream using a multiast tree and eah lient subsribes to all the m trees. The rate of dissemination of all the substreams, r t is equal, suh that the sum of the substreams equals the playout rate, i.e., r t = r/m. This onstrution is similar to what is done in Splitstream [10] and CoopNet [21]. The number of trees, m, depends on the allowed degree of any node, k. For d-ary trees, eah node is onneted to at most d + 1 other nodes (one parent and d hildren). Thus, the number of trees is bounded by: m k/(d + 1). Choosing the arity of the trees is not trivial. On the one hand, hoosing a small arity allows for a greater number of trees, eah with a small substream rate. This will minimize the unassigned lient apaities i C (u(i) mod rt) and utilizes angels more effiiently. As the theoretial results showed, angels are best utilized when they download the smallest substream whih allows them to upload with their maximum bandwidth. On the other hand, hoosing a larger arity would result in a smaller start-up delay, as we prove in Setion 3.2. Also, hoosing a large arity enables the utilization of the lient with high uplink apaity in full beause when a lient subsribes to all trees as a parent of d hildren, it an forward data with maximum rate d r t m = d r. Thus, any lient uplink apaity above d r will be wasted. Consequently, hoosing the right arity has to balane utilizing the resoures and providing a small start-up delay. Beside deiding on the number of trees and their arity, we need to deide on the plaement of eah lient in eah tree. First, let us onsider the ase, in whih there are no angels. Adding angels to this onstrution is straightforward and will be explained shortly. In our onstrution, eah lient alulates how many hildren it an adopt aross all trees, whih equals the uplink apaity of the node divided by the rate of a substream, r t. Let us all this parameter l i, where l i = u( i)/r t. Our onstrution ditates that these hildren be alloated in the minimum number of trees. This is neessary to avoid degenerate trees, where parents have only one hild. Thus, the number of trees where this lient an have d hildren is g i = l i/d. Client i an have the remaining hildren assigned to one more tree and it will be a leaf in all the other trees. Whenever a new lient arrives, it will join all trees. To ensure that no tree is starving for bandwidth while another one has an abundane of it. The new lient will be a parent in the trees where there are fewer plaes to adopt more hildren. We use vaantspots to denote the number of plaes in a tree where it is possible to adopt more hildren.

6 The position of lients in eah tree is equally important. To ensure a small start-up delay, the depth of the trees should be minimized. In a bounded-degree setting, the path from any node to the root should be logarithmi in the size of the swarm. Subsetion 3.2 shows that full trees with large arity ahieve that. Therefore, nodes that an adopt more hildren should be higher in the tree. Subsetion 4.1 shows how we add/remove lients and hange onnetions while maintaining low-depth trees. Adding angels to this onstrution is straightforward. The minimum upload bandwidth of angels needed, u(a), is given by the lower bound in Equation 4. This upload bandwidth would be divided equally between a number of angels n a = u(a)/(k r t), eah of whih will be assigned to a different tree. Eah angel will have k hildren in that tree. Whenever the number of vaantspots in a tree falls below a ertain threshold, we know that this tree is in poor health, hene we add an angel to that tree. When a tree has too many vaantspots, we eliminate an angel, if any exists in this tree. Even though when an angel is added, it is added to a single tree, the health of the other trees will also improve. This is beause newer lients will not need to beome parents in this tree and will alloate their resoures to other needy trees. As for the provider, it will be a parent to the roots of the trees. The exess apaity of the provider an be utilized fully as well, as the provider an adopt more hildren. To avoid adding angels in all trees at the start, the provider fouses its extra apaity in fewer trees. To onlude, this onstrution allows eah lient to download with rate r and ahieves near optimal utilization of the lients uplink apaity. The remaining uplink apaity that is not enough to adopt a hild equals i C (u(i) mod rt), whih an be seen as insurane in the ase of bandwidth osillations. The gap between the lients uplink apaities and the playout (and hene download) rate an be supplemented by angels, and eah node will not have to onnet to more than k other nodes. In the following subsetion, we will show that our onstrution has, on average, a logarithmi startup delay in the number of lients,. 3.2 Bounding the Startup Delay In this setion, we will ompute the startup delay given our onstrution in Subsetion 3.1. A node with d hildren dediates r t of its uplink apaity to eah one of them. Therefore, if we serialize the dissemination by sending a paket to a hild at a time, the time to send a paket of size ψ to the first hild will be ψ/(r t d). The time to disseminate a paket of size ψ to all the d hildren, is d ψ/(r t d) = ψ/r t seonds. Eah tree has hildren, thus, it has log d () levels. Therefore, the time it takes for the last lient in the last level of the tree to download a paket is: D = log d () ψ r t = log d () ψ r (d + 1)/k This startup delay is the minimum when D d = 0 D = ψ k ln() d+1 ( + log(d) 1) d ( d r ln 2 ) (d) ln(d ) = d + 1 D At d d = 0 The above means that in order to minimize the start-up delay, the degree of the tree should be maximized i.e., k 1. This result illustrates the trade-off between minimizing the start-up delay and minimizing the needed angel apaity: The more trees we have, the better we are utilizing the angels/lients at the expense of inreasing the start-up delay. 4. ANGELCAST ARCHITECTURE Figure 5 shows the agents in our system. While the registrar does not disseminate data, it horeographs the onnetivity of lients and angels in the system. The registrar is the main agent in our loud servie. Content providers ontat the registrar to enroll their streams. The registrar uses the profiler to estimates the uplink apaity of lients. The aountant uses the estimated gap between the lients uplink apaity and the stream playout bit-rate to give the ontent provider an estimate of how many angels it will need. Figure 5: The arhitetural elements of AngelCast. 4.1 Membership Management: The Registrar Live streaming swarms are dynami in nature. Clients arrive and depart the stream onstantly. Also, some bilateral onnetions between lients an degrade arbitrarily. Thus, it is absolutely essential to inorporate resiliene in the design of swarms to ensure that some minimal quality of servie is maintained. In this setion, we explain how AngelCast handles membership management, i.e., handling lient arrival and departure, and replaing degraded onnetions with new ones. Our system relies on a speial server to ahieve that, the registrar. The registrar is a speial node in the system that orhestrates the swarm and horeographs the onnetivity of the lients. When a new node joins the stream, it ontats the registrar and informs it of its available upload bandwidth. The registrar uses a data-struture representing the streaming trees and assigns the new lient to a parent node in eah tree. The registrar also deides how many future hildren the new node an adopt in eah tree. Clients an also omplain to the registrar about their parents. The registrar would pik a new parent for a omplaining lient, informs the lient of its new parent, and also probes the underperforming parent to ensure it is still alive. If not, it pro-atively informs other hildren to disonnet from it and provides them with new parents. These deisions are ruial in guaranteeing a ontinued servie with low start-up delay and little disruption. In or-

7 der to ensure fast response to lients requests, the registrar maintains a data-struture ontaining the state of eah node in the system. The state of a node ontains: (1) the depth of the subtree rooted at that node, (2) a pointer to the losest desendent with a vaant spot that an adopt one new hild, whih we all the losestadopter, and (3) the distane to the losestadopter. When a new lient joins the swarm, the registrar adds it to the root s losest adopter in eah tree. The arrival and departure of lients hanges this state. Algorithm 1 shows the funtion that updates the losestadopter as well as the distane to it. The value of the losestadopter an hange for the new/old parent as well as for predeessors, reursively all the way to the root (by onstrution, a logarithmi proess at worst). If the node has vaantspots, then it is its own losestadopter with distane zero. Otherwise, it piks the losestadopter of one of its hildren, the one with the minimum distane to its losestadopter. The update will propagate reursively along the path towards the root until the losestadopter of a node along the path does not hange. Algorithm 1 UpdateClosestAdopter() oldadopter = self.losestadopter if This node an adopt more hildren then self.losestadopter = self self.losestadopterdistane = 0 5: else mindistane = Infinity adopter =NULL for all hild in ChildList do if hild.losestadopterdistane < mindistane then 10: mindistane = hild.losestadopterdistane; adopter = hild.losestadopter end if end for self.losestadopter = adopter 15: self.losestadopterdistane = mindistane +1 end if if oldadopter!=self.losestadopter then parent.updateclosestadopter() end if Figure 6 illustrates how the value of the losestadopter hanges when a new lient arrives. Before the addition, nodes C and D had vaantspots. The root, node A, has node C as the losestadopter. Thus node C will adopt the new node, F. This will hange the value of the losestadopter up the path to the root. Nodes C, F will have no losestadopter. Thus, node A s losestadopter will beome node D, its other hild, node B s, losestadopter. As we alluded before in Subsetion 3.2, in order to minimize the average start-up delay, we need to minimize the depth of the tree. We note that the degeneration of a tree ould be aused by those few nodes that annot have the maximum number of hildren. Our goal is to push those nodes down the tree to avoid this ondition. In order to do so, we allow new nodes to interept ertain onnetions. By interepting a onnetion we mean severing a onnetion between a parent and a leaf hild node, making the parent adopt the new node, and making the new node adopt the hild node. We prefer intereption over adoption if the distane to the losestinterept is smaller than the distane Figure 6: Node F joins the tree, the registrar updates the data struture aordingly. to the losestadopter. We maintain and update the information about the losestinterept and its distane for eah node in the tree in a way similar to the losestadopter. The registrar reeives omplaints from nodes about their parents when they are not downloading at an adequate bitrate. The registrar sends a probe to the parent, if the parent is alive and replies, the problem is with the link not with the parent. The registrar severs the onnetion to that parent and attahes the omplaining hild, and the subtree below it, to the losestadopter in the tree. We need to ensure that the omplaining node is not re-attahed to the same parent, or worse to a desendent of its own. We ensure that by setting the losestadopter distane of the parent to a very big number and propagating the update upward the tree, foring the root to hoose a losest adopter away from the omplaining node. We then attah the severed subtree to the new losestadopter then set the losestadopter distane of the old parent to zero and update up the tree. By the end of this proess, the omplaining node gets alloated, with its subtree, to a different part of the tree and the values of losestadopter of all the nodes are adjusted. If the registrar s probe to a node results in no response, the registrar onludes that the lient unsubsribed from the stream. Thus, it will atively remove it from all trees. When a node is removed from a tree, eah of its orphaned hildren will be added, one by one, to the losestadopter in the tree. To maintain balane in the tree, the hildren with smaller distane to their losestadopter are added before the hildren with larger distane to their losestadopter. Our servie enables a graeful departure of lients by allowing them to delare their intention to leave the stream. Figure 7 illustrates how our membership management tehniques work through an example. Step 1 shows the initial state in whih the provider is the root of the three trees, with an uplink apaity of 4 and a stream playout rate of 3. Thus, the root, s, has 4 vaantspots, two of whih are assigned to the first tree and one vaantspot for eah of the seond tree and the third tree. Client x joins in Step 2. It has two vaant spots, both of them will be assigned to the seond tree. As we disussed before we assign a lient as a parent in the minimum number of trees to maintain low depth trees. As a result of lient s x arrival, the number of vaantspots in the third tree is redued to zero. Thus a new angel, A, is added

8 automatially to the third tree. The angel s uplink apaity equals 3, allowing it to have three hildren in one tree. If we had only one tree, the angel would have been useless as it will have had only one hild and downloading as muh as it is uploading. Beause there are no vaantspots in the third tree, the added angel will interept the onnetion between the provider and lient x. Step 3 illustrates the arrival of lient y. Both of its vaantspots will be assigned to the tree with the minimum number of vaantspots, whih is tree 1. In Step 4, lient x omplains about its onnetion to the provider in the first tree. The registrar disonnets it from the provider and instruts it to onnet to lient y. Step 5 illustrates the departure of lient y. It will be removed from all trees and its hildren, if any, will be added one by one. Figure 7: A hypothetial senario illustrating the formation of AngelCast trees when lients join, leave or hange parents. 4.2 The AngelCast Protool The registrar deides on the number of substreams, the fan-out of the trees and adds the provider as root to all trees. It also initializes the data struture in whih the state of the system is kept. The registrar then starts a listener proess to reeive join requests and omplaints from lients. It uses the membership management tehniques, desribed in Subsetion 4.1, to respond to suh request. Whenever the number of vaantspots in a tree falls below a ertain threshold, the registrar instantiates a new mahine from the loud as an angel. When a tree has too many vaantspots, an angel is released from this tree, if any exists. A full implemented system, serving many live streams onurrently, an instantiate a ouple of mahines and leave them on standby at all time. Therefore, in the ase when a stream is in need of help, an angel would be ready to help and there would be no need to wait for the typial delay assoiated with aquiring a mahine from the loud. In our implementation, the provider and lients need to download plug-ins (software) to enable them to interat with the AngelCast system. On the provider side, the software divides live ontent as it arrives into substreams, whih are maintained in separate substream buffers. The ontent of eah buffer is divided into hunks of fixed size. The provider also starts a listener proess, whih instantiates threads in response to join requests. These threads read from a substream buffer and sends hunks of data to the lient. On the lient side, the software starts by ontating the registrar asking to join a stream. The registrar replies with information about the stream as well as the identity of a parent apable of serving the (sub)stream in eah tree. Upon ontating these parents, a newly-arriving lient is able to start downloading the substreams into different buffers. The software on the lient side inludes a thread that reads from these buffers in a round robin fashion and writes to a loal port using an HTTP server. Any media players with the ability to play streams over HTTP (e.g., mplayer) an play out the stream from this loal port. Similar to the software on the provider side, the software at the lient also starts a listener proess, whih instantiates threads in response to join request from hildren. When suh a request is reeived for a speifi substream, the software sends data from the buffer assoiated with that substream. The angels software is similar to the software at the lients, exept that angels need only subsribe to one substream and then listen and serve inoming lient requests for that one substream. Figure 8 illustrates an example of the interation between a newly arriving lient, lient A, the registrar and other lients hosen by the registrar as parent to lient A in two trees. Client A joins the system by sending a Join message (message #1) to the registrar, the Join message ontains the ID of the requested stream and the uplink apaity it is willing to ontribute. The registrar replies with a Welome message (message #2) informing the lient with the stream playout rate, the number of trees (substreams), the hunk size, and the identity of the hunk it should download first. The registrar also sends to the lient the IP/port# of eah parent that the lient should ontat for eah substream (Messages #3 and #5). When ontating these parents (messages #4, #6), the lient speifies the tree ID and the hunk it is expeting to start downloading from. Messages #7 to #13 represent data messages from the parents to lient A. The data messages has the hunkid and the assoiated streaming data. In this example, the streaming ontinues smoothly (message #13), after that the onnetion is lost or degraded (message #14 is lost). The lient realizes that and ontats the registrar before it depletes its buffer. It sends message #15 to the registrar informing it that it was disonneted from its parent in the first tree, lient B. The registrar replies to lient A with a new parent to onnet to, lient D (Message #16). The lient sends message #17 to the new parent, lient D, requesting hunks starting at where it stopped, the new parent starts streaming this substream. In the meanwhile, the registrar probes

9 old parent, lient B, to hek if it is still alive or not (Message #18). In this ase it reeives an EhoBak message (#19), and the registrar sends the old parent message #20 informing it to disonnet that hild. If the registrar had not reeived an EhoBak message, it would have assumed the lient is disonneted and would have sent a proative message to all its hildren in all trees to onnet to a different parent. For seurity reasons, the registrar sends messages to the parents informing them whih lients to aept as hildren. The lient an ignore any download request from any unauthorized lient. We omitted those messages from this example for simpliity. Figure 8: An interation diagram showing the exhange of messages between a new lient, the registrar and the parents. We implemented a prototype of our AngelCast protool in python. 3 Our prototype inludes the ode for the registrar, provider, lients and angels. Our prototype does not inlude the profiler, thus lients report how muh uplink apaity they are willing to ontribute to eah swarm. 5. EXPERIMENTAL EVALUATION To evaluate the performane of our AngelCast prototype, we deployed it in the widely used researh platforms: Emulab[6] and PlanetLab[7]. On the one hand the Emulab experiments give us aurate insights by isolating our protool form other experiments, and also making it possible for our results to be repeatable. On the other hand the PlanetLab experiments are meant to validate that AngelCast performs well in the wild on the Internet. Our main motivation in performing these experiments is three-fold: (1) establish onfidene in our implementation by omparing its performane to that of widely used streaming solutions, (2) establish the effetiveness of deploying angels from the loud for the purpose of guaranteeing ertain 3 The ode is available at: remos/researh/angels.html streaming rates, and (3) measure the performane of our system under hurn. We deploy the registrar on a mahine of its own. The angels were also deployed on Emulab/PlanetLab mahines instead of the loud. The first set of experiments aims at validating our AngelCast prototype by omparing its performane to that of SopCast[5]. SopCast is a popular P2P streaming lient used widely on the Internet. We ran SopCast and AngelCast protools on the same set of mahines at the same time to neutralize unpreditabilities related to host/network proesses (e.g., ross-traffi). We performed experiments to ompare the frame dropratio of AngelCast vs Sopast for streams of varying rates (280Kpbs to 1.4Mbps) on Emulab. The results 4 are shown in Figure 9a. Emulab mahines tend to have signifiantly higher uplink bandwidth than the average household. Thus we use traffi shapers to limit the uplink apaity of the nodes. We limit the uplink apaity of the provider to twie the stream rate, 2 r, and the thirty two lients uplink apaity to (4/3) r. This assignment guarantees that there is enough upload bandwidth for all lients, thus, there is no need for angels. The frame drop-ratio of AngelCast and SopCast are omparable when the upload bandwidth is plentiful. Figure 9b shows the result of the same previous experiment on PlanetLab. The frame drop-ratio is signifiantly higher than in Emulab but the performane of AngelCast and Sopast is still omparable. Beause Emulab allow us to perform repeatable experiments and to isolate the performane from other experiments running on the same mahine, we deided to run the rest of the experiments on Emulab. The seond set of experiments aims to haraterize the effetiveness of angels. Our system deploys angels when a tree has no vaantspots. We seured 26 lients for downloading a live stream at r=950kbps playout rate. We vary the lient uplink apaity between 60% to 100% of the stream rate, r. AngelCast splits the stream into ten trees eah with a fanout of three. The provider s upload bandwidth is double the stream rate, ensuring that the provider is not the bottlenek. An angel uplink apaity is 1.5 times the stream rate, ensuring that it is larger than the stream rate, but also that it does not have too many hildren in one tree (maximum=15). On the x-axis of Figures 10a and 10b, we vary the lient uplink apaity, shown as the ratio between the lient uplink apaity and the stream rate. On the y-axis of Figure 10b we plot the apaity of angels deployed by AngelCast against the theoretial bound for the minimum angel apaity (AngelCast theoretial). Also, we ompare it against the minimum server apaity when the server downloads the whole live stream (ServerCast). The results onfirm that AngelCast utilizes near minimal apaity, and that it ahieves signifiant savings when ompared to ServerCast. On the left-hand-side of Figure 10a (in red), we plot the angel apaity being used and on the right-hand-side sale (in blak), we plot the assoiated frame drop ratio. This experiment verifies that our system ahieves reliable streaming utilizing near minimal resoures. The third set of experiments aims to demonstrate the performane of AngelCast under hurn. In live streaming, hurn is due to lient arrivals and departures. This is different from 4 All results are shown within 95% onfidene interval.

10 2.5% 2% Emulab AngelCast SopCast 14% 12% PlanetLab AngelCast SopCast Frame Drop Ratio 1.5% 1% 0.5% Frame Drop Ratio 10% 8% 6% 4% 2% 0% 280k 530k 950k 1400k Streaming Rate in Kbps 0% 280k 530k 950k 1400k Streaming Ratio in Kbps Figure 9: The frame drop ratios of AngelCast vs SopCast. Normalized Upload Defiit 16r 14r 12r 10r 8r 6r 4r 2r Angel Capaity AngelCast ServerCast minimum AngelCast minimum 0r 60% 70% 80% 90% 100% Normalized Upload Capaity Normalized Upload Defiit 16r 14r 12r 10r 8r 6r 4r 2r Drop Ratio Frame Drop Ratio Deployed Angel Capaity 16% 14% 12% 10% 8% 6% 4% 2% 0r 0% 60% 70% 80% 90% 100% Normalized Upload Capaity Frame Drop Ratio Figure 10: Minimal amount of angel apaity is suffiient to ahieve good stream rates. how hurn is typially modeled in VoD where playbak funtionality, suh as pause, seek and fast-forward must be onsidered as well[14]. Therefore in this experiment, we observe a live stream over a period of 210 seonds, whereby lients join the stream at a onstant rate of 0.1 arrival per seond (i.e., one arrival every 10 seonds on average). Clients stik to the stream for an exponential amount of time of mean 50, 100, 150 or 200 seonds then leave. We set the uplink apaity of the provider to be twie the playout rate; we set the uplink apaity of angels to be 150% the playout rate; and we set the lients uplink apaity to be 70% the playout rate. On the x-axis of Figure 11 we vary the expeted duration of the lient s stay. On the right y-axis we show the frame drop-ratio. This experiment shows that, as expeted, higher hurn results in poor performane, (e.g. when lients stay less than a minute on average, the frame drop ratio is as bad as 25%). On the left y-axis, we plot the aggregate apaity of the deployed angels. When there is no hurn, six angels are needed to fill the apaity gap. In the presene of hurn, the number of deployed angels is almost fixed to ten, the number of trees. The reason for that is the lak of vaantspots in eah tree at different points during the experiment, due to hurn. Normalized Upload Defiit 16r 14r 12r 10r 8r 6r 4r 2r Figure 11: hurn. Frame Drop Ratio Deployed Angel Capaity 0r 50s 100s 150s 200s 0% Expeted Stay of a Client (se) The performane of AngelCast under 6. RELATED WORK This paper builds on a rih body of work that approah the problem of ontent delivery in general and live streaming in partiular from a number of perspetives: Pull-based Mesh Protools: There is a large number of papers/systems that utilize pull-based mesh streaming, suh as SopCast, PPLive, UUsee, Joost, and CoolStream- 45% 40% 35% 30% 25% 20% 15% 10% 5% Frame Drop Ratio

11 ing. Our push-based approah differs from these in that it horeographs the onnetivity among nodes to guarantee the quality of streaming for every lient. We hoose to ompare AngelCast against SopCast [5] as it is extensively used, allows users to stream their own hannels and works with mplayer over Linux. An example of suh pull-mesh protools is CoolStreaming [29], the streaming version of Bittorrent. The differene is that the deadline of a hunk playtime is a fator in the piee seletion algorithm. Feng et. al. [13] illustrated the inherent shortomings of pullbased mesh networks as well as providing a glossary of suh protools. Peer-Assisted Content Distribution: The researh ommunity is aware of the promise of P2P in alleviating the load of ontent distribution on servers. Nonetheless, it is also aware of its limitations, espeially in providing suffiient upload bandwidth. For file sharing, Wang et al [28] proposed adding powerful peers to BitTorrent swarms to aelerate the download rate. This is not optimal, beause these helpers will unneessarily onsume the sare upload bandwidth in the swarm. In Antfarm [23], the authors propose a protool for seeders to measure the vital signs for multiple swarms and alloate more seeder bandwidth to struggling swarms. Our previous work [27] showed that horeographing the onnetivity of a swarm and using angels instead of seeders results in minimizing the maximum lient download time for a fixed group of lients in a swarm. Jin el. al. [15] introdued edge ahing to help original servers stream to lients at the presribed bit-rate. The ahe ontains the objets where the ratio between the lient request rate and the defiit between download rate and playbak rate is maximal. This work is different as it requires in-network ahing, but it highlights the need for infrastruture help to ensure smooth streaming. Modeling P2P Performane: Qiu and Srikant s seminal work [24] is the first to haraterize the average download time in a swarm. Das et al [12] extended Qiu s model [24] of swarm download rate to inorporate seeders. The result points out that the average download time is inversely proportional to the seeders aggregate upload rate. However, the inrease in the number of peers requires a linear inrease in the number of seeders to maintain the same average download time. Although Qiu s model is fundamentally different, these results are in line with our findings. Parvez et al.[22] extended Qiu and Srikant s model [24] to the ase of stored VoD, studying the need for sequential progress instead of random hunk download. This is inline with our design onept of horeographing the onnetivity of the swarm instead of relying on random hunk download. Kumar et al. [16] used the uplink sharing model [18] to find the bound on the highest streaming rate a swarm an handle given the uplink/downlink apaities of the lients. They proposed a fluid onstrution that ahieve their bound. We extend their model to ompute the required angel apaity to ahieve a ertain streaming rate. Likewise, we built an optimal fluid onstrution that ahieves the bound, inorporating angels. They highlighted the gap between the uplink apaity and download rate, stating that most hannels in PPLive are running at rate 2-4 times the uplink apaity of many residential broadband peers. Angels are the answer to this problem. Liu et al. [17] extended Kumar s model in the ase of bounded node degree as well. They proposed reating spanning trees with varying streaming apaities. Given their onstrution, they provided bounds on the depth of the tree, the maximal upload rate and the minimum server apaity. Their onstrutions assumes the provider an onnet to all lients, that the number of spanning trees an reah the number of lients and the depth of some trees an be linear in the size of the swarm. Our AngelCast tehnique avoids those three problems. Multiast Multi-Tree Constrution: Many papers leverage the idea of onstruting multiple multiast trees (a forest) for file distribution as well as for streaming. SplitStream [10] onstruts a forest of multiast trees, one for eah stripe, all with the same rate. This approah is different from ours in that the lient an hoose the number of stripes it wants to subsribe to, thus reeiving a subset of the broadasted data. In ontrast to tree-based multiast, the load on the nodes is balaned as eah node is an internal node in one tree but a leaf node on the others. When the internal nodes of one tree an not adopt any more hildren, the hild must searh for some node in the exess apaity tree to download this strip. This leads to ineffiienies as a node ould perform a distributed linear searh until it finds a suitable parent. More importantly a lient with signifiantly large apaity an adopt many hildren eah in a different tree resulting in degenerate trees and more than logarithmi depth of trees. Our tehnique makes sure that any parent has at least two hildren exept for the nodes in the seond to last level, insuring a logarithmi depth of all trees. P2PCast [19] is a modifiation of SplitStream where all nodes subsribe to all trees to download the same ontent. They require from eah lient to partiipate an upload bandwidth equal to the download rate. This ould be unrealisti given the diversity of user s uplink apaities and the shielding of some lients behind NATs. CoopNet[21, 20] reates multiple trees, eah streaming a substream of an MDC enoded video. There ontribution is in providing a mehanism to ope with the flutuation in the available bandwidth. Coding for Adaptive Streaming: Multiple Desription Coding (MDC)[11] and Salable Video Coding (SVC) [9] were introdued to enable lients to download the same video on different rates/qualities. MDC tends to be more theoretial, where any number of desriptions are enough to deode the movie at a rate proportional to the number of reeived desriptions. SVC odes the video in layers, the base layer is essential for deoding while the subsequent layers are inreasingly less important. Suh tehniques are inreasingly deployed to overome the unertainty of the available bandwidth and its flutuation, in partiular Dynami Adaptive Streaming over HTTP (DASH) [26]. We onsider those tehniques omplementary to our angels approah. Providers who prefer better than best effort delivery to their lients an deploy angels to offer better download rate. MDC and SVC an be deployed in onjunture with angels in this ase, where lients an attempt subsribing to m trees downloading m desriptions/layers. If a lient is not able to download all the layers, it is still able to deode the video with lower quality. Our urrent prototype implementation works over HTTP, we are planning on extending our protool to onform more losely to DASH.

12 7. CONCLUSION In this paper we onsidered the potential of peer-assisted ontent distribution for affordable high-quality live streaming. As, the defiit between lients uplink and downlink apaities limits the use of pure P2P arhiteture in suh a setting, we introdued the notion of angels servers who do not have a feed of the live stream and are not interested in downloading it in full. We omputed the minimum amount of angel apaity needed in a swarm to ahieve a ertain bit-rate to all lients and provided a fluid model onstrution that ahieves that bound. We introdued pratial tehniques that handle limited node degree onstraints and hurn. We built AngelCast, a loud-based servie that assists ontent providers in delivering quality streams to their ustomers, while allowing the ontent providers to leverage the ustomers resoures to the fullest. We deployed AngelCast unto two researh platforms: Emulab and Planetlab. We showed that the performane of AngelCast is omparable to that of SopCast, a widely used streaming protool, and that it is apable of supplementing the bandwidth defiit with near minimal apaity, while being able to handle hurn. We are urrently developing a version of AngelCast for wide-spread deployment. We are planning on onduting extensive evaluation and on olleting measurements of its performane in delivering real-world live streams. Our future work will explore ways in whih underutilized angels are managed. This inludes the possibility of using angels aross multiple swarms. Seurity is another fous of our future work, espeially seuring the registrar ontrol messages. 8. REFERENCES [1] Akamai Netsession. [2] Otoshape. [3] Pando Networks. [4] Bittorrent DNA. [5] SopCast: Free P2P Broadasting. [6] Emulab. [7] PlanetLab. [8] Netflix Teh Blog netflix-performane-on-top-isp-networks.html. [9] Abboud, O., Zinner, T., Pussep, K., Sabea, S. A., and Steinmetz, R. On the impat of quality adaptation in SVC-based P2P video-on-demand systems. ACM 2nd MMSys 11, pp [10] Castro, M., Drushel, P., Kermarre, A., Nandi, A., Rowstron, A., and Singh, A. Splitstream: high-bandwidth multiast in ooperative environments. In SOSP 03. [11] Chou, P., Wang, H., and Padmanabhan, V. Layered multiple desription oding. In Pro. Paket Video Workshop (2003), Citeseer. [12] Das, S., Tewari, S., and Kleinrok, L. The Case for Servers in a Peer-to-Peer World. Communiations, 2006 IEEE International Conferene on. [13] Feng, C., Li, B., and Li, B. Understanding the performane gap between pull-based mesh streaming protools and fundamental limits. In INFOCOM 2009, IEEE (2009), IEEE, pp [14] Guo, Y., Yu, S., Liu, H., Mathur, S., and Ramaswamy, K. Supporting vr operation in a mesh-based p2p vod system. In CCNC th IEEE (2008), IEEE, pp [15] Jin, S., Bestavros, A., and Iyengar, A. Aelerating internet streaming media delivery using Network-Aware partial ahing. ICDCS 02, [16] Kumar, R., Liu, Y., and Ross, K. Stohasti fluid theory for P2P streaming systems. In INFOCOM th IEEE International Conferene on Computer Communiations. IEEE (2007), IEEE. [17] Liu, S., Zhang-Shen, R., Jiang, W., Rexford, J., and Chiang, M. Performane bounds for peer-assisted live streaming. In ACM SIGMETRICS Performane Evaluation Review (2008), vol. 36, ACM. [18] Mundinger, J., Weber, R., and Weiss, G. Optimal sheduling of peer-to-peer file dissemination. Journal of Sheduling 11, 2 (2008), [19] Niolosi, A., and Annapureddy, S. P2past: A peer-to-peer multiast sheme for streaming data. In 1st IRIS Student Workshop (ISWŠ03). Available at: http: // www. s. nyu. edu/ niolosi/ P2PCast. ps. [20] Padmanabhan, V., Wang, H., and Chou, P. Supporting heterogeneity and ongestion ontrol in peer-to-peer multiast streaming. Peer-to-Peer Systems III (2005), [21] Padmanabhan, V. N., Wang, H. J., and Chou, P. A. Resilient peer-to-peer streaming. In 11th IEEE ICNP 03 (Nov. 2003), IEEE Comput. So. [22] Parvez, N., Williamson, C., Mahanti, A., and Carlsson, N. Analysis of bittorrent-like protools for on-demand stored media streaming. SIGMETRICS 08. [23] Peterson, R. S., and Sirer, E. G. Antfarm: effiient ontent distribution with managed swarms. In NSDI 09, USENIX Assoiation. [24] Qiu, D., and Srikant, R. Modeling and performane analysis of BitTorrent-like peer-to-peer networks. SIGCOMM Comput. Commun. Rev. 34 (2004). [25] Salehi, J., Zhang, Z., Kurose, J., and Towsley, D. Supporting stored video: Reduing rate variability and end-to-end resoure requirements through optimal smoothing. ACM SIGMETRICS Performane Evaluation Review 24, 1 (1996), [26] Stokhammer, T. Dynami adaptive streaming over http : standards and design priniples. In ACM 2nd MMSys [27] Sweha, R., Ishakian, V., and Bestavros, A. Angels In The Cloud: A Peer-Assisted Bulk-Synhronous Content Distribution Servie. In IEEE CLOUD 2011: The IEEE International Conferene on Cloud Computing. [28] Wang, J., Yeo, C., Prabhakaran, V., and Ramh, K. On the role of helpers in peer-to-peer file download systems: Design, analysis and simulation. In In IPTPS 07 (2007). [29] Zhang, X., Liu, J., Li, B., and Yum, T. Coolstreaming/donet: A data-driven overlay network for effiient live media streaming. In proeedings of IEEE Infoom (2005), vol. 3, Citeseer, pp