Channel Allocation under Batching and VCR Control in Video-on-Demand Systems

20

Transcript of Channel Allocation under Batching and VCR Control in Video-on-Demand Systems

Channel Allocation under Batching and VCR Control inMovie-On-Demand ServersAsit Dany; Perwez Shahabuddiny; Dinkar Sitaramy; Don Towsleyz1yIBM Research Division, T. J. Watson Research CenterYorktown Heights, NY 10598zDept. of Computer Science, University of MassachusettsAmherst, MA 01003ABSTRACTIn order to to guarantee continuous delivery of a video stream in an on-demand video server environment, acollection of resources (referred a logical channel) are reserved in advance. To conserve server resources, multipleclient requests for the same video can be batched together and served by a single channel. Increasing the batchinginterval results in larger savings in server capacity, however, it also increases the reneging probability of a client.A complication introduced by batching is that if a batched client pauses, a new stream (which may not beimmediately available) needs to be started when the client resumes. To provide short response time to resumerequests, some channels are set aside and are referred to as contingency channels. To further improve resourceutilization, even when a non-batched client pauses, the channel is released and reacquired upon resume. In thispaper, we �rst develop an analytical model that predicts the reneging probability and expected resume delay,and then use this model to optimally allocate channels for batching, on-demand playback, and contingency.The e�ectiveness of the proposed policy over a scheme with no contingency channels and no batching is alsodemonstrated.IBM Research Report, RC 195881This work was partially performed while this author was visiting IBM Research.

1 IntroductionIn a video-on-demand environment, each client sends requests for the playback of a movie of his/herchoice to video servers at a random point in time independently of others [7, 12]. The request can besatis�ed by a new data stream on that movie. In order to guarantee the continuous delivery of a streamto the client, the admission control policy reserves su�cient resources (both at the network as well as atthe server) to deliver a stream prior to initiating the playback of a movie [3, 2, 1, 11]. The collection ofresources required to deliver a data stream is referred to as a logical channel in this paper. If two clientsmake a request for the same movie separated by a small time interval, then by delaying the playbackfor the �rst client, the same server stream can be used to satisfy both client requests [3, 1], i.e., thesame logical channel will be shared by both the clients. In general, batching multiple requests for thesame movie from di�erent clients, and using a single data stream from the video server to multicast [10]to all batched clients,1 can signi�canty reduce the number of channels required by a video server [3].A client may withdraw (renege) his/her requests for the playback of a movie, if the delay is signi�cant [3].The likelihood of reneging increases with the delay. A simple batching policy plays popular (hot) moviesat regular intervals. In order to reduce the overall probability of reneging, the batching intervals for thehottest movies are made shorter than those of the less hot movies. One of the main objectives of thispaper is to determine the optimal allocation of channels and, hence, batching interval for various hotmovies so as to minimize the overall reneging probability. In addition, the allocation policy determinesif it is bene�cial to playback a movie at regular batch intervals or simply to start a new stream ondemand.The batching decision is also in uenced by the probability of pausing by a client while viewing a movie.If a client pauses while watching a batched stream, a new stream may need to be started upon a resumerequest from this client. Unlike the initial starting of the playback stream of a movie, the resume requestcannot be delayed for a long time. Therefore, it con icts with the goal of batching multiple requests.In [4], it is proposed that a few channels should be set aside (referred to as contingency channels) forthe purpose of immediately resuming a stream. In the case of a playback stream that is viewed onlyby a single client it is possible to hold the resources on behalf of that stream even when the clientis in paused state. However, if the pause duration is large, this may result in signi�cant wastage ofserver resources. Therefore, it is preferable that the paused client return the resources to the serverand reacquire them from the contingency pool upon resume [4]. A second important objective of this1The conceptof batching is also used in videotex system [5, 14] where a single page is broadcasted tomultiple requesters.1

paper is to determine the number of channels that should be set aside such that a resume stream canbe started within a small time delay with a very high probability (say 95%).The remainder of the paper is organized as follows. In Section 2, we describe customer renegingbehavior, the resume response time requirement, and how channels are used for batching, VCR control,and on-demand playback. In Section 3 we �rst develop analytical models to estimate the renegingprobability and expected delay in resume for a speci�c allocation of resources. We then use the modelto optimally allocate the resources for various functions: batching, on-demand playback, and resume.The e�ectiveness of the proposed policy for handling batching and VCR-control functions is studied insection 4. Section 5 contains our concluding observations.2 Video-On-Demand EnvironmentClients make requests for the playback of movies of their choice at arbitrary points in time. Prior tostarting the playback of a movie a logical channel is reserved. This corresponds to the set of resourcesrequired for the playback of a stream, i.e., network, disk, CPU, etc. required to guarantee continuousdelivery of the video stream. If multiple clients request the same movie within a short time interval,then multiple requests can be batched together so that a single channel is used to satisfy all clients.However, a client may withdraw his/her request if the delay in starting the playback is signi�cant. Thereneging probability of a client increases with the starting delay.2 A simple batching scheme is to pre-allocate channels for the playback of a movie at regular intervals, referred to as batching intervals, andsatisfy requests for such a movie at the next showing of that movie. The channels associated with thesemovies are referred to as dedicated channels. Access to the movies is non-uniform, i.e., some movies aremore popular than others [2]. We will refer to the movies with dedicated channels as hot movies, andthe remainder as cold movies. Therefore, given a certain video server capacity, selection of the set ofhot movies, as well as the determination of batching intervals for these movies so as to minimize theoverall reneging probability are very important.The remaining movies share a common pool of channels, referred to as on-demand channels. If theprobability of multiple requests for a movie within a short time is small, then very little is gained indelaying the playback of that movie. However, if channels are not pre-allocated to the popular movies,then batching can also be used for the requests sharing the common pool. In [3], various scheduling2In [3] alternative models of client reneging behavior are studied where client reneging behavior is in uenced bymaximum waiting time guarantee. 2

policies are studied that select movies for batching based on various objectives (e.g., minimizing renegingprobability, fairness, etc.). In this paper, we will assume that a new stream is started for each requestto the cold movies, and that requests are served through a FCFS discipline.2.1 VCR ControlA client may choose to stop viewing a movie at any point in the movie, and resume viewing it fromthat point after a random pause duration. If the client is the sole viewer of a stream, then the simplestway to handle such a pause/resume request is to dedicate the channel (i.e., server resources) to thatclient until the end of the movie is reached. However, this can result is in signi�cant wastage of serverresources, particularly if the clients pause on an average for a long duration. While some clients mayresume playback within a short time, others may pause for a long duration, and hence, the averagepause duration can be very high. Alternatively, the sole clients may release their channels and reacquiredi�erent channels upon resumption of playback [4].The delay between the receipt of a resume request from a client and playback needs to be small in orderto assure client satisfaction. One measure of client satisfaction is the probability that the resume delayis less than certain duration, say, Tresume. As an example, a system may be con�gured to guaranteethat 95% of the resume delays are less than 30 seconds. A scheme is proposed in [4] where some channelsare set aside (referred to as contingency channels) for the purpose of achieving client satisfaction. Inaddition, resume requests are given higher priority over new client requests, i.e., if there are no availablecontingency channels the channels from the on-demand pool can be used. This reduces the worst casedelay for a resume request. The contingency channels are also used by the resuming clients that wereviewing batched streams. However, before a new channel is allocated to such clients, it is checked tosee if there is another stream within Tresume that can be used by this client.2.2 Channel AllocationThe channels are divided into three groups, dedicated, on-demand, and contingency channels. A videoserver needs to be con�gured with a su�cient number of channels to satisfy two objectives:1. Reneging probability: The overall reneging probability must be less than �1.2. Resume delay: No more than a fraction, �2, of the resume delays are greater than Tresume.3

To minimize the required number of channels to satisfy the above two objectives we are concerned witha number of questions.1. how to partition the movies into hot and cold classes.2. given a partition of movies into hot and cold classes, how many channels should be allocated toeach of the hot movies, to the cold movies and to the contingency pool.A solution to the above allocation problem can be used in various ways in a real system. In the designphase, it can be used as to con�gure the system, that is to determine how many channels are requiredfor certain workloads and objectives. In an existing system, it could be used to recon�gure the systemas the workload changes. Note that, here we assume for the purpose of analysis a strict partitioning ofchannels into three categories. However, in a real system a more dynamic policy will be used that notonly adapts to the changes in the workload in terms of movie access pattern, but also changes the sizeof the contingency pool (by admission control of new requests and giving higher priority to the resumerequests) to cope with surges in VCR-control activity (see, Figure 1). The set aside server capacity forVCR control is a function of the number of viewing clients, the number of playback streams, and thenumber of paused clients [4].3 Optimal Allocation of ChannelsIn this section, we �rst develop an analytical model for estimating the reneging probability and resumedelay for a speci�c allocation of resources. We then use the model to optimally allocate channels to thethree classes: dedicated, on-demand and contingency. The allocation has to be done in such a way sothat the overall reneging probability and the resume delay lie within certain pre-speci�ed limits.3.1 Analytical ModelThere are K movies labelled k = 1; 2; : : : ;K. Requests to view movie k arrive according to a Poissonprocess with rate �k where �1 � �2 � � � � � �K . Let �tot be the sum of all these arrival rates. Letpk(x) denote the probability that a new request leaves (reneges) if it has to wait at least x time units.We choose a reneging function that is characterized by two parameters, Lk > 0 and nk � 1,:pk(x) = � (x=Lk)nk 0 � x � Lk1 otherwise4

Note that the probability that a customer, who arrives at least Lk time units prior to the beginning ofthe playback, leaves is 1.Initially, a client is labelled as a �rst-timer. However, as soon as a client pauses the movie, he/she isrelabelled as a second-timer. We will occasionally refer to these as type 1 and type 2 clients, respectively.Upon restarting a movie, a second-time client can be handled in one of two di�erent ways. If the client isviewing a hot movie, k, and he/she can join one being shown through a dedicated channel within someshort period of time, say of length tk, then he/she does so. (In our example, we choose tk = Tresumefor all movies.) In all other cases, the client queues for a contingency channel.Let Nk be a r.v. (random variable) denoting the number of times that playback of movie k is paused.We assume that Nk has a geometric distribution, i.e., P (Nk = j) = (1 � k)j k for j = 0; 1; 2; : : :.Let Sk denote the length of movie k. We assume that the pauses are uniformly distributed over thelength of movie. Let S1k denote the time duration that a �rst time client views movie k until he/sheeither pauses the movie or it completes. Let S2k denote the time between resume and the next pause (orcompletion of the movie) and let F ik(x) = Pr[Sik � x] and 1=�ik = E[Sik]. Without any loss of generalitywe will assume that �ik = �i for all movies. If movie k is paused j times, then S1k will have a mean ofSk=(j + 1). Hence E(S1k) = 1Xj=0 P (Nk = j)Sk(j + 1) = � log( k) kSk(1� k) :Given that Nk = j; S2k will also have a mean of Sk=(j + 1): Furthermore, there are j pauses. Hence,E(S2k) = P1j=0 P (Nk = j)jSk=(j + 1)P1i=0 P (Nk = i)i = k(1� k) (Sk �E(S1k)):We will now calculate the reneging probabilities for �rst time requests for hot and cold movies and thengo on to compute the expected resume delay.3.1.1 Estimation of Reneging Probability for Batched MoviesLet the �rst M movies be considered hot. Let xk denote the number of channels allocated to moviek, 1 � k � M . Movie k will be started periodically with period equal to Sk=xk. Let Pk(t) denote thefraction of clients making requests for movie k in an interval of length t that leave given that the moviedoes not begin until the end of the interval. It is given asPk(t) = 1t Z t0 pk(y)dy:5

This is because, due to the Poisson assumption, requests arrive uniformly in [0; t]. Using the earlierdescribed reneging function, we can calculate Pk(t) for 0 � t � Lk as:Pk(t) = 1(nk + 1) � tLk�nk :Note that the probability of a type 1 customer leaving in an interval of length Lk is given by 1=(nk+1).For example, for nk = 2, this probability is 0:3333. We do expect the reneging probability in a realsystem to be much smaller, and hence, the batching interval will be smaller than Lk. Hence, for thehot movies we are interested only in the values of Pk(t) for t � Lk. This will make the function Pk(t)concave in t for 0 � t � Lk.3.1.2 Estimation of Reneging Probability for Cold MoviesConsider now the cold movies. Let y1 denote the number of channels allocated to the cold moviesfM + 1; : : : ;Kg. We assume that the fraction of clients lost due to impatience is negligible for thepurpose of computing the waiting time for a movie to start. Hence, the waiting time of a clientcorresponds to that of a M=G=c queue with c = y1, arrival rate M �PKk=M+1 �k and service rate �1.For large values of c we conjecture that the customer waiting time at a M=G=c queue will be very closeto that at a M=M=c queue with the same mean service time. Let W1 denote the waiting time in thisM=M=c queue. Let gk(y1) denote the fraction of customers that become impatient and leave. Thengk(y1) = R10 pk(t)dFW (t; M ; �1; y1) where FW (t;�; �; c) is the waiting time distribution function for aM=M=c queue with arrival rate � and service rate �. FW (t;�; �; c) is given by (see [9])FW (t;�; �; c) = 1� c(�=�)ce�(�c��)tc!(c� �=�) p0(�; �; c); t � 0:Here p0(�; �; c) is the probability that the system is idle and is given byp0(�; �; c) = "c�1Xn=0 �nn!�n + c(�=�)cc!(c� �=�)#�1Using the reneging function described before we can compute g1k(y1) as:gk(y1) = Z Lkx=0 pk(t)dFW (t; M ; �1; y1) + Z 1x=Lk pk(t)dFW (t; M ; �1; y1)= � 1Lk�nk 1(y1 � 1)! M�1 y1�1p0( M ; �1; y1) Z Lkt=0 tnke��1y1 M tdt(1� FW (Lk))6

= � 1Lk�nk 1(y1 � 1)! M�1 y1�1p0( M ; �1; y1)f( M ; �1; y1; nk; Lk)(1� FW (Lk))where f( M ; �1; y1; nk; Lk) = nk!(�1y1 � M )nk+1 "1� nkXi=0 [(�1y1 � M )Lk]ii! e�(�1y1� M )Lk# :3.1.3 Estimation of Mean Resume DelayIn order to determine the rate at which resume requests arrive at the contingency pool, we have thefollowing assumptions.� The arrival of second-time requests to the contingency pool for hot movie k is governed by aPoisson arrival process with rate �kE[Nk][Sk=xk � tk]+=(Sk=xk) = �kE(Nk)[Sk � tkxk]+=Sk,k = 1; : : : ;M . Here [x]+ = max(0; x).� The arrival of second-time requests to the contingency pool for cold movie k is governed by aPoisson arrival process with rate �kE[Nk], k = M + 1; : : : ;K.� The arrival processes are mutually independent from movie to movie.� The service times are exponentially distributed r.v.'s with a mean 1=�2 that does not depend onthe movie.This allows us to model the contingency channels as a M=M=c queue with c = y2 and an arrival rategiven by 0 = MXk=1�kE(Nk)[Sk � tkxk]+=Sk + KXk=M+1�kE(Nk):The probability that a type 2 request for the kth movie will have to wait for more than tk units of timeis given by: qk(x1; x2; : : : ; xM ; y2; tk) = R1t=tk dFW (t; 0; �2; y2) = 1� FW (tk : 0; �2; y2).3.2 Optimal AllocationWe are now faced with the following optimization problem, which we call P:7

minimize PMk=1 xk + y1 + y2subject to xk = 0; 1; 2; : : :,y1; y2 = 0; 1; 2; : : :,M = 0; 1; 2; : : :K,�PMk=1 �kPk(Sk=xk) +PKk=M+1 �kgk(y1)� =�tot � �1qk(x1; : : : ; xM ; y2) � �2 for k = 1; 2; : : :KClearly this is a very complex problem. To simplify this problem, �rst of all we need to search overall M . This is not very di�cult as in most applications M is not that large. But even then, sinceqk(x1; : : : ; xM ; y2) does not appear to be a concave function, the problem is still very di�cult. Hencewe settle for a sub-optimal solution. We remove the resume delay constraint and only �nd the minimumof the sum of the hot and cold channels needed to satisfy the reneging constraint. Using the arrivalrate for the contingency queue generated from this solution, we calculate the minimum number ofcontingency channels needed to satisfy the resume delay constraint. We will see that even this sub-optimal solution yields signi�cant savings in the number of channels over schemes that do not usebatching and contingency channels.More formally, consider the optimization problem P 0(M ), given by:minimize PMk=1 xk + y1subject to xk = 0; 1; 2; : : :,y1 = 0; 1; 2; : : :,�PMk=1 �kPk(Sk=xk) +PKk=M+1 �kgk(y1)� =�tot � �1Let x�1(M ), x�2(M ), : : : , x�M(M ) and y�1(M ) be the optimal solution of this problem. Also let C�(M )be the optimal value of the objective function. We use a search procedure to determine the minimumy2 so that qk(x�1(M ); : : : ; x�M(M ); y2) � �2. Call this y2(M ). Then the problem is to �nd the optimalM so that C�(M ) + y2(M ) is minimized. We will call this M�.Now we will describe an iterative procedure for the solution of P 0(M ).3.2.1 Solution of P 0(M )Consider the following optimization problem which we call P 00(ch).minimize PMk=1 �kPk(Sk=xk)=�totsubject to xk = 0; 1; 2; : : :,PMk=1 xi = ch8

The solution of this problem gives the best allocation of ch channels among the hot movies. We will solvea continuous approximation to this problem, i.e., remove the integer constraints. Since the objectivefunction is concave in xk we can use the Lagrange multiplier approach. More precisely, letL = L(x1; : : : ; xM) = MXk=1�kPk(Sk=xk)=�tot � � MXk=1xi � ch!where � is the Lagrange multiplier. Then a solution to P 00(ch) is optimal if and only if it satis�es thefollowing equations:@L@xk = ddxk � �k�totPk(Sk=xk)�� � = �k�tot nknk + 1 �SkLk�nk 1xnk+1k � � = 0; k = 1; : : :M (1)and @L@� = �( MXk=1xi � ch) = 0: (2)From Equation 1 we get that xk = �Dk� �1=(nk+1) (3)where Dk is the constant Dk = �k�tot nknk + 1 �SkLk�nk :Subsitituting this expression for the xk's in Equation 2, allows us to solve for �,� = PMk=1D1=(nk+1)kch !nk+1 :Substituting this in Equation 3 yields the optimal value of the xk's. By rounding o� the xi's tothe nearest integer ( so that PMk=1 xk is still equal to ch) we can �nd an \approximate" optimalinteger solution. Since the solution obtained for the continuous case is an upper bound on the optimalinteger solution, we can �nd out the worst case error between the optimal integer solution and the\approximate" optimal integer solution. Intuitively, if ch is large then this error will tend to be small.Hence we have a closed form solution for the problem P 00(ch). Let OBJ(ch) be the optimal value of theobjective function. Note that because the objective function is concave, OBJ(ch) will also be concavein ch.To solve P 0(M ) we use a version of Fox's algorithm [6, 8]. This is because, in addition to Pk(t) beingconcave, empirical investigation shows that gk(y1) also is concave for the values of y1 for which theon-demand queue is stable, i.e., y1 > M=�1 (�gure 2 shows one such case). We start with a smallnumber of channels: we allocate enough channels to the cold movies so that the cold queue is stable9

and we allocate enough channels to the hot movies so that the batching duration Sk=xk � Lk. Thenfor each additional channel we bring into the system, we compute the marginal decrease in the renegingprobability due to its allocation to to the hot channels as well as due to its allocation to the coldchannels.More precisely, suppose that currently ch channels have been allocated to the hot movies and y1 chan-nels to the hot movies and still the overall reneging probability is greater than �1 (hence we needto allocate more channels). We increase the number of allocated channels by 1 and determine whereto allocate it. For this we compute OBJ(ch) � OBJ(ch + 1) as well as PKi=M+1(�k=�tot)gk(y1) �PKi=M+1(�k=�tot)gk(y1 + 1): We allocate the extra channel to where the di�erence is the greatest. Wecontinue allocating more channels until the overall reneging probability falls below �1.4 Experimental ResultsIn this section we consider an example of a video-on-demand system and use it to study the e�ect ofbatching and contingency on the total number of channels required. We will see that the combinationof batching and contingency can reduce the total number of channels allocated signi�cantly.We consider a system with 100 movies. Relative frequencies, fk; k = 1 : : :K, for the movie k follow aZipf distribution, fk = c=k(1��) with the parameter � and normalization constant c. The parameter� has been taken from the earlier work on scheduling of video on demand systems as 0.271 (see [3]).The total arrival rates of the movies, �tot, is taken to be 50 per minute and we assume a movie length,Sk, of 120 minutes for all k. The reneging function parameters, nk and Lk are taken to be 2 and15, respectively, for all k. We will compute the required total number of channels to guarantee thatthe fraction of �rst timers lost due to reneging, �1, is less than 5%. In the cases where we considercontingency channels, we will guarantee that than no more than 5% (�2) of the resume delays aregreater than 30 seconds (Tresume). Unless otherwise speci�ed, the mean number of pauses for a movie,E(Nk), is taken to be 1 for all k and the average pause duration is taken to be 15 minutes. In orderto study the e�ect of contingency and batching, we vary some of these parameters from their nominalvalues. 10

4.1 E�ect of ContingencyFigures 3 through 8 examine the e�ect of contingency on the required number of channels in the casewhere we have no batching (M = 0). Figure 3 studies the variation in the required number of channelswith an increase in the mean number of pauses. Three di�erent arrival rates are considered. Note that(for each arrival rate) with no contingency, the required number of channels increases approximatelylinearly as a function of the mean number of pauses. This is because, increasing the mean number ofpauses (with the pause duration �xed) causes a linear increase in the time a request holds a channel.However, if we make provisions for contingency, then the required number of channels remains almostconstant with an increase in the mean number of pauses. This is explained further in Figure 4 for thecase where the arrival rate is 50. As the mean number of pauses increase, the number of contingencychannels obviously increases since the arrival rate to the contingency queue increases. At the same timethe expected service time of �rst timers go down, resulting in the decrease in the required number ofchannels for �rst play. As the amount of waiting in the contingency queue is almost negligible, thesystem behaves like a work conserving system with the result that the total number of channels remainsconstant. In Figure 5 we further examine the case where the arrival rate is 50, for di�erent pausedurations. As expected, in the case of no contingency, the slope of the line increases with increasingpause duration, whereas it has no e�ect in the case with contingency.An important parameter in a movie on demand system, from the client point of view, is Tresume. Forexample, what happens if we select Tresume to be 15 secs instead of 30 secs. Will the number ofrequired channels increase dramatically? Figure 6 studies the e�ect of varying Tresume on the totalrequired number of channels. Fortunately, we see that changing Tresume has negligible e�ect on thetotal required number of channels. This is explained by Figure 7. It considers the scenario where themean number of pauses is equal to 1 (thus the mean service time at the contingency queue is 36.8minutes) and the arrival rate to the video on demand system is 50 per minute. The optimal numberof contingency channels in this case is 1819 and the arrival rate to the contingency queue is 47.63 perminute. Let the state at any given time be de�ned to be the number of contingency channels that arebusy at that time. The �gure shows the long run fraction of time the system spends in each state.Note that very rarely is the system fully busy (only around 0:3% of the time). So the fraction of secondtimers who have to wait at all is very small. And adding no or few contigency channels channels isenough to handle the change in Tresume.Figures 9 and 8 show the variation in the required number of channels for increasing arrival rate. Cases11

with and without contingency are considered. First consider the case with contingency. Increasingthe total arrival rate while keeping the mean number of pauses �xed, has the e�ect of a proportionateincrease in the arrival rate for both the �rst timer queue and the contingency queue. (The average servicetime remains constant for both the queues.) It is interesting to note that, in all cases, the requirednumber of channels increases (approximately) linearly with the arrival rate into that particular queue.This is evident in Figure 8, where both the number of contingency channels and the channels for �rsttime play increase approximately linearly with the arrival rate. The same linear relationship is true inthe case of no contingency. However, now the slope of the curves in Figure 9 increases as the meannumber of pauses increases, due to a corresponding increase in the expected service time.4.2 E�ect of BatchingIn [3], it was found that batching reduces the total required number of channels in systems which do notsupply VCR control. In this study we further improve this technique by optimizing over the batchingintervals. In addition we investigate the performance of batching in conjunction with contingencychannels for e�ective VCR control.Figure 10 depicts the variation in the optimal number of movies that are batched (M�) with increasingarrival rate. Note that as the arrival rate increases more and more movies are batched, until a certainpoint when we only have batching in the system (where the curve becomes a horizontal line). Figure10 also studies the e�ect of skew on the number of movies that are batched. This we do by varying theZip�an constant �. Setting � = 0 generates a distribution with a high skew, whereas � = 1 generatesa uniform distribution over all movies. Note that if the skew is high, then the number of movies to bebatched increases very slowly as there is not much incentive to include movies with the lower arrivalrates.Figure 11 shows the optimal batching intervals for each of the hot movies. We consider two di�erentarrival rates: 50 requests/minutes and 20 requests/minutes. Note that for the case of arrival rate =50 requests/minutes the batching interval varies anywhere from 2 minutes for the hottest movies to 10minutes for the least hot movie. If we choose the same batching interval for all hot movies, even thoughwe have assumed the same reneging behavior for all movie requests, the actual number of requests thatrenege will be more for the hottest movies than for the less hot movies.Figure 12 shows the average waiting times for �rst time requests for cold movies and hot movies. Thereis one interesting observation that can be made from this �gure: on demand movies have much lower12

waiting time than batched movies. Because batched movies have an upper bound on the amount oftheir wait, we can make them wait much longer on the average than on demand movies, and at thesame time have almost the same reneging probability for both hot and cold movies.Figure 13 shows how the contingency capacity increases as the mean number of pauses increases.Increasing the mean number of pauses produces a linear increase in the arrival rate to the contingencyqueue. Under normal circumstances this increase would have led to a linear increase in the numberof channels required, had it not been for the fact that the expected service time at the contingencyqueue, E(S2k), also decreases as the mean number of pauses increases (as the movie length is �xed). Theexpected time to the �rst stop (pause or �nish) of the movie E(S1k), also decreases resulting in a slightdecrease in the channels required for �rst timers. The overall result is an increase in the total numberof channels required as the mean number of pauses increase. Figure 14 compares this total number ofchannels to the total number of channels for the case of no batching. This is done for three di�erentarrival rates. We see that the improvement gained by batching decreases as the mean number of pausesincreases.Figure 15 shows the e�ect of changing Tresume on the required number of channels, with batching. Asin the case with no batching, changing Tresume has little e�ect on the required number of channels.In Figure 16, we study the variation in the required number of channels with increasing arrival rate.Such a curve may be used by the system designer to con�gure the system. As expected the increasein the required number of channels is much smaller for systems with batching than systems withoutbatching. Also, beyond a certain arrival rate all movies are batched (refer to Figure 10). From thatpoint on, there is no need for additional channels to satisfy �rst time requests. Hence the batchingintervals do not change and the fraction of the second time requests that go to the contingency queuedoes not change either. Hence from that point on, the arrival rate to the contingency queue increaseslinearly with the total arrival rate. Thus we see that (in the case of batching) the increase in the totalnumber of channels soon becomes linear in the arrival rate.Finally, we study the e�ect of skew on the total required number of channels. This is depicted inFigure 17. Note that, due to the optimization, the skew has very little e�ect on the total requirednumber of channels. 13

5 Future WorkWe are currently working on dynamic policies that adapt to changes in the workload and dynamicallydetermine the number of contingency channels that should be set aside. We are also working on theextensions to the policy where all resources can not be shared by all streams.5.1 Partitioned ResourcesA channel consists of various types of resources: disk bandwidth, CPU bandwidth, network bandwidth,etc.. A stream can be started only if enough resources of each type required to deliver a stream areacquired. If the resources released by a stream can be reused by another stream then we refer to thoseresources as shareable between these streams. For example, if all the video �les are striped across alldisks in the system, then the total disk bandwidth (i.e., sum of the bandwidths of all disks) in the systemis shareable amongst all streams irrespective of the video �les being accessed by various streams. Ifall the resources in the system is shareable then the channel allocation and admission control for thepurpose of vcr control need to be applied only to the bottleneck resource. Otherwise admission controlneeds to ensure enough contingency capacity for each type of resource.Figure 18 shows an abstract view of resource sharing across various types of streams. A stream typeis de�ned by the set of resources it requires to form a complete channel. For example, to deliver datafrom certain video �les to a set of viewers, appropriate bandwidth needs to be reserved on the disks onwhich the video �les are stored, on the CPU to which the disks are connected and on the network thatconnects these viewers to the server. Based on the sharing characteristics, resources can be groupedinto shareable resource classes such that, within a class, resources are interchangeable. In the �gure,each box represents a shareable resource class, such as disks, CPU, etc.. The stream type A requiresresource class I, III and IV. Resource class III is shareable across all stream types, while resource classI is shareable across stream types A and B, and resource class V is shareable across stream types B andC.In a partitioned environment, to satisfy vcr control requirements, su�cient contingency capacity has tobe set aside for each resource class. The demand on a resource class is estimated as the total demandby all stream types on that resource class. 14

6 Summary and ConclusionsIn order to guarantee continuous delivery of a video stream, in an on-demand video server environment,su�cient resources are reserved in advance. This set of resources is referred to as a logical channelin this paper. Multiple client requests for the same video can be batched together so that a singlevideo stream can be used. An increase in the batching interval, however, also increases the renegingprobability of a client. If a client pauses while viewing a batched stream, a new stream needs to bestarted upon resume of this client. To provide a prompt response to a resume request, some channels,referred to as contingency channels, are set aside. In order to improve resource utilization, a channel isreleased when a sole client viewing a stream pauses and is reacquired from the contingency pool uponresume. In this paper, we �rst developed an analytical model that predicts the reneging probability andexpected resume delay and then used the model to optimally allocate channels for batching, on-demandplayback, and contingency.The e�ectiveness of the proposed policy over a system with no contingency channels and hence, nobatching is also demonstrated. A signi�cant reduction in required channel capacity is achieved in mostcases, particularly for higher arrival rates and longer pause durations. The optimal allocation can beused both during initial system con�guration as well as a guide for recon�guring the system to adapt tochanges in the workload pattern. We are currently working on dynamic policies that adapt to changesin the workload and dynamically determines the number of contingency channels that should be setaside.References[1] Anderson, D. P., \Metascheduling for Continuous Media," ACM Transactions on Computer Systems,Vol. 11, No. 3, August 1993, pp. 226{252.[2] Dan, A., and D. Sitaram, \Bu�er Management Policy for an On-Demand Video Server", IBM ResearchReport, RC 19347, Yorktown Heights, NY, 1994.[3] Dan, A., D. Sitaram, and P. Shahabuddin, \Scheduling Policies for an On-Demand Video Server withBatching", IBM Research Report, RC 19381, Yorktown Heights, NY, 1994.[4] Dan, A., D. Sitaram, and P. Shahabuddin, \Scheduling Policies with Grouping for providing VCR ControlFunctions in a Multi-media Server", U.S. Docket No YO993-030, 1994 (patent pending).[5] Dykeman, H. D., M. H. Ammar, and J. W. Wong, \Scheduling Algorithms for Videotex Systems underBroadcast Delivery", Proc ICC'86, 1986, pp. 1847{1851.[6] Fox, B., \Discrete Optimization via Marginal Analysis," Management Science, Vol. 13, November 1966,pp. 210{216.[7] Fox, E. A., \The Coming Revolution in Interactive Digital Video," Communication of the ACM, Vol. 7,July 1989, pp. 794{801.[8] Ibaraki, T., N. Katoh, Resource Allocation Problems, MIT Press, 1988.15

[9] Kleinrock, L., Queueing Systems, Volume 1: Theory, John Wiley and Sons - New York, Chichester, Bris-bane, Toronto, 1975, pp 105.[10] Le Boudec, J.-Y., \The Asynchronous Transfer Mode: A Tutorial," Computer Networks and ISDN Systems,Vol. 24, 1992, pp. 279{309.[11] Rangan, P. V., H. M. Vin, and S. Ramanathan, \Designing an On-Demand Multimedia Service," IEEECommunication Magazine, Vol. 30, July 1992, pp. 56{65.[12] Sincoskie, W. D., \System Architecture for a Large Scale Video On Demand Service," Computer Networksand ISDN System, Vol. 22, 1991, pp. 155{162.[13] Video Store Magazine, Dec. 13, 1992.[14] Wong, J. W. and M. H. Ammar, \Analysis of Broadcast Delivery in a Videotex System", IEEE Transactionson Communications, Vol. 34, No. 9, September, 1985, pp. 863{866.

16

Admission control

Active

resource

Free

Contingency

resource

resource

&Scheduling

resume

pause,end

startFigure 1: Admission controller and scheduler in avideo serverFigure 2: Concavity of the reneging probability forthe cold movies as a function of the number of serversFigure 3: E�ect of contingency (no batching case)

Figure 4: Variation in contingency capacity with in-creasing number of pauses (no batching case)Figure 5: E�ect of pause duration (no batching case)

Figure 6: E�ect of TResume (no batching case)17

Figure 7: Steady state distribution of number of busychannels in contigency queueFigure 8: Variation in contingency capacity with in-creasing arrival rates (no batching case)Figure 9: E�ect of contingency (no batching case)

Figure 10: E�ect of skew on (optimal) number of hotmovies (mean number of pauses = 0)Figure 11: Batching duration for hot moviesFigure 12: Mean waiting times before service18

Figure 13: Variation in contingency capacity with in-creasing number of pausesFigure 14: E�ect of batching on the required servercapacity

Figure 15: E�ect of TResume

Figure 16: E�ect of batching on the required servercapacityFigure 17: E�ect of skew on (optimal) server capacity

Stream Type

A B C

Resource Class

Stream Type Stream Type

Resource Class

Resource Class

Resource Class Resource Class

I II

III

IV VFigure 18: Video server environment with partitionedresources19