In conventionalvideo-on-demand(VoD) systems,compressed digitalvideo streams arestored in a videoserver for delivery toreceiver stations overa communicationnetwork. This articleintroduces aframework for thedesign of parallelvideo serverarchitectures andaddresses threecentral architecturalissues: videodistributionarchitectures, serverstriping policies, andvideo deliveryprotocols.

Among the many different types ofmedia available for retrieval, retriev-ing full-motion, high-quality videoin real time—video-on-demand

(VoD)—poses the greatest challenges. Digitalvideo not only requires significantly more storagespace and transmission bandwidth than tradi-tional data services, it must be delivered in timefor continuous playback. Many studies conduct-ed in the last decade have addressed these issues.

One common architecture shared by most VoDsystems is a single-server model. The video serverscan range from a standard PC for small-scale sys-tems to massively parallel supercomputers withthousands of processors for large-scale systems.However, this single-server approach has its limi-tations.

ScalabilityThe first of these limitations is capacity. When

demand exceeds the server’s capacity, one mayneed to replicate data to a new server. This dou-bles the system’s storage requirements. To reducestorage overhead in replication and to balance theload among replicated servers, a number of studieshave proposed replication algorithms based onvideo popularity as well as server heterogeneity,for example different storage and bandwidth.1,2 Asecond approach partitions the video titles intodisjointed subsets and stores each subset on a sep-arate video server. Although this approach doesnot incur extra storage, it suffers from anotherproblem—load balancing. Studies have shownthat video retrieval is highly skewed in manyapplications because some videos are more popu-lar than others.3 Furthermore, the skewness

changes with time, particularly when most usershave seen a popular video and it becomes lesspopular. This implies that some video serversmight become overloaded because of a populartitle, while other servers might be underused.

A third approach takes advantage of the scaleeconomy in large VoD systems by batching mul-tiple users to share a single multicast videostream.4 Multicasting popular video titles intomultiple channels in a staggered manner means auser requesting a popular video title can bebatched into one of these multicast channels andshare it with other users. However, this approachdoes not support full VCR-like controls becausethe client can only select preset multicast chan-nels. In a more recent study, Li and Liao proposeda way to merge users into a multicast stream thatsupports full VCR-like controls.5

The effectiveness of the batching approachdepends on the video access pattern as well as thescale of the system. Loosely speaking, batching ismost effective when a large portion of the usersview only a small portion of video titles.

Server fault toleranceA second limitation of single-server VoD sys-

tems is that they cannot survive server failure.While replication can improve reliability, the stor-age requirement will multiply. Partitioning canconfine a server failure to avoid bringing down allservers in the system, but it still suffers from theload-balancing problem discussed earlier. Finally,the batching approach is not intended to provideserver fault tolerance and is also susceptible toserver failure.

Parallel video serverThe scalability and fault tolerance problems are

due to the fundamental limitations of the single-server architecture. Researchers have begun toinvestigate video server designs and implementa-tions based on parallel video server architectureswhere video data are striped (rather than replicat-ed or partitioned) across multiple servers.Designing video servers with parallel architecturesnot only breaks through the capacity limit of asingle server, but also opens the way for server-level fault tolerance. Unlike replication and parti-tion, server-level striping in parallel video serversachieves scalability without extra storage over-head. Moreover, the servers are load-balancedregardless of the skew in video popularities. Thisof course assumes each video stream is stripedacross all servers, which is likely because the stripe

20 1070-986X/98/$10.00 © 1998 IEEE

Parallel VideoServers: A Tutorial

Jack Y.B. LeeThe Chinese University of Hong Kong

Tutorial

.

size is significantly smaller than the video stream.This article introduces a framework for design-

ing parallel video server architectures. I willaddress three central architectural issues: videodistribution architectures, server striping policies,and video delivery protocols for parallel videoservers.

Parallel video distribution architecturesThe essence of parallel video servers is the strip-

ing of data across an array of servers. Since thedata receiver (such as a video decoder) expects asingle stream of video data, data streams fromeach server must first be resequenced and merged.The term proxy refers to the system moduleresponsible for resequencing and merging datafrom multiple servers into a coherent video streamfor delivery to a client. In addition, the proxy canuse data redundancy to mask server failures andachieve server-level fault tolerance.

The proxy is a software or hardware modulethat knows the system’s configuration. Thisknowledge includes the number and addresses ofservers, data locations, and striping policy. Thereare three ways to implement the proxy: at theserver computer—proxy-at-server; at an indepen-dent computer—independent proxy; and at theclient computer—proxy-at-client. The term com-puter in this context refers to the hardware per-forming the proxy function. In practice, thishardware may or may not be a computer in thegeneral sense.

Proxy-at-serverFigure 1 shows the proxy-at-server architecture,

which includes NS server computers, each per-forming as both storage server and proxy. Becausethere are likely more clients than servers, eachproxy will have to serve multiple clients simulta-neously. The servers are connected locally by aninterconnection network. The proxies combinedata retrieved from local storage and other serversinto a single video data stream for transmission tothe clients.

Under this architecture, system configurationdetails can be completely hidden from clients. Adrawback of this approach is processing and com-munications overhead. For example, to deliver Bbytes of video data from the video servers to aclient, B bytes of data must first be read from oneor more servers’ local storage. This data must thenbe transmitted via network to the client’s proxy(unless the proxy happens to share the same hostas the video server). Finally, the proxy processes

the data and transmits to the client. Assuming allNS servers evenly service requests, then on theaverage B(2NS - 1)/NS bytes of data transmission(server-to-proxy, proxy-to-client) and B(2NS - 1)/NS

bytes of data reception (proxy and client) areneeded for every B bytes of data delivered fromthe storage servers to a client.

Independent proxyAlternatively, separate computers can run the

proxies. Figure 2 shows the independent proxyarchitecture using this approach. The back-endstorage servers and proxy computers are connectedlocally by an interconnection network. Each proxyconnects to multiple clients via another externalnetwork. Similar to the proxy-at-server architec-ture, this independent proxy architecture alsohides server complexity from clients. Moreover,separating the proxy from the server eliminatesinterference between the two processes. This maysimplify the server and proxy implementations.

21

Server S0 Proxy P0

C CC

Server S1 Proxy P1

C CC

Server S2 Proxy P2

C CC

Server S3 Proxy P3

C CC

Server SNS−1 Proxy PNS−1

C CC

Net

wor

kin

terc

onne

ctio

ns

Combing storage serve with proxy server Front-end clients

Figure 1. The proxy-at-

server architecture.

Proxy P0

C CC

Proxy P1

C CC

Proxy P2

C CC

Proxy P3

C CC

Proxy PNp−1

C CC

Net

wor

kin

terc

onne

ctio

ns

Back-endstorage servers

Front-endclients

Independentproxies

Server S0

Server S1

Server S2

Server S3

Server SNS−1

Figure 2. The

independent proxy

architecture.

.

Under the independent proxy architecture,data is first retrieved from the back-end server’slocal storage and then transmitted to the proxy.The receiving proxy then processes and transmitsthe data to clients. Therefore, requesting B bytesof data requires 2B transmission bytes and 2Breception bytes. This approach requires even moreprocessing and network bandwidth than theproxy-at-server architecture. Moreover, additionalhardware and network links are required to hostand connect the proxies.

Proxy-at-clientThe third approach integrates the proxy into

the client, as shown in Figure 3. This can be doneby adding a proxy software module into the oper-ating system or within the application. Under thisarchitecture, a proxy requests the servers to senddata directly to the client computer. After process-ing by the proxy, video data goes directly to theclient application without further network com-munications. Hence, retrieving B bytes from theservers requires only B transmission bytes from theservers and B reception bytes at the client.

Compared with the proxy-at-server and inde-pendent proxy architectures, the proxy-at-clientarchitecture requires only half the amount of datatransfer and does not need separate hardware forthe proxies. The primary advantage of the proxy-at-server and independent proxy architectures isclient transparency (the ability of the proxy tohide the complexity of communicating with mul-tiple servers). However, experimental results froma study by Lee and Wong have shown that theextra complexity involved is negligible, evenwhile running the client in moderate-speed hard-ware such as a 60-MHz Pentium.6

On the other hand, if the computer running aproxy fails under the proxy-at-server and the inde-pendent proxy architecture, it will disrupt the ser-vice of all clients served by the proxy. Conversely,the same situation will only affect a single clientin the proxy-at-client architecture because eachproxy serves only one client and the proxy runsat the client host.

Existing architecturesThe proxy-at-server architecture has been con-

sidered by several researchers.7-9 In Tewari’s paper,they called this the flat architecture. The samestudies also considered a two-tier architectureequivalent to the independent proxy architecture.They called the proxy a delivery node, whichretrieves video data from back-end storage nodesand delivers a single video stream to the client. Theindependent-proxy architecture was also consid-ered in another study by Buddhikot et al.10 Unlikeprevious works, the authors implemented theproxy functionality in their custom asynchronoustransfer mode (ATM) port interconnect controller(APIC), which also functions as the interconnec-tion network linking the storage nodes and theexternal network. Lougher et al. considered usinga striping server in a hierarchical network topolo-gy to perform the proxy functions.11 Finally, theproxy-at-client architecture has been consideredby several other researchers.6,12-15

All three architectures are scalable in the sensethat more servers and proxies can be added to sup-port more concurrent video sessions. However,the proxy-at-server and independent proxy archi-tectures suffer from the problem that a proxy fail-ure will affect all connected clients. Conversely,systems based on the proxy-at-client architecturedo not have the proxy reliability problem; onlyback-end storage server failures need to be con-sidered.

Server striping policiesStriping is a general technique for distributing

data over multiple devices to improve capacity (orthroughput) and potentially reliability. Disk arrayand the Redundant Array of Inexpensive Disks(RAID)16 are among the most successful applica-tions. Other applications include network17 andtape striping.18 In a parallel video server, stripingvideo data over multiple servers increases the sys-tem’s capacity and potentially improves its relia-bility through data redundancy. This is calledserver striping. Striping a video stream across all NS

servers is commonly called wide striping. Striping

22

IEEE

Mul

tiM

edia

Net

wor

kin

terc

onne

ctio

ns

Back-endstorage servers

Front-end clientswith integrated proxy

Server S0

Server S1

Server S2

Server S3

Server SNS−1

P C P C

P C P C

P C P C

P C P C

P C P C

Figure 3. The proxy-at-

client architecture.

.

over a subset of the NS servers is called short strip-ing.8 Unless stated otherwise, wide striping is themethod referred to in the following sections.

Time stripingA video stream can be viewed as a series of

video frames. Striping a video stream in units offrames across multiple servers is called time strip-ing. Figure 4 depicts one example of how videounits are striped using time striping. Assume thata stripe unit contains L frames and the video playsat a constant frame rate of F frames per second. Ineach round of NSL/F seconds, L frames will beretrieved from each server and delivered to aclient. In general, the striping size L does not needto be an integer equal to or larger than one. Inparticular, if L < 1, then it is called subframe strip-ing,12 where L ≥ 1 is simply frame striping.

Studies by Biersack et al. considered time strip-ing by using a granularity of one frame and alsoone segment of a frame, or subframe striping.12,19

For subframe striping, they divided a frame into kequal-size units and distributed the units acrossthe servers in a round-robin fashion. They arguedthat subframe striping has perfect load balancingfor both constant bit-rate and variable bit-ratevideo streams, as each frame is striped equallyacross all servers. Conversely, a study byBuddhikot et al. used a stripe unit of k (k ≥ 1)frames.10 They suggested solving the load balanceproblem by grouping more frames into a stripeunit to obtain a more uniform stripe unit size.

Space stripingTime striping divides a video stream into fixed-

length (in time) stripe units. A second approachwould be to divide a video stream into fixed-size (inbytes) stripe units, called space striping. Space strip-ing simplifies storage and buffer management atthe servers because all stripe units are the same size.Moreover, the amount of data sent by each serverin a service round is also the same. A video streamcan be striped across the servers independent of theencoding formats and frame boundaries.

This space striping approach is employed bymost of the studies already mentioned.6-9,11,13-15

Depending on the system design, the stripe unitsize can range from tens of kilobytes to hundredsof kilobytes. In most of the studies, a stripe unit isassumed to play back in a constant time length.However, under modern video compression algo-rithms like MPEG, a fixed-size stripe unit will like-ly contain a variable number of frames and partialframes. Moreover, if the video is compressed using

constant-quality compression algorithms, thenthe video bit-rate will also vary. Consequently, thedecoding time for a stripe unit at the client willvary and may cause playback starvation. To solvethis problem, designers can incorporate thedecoding time variation into the model to derivethe client buffer required to compensate for thedecoding time variations.

Placement policiesIn the previous discussions, I have assumed a

round-robin placement of the stripe units acrossthe servers in the system. If the stripe units of avideo stream are denoted using v0, v1, …, and soon, then stripe unit vi will be stored in server (imod NS). However, a minor problem with this pol-icy is that server i will likely store more stripe unitsthan server j, for i < j. This happens because thevideo length is not always an integral multiple ofthe stripe size. Therefore, the last stripe will likelycontain less than NS stripe units filling from serv-er zero. To balance the storage, the round-robinpolicy can be modified to start striping a newvideo stream from different servers. Apart fromround-robin placement, Tewari et al. also consid-ered a random placement policy where the orderwithin a stripe is permuted pseudo-randomly.8

They suggested that the round-robin placementpolicy can introduce a convoy effect when oneserver becomes overloaded. That is, the overload-ing condition will shift from one server to thenext due to the round-robin placement. This con-voy effect can be avoided by permuting the orderof the stripe units in each stripe.

Issues in load balancingIn time striping, the frequency at which video

frames are retrieved is the same for all participat-ing servers. However, the size (in bytes) of stripe

23

Ap

ril–June 1998

Server

S0

v0

v5

v10

v15

v20

S1

v1

v6

v11

v16

v21

S2

v2

v7

v12

v17

v22

S3

v3

v8

v13

v18

v23

S4

v4

v9

v14

v19

v24

Stripe

Stripe unit

vi is stripe unit i, containing frames ki to k(i+1)−1

Figure 4. Striping a

video stream over five

servers using time

striping.

.

units may not be the same. This is especially sig-nificant in video streams compressed using inter-frame compression algorithms like MPEG-1 andMPEG-2. Consequently, the amount of video dataretrieved from each server in a round depends onthe type of frames stored. Take MPEG-1 as anexample. There are three frame types, namely I, P,and B, in order of decreasing average size. A serv-er storing an I frame will store and send muchmore data than a server storing a B frame in thesame round. Worse still, if the number of serversNS is a multiple of the MPEG group of pictures(GOP) size G, then the uneven load will be repeat-ed for all future service rounds. This could lead toload imbalance where some servers become over-loaded while others are underused.

For frame striping, this load-balancing problemcan be reduced by selecting L equal to integralmultiples of the MPEG GOP size G. This canreduce the size differences between the stripeunits. In practice, the size of each GOP differsslightly even in fixed-GOP MPEG encoding.Moreover, some encoders produce MPEG streamshaving variable GOP sizes to improve visual qual-ity, thereby defeating the discussed solution.

Conversely, Biersack et al. proposed subframestriping to achieve perfect load balancing.12,19

However, subframe striping suffers from the prob-lem that the processing complexity at the proxywill increase when more servers are added to thesystem. This is because the proxy needs to com-bine subframe data from all servers for each videoframe. On the other hand, space striping is bal-anced by definition. To cope with variable play-back duration for each stripe unit, additionalclient buffering can be used.

Another problem arises when a video stream isplayed at a different speed than normal playbackspeed, like fast forward and fast backward. Twoapproaches support fast forward: encode separatestreams for fast forward and fast backward pur-poses; and skip frames to achieve an apparentfaster playback rate. The first approach needs extrastorage space, but the system design and imple-mentation are fairly straightforward. For the sec-ond approach, the fast forward feature leads toload-balancing problems for parallel video servers.To see why, consider a system having four serversand using time striping of one frame per stripeunit. If double-speed fast forward is implemented

24

Parity unit

Parity calculationsS0

v0

v4

v8

v12

p4

S1

v1

v5

v9

p3

v16

S2

v2

v6

p2

v13

v17

S3

v3

p1

v10

v14

v18

S4

p0 p0 = v0 ⊕ v1 ⊕ v2 ⊕ v3

p1 = v4 ⊕ v5 ⊕ v6 ⊕ v7

p2 = v8 ⊕ v9 ⊕ v10 ⊕ v11

p3 = v12 ⊕ v13 ⊕ v14 ⊕ v15

p4 = v16 ⊕ v17 ⊕ v18 ⊕ v19

v7

v11

v15

v19

Stripe

Stripe unit

Figure 5. Adding

redundant data to

support server-level

fault tolerance.

Parity unit

Recovering lost unitsS0

v0

v4

v8

v12

p4

S1

v1

v5

v9

p3

v16

S2

v2

v6

p2

v13

v17

S3

v3

p1

v10

v14

v18

S4

p0 v2 = v0 ⊕ v1 ⊕ v2 ⊕ p0

v6 = v4 ⊕ v5 ⊕ p1 ⊕ v7

Not needed

v13 = v12 ⊕ p3 ⊕ v14 ⊕ v15

v17 = p4 ⊕ v16 ⊕ v18 ⊕ v19

v7

v11

v15

v19

Stripe

Stripe unit

Figure 6. Recovering

stripe units lost due to

failure of server 2.

.

simply by skipping every other frame in the videostream, then two of the four servers will handle alldata transmissions while the other two sit idle.This problem has been studied in detail by Wu etal and Buddhikot et al.9,10 They proposed algo-rithms for the data layout, scheduling, and play-out control to support fast forward and otherinteractive features.

Issues in redundancyAs discussed earlier, parallel video servers open

the way to achieving fault tolerance at the serverlevel. Ideally, the system should be able to main-tain continuous video playback for all active ses-sions when one or more of the servers becomeinoperable. As with the disk array and RAID archi-tectures, data redundancy can be added to supportfailure recovery in a parallel video server. The basicidea is to introduce one or more parity units intoeach stripe. As shown in Figure 5, the parity unitsare computed using the rest of the stripe units inthe same stripe. When a server fails, the lost stripeunit stored in the failed server can be recoveredfrom the parity unit together with the remainingstripe units (Figure 6).

For single-failure protection, simple paritycomputed from exclusive-or between the datastripe units can be used. A higher level of redun-dancy can be achieved by using more sophisticat-ed erasure-correction codes such as theReed-Solomon code. Note that to perform erasure-correction, stripe units within a stripe must be ofidentical size. This requirement argues againsttime-striping algorithms, which result in variablestripe unit sizes. Conversely, space striping, bydefinition, has fixed stripe size and can easilyextend to incorporate redundancy.

For parallel video servers, the fault toleranceissue has been studied by Wong et al. and Biersacket al.6,12 Biersack’s system employs subframe strip-ing, hence they can use error-concealment tech-niques to partially mask a server failure.Alternatively, they also suggested the possibilityof using forward error correction (FEC) to recoversubframes lost in a failed server. The study byWong et al. employs space striping algorithmssimilar to RAID to achieve server-level fault toler-ance.6 Their system can sustain nonstop videoplayback for all clients when a server fails.

In another study, Bolosky et al. proposed usingmirroring to achieve server fault tolerance.13 Inparticular, they used declustering to evenly dis-tribute the extra load caused by a server failure tothe remaining active servers. Unlike the study by

Wong et al., their system does not perform real-time recovery when a server fails; it cannot sustainnonstop video playback for existing users.

Parallel video delivery protocolsThe parallel video delivery requirement poses

challenges in designing the application protocol’sflow control, error control, and synchronization.The following section focuses on the client-pullversus the server-push service model, then dis-cusses synchronization and fault-tolerance issues.

Client-pull versus server-pushVoD systems generally have two ways to

request and deliver video data from a server to aclient. Most VoD systems let the video server senddata to the client at a controlled rate. The clientreceives and buffers the incoming video data forplayback through a video decoder. As shown inFigure 7a, once the video session starts, the videoserver continues the data transmissions until theclient specifically sends a request to stop it. Sincethe server pushes video data to the client at a con-trolled rate, this approach is called server-push.

In the traditional request-response model, thevideo client sends a request to the server for a par-ticular piece of video data. As shown in Figure 7b,upon receiving the request the server retrieves thedata from the disk and sends it back to the client.This approach is called client-pull for obvious rea-sons. The studies by Lee and Wong employ thisclient-pull service model.6,15

Interserver synchronizationMost studies on single-server VoD systems

employ the server-push delivery model. This

25

Ap

ril–June 1998

Server Client

Start new video

Video data

Video data

Video data

Video data

Video data

Video data

Video data

Server push

Server Client

Start new video

Request

Request

Video data

Video data

Video data

Video data

Client pull

(a) (b)

Figure 7. Service model

for VoD systems:

(a) server-push;

(b) client-pull.

.

model allows the system designer to devise peri-odic schedules at the server for reading data offthe disk and then transmitting it to the client.Extending the server-push model to a parallelvideo server causes a new problem due to the par-allel transmissions from multiple independentlyrunning servers.

For example, consider a system with NS serversusing fixed-size space striping. To start a newvideo session, a client sends a request to theproxy, which in turn sends requests to all NS

servers to start a new video session. Due to delayvariations in processing, networking, and sched-uling, the servers will start transmitting data atdifferent times. The first stripe unit might evenarrive at the proxy later than the subsequent stripeunits. Consequently, the proxy has to buffer thelater stripe units to wait for the first stripe unit toarrive for playback. This increases the client bufferrequirement and startup delay.

This synchronization problem has been studiedby Biersack et al.19 For scenarios where networkdelays between servers and a client is different,they propose adding different delays to the start-ing times of each server to compensate for delaydifferences. They also extended this model toinclude bounded network delay jitters. In anotherstudy by Buddhikot et al., they designed a closelycoupled system in which each storage node is con-nected by a custom high-speed interconnectionnetwork (APIC).10 The proximity of the storagenodes enables them to be accurately synchronizedthrough the common APIC. Lee et al. extended theclient-pull service model for use in a parallel videoserver (Figure 8).15 Since a client explicitly sends arequest to a particular server for a specific piece ofvideo data, the synchronization is implicit and theservers need not be separately synchronized.

Detecting and masking server failuresEarlier, I discussed how data redundancy can

be introduced among the servers to support serv-er-level fault tolerance. The redundant data allowsthe receiver to mask a server failure by computinglost stripe units stored in the failed server from theparity units together with the remaining stripeunits. In this section, I focus on ways to deliverredundant data to the receivers.

Forward error correction. Network communi-cations, generally offer two ways to recover pack-ets lost in transit. The first way, called forward errorcorrection (FEC), sends redundant data along withnormal data to the receiver at all times. In this way,the receiver can recover lost packets by using thereceived data together with the redundant data.This approach can extend to parallel video serversto recover lost stripe units due to server failures.6,12

FEC has the distinct advantage that the receiv-er does not need to detect a server failure. Becausethe receiver always receives redundant data, loststripe units can readily be recovered in case a serv-er fails. However, like the case in network commu-nications, FEC incurs constant transmissionoverhead even when no server fails. According tocoding theory, one redundant symbol is needed forevery lost symbol. Therefore, by using K to denotethe number of lost symbols we want to recover perparity group (or stripe), the transmission overheadwill be K/(NS − K). This overhead could become sig-nificant for systems having a small number ofservers or a high level of redundancies.

For a redundancy level of more than one (forexample, K > 1), Wong et al. proposed a progressiveredundancy transmission algorithm that transmitsless redundant symbols at startup.6 A server failureprompts a request for the servers to start transmit-ting one more redundant symbol per stripe. Forexample, let K = 3. Then the system can transmitonly one redundant symbol at startup. When aserver fails, the system will be able to mask the fail-ure immediately using the available redundantsymbol. At the same time, the receiver will requestthe servers to start transmitting one more redun-dant symbol per stripe, and so on. As servers sel-dom fail simultaneously, this algorithm can keepthe transmission overhead low while still allowingthe system to survive multiple server failures.

On-demand correction. A second way torecover lost packets in network communicationsis retransmission. Unlike FEC, retransmissionrequests extra transmission only when needed.

26

IEEE

Mul

tiM

edia

Server Client

Start new video

Request (0)

Request (1)

Video data

Video data

Video data

Video data

Client pull

Server 0

Server 1

Figure 8. Extended

client-pull service model

for use in a parallel

video server.

.

While retransmission cannot recover packets lostin failed servers, this on-demand principle can beextended for the delivery of redundant data. Thisapproach is known as on-demand correction(ODC). Specifically, the system does not sendredundant data until the system detects a serverfailure. This method completely avoids the trans-mission overhead in FEC and the system can stillrecover from server failures.

The challenge in ODC is to devise a way to de-tect server failures quickly and reliably. The detec-tion method must be quick enough to ensure thatvideo playback continuity can be sustained whilethe system requests redundant data for recovery.On the other hand, the detection method mustnot generate too many false alarms or risk causingthe system to send redundant data anyway.

Wong et al. designed a new video transfer pro-tocol together with a new network protocol todetect and mask server failure.6 They successfullyimplemented both FEC and ODC in a LAN envi-ronment where network delay is relatively shortand constant.

Future research directionsMany of the studies reviewed here have shown

that a scalable video server can be built from acluster of cheaper, less powerful servers. Table 1summarizes the design choices studied by variousresearchers. In addition, some of the studies haveexploited parallelism to support server-level fault

tolerance. The early results have demonstrated thefeasibility of maintaining nonstop video servicesdespite server failures.

Despite its brief history, parallel video serverresearch has obtained many encouraging results.As discussed in this article, many architectural anddesign alternatives with many combinationsremain unexplored. In the future, the followingissues will need study:

1. Server synchronization issues for loosely-cou-pled, push-based parallel video servers. Thesynchronization scheme must be efficient, yetaccurate enough to avoid server asynchrony.Furthermore, the scheme must be able to sur-vive server failures.

2. Push-based transmission scheduling for loose-ly-coupled parallel video servers. The schedul-ing policy must tolerate the clock jitterinherent among loosely coupled servers.Moreover, the scheduling policy must handlethe case when one or more server fails and beable to sustain nonstop video playback forexisting users.

3. Scheduling issues for delivering VBR videostreams in a parallel video server.

4. Extensions of the server striping principle toimplement parallel multimedia servers. MM

27

Ap

ril–June 1998

Table 1. Summary of design choices studied by various researchers.

Video Distribution Server Striping Video Delivery Server Fault Researchers Architecture Policy Protocol Tolerance

Biersack et al. Proxy-at-client Time Server path Striping w/parity; FEC

(Video server array)

Bolosky et al. Proxy-at-client Space Server path Mirroring with declustering

(Tiger video fileserver)

Buddihikot et al. Independent proxy Time Server path —

(MARS)

Freeman et al. Proxy-at-client Space — —

(SPIFFI)

Lee et al. Proxy-at-client Space Client pull Striping w/parity; FEC and ODC

(Server array & RAIS)

Lougher et al. Independent proxy Space — —

Reddy et al. Proxy-at-client, Space Server push —

Independent proxy

Tewari et al. Proxy-at-client, Space Server push —

(Clustered video server) Independent proxy

Wu and Shu Proxy-at-client, Space & Time Server push —

Independent proxy

.

AcknowledgmentsI thank the reviewers for their constructive com-

ments in improving this article to its final form.

References1. N. Venkatasubramanian and S. Ramanthan, “Load

Management in Distributed Video Servers,” Proc.

17th Int’l Conf. on Distributed Computing Systems,

IEEE Computer Society Press, Los Alamitos, Calif.,

1997, pp. 528-535.

2. C.C. Bisdikian and B.V. Patel, “Issues on Movie

Allocation in Distributed Video-on-Demand

Systems,” Proc. ICC95, IEEE Press, Piscataway, N.J.,

1995, pp. 250-255.

3. C. Griwodz, M. Bar, and L.C. Wolf, “Long-term

Movie Popularity Models in Video-on-Demand

Systems or, the Life of an On-Demand Movie,” Proc.

Multimedia 97, ACM Press, New York, 1997, pp.

349-357.

4. A. Dan, D. Sitaram, and P. Shahabuddin,

“Scheduling Policies for an On-Demand Video

Server with Batching,” Proc. 2nd ACM Multimedia

Conf., ACM Press, New York, 1994, pp. 15-24.

5. W. Liao and V.O.K. Li, “The Split and Merge

Protocol for Interactive Video-on-Demand,” IEEE

MultiMedia, Vol. 4, No. 4, Oct. 1997, pp. 51-62.

6. P.C. Wong and Y.B. Lee, “Redundant Array of

Inexpensive Servers (RAIS) for On-Demand

Multimedia Services,” Proc. ICC 97, IEEE Computer

Society Press, Los Alamitos, Calif., 1997, pp. 787-

792.

7. A. Reddy, “Scheduling and Data Distribution in a

Multiprocessor Video Server,” Proc. Second IEEE Int’l

Conf. on Multimedia Computing and Systems, IEEE

Computer Society Press, Los Alamitos, Calif., 1995,

pp. 256-263.

8. R. Tewari, R. Mukherjee, and D.M. Dias, “Real-Time

Issues for Clustered Multimedia Servers,” IBM

Research Report RC20020, June 1995.

9. M. Wu and W. Shu, “Scheduling for Large-Scale

Parallel Video Servers,” Proc. Sixth Symp. on the

Frontiers of Massively Parallel Computation, IEEE

Computer Society Press, Los Alamitos, Calif., 1996,

pp. 126-133.

10. M.M. Buddhikot and G.M. Parulkar, “Efficient Data

Layout, Scheduling and Playout Control in MARS,”

Proc. NOSSDAV 95, Springer-Verlag, Berlin, 1995,

pp.318-329.

11.P. Lougher, D. Pegler, and D. Shepherd, “Scalable

Storage Servers for Digital Audio and Video,” Proc.

IEE Int’l Conf. on Storage and Recording Systems 1994,

IEE Press, London 1994, pp. 140-3.

12.C. Bernhardt and E. Biersack, “The Server Array: A

Scalable Video Server Architecture,” High-Speed

Networks for Multimedia Applications, Kluwer Press,

Boston, 1996.

13. W.J. Bolosky et al., “The Tiger Video Fileserver,”

Proc. Sixth Int’l Workshop on Network and Operating

System Support for Digital Audio and Video, IEEE

Computer Society Press, Los Alamitos, Calif., 1996.

14.C.S. Freedman and D.J. DeWitt, “The SPIFFI Scalable

Video-on-Demand System,” Proc. ACM Sigmod 95,

ACM Press, New York, June 1995, pp. 352-363.

15.Y.B. Lee and P.C. Wong, “A Server Array Approach

for Video-on-Demand Service on Local Area

Networks,” IEEE Infocom 96, IEEE Computer Society

Press, Los Alamitos, Calif., 1996, pp. 27-34.

16.D.A. Patterson et al., “Introduction to Redundant

Array of Inexpensive Disks (RAID),” Compcon Spring

89, IEEE Computer Society Press, Los Alamitos, Calif.,

1989, pp. 112-17.

17.C. Brendan, S. Traw, and J.M. Smith, “Striping

Within the Network Subsystem,” IEEE Network, IEEE

Press, Piscataway, N.J., 1995, pp. 22-32.

18.A.L. Drapeau and R.H. Katz, “Striped Tape Arrays,”

Proc. 12th IEEE Symp. on Mass Storage Systems, IEEE

Press, Piscataway, N.J., 1993, pp. 257-65.

19.E. Biersack, W. Geyer, and C. Bernhardt, “Intra- and

Inter-Stream Synchronization for Stored Multimedia

Streams,” Proc. IEEE Int’l Conf. on Multimedia

Computing Systems, IEEE Computer Society Press,

Los Alamitos, Calif., 1996, pp. 372-381.

Jack Lee is a visiting assistant pro-

fessor in the Information

Engineering Department at the

Chinese University of Hong Kong.

He received his PhD and Beng

degrees from the same department

in 1997 and 1993. His research interests include distrib-

uted multimedia systems, fault-tolerant systems, and

Internet computing.

Readers may contact Lee at the Department of

Information Engineering, The Chinese University of

Hong Kong, Shatin, N.T., Hong Kong, email

yblee@ie.cuhk.edu.hk.

28

IEEE

Mul

tiM

edia

.