Optimal chaining scheme for video-on-demand applications on collaborative networks

972 IEEE TRANSACTIONS ON MULTIMEDIA, VOL. 7, NO. 5, OCTOBER 2005

Optimal Chaining Scheme for Video-on-DemandApplications on Collaborative Networks

Te-Chou Su, Shih-Yu Huang, Chen-Lung Chan, and Jia-Shung Wang, Member, IEEE

Abstract—By forwarding the server stream client by client, achaining-based scheme is a good way to reduce the server streamsfor streaming applications in well-connected networks. In thispaper, we prove that the minimum number of required serverstreams in such schemes is + 1, where is the numberof client requests and is a value determined by client buffersizes and the distribution of requests. In addition, we present anoptimal chaining algorithm using a dynamic buffer allocationstrategy. Compared to existing chaining schemes, our schemenot only utilizes the backward (basic chaining) and/or forward(adaptive chaining) buffer, but also exploits the buffers of otherclients in order to extend the chain as much as possible. In thisway, more clients can be chained together and served by the sameserver stream. Our simulation results show that the requirementsof the server streams in the presented scheme are much lowerthose of existing chaining schemes. We also introduce mechanismsfor handling VCR functions and fault exceptions in practicalapplications.

Index Terms—Chaining, collaborative network, streaming,video-on-demand.

I. INTRODUCTION

STREAMING applications allow users to access remotevideo programs over networks. In general, a dedicated

video stream is delivered from a video server to the subscribeduser to provide a true video-on-demand service. Unfortunately,this requires significant transmission bandwidth in the videoserver and intervening network, which restricts the servicescale. For example, to provide 10 000 users with simultaneousaccess to individual 6-Mbps MPEG-2 video streams, a guar-anteed server and network bandwidth of at least 60 Gbps isrequired. This is not affordable in current network platforms.To address this problem, various multicast (or broadcast)-basedsolutions, such as batching [1], [2], [11], patching [3]–[5], peri-odic broadcasting [6]–[10], and piggybacking [11], have beenproposed. In these schemes, a single copy of the source videostream is delivered to multiple destinations by employing themulticast facility. Although these schemes substantially reducethe transmission cost relative to point-to-point communication,

Manuscript received October 11, 2001; revised February 26, 2003. This workwas supported by MOE Program for Promoting Academic Excellent of Univer-sities under Grant 89-E-FA04-1-4. This work was also supported by the Com-munications Software Technology project of Institute for Information Industryand sponsored by MOEA, R.O.C. The associate editor coordinating the reviewof this manuscript and approving it for publication was Dr. Harrick M. Vin.

T.-C. Su, C.-L. Chan, and J.-S. Wang are with the Department of ComputerScience, National Tsing Hua University, Hsinchu, Taiwan, R.O.C. (e-mail:[email protected]; [email protected]; [email protected]).

S.-Y. Huang is with the Department of Computer Science and InformationEngineering, Ming Chuan University, Taoyuan, Taiwan, R.O.C. (e-mail: [email protected]).

Digital Object Identifier 10.1109/TMM.2005.854390

they can only be applied on multicast-enabled networks, andthese are not globally available in the Internet (or in intranets)due to the lack of widespread deployment and interoperabilityof multicast routers.

An alternative to the multicast solution is a proxy-based ser-vice [12]–[15], which caches videos near client stations. Al-though the original server load can be distributed over theseproxies, two problems arise.

1) Only a limited number of hot videos can be cached ina proxy since the size of a video program is significantlylarger than a typical file. In this way, lots of requests willbe redirected to the content server.2) Even a request finds a proxy with the cached hot video,it may not be served successfully because of the servicecapability of a proxy.

To further reduce a proxy or a server load, Hua et al. [16]presented the clientside caching scheme, called Earthworm.Using the similar buffering technique of interval caching [17],each client not only plays back the received video stream butalso forward it to another client with an adequate bufferingdelay. Therefore, clients requesting the same video programcan be “chained” together and served in a single server stream.In addition, Sheu et al. [18] proposed extended chaining, whichcombines the earthworm scheme (called basic chaining) witha batching scheme to extend the video chain. In both schemes,the client buffer is used as a backward bridge to the followingclient in a video chain. Therefore, when the client buffer is toosmall to hold the data transmitted during the inter-arrival time(playback gap) between two consecutive requests, the videochain must be broken and a new server stream is required. Toaddress this problem, Chen et al. [19] further presented adap-tive chaining, which achieved nearly twice the performanceof basic chaining by using a two-way bridging technique inwhich both the forward and/or backward client buffers areused. However, the length of the video chain is still limitedby the combined size of client buffers. In addition, the unusedfragments of the forward and/or backward client buffers cannotbe used in both schemes.

To extend the chain as much as possible, this paper pro-poses a novel bridging technique, called optimal chaining. Thepresented scheme not only utilizes the backward buffer (basicchaining) and/or the forward buffer (adaptive chaining), butalso exploits the buffers of other clients when the playback gapis larger than the combined size of these two buffers. The con-cept of exploiting other client buffers is especially practical inwell-connected networks, such as a campus network or intranetin which hundreds of clients are online and their buffers canbe shared efficiently. Compared to proxy-based solution, the

1520-9210/$20.00 © 2005 IEEE

SU et al.: OPTIMAL CHAINING SCHEME FOR VIDEO-ON-DEMAND APPLICATIONS ON COLLABORATIVE NETWORKS 973

presented scheme caches much more videos in clients becausethe total number of buffer space is proportional to the numberof participating clients. In this way, the hit ratio becomes muchhigher than proxy when more clients participate. Moreover, theload of serving requests are dynamically distributed to clients,not converged to a small amount of proxies assigned.

In addition to introduce the borrowing concept, this paper alsopresents an optimal chaining algorithm and proves that the min-imum number of required server streams is , where

is the number of client requests and is a value determinedby client buffer sizes and the distribution of client requests. Thispaper also studies the deployment issues of optimal chaining, in-cluding the network model, the fault-tolerance design, the sup-port of interactive VCR functions, and the architecture of theclient stations. All these features have been implemented on aprototype of our streaming video system.

The remainder of this paper is organized as follows. Sec-tion II introduces the concepts of various chaining schemes.In Section III, two optimal chaining algorithms are presentedfor offline and online applications. Deployment issues of op-timal chaining and the network model are introduced in Sec-tion IV. Section V evaluates the performance of various chainingschemes using simulations. Conclusions are finally drawn inSection VI.

II. CHAINING SCHEMES

This section introduces the concept of various chaining-basedschemes, including basic chaining (earthworm), adaptivechaining, and the new optimal chaining presented here. In achaining-based scheme, each client not only plays back thereceived video stream but also caches a sliding window of thevideo stream into disk or memory space. Then, the cached datais forwarded to another client with a buffering delay sufficientto meet that client’s playback time. Therefore, clients whorequest the same video stream can be “chained” together ina single server stream. Without loss of generality, the size ofcached unit can be assumed to hold 1-s of video data. Forexample, a 1-h video program can be represented as segments

.To illustrate the data flow in the basic chaining scheme, let us

consider the following example. There are five clients , ,, , and , each of which has a 2-s chaining buffer. All

clients access the same video program sequentially at times ,, , , and , respectively. Let , ,

, and be the playback gaps for, , , and , respectively. Fig. 1(a) shows an example

of a basic chaining scheme at a snapshot, . Initially,the server generates a video stream for the first request, fromclient . When client receives the video, the received datais displayed and simultaneously stored in ’s buffer. Whenclient issues a request at time , it can chain to clientsince the current stored video segments and in client(called the backward buffer for the request of client ) can beforwarded to client to meet the playback gap, .Therefore, no additional server stream is required. On the otherhand, clients and cannot join the existing chain becausetheir playback gaps, and , are greater

Fig. 1. Snapshots at time t +13 s for chaining, adaptive chaining, and optimalchaining. (a) Chaining. (b) Adaptive chaining. (c) Optimal chaining.

than the corresponding 2-s backward buffers. Two additionalserver streams are generated for clients and . Clientcan chain to client because the client ’s buffer is largerthan the playback gap, . Therefore, in total, threevideo streams are required.

In basic chaining, a video chain must be broken when theplayback gap between two consecutive clients requesting thesame video is larger than the backward buffer. To address thisproblem, adaptive chaining was proposed to utilize both thebackward and its own buffer (called the forward buffer) to chaina client request. This two-way bridging technique is shown inFig. 1(b). The behaviors of clients and are similar to thosein basic chaining. Client can chain to client because thecombined size of the backward and forward buffers is larger thanthe playback gap, . However, client cannot jointhe chain because the unused fragment of the backward bufferin client and the forward buffer is too small to meet the play-back gap, . A new server stream must therefore begenerated. In this example, two server streams (video chains)are required. Although adaptive chaining achieves better perfor-mance than basic chaining, the length of the video chain is stilllimited by the sizes of the forward and backward client buffers.In addition, the unused fragments of client buffers can not beused in both schemes. For example, in Fig. 1(b), 1 unit of bufferin client is not used after chaining.

To utilize client buffers more efficiently, we present a novelbridging technique, called optimal chaining, which is optimalin terms of minimizing the required server streams. In optimalchaining, not only are both the backward and forward buffersused in chaining a client request, but also all the available bufferscan be utilized to extend the chain as much as possible. Fig. 1(c)


Fig. 2. On-line optimal chaining algorithm.

shows an example of how the optimal chaining scheme utilizesclient ’s buffer when chaining client ’s request. For therequest from client , by borrowing a 1-s buffer from client

, we can relay the stream from client to client and thento client to meet the playback requirement. No additionalserver stream is required in this case. Finally, client can bechained to client because the unused 1-s buffer in clientcan also fulfill their playback gap. Thus, only one video streamis required for all five clients in optimal chaining.

The above example demonstrates that the shared buffer andthe playback gaps heavily affect the number of required serverstreams in optimal chaining. If the shared buffer is large enoughto fulfill the playback gaps, all requests can be chained togetherand only one video stream is sufficient. However, we usually donot have such large amount of buffer, and hence efficient buffermanagement is required. For example, a client with a very largeplayback gap should not join the chain since it will consumeconsiderably more buffers than those clients with smaller play-back gaps. In Section III, we present two optimal buffer manage-ment algorithms for offline and online streaming applications.

III. OPTIMAL CHAINING ALGORITHMS

Assume that there are clients, where client has a chainingbuffer of size . Therefore, the total size of the shared bufferis . Every client requests a video program attimes , where for .Without loss of generality, we assume that issues a requestat time for all and all clients request the same video programas . Also, in the following analysis, we assume that

is less than the video length since the buffer allocated to aclient will be released after the video program ends, and thisreleased buffer can be reallocated to other clients. Each client

either initiates a new server stream or shares anexisting server stream via a sequence of bridge buffers. Clearly,the buffer required to chain client ’s request must be of atleast length . Let be the buffer size required to bridgethe playback gap between client and , .(Note that no buffer is consumed if the request initiates a newserver stream.) The minimum number of required server streamscan be derived in the following two cases.

Case I: : The sum of the required buffer sizesis less than the total buffer size . In this case,

one server stream is sufficient.

Case II: : The total available buffer is insuffi-cient, and hence more than one server stream is re-quired. Let be the sorted sequence of

in a nondecreasing order (i.e.,). Let

. Then the minimum number of required serverstreams is equal to , as explained in thefollowing.

Trivially, from the definition of , the lowest possible numberof server streams is . If all the client requests areknown in advance (as in an offline situation), the definition ofin case II suggests a simple offline optimal chaining algorithm:let be a set of clients corresponding to the playback gaps

. A new server stream is initiated for each clientthat is not in , otherwise we allocate the client buffer to chainthis request to an existing video chain. This algorithm will gen-erate server streams (video chains), and allocate thebuffer of size , which is less than . In addition, if thevalue of is unique, is a threshold value of the playback gapthat determines whether or not a client should join the existingvideo chain.

A. On-Line Algorithm Design

In online applications, the request pattern is unknown andhence we do not know whether or not the current client requestis in the set . Because of this, we present an online optimalchaining algorithm in Fig. 2. The key of the on-line algorithm isto greedily allocate buffers for the current request and dynam-ically release those allocated buffers of size equal to or largerthan when the available buffer is insufficient. Since we donot know the value of in advance, we replace the one whosebuffer size is currently the largest. Let be the size of the al-located buffer for chaining client . Then if clientinitiates a server stream; otherwise, .

Line 1 in Fig. 2 tests whether or not the total available buffersatisfy the current buffer requirement. If so, client is chainedto an existing video chain by allocating the buffer. Similar tothe chaining scheme, the backward buffer is first used to bridgethe playback gap between and . If the backward bufferis smaller than , the forward buffer is utilized. When the totalsize of the backward and forward buffers is still smaller than ,the buffers of other clients are utilized. The details of allocatingother clients’ buffers are given in the next paragraph. When the


Fig. 3. Patching the missing segments.

total buffer size is insufficient to serve the current request, lines4–12 are executed to achieve the same results as the offline algo-rithm. Line 5 chooses the request using the largest buffer from

to . If the largest bridged buffer, , is less than or equalto , a new server stream is generated for the request from(line 7). On the other hand, if , client is reconnectedto the server and a buffer of size is released (lines 9 and 10).This released buffer is then reallocated to chain the request from

in line 11.Since in the online environment we do not know when and

where the next request will be issued, when processing the re-quest from , the first few video segments may not be cachedin the chaining buffer for client . We need a mechanism topatch this problem. Similar to the patching scheme [3], whenchaining client , the chaining path with an adequate bufferingdelay of is established to receive the video segments cur-rently available on client . Meanwhile, a temporary serverstream (patching stream) is established to fetch the first fewmissing segments. For the first time period, client plays thevideo from the patching stream, and then subsequently playsthe chaining stream. Fig. 3 shows an example of this process.The playback gap between clients and is 3 s. A patchingstream for segments , , and is established for the first 3 s.Simultaneously, the normal chaining path with a 3-s bufferingdelay is established for segments starting from . After 3 s, theclient plays the video from the normal chaining stream and re-leases the patching stream. Note that if the previous clientgreedily stores the incoming video segments and discards themas late as possible, i.e., only when its buffer is close to full, thetransmitted video segments in the patching stream can be re-duced or even avoided. Although the greedy storage of data maybe found to be impractical in the future, currently it is not prob-lematic since this buffer can be reused when necessary.

Max-fit strategy is used to borrow buffers. When chaining aclient request to an existing chain (lines 2 and 11 in Fig. 2),the number of participating clients should be as small as pos-sible because more clients implies more network traffic. For thisreason, the client with the largest available buffer should be se-lected first. If the selected buffer is less than or equal to the play-back constraint, we exhaust it so as to avoid this client beingborrowed from again. On the other hand, the process for findingthe current maximum buffer will be executed iteratively untilthe total borrowed buffer fits the playback constraint. Note thatwhen the found available buffer is larger than the playback con-straint, some free buffer will remain. This phenomenon can befurther improved by implementing a best-fit strategy followedby the max-fit.

B. The Correctness of the On-Line Algorithm

We prove the correctness of this on-line algorithm as below.

Fig. 4. Architecture of the proposed network model.

Theorem: The proposed on-line algorithm is optimal. Thatis, this algorithm consumes number of server streamsand uses up the buffer of size , which is less than B.

Proof: As discussed above, we only have to prove that allof the clients whose allocated buffers of size equal to or largerthan will be redirected to the server.

In the proposed algorithm, the reschedule process is executedonly when and (line 8), where the bufferpreviously allocated for client is released and re-allocatedto client (line 10). Let be thesize of the first released buffer, and let

. We have . Similarly, thesize of the next released buffer, , is less than or equal to .Finally, we have , where

is the final set of chaining buffers and corresponds to thelast released buffer. It is easily seen that this set is optimal.Accordingly, the theorem is proved.

IV. DEPLOYMENT ISSUES

The borrowing mechanism in optimal chaining works per-fectly in a well-connected network, such as a campus networkor intranet. However, some issues should be considered for ap-plying it to other practical networks. The overhead of networkconsiderably increases if we arbitrarily allow the borrowing onall clients because the algorithm does not consider the distanceinformation. In this section, optimal chaining is modified to ac-commodate the real network environments, based on a proposedregion-based collaborative network model. Moreover, to ensurethat the system can be user-friendly and robust, VCR functionsand fault handling process are also presented.

A. Region-Based Collaborative Network Model

Fig. 4 shows a demonstrative architecture of the region-basednetwork model. A collaborative network forms a region inwhich hundreds of clients are active and their buffers can beshared efficiently. Numbers of collaborative networks are con-nected to backbone. In this model, we assume that bandwidth


in each collaborative network is sufficient but is limited onbackbone. One or more video servers are deployed on backboneor in collaborative networks. There is a web server (manager) tomaintain directory information about video programs. In eachcollaborative network, there is a service gateway to managelocal chaining and buffering information that is collected andupdated by client events.

Each client consists of a display module and a chainingmodule. Display module controls and plays back the videoprogram. Chaining module caches the incoming video streamand relays it to display module or to other clients’ chainingmodules. In our implementation, the chaining buffer is allocatedfrom hard disks via Microsoft Windows file system. To enhanceI/O performance, a file-mapping technique is employed tomap the data from disks to memory of the system. The sizeof client chaining buffer is configurable (50 MB in default).Each video stream is assumed of constant bit rate and its cacheunit is 1 MB. Data exchanged between chaining and displaymodules is accomplished by Inter Process Communication(IPC). All clients will register their chaining buffer and networkbandwidth on the service gateway when they boot up.

B. Near-Optimal Chaining Algorithm on Region-BasedCollaborative Network

To chain client to , optimal chaining uses the max-fitstrategy to choose participating clients while executing the bor-rowing process. Suppose clients and are located at region

and , respectively. Traffic on backbone will be consider-ably increased if the chosen clients are not both located on re-gion or . To reduce the required bandwidth of backbone,we change the max-fit strategy into regional max-fit. We firstutilize buffers of region and . When the above buffers areexhausted, buffers of other regions are then borrowed one by onethrough backbone. By using regional max-fit strategy, traffics onbackbone can be significantly reduced, as shown by the exper-imental results in Section V. We denote this revised algorithmas the near-optimal chaining algorithm because the solution isstill optimal within a collaborative network.

Another concern is the overhead of chaining because the moreclients involved, the more bandwidth required. The original al-gorithm serves a client request if the size of total buffers is equalto or larger than that of the required buffer (line 1 in Fig. 2). Al-though this strategy fully utilizes client buffers, the number ofborrowed clients may be significantly large when each buffer issmall or the required buffer is large especially. To address thisproblem, we add a threshold mechanism to limit the numberof clients involved. That is, a client request joins in an existingvideo chain only if the required number of borrowed clientsis less than a preset threshold value. Otherwise, a new serverstream is created. Although this revision increases the amountof required server streams, the length of video chain can be lim-ited to a reasonable value. In addition, shorter length of videochain implies smaller delay to start-up a request.

C. VCR Operations Support

VCR operations include play, pause, stop, fast-forward, seek,, etc. Obviously, the chaining process presents the intrinsic

play operation. To illustrate VCR-pause and VCR-resume op-erations, let’s consider the following scenario: A client playeda stream at time , paused at time and resumed at time

. Initially, this client was served by a video chain. When theclient paused, it doesn’t consume video data during the pausedperiod but the video chain is still ongoing. In this way, the orig-inal video stream may not meet the access time after a client re-sumes. Therefore, a client leaves a video chain when it pauses.

When the client resumed at time , it requires video seg-ments starting from (paused point). To serve this request im-mediately, we must find a client that can deliver the expectedsegments. If such client was found, a chaining path with nobuffering delay is established to serve the resumed client. Oth-erwise, a client with the near future segments, for example seg-ments after , can be a candidate. This case is similar to on-line algorithm in Fig. 2. Two streams are established simulta-neously. The first (from a server) is for segments and andthe second (from the candidate) is for segments followingwith 2-s buffering delay. If no client satisfies above two cases,a dedicated server stream is allocated for this resumed client.Concisely, the resume process can be considered as a VCR-playoperation with parameter of segment offset.

The same concept can be applied to other VCR operations.For example, VCR-stop operation can be achieved by leavingan existing video chain. VCR-fast-forward operation is com-bined by VCR-stop and then VCR-play at the specific rate.Other VCR operations (jump-forward, jump-backward andslow-down) have similar properties. In summary, all VCRoperations can be achieved by the combination of VCR-playwith parameters (segment offset, video rate) and VCR-stopoperations, which are supported by online chaining algorithm.

D. Fault Tolerance

In chaining-based schemes, the failure of any client corruptsa video chain service. To address this problem, we present thefault detection and recovery process. Both processes are basedon a client-server model which is simple to manage and imple-ment in real systems.

In a video chain, a node can be considered as a “client” re-spective to its immediate upstream node and vice-versa. Once anode fails, its downstream node will detect this situation after re-ceiving time out. To recover from the fault, the downstream nodesignals this situation to service gateway and issues a VCRplayoperation with segment offset to get the missing segments. Onthe other hand, the upstream node of the fault node can also de-tect this condition by periodical control message between clientand server. When a node detects its downstream nodes failed,the related resources for the fault nodes are released.

In addition to maintain a reliable video chain, we also developa protocol to make sure the service gateway works correctly. Inour prototype, the fault of service gateway is detected when aclient issues a new request to the service gateway but does notreceive response during a period. In this situation, this clienttries to be a new service gateway by broadcasting ELECT mes-sage. Although many clients may initiate ELECT message con-currently, only the client with the longest alive time will finallybe a new service gateway. When a new service gateway starts,it broadcasts a QUREY message to all clients in a collaborative


Fig. 5. Flow control model.

Fig. 6. Example of system flow.

network and set a timer to collect information responded fromclients. After time out, this service gateway starts its services.Since the above broadcast messages are considerably smallerthan the traffic of video streams, it is not problematic for net-work load.

E. Flow Control

For performance and real-time issues, video data is usuallytransmitted via unreliable UDP service in the Internet. UnlikeTCP service, the delivered video data may be lost because UDPpacket is sent without loss control. In addition, Internet protocoldoes not support Quality of Service (QoS) service. The videodata may be delayed or jittered. To address this problem, wedesign a control mechanism that is applied piece-wisely in avideo chain to avoid the propagation of packet jitter or lost.

Fig. 5 shows the presented flow control to smooth the averagetransmission rate of each cache unit via feedback control mes-sages. When the received data in client is underflow or over-flow, sends a control message to to change its transmis-sion rate. Because the target bit rate of cache unit is dynamicallyconfigurable, the average transmission rate of each cache unit isapproximate to the data rate of a video stream. Therefore, theinstant network jitter can be smoothed via the cache buffer. Onthe other hand, a packet lost can be detected in client viaa sequence number. This condition triggers client to get thelost packet by sending a control message to . Meanwhile, weadd a tag in the position of corresponding buffer in client .If the lost packet is received before the transmission of the nextsegment, this tag is clear. On the other hand, if the lost packet isnot received, this tag will propagate to the next client. When aclient receives a packet marked with lost tag, this client tries toget the lost packet by sending a control message to a server. Thisprocess is repeated until the lost packet is received in a client. Inthis way, the propagation of a lost packet stops. Although partof video data is lost in some clients, this is not a severe problemsince most of video player is tolerable for such error.

F. An Example of System Flows

Fig. 6 shows an illustrative example of message flow for aclient request. At step 1 and 2, client gets the video in-formation from the web server (manager) and passes this in-

TABLE IDEFAULT SIMULATION PARAMETERS

formation to display module. At step 3, display modulesends PLAY message with parameters (video_id, server_url,play_offset, play_rate) to chaining module . If the requiredvideo segments are not cached in chaining module, a QUERYmessage is sent to the service gateway at step 4 to query thechaining information. At step 5, service gateway responds witha chaining path and the video segment offset. The chaining pathis represented by a list of (client, buffer) pairs. In this example,( , ) and ( , ) are responded. On receiving this infor-mation, sends a PLAY message with parameters containing( , ) to (step 6a) and enter a play state to playback thevideo. Note that if the first few segments cannot be offered, apatch stream is setup concurrently to get the missing segments(steps 6b and 7b). On the other hand, sends another PLAYmessage to (step 7a) according the chaining information( , ). Once this chaining path is setup (steps 8a and 9a), thevideo segments are delivered from to and to with ad-equate buffering delay.

V. PERFORMANCE STUDY

This section studies the performance on two major points.The first focuses on the comparison among various chainingschemes. For this reason, only one collaborative network is con-sidered. The second simulation studies the performance of therevised algorithm in region-based network, which is the generalarchitecture in real world.

In the following simulations, we assume that there areclients in a collaborative network. Each client has buffer.The inter-arrival time of client requests follows a Poisson distri-bution with mean . There is one video server and videoprograms, which access pattern is according to a Zipf’s-likedistribution [15] with skew factor . That is, the probability ofchoosing popular video for a request is

Table I lists the default parameters.Fig. 7 shows the effect of required server streams and the

corresponding buffer usage among various chaining schemes.In both basic and adaptive chaining schemes, large amount ofclient buffers are not used. On the other hand, optimal chainingutilizes all the available buffers and thus has significant benefitthan the others. As depicted in Fig. 7(a), only one server streamfor each video program is required before buffers are exhausted


Fig. 7. Effect on the required server streams. (a) Required server streams. (b)Total available buffer.

(about 2600 s). Because dynamic buffer management in optimalchaining (line 9–10 in Fig. 2) is applied to “re-chain” the clients,the required server streams increase gradually. After 5400 s, thenumber of the required server streams in all chaining schemesis stable because some clients had finished and released the al-located buffers. In statistics point of view, the allocated and re-leased buffers are almost equal.

To study the impact of the client buffer size on the requiredserver streams and the length of a video chain, we change theclient buffer size from 20 to 220 s. Fig. 8(a) shows this simu-lation results. In optimal chaining, the number of the requiredserver streams is less than the number of offered video pro-grams when client buffer is larger than 160 s. This phenomenonis interesting because some popular video programs are alwayscached on video chains after the server sent out the last segment.Such video chains are traversed client by client if a new requestcan join into this video chain. In this way, no server stream forthat video is required in the future. Fig. 8(b) shows the videoaccess pattern and the required server streams. In this simula-tion, client buffer size is 180 s. Although 50 video programsare offered, only 36 server streams are required. This figurealso indicates that the buffer management is efficient in optimalchaining since most of buffers are used for popular video pro-grams. Fig. 8(c) shows the average number of served clients in avideo chain on various buffer sizes. As indicated, the number ofserved clients in optimal chaining grows much rapidly than theothers as the size of client buffers increases. This means that op-

Fig. 8. Effect on the client buffer size and the number of served clients in achain. (a) Required server streams. (b) Video access pattern and the requiredstreams. (c) Average number of clients in a chain.

timal chaining will get much better performance than the othertwo schemes when more client buffers are available.

Fig. 9 shows the effect of the video programs offered in thesystem. The simulation results suggest a practical deploymentissue of how many video programs should be offered when theserver and the network resources are given in various chainingschemes. For example, if the server is able to concurrentlytransmit 150 video streams, about 10 and 40 video programscan be offered in the adaptive chaining and optimal chaining,respectively.

Fig. 10 studies the impact of the number of clients on the re-quired server streams, which is varied from 1000 to 4000. The


Fig. 9. Effect of video programs.

Fig. 10. Effect on the number of clients.

mean value of inter-arrival time is determined by the numberof clients such that there are always 50% clients playing back avideo program concurrently. This simulation shows a very inter-esting result. Less server streams are required when more clientsparticipate in optimal chaining because the available buffer sizesare proportional to the number of clients. On the other hand,buffers used in basic and adaptive chaining are restricted by thebackward and forward buffers. Although the playback gap issmall when more clients request a video program, however, theincreasing of the requests makes the required server streams in-creased in both basic and adaptive chaining schemes.

Finally, we study the performance of near-optimal chainingalgorithm operated on a region-based network stated in Sec-tion IV. In this simulation, there are one video server and 10 000clients which are randomly distributed in ten collaborativenetworks. Each client has 200 s buffers and the server offers1000 video programs. The inter-arrival time is 2 s. Fig. 11(a)and 11(b) shows the effect of the threshold mechanism on theserver streams and chaining overhead, respectively. It indicatesthat the number of the required server streams decreases asthe number of involved clients increases. The behavior ofthe revised algorithm with the threshold value 2 is the sameas that of adaptive chaining. In this case, lots of additionalserver streaming are produced although no chaining overheadis included. When the threshold value increases to 20, only554 server streams are required in the revised algorithm (about14.7% extra number of server streams than optimal chaining,483 server streams). In this threshold value, the average numberof involved clients is only 2.03. The overhead is so little that canbe accepted. Fig. 11(c) shows the effect of the regional max-fitstrategy. As indicated, regional max-fit significantly reduces

Fig. 11. Performance of near-optimal chaining algorithm on region-basedcollaborative network. (a) Required server streams. (b) Average length ofinvolved clients. (c) Backbone bandwidth.

the required backbone bandwidth. When the threshold value is20, the number of streams on backbone is reduced from 13 743to 3451. Accordingly, combining regional control of borrowedbuffers and threshold control of involved clients alleviate thenetwork overhead, which is one of the major concerns in realsystems.

VI. CONCLUSIONS

Chaining that utilizes client buffers is an efficient method forreducing the required video streams in streaming applications.To extend the chain as much as possible, we propose an optimalchaining scheme that utilizes not only the backward and forward


buffers, but also all the available client buffers in a collaborativenetwork. In this paper, the lower bound of the optimal chainingproblem is first proven. An optimal chaining algorithm is thenpresented based on a dynamic buffer allocation technology. Inaddition, in order to build a robust system, we develop mecha-nisms to handle VCR functions and faults. We have built a pro-totype on our campus network to evaluate the practical usageof the optimal chaining scheme. With small buffers allocatedto each client, the simulation results indicate that only a fewserver streams are required for all user requests, tremendouslyreducing the server load and avoiding a network bottleneck atthe server. The simulation has also shown the interesting resultthat fewer video streams are required when there are more usersin the collaborative network. This result inherently makes theoptimal chaining scheme scalable to the streaming services.

REFERENCES

[1] S. Ramesh, I. Rhee, and K. Guo, “Multicast with cache (Mcache): anadaptive zero-delay video-on-demand service,” IEEE Trans. CircuitsSyst. Video Technol., vol. 11, no. 3, pp. 440–456, Mar. 2001.

[2] W.-F. Poon, K.-T. Lo, and J. Feng, “Adaptive batching scheme for mul-ticast video-on-demand systems,” IEEE Trans. Broadcast., vol. 47, no.1, pp. 66–70, Mar. 2001.

[3] K. A. Hua, Y. Cai, and S. Sheu, “Patching: a multicast technique for truevideo-on-demand,” in Proc. ACM Multimedia, Bristol, U.K., Sep. 1998,pp. 191–200.

[4] Y. Cai, K. A. Hua, and K. Vu, “Optimizing patching performance,” inProc. IS&TSPIE Conf. Multimedia Computing and Networking, SanJose, CA, Jan. 1999, pp. 204–216.

[5] S. Sen, L. Gao, J. Rexford, and D. Towsley, “Optimal patching schemefor efficient multimedia streaming,” in Proc. NOSSDAV, Basking Ridge,NJ, Jun. 1999.

[6] C. C. Aggarwal, J. L. Wolf, and P. S. Yu, “A permutation-based pyramidbroadcasting scheme for video-on-demand systems,” in Proc. IEEE Int.Conf. Multimedia Computing and Systems, Hiroshima, Japan, Jun. 1996,pp. 118–126.

[7] K. A. Hua and S. Sheu, “Skyscraper broadcasting: A new broadcastingscheme for metropolitan video-on-demand systems,” in Proc. ACM SIG-COMM, Cannes, France, Sep. 1997, pp. 89–100.

[8] L.-S. Juhn and L.-M. Tseng, “Harmonic broadcasting for video-on-de-mand service,” IEEE Trans. Broadcast., vol. 43, no. 3, pp. 268–271, Sep.1997.

[9] D. L. Eager and M. K. Vernon, “Dynamic skyscraper broadcasts forvideo-on-demand,” in Proc. 4th Int. Workshop Multimedia InformationSystems (MIS’98), Istanbul, Turkey, Sep. 1998, pp. 18–32.

[10] D. Saparilla, K. W. Ross, and M. Reisslein, “Periodic broadcasting withVBR-encoded video,” in Proc. IEEE INFOCOM ’99, vol. 2, New York,Mar. 1999, pp. 464–471.

[11] N. L. S. Fonseca and R. A. Facanha, “Integrating batching and piggy-backing in video servers,” in Proc. IEEE GLOBECOM ’00, vol. 3, SanFrancisco, CA, Nov. 2000, pp. 1334–1338.

[12] W. H. Ma and D. H. C. Du, “Reducing bandwidth requirement for deliv-ering video over wide area networks with proxy server,” in Proc. IEEEICME 2000, vol. 2, New York, Aug. 2000, pp. 991–994.

[13] Z. L. Zhang, Y. W. Wang, D. H. C. Du, and D. L. Su, “Video staging: aproxy-server-based approach to end-to-end video delivery over wide-area networks,” IEEE/ACM Trans. Netw., vol. 8, no. 4, pp. 429–442,Aug. 2000.

[14] R. Rejaie, H. B. Yu, M. Handley, and D. Estrin, “Multimedia proxycaching mechanism for quality adaptive streaming applications in theInternet,” in Proc. IEEE INFOCOM 2000, vol. 2, Tel Aviv, Israel, Mar.2000, pp. 980–989.

[15] L. Breslau, P. Cao, L. Fan, G. Phillips, and S. Shenker, “Web cachingand Zipf-like distributions: evidence and implications,” in Proc. IEEEINFOCOM ’99, vol. 1, New York, Mar. 1999, pp. 126–134.

[16] K. A. Hua, S. Sheu, and J. Z. Wang, “Earthworm: a network memorymanagement technique for large-scale distributed multimedia applica-tions,” in Proc. IEEE INFOCOM ’97, vol. 3, Kobe, Japan, Apr. 1997,pp. 990–997.

[17] A. Dan and D. Sitaram, “Buffer Management Policy for an On-DemandVideo Server,”, IBM Res. Rep. RC 19347, Oct. 1994.

[18] S. Sheu, K. A. Hua, and W. Tavanapong, “Chaining: a generalizedbatching technique for video-on-demand systems,” in Proc. IEEE Int.Conf. Multimedia Computing and Systems, Ottawa, ON, Canada, 1997,pp. 110–117.

[19] J. K. Chen and J. L. C. Wu, “Adaptive chaining scheme for distributedVOD applications,” IEEE Trans. Broadcast., vol. 45, no. 2, pp. 215–224,Jun. 1999.

Te-Chou Su received the B.S. degree in applied mathematics from NationalChung Hsing University, Taichung, Taiwan, R.O.C., in 1992, and the M.S.and Ph.D. degrees in computer science from National Tsing Hua University,Hsinchu, Taiwan, R.O.C., in 1994 and 2002, respectively.

His research interests include video streaming, multimedia applications, andmulticast communications.

Shih-Yu Huang received the B.S. degree in information engineering fromTatung Institute of Technology, Taipei, Taiwan, R.O.C., in 1988, and the M.S.and Ph.D. degrees in computer science from National Tsing Hua University,Hsinchu, Taiwan, n 1990 and 1995, respectively.

From 1995 to 1999, he was with the Chunghwa Telecom, as a member of theTelecommunication Laboratories. In 1999, he joined the Department of Com-puter Science, Ming Chuan University, Taiwan. His current interests are imagecompression, visual communication, and digital libraries.

Chen-Lung Chan received the B.S. and M.S. degrees in computer science fromNational Tsing Hua University, Hsinchu, Taiwan, R.O.C., in 1999 and 2001,respectively. He is currently working toward the Ph.D. degree.

His research interests include multimedia delivery, P2P network, storage, andwireless communications.

Jia-Shung Wang received the B.S. degree in mathematics from NationalTaiwan University, Taiwan, R.O.C. in 1978, and the M.S. and Ph.D. degreesin computer science from National Tsing Hua University, Hsinchu, Taiwan,R.O.C., in 1983 and 1986, respectively.

He joined the Computer Science Department, National Tsing Hua Univer-sity, in 1986 as an Associate Professor and became a Full Professor in 1995. Hecurrently serves as the Director of the Institute of Information Systems and Ap-plications and the Director of the Industrial Affiliates Program of the Electricaland Electronic Computer Sciences College, National Tsing Hua University. Hisresearch interests cover several aspects of multimedia networking, video coding,and VLSI design.

Dr. Wang was awarded the Dr. Sun-Yet-Sen Technology award in 1989 andnumerous other awards for his inventions, program competition, and thesis su-pervision.

Documents

Optimal chaining scheme for video-on-demand applications on collaborative networks