Video on Demand Distribution Over ATM. Virtual Private Networks 1. Jose A. S. Monteiro y Luigi Fratta z. 405 Hilgard Ave., Los Angeles, CA 90024

Transcription

1 Video on Demand Distribution Over ATM Virtual Private Networks 1 Carlos M. D. Pazos? 2 Edilayne M Silva y Mario Gerla? Jose A. S. Monteiro y Luigi Fratta z? University of California, Los Angeles Computer Science Department 405 Hilgard Ave., Los Angeles, CA fpazos,gerlag@cs.ucla.edu y Universidade Federal de Pernambuco Departamento de Informatica Caixa Postal 7851, Recife PE , Brasil fems,suruagyg@di.ufpe.br z Politecnico de Milano Dipartimento di Eletronica e Informazione Milano, Italia fratta@elet.polimi.it Abstract. The Video on Demand service is expected to become one of the most popular oerings with the introduction of multimedia ATM networks. Several options are available for the support of such service. In this paper we investigate an approach which exploits ATM Virtual Private Networks. We use a Token Protocol and Fast Resource Reservations to achieve good utilization of network and video server resources and to allow for dynamic load balancing among multiple Information Warehouses. We also investigate the use of \caches" in Central Oces to further improve bandwidth eciency. Simulation results shows that this approach is feasible and eective. 1. Introduction With the advances in ber optics transmission systems, video compression techniques and networking technology, multimedia communications services are becoming the common platform for next generation, multi-purpose information systems. One such service is Video on Demand (VoD), a service similar to Pay Per View, but in which viewers have more interactive control over the video programs. For example, VoD includes real-time interactive features such as stop, fast-forward, rewind, pause, fast-forward-play, and fast-rewind-play. VoD systems design is an active area of research since this application is expected to contribute a signicant fraction of the multimedia trac in future metropolitan and wide area ATM networks. There are a number of ways to provide the VoD service over ATM networks. 1 This research was supported by NSF, SUN-MICRO and Italtel grants. 2 Bolsista do CNPq { Braslia/Brasil

2 The approach we consider in this paper makes use of the ATM Virtual Private Networks concept. In this approach, the local access loop is decoupled from the broadband network which interconnects VoD servers, henceforth called Information WareHouses (IWHs). The IWHs are interconnected through the ATM network to Central Oces (COs) where the residential local loops terminate, see Figure 1. In the CO, a dedicated network device called the Intelligent Access Peripheral (IAP), terminates the ATM protocols, buers video for each customer and transmits, at a constant rate, the video to the customer set top unit (STU). 2 3 Local Loop ATM VPs ATM Switch IWH CO STU Fig. 1. The VoD AVPN. Hence, the only trac which uses the ATM bandwidth is the video trac between IWHs and COs. Since the IWHs and the COs are typically owned by the same VoD service provider, we use an ATM Virtual Private Network (AVPN) to interconnect them. The key advantage of the AVPN approach is that the ATM customer (in our case the VoD service provider) acquires and manages the VP bandwidth in a way that best suits the customer's own application needs. The ATM network provider only enforces the peak policing on the AVPN VPs. For topology design and congestion control in AVPNs see [GF95]. A scheme for the management of the AVPN using a token passing protocol and fast reservations was proposed in [C + 96]. In this paper, we improve upon

3 that scheme by exploiting the fact that some movies are more popular than others (e.g., new releases). Hence, it makes sense to have copies of these most popular movies close to the users, namely in the COs. More precisely, in this paper we augment the CO functionality to include cache disks for storing frequently requested movies, as originally proposed in [DDM + 95, NPSS95, BA96]. In the balance of the paper, we present in section 2. the system architecture in more detail. Namely, we review the token protocol and the use of ATM Fast Resource Reservations, and we introduce the concept of video caching at the COs. In section 3. we compare qualitatively our scheme to another VoD support alternative. In section 4., we describe the simulation model used in our study, and in section 5. we present the simulation results. Section 6. concludes the paper. 2. The VoD System Architecture The architecture for the VoD service using AVPNs is presented in Figure 1. This system comprises three main network elements: the Information WareHouse (IWH), the Central Oce (CO), and the Set Top Unit (STU). Within the AVPN, a set of VPs are congured, connecting IWHs and COs to ATM switches, as well as connecting pairs of switches. Using the mesh of VPs, VCs are then set up connecting each CO to a set of IWHs that will be used as possible providers of video data to the CO. For instance, in Figure 1, CO 3 is congured to receive video only from IWHs 1, 2 and 4, since VCs are established only to these IWHs. These VCs are set up at system initialization and no bandwidth is assigned to them. They are \thin" VCs which basically predene routes for the video data transported from IHWs to COs. In addition to these data VCs, low bandwidth control VCs (possibly point-to-multipoint VCs) are also set up to connect each CO to the subset of IWHs serving it. These control VCs are used for the token protocol governing the transfer of video data. In this architecture, the VPs in the AVPN are Constant Bit Rate (CBR) VPs, over which the ATM network applies peak rate policing. This is the service class contracted from the network. The thin VCs are managed by an AVPN manager and we assume that the ATM network provides signaling for setting them up, but no ow control is applied to them. Since these VCs are assigned no bandwidth, the Fast Resource Management protocol [BRM92, ITU96] is used to allocate bandwidth to them before trac can be sent over them. The control VCs are low speed CBR VCs. The IWHs store copies of all the movies that are oered by the VoD service. The storage medium is a Redundant Array of Independent Disks (RAIDs). The IWHs are also responsible for managing one end of the token protocol and for managing ATM Fast Reservations. The CO houses Intelligent Access Peripherals (IAPs) and disks used as caches. The IAPs terminate the VPs and VCs reaching

4 the CO, manage the other end of the token protocol and supervise the transfer of video data to the users' STUs. The connection of the STU to the IAP is made through a Local Card (LC) on the IAP, hence the number of users (STUs) an IAP can support is determined by the number of LCs it carries. These LCs contain a pair of buers each capable to store 20 seconds worth of video data, or 30Mbit. In steady state, one of the buers sends the video data to the STU, while the other holds the next 20 sec-block of video or it is in the process of getting that block from an IWH. The 30Mbit bursts are considered real time trac transported over ATM using AAL1. The STU decodes the MPEG video and audio signals and feeds them to the user's TV set. When the STU is nished playing one of the IAP's buer, it requests the next block. The IAP switches to the other block and initiates the token protocol to request the following block from the IWH. For further information on IWHs, IAPs and STU, see [C + 96]. 2.1 The Multi Token Protocol and Fast Reservations The Multi Token Exchange (MTEX) protocol was designed to support the distribution of time sensitive data in a bursty environment. It is particularly suited for our system since disk accesses in the IHWs must be scheduled under strict real time constraints. The MTEX protocol denes a set of control messages (Request, Token, Accept, Reject, Go) that are exchanged between an IAP and the IWHs supplying the video data. These messages are used to synchronize the actual video transfers from IWHs to IAPs. The MTEX protocol is illustrated in Figure 2 and extensively described in [C + 96]. Once the synchronization is nished, the transfer of video data can take place. However, the IHW is only connected to the IAP through a thin VC, as described above. Hence, before data can actually be transferred, a temporary allocation of bandwidth to the thin VC must be made, which is accomplished by using the Fast Resource Management (FRM) strategy initially proposed in [BRM92] and standardized by ITU-T in [ITU96]. In our model, the FRM mechanism implemented is the ATM Block Transfers with Delayed Transmission (ABT/DT) described in [ITU96]. Through this FRM mechanism, the IWH requests that the peak bandwidth allocated to all VPs traversed by the VC connecting the IWH and the IAP be reserved to this VC. Once again, the reader is referred to [C + 96] for a full description of the steps needed to carry out the booking of bandwidth for the thin VCs. In the particular scenario considered in this paper, the VPs in the AVPN are assigned 150Mbps and the buers in the LCs store 30Mbit worth of video data for 20sec of movie play-back, transferred at 1.5Mbps to the STU. Hence, the MTEX and FRM phases are initiated once every 20sec by each of the active LCs and, if the FRM is successful, 150Mbps are assigned to the thin VC connecting IWH and IAP. Note that no intermediate storage of the full block is required

5 IWH ATM Nodes IAP LC STU Request Request Request Token Accept/Reject RM_Req Go RM_Ack RM_Start (Abort) RM_End Data Data Data Data Ack. Fig. 2. The MTEX and FRM Protocols. at the IWH, since the transfer from RAID storage to LC buer is carried out basically on the y. This is made possible by the fact that both RAID channel and network bandwidth are acquired before the transfer occurs. Only a small amount of transit buering is required at the IWH, in part to handle the possible mismatch between disk I/O channel rate and VP rate. If the bandwidth reservation to the VC is not successful, an FRM release cell is sent back to the IWH to signal a blocking on the requested assignment. The IWH can then take several possible actions as described in [C + 96]. In the one considered in our study, the IWH uses the MTEX protocol to send an Abort message back to the requesting IAP, Figure 2. Since an IAP always sends requests to all IWHs which it is connected to, if one of them cannot reserve bandwidth along the appropriate VC, some other IWH might have a better chance. Hence, in our implementation, the IAP keeps track of all IWHs that can still provide it with the requested data. Only if the last IWH in this list also fails to make the reservation, does the IAP resends the reservation message to all IWHs which it is connected to. As a consequence, a new FRM reservation request for bandwidth to a VC for which a reservation attempt has just been blocked, will only be repeated if needed, and most likely after some signicant amount of time. In this approach, we prevent the generation of continuous FRM requests over the same VP, that

6 would possibly nd the blocking VP still busy. In addition, by sending the Abort message, the IWH is released from the commitment to serve that IAP and can move on to service other pending requests, possibly over other paths. At last, notice that by allowing the IAP to submit its request to dierent IWHs at the same time, we allow for dynamic load balancing. Namely, if some areas of the network or some IWHs are overloaded, the requests through overloaded areas and to overloaded IWHs are more likely to be aborted. Thus, the load will tend to shift to less congested areas. 2.2 Caching One way to reduce network blocking is through the use of caches in the COs. In this approach, the IWH servers store all titles on a permanent basis while CO caches store a limited amount of titles based on real or anticipated user demand. Server location and data distribution were studied in [SB96, BA96], while [DDM + 95, NPSS95, BA96] studied caching in order to improve large scale VoD systems performance. With this technique, caches are distributed over the network and store only a subset of video titles. Copy distribution to local caches depends on local user preferences. A copy may be removed after a given time interval due to request rate variations [LV95]. Video request rate varies for dierent titles (e.g., some titles are more popular than others, and new releases are more likely to be requested than \older" ones). For each new release, copies can be distributed during o-peak hours, anticipating a heavy user demand. The caches are also implemented using RAIDs, in order to keep storage costs low. Caches behave as local servers but with a much more limited number of video titles. The proposed architecture thus implements a two-level storage hierarchy, consisting of the caches present at COs and of the main storage at the IWHs. When a user requests a movie, the IAP rst checks whether a copy of the desired movie is available on the cache, before sending a request to the IWHs. If the desired movie is available locally, the video data can be retrieved directly from local disks, eliminating the need to allocate bandwidth for video data transmission from remote servers. Hence, if the movie is available locally, the request for individual blocks are sent to the cache as well as to the IWHs. With the use of caching, the number of users serviced by a CO can signicantly increase, at a much lower cost than replicating the IWH servers [SN95]. The actual number of user connections is limited by the available bandwidth and by the number of simultaneous users which can be served by the caches. Since latency times for the caches are shorter because of their proximity to the users, the system can service a higher number of users whenever the movies they request are available on the caches. Caching at the CO oers the additional advantage of more exible sharing

7 of movies by the users [NPSS95]. The same copy can be viewed by two or more users without the additional cost of remote access. Another advantage is better interactive control of the video stream by the user. The low latency allows the use of VCR controls without increasing network load. 3. VoD Design Alternatives In the previous sections we have reviewed a VoD scheme based on burst transmissions, AVPN support and local caching. In this section, we review another VoD alternative and compare it (qualitatively) to the approach we consider. An obvious alternative (and, probably, the most common) is the CBR (Constant Bit Rate) solution. A VC is set up for each video session. Peak bandwidth (1.5Mbps) is allocated to the VC for the entire duration of the session. A single buer (per active user) is allocated at the IHW to handle the mismatch between RAID I/O channel and VC bandwidth, and to multiplex several users. Each IWH can simultaneously feed up to 90 user buers, periodically replenishing them from the RAID. The required buer size per user (assuming disk latency = 30ms) is about 30 sec play time at 1.5Mbps. Furthermore, some minimal buering is required also in the CO local cards. Thus, buer cost and complexity is approximately the same as for the proposed bursty scheme. Bandwidth management is easier (no fast reservations). Service quality is superior (no missed deadlines because of unavailable bandwidth). On the negative side, the CBR scheme establishes a static binding between user, IWH, network path and network bandwidth. This implies that there is no dynamic load balancing, nor automatic recovery from IWH and path failures. Consider a VoD in which multiple copies of the same movie are replicated at a few sites (for redundancy). Assume that the less popular movies are replicated only at two IWHs. A viewer is blocked if he nds the two sites already full (i.e., 90 sessions each). Yet, blocking would be avoided if some of the current sessions could be reassigned to other IWHs. Clearly, in the CBR scheme dynamic reassignment without user stream interruption is not possible, unless large buers are assigned to the LCs. In the proposed scheme, dynamic reassignment is the norm, since the IWH-path-user binding is determined on a burst by burst basis. Similar considerations apply to the dynamic sharing of network bandwidth. The proposed scheme can o load busy paths by rerouting the block transfers on less congested areas in the network. Likewise, recovery from IWH or path failure is automatic, and it is transparent to users. The AVPN may be viewed as an additional cost in the proposed scheme vis a vis the simplicity of the CBR service. However, the use of the AVPN for burst transmissions is not a strict requirement, especially if the public ATM networks support FRM. Furthermore, AVPN provides service benets [CFF + 95]. To start, the VoD provider can \depend" on the bandwidth provisioned in the AVPN,

8 regardless of public network congestion. Billing is much more straightforward since the charge is based on VP peak bandwidth rather than on burst-by-burst transmissions (if the service is provided directly by the public ATM network). The VoD provider decides on call acceptance based, in part, on AVPN bandwidth availability. Thus, there is more direct control of QoS from the customer part. In addition, AVPN bandwidth is dynamically acquired and released based on measured/predicted user trac patterns. Lastly, the AVPN customer manager can \emulate" fast reservations even if the network switches do not support FRM. This can be done in various ways. The simplest approach consists of having the central AVPN network manager act as burst scheduler. The AVPN manager knows the AVPN topology and keeps track of ongoing burst transmissions. The IWHs submit burst reservations to the manager, which either accepts, queues or rejects a reservation based on current path availability. A decentralized reservation scheme is also possible, where each IWH monitors the current burst transmissions in the network and determines whether to transmit or abort based on bandwidth availability. Prior to transmit, the IWH informs all the other IWHs of its intention, using a multicast VC control (as supported, for example, by the OPENET, open ATM network management platform [CHK + 95]). The burst transmission is promptly aborted if a path/bandwidth conict is detected during the \sensing" interval. 4. The Simulation Model In this section we describe the simulation model used to study the performance of the architecture reviewed in section 2.. In our studies, we considered the Virtual Private Network topology of Figure 1 and we assumed it to cover a metropolitan area. The length of each ATM link between ATM switches is 20Km, while the IWHs and the COs connect to switches via 10Km links. All VPs in Figure 1 are CBR VPs with a peak rate of 150Mbps. During the bandwidth reservation phase the FRM reservation message requests the 150Mbps on all the VPs along the appropriate VC path. This allows for a simple FRM unit (FRMU), the entity in charge of the FRM protocol which we assume to be implemented on all ATM switches. The FRMU needs only keep a binary busy/idle ag for each VP it manages. We assume that the binary test and the associated bandwidth booking can be done in negligible time. Thus, the latency involved in the reservation phase is limited to the round trip propagation delays. We further assume that the RAID I/O channel rate is greater than or equal to 150Mbps. This model places a limit on the number of simultaneous users that can be active and connected to the same IAP as well as on the number of requests any IWH can satisfy. The buers in the LCs store 20sec worth of video that is sent to the STU at 1.5Mbps. The buer size, and thus the burst length,

9 is 30Mbit, requiring 221ms for transmission at 150Mbps on the AVPN. Since each LC requests a burst only once every 20sec, and the IWHs and COs are connected to the ATM network by 150Mbps lines, they can support up to 90 active customers each. The caches provide video data locally to the buers in the LCs, not using the ATM network. Since we do not have the cell header overhead, the transfer of a block from the cache to a LC takes 200ms and 100 simultaneously active users can be served from the cache. Notice that we are considering the currently available 150Mbps link speeds which is also the rate supported by the RAIDs. Hence, it is ultimately the trunk speed that limits the maximum number of simultaneous active users that can be supported at any one time. Since in our model of Figure 1, we only have 5 IWHs connected to the AVPN by 150Mbps VPs, the maximum number of simultaneously active users is 450. In order to support more VoD users, we would need to install more IWHs or use faster RAIDs with multiple VP connections to the AVPN, and possibly parallel VPs in the AVPN backbone. Hence, to support more than 450 users, we would have parallel VoD AVPNs with the same behavior studied here. In our experiments, we assume that the IAP in each of the COs is connected through a thin VC to each of the ve IWHs in Figure 1. Hence, in this environment an IWH or an IAP can only be engaged in the transfer of data or in the MTEX/FRM protocols at any one time. When an IAP receives a token it immediately replies with either a Reject message or an Accept message followed by a Go message. When the data transfer is completed, the IAP selects the next most urgent request from its request queue and sends it to the ve IWHs. We further assume that all 20sec of video data are worth delivering no matter how late they arrive. Basically, it is better to freeze the image while the next block is being transferred, than simply skipping to the following block. Hence, two performance parameters in this environment are the number of missed deadlines and the maximum freeze time, i.e., the time by which the deadline was missed. In the experiments, the simulated time was 15 minutes, which amounts to the transfer of 45 video blocks for each user. Besides the number of missed deadlines and the maximum freeze time, we are also interested in the FRM trac which corresponds to the trac of control overhead transported over the AVPN. In the next section, we present simulation results for these performance parameters accumulated in a period of 15 minutes as a function of the number of active VoD users, each watching a particular movies. It is not part of the scope of this paper to study the behavior of these performance metrics under dynamic variations on the number of active VoD users. This study is left for future research. In the experiments using cache, we assume that the COs are equipped with RAIDs similar to the ones used in the IWHs. These RAIDs at the COs are used as caches and they store only 30 lm titles. These are the most popular titles

10 and are periodically updated. In our experiments, however, in order to obtain the performance metrics we are interested over the 15 minutes of simulated time, we consider that the movies in the cache are the same during these 15 minutes. We do actually assume dynamic changes on the movies stored on the cache, as described in section 2.2, but for simplicity we assume that these changes do not occur during the simulated time. The study of such dynamic variations is also left for future research. Furthermore, whenever a user requests a movie, a determination is made as to whether it is a popular one, and hence whether it is stored in the cache. In [Tan96] it was shown that the probability that a movie i, out of a population of N movies ranked by decreasing popularity, is selected following the Zipf distribution: P Zipf (i) = N In our experiments we considered dierent cache sizes: out of a population of N = 100 titles, the 5, 10 and 30 most popular titles (the ones with the largest probability P Zipf according to the Zipf distribution) were stored in the cache. So, once it is determined that the newly selected movie is a popular one, the CO will obtain the video data from the local cache. Otherwise, the request must be routed to the IWHs. However, since the capacity of the cache RAID I/O channel is nite, the cache can only support a limited number of viewers (specically, 100 viewers under our assumptions). Thus, if the number of viewers watching popular movies in a CO exceeds that limit, the excess requests must be serviced by the IWHs. Hence, in our simulation the caches are modeled as local IWHs. In particular, they also implement the MTEX protocol. Each IAP sends requests for blocks of popular movies to both the cache and the IWHs. 5. Simulation Results Using the simulation model described in the previous section we have carried out several experiments. The AVPN topology of Figure 1 has ve IWHs, each of which can support at most 90 simultaneous users because of VP bandwidth limitations as discussed in section 4.. Hence, this infrastructure can support at most 450 users assuming perfect load balancing among IWHs. Since there are eight COs, each CO can support at most 55 simultaneous users, assuming uniform distribution of users among COs. Naturally, the use of caches improves on this limitation since the caches are local to the COs and do not use AVPN bandwidth. In Figures 3 and 4 we plot the number of missed deadlines and the maximum freeze time observed during the 15 minutes of simulated time, as a function of the number of active VoD users. Furthermore, in these gures we plot the results for the system without cache and the system in which the COs are each equipped i

11 with caches capable of storing 5, 10 and 30 movies, respectively Number of Missed Deadlines no cache cache = 5 cache = 10 cache = Number of Local Cards per IAP Fig. 3. Total number of missed deadlines with and without caches. Studying the results for the system without caches, we can rst study the usefulness and eectiveness of the combined MTEX and FRM approach. From Figure 3 we observe that as the number of users exceeds 55, the system is not capable of meeting the VoD users' deadlines. In addition, from Figure 4 we observe that for this same condition, the maximum time a scene is frozen on the TV screen begins to be noticeable. In fact, for only 60 active users, the maximum freeze time is already intolerable, close to 5 seconds. Since this service degradation is only observed when the installed system capacity is exceeded, this result indicates that the IWHs and the VPs connecting them to the AVPN are used at 100%. This is a consequence of the well known fact that systems operating at this level of utilization are bound to experience long delays and losses. On the other hand, for fewer than 55 users per CO, there are no missed deadlines and no user experiences a frozen image. Hence, by using the MTEX protocol to schedule block delivery and by using the FRM protocol to reserve bandwidth on the thin VCs connecting IWHs and COs, we actually provide an eective infrastructure for the distribution of VoD data with all the advantages discussed in section 3.. Another relevant performance aspect is the dynamic contention for the AVPN bandwidth. This contention is reected in the number of FRM request and reject

12 Maximum Freeze Time (Second) no cache cache = 5 cache = 10 cache = Number of Local Cards per IAP Fig. 4. The maximum freeze time with and without caches. messages that are generated. In Figure 5, we show the trac of FRM requests injected into the network and in Figure 6 we plot the fraction of the FRM requests that are actually rejected. This trac represents the overhead incurred in the use of Fast Resource Reservations. Again, considering rst the results for the system without caches, we observe that the number of FRM request messages increases with the number of active users (Figure 5). The fraction of requests that are rejected is high even when the oered load is below the maximum capacity. This is to be expected since the probability of FRM blocking increases with trunk utilization. It is surprising, however, to observe that the fraction of FRM rejections stabilizes (in fact, even decreases), as seen in Figure 6. This unexpected behavior is due to the self regulating nature of the system. Since the bottleneck in our system is the IWH channel, fewer and less frequent tokens are returned (per user) by the MTEX protocol as the I/O channel queue increases due to increased load. Thus, fewer FRM reservations (per user request) are attempted. Furthermore, user block request rate also decreases since the block play time is articially stretched by the frozen frame. For 80 active users and no cache, block play time is up to 40 sec, twice the nominal value (see Figure 6). Thus, new block request is reduced to one half! Note that if the AVPN backbone bandwidth, instead of the IWH I/O channel capacity, was the bottleneck, the FRM rejection rate would be much higher. However, even in that case the self regulating eect of

13 Number of FRM Request Messages no cache cache = 5 cache = 10 cache = Number of Local Cards per IAP Fig. 5. Number of FRM request messages with and without caches. the \structured" blocks would be felt. We can now consider the eect of adding caches to the COs to store a number of most popular movies. We consider three cache sizes and we plot the appropriate performance metrics for each cache size in Figures 3 through 6. Since the caches in the COs are actually RAID disks which, except for the storage capacity, are just identical to the ones in the IHWs, we would expect at least a two fold improvement in the system performance. By comparing the results in Figure 3 for the case of a 30-movie cache to the results for the system without cache, this is exactly what we observe. For a cache of that size, Figure 3 shows that we can service 150 customers. There is not a single missed deadline, and the cache captures most of the requests. For more than 160 active users we observe that deadlines are missed and the maximum freeze time in Figure 4 is already intolerable. This is the same behavior observed for the system without cache when the installed capacity is exceeded. The results for smaller cache sizes in Figures 3 and 4 demonstrate that the saturation point for which the number of active users needed to degrade system performance is somewhere between the number needed for a system without cache and the number needed for a system with a cache for 30 movies. This simply indicates that even though the cache throughput is identical to the IWH throughput, the cache sizes for 5 and 10 movies cannot capture most of the requests. Hence, the caches are actually left idle for some time even when there

14 FRM Reject / FRM Request Messages no cache cache=5 cache=10 cache= Number of Local Cards per IAP Fig. 6. The fraction of FRM requests that gets rejected. are far too many active users. Furthermore, we observe that it is not very cost eective to increase the cache size beyond 30 movies for the movie population size considered. The use of caches further reduces the amount of FRM cells in circulation in the network as it can be observed in Figures 5 and 6. In this case, under light load conditions, the majority of the request are serviced by the cache directly. The measured FRM trac is a result of viewers watching less popular movies, which are stored on the IWHs only. The AVPN is then almost entirely dedicated to less popular movies and the fraction of rejected reservations is smaller. On the other hand, as the oered trac increases, more viewers select non-popular movies and, for some oered loads, the cache capacity is saturated. Hence, more video blocks are retrieved from the IWHs, causing an FRM trac increase. Again, the fraction of rejected requests uctuates around 80% because of system self regulation. 6. Conclusions In this paper we have studied the application of ATM Virtual Private Networks to the provisioning of a Video on Demand service. The main innovation of the proposed system is the transmission of bursts on an AVPN which supports or \emulates" FRM. This is in contrast with more traditional systems based on

15 CBR service. Two options have been implemented. In one, the video data is stored in Information Warehouses and is transmitted to Central Oces through the VoD AVPN for subsequent delivery to the viewer. In the second option, the system provides extra storage (caches) in the COs. Simulation results show that the implementation without caches is capable of delivering the VoD service with acceptable QoS up to the network capacity. The cache solution improves on this result by doubling the number of supported viewers, yet retaining a good quality VoD service. Work is in progress in several directions. First, the support of Fast Forward and Fast Reverse viewing is under evaluation. Secondly, an eective VoD system places critical demands on system resources such as RAID capacity, disk I/O channel rates, cache memory and AVPN bandwidth. We plan to investigate such trade os. We also plan to evaluate centralized and decentralized options for fast burst reservation within AVPN. Finally, we are exploring the eectiveness of the IWH-ANPN-cache strategy with burst reservations for the support of more general video based services (e.g., network news clips, WWW video clips, multimedia documents etc). References [BA96] [BRM92] S. A. Barnett and G. J. Anido. A cost comparisom of distributed and centralized approaches to video-on-demand. IEEE Journal on Selected Areas in Communications, 14(6):1173{1183, August D. P. Tranchier P. E. Boyer, Y. M. Rouaud, and J. Y. Mazeas. Fast bandwidth allocation in ATM networks. In XIV ISS, October [C + 96] P. Crocetti et al. Video on demand service based on ATM virtual private networks. In ECMAST '96, May [CFF + 95] P. Crocetti, S. Fotedar, L. Fratta, G. Gallassi, and M. Gerla. ATM virtual private networks design alternatives. Computer Communications, 18(1):24{31, January [CHK + 95] I. Cidon, T. Hsiao, A. Khamisy, A. Parekh, R. Rom, and M. Sidi. The OPENET architecture. Technical report, Sun Microsystems Laboratories, December [DDM + 95] A. Dan, D. M. Dias, R. Mukhrjee, D. Sitaram, and R. Tewari. Buering and caching in large-scale video servers. In COMPCOM - Technologies for the Information Highway, pages 217{224, Los Alamitos, CA, January [GF95] M. Gerla and S. Fotedar. ATM trac and bandwidth management using virtual private networks. In Third International Conference on Telecommunication Systems, March 95.

16 [ITU96] Study Group 13 ITU. ITU-T Recommendation I.371: Trac Control and Congestion in B-ISDN. Technical Report 35-E (PLEN), ITU { Telecommunication Standardization Sector, Geneva, May [LV95] T. D. C. Little and D. Venkatesh. Popularity-based assignment of movies to storage devices in a video on demand systems. ACM/Springer Multimedia Systems, 2(6):280{287, January [NPSS95] J.-P. Nussbaumer, B. V. Patel, F. Schaa, and J. P. G. Sterbenz. Network requirements for interactive video on demand. IEEE Journal on Selected Areas in Communications, 13(5):779{787, June [SB96] D. N. Serpanos and T. Bouloutas. Centralizeded vs. Distributed Multimedia Servers. Technical Report RC 20411, IBM Research Division, T. J. Watson Research Center, Yorktown Heights, New York, [SN95] F. Schaa and J.-P. Nussbaumer. On bandwidth and storage tradeofs in multimedia distribution networks. In Proc. INFOCOM '95, volume 1, pages 1020{1026, April [Tan96] A. Tanenbaum. Computer Networks. Prentice Hall, 3rd edition, 1996.