Congestion Control for Interactive Video-on-Demand over ATM

Real-Time Imaging 5, 315±328 (1999)Article No. rtim.1998.0163, available online at http://www.idealibrary.com on

Congestion Control for InteractiveVideo-on-Demand over ATM

An interactive video-on-demand (IVoD) system consists of a video server and a clientconnected together through a high speed network. Use of interactive video-on-demand inan educational environment is very interactive because students frequently pause, fast-

forward, skip and view frame-by-frame. Designing a network able to support interactivity andmake e�cient use of bandwidth is challenging. In this paper we evaluate the suitability of anumber of congestion control schemes (based on the service categories of ATM) for carryinginteractive video on demand. We have developed analytical models to evaluate and compare thevarious schemes. Data on interactive behaviour of students obtained from IVoD trails carried outin our laboratory have been used in the models. We show that the renegotiated constant bit rateservice category has considerable potential for carrying IVoD over a high speed network, such asthe asynchronous transfer mode (ATM). We also show the use of an application layer, (such asWinsock 2), by the server to limit congestion within the network.

# 1999 Academic Press

Philip Branch1, Mohammed Atiquzzaman2

1Network Systems Performance and Applications Group, Department of E&CS Engineering,Monash University, Clayton, Melbourne, Victoria 3168, Australia.

E-mail: [email protected] of Electrical and Computer Engineering, University of Dayton, Dayton, Ohio 45469-0226, USA.

E-mail: [email protected]

Introduction

Interactive video-on-demand is a useful technology ineducation. With video-on-demand students can reviewlectures, watch a documentary or examine ®lms, plays ortelevision. However, usage is very interactive in such anenvironment. Students will often skip to the point ofinterest, review it a number of times and then exit. It isunusual for a video sequence to be viewed frombeginning to end without some interaction. Interactivityin entertainment where the video is usually viewed frombeginning to end without interruption, is small. Inter-

1077-2014/99/100315+14 $30.00/0

active functions are however, heavily used in educationand research [1,2].

Designing interactive video on demand systemspresent many challenging research issues, such asnetworking requirements, congestion control schemes,client bu�ering requirements etc. Interactive behavior ininteractive-video-on-demand systems is thus an impor-tant are networking application research. Ledistchkeand Johnson [3] carried out a review of techniques forentertainment systems. Li et al. [4] investigated theperformance of large scale interactive video-on-demand

# 1999 Academic Press

316 P. BRANCHANDM. ATIQUZZAMAN

servers. Dey-Sircar et al. [5] suggest queuing ofbandwidth requests within the server. Andersen [6]described producing subsidiary encodings for fast-forward and fast-rewind.

Unless the network is able to support di�erentbandwidths for di�erent interactive functions, somefunctions, such as fast-forward and fast rewind are verydi�cult to provide. Di�culties are caused by the natureof MPEG encoding. With MPEG encoding, an increasein fast-forward rate of n cannot be achieved by simplysending every nth frame. MPEG gains much of itscompressions through temporal encoding which createsdependencies between frames. In addition, MPEGpictures are encoded in di�erent modes. A group ofpictures (GOP) in MPEG consists of one I framefollowed by a number of B and P frames. An I frame,with no temporal dependencies, contains more data thanB or P frames. So sending only I frames withoutincreasing the bandwidth will result in only a smallspeedup. It is possible to construct fast-forward bysimply sending I frames but to be e�ective, this requiresseveral times the bandwidth than for the play mode.

In simple low cost systems fast-forward or fast-rewindare not provided, rather a slider bar to provide randomaccess to the scene of interest is used. Unfortunately,fast-forward and fast-rewind are useful in identifyingwhere scenes of interest start and are essential foreducation use [1].

The solution adopted in many high end systems is toproduce a separate encoded stream for fast-forward at asimilar bit rate to that of normal play [6]. Unfortunately,this scheme requires around 20% additional serverstorage space. However, in educational environmentsstorage is a scarcer resource than bandwidth, therefore,scheme is unsatisfactory. Furthermore, it does not lenditself to new modes of viewing such as high resolutionzoom. Storing a separate encoding for every viewingmode, and possibly every variation of every mode isunacceptable.

Another scheme which does not require additionalstorage is to allocate a virtual circuit at n times theordinary rate and allow the client to selectively displayevery nth picture. This is wasteful of bandwidth. It hasthe advantage of being simple to implement, and is areasonable solution in networks with an abundance ofbandwidth [3]. Unfortunately, it is not scalable to widearea networks where bandwidth is scarce and expensive.

To design a system that minimizes bandwidth andserver space, both the network and server must beconsidered. Modern networks such as ATM o�erconsiderable ¯exibility in delivery of video on demand[7±10]. We can take advantage of ¯exibility in both theserver and the network to support more clients than wecould otherwise. However, to do this, it is necessary forthe application to communicate quality of serviceinformation to the network. Until recently applicationshad to assume best e�ort service or take advantage ofnetworks able to support quality of service (such asATM) by using proprietary programming interfacesfor ATM network interface cards. Recently, theWinsock 2 programming interface was developed by aconsortium of vendors to allow application developersto take advantage of ATM [11]. Winsock 2 allows anapplication to specify a Quality of Service to theunderlying network, and then police it. Winsock 2 islikely to be popular for applications development in thenear future. The interaction of application layer inter-faces, such as Winsock 2, with underlying networktechnologies is an emerging and importance area ofnetwork research.

For video-on-demand to be a�ordable, storage andbandwidth must be utilized e�ciently. The objective ofthis paper is to evaluate schemes that will better usethese scarce resources. We begin with a discussionof user interactivity, and present statistics on the natureof interactivity obtained from wide area video-on-demand system trails carried out over the last two yearsin our laboratory. We model and evaluate the perfor-mance of a number of congestion control schemes basedon the di�erent. ATM categories of service. Finally, weanalyse the e�ectiveness of the policing mechanism ofWinsock 2 in an interactive video-on-demand environ-ment.

The rest of the paper is structured as follows. In``Video-on-Demand System Model'' we describe thevideo-on-demand system used in our work. It is verysimilar to an actual system developed as apart of ourvideo-on-demand trails at Monash University. `Ìnter-active Behavior of Users'' and ``Source Model'' describethe interactive behavior of users and a source model tocapture the user interactivity along with some prelimin-ary statistics relating to the interactivity in a video-on-demand system used in education. In ``Suitability ofATM Service Categories for IVoD'' we propose schemesfor carrying interactive video-on-demand on variousATM categories of service. We develop analyticalmodels of the proposed schemes based on di�erent

VIDEO-ON-DEMANDOVERATM 317

categories of service and compare the performance ofthe schemes. In `È�ect of Winsock 2 on ServiceTra�c'', we show techniques to control the impact ofextremes of interactive behavior on the schemes using anapplication layer such as Winsock 2. Our concludingremarks are presented in the conclusion.

Video-on-Demand System Model

We consider an interactive video-on-demand (IVoD)system where the client behavior is highly interactivein nature. In addition to play, clients frequently pause,fast-forward and fast-rewind. The video clients andthe server are connected together using a wide areaATM network (see Figure 1). The edge switches connectto the wide are ATM network. Switched virtualcircuits the video tra�c from the server to the clients.Video encoded at a constant rate is used for play.Fast-forward (FFR) and fast-rewind (FRW) are im-plemented by sending only I frames at the maximumrate supported by the server. We make the followingassumptions regarding the IVoD system discussed inthis paper.

Video on demand exhibits di�erent statistical beha-vior depending on the time it is examined. At each timescale, resources are provided di�erently. At the ®nesttime scale of the cell, it appears to be periodic, with largeI frames followed by smaller P frames and smallest Bframes. In addition, small bu�ers within the switch,server and client absorb the small time scale variation oftra�c to allow a smooth playout of video. At thecoarsest time scale, one can see session commencementsand terminations. At this time scale, the tra�c rate

Figure 1. A typical video-on-demand system.

variations are absorbed through limiting session com-mencements. Our interest is in behavior or a system atthe intermediate timescale (typically seconds to minutes)which capture user interactions such as pause, playFFW, FRW, etc. At this time scale, bandwidthprovisioning is the key technique used to deal withtra�c variations introduced by interactive behavior ofusers.

It is assumed that used interactivity exhibits Marko-vian behavior. Statistics from our video-on-demandtrails appear to back up this assumption [12]. Weonly model video systems using constant rate encodedvideo.

Interactive Behavior of Users

The IVoD system described in the previous section hasbeen used in an IVoD trial at Monash University. Theserver and clients were connected using the Experi-mental Broadband Network (Telstra Australia's experi-mental wide area ATM network connecting the majorcities of Australia). The trail involved students from theVisual Arts department who used the system in theiracademic courses for analysis and criticism of video®lms. The MPEG encoded ®lms were stored in theserver, and the students accessed the video ®lms over theATM network.

As part of the trail, we have collected data on theinteractive behavior of the users with a view todeveloping statistical models of users interactivity. Themodels are applied in this paper to determine thesuitability of the various ATM service categories incarrying IVoD. The models are also suitable fordescribing the performance of systems at the designphase (see ``suitability of ATM Service Categories forIVoD'').

Analysis of the collected data shows that the timespent by a user in the play mode can be approximatedby an exponential distribution with mean of 170seconds. Time spent in fast-forward/rewind and pauseare also exponentially distributed and have means of 20seconds and 50 seconds respectively [13]. We use thisinformation in the next section. To develop a three stateMarkov Chain model (Figure 2) to describe theinteractive behaviour of users. In Figure 2, states 0,1and 2 represent the user in pause, play and FFW/FRWmodes. We denote the bandwidth required in states 0,1and 2 by r0, r1 and r2 respectively.

Figure 2. Transition diagram for single client.

Table 1. Approximate transition probabilities

�(0,1) 0.050�(2,1) 0.020�(1,2) 0.003�(1,0) 0.003

Table 2. Mean times in each state

State Duration (seconds)

t0 50t1 170t2 20


We have found from subjective tests that for visualarts students studying video material the minimumacceptable level of quality is MPEG encoding at 2.0Mbps. When header information is included, thisencoding rate corresponds to a transmission rate of 2.5Mbps. The maximum rate supported by the server inour testbed for an individual video stream is 5 Mbps.Consequently, we use the above two values as repre-sentative data rates in our subsequent analysis, i.e.r0 � 0, r1 � 2:5 Mbps and r2 � 5 Mbps.

Source Model

In this section we develop a source model to representthe interactive behavior of users. The behaviour of auser at any instant of time determines the bit rates of thevirtual circuit connecting the user to the server. We usethe source model as the basis of our analysis todetermine the suitability of the ATM service categoriesto transport IVoD in the following section and toinvestigate the e�ect of the Winsock 2 layer onindividual VCs in `È�ect of Winsock 2 on SourceTra�c''. It is also used to study the e�ect of the ATMservice categories on the aggregate tra�c resulting frommultiplexing of the VCs at the server.

A tra�c source, representing the bit stream of a user,is modelled as a three-state process (Figure 2) represent-ing pause, play and fast-forward/rewind. The transitionsbetween the states are governed by the behavior ofthe client. Each state results in a di�erent bit ratefrom the server to the network. Based on our measure-ment of user behavior (see previous section) we modelthe duration of each state as Markovian; i.e. thetransition probabilities between the states are constantand depend only on the current state. The transitionprobability from state i to state j is represented by��i; j�; 0 � i; j � 2:

The source transition probability matrix Q, deriveddirectly from the above diagram, is given by:

Q �1ÿ ��0; 1� ��0; 1� 0��1; 0� 1ÿ ��1; 0� ÿ ��1; 2� ��1; 2�

0 ��2; 1� 1ÿ ��2; 1�

0@ 1A:�1�

As part of our video-on-demand trail, we madeavailable to undergraduate students some of the videomaterial being studied by them as part of their coursesthrough a video-on-demand system. Statistics as to userbehavior were collected over a two week period duringthe busiest time of student usage of video. From thestatistics, we developed the above model the derivedsource transition probabilities. The measured transitionprobabilities are given in Table 1 and the mean timesspent in each state are shown in Table 2. The values inTable 2 are derived from the matrix Q throughti � 1=�1ÿ qii�. From Table 1 and Table 2, we obtainthe probabilities of a client being in the di�erent statesas shown in Table 3.

The ATM Forum has de®ned ®ve categories ofservice for ATM: Constant Bit Rate (CBR), Variable

Table 3. State probability

State Probability

p0 0.208p1 0.709p2 0.083


Bit RateÐ real-time (VBR-rt), Variable Bit RateÐnonreal-time (VBR-nrt), Available Bit Rate (ABR)and Unspeci®ed Bit Rate (UBR). In this section weevaluate the suitability of the service categories forrunning IVoD.

CBR is intended for low latency, low loss and highquality real-time services. A ®xed amount of bandwidthis allocated during connection set up and applicationscan continuously transmit at that rate throughout theduration of connection. VBR-rt provides a similar highquality service, but is intended for the transfer ofvariable bit rate encoded video. Video can be encoded ateither constant quality or constant rate. When encodedat constant quality, the rate will ¯uctuate widely overshort time scales. VBR-rt is intended to allow thesevariations onto the network, within de®ned delayvariations, such as those introduced by queueing withinswitches. VBR-nrt also allows ¯uctuations over shorttime scales, but has less stringent delay variationrequirements than VBR-rt. Examples of tra�c suitablefor VBR-nrt include CAD/CAM and distributed super-computer applications. VBR connections are acceptedby switches based the switch's ability to meet therequested quality of service, de®ned by Peak Cell Rate,Sustainable Cell Rate, Maximum Burst Size and CellDelay and Cell Delay Variation (for VBR-rt).

ABR makes use of excess bandwidth in the networkfor the tranport of tra�c which is not time critical andcan tolerate variations in the bandwidth available fromthe network. Examples include ®le transfer and webaccess. ABR attempts to increase the utilization of thenetwork bandwidth using complex feedback controlmechanisms. ABR provides some service guaranteessuch as a Minimum Cell Rate.

UBR is intended for applications which do notrequire any guarantees. An examples is TCP/IP tra�c,where losses can be remedied by retransmissions.

In the above paragraphs, we have discussed thevarious ATM service categories and their suitability forvarious applications such as circuit emulation, data

tra�c, Web tra�c etc. In the subsections to follow, wewill discuss the suitability of the ATM service categoriesfor carrying IVoD. The suitability depends on a numberof competing priorities. First of all, not all categories ofservice are supported in all networks. For example,many carriers and equipment vendors do not supportABR. The second consideration is the quality of servicerequired by the IVoD service. Generally, higher qualityservices will cost more. Therefore, most clients are likelyto opt for the lower quality of service that is adequatefor the IVoD service.

Constant bit rate

In this subsection, we look at two bandwidth allocationschemes for running IVoD over a CBR service.

Peak rate allocationCBR circuits are allocated a ®xed amount of bandwidth.In the case of IVoD, the allocated bandwidth is the peakrate required for the di�erent viewing modes. For usagewhere the peak rate is P and the average rate is A thebandwidth utilisation is A/P.

For our system where the peak rate is used when inFFW/FRW mode, P is 5 Mbps and A is 2.2 Mbps(derived from Table 3). This results in a low bandwidthutilisation of only 2.2/5�0.44.

Renegotiated constant bit rateThe Renegotiated Constant Bit Rate service has beenproposed as a suitable service for the carriage of variablerate encoded video [14]. In this section we investigate thepotential of RCBR for interactive video-on-demand. Inthe Renegotiated Constant Bit Rate service, when aclient requests additional bandwidth from the network,the request is queued within the server until bandwidthbecomes available. Once available, a CBR connection isopened. Clients give up the bandwidth they already havewhen their request is queued. We believe that thisscheme has great potential, since it has the advantages ofCBR, but without the wasted bandwidth.

In this scheme:

. All clients share a ®xed amount of bandwidth over avirtual path.

. Fast forward is provided by transmitting only Iframes at a higher rate over a constant bit rate(CBR) channel.

. When a client requests either fast-forward or play,the bandwidth held by the client is released and the

Figure 3. Delay vs. number of clients.


request for additional bandwidth is queued withinthe server. The connection is kept open, but serviceto the client ceases until bandwidth becomes avail-able. Other information such as location within thevideo is not lost.

. If bandwidth is available, a higher rate channel isopened and the I frames are transmitted.

If bandwidth is not available, the request is queuedwithin the server.

We develop an analytical model of this scheme byusing a multi-server, ®nite population queue. Each 2.5Mbps unit of bandwidth is modelled as a separate serverwhile each request for bandwidth is treated as an arrivalin the queue.

The multi-server, ®nite population queue is in a senseself-regulating. As the number of clients waiting forbandwidth increases, the rate of arrivals decrease.Because of this, multi-server, ®nite population systemstend to be quite robust under heavy loads.

If N is the number of clients, � is the arrival rate ofrequests for additional bandwidth divided by the rate atwhich they are met for a single client, and m is thenumber of units of 2.5 Mbps bandwidth and pk is theprobability of k requests in the queue, then the steadystate probabilities of queue occupancy for a multi-server, ®nite population queue are from [15]:

Pk �p0 �

k 2Nk

� �; 0 � k � mÿ 1

p0�k 2N

k

� �k!m!m

mÿk; m � k � 2N

8>>><>>>: �2�

and

p0 �Pmÿ1k�1

2Nk

� ��k � Pmÿ1

m�1�k k!

m!mmÿk

� �ÿ1: �3�

If 1/l is the mean time between requests for bandwidthand 1=� the mean time between releases of bandwidthfor an individual client, then we can calculate � in termsof the mean time spent in each state as follows:

� � l�� t2p2 � t1p1

t0p0 � t1p1: �4�

As the bandwidth requests arrive and enter the queue,the arrival rate decreases. When there are i clientswaiting for bandwidth, the aggregate arrival rate li is:

li � �mÿ i�l: �5�

Therefore the average aggregate arrival rate of band-width requests is:

l �Xmÿ1i�0

pil�mÿ i�: �6�

We now apply Little's result to ®nd the expected delayE�T� experienced by a client while waiting for band-width:

E�T� � E�n�l

: �7�

Figure 3 shows the mean delay a client experienceswhile waiting for a fast forward request to be serviced ina small system of 10 clients sharing a 34 Mbps path.Given the inherent robustness of the multi-server, ®nitepopulation queue, it is not surprising that the schemeperforms very well even at very high loads.

It should be pointed our that we have made thesimplifying assumption that arrivals are Poisson,whereas, for each stream they will only be approxi-mately Poisson. Each request for a transition from state1 to state 2 generates two arrivals (requests forbandwidth), while a transition from state 2 to state 1releases two units of bandwidth. Also, the time betweenarrivals depends on whether the previous state waspause or view. However, the arrivals and service timeswill be dominated by the mean time in ordinary viewingmode, since it is much larger than the time in pause orfast-forward. So overall, we would expect Poissonianbehavior to be a reasonable model, and our simulationsshow that this is so.


This scheme is appealing for a number of reasons.First, clients use CBR for carriage of video. Forconstant rate encoded video, CBR is the most appro-priate category of service. This method has theadvantages of CBR without the wastefulness of band-width in CBR. Second, degraded service is expressed asdelay, rather than intermittent frame loss. This delaycan be controlled by using the Winsock 2 mechanism, toensure bandwidth is shared fairly amongst the clientsand to limit the delay. Third, there is no queueing ofvideo data within the server or the network. Videorequires substantial space and large queues of it bothadd to queueing delay and consume scarce network andserver bu�er space. With this scheme, only requests forbandwidth are queued. Fourth, using the Winsock 2mechanism, the system developer has great control overbandwidth allocation. Finally, the inherent robustnessof the multi-server, ®nite population queue shouldprovide robustness under heavy loads.

This scheme has a signi®cant disadvantage in that itgenerates additional signalling tra�c as connections areopened and closed. This could be ameliorated somewhatif a renegotiated constant bit rate category of servicewere de®ned. A connection would be opened for theduration of a session, but its parameters could berenegotiated with the network. Regardless of furtherdevelopments with ATM categories of service, even withthe existing CBR category of service, this schemeappears very promising.

Variable bit rate

Variable bit rate (VBR) is designed for the transmissionof real-time, constant quality, variable rate video.Bandwidth ¯uctuations in VBR occur on a small timescale. It is assumed that several multiplexed, small timescale tra�c will result in statistical multiplexing gain.Any bandwidth variations above the maximum rate willbe able to absorbed by a small amount of bu�eringwithin the switch. The bu�ering within the switchcannot be large since large bu�ers add to delay variationwhich causes performance degradation in real-timeapplications. Since bu�ering times within the switchare small when compared with the time scale ofinteractions, there is no distinction in between VBR-rtand VBR-nrt in our analysis.

For statistical multiplexing to be e�ective, tra�cbandwidth ¯uctuations need to be large and rapid. Withthe tra�c generated by user activity in an IVoD system,tra�c ¯uctuations are comparatively small and slow.

Consequently, we might expect VBR to perform poorlyfor this application.

As a measure of performance, we will use theprobability that the aggregate bit rate exceeds thebandwidth allocation to the virtual path. Since bu�eringwithin the switch is small compared to the timescale ofinteractions, we assume that aggregate bit rates exceed-ing that of the total capacity of the virtual path result incongestion.

The aggregate behavior of a number of clients eachhaving a number of states is a multinomial combinator-ial problem [16]. If we have N sources, each of which hasstates of 0,1 and 2, with probabilities of p0; p1 and p2respectively then the maximum output will be 2 N andthe probability that the aggregate output will be n is:

Pr�n�

�

PTrunc�n=2�

i�0M�N; i� �Nÿ n�; nÿ 2i; i�

�pi�Nÿn0 pnÿ2i1 pi2; n � N

PTrunc�Nÿn=2�

i�0M�N; iÿN� n; 2Nÿ nÿ 2i; i�

�pi0p2Nÿn2inÿ2i1 piÿNÿn2 ; n > N

8>>>>>>>>><>>>>>>>>>:

9>>>>>>>>>=>>>>>>>>>;�8�

The probability of congestion occurring during anyunit of time is the probability that the aggregate rateexceeds the rate of the output link. If the output link hasa maximum capacity of c then the probability ofcongestion is:

Pr�congestion� �X2Ni�c

Pr�i�: �9�

The following plot shows the performance as thenumber of clients (N) increases for a system with anE3 connection of 34 Mbps. In this case, c is Round (34/2.5)=14.

From the plot we see that the probability of cell loss ishigh when there are more than 13 clients. This scheme isprobably only tolerable for 9 or less clients when theprobability of cell loss is less than 1076.

Unspeci®ed bit rate

UBR is intended for carriage of data tra�c and to allowunused cells to carry waiting data. It is unlikely that itcould be used for video. Without any QoS guarantee, it

Figure 4. Probability of cell loss for VBR.


is unlikely that it could be used for the carriage of video.However, if a virtual path is allocated for UBR streamswhich are multiplexed across it, and cell delay and celldelay variation are absorbed by bu�ers within the client,the analysis and conclusion are the same as for the VBRcase.

Available bit rate

In this section, we evaluate the performance of ABR (arate based control scheme) for transport of video ondemand tra�c [17].

Rate based controlRate based control schemes make use of feedback andlarge bu�ers within the network to control congestion.Tra�c variation is absorbed by bu�ers that may in turnbecome congested. Once congestion is imminent,sources are informed that they must reduce their rate.The ABR category of service uses feedback to controlcongestion. Within the ABR speci®cation, there aremany options for implementing this. In this section, weconsider the vary simplest based on Backward ExplicitCongestion Noti®cation.

In our scheme, the server and the clients are connectedthrough ABR connections. Wide area bandwidth isscarce. Therefore, we assume that the switch thatconnects the server to the wide area is the bottleneck.The switch has a large bu�er that can absorb substantialamounts of video and release it onto the network whenbandwidth becomes available. However, once thebu�ers ®lls to a trigger point, it informs the server thatit must reduce its output. The server, on receiving themessage, drops frames from the output streams until amessage is received from the switch that it can resume

output. The rate of frame drop is the performancestatistic in this scheme.

For this scheme to be useful, large amounts of videomust be able to bu�ered within the edge switch, which isusually undesirable because of the cost and becauselarge switch bu�ers add to network delay. However, inABR delay is usually not important and the cost ofbu�er memory is decreasing rapidly. Since ABRconnections are likely to be much cheaper than CBR,it is worth considering the potential of ABR for carryinginteractive video-on-demand.

The ABR control mechanism is a simple STOP/START scheme where a STOP message is sent to thesource when the bu�er occupancy reaches a high tidemarker. The source stops transmitting data, and thebu�er starts to empty. We assume a negligible propaga-tion delay. Once the bu�er reaches a low tide marker, aSTART message is transmitted to the server which startsvideo transmission.

The presence of large bu�ers within the switches willintroduce large delay variations in the video received atthe client. This implies that the client will need signi®-cant bu�er space to allow continuous playout of video.

The amount of wide area bandwidth in ABR will¯uctuate considerably as other applications open andclose higher priority connections. Unfortunately, thenature and duration of these other connections may notbe predictable. However, ABR does allow the speci®ca-tion of minimum cell rates and at the very least we cangain some insights into the suitability or otherwise ofABR by considering its behavior when constant widearea bandwidth is available.

Analysis of rate based schemeWe use Markov Chains to examine the performance ofthis scheme. We begin by de®ning two ``super states''.Each state within the super state is bu�er occupancy.Super state I is entered when the switch sends a STARTmessage to the server, allowing it to transmit video.During super state I, the bu�er occupancy grows andshrinks as the client actions cause server tra�c to vary.Super state II is entered when the bu�er within theswitch reaches a trigger point and sends a STOPmessage to the server. During super state II, the serverdrops video frames, while the bu�er occupancy withinthe switch drops to a more acceptable level. We modelthe occupancy of the bu�er with two Markov Chains,one for each super state.

Figure 5. Bu�er occupancy and super states.

Figure 6. Markov Chain of bu�er states in super state I.


We use our Markov Chain model to calculate themean time spent in each of the superstates, and from thiswe can derive the mean frame loss probability within theserver. The mean time spent in super state I, can becalculated by treating super state II as a single absorbingstate, and all states in super state I as transient states.

We denote the transition matrix by:

P � 1 or Q

� ��10�

where Q are the transition probabilities betweenoccupancy 0 and H, o is the zero vector and r is thevendor associated with transition from transient toabsorption states. The values of Q are obtained byconsidering the probability of a transition within thebu�er.

In developing a Markov Chain model for the bu�erwe let m be the number of cells removed from the bu�ereach unit of time and N the number of clients. If thebu�er is serviced at the rate of m frames per second, thenthe probability of a transition from i to i�k is given bythe probability that k�m cells arrive.

For three state tra�c as we have in our model, theprobability of n arrivals from N clients has a multi-nomial distribution given by Eqn (8), from which weconstruct the transition matrix P� fpij; 0 � i � H; 0 �j � Hg

where

Pij �

0; m� j > i > jÿmPr�m� jÿ i�; m� j � i � jÿmPmÿik�0

Pr�k�; j � 0; j � 0; 0 � i � mPmk�Hÿ1

Pr�k�; j � H; i � Hÿm

8>>>>>><>>>>>>:

9>>>>>>=>>>>>>;: �11�

From P we de®ne the fundamental matrix [18] as

N � �IÿQ�ÿ1: �12�If the initial probability vendor is p, then the mean timeuntil absorption is

t � pNe: �13�Apart from initial startup time, when the bu�er

is empty, we know that super state I is only everentered from super state II when the occupancy is L.

Figure 7. Probability of cell loss against number of clients forrate based control.


Consequently, the initial probability vendor p is a vectorof Hÿ L elements de®ned by

pi � 1; i � L0; i 6� L

� �: �14�

All frames generated by the server are lost when thesystem is in super state II. Frames are not lost at anyother time. If we assume that the client requests areuna�ected by whether the switch is in super state I or II,then the probability of any frame being lost is theprobability of being in super state II.

Pr�loss� � Hÿ L

pNe�Hÿ L: �15�

E�ect of bu�er size on cell loss rateIn this section we apply the analysis in the previoussection to our system with 34 Mbps wide areaconnection to see how cell loss probability varies asthe number of clients is increased.

The above chart shows the probability of cell loss fora large bu�er of 3 Mbytes. The lower limit of L is 0.From the graph we can see that the rate based schemecan perform very well in keeping cell loss under control,provided a large bu�er is available. However, once thenumber of clients reaches a threshold, performancedeclines rapidly. Also, a large bu�er in the switch willcause large variations in cell delay experienced by theclient, and so will require large bu�ers in the client toabsorb this variation. We can summarize our analysis ofABR by saying that if bu�er memory for both the clientand the switch were to become very cheap, and if thecost of an ABR service were considerably less than thatof a CBR service, it might be suitable for carriage ofinteractive video-on-demand tra�c.

Comparison of schemes

CBR can be used to provide a very robust service.Its performance is measured in delay within the serveruntil bandwidth becomes available to service a fast-forward or ordinary view request. It can be used withthe Winsock 2 scheme to limit delays experienced byclients.

VBR is less well suited to the tra�c generated byinteractive video-on-demand. VBR is designed for tra�cwhere the bandwidth ¯uctuates rapidly and widely,whereas interactive video-on-demand generates tra�cwhich ¯uctuates over comparatively long time frames.The use of large bu�ers within VBR is not possiblebecause it is intended for real time services. Conse-quently, VBR based scheme experiences considerablecongestion.

UBR is a data service intended for non-timedependent tra�c. The analysis and the conclusions arethe same as for VBR.

ABR has potential, but requires large bu�ering withinthe network, which is currently very expensive.

Video-on-demand is unusual in that any of thecategories of service can be used to carry it. Use ofany particular category of service depends on theapplication, the relative cost of bandwidth in eachcategory of service, bu�er space available within theclient, network and server, and the extent of userinteractivity.

E�ect of Winsock 2 of Source Tra�c

The previous section has assumed that all clients behavein a consistent and fair manner. No client attempts touse more than the fair share of bandwidth. However,malicious users or equipment malfunctioning may makethe above assumption inpractical. In this section, weshow how a policing mechanism such as that de®ned forWinsock 2 can be used to enforce long term behavior ofvideo-on-demand clients [11].

Until recently, applications had to assume best e�ortservice, or could take advantage of only those networkswhich are able to support quality of service (suchas ATM) by using proprietary programming interfacesfor ATM network interface cards. Recently, theWinsock 2 programming interface has been developed

Figure 8. Winsock 2 layer model.


by a consortium of vendors to allow applicationdevelopers to take advantage of ATM. Winsock 2allows an application to specify a Quality of Serviceto an underlying network, and then police it. Winsock 2uses a token bucket mechanism to both de®ne andenforce the tra�c characteristics that the user transmitsonto the network. In this section, we investigatethe e�ect of the token bucket mechanism on usertra�c.

Winsock 2 control overview

In the previous section we saw how di�erent categoriesof service can be used to support interactive video-on-demand. We now turn our attention to the server, anddescribe how Winsock 2, can be used to limit the e�ectsof aberrant user behavior on the network.

Winsock 2 provides an application programminginterface that has a mechanism for programming theunderlying network. In particular it can communicate tothe network quality of service information needed forthe application. Winsock 2 uses the token bucketmechanism to specify and control the tra�c streamsthat the application will generate. The Winsock 2mechanism can be used to discard video frames withinthe server to reduce congestion within the network.Discarding at this point is preferable to discardingwithin the network. To minimize the e�ects on theclient, the server can choose which video frames aredropped, and which client will be least a�ected by losingframes. Also, it is preferable to discard frames at theearliest point in the network, than to waste resources intransporting video only part of the way to its destina-tion.

The token bucket is a simple mechanism to imple-ment, and if implemented as we describe, is fair in itsselection of frames to drop, since it will only drop framesthat are in high rate modes of fast-forward or fastrewind.

The token bucket forces a video stream to conform toa tra�c pattern. It limits the maximum burst size to thetoken bucket size and the sustainable rate to the tokenrate. Generally, the larger the bucket and the greater thetoken rate, the lower the lose rate. However, we areconfronted with a trade-o� between the server andnetwork. A low frame loss rate in the server may resultin degraded network performance, while infrequentcongestion within the network may be at the cost ofhigh rates of loss within the server.

Analytical model of Winsock 2 and interactive behavior

In this section we develop an analytical model of thee�ect of the Winsock 2 application interface oninteractive video-on-demand tra�c. Winsock 2 uses theToken Bucket scheme described in [11]. Tokens build upin the token bucket until they reach a maximum, beyondwhich tokens no longer accumulate. A token is removedwhen a unit of data (a frame, cell or packet) istransmitted onto the network. When the bucket isempty, and data waiting to be transmitted must waitfor a token. The rate at which tokens build up dependson the long term maximum rate at which the source cantransmit. The size of the token bucket is the maximumburst size that can be allowed onto the network in oneunit of time. Previous analyses of token buckets haveconsidered very bursty tra�c on a small time-scale [19].

We model the e�ect of the token bucket on the videotra�c by assigning a state to each rate/token pair asfollows. First, we make a number of assumptions as tothe order in which events task place during a slot (Figure9).

. Token arrives at the beginning of a slot. If the tokenbuckets is full, the token is lost.

. Packet arrives, removes a token (if one is available),and then departs. If there are no tokens, the packet islost.

. If a rate change occurs, it happens at the end of theslot.

For the three state interactive tra�c, we haveobserved on our system, the token bucket reduces thetime spent in the higher rate and increased the timespent in the intermediate rate. We look at two statistics:the probability that during any unit of time the tokenbucket will force the rate to drop from rate 2 to rate 1,and the mean duration spent in rate 2.

Figure 9. Event ordering.


We construct a Markov Chain to describe this systemas follows. We assume a token arrives each unit of time.The frame time (one-thirtieth of a second) is anappropriate unit of time. When paused, tokens areunused so the token bucket ®lls at the rate of one tokenevery thirtieth of a second. When viewing, the tokenbucket depletion rate matches the token arrival rate, sothe token bucket is unchanged. When fast-forward orfast-rewinding, the token bucket starts to empty.

The Markov Chain describing the token bucketscheme consists of a separate state for each pair ofpossible token and rate values. Figure 10 shows aMarkov Chain for a token bucket system with amaximum of three tokens, and a token rate of 2.5 Mbps.

Figure 10. Markov Chain for token bucket and interactivetra�c.

We denote the state with rate i and token bucketoccupancy j by sij. From the Markov Chain weconstruct a transition matrix P1 which consists of thetransition probabilities between the di�erent states asshown in Figure 10. We de®ne rate i as the bit rate instate sij for all j.

The state s2;0 represents a request for rate 2, but withinsu�cient tokens to sustain that rate. When a source isin s2;0, its rate will be 1, and not 2 as requested.Consequently the steady state probability of s2;0 gives usthe probability that at any particular time, a source'srate will be reduced from 2 to 1.

To obtain the probability that the policing mechanismwill drop cells, we solve the Eigensystem

� � P1� �16�where p is the steady state probability vector consistingof the states Sij, and the probability of the policingmechanism dropping cells is given by the probabilitys2;0.

We can also obtain the mean duration of a sourceremaining in rate 2, until it changes to rate 1, either of itsown accord, or is forced to by the token bucketmechanism. We treat those states representing rate 2as transient states and all other state (including s2;0) as asingle absorbing state. We then ®nd the mean time untilabsorption.

We modify P1 to obtain another transition matrix, P2.A source eventually enters rate 1 which we treat as anabsorbing state as in Eqn (10).

For this case, 0 is the zero vector, Q represents thetoken rate pairs where the rate is 2 and r is the vendorwhich takes the Markov Chain from transient states tothe absorbing state. The fundamental matrix N is givenby Eqn (12).

Figure 12. Mean time in rate 2 vs. token rate.


If � 0 is the initial probability of the transient states,and e the unit vector, then the mean time spend in state 2is:

t � � 0Ne: �17�We obtain � 0 by observing that a source begins its entryinto rate 2 from rate 1 (see Figure 10). Consequently, theinitial probability vector consists of the state probabil-ities of the states where the rate is 1 is:

�0 � fs1; jgPS1; j

: �18�

The next section uses this analysis to investigate theperformance of the token bucket when it is used tocontrol interactive tra�c.

E�ect of token bucket size and token rate

In this section we apply our analysis to a system wherethe play mode causes a bit rate request of 2.5 Mbps andfast-forward causes a bit rate request of 5.0 Mbps.

Figure 11 shows the probability of the Winsock 2mechanism dropping an I frame during fast-forward/rewind. This is derived from the equations given in theprevious section. The three graphs correspond to tokenbucket sizes of 10, 30 and 50 seconds of video at 2.5Mbps. We ®nd that large token buckets are needed toprovide any signi®cant e�ect on the source whileincreasing the token rate is e�ective in reducing theframe loss rate.

Another performance measure is the mean time until Iframes start to be dropped while in fast-forward/rewindin rate 2.

Figure 11. Probability of frame drop vs. token rate.

Figure 12 shows the mean duration in rate 2 withtoken bucket sizes varying from 10 to 50 seconds.

Winsock 2 has two important functions that are ofinterest to the developer of an interactive video ondemand system. The ®rst is that it allows the applicationto specify (to the network) the characteristics of thetra�c that is to be presented to the network. The secondis that it forces the user to conform to thosecharacteristics. This section has shown how the twotoken bucket parameters can be used to limit congestionwithin the network and allocate bandwidth fairly toclients.

Conclusion

In this paper we have described how interactive tra�ccan be carried across an ATM network using thedi�erent categories of service. The suitability of anumber of congestion control schemes for the transportof highly interactive video on demand over ATM havebeen evaluated. In order to carry out the aboveevaluation, we have developed a framework forrepresenting the interactive nature of users in a video-on-demand systems (which is used in education) and amodel to capture the interactivity of the users. Therenegotiated CBR based scheme uses bandwidth moste�ciently. If the cost of bu�er space is small, ABRmight also be used to carry interactive video-on-demand. Our evaluations indicate that VBR and UBRperform poorly in an interactive video-on-demandenvironment.

Finally, we have shown how the Winsock 2 applica-tion layer a�ects the underlying tra�c. Winsock 2 canbe used to provide limits to excessive behavior of clients


and to communicate to the network the nature of thetra�c to be carried.

Acknowledgements

The support of Telstra Australia, Siemens Ltd, MonashUniversity and the Australian Government's Coopera-tive Research Centre Scheme in the preparation of thispaper is gratefully acknowledged.

References

1. Branch, P. & Durran, J. (1996) PC Based Video onDemand Trials. Learning Technologies, Prospects andPathways, Edtech'96, Melbourne, July 1996.

2. Branch, P., Newstead, S. & Kaushik, R. (1996) Design of aWide Area, Video-on-Demand User Interface. Proceedingsof Australian Telecommunication Networks and Applica-tions Conference, Melbourne, 3±6 December 1996, pp. 55±58.

3. Leditschke, M. & Johnson, A. (1995) Implementation ofMPEG-2 Trick Modes. Proceedings of Australian Tele-communications Networks and Applications Conference,Sydney, Australia, 11±12 December 1995, pp. 39±44.

4. Li, V. O. K., Liao, W., Qiu, X. & Wong, E. W. M. (1996)Performance Model of Interactive Video-on-DemandSystems. IEEE Journal on Selected Areas in Communica-tions 14: 1099±1109.

5. Dey-Sircar, J. K., Salehi, J. D., Kurose, J. F.& Towsley,D. (1994) Provisioning VCR Capabilities in Large-ScaleVideo Servers. Proceedings of ACM Multimedia 94, SanFrancisco, California, USA, October 1994, pp. 25±32.

6. Andersen, D. B. (1996) A Proposed Method for CreatingVCR Functions using MPEG Streams. Proceedings ofIEEE 12th International Conference on Data Engineering,New Orleans, LA, USA, pp. 380±382.

7. The ATM Forum, ATM User-Network Interface Speci®-cation, Version 3.1, The ATM Forum, September 1994.

8. Zheng, B. & Atiquzzaman, M. (1998) Multimedia OverHigh Speed Networks: Reducing Network RequirementsWith Fast Bu�er Fillup. IEEE GLOBECOM'98, Novem-ber 8±12, Sydney, Australia.

9. Zheng, B. & Atiquzzaman, M. (1998) Multimedia overATM: Progress, Status and Future, IC3N: SeventhInternational Conference on Computer Communicationsand Networks, October 12-15, 1998, Lafayette Louisiana,USA. pp. 114±121.

10. Zheng, B. & Atiquzzaman, M. (1998) Video on Demandover ATM: System Design and Networking Require-ments. ENCOM-98: Enterprise Networking and Comput-ing'98, June 7, 1998, Atlanta, Georgia.

11. Quinn, B & Shute, D. (1996) Windows Sockets NetworkProgramming. Reading, Massachusetts, Addison-WesleyPublishing Company.

12. Branch, P. (1998) Bandwidth Allocation Schemes forInteractive Video-on-Demand. IEEE International Sym-posium on Computers and Communications, Athens,Greece, 1998.

13. Branch, P. & Atiquzzaman, M. (1997) ATM Category ofService for Interactive Video on Demand, IEEE/IEEInternational Conference on Telecommunications, Mel-bourne, April 1997.

14. Grossglauser, M., Keshav, S. & Tse, D., RCBR: ASimple and E�cient Service for Multiple Time-ScaleTra�c. IEEE/ACM Transactions on Networking, 5:741±755.

15. Kleinrock, L. (1975) Queuing Systems, Vol 1, John Wileyand Sons Inc.

16. Brualdi, R. (1977) Introductory Combinatorics, New York:North Holland.

17. Branch, P., Atiquzzaman, M. (1996) Modelling RateBased Congestion Control in an ATM Network Designedfor Video Retrieval, Proceedings of Australian Telecom-munications Networks and Applications Conference, Mel-bourne, 3±6 December 1996, pp. 55±58.

18. Kemeny, J. & Snell, J. (1960) Finite Markov Chains,Princeton, New Jersey: Van Nostrand.

19. Sen, P., Maglaris, B., Rikli, N. & Anasstassiou, D. (1989)Models for Packet Switching of Variable Bit Rate VideoSources. IEEE Journal on Selected Areas of Communica-tions, 7: 865±869.

Documents

Congestion Control for Interactive Video-on-Demand over ATM