Video-on-Demand Broadcasting Protocols: A Comprehensive Study

Transcription

1 Video-on-Demand Broadcasting Protocols: A Comprehensive tudy Ailan Hu Intel Corporation 2200 Mission College Blvd anta Clara, CA ailan.hu@intel.com Astract Broadcasting protocols are proved to e efficient for transmitting most of the popular videos in video-on-demand systems. We propose a generalized analytical approach to evaluate the efficiency of the roadcasting protocols and derive the theoretical loer andidth requirement ound for any periodic roadcasting protocols. By means of the proposed analytical tool - temporal-andidth map, the approach can e used to direct the design of periodic roadcasting protocols to achieve different goals, e.g., server andidth requirement, client aiting time, client I/O andidth requirement etc. As the most important performance index in VOD system is the required server andidth, e give the solution to achieve the optimal andidth efficiency given client aiting time requirement and the length of the video. To take into account the popular compressed video ith variale it rate, the optimal approach is applied readily to the VBR videos and can achieve zero loss and est andidth efficiency. We give proof hy existing techniques such as smoothing and prefetching is not necessary and in some cases inefficient in roadcasting protocols. We also discuss ho roadcasting schemes can e tailored to support true and interactive VOD service. An insightful comparison eteen roadcasting and multicasting schemes is also given in this paper. I. INTRODUCTION Video-on-Demand (VOD) proposes to provide suscriers ith the possiility of atching the video of their choice at the time of their choice, as if they ere atching a rented video cassette. o far VOD has not een a commercial success ecause the technology is still very expensive and its potential users are unilling to pay much more for a VOD selection than they are used to paying for a video cassette rental. Previous research has shon that performance of VOD system can e greatly improved through the use of multicast or roadcast schemes. Most of the multicast protocols [16], [17], [18], [19], [20] are reactive in the sense that they transmit data in response to the user requests. Multicast schemes try to let user share the same stream of data as much as possile. While some of the multicast approaches can provide immediate service and save server andidth y avoiding unnecessary transmission of data, they are suject to data loss and can not guarantee on time delivery of data if user requests are ursty or too high. Broadcasting schemes can address this prolem y periodically transmitting video segment in a proactive ay and guarantee service latency ithin certain amount of time. The idea ehind periodic roadcasting schemes is to divide the video into a series of segments and roadcast each segment periodically on dedicated server channels. While user is playing the current video segment, it is guaranteed that the next segment is donloaded on time and the hole video can e played out continuously. User ill have to ait for the occurrence of the first segment efore they can start playing the video. User aiting time is usually the length of the first segment. A true VOD service does not require user to ait for the video. ince user can not atch the video immediately, roadcasting protocols can only provide near VOD service. In the literature, researchers ere trying to find out the golden factor to divide the video to achieve the loest server andidth hile still guarantee on time delivery of each segment. In this paper, e propose an insightful analysis for VOD roadcasting protocols and give the solution to this golden factor. A convenient tool, the temporal-andidth map, is provided to evaluate roadcasting protocol performance efficiency. The theoretical loer server andidth requirement for any roadcasting protocols is derived and the optimal roadcasting schemes to achieve the loest server andidth given certain user aiting time and numer of segments are presented. It is also shon that our approach can e readily tailored to analyze variale it rate (VBR) ased videos. As a result, the VBR video is transformed to constant it rate (CBR) streams to e roadcast. We sho that smoothing techniques in roadcasting protocols could not achieve etter performance for saving server andidth. The proposed approach can also e utilized to design roadcasting protocols to satisfy other performance requirements such as client I/O andidth and client storage constraint. We also discuss ho roadcasting protocols can e modified to provide true VOD service and the possiility of interactive functions, hich are rarely mentioned for roadcasting protocols in previous research. We also sho the relationship eteen roadcasting and multicasting schemes and ho multicasting schemes degenerate to roadcasting schemes. Throughout the paper e use to denote the total length (in time units) of the video, i the ith segment, the client aiting time requirement, the video consumption or display rate and n the numer of segments for a given video. II. OVERVIEW OF THE PERIODIC BROADCATING PROTOCOL taggered roadcasting [15] is the simplest roadcasting pro- 508 IEEE INFOCOM 2001

2 tocol proposed in the early days. It allocates K server channels each ith andidth to transmit the hole video. The eginnings of each video replica are staggered evenly across the channels. Client access latency is =K and it could not e improved ithout the expense of linear increase in the corresponding server andidth. ome more efficient roadcasting protocols have een proposed. All these protocols share a similar organization. They divide each video into n segments that are simultaneously roadcast on different data streams (logical channels). One of these streams transmits nothing ut the first segment of the video. The other streams transmit the remaining segments at their designated andidth. When users ant to atch a video, they ait for the eginning of the first segment from the first stream. While they start atching that segment, their set-top ox (TB) starts donloading enough data from the other stream(s) so that it ill e ale to play each segment of the video in turn. These roadcasting protocols can e sudivided into three groups. Protocols in the first group partition the video into increasing size of segments and transmit them in logical channels of same andidth. They are ased on Visanathan and Imielinski s Pyramid Broadcasting (PB) protocol [1]. The segment size of the videos in this protocol follos a geometrical series and different videos are mingled together in each logical channel. To provide on time delivery of the videos, each segment channel has to transmit the segments in a very high rate and client I/O andidth and storage requirement are also high. Clients can donload the next segment at its earliest occurrence and at any time they donload at most to consecutive channels. To address the prolem of high client side requirement in PB, Permutation-ased Pyramid Broadcasting (PPB) as proposed. Instead of transmitting a segment in a very high andidth, PPB multiplexed the segment channel into P suchannels and transmitted them in P times loer rate. The P sustreams are staggered ith each other to meet the same timing requirement as in PB. Another important protocol in this family is the kyscraper Broadcasting protocol (B) [3]. B transmits each segment in the video consumption rate and its segment series progression is much loer ut still meet the timing requirement. User needs to donload from at most to streams at any time. The client disk storage requirement is constrained y the size of the last segment. A more efficient roadcast scheme, the Fast Broadcasting (FB) [7] is proposed to divide the video into geometrical series of [1, 2, 4,... 2 K 1, 2 K ]. The channel andidth is and client needs to donload from all K streams simultaneously. This protocol is the most efficient in terms of server andidth requirement. It is the Harmonic Broadcasting (HB) [4] initiated another group of roadcasting protocols. They divide the video into equal size segments and transmit them in logical channels of decreasing andidth. The playout duration of a segment is defined as a slot. In HB, each segment is roadcast repeatedly on its dedicated channel ith a andidth =i. This requires much less server andidth than the PB family protocols. Client starts receiving data from each segment stream right after it can start donloading the first segment. When the client is ready to consume segment i, it ill have received i 1 slots of data from that segment and the last slot of that segment stream can e received during the segment playout time. HB requires the client receiving andidth the same as the server transmission rate and the storage requirement aout 37% of the entire video. The major fla in HB is that it can not alays deliver all the data on time. Paris et. al. proposed the Cautious Harmonic (CHB), the Quasi-Harmonic (QHB) [5] and the Polyharmonic (PHB) [6] protocol and solved this prolem. These protocols provide almost the same performance results as HB hile the timing requirement is still met. To further reduce the server andidth, HB-ased schemes need to divide the video into more segments, this requires more logical channels. A ne family of the roadcasting protocol includes Pagoda roadcasting [8] and Ne Pagoda [9] roadcasting schemes. These protocols are hyrid of pyramid-ased protocols and harmonic-ased protocols. They partition each video into fixed size segments (as in HB) and map them into a small numer of data streams of equal andidth (asinpb)andusetimedivision multiplexing to ensure that successive segments of a given video are roadcast at the proper decreasing frequencies (as in HB). The result is that they do not require significantly more andidth and at the same time do not use more logical streams or less segments than HB-ased protocols. All the aove protocols are ased on the assumption that the videos are Constant Bit Rate (CBR) encoded. In the real orld there are many videos ith Variale Bit Rate (VBR). ome more protocols are proposed to address this prolem. aparilla et. al. proposed a protocol in [12] (e ill call it VBR-B) using the segmentation scheme in FB and applied the techniques of GoP smoothing, server uffering and client prefetching to improve its performance. Another protocol, the Trace Adaptive Fragmentation (TAF), proposed in [13] is an improvement of VBR-B to take into account the trace of each video and try to otain loer aggregate andidth y comparing possile cominations of feasile video schedules. In [11] Paris proposed a VBR roadcasting protocol (VBHB) ased on the cautiousharmonic protocol. This protocol does not use the smoothing technique as the other protocols for VBR videos. As a roadcasting protocol, it requires predetermined server andidth. III. A GENERAL ANALYI OF BROADCATING PROTOCOL A. The Generalized Analytical Approach To analyze the efficiency of the roadcasting protocols, e oserve that there are three notions very important: segment size progression, andidth allocation for each logical channel (data stream to transmit a segment), and the satisfaction of continuous play condition. To descrie the schemes ith these notions, e introduce a temporal-andidth map, hose x-direction represents time, and y-direction represents andidth. On the loer part of the map is the roadcasting area. Each logical channel is 509 IEEE INFOCOM 2001

3 Playout Fig. 1. Temporal-Bandidth Map of Pyramid Broadcasting ith ff =2 presented in this part and its corresponding andidth is represented y its height. These logical channels are piled up together and the sum of their heights is equal to the server andidth requirement. The upper part of the map is the playout of the video segments corresponding to each of the roadcasting segment in the roadcasting area. We call this part the playout area. Figure 1 1 is the analysis of pyramid roadcasting protocol using temporal-andidth map. The loer part (roadcasting area) corresponds to roadcasting of segments in pyramid roadcasting scheme. The shaded area of 1, 2, in the roadcasting area corresponds to the playout of segment 1, 2, in the playout area. From the time hen user starts aiting to the end the hole video is played out, only the shaded areas are useful in the roadcasting area. To measure the efficiency of the roadcasting protocols, e define roadcasting andidth efficiency as: server andidth efficiency = area of the playout area area of roadcasting area ince the playout area is equal to the shaded segments in the roadcasting area, e can see that the efficiency is actually the fraction of the useful its for playout in the roadcasting area to the total its roadcast from the time user starts aiting to the end of the video playout. One of the design goals of all roadcasting protocols is thus to maximize the andidth efficiency, in other ords, reduce the sum of the andidth of each logical channels, i.e., the height of the roadcasting area, and at the same time, meet the access time requirement and client I/O andidth and storage requirement. B. Advantage of eparating Different Videos Before applying the generalized analytical approach to analyze existing roadcasting protocols, e digress for a moment to sho the advantage of separating different videos. InPB,all the videos are considered and they are roadcast sequentially in each logical channel. Each channel has andidth B (here e use B as andidth for each logical channel instead of total andidth for a video) and contains segments from M videos. 1 The map provided here only considers one video. ee the argument in the next section hy e only consider one video here. Clients have to donload at speed B and only 1=M of the channel cycle is the video they ant to atch. A slight change to the protocol could e made to achieve the andidth of B=M for each segment: separate the M video segments in one logical channel into M logical channels and let each segment transmit at a sloer speed ith andidth B=M. This sloer transmission scheme is involuntarily adopted in all of the later protocols and contriutes part to their etter performance results. The point is that e can consider each video independently. Each of them is roadcast in its allocated andidth in its on channels. To mix them ith other videos and transmit them serially can only force higher client I/O andidth and hence higher client storage requirement. We ill also sho in a later section that there is no performance gain to aggregate VBR videos together. Thus far, e ill consider only one video. C. Analysis of Existing Broadcasting Protocols No e compare the pyramid-ased and harmonic-ased protocols using the proposed approach. We ill give the analysis of the other hyrid protocols in a later section. Without loss of generality, e set the access latency as 1 and the total video duration is a relative value to. Note also that the andidth requirement for each logical channel is proportional to the consumption rate, its value is not important and e can also assume it to e 1 for convenience. The comparison here is ased on the same = ratio, the required andidth for each protocol is shon y the height of the roadcasting area. Pyramid roadcasting protocol partitions each video into K segments of geometrically increasing sizes. The geometric series has factor ff, hereff > 1. Each logical channel is no allocated ith andidth B=K,hereB is the total andidth allocated to this video. Figure 1 gives an example of pyramid roadcasting ith ff = 2. ince the playout time of the first segment must e at least the roadcasting time of the second segment to guarantee on time delivery, and the first segment is 1=ff of the size of the second, the roadcast time of the first segment must e 1=ff of its playout time. o the andidth requirement for the first logical channel must e at least ff times of the consumption rate. We can see the andidth allocated for the hole video is quite large. kyscraper roadcasting scheme allocates fixed andidth - the consumption rate for each logical channel. Its segment size is determined y a recursive function, hose materialized series is as follos: [1; 2; 2; 5; 5; 12; 12; 25; 2 5; 52; 52;:::]: The intuition in this series is that eginning of any next segment must e encountered efore the current segment is consumed. ince its andidth requirement is not as demanding as pyramid roadcasting, the roadcasting area is not as high as that in PB, and its segment is somehat spread out during its playout time. Figure 2 shos one scenario of ho skyscraper roadcasting orks to achieve the same maximum latency time and play the same length of video as in PB. Note the andidth efficiency for 510 IEEE INFOCOM 2001

4 Playout t 2 t 0 t Fig. 4. right-edge restriction of the roadcast segment Fig. 2. Temporal-Bandidth Map of kyscraper Broadcasting Playout H(14) = Not to scale Fig. 3. Temporal-Bandidth Map of Polyharmonic Broadcasting the protocol is the same no matter hat scenario is. Compared to pyramid roadcasting, B has higher efficiency, as can e easily oserved from its shaded area in the roadcasting area. The major contriution for harmonic roadcasting is its lo andidth requirement. The underlying mechanism for its etter performance as not addressed in the original paper, ut after applying temporal-andidth map to harmonic roadcasting protocol, it is clear that it actually managed to achieve a higher andidth efficiency: its shaded area has higher occupancy in the roadcasting area. CHB and QHB solved the prolem of the fla in HB that could not alays deliver the video segment on time. But oserved in temporal-andidth map, they have less andidth efficiency. In CHB, if e transform the second and third segment into the equivalent 1/2 height and 2 slots length, starting from the third segment, each segment stream does not stretch as far as its counterpart in HB and thus has higher height and less efficiency. In QHB, every segment has some portion of redundancy and thus not as efficient. A etter protocol similar to HB is the polyharmonic roadcasting protocol. The novel point in this protocol is to donload the video right aay hen the user sitches in. Although the segment is not donloaded from the eginning, it can e reassemled to form a hole segment and it is guaranteed that y the time the previous segment has finished playing, the next segment is donloaded. The same maximum access latency can e achieved ith the same server availale andidth as harmonic roadcasting, ut PHB does not have the on-time delivery prolem. Figure 3 gives an example of ho polyharmonic roadcasting scheme orks 2. Again, it is easy to oserve that polyharmonic roadcasting tries to stretch its useful segment to get etter efficiency. IV. OPTIMIZATION OF ERVER BANDWIDTH EFFICIENCY The aove analysis gives rise to the folloing oservations as rules to design efficient roadcasting protocols: Rule 1: Any efficient periodic roadcasting protocol should not repeat transmitting another cycle of the segment during the period hen the user starts to ait the video until this part of information is actually started to e played out. Proof: Oserving the temporal-andidth map, appearance of a repeated cycle means that there must e some part of the cycle that is not in the shaded area (the useful part) efore the time hen the segment is played out. This implies there exists unneeded cycle(s) during the donloading time of the segment. uch protocols are not efficient since they aste part of the andidth to transmit the same data that have een already received. Note that e restrict the donloading of a hole segment to end efore the start of its playout. This is necessary to meet the timing requirement. Figure 4 shos a roadcast segment on the loer part and its playout in the upper. ince user can sitch in at any time t 0, the eginning of the next roadcast cycle t 1 should appear as early as the starting playout time of this segment, t 2. In other ords, the right edge of the roadcast segment should not stretch further right to the starting playout time of this segment, otherise the timing requirement ill not e met, as is the case in harmonic protocol. We define the duration from the time hen user sitches in to the time hen a segment starts to playout as the good segment donloading time. Examples of inefficient protocols that violate this rule are pyramid roadcasting, permutation-ased pyramid roadcasting, skyscraper roadcasting, and cautious harmonic roadcasting protocols. All of them have more than one cycle during their good segment donloading time. Harmonic roadcasting violates the timing requirement enforced y this rule. Rule 2: Any efficient periodic roadcasting protocol should not include, in any of its cycle, unneeded portions of data for just in time playout of the video. Proof: To include unneeded portion of information in any of its cycle means that the shaded area is somehat interleaved ith portions of lank area hich include useless information. uch protocols ill not e efficient. Quasi-harmonic, pagoda 2 Here e use m =1,alargerm could e used to achieve loer andidth 511 IEEE INFOCOM 2001

5 and ne pagoda roadcasting are examples of such protocols that conflict ith this rule. Rule 3: Any periodic roadcasting protocol needs to repeat cycles for each segment ithin their good donloading time. Proof: This is a requirement for any periodic roadcasting protocol. To meet the access latency requirement, repeated cycles are needed to roadcast in the netork and to let users donload and play the segments ithin certain aiting time. Each segment should repeat transmitting the necessary data at least during its good donload time, otherise this segment of data can not e delivered on time. We can cut all of the unneeded cycles or part of them ecause users actually do not ant them for continuous playout, ut e can not avoid roadcasting their next cycles in order to allo any user to sitch in at any time. Playout Playout t Not to scale Fig. 5. Optimally-tructured chemes The essence of these oservations is to let the shaded area stretch as far to the left and right as possile so that the height of the roadcasting area, i.e., the required andidth, is minimized. To the left means the starting donloading time is the time the client sitches in. To the right means to let the donloading period as long as possile, to the point hen the segment is needed to e played out - this is essentially to let the segment arrive just in time. An interesting family of roadcasting protocols is the pagoda protocol and its variants. Their segments have equal size. Different segments can map to the same roadcast stream, ut each segment only occupies part of the roadcast stream cycle. Each stream roadcasts at consumption rate. The ith segment is roadcast at frequency close to ut at least 1 every i slots. To analyze its efficiency, a normalization transformation can e performed y replacing the segment in the roadcasting area ith a segment of length corresponding to reverse of the segment roadcast frequency and height calculated from the area of the segment in the playout area. The normalized map has one stream per segment. It can e shon that pagoda protocol has portion of data asted during its good segment donloading time and is not as efficient as polyharmonic protocol in terms of andidth requirement. The discussion aove shos that polyharmonic protocol is the only protocol meets all the necessary conditions for efficient roadcasting protocols. We define the protocols that meet the three rules the optimally-structured roadcasting protocols. Optimally-structured protocols can have different video information encoding schemes hich could e different from polyharmonic roadcasting protocol, ut they can e normalized to a structure similar to polyharmonic protocol. Note that unlike polyharmonic roadcasting, optimally-structured schemes can have different segment size as ell as different segment roadcasting andidth. The key restriction is the area restriction, i.e., the segment area in the playout area should e equal to the one in the roadcasting area. The structure of optimally-structured roadcasting schemes is illustrated in Figure 5. Every segment is donloaded during its good segment donloading time. Every roadcast segment (shaded area) contains no portion of replicated information. Areas 1 ; 2 ; ;:::in the playout area and roadcasting area are of the same size respectively. Timing requirement can still e met as long as e keep the corresponding segment area restriction in mind. Figure 5 illustrates that starting from any time t, playout of segments (corresponding to the loer playout area, their corresponding segments in the roadcasting area are those shaded segments) have the same structure as those segments starting from the same time (corresponding to the solid line rectangles in the roadcasting area, their playout is in the upper playout area). o hen analyzing these schemes, e can assume that all the segments in the roadcasting area are started from the same time. A. Optimization of CBR Broadcasting chemes We oserve that segment size and channel andidth in optimally-structured schemes can e different. The optimization prolem is thus to choose the optimal segment progression among the optimally-structured schemes. Given segment numer n, ho can e partition the video to achieve the loest andidth? Formally, let i e the channel andidth for the ith segment, i e the segment size, =1and =1, the prolem can e stated as: suject to Note that X minimize i 1 i (1 + j )= i j=1 (1 + i )= nx i=1 nx i i=1 i = i > 0; i > 0 1+ P i j=1 j 1+ P i 1 j=1 j i =1; 2;:::;n i =1; 2;:::;n 512 IEEE INFOCOM 2001

6 Multiplying all n numer of (1 + i ) produces: ny i=1 (1 + i )=1+ nx j=1 j = +1 That is, the product P of the n variales (1 + i ) is a P constant, n +1. To minimize n i=1 i is the same as minimize i=1 (1 + i ). The latter is minimized hen (1 + i );i =1; 2;:::;nare Pequal to each other, given their product is a constant. This means n i=1 i is also minimized hen i are equal to each other, say Λ. Consquently, or the andidth requirement is nx i=1 (1 + i ) n = +1 i = Λ = np +1 1 (1) i = n Λ = n( np +1 1) (2) and the optimized segment size progression is i = Λ (1 + Λ ) i 1 = ( np +1 1)( np +1) i 1 The segment progression follos a geometrical sequence. The golden factor for segment progression is thus np +1,here is a relative value to access latency. The golden factor is solely determined y the duration of the video, the required access latency and the numer of segments. The original idea is proposed y Hu et. al. in [10]. The protocol is called greedy equal andith roadcasting (GEBB). Like PB, the optimized scheme has equal andidth roadcasting stream and geometrically groing segment size; unlike PB, it donloads each segment greedily, i.e., immediately after user sitches in. Interestingly, for a video ith = equal to 127, the golden factor is 2. The Fast Broadcasting protocol uses this factor ut it is not optimal if = has other values. B. Optimization of VBR Broadcasting chemes o far e limited our discussion in CBR roadcasting. A similar approach can e applied to the compressed video or a VBR video. The playout area of the video ill have variale it rate in the temporal-andidth map and its roadcasting segment is still of constant it rate. Area restriction still applies. The optimal partition of the video is a prolem that can e formalized in a similar manner as the previous section. This is a non-linear optimization prolem ith n linear inequality constraints, e can construct a Lagrangian function and solve it using Kuhn-Tucker necessary conditions. In theory, a series of n equations need to e solved to otain the optimal partition. A more practical dynamic programming approach is presented in Figure 6. The idea is to construct a tale B min starting from one segment and video length of one frame, then go // Initialize tale B min to infinity for (i =1;i» N ; i ++) for (j =1;j» n; j ++) B min [i; j] =1 // Initialize A[i] to e the accumulated frame // sizes from the first frame to the ith frame. // Initialize the required andidth for one // segment and i frames of video length. A[0] = 0; for (i =1;i» N ; i ++) P min [i; 1] = i; A[i] =A[i 1] + f [i]; B min [i; 1] = A[i] A[0] ; // Construct the rest of the tale for (i =2;i» n; i ++) for (j = i; j» N ; j ++) for (k = i 1; k<j; k ++) B 0 = B min [k; i 1] + A[j] A[k] +k=f ; if (B 0 <B min [j; i]) B min [j; i] =B 0 ; P min [j; i] =k; Fig. 6. Pseudocode for the dynamic programming solution on step y step for larger segment numers and larger video length. The given arguments are: client aiting time requirement, total video length N frames, the ith frame size f [i], and frame consumpution rate F frames/sec. B min [j; i] indicates the minimum andidth requirement for a video ith j frames and i segments. It is calculated from the minimum andidth requirement for i 1 segments and video length k frames (B min [k; i 1]), here k is less than j frames and larger or equal to i 1 frames 3. A[j] A[k] +k=f is the andidth requirement for a segment ith frames from k to j 1. P min [j; i] saves the starting frame position of the ith segment ith video length of j frames. The computational complexity of this algorithm is in O(nN 2 ) and the space complexity is in O(nN ). In any case hen the complexity is inhiiting, a ready ay to reduce it is to relax the frame granulity, or comine several frames together to form a larger frame. Due to the design of the optimally-structured scheme, the VBR video is naturally transformed to CBR streams to roadcast in the netork and it is inherently not suject to loss. It is shon that the optimal solution out-performs the existing VBR roadcasting schemes significantly. Experiments ith different video traces using the optimal approach indicate the later segments in VBR video follo a similar geometric series as a CBR video. This is ecause the later segments tend to e large and include more frames. The average segment playout rates in later 3 B min [k; j 1] ith k < j 1 has no meaning since frame numer is alays no less than segment numer. 513 IEEE INFOCOM 2001

7 segments are almost the same and this makes the optimal segment division similar to that of CBR. A simplified algorithm can e constructed ased on the aove oservation to calculate a near optimal video division. A 1 i 1 A 1 i j 1 j V. THEORETICAL BANDWIDTH REQUIREMENT BOUND FOR ANY PERIODIC BROADCATING PROTOCOL Given the required access latency and video length,hat is the server andidth loer ound requirement for any periodic roadcasting protocol? From the discussion aove, e see that only the optimally-structured roadcasting schemes are designed in the ay that does not aste server andidth. Any other schemes can e transformed to a similar structure ith each logical channel transmitting a portion of data from the video, hether this cycle of data is transmitted during its good donloading time ill decide if it s optimally-structured or not. What if e change the shape of the video itself hile still let it e played out on time? This corresponds to change the shape of the playout area, ith part of certain segment(s) moved to some previous 4 segment(s). This is essentially a kind of smoothing technique. Figure 7 shos hy smoothing incurs more andidth demand. uppose part of segment i is smoothed to its previous segment i 1. The andidth requirement for the (i 1)th roadcast channel ill e increased. To compensate the lost area A 2, the comined to ne channels andidth ill e greater than that efore smoothing, i.e., i 1 + i < 0 i i. The same argument can e applied to segment i 2, i 3 :::. This implies that smoothing y segment rearrangement does not help loering the andidth requirement, it can only make it orse. We also see hy just in time is so desirale to reduce the andidth requirement. The earlier the part of the segment arrives ahead of the time hen it is needed, the less efficient the protocol is. We conclude that optimally-structured roadcasting scheme ithout changing the playout shape is the only candidate to achieve loer andidth requirement. The essence of the optimally-structured scheme is that any segment is donloaded and only donloaded during its good segment donloading time, and during this time period, there should not e any other portion of the segment included in this repeated cycle. The theoretical server andidth loer ound is reached hen the optimally-structured schemes have an infinity numer of segments as is shon y the folloing theorem. Theorem 1: Given a video ith required access latency of and length of, there exists a theoretic andidth requirement loer ound B 0. This ound is reached hen the optimallystructured roadcast scheme has infinity numer of segments. A CBR video ith consumption rate has the ound of ln(= +1). A VBR video ith video consumption rate f(t) R has the ound of 0 Proof: f (t)dt +t. uppose the video is partitioned into n segments (does not matter if it s optimally partitioned or not) and its re- 4 Normally moving to latter segment is not feasile since timing requirement is violated. i 1 i j A 1 A 2 A 2 Not to scale Fig. 7. The donside of smoothing and the upside of splitting Variale Bit Rate Constant Bit Rate =1 Part has een played B B 0 B t f(t) B(t) Not to scale Fig. 8. Bandidth Loer Bound Asymptote and Client torage Requirement quired andidth is B(n). Figure 7 shos ho further partition of any segment j into j1 and j2 results in loer andidth requirement. j must e larger than sum of j1 and j2. Let every segment split and e get 2n segments, hile P B(n) > B(2n). When n! 1, n i monotonically decreases, ut it has a loer ound. This concludes that series B(n) converges, i.e., the loer ound exists and is reached hen segment numer tends to inifinity. We denote its limitation as B 0. In the case of CBR video, B 0 can e calculated from the optimal segment andidth Λ : B 0 (CBR) = = lim n!1 n Λ lim np n!1 n( = +1 1) = ln(= +1) For any video ith consumption rate given y f (t), atany time t to t + dt, the roadcast scheme must at least transmit f (t)dt length of data. This amount of data should transmit fully during its good donloading time + t. The andidth f (t)dt required to transmit this amount of data is +t. The total andidth requirement for a video of length is: B 0 (VBR)= Z 0 i 1 i f (t)dt + t Note that in the CBR case, f (t) =1and equation 4 reduces to thevaluein equation3. By varyingvideolengtht, an asymptote j1 j2 =1 t (3) (4) 514 IEEE INFOCOM 2001

8 Fig. 9. An Illustration of Design cheme to Restrict Client I/O Bandidth B(t) = ln(t= +1)can e otained as shon in Figure 8. Any normalized roadcasting streams are confined y this asymptote. VI. CLIENT I/O BANDWIDTH AND TORAGE REQUIREMENT ANALYI While server andidth requirement and client access latency are the key issues in current VOD systems, e should also take into account to other performance measures: client I/O andidth and uffer space requirements. Optimally-structured roadcasting protocols require client donload at the same andidth as the server for the video. Although the optimal division of the video gives out the loest server andidth, it could still cause too high demand at the client side. ince oth pyramid roadcasting and skyscraper roadcasting donload no more than to logical channels, their I/O andidth requirement could e less than that of optimaly-structured protocols. A convenient change to the optimaly-structured protocol can e made to meet the maximum client I/O andidth requirement. As illustrated in Figure 9, assume client can donload at most 2 streams at rate, the first to segments are constructed as normal, starting from the third segment, segment i s left edge is aligned ith segment i 2 s right edge. This guarantees that client needs to donload at most at rate 2. The segment progression is a fionacci series. Its server andidth requirement is etter than skyscaper protocol and its variants. Note also that starting from the third roadcast stream, the unused portion of the cycle need not transmit any data, this is different from any other existing roadcasting protocols. As a result, the average server andidth for this scheme is only 4:78, lessthan6 since the unused portion in each good segment donloading time can e used to transmit any other data. As for the uffer space requirement, e first give an estimate of the optimally-structured scheme. The orst case uffer space requirement for the optimal case of CBR video hen n! 1 can e calculated as follos. The uffer space requirement at any moment t 0 is given y the shaded rectangle area shon in Figure 8. The lank area elo the asymptote and aove the shaded area is the part that has een played. Client first donloads the video at andidth B 0 and starts accumulating video segments. After time, it starts to consume the video at rate. The donloading speed slos don and at the time hen it reduces to the consumption rate, the uffered data reaches 13 its highest amount. After that the donloading speed ill e less than and the uffer space requirement is reduced. o the orst case uffer space requirement can e calculated hen the shaded rectangle has the height of, and its length corresponds to the t value given in B(t) = ln(t= +1) = B 0 = (ln(= +1) 1). o the uffer space requirement is + e, almost 1=e, or37% ofthe video, if is relatively much smaller than. With fixed segment numer n and optimal partition scheme, the uffered data are given y: ( + lx j=1 j ) (n l) Λ here l is the last segment that satisfies (n l) Λ >,orl = n c. Note that hen Λ >, l = n 1 and the orst case Λ uffer space is the size of the last segment, i.e., Λ (1 + Λ ) n 1, if is normalized ith, according to equation 1, it can e presented as: ((1 1 np +1 ) +1 ) ince +1 is almost 1 hen the video length is relatively larger than the access latency, the orst case uffer space requirement is (1 np 1 ) +1 of the total video. With 7 segments and video length of 127 and access latency of 1, it corresponds to 50% of the video. We can expect less uffer space requirement hen e partition the video into more segments. With more segments, client ill e ale to donload at loer pace. o the client storage requirement is also related to client I/O andidth. Restriction on client donload speed ill require less client storage. The scheme illustrated in Figure 9 requires only 31% of the video. The tradeoff among the different design goals can e oserved from the aove discussion. A ell-designed roadcasting protocol needs to consider different design goals and tailor its structure to meet all the requirements. The proposed analytical approach is a good guide to analyze roadcasting protocols and direct the design of these protocols to achieve different performance goals in different categories. To reduce the server andidth of optimally-structured schemes ill at the same time reduce the client I/O andidth as ell as the storage requirement. But reducing server andidth could end up ith too many segments and it also has a loer ound. If client I/O andidth and storage requirement are the ottleneck, the optimally-structured scheme can e modified to satisfy these requirement hile still remains the est in terms of server andidth requirement. One last note here is the possiility of reducing the segment numer and roadcasting streams to decrease encoding and decoding complexity. o far most of the protocols have one segment per stream. The exception is the Pagoda family schemes. The artful design of these schemes packs different segments together in one stream, thus reducing the numer of roadcasting and donloading streams. Note that streams in roadcasting protocols are logical streams. There is no requirement for 515 IEEE INFOCOM 2001

9 streams in optimally-structured schemes transmit in different physical channels. Different streams can e packed together and transmitted in one physical channel. It adds no more complication to the client to reassemle the segments ith the structure in optimally-structured scheme than Pagoda family schemes. As for the segment numer, as e proved efore, to reduce the segment numer ill end up ith larger server andidth requirement. Again here is the trade-off eteen implementation complexity and performance results. VII. TRUE VOD AND INTERACTIVE FUNCTION UPPORT All the existing roadcasting protocols do not support true VOD, or zero client aiting time. One possile solution is proposed in [14]. It requires the client set-top ox predonload the first segments of the most popular videos. Client can start atching right aay if he tunes into the popular videos. This scheme does not alays ork since client may not ant to atch the predetermined popular videos. Here e propose a slight change to the roadcasting protocols to provide true VOD. Rather than roadcasting the first segment in the netork, the first segment can e transmitted on demand. Its length should e equal to the good donloading time of the second segment that is roadcast in the netork. ince the first segment could e very small, it on t require demanding server andidth. The remaining segments are roadcast as normal. To support interactive VOD in roadcasting schemes is a tough issue. None of the knon protocols support interactive functions. While pause and reind can e supported y introducing more uffer space, fast forarding is the most difficult to implement in roadcasting protocols. Fast forard requires the video data transmitted in shorter time than normal, ut the most efficient roadcasting protocol in terms of server andidth tries to transmit data just in time. Optimally-structured schemes transmit video segments throughout its good donloading time. A x time units forard action ould result in a later segment i donloading less x i of data y the time hen they are needed to e played out, here i is the transmission rate for the ith segment. We propose to possile solutions here to support interactive VOD. The first approach is ased on the optimally-structured scheme. Due to the predetermined nature of roadcasting schemes, e can only support limited fast forard service, say up to x time units of fast forarding. Rather than transmitting each data segment throughout its good segment donloading time, e can change the roadcasting period for each segment to e x time units less than its good donloading time. Note that the corresponding segment stream ill require higher transmission andidth. Another approach is to transmit unreceived portion of the segment on demand. The client should still receive each roadcasting stream as normal and the server ill transmit the missing x i data for each of the later segment i. VIII. BROADCAT V. MULTICAT Broadcasting schemes have proved themselves as efficient for most of the popular videos. They require predetermined server andidth to achieve certain access latency and they are not suject to data loss. The donsides are they are not flexile in providing true or interactive VOD service. Many multicasting schemes are proposed to provide immediate service to users hile still keep server andidth requirement lo. But all these schemes can not perform ell hen client arrival rate is high. The loer ound on required server andidth for multicast schemes is given in [20] as: ln( +1). The roadcasting loer ound given in Equation 3 is exactly a special case here e consider the arrival rate is 1 every time units. In other ords, multicast schemes ith regular client arrival rate of 1= degenerate to roadcast schemes. In real orld, client arrival could e ursty and all multicast schemes can not scale ell hen is too high. We envision that a good ay to provide VOD service is to comine oth the proactive and reactive approaches together. The essence of the existing multicast schemes is to share the later part of the video as much as possile. To transmit first segment of the video immediately and use later segments from roadcasting streams is a promising ay to provide guaranteed service for popular videos. This is essentially to merge users to the shared stream just after the first segment. Notehoever that there is a loer ound server andidth requirement for roadcasting schemes. Broadcasting is not efficient hen the video is not required frequently. VOD system needs to decide certain threshold from hich e can divide videos according to their popularity and choose to transmit them using roadcasting or multicasting schemes. IX. CONCLUDING REMARK Netork andidth has een identified as a serious ottleneck in today s media servers. Many researchers have shon that roadcasting is a good remedy for this prolem. From the pioneering ork of pyramid roadcasting protocol and its variants to the harmonic family protocols, e see the trend of loer roadcasting speed for the video segments. This loer transmission speed at the video servers results in a loer client I/O andidth requirement and less uffer space requirement at the client end. Based on our generalized analysis approach y means of the proposed temporal-andidth map, e oserve that a common thread uniting all these schemes is to transmit the video segments just in time. To achieve the loest server andidth requirement, it is crucial that video segments e transmitted during their good donloading time. We proved that there exists a loer server andidth requirement given client access latency requirement and video length. The loer ound is reached hen there are infinity numer of segments roadcasting in the netork. Given limited segment numer n, the optimal partition of the video is to let the segment progression ith the golden factor of np = +1and each roadcasting stream have equal andidth. The optimal partition of VBR videos can e calculated using a dynamic pro- 516 IEEE INFOCOM 2001

10 gramming algorithm. VBR videos are naturally transmitted ith CBR streams and there is no need to apply smoothing techniques to reduce data loss. The proposed generalized analysis approach provides an insight look at the roadcasting protocols. The four important performance measures: roadcasting andidth, access latency, client I/O andidth requirement and uffer space requirement can e oserved through the temporal-andidth map. To design a roadcasting scheme to meet different performance requirement, e can start ith the optimally-structured schemes and then tailor them to meet the other requirements. The resulting scheme ill require the least server andidth hile still meet the other requirements. We provided examples on ho to restrict client I/O andidth and provide interactive function ased on this approach. The essence of all the protocols in VOD system, no matter they are roadcasting or multicasting schemes, is to let users share as much data as possile. The reactive multicast approach degenerates to roadcast structure for the arrival rate of 1=. We envision a etter ay to provide VOD service is to comine oth reactive and proactive approaches together to provide true interactive and still guaranteed VOD service. [1]. Visanathan and T. Imielinski. Pyramid Broadcasting for video on demand service. In IEEE Multimedia Computing and Netorking Conference, Volume 2417, pp 66-77, an Jose, California, [2] C. C. Aggaral, J. L. Wolf, and P.. Yu. A permutation-ased pyramid roadcasting scheme for video-on-demand systems. In Proc. of the IEEE Int l conf. on Multimedia Computing and ystems 96, Hiroshima, Japan, June [3] K. A. Hua and. heu. kyscraper Broadcasting: a ne roadcasting scheme for metropolitan video-on-demand systems. In IGCOMM 97, pp , Cannes, France, ept ACM. [4] L. Juhn and L. Tseng. Harmonic roadcasting for video-on-demand service. IEEE Transactions on Broadcasting, 43(3): , ept [5] J.-F. Paris,. W. Carter, and D. D. E. Long. Efficient roadcasting protocols for video on demand. In 6th International ymposium on Modeling, Analysis and imulation of Computer and Telecommunication ystems (MACOT 98), pp , July [6] J.-F. Paris,. W. Carter, and D. D. E. Long. A lo andidth roadcasting protocol for video on demand. In Proc. of IEEE Int l Conference on Computer Communications and Netorks (IC3N 98). [7] L. Juhn and L. Tseng. Fast data roadcasting and receiving scheme for popular video service. In IEEE Transactions on Broadcasting, 44(1): , Mar [8] J.-F. Paris,. W. Carter, and D. D. E. Long. A hyrid roadcasting protocol for video on demand. In Proc Multimedia Computing and Netorking Conference (MMCN 99), an Jose, CA, Jan 1999, pp [9] J.-F. Paris. A simple lo-andidth roadcasting protocol for video-ondemand. In Proc. 8th Int l Conference on Computer Communications and Netorks (IC3N 99), Boston-Natick, MA, Oct 1999, pp [10] A. Hu, I. Nikolaidis, P. van Beek. On the design of efficient video-ondemand roadcast schemes. In Proc. of 7th Int l ymp. On Modeling, Analysis and imulation of Computer and Telecommunication ystems (MA- COT 99), pp [11] J.-F. Paris. A roadcasting protocol for compressed video. In Proc. Euromedia 99 Conference, Munich, Germany, Apr 1999, pp [12] D. aparilla, K. Ross, M. Reisslein. Periodic roadcasting ith VBRencoded video. In Proc. of IEEE Infocom 99, pp [13] F. Li, I. Nikolaidis. Trace-adaptive fragmentation for periodic roadcast of VBR video. In Proc. of 9th Int l Workshop on Netork and Operating ystem upport for Digital Audio and Video (NODAV 99), June [14] J.-F. Paris,. W. Carter, and P. E. Mantey. Zero-delay roadcasting protocols for video-on-demand. In proc ACM Multimedia Conference, Orlando, FL, Nov 1999, pp [15] K. c. Almeroth and M. H. Ammar. The use of multicast delivery to provide a scalale and interactive video-on-demand service. IEEE Journal on elected Areas in Communications, 14(5): , Aug [16] C. C. Aggaral, J. L. Wolf and P.. Yu. On optimal piggyack merging policies for video-on-demand systems. In Proc ACM IGMETRIC Conf. On Measurement and Modeling of Computer ystems, Philadelphia, PA, May 1996, pp [17] A. Dan, D. itaram and P. hahauddin. cheduling policies for an on-demand video server ith atching. In Proc. 6th Int l. Multimedia Conf.(ACM Multimedia 94), an Francisco, CA, Oct 1994, pp [18] K. A. Hua, Y. Cai and. heu. Patching: a multicast technique for true video-on-demand services. In Proc. 6th ACM Int l. Multimedia Conf. (ACM Multimedia 98), Bristol, U.K., ept 1998, pp [19]. W. Carter and D. D. E. Long. Improving video-on-demand server efficiency through stream tapping. In Proc. 6th Int l. Conf. On Computer Communications and Netorks (ICCCN 97), Las Vegas, NV, ept 1997, pp [20] D. Eager, M. Vernon, J. Zahorjan. Minimizing andidth requirements for on-demand data delivery. In Proc. 5th Int l. Workshop on Multimedia Information ystems (MI 99), Indian Wells, CA, Oct REFERENCE 517 IEEE INFOCOM 2001