Efficient Broadcasting Protocols for Video on Demand Jehan-François Pâris y Department of Computer cience University of Houston Houston, TX 7704-3475 paris@cs.uh.edu teven W. Carter Darrell D. E. Long z Department of Computer cience Baskin chool of Engineering University of California, anta Cruz anta Cruz, CA 95064 fcarter, darrellg@cse.ucsc.edu Astract Broadcasting protocols can improve the efficiency of video on demand services y reducing the andwidth required to transmit videos that are simultaneously watched y many viewers. We present here two roadcasting protocols that achieve nearly the same low andwidth as the est extant roadcasting protocol while guaranteeing a lower maximum access time. Our first protocol, cautious harmonic roadcasting, requires somewhat more andwidth than our second protocol, quasi-harmonic roadcasting, ut is also much simpler to implement. Keywords: video on demand, video roadcasting. Introduction Video on demand (VOD) proposes to provide cale television suscriers with the possiility of watching the video of their choice at the time of their choice, as if they were watching a rented video cassette. Despite the attractiveness of the concept, so far VOD has not een a commercial success ecause the technology is still very expensive and its potential users are unwilling to pay much more for a VOD selection than they are used to paying for a video cassette rental. Broadcasting is one of several techniques that aim at reducing the cost of VOD []. It is clearly not a panacea as it only applies to videos that are likely to e watched y many viewers. Even so, the savings that can e achieved are nevertheless considerale, as it is often the case that 55 percent of the demand is for the 0 most popular videos [,3]. A naive roadcasting strategy would simply consist of retransmitting the same video on n distinct channels at equal time intervals d = D=n,whereD is the duration of the video eing roadcast. The major prolem with this approach is the numer of channels per video required to achieve a reasonale access time. Assuming an average video duration of 0 minutes, 4 channels per video would e required to guarantee that no customer would ever have to wait more than 5 minutes. y On saatical leave at the Department of Computer cience, University of California, anta Cruz. z This research was supported y the Office of Naval Research under Grant N0004 9 J 807. Viswanathan and Imielinski [4] have proposed a etter solution that assumes that the clients can receive and store some segments of a video while watching other segments. Their pyramid roadcasting protocol has een followed y several more recent proposals among which we should mention Aggarwal, Wolf and Yu s permutation-ased pyramid roadcasting protocol [5], Hua and heu s skyscraper roadcasting protocol [6] and Juhn and Tseng s harmonic roadcasting protocol [7]. Of all these protocols, harmonic roadcasting is the one promising the lowest andwidth cost to achieve a given access time. However, this excellent performance is marred y the fact that harmonic roadcasting sometimes fails to provide actual on-time delivery of all frames. Juhn [8] suggested that this prolem could e fixed y slightly delaying the moment at which the clients start consuming the video. While this extra uffering solves the prolem, it also very significantly increases the video access time and reduces the competitive advantage of harmonic roadcasting over its rivals. We present here two variants of the harmonic protocol that do not impose on their end-users any additional delay efore they can egin viewing the video they ordered. The first protocol, cautious harmonic roadcasting, entirely avoids the prolem y guaranteeing that all frames of any video segment transmitted at a reduced andwidth will e effectively present in the client memory efore it starts playing that segment. The second protocol, quasiharmonic roadcasting, modifies the organization of the segments to ensure on-time delivery of all frames under all conditions. While more complex than either harmonic roadcasting or cautious harmonic roadcasting, quasi-harmonic roadcasting offers a guaranteed on-time delivery of all frames without any significant andwidth penalty. Harmonic Broadcasting Harmonic roadcasting (HB) [7] reaks a video into n equally-sized segments. If the length of the video is D and the consumption rate of the video is,then = D is the size of the video, and each segment i,for i n,has size =n. HB then dedicates n streams for the video, and each stream i repeatedly shows segment i with and-
tream : tream : tream 3: d,,,, 3 3, 3, 3,3 3, Figure : An illustration of the first three channels for a video under harmonic roadcasting. width =i (see Figure ). The client must wait for the eginning of an instance of segment efore it can start receiving (and viewing) data. Once it starts receiving segment, it will also start receiving every other stream dedicated for the video. That means the client and the VOD server must e ale to support a andwidth of B HB = i= i = i= i = H(n) where H(n) is the harmonic numer of n. H(n) grows very slowly, so even for large values of n, B HB is likely to e less than six times the data consumption rate. We define a slot as the amount of time it takes for the client to consume a single segment of the video, and we represent this time y d. Thus, we have d = = D n and note that d is also the maximum amount of time a client must wait efore receiving data. We also define a susegment as the part of a segment the client receives during a slot. ince the first stream uses andwidth equal to the consumption rate, it only has a single susegment, the segment itself. Every other stream i will divide the segment into i equal susegments, i;, i; ;::: ; i;i. Note that since the client will e receiving video data out of order, it will require local uffer space within the customer set-top ox. The uffer space needs to e large enough to hold slightly less than 40 percent of the size of the video [7]. Using an example of MPEG- encoding and a two-hour video, the uffer would need to e approximately 500 megaytes in size. The main idea ehind HB is that when the client is ready to consume segment i, it will have een receiving data for i, slots of time. o the client will have i, of the i susegments of segment i in its uffer, and it will receive the last susegment while it is consuming the full segment. It is at this point that HB reaks down. Claim Harmonic roadcasting does not always deliver all data on time. Proof: Refer to Figure and consider a client who arrives just in time to egin receiving the second instance of segment. Call the time when the client egins receiving data t 0. At time t 0 + d, the client will e ready to consume segment and it will have one susegment of the segment, ;, in its uffer. However, it will require all of the data from susegment ; y time t 0 +3d= ut it will not receive it until time t 0 +d. ince the prolem with HB involves data not eing at the client in time, a straightforward solution is to have the client simply delay a certain amount of time efore consuming data. Clearly, a delay of one slot would work; the client would then have all i susegments of i efore consuming it. As we will see, the minimum required delay is not much lower. Claim Harmonic roadcasting requires the client to wait for (n, )d=n units of time. Proof: As efore, assume that the client egins receiving data at time t 0. Now consider any stream i. The worst case for the VOD server occurs when the client receives the first susegment of stream i last. This is ecause the client will require all of the data from that susegment efore the data from any of the other susegments. The client can consume the first susegment while it is receiving the susegment as long as all of the data from it will arrive at the client in time. ince the data from the first susegment will not finish arriving at the client until time t 0 + id, and since it takes time d=i to consume the susegment, the client cannot start consuming the susegment until time t 0 +(i, )d +(i, )d=i. Thus the client must delay y (i, )d=i units of time in order to receive all data from stream i on time. Therefore, in order for the client to guarantee that it will receive all data from all streams on time, it must delay consumption y (i, )d = max in units of time. i (n, )d n ince n will e large, the client will essentially have to wait an entire slot efore consuming data.
,,4,6,,3,5,7,,,4,6,,3,5,7, 3,3 3,6 3,9 3, 3,4 3,7 3,0 3, 3,5 3,8 3, 3, 3,3 3,6 3,9 3, Figure : An illustration of the first three streams for a video under quasi-harmonic roadcasting when m =4. 3 Our olution The two protocols we present trade some additional andwidth for the guarantee that (a) all frames will always arrive on time and () the client will never have to wait any extra time after the eginning of an instance of segment. 3. Cautious Harmonic Broadcasting Cautious harmonic roadcasting (CHB) avoids frame delay prolems y adopting a more conservative stream allocation policy. As in harmonic roadcasting, stream transmits the first segment of the video at full andwidth. The second stream is allocated differently: it transmits alternately segments and 3 at full andwidth. treams 3 to n, respectively transmit segments 4 to n at decreasing andwidths i = =i for i =3;::: ;n,. Late frame deliveries cannot occur while the first three segments of the video are consumed ecause these three segments are roadcast at full andwidth. They cannot either occur for any of the n, 3 remaining segments ecause the entire contents of segment i will e retransmitted every i, susegments and will thus e availale to the client efore it starts consuming i. The total andwidth B CHB required y the CHB protocol is given y: B CHB = + n, X i=3 i = + H(n, ): That is, (=, =n) units of andwidth more than the original HB protocol. Given that the term in =n will quickly ecome negligile for large values of n, the extra andwidth required y the CHB protocol is very close to = or half the consumption rate of the video. 3. Quasi-Harmonic Broadcasting CHB guarantees that all susegments of a segment will arrive at the client efore the client starts to consume the segment. If we were to allow the client to consume data from a segment while it is receiving data for the segment, then we can improve upon the protocol. We take this approach with quasi-harmonic roadcasting. Quasi-harmonic roadcasting (QHB), like the other harmonic protocols, divides each video into n equal segments and roadcasts the first segment repeatedly on the first channel. But then each segment i, for <i n, is roken into im, fragments for some parameter m,and the client will receive m fragments from each channel per time slot. Ifwe divideeach timeslot into m equally sized suslots, then the client will receive a single fragment during each suslot. The key to QHB is in how the fragments are laid out. Consider some channel i. The last suslot of each time slot is used to transmit the first i, fragments of i in order. The rest of the suslots transmit the other i(m, ) fragments such that the k th suslot of slot j is used to transmit fragment (ik + j, ) mod i(m, ) + i (see Figure ). This mapping can e etter understood using an example. Consider for instance the first three segments of a video and assume that m =4. As seen on Figure, the first segment of the program occupies a single slot and will e roadcast unchanged. The second segment consists of seven fragments that occupy two slots, each comprising four suslots. The first fragment of the segment, that is fragment ;, is roadcast in the last suslots of oth slots, while the six remaining suslots respectively contain fragments ; to ;7 : fragment ;i will occupy suslot i=+ of slot i mod+. Thus the client will always have in memory two fragments of segment efore it starts consuming the contents of that segment. One of these two fragments will necessarily e fragment ; while the other one could either e ; or ;3. We need only to worry aout the case where ; is the missing fragment ecause it will have to e consumed efore the client has finished downloading it from the server. Oserve however that the client will start consuming ; after it has ended consuming fragment ;, that is, after one seventh of the total slot transmission time has elapsed. During that time, it will have already downloaded four sevenths of ;.The remaining three sevenths will arrive efore they are actually needed given that they will e transmitted at one half of the normal rate. The third segment is sudivided into eleven fragments that occupy three slots each comprising four suslots. Fragment 3; is repeatedly roadcast in the last suslot of each odd slot while fragment 3; is repeatedly roadcast in the last suslot of each odd slot. The ten remaining suslots contain fragments 3;3 to 3; and fragment 3;i will occupy suslot i=3+of slot i mod3+. Thus the client will always have in memory eight fragments of segment 3 efore it starts consuming the contents of that segment. Two of these two fragments will necessarily e fragments 3; and 3; while the three missing fragments could e any of the nine remaining fragments. The case when 3;3 is the first missing segment is the only one that we have to consider here ecause it is the only one where a fragment will have to e consumed efore the client has finished downloading it from the server. Oserve however that the client will start consuming 3;3 after it has ended
consuming oth 3; and 3;, that is after two elevenths of the total slot time has elapsed. During that time, it will have already downloaded eight elevenths of 3;3.Theremaining three elevenths will arrive efore they are actually needed given that 3;3 is transmitted at one third of the normal rate. Understanding the fragment to segment mapping will also help us computing the total andwidth afforded y the protocol. The essential difference etween QHB and the original HB protocol is that QHB partitions each segment into im, fragments to e roadcast over im suslots while HB effectively allocates one fragment to each suslot. QHB then uses the remaining suslot to roadcast a redundant copy of the first fragment of each segment to guarantee that the consumer will always have in memory the first i, fragments of each segment efore it starts consuming the contents of that segment. As a result of this redundancy, each suslot of stream i will now have to roadcast =(im, ) of segment i instead of =im. ince slightly more information will have to e transmitted in the same time interval as efore, this will result in an increase of the required andwidth. While the original harmonic roadcasting protocol transmitted segment i at a andwidth i = =i, our protocol requires a andwidth 0 i equal to ( if i 0 i = = m otherwise : im, The additional andwidth per stream is given y: i = m im,, i = i(im, ) for all i>. As a result, the andwidth required y our protocol to transmit the i th segment of a video can e made aritrarily close to the i th term of the harmonic series y increasing aritrarily the numer of suslots for each slot and, hence, the numer of fragments per segment. We therefore decided to call our protocol the quasi-harmonic roadcasting protocol. The total andwidth B QHB required y our quasiharmonic roadcasting protocol is given y: B QHB = + The series i= m im, = H(n) + i= i(im, ) i= i(im, ) : converges for all values of m and has a closed form: (,, (, m )) where is the digamma function and is Euler s constant. Although unwieldy, this expression provides an upper ound for the additional andwidth required y the Bandwidth (multiples of the consumption rate) 6 5 4 3 Harmonic Cautious Harmonic Quasi Harmonic (m = 4) Quasi Harmonic (m = 6) 0 0 0 40 60 80 00 0 Numer of egments Figure 3: Bandwidth versus the numer of segments for the three harmonic protocols. QHB protocol. Oserving that () =,, we can verify that this additional andwidth ecomes equal to zero when the numer of suslots per slot m goes to infinity. Figure 3 displays the andwidth requirements of harmonic roadcasting, cautious harmonic roadcasting and quasi-harmonic roadcasting for videos requiring etween and 0 segments and selected values of m. To eliminate the factor representing the andwidth of a standard full speed channel, all quantities on the y-axis are expressed in standard channels, that is, taking the andwidth of a standard channel as unit of measurement. As one can see, the andwidth requirements of HB and QHB ecome virtually indistinguishale as soon as there are more than, say, sixteen suslots per channel. It may not e ovious at this point that QHB transmits all of the data to the client on time, so we will demonstrate it. Claim 3 Quasi-harmonic roadcasting delivers all video data on time. Proof: Consider any channel i, and suppose the client started receiving data at time t 0. The client will start to consume i at time t 0 +(i, )d. That means the client will already have (i, )m of the im, fragments of i in its uffer. In particular, it will have the first i, fragments since they appear in every consecutive series of i, time slots. The client must receive all of the first i fragments of i y time t 0 +(i, )d + d=m. If the client has not yet already received the i th fragment, then it will receive that fragment in the first suslot of the current time slot. That suslot will end at time t 0 +(i, )d + d=m, and thus the client will receive the first i fragments on time. For the next i fragments, the client will once again already have at least i, of the fragments
in its uffer, and it can receive the last fragment during the current suslot. This argument repeats for the remainder of the segment, until the last suslot of the current time slot, during which the client only needs to receive i, fragments, all of which are already in its uffer. 3.3 Discussion Our comparison etween the three protocols is actually unfair to oth cautious harmonic roadcasting and quasiharmonic roadcasting ecause they are compared against a protocol that provides a much higher access time for the same segment duration. As we showed earlier, the harmonic roadcasting protocol cannot deliver all frames on time unless the moment at which the clients start consuming the video is delayed y at least (n, )d=n. Delaying the eginning of the video y almost one slot has however the major disadvantage of douling the maximum access time and tripling the average access time as the customer will now have to wait etween one and two slots efore eginning to view the video. The same maximum access time and a lower average access time could have een otained y using either one of our new protocols and douling the segment size, thus reducing y a factor of two the numer of segments required to roadcast a given video. This in turn would result in sufficient andwidth savings to make our protocols more efficient than the original harmonic roadcasting protocol. Consider first the case of the cautious harmonic roadcasting protocol. Douling the segment size would result in the elimination of the last n= streams for a totalandwidth savings equal to: i= n i = (H(n), H(n )) + To show that the savings achieved would exceed the andwidth overhead of the cautious harmonic roadcasting, let us oserve that: i= n + i > i= n + n = ; while the andwidth overhead of the cautious roadcasting protocol was given y (=, =n) <. Hence the cautious harmonic roadcasting protocol can provide the same maximum access time as the harmonic roadcasting protocol and a lower mean access time at a lower andwidth cost. The comparison is even more favorale to the quasiharmonic protocol. Reducing y a factor of two the numer of segments would result in a total andwidth savings equal to: i= n + m im, > i= n + i > Bandwidth (multiples of the consumption rate) 7.5 7 6.5 6 5.5 5 4.5 4 3.5 3 Harmonic Cautious Harmonic Quasi Harmonic (m = 4) Quasi Harmonic (m = 6).5 0 3 4 5 6 7 8 9 0 Maximum Waiting Time (percentage of video length) Figure 4: Bandwidth versus maximum access times for the three harmonic protocols. while the andwidth overhead of the quasi-harmonic protocol: i= n i(im, ) >(H(n), H(n )) + can e made aritrarily small y selecting a sufficiently large value of m. As a result, the quasi-harmonic roadcasting protocol can provide the same maximum access time as the harmonic roadcasting protocol and a lower mean access time while using at least = less andwidth. Figure 4 displays the andwidth needed y each of the three harmonic roadcasting protocols to guarantee a given maximum access time. To eliminate the factor D representing the length of the video, the maximum waiting times on the x-axis are expressed as percentages of the video length. As in Figure 3, all quantities on the y-axis are expressed in standard channels, that is, taking the andwidth of a standard channel as unit of measurement. As one can see, cautious harmonic roadcasting and quasi-harmonic roadcasting always require a lower andwidth than harmonic roadcasting to guarantee the same maximum access time. The savings are quite significant, especially for quasi-harmonic roadcasting with 6 suslots, which requires etween 0.64 and 0.68 standard channels less than harmonic roadcasting to guarantee the same maximum access time. In other words, quasiharmonic roadcasting requires etween 8 and 9 percent less andwidth than harmonic roadcasting to provide the same quality of service. We would have otained even etter figures if we had selected the mean access time rather than the maximum access time as our performance index. We elieve however that the maximum access time is a etter performance index ecause end-users tend to e mostly concerned y never having to wait too long for the services they request.
4 Related Work The first protocol to reak a video into segments and display those segments repeatedly on different channels was pyramid roadcasting [4]. With this protocol the n segments are not the same size; each segment i, for <i n, is i, times as large as the first segment, where is a value close to the ase of natural logarithms e. Pyramid roadcasting also groups the videos together on each channel, so channel i, for example, repeatedly shows the i th segment of each video. As with harmonic roadcasting, the client must wait for the first segment of the video it wants to consume. Once it starts receiving (and possily consuming) data from one segment, it waits for the earliest opportunity to receive data from the next segment as well, and it receives the entire video in this pipelined fashion. Given a andwidth B times the consumption rate of the videos and M videos to roadcast, pyramid roadcasting calculates n to e B=(Me)c and it dedicates a andwidth of B=n for each of the n channels. ince n grows with B, the maximum waiting time for the client improves exponentially with B. However, since the data is pipelined, the client will have to support a high andwidth, and since the last (and largest) segment of the video will have to e stored in the client s uffer, the uffer will have to e large enough to hold nearly 80 percent of the video. Permutation-ased pyramid roadcasting [5] solves some of the prolems of pyramid roadcasting in that it eliminates the pipelining of data to the client, and it removes the grouping of multiple videos per channel. But it also constrains n to e etween two and seven, and so the client waiting times will not improve exponentially eyond a certain andwidth. kyscraper roadcasting [6] limits the width of each segment, and so its segments, if stacked one on top of the other, would form a skyscraper shape rather than the pyramid shape of the segments from pyramid roadcasting. kyscraper roadcasting also uses a more slowlygrowing function to calculate its segment sizes, allowing for smaller uffer sizes on the clients, and it reduces the andwidth clients must support. Figure 5 shows the andwidth versus client waiting times for the three protocols descried in this section as well as for harmonic roadcasting and cautious harmonic roadcasting. We used the unconstrained version of permutation-ased pyramid roadcasting [5] and skyscraper roadcasting with a maximum width of 5 [6]. 5 Conclusions Video roadcasting protocols can improve the efficiency of video on demand services y reducing the andwidth required to transmit videos that are simultaneously watched y many viewers. One of the newest roadcasting protocols to e proposed, harmonic roadcasting, requires much less andwidth than other roadcasting protocols to guarantee the same maximum access time. We found that the harmonic roadcasting protocol could not ensure on-time delivery of all frames of a given video unless the actual viewing of the video is delayed. Maximum Client Waiting Time (min) 4 0 8 6 4 0 Pyramid Permutation-ased Pyramid kyscraper Harmonic Cautious Harmonic 6 8 0 4 6 8 0 Bandwidth Per Video (multiples of the consumption rate) Figure 5: How harmonic roadcasting compares to other roadcasting protocols. We have presented two roadcasting protocols that achieve nearly the same low andwidth as harmonic roadcasting without imposing any additional delay on their end-users. As a result, oth protocols require less andwidth than harmonic roadcasting to achieve the same maximum access time. Our first protocol, cautious harmonic roadcasting, requires somewhat more andwidth than our second protocol, quasi-harmonic roadcasting, ut is also much simpler to implement. electing etween them should e the result of evaluating a tradeoff etween andwidth capacity and protocol complexity. References [] J. W. Wong. Broadcast delivery. Proc. of the IEEE, 76():566 577, Decemer 988. [] A. Dan, D. itaram, and P. hahauddin. cheduling policies for an on-demand video server with atching. ACM Multimedia, pp. 5 3, an Francisco, CA, Octoer 994. [3] A. Dan, D. itaram, and P. hahauddin. Dynamic atching policies for an on-demand video server. Multimedia ystems, 4(3):, June 996. [4]. Viswanathan and T. Imielinski. Metropolitan area videoon-demand service using pyramid roadcasting. Multimedia ystems, 4(4):97 08, August 996. [5] C. C. Aggarwal, J. L. Wolf, and P.. Yu. A permutationased pyramid roadcasting scheme for video-on-demand systems. Proc. International Conference on Multimedia Computing and ystems, pp. 8 6, Hiroshima, Japan, June 996. [6] K. A. Hua and. heu. kyscraper Broadcasting: a new roadcasting scheme for metropolitan video-on-demand systems. IGCOMM 97, pp. 89 00, Cannes, France, eptemer 997. [7] L.-. Juhn and L.-M. Tseng. Harmonic roadcasting for video-on-demand service. IEEE Transasctions on Broadcasting, 43(3):68 7, eptemer 997. [8] L.-. Juhn. Private correspondence, Octoer 997.