Scalable live video streaming to cooperative clients using time shifting and video patching

Transcription

1 calable live vieo streaming to cooperative clients using time shifting an vieo patching Meng Guo, Mostafa H. Ammar {mguo, Networking an Telecommunication Group ollege of omputing, Georgia Institute of Technology Abstract We consier the problem of how to enable the streaming of live vieo content from a single server to a large number of clients. One recently propose approach relies on the cooperation of the vieo clients in forming an application layer multicast tree over which the vieo is propagate. Vieo continuity is maintaine as client epartures isrupt the multicast tree, using multiple escription coe (MD) streams multicast over several application layer trees. While this maintains continuity, it can cause vieo quality fluctuation as clients epart an trees are reconstructe aroun them. In this paper we evelop a scheme using the transmission of a single-escription coe vieo over an application layer multicast tree forme by cooperative clients. Vieo continuity is maintaine in spite of tree isruption cause by eparting clients using a combination of two techniques: 1) proviing time-shifte streams at the server an allowing clients that suffer service isconnection to join a vieo channel of the time-shifte stream, an 2) using vieo patching to allow a client to catch up with the progress of a vieo program. imulation experiments emonstrate that our esign can achieve uninterrupte service, while not compromising the vieo quality, at moerate cost. I. INTRODUTION We consier the problem of how to enable live streaming of vieo content from a single server to a large number of clients. Due to the banwith-intensive nature of vieo streams, eploying scalable streaming service with acceptable quality has always been a challenge. The straightforwar solution of setting up a connection for every single request is obviously not scalable. The server sie link can be easily congeste as the client requests accumulate. Native network layer IP multicast coul be a goo solution for scalable meia streaming applications, but it is not wiely eploye. One recently propose approach relies on the cooperation of the vieo clients in forming an overlay network over which the vieo is propagate [1], [13], [1]. In this approach, a client currently in the overlay network forwars the content it is receiving, an serves other client s request as a server. y istributing the transmission loa evenly to the clients all over the network, the vieo server is no longer the bottleneck. This approach is scalable in the sense that the forwaring capability of the overlay network is growing incrementally. New clients joining the network also bring in extra banwith capacity to the system. This work is supporte by NF Grant ANI-2448, ANI , an AFOR MURI Grant F The major problem for application layer multicast is the vieo iscontinuity cause by the ynamics of membership. ince the clients in the group can leave at any time, other clients which are receiving vieo content from them have to suffer service isconnection. Although the isconnecte clients can resume the service by rejoining the application layer multicast tree, this process can take time an can result in loss of vieo content an interruption of vieo reception. To make things worse, unsatisfie clients leaving the group can become a positive feeback process, causing more clients to leave, which ultimately makes the streaming meia service unacceptable. In oopnet [13], vieo continuity is maintaine using multiple escription coe (MD) streams multicast over several application layer trees. oopnet employs a serverbase centralize control protocol, the server is responsible to make sure that multiple trees for ifferent escriptions are uncorrelate with each other. A single client s eparture can only isconnect a subset of escriptions for its chilren. While oopnet maintains vieo continuity, it can cause vieo quality fluctuation as clients epart an trees are reconstructe aroun them. Recent work in oopnet shows the PNR variation with ifferent number of escriptions [14]. Our solution tries to provie continuous streaming service without vieo quality fluctuation. In this paper we evelop a scheme using the transmission of a single escription coe vieo over an application layer multicast tree forme by cooperative clients. lients in the tree always receive full quality vieo stream. Vieo continuity is maintaine in spite of tree isruption cause by eparting clients using a combination of two techniques: (1) proviing time-shifte streams at the server an allowing clients that suffer service isconnection to join a vieo channel of the time-shifte stream, an (2) using vieo patching to allow a client to catch up with the progress of the live vieo program. We also nee a buffering scheme that allows the client to store the vieo packets, an to playout when neee. In our esign, the client buffers the initial part of the vieo content for a certain time before play out. If the client is isconnecte from the multicast tree, it can play out full quality vieo from this buffer while reconnecting to the group. The client rejoins the group by connecting to both the original stream an a time-shifte stream. The time-shifte stream (patching stream) is use to retrieve the misse vieo. The original stream is use to catch up with the progress of the

2 live vieo. Receive vieo packets that are not being playe out are store at the buffer for future playout. When the misse portion of the vieo content is fixe, the time-shifte stream is release, an the client receives from the original stream only. The use of vieo patching requires that a client shoul have enough banwith for two vieo streams: the original stream, an the time-shifte stream. This paper is organize as follows. We give an overview of our esign in ection 2. In ection 3, we escribe our esign in etail, Then, in ection 4 we set up the simulation environment, an show some sample results of our performance evaluation experiments. Finally, we conclue this paper in ection. II. DEIGN OVERVIEW In this section, we first give a general escription of how our system operates. Then, we iscuss the potential problem of the straightforwar time shifting solution. We then apply vieo patching in live streaming service, an escribe how the esign goals are met. Finally, we give an example to illustrate the system operations. A. asic Operations Our esign of the system is compose of three components: 1) a time shifting vieo server, 2) a level-base tree management protocol, an 3) a vieo stream patching scheme. A time shifting vieo server broacasts vieo program in channels. Each channel can be use to transmit one vieo stream. There is an application layer multicast tree associate with each channel. The server serves the clients with the original stream, an m time-shifte streams. We label these streams s,s 1,,s m. tream s is the original stream, while s i starts after a i elay. Vieo server is the single source of the vieo content, an is the root of the application layer multicast tree. It processes client requests to join, leave, an rejoin the multicast group, an is responsible for maintaining the topological structure an resource availability of the multicast tree. When a client first joins the multicast group, it always joins a multicast tree of the original stream. If the server has free vieo channel available, the client connects to the server irectly. Otherwise, the client joins the tree by connecting to a client alreay in the tree who has enough available banwith resources, while at the same time, has the shortest overlay path to the vieo server. This noe join protocol guarantees that the clients in the upper level of the tree are fully loae, before the clients in the lower level of the tree start to aopt new clients as their chilren. In this way, we can get a wellshape wie an short multicast tree. A wie an short tree can achieve lower banwith consumption, an can reuce the probability of service isconnection ue to ancestor noe failure. A client in the multicast tree suffers service isconnection in two cases: 1) upstream link congestion, or 2) an ancestor noe s failure. imilar to oopnet, to etect service isconnection, the client sets a threshol value, if the packet loss rate is above the threshol, the client eems it as a service isconnection. For the case of ancestor noe failure, the client etects 1% packet loss. The client manages to rejoin the group by connecting itself to another parent noe. The noe rejoin elay for a client is the time interval between the moment when the client is isconnecte an the moment when the client is reconnecte. We enote the noe rejoin elay for client c as r c. A straightforwar approach for lossless vieo reception is: when the client rejoins the tree, it can select to join the vieo channel of an appropriate time-shifte vieo stream, so that it will not miss any vieo content. For example, if at time t, the client is isconnecte, an it manages to rejoin the group at t + r c, the appropriate stream shoul be the stream with rc elay. lients that join the same vieo channel form an application layer multicast tree. playback time Receive tream Viewing Delay tarving Perio t1 t2 t3 Fig. 1. Freezing Perio An example of inefinite shifting time A client might experience multiple service isconnections uring the vieo reception process. Figure 1 shows an example when client c suffers multiple isconnections. In this figure, the horizontal axis is the actual time, while the vertical axis is the vieo playback time. The server sens out vieo streams with equal time shifting interval. The client experiences three service isconnections at time t 1,t 2, an t 3. Viewing elay means the elay between the playback time of the vieo stream that the client is watching an the playback time of the original stream. tarving perio is the time interval when the client is not receiving any vieo. Freezing perio refers to the time perio when the client sie play out is temporarily stoppe. The client joins the original stream at time. During[,t 1 ], the viewing elay is. Attimet 1, it is isconnecte from the application layer multicast tree. It manages to reconnect to the tree at time t 1 + 1, the misse vieo is [t 1,t ].The esignate time-shifte stream is s i, where i = 1 =1 (assume 1 <). The client begins to receive from stream s 1 at time t 1 +. The viewing elay uring [t 1,t 1 + ] increases from to. The client is isconnecte again at time t 2, an rejoins the tree at t Note that at this time, the misse vieo portion is [t 2 1, t ]. The esignate timeshifte stream shoul be s j, where j = =2. (again, we assume 2 <). The client begins to receive from stream s 2 at t 2 +, an the viewing elay is increase to

3 2. imilar event occurs after the thir isconnection. In a general case, if a client suffers n service isconnections, it has to switch to stream s k, where k = n i=1 i, an the client viewing elay will be k. Here, i enotes the rejoin elay after the i th isconnection. As shown in the Figure 1, each time the client rejoins the multicast tree, it has to join a stream with a larger time shifting value. This can result in inefinite time shifting, which is unesirable since the client s reception time coul be much longer than the actual vieo program time. Also, if the time shifting value excees the bounary that the server can provie (m ), the client will suffer vieo content loss. Another problem emonstrate in this example is vieo freezing cause by vieo starvation. In this example, the starving perio an freezing perio is same. Whenever the client is isconnecte from the application layer multicast tree, the client sie s playback is pause. In our esign, we introuce vieo patching to tackle the inefinite time shifting; an use initial buffering to provie continuous vieo streaming. patching perio 1, the client is actually receiving at twice the spee as the normal stream rate. After the progress of the vieo is caught up, the patching stream is release, an the client receives only from the original stream. There are several major ifferences between vieo patching in VoD service, an vieo patching in our scheme. 1) Different purposes: vieo patching in VoD service is use to reuce the access latency, while vieo patching in our scheme is use to provie lossless vieo reception. 2) Different starting time: vieo patching in VoD service starts at the begining of the service, in our scheme, vieo patching coul happen at anytime uring the vieo reception process. 3) Different releasing time: in VoD service, the patching channel is release when the vieo playback ifference with another regular channel is fixe, while in our service, the patching channel is release when the misse vieo is retrieve. lient Receive Rate lient Playout Vieo Patching in Live treaming Vieo patching is a popular channel allocation technique in Vieo on Deman (VoD) service. It is esigne to provie better server channel utilization an thus lower server loa. In vieo patching, vieo channels of the VoD server are classifie in two categories: regular channels an patching channels. Regular channels transmit the entire vieo stream, while patching channels only transmit the initial portion of a vieo as neee. When the server allocates a free channel to client requests, it first scans the on-going channels. If there is no regular channel istributing the requeste vieo, or the starting time for this vieo is too early for the client to patch, this channel is allocate as a regular channel. Otherwise, the channel is allocate as a patching channel. Uner vieo patching, the clients receive ata from both the regular channel an the patching channel. The ata from the patching channel is use to make up for the ata the clients are missing from the regular channel. While receiving from the patching channel, the ata being receive from the regular channel is buffere by the clients for playout when neee. When the missing portion is completely receive, the patching channel is release, an the clients only receive packets from the regular channel. More etaile escription of vieo patching can be seen in [9]. In our scheme, the server sens out the original stream, as well as multiple time-shifte streams space by a fixe time interval. The time-shifte stream serves as patching stream in our system. Here is how it works: when the connection to the tree is re-establishe after a service isconnection, a client woul have misse the vieo from the point it is isconnecte to the point it is reconnecte. The reconnecte client utilizes a time-shifte stream as patching stream. The patching stream is use to retrieve the misse vieo portion. At the same time, this client also receives the original stream, this stream is use to catch up the progress of the vieo program. During the Normal Perio 1 tarving Perio Freezing Perio t1 t1+r1 t1+ t1+r1+ t2 t2+r2 t2+ t2+r2+ Fig. 2. Viewing Delay Patching Perio Vieo patching in live streaming We illustrate how the vieo patching scheme works, an how it eliminates inefinite time shifting through an example shown in Figure 2. Assume at time t 1, the client is isconnecte. It rejoins the group by sening out two rejoin signals to the server. One of them is for the original stream, the other is for the patching stream. The client rejoins the original stream at time t 1 + r 1, the misse vieo portion is [t 1,t 1 + r 1 ].It rejoins the patching stream at time t (here, we assume 1 < ), an begins to receive the patching stream s 1 at time t 1 +. At time t 1 + r 1 +, the misse vieo portion is mae up, an the patching channel is release. From this time, the client receives only from the original stream. Assume at time t 2, the client is isconnecte again. At this moment, the client s playing out time is t 1, an its buffer stores the vieo portion of [t 1, t 1 ]. The noe rejoins the original stream at time t 2 + r 2, an the misse vieo is [t 2,t 2 + r 2 ]. It rejoins the patching stream at time t We analyze two cases base on the value of 2. In the first case where 2, the client starts to receive patching stream at t patching perio enotes the time when a client is receiving both the original stream an the time-shifte stream

4 During [t 2,t 2 + ], the client is playing out from the buffer, the client s viewing elay remains unchange. When the client rejoins the tree, it still receives the patching stream from s 1, instea of the other streams with longer time shifting values. In the secon case, where 2 >,say(i 1) < 2 <i, i>1. The client starts to receive patching stream at t 2 +i. During [t 2,t 2 + ], the client is playing out from the buffer, the buffer is exhauste at t 2 +. When the client rejoins the tree at t 2 + i, it receives the patching stream from s i, an the client viewing elay is i. In a general case, if a client suffers the n th isconnection, the client viewing elay shoul be etermine by the formula below: { n n = n =1 n 1 + max( n n 1,) n > 1 olving this formula, we get: t+2tr t+tr t Vieo Progress Normal Perio Initial Delay Fig. 3. Freezing Perio t Viewing Delay Patching Perio Original tream Time hifte tream lient Receive Rate lient Playout t+tr1 t+tr2 t+tr1+tr2 ontinuous vieo streaming with initial elay Time n = max( i ) i [1..n] The client sie viewing elay is etermine by the maximum value of the noe rejoin elay. Thus, the inefinite time shifting can be eliminate.. ontinuous Vieo treaming As we state in previous sections, the combination of a time shifting server an a vieo patching scheme can achieve lossless streaming, an prevent inefinite time shifting. ut there are still some perios that the client s playback is halte, when the client is temporarily isconnecte from the multicast tree. This typically happens when the client is first isconnecte, when the client buffer is empty; or when the client s rejoin time is longer than the playback time of the buffere vieo. To avoi interruption of play out uring the starving perio, buffere vieo accumulate uring an initial playout elay can be use. In our esign, when the client first joins the multicast tree, instea of immeiately playing out the vieo stream, it can buffer the initial part of the vieo for a certain time. This time interval is calle initial access elay. y waiting for an appropriate initial access elay, when there is a service isconnection in the future, the client can still playout the vieo from its buffer instea of stopping the playout. We illustrate our solution in Figure 3. The client connects to the server at time, instea of playing out immeiately, it buffers the initial D time unit vieo. At time D, itbegins to play out the vieo from its buffer, while it keeps receiving from the original stream. As to how large this D shoul be, there is a traeoff between access latency an vieo continuity. Obviously, longer access latency can result in smoother vieo reception. In the case of time shifting without vieo patching, the initial elay shoul be D n i=1 i. If vieo patching is introuce, the initial elay can be reuce to D max( i ) uner non overlapping failures. For etaile analysis, please refer to our technical report [12]. In Figure 3, at time t, the client is isconnecte. ince the client buffer stores vieo [t D, t ], it can still play from the buffer while reconnecting to the server. If the initial elay D is larger than the noe rejoin elay, the client buffer will not be raine out before it is reconnecte to the server. Once the client is reconnecte, it receives the time-shifte (patching) stream as well as the original stream, until the misse vieo is mae up. During this process, the client oes not experience any pause of playout, neither oes it suffer any extra elay. If D is smaller than the noe rejoin elay, then the client sie vieo playback has to be pause. D. An Example of ystem Operations Y Y A (a) the original tree Z (c) patching structure Fig. 4. Y Z Z Y (b) noe A isconnecte Y Z A () new tree The example of system operations Figure 4 shows several snapshots of the application layer multicast tree uring the vieo streaming process. Figure 4(a) shows the multicast tree structure where all the clients in the tree receive the original stream. At time t, noe A leaves the group either ue to congestion or noe failure. This causes Z

5 the subtrees roote at noes Y, an Z to suffer service isconnection. This is shown in Figure 4(b). Noes Y an Z sen rejoin message to server respectively. We escribe the rejoin process for noe Y. Noe Z has similar rejoin process. The rejoin message inclues the rejoin requests for both the original stream an the time-shifte stream. To reconnect the client to the original stream, server selects a client which is currently in the multicast tree as the parent noe of Y. In this case, client is selecte. Noe Y connects with client at time t Y 1, an begins to receive the original stream from it. At the same time, the server allocates a free vieo channel to sen out the patching stream to Y. Assume the server starts to sen out the patching stream at t Y 2, an stream s i is the esignate patching stream, where ty 2 t i =. Figure 4(c) shows the multicast tree structure at time t 1, when both noes Y an Z are in patching perio. Figure 4() shows the tree structure when both patching channels for noes Y an Z are release. We analyze the influence of this service isconnection to noe Y. The chilren of Y suffer the same experience. Noe Y begins to receive the original stream at time t Y 1,itmisses vieo [t,t Y 1 ] ue to service isconnection. The patching stream starts at t Y 2. Assume at time t, the client buffer has b time unit of vieo content. Y playout the vieo content from its buffer, when the client is isconnecte. If b t Y 2 t, then the client still plays vieo from the buffer when the patching stream begins to fee the client. Thus, the client s viewing process is not interrupte, an the client viewing elay remain unchange. Otherwise, the client may suffer a pause of t Y 2 t b.attimet + t Y 2 + t Y 1, the patching perio finishes an the patching stream is release. At this time, the client buffer size is b + max(,t Y 2 t b ). III. DEIGN DETAIL In this section, we escribe our system in etail, incluing the time shifting vieo server esign, an the tree management schemes. A. Time hifting Vieo erver A meia server is the single source for the live vieo content, an is the root of the application layer multicast tree. In this section, we escribe the time shifting vieo server esign in our system. Figure shows the structure of our server esign. The lient Request Aggregator receives four kins of client requests: join, leave, rejoin, an patching en. When the server receives a join request, it contacts the Peer elector to fin the appropriate parent noe 2 to connect with. The Peer elector obtains global topology an resource availability information from the centralize atabase. In the case of a graceful leave, the server signals the chilren of the leaving client to rejoin other parent noes. The server also upates the tree structure an resource availability information upon a noe leave. If a client experiences severe packet loss ue to network congestion 2 Parent noe can be either the vieo server or a client which is currently in the application layer multicast tree. Join Leave Rejoin Patching En lient Request Aggregator Join a client Join erver Peer elector server is parent? hannel Usage Monitor tream elector hannel Release Y hannel Release Tree tructure an Resource Availability Database Fig.. Vieo server Design or ancestor noe failure, it sens a rejoin message to the server. The server then assigns another parent noe to forwar the original stream to it. At the same time, the server also contacts the hannel Usage Monitor, an assigns a free vieo channel to transmit the time-shifte vieo stream to this client. The tream elector is responsible for assigning the client a stream with appropriate time shifting value. When the misse vieo portion has been fully receive, the client sens a patching en message to the server, the server then releases the corresponing patching channel.. hannel Allocation: Our vieo server streams vieo content in two kins of channels. The channel for the original stream is calle the live channel, an the channel for the time-shifte stream is calle the patching channel. The ata rates for the live an the patching channels are the same. Vieo content that is transmitte on a particular channel is multicast to the clients in the application layer multicast tree associate with this channel. hannel allocation eals with whether the channel is use to transmit the original vieo stream or the timeshifte vieo stream. Allocating more channels to the original stream at the server leas to a shorter an wier tree. Reserving more channels for the time-shifte streams means that when the client s rejoin message reaches the server, there is a higher probability that the server has a free patching channel available. In this way, the client can start to receive the patching stream earlier. In this section, we propose three channel allocation schemes, as escribe below. 1) 1:1 Allocation: One way to allocate vieo channels is that whenever a server allocates one live channel to the client, it also reserves one patching channel for this client. We call this allocation scheme, 1:1 allocation. This approach has the benefit that whenever there is a noe failure in the application layer multicast tree of a live channel, there is a free patching channel available for the clients below the faile noe to patch the misse vieo content. Figure 6 shows an example of the 1:1 allocation. As shown hannel Allocator

6 L P L erver D E Patchin tream Live tream (a)tree tructure Li Pi L P L A Fig. 6. 1:1 channel allocation erver Li D Patchin tream Live tream (b) Patching tructure in Figure 6(a), noe A in the multicast tree of channel L i leaves the group. The subtree of noe A manages to rejoin the patching channel P i for the time-shifte vieo stream, as well as rejoin the multicast tree for the original stream. The problem with this channel allocation scheme is that each patching channel is boun with a live channel. If at time t, there are more than one patching channel requests from live channel L i, only one of them can be serve, even though the patching channels for other live channels are left unuse. 2) tatic Multiplexing: To overcome the inefficiency of 1:1 allocation, we propose the static multiplexing allocation scheme. In this scheme, m of the vieo channels are allocate as live channels, while the other n = m channels are allocate as patching channels. There is no fixe bining in this scheme, the patching channel can be use to patch the isconnecte clients from any live channel. L erver erver Li P Pj L Li P Pj D A E Patchin tream Live tream (a)tree tructure Fig. 7. D E Patching tream Live tream (b) Patching tructure tatic multiplex channel allocation Figure 7 shows how this channel allocation scheme works. Noe A of channel L i leaves the group, causing service isconnection for all its chilren. These noes receives the patching stream by rejoining one of the free patching channel P j. Obviously, this scheme is more efficient than the 1:1 scheme, since the vieo patching request will be serve as long as there is a free patching channel available. 3) Dynamic Multiplexing with hannel Merging: In the static multiplexing scheme, the value of m an n is preetermine an fixe throughout the vieo transmission process. A more flexible scheme is to assign the number of live an patching channels ynamically. In this section, we propose a lifetime-base allocation scheme. The lifetime of an original stream is the remaining playback time of the vieo program. The lifetime of the patching stream is the uration of the Pi E D E patching perio. For a vieo program of length T,attime t, the lifetime of the original stream is T t.astothe patching stream, the life time is the time shifting value of this stream; the lifetime for stream s k is k. Our allocation algorithm works as follows: For the patching stream, at time t, the number of patching channels reserve is: m i=1 (i ) P = T t + m i=1 (i ) For the original stream, at time t, the number of vieo channels allocate is: L = P The number of patching channels P is monotonically increasing as the vieo program procees. It is possible that when the server nees to allocate more patching channels, there is no free channel available. We introuce a channel merging scheme to eal with this problem. In this solution, when the server s request for more patching channels can not be satisfie, two live channels that have the fewest number of clients in their multicast trees are merge, an the free channel is use as a patching channel. To merge two live channels, just connect the root noe of the channel with fewest members to the highest possible level of the other channel.. Patching tream election The tream selector in the vieo server etermines which time-shifte stream shoul be use to patch the misse vieo portion for a certain client. When a client is isconnecte from the group, it recors the vieo playback time t, an sens a noe rejoin request to the server. Assume when the server receives this noe rejoin request, the live vieo playback time is t 1. If the server has an available channel at this time, it estimates the connection set up time as t 1 t. This is the time for the rejoin signal to travel from the client to the server. Thus, stream s i is selecte, while i is calculate by the formula below: i = 2 (t 1 t ) If there is no available channel when the rejoin message reaches the server, this rejoin message will be hel until a free patching channel is available. For example, at time t 2. Then the stream s j shoul be selecte, while j is etermine by the formula below: j = (t 2 t )+(t 1 t ) D. Noe join algorithm A well shape application layer multicast tree shoul be wie an short. A shorter multicast tree means a smaller number of overlay hops from a client to the server, thus a smaller average stretch. tretch is the ratio of the latency along the overlay to the latency along the irect unicast path [2], []. The stretch of the application layer multicast tree is the average stretch value over all the clients in the tree. Furthermore, by

7 reucing the number of intermeiate clients, the chance that a client suffers service isconnection ue to ancestor noes leave is also reuce. In this section, we esign a level-base scheme to hanle client join. In this scheme, a newly arriving client joins the noe whose overlay path istance to the server is shortest, an has enough available banwith resource to accomoate a new client. The join algorithm is shown in Figure 8: Join (, ) { 1: joine = false; 2: Push the server IP aress in current list L c ; 3: while (joine==false an L c ) { 4: repeat : Probe the next IP aress p n in L c ; 6: if (p n has enough resource for new client) { 7: join the tree an become p n s chil; 8: joine ==true; 9: } 1: Push the chilren of p n into L n ; 11: until(l c is visite or joine == true) 12: L c = L n ; 13: } 14: return joine; 1: } Fig. 8. Noe Join Algorithm The patching scheme in our esign requires extra banwith for each client, we now analyze how this scheme influences the overall structure of the tree. Assume the banwith of a vieo stream is b, an the average banwith of each host is k b. The height of a tree with N hosts shoul be h 1 log k N. ecause of the use of the vieo patching scheme, each host has to allocate twice the banwith of a vieo stream: one for the original stream, the other is for the patching stream. Thus, the height of the tree is h 2 log k N. Wenowhave: 2 h 2 N 2 log k h 1 log k N = logk logk 1 To further reuce the height of the tree, we esign a highbanwith-first tree join algorithm. The key iea is to push the client with larger banwith up to the higher level of the tree. The multicast tree built by this scheme has the feature that clients in the lower level of the tree o not have more banwith capacity than the clients in the upper level of the tree. Figure 9 an Figure 1 shows the high-banwith-first join algorithm. E. Noe Leave lients in the application layer multicast tree may leave the group at any time. A leaf noe leaving the group oes not have much impact on the application layer multicast tree. An internal noe leaving the group, on the other han, will cause service isconnection for its chilren. There are two WJoin(c,, bw c ) { : joine = false; 2: Push the server IP aress in current list L c ; 3: while (L c ) { 4: Push the chilren of members in L c into L n. : repeat 6: probe the banwith of next host p n in L n ; 7: if (p n s banwith <bw c ) 8: if (Join Level(L c ) == true) return(true); 9: else 1: c becomes p m s parent s chil; 11: p m becomes the chil of c; 12: return(true); 13: if (p n s banwith == bw c ) 14: if (Join Level(L c )==true) return(true); 16: else 17: if (Join Level(L n )== true) return(true); 18: until(l c is visite) 19: if (L n = ) 2: if (Join Level(L c )==true) return(true); 21: L c = L n ; 22: } 23: return joine; 24: } Fig. 9. anwith First Noe Join Algorithm Join Level(L c ) { 1: repeat 2: Probe the next host p a in L c ; 3: if(p a has enough banwith) 4: c join the tree an become p a s chil; : return true; 6: until (L c is visite) 7: return(false); 8: } Fig. 1. Level Join Algorithm kins of leave: graceful leave an noe failure. With a graceful leave, the client first informs the server an its chilren. Its chilren then manage to rejoin the tree by connecting to other parent noes. It leaves the tree after the aaptation of the tree is finishe. In the case of a noe failure, the client leaves the group without informing any other hosts. The tree recovery operation ue to a noe failure is a two step process: First, the faile noe an affecte region 3 etection. econ, isconnecte noes rejoin the tree, this step follows the same operation as the rejoin process uner a graceful noe leave. There are two approaches to iscover the faile noe an the affecte region, as shown in Figure 11. First approach 3 Affecte region of a client c enotes the set of all noes that are isconnecte ue to noe failure of c.

8 is through localize etection. A client that etects a heavy packet loss sens a hello message to its parent noe. If the parent noe is experiencing the same problem, it sens an echo message back to the sener, an sens another hello message to its parent. If the parent noe oes not suffer packet loss, then it is the link congestion between the chil an the parent causing the problem. This process repeats until a client oes not receive echo message from its parent, then either this parent noe is faile or the link between this client an its parent is isconnecte. This approach oes not require global topology knowlege, an etection oes not exert extra loa on the meia server. The problem of this approach is that it might be slow in etecting the affecte region. The other approach is to use the central vieo server. The vieo server maintains the topology of the application layer multicast tree. Each client that suffers service isconnection reports to the server, the server then figures out which noe or link is faile, an the corresponing affecte region. erver faile noe (a)local iscovery Fig. 11. Hello ignal Echo ignal Affecte Region erver faile noe Rejoin ignal Affecte Region (b) entralize iscovery Faile noe iscovery process The noe rejoin process works like this: the affecte clients first try to elect a central noe. A central noe is a chil of the faile noe with enough banwith resource to accommoate all its siblings. If there exists such a central noe, then the central noe rejoins the parent of the leaving noe, an all the chilren of the leaving noe rejoin this central noe as its chilren. If no central noe can be electe, each chil of the leaving noe as well as the sub-tree roote at them rejoins the application layer multicast tree inepenently. IV. PERFORMANE EVALUATION A. imulation Environment etup We use the GT-ITM transit-stub moel to generate a network topology [4] of about 14 routers. The average egree of the graph is 2., an core routers have a much higher egree than ege routers. The meia server an the en hosts are connecte with the ege routers. We categorize the banwith capacity of the en hosts into three levels. 1) Narrow banwith: with 1.Mbps banwith, 7% of the en hosts are in this category. This banwith capacity is only enough for receiving vieo streams. The hosts with such banwith capacity can only be leaf noes in the tree. 2) Meium banwith: with 1Mbps banwith, 2% of en hosts belong to this category. 3) High banwith: with 1Mbps banwith, only 1% of hosts have such high-spee connection. There is one fixe meia server in the topology, it has 1Mbps high spee connection. The time shifting value between stream s i an s i+1 is 4 secons. The server processing capability an I/O capacity is not a bottleneck compare to the server sie banwith. We further assume links between the routers are never a bottleneck.. Evaluation of client vieo reception performance In this section, we stuy the client vieo reception performance in our system. We are intereste in the following performance metrics: client viewing elay, maximum buffer usage, vieo continuity, an vieo completeness. lient viewing elay means the elay between the client sie playback time an the playback time of the original stream. Maximum buffer usage recors the maximum buffer usage throughout a client s vieo reception process. Vieo continuity for a client is evaluate by the uration an frequency of freezing perio. Vieo completeness refers to the rate between the receive vieo an the transmitte vieo. 1) Effect of vieo patching: We first compare the vieo reception performance of a client with or without vieo patching scheme. In this experiment, we recor a client s viewing behavior from the time it first joins the application layer multicast tree until it leaves the group. We assume infinite client buffer size in this simulation. Figure 12 shows the simulation result. Figure 12(a) shows the client viewing elay. Without vieo patching, the client suffers the longest viewing elay. Vieo patching scheme can greatly reuce the viewing elay. As to the buffer usage, vieo patching scheme requires some buffer space to store the vieo packets that is not being playe out. The no patching scheme oes not use any buffer space, as shown in Figure 12(b). Figure 12(c) shows the vieo continuity uring the viewing process. Without vieo patching scheme, the client suffers freezing perio every time it is isconnecte. With vieo patching, the freezing perio is significantly reuce, since the client can still playout the previously buffere vieo content when the subsequent service isconnection happens. We also fin that, if the client starts playout the vieo after an appropriate initial elay, the client can receive continuous vieo stream. 2) Aaptation to ifferent traffic patterns: We now stuy the vieo reception performance of a client uner ifferent traffic patterns. In this experiment, the clients join the multicast tree accoring to a Poisson process, their average time in the group varies from 1s to 3s. We manually insert a client into the group, an it oes not leave the group throughout the simulation process. The simulation time is one hour, we sample the viewing elay for this client every 1 secons, an calculate the average buffer usage uring this 1 secon interval. Figure 13 shows the simulation result. The shorter the average client lifetime, the longer the client viewing elay.

9 lient Viewing Delay (secons) patching no patching patching with init elay uffer Usage (secons) 1 1 patching no patching patching with init elay Patching No Patching Patching with initial elay Freezing Perio Time (econs) Time (econs) Time (secons) Time (secons) Time (econs) (a)viewing Delay (b) uffer Usage (c) Vieo ontinuity Fig. 12. Vieo patching on client vieo reception ince as the clients leave the group more frequently, it is more possible that the client is isconnecte again before the patching perio finishes. In this way, the client has to join later an later time-shifte streams each time it rejoins the multicast tree. The client buffer usage is also increase as the clients join/leave the group in a more frequent manner. ince uner this case, the clients have to join the patching stream with larger time shifting value. This causes longer patching perio, an accumulates more ata in the client buffer. Delay (secons) Avg. lifetime: 1 Avg. lifetime: 2 Avg. lifetime: Time (secons) (a)lient Viewing Delay Fig. 13. uffer Usage (secons) Avg. lifetime: 1 Avg. lifetime: 2 Avg. lifetime: Time (secons) (b) uffer Usage Vieo Patching on viewing performance 3) lient viewing elay istribution: In this section, we focus on the viewing elay for all the clients in the system. In the simulation experiment, we recor the maximum viewing elay of each client, an stuy their overall istribution. The average lifetime of a client is 1 secons. Figure 14 shows the istribution of client viewing elay. The client buffer usage emonstrates very similar istribution. The maximum client viewing elay value is 24 secons. Most of the clients viewing elay is between 4 an 16 secons. The factors that affect the viewing elay are: the client rejoin latency, an the server vieo channel usage conition. The client rejoin latency is mostly etermine by its location in the application layer multicast tree. There are some clients irectly connecte with the vieo server, these clients suffer no viewing elay at all. Those clients further away from other clients ten to nee longer time to rejoin the application layer multicast tree. Another factor that influences the viewing elay DF (%) DF Viewing Delay(secons) Fig. 14. Viewing elay istribution is the server channel usage conition. If the server oes not have a free patching channel available when the client rejoins the tree, the patching stream has to be elaye, as well as the client viewing elay. lients that suffer longer viewing elay also nee more buffer space, since the patching perio tens to be longer.. The effect of vieo patching on tree structure Vieo patching requires extra banwith on the client sie, which reuces the forwaring capability, in terms of fan out, of the clients. Thus, the with of the tree will be reuce. In this section, we stuy the influence of the patching scheme on the structure of the application layer multicast tree, an the average stretch of the en hosts. In this experiment, the clients join the multicast group in a Poisson process, an stay in the group throughout the experiment. Thus, the number of clients in the tree is monotonically increasing. The maximum number of clients in the tree is about 1 in our simulation. The simulation time is 1 ay in this experiment. We compare four tree join algorithms in this experiment: level-base algorithm, with an without vieo patching; highbanwith-first algorithm, with an without vieo patching. Figure 1(a) shows the height of the tree. The level-base tree join algorithm with vieo patching generates the highest multicast tree. The high-banwith-first algorithm promotes the clients with high banwith to the upper level of the

10 Tree Height level-base with patching high bw. with patching level-base no patching high bw. no patching Time (hours) (a)level-ase cheme Fig. 1. Average tretch level-base with patching high bw. with patching level-base no patching high bw. no patching Time (hours) (b) High-W First cheme Influence of vieo patching on tree structure hannel Utilization :1 static multiplexing ynamic multiplexing Time (secons) multicast tree, thus increases the fan out of the tree in the higher level. The height of the tree for the high-banwithfirst algorithm is significantly smaller than the level-base scheme. Furthermore, for the high-banwith-first algorithm, the height of the tree with vieo patching oes not increase much compare to the scheme without vieo patching. Figure 1(b) shows that the level-base tree join algorithm with vieo patching has the worst stretch performance, an is much worse than the same tree join algorithm without vieo patching. For the high-banwith-first scheme, the shape of the tree is optimize, an the height of the tree is comparatively shorter, the stretch performance with or without vieo patching is close to each other. D. erver hannel Allocation cheme The server sie banwith resource (vieo channel) availability etermines the shape of the multicast tree, an the starting time of the patching stream. How to effectively assign server channels is important to the overall system performance, an to the satisfaction of client vieeo reception. We have propose three vieo channel allocation scheme: 1:1, static multiplexing, an ynamic multiplexing. In this section, we evaluate two aspects of vieo channel allocation scheme: 1) vieo channel utilization 2) client queuing elay for the patching channel. 1) erver channel utilization: erver channel utilization means the percentage of the number of channels in use to the number of all the vieo channels. In this experiment, we assume the server can support 1 vieo channels simultaneously. We run the simulation for 1 hour, an recor the average channel utilization value every 1 secons. Figure 16 shows the simulation results. For 1:1 channel allocation scheme, the channel utilization value is worst. In this scheme, half of the vieo channels are allocate as live channel, an each live channel is boun with a patching channel. A patching channel is use only after a service isconnection in the application layer tree of the associate live channel, otherwise, it is free. An the life time of a patching channel is short compare to the live vieo program time. Furthermore, in 1:1 scheme, even if there are multiple rejoin requests in the application layer multicast tree of a live channel, the associate patching channel can only Fig. 16. Vieo erver hannel Utilization serve one request at a time, other requests have to be put into a queue until this patching channel is free. In static multiplexing scheme, we use half of all the vieo channels as live channel, an reserve the other half as patching channel. The channel utilization value is better than the 1:1 scheme. ince multiple rejoin requests from the same live channel can be satisfie as long as there are free patching channels. An the channel utilization has larger variations, since when there are multiple rejoin requests, they are serve simultaneously, instea of one at a time in 1:1 scheme. Dynamic multiplexing with channel merging performs best in terms of vieo channel utilization. In the beginning stage, most of the vieo channels are use as live channel. The channel utilzation value is close to 1%. As time procees, the server nees to reserve more channels for vieo patching. It oes this by merging the live channels with fewest clients, an reserve these channels as patching channel. Thus, there is a egraation in channel utilization. DF(%) :1 static multiplexing ynamic multiplexing Queueing Delay (secons) Fig. 17. lient Requests Queueing Delay 2) lient queueing elay: lient queueing elay refers to the time when the server begins to receive the vieo patching request until the time this requests is being serve. We compare the client queueing elay uner the three vieo channel allocation schemes. We use the same configuration as last section, Figure 17 shows the simulation result.

11 We fin out that the queueing ealy for 1:1 scheme is significantly longer than the other two schemes. ince the patching channels are not share in this scheme. If a noe with many chilren leaves the group, there coul be many rejoin requests at the same time. Uner 1:1 scheme, only one request can be serve at a time, while the other requests have to wait until this patching channel is free. For the other two schemes, they use channel multiplexing, so that the rejoin requests can be serve as long as there are patching channels available. The queuing elay in these schemes is significantly reuce. For the ynamic multiplexing case, when the patching channel is not enough to hanle the rejoin requests, some live channels are merge an use as patching channel. Thus, ynamic multiplexing can further reuce the queueing elay. E. Protocol Overhea Analysis In this section, we consier several aspects of complexity in our system esign. We only give qualitative analysis in this paper, for quantitaive analysis, please refer to our technical report [12]. Message processing overhea: in our system esign, the server has to process four kins of messages: join, leave, rejoin an patching en. We assume the weight for processing these messages is the same. Our noe rejoin message is compose of join live an join patching messages. The patching en message is couple with a join patching message. Assuming there are N noe join message, an M noe rejoin messages throughout the vieo streaming process, the number of messages shoul be: 2 N +3 M. For those no-shifting, no patching solutions, the number of messages is: 2 N + M. For a oopnet solution with m escriptions, each join, leave, rejoin message involves operations over m trees, the number of messages shoul be: (2 N + M) m. Tree management overhea: the vieo server maintains one application layer multicast tree for the original stream, an multiple application layer multicast trees for the patching stream. Note that the patching tree has consierably smaller size an shorter lifetime than the original tree. anwith overhea: although the MD coec use in oopnet introuces some banwith overhea [1], [7], our solution is more banwith intensive. ince we nee to reserve same amount of banwith for each original stream allocate. ut the aoption of the MD approach brings extra overhea such as coing/ecoing complexity, synchronization of multiple streams, etc. V. ONLUDING REMARK In this paper, we eal with the problem of continuous live vieo streaming to a group of cooperative clients. Our solution is centere aroun a time-shifting vieo server, an a vieo patching scheme. The time-shifting vieo server sens multiple vieo streams with ifferent time shifting values. lients in the application layer multicast tree can retrieve the misse vieo content by joining the time-shifte vieo stream. To avoi inefinite time-shifting ue to multiple service isconnection uring the vieo reception process, we introuce the vieo patching scheme. During the patching perio, a client is receiving the time-shifte vieo stream as well as the original stream. The vieo content that is not being playe out immeiately is store in a client buffer. When a subsequent service isconnection occures, a client can play the vieo content from the buffer while rejoining the group. In this way, the client can receive the complete vieo program even though the forwaring infrastructure is unreliable. ontinuous vieo streaming is achieve if the client starts vieo playout after some initial elay. Our esign has the following features: 1) lossless vieo reception: by allowing clients rejoin the time-shifte vieo stream, the client can receive the whole vieo content from the point it first joine the group. 2) stable vieo quality: the client receives full quality vieo throughout the vieo reception process. 3) continuous vieo streaming: continuous vieo streaming can be achieve by sacrificing initial vieo access elay. 4) ompare to oopnet s MD-base system, our system has the avantage that it can use stanar-base single escription encoe streams. ) Moerate complexity: the overhea of message processing an tree management is at the same level with a no-shifting, no-pacthing solution. REFERENE [1] J. Apostolopoulos. Reliable Vieo ommunication over Lossy Packet Networks using Multiple tate Encoing an Path Diversity. In Proceeings of VIP 2. [2]. anerjee,. hattacharjee,. Kommarey calable Application Layer Multicast In Proceeings of AM IGOMM, August 2. [3]. anerjee,. Kommarey, K. Kar,. hattacharjee,.khuller onstruction of an Efficient Overlay Multicast Infrastructure for Real-time Applications To appear in Proceeings of Infocom, 23 [4] K. alvert, M. Doar, an E. Zegura. Moeling Internet topology. IEEE ommunications Magazine, June [] Y.H. hu,.g. Rao an H. Zhang A ase For En ystem Multicast In Proceeings of AM IGMETRI, June 2, [6] Y.H. hu,.g. Rao an H. Zhang Enabling onferencing Applications on the Internet using an Overlay Multicast Architecture In Proceeings of AM IGOMM, August 2. [7] V.K. Goyal, J. Kocevic, R. Arean, an M. Vetterli. Multiple Description Transform oing of Images In Proceeings of IIP, 1998 [8] D. Hrishikesh;. Mayank; G. Hector treaming Live Meia over a Peerto-Peer Network. Technical Report, tanfor, 2 [9] K.A. Hua, Y. ai,. heu. Patching: a multicast technique for true vieoon-eman services. In Proceeings of the sixth AM international conference on Multimeia, [1] Duc A. Tran, Kien Hua, Tai Do ZIGZAG: An Efficient Peer-to-Peer cheme for Meia treaming In Proceeings of Infoom 23. [11] M.. Kim,.. Lam, D.Y. Lee Optimal Distribution Tree for Internet treaming Meia. Technical Report, U.T. Austin, 22 [12] M. Guo, M.H. Ammar calable live vieo streaming to cooperative clients using time shifting an vieo patching. Technical Report GIT- -3-4, ollege of omputing, Georgia Tech, 23. [13] V. N. Pamanabhan, H. J. Wang, P. A. hou, K. ripanikulchai. Distributing treaming Meia ontent Using ooperative Networking. In Proceeings of NODAV 22. [14] V. N. Pamanabhan, H. J. Wang, P. A. hou. Resilient Peer-to-Peer treaming In Proceeings of INP, November, 23. [1] D. A. Tran, K. A. Hua, T. T. Do Peer-to-Peer treaming Using A Novel Hierarchical lustering Approach To appear at IEEE JA pecial Issue on Avances in ervice Overlay Networks, 23 [16] D.Y. Xu, M. Hefeea,. Hambrusch,. hargava On Peer-to-Peer Meia treaming. In Proceeings of ID, 22 [17] L. Zou, E.W. Zegura, M.H. Ammar The Effect of Peer election an uffering trategies on the Performance of Peer-to-Peer File haring ystems. InProceeings of MAOT 22, October 22.