Allocating resources for soft requests—a performance study

NORTH-HOLLAND Allocating Resources for Soft R e q u e s t s - - A Performance Study YI-BING LIN YOVI-JIAN LIN and VIC~["OR MAK Bellcore, 445 South Street, Morristown, NJ 07960-6~38

ABSTRACT To effectively utilize a l i m i t e d n u m b e r of resources s h a r e d by m a n y users, algor i t h m s h a v e b e e n p r o p o s e d to m a n a g e t h e " d y n a m i c resource allocation" p r o b l e m . T r a d i t i o n a l l y , t h e s e a l g o r i t h m s only deal w i t h rigid requests t h a t precisely specify t h e desired n u m b e r of resources needed. However, in a p p l i c a t i o n s such as s t o r a g e a l l o c a t i o n a n d parallel processing, or in new t e l e c o m m u n i c a t i o n services such as S w i t c h e d F r a c t i o n a l - D S 1 a n d a d a p t a b l e - b i t - r a t e video, a user m a y prefer to initia t e ~oft requests, each of which expresses n o t only t h e desired n u m b e r of resources b u t also t h e m i n i m u m n u m b e r of t h e m . In order to increase t h e possibility of a r e q u e s t b e i n g g r a n t e d , t h e user w h o sends in t h e soft r e q u e s t is willing to accept a d e c r e a s e in service quality by receiving fewer resources. How to decide w h e t h e r to a c c e p t or d e n y soft requests, so t h a t a p e r f o r m a n c e o b j e c t i v e can be m e t , adds a n e w d i m e n s i o n to t h e old resource allocation p r o b l e m . T h i s p a p e r s t u d i e s t h e i m p a c t of soft r e q u e s t s on various resource allocation a l g o r i t h m s . Four a l l o c a t i o n a l g o r i t h m s for soft r e q u e s t s are s t u d i e d in t h i s p a p e r v i a a simu l a t i o n t h a t is b a s e d u p o n a n e v e n t - d r i v e n model. For t h e p e r f o r m a n c e m e a s u r e s we choose (i.e., utilization, a c c e p t a n c e ratio, a n d allocation ratio), t h e results i n d i c a t e t h a t some a l g o r i t h m s c a n gracefully a d a p t to different s y s t e m loads a n d achieve b o t h a h i g h a c c e p t a n c e r a t i o a n d a high u t i l i z a t i o n at t h e cost of t h e a l l o c a t i o n ratio. T h e results also show t h a t h a v i n g soft r e q u e s t s is b e t t e r for enh a n c i n g t h e a c c e p t a n c e ratio, a n d t h a t increasing t h e t i m e - o u t p e r i o d c a n f u r t h e r i m p i o v e t h e possibility of a soft request b e i n g accepted. However, our s t u d y indicate,; t h a t m a k i n g t h e t i m e - o u t p e r i o d a r b i t r a r i l y large m a y n o t b e cost-effective, since a f t e r t h e t i m e - o u t p e r i o d is over a t h r e s h o l d value, t h e a c c e p t a n c e r a t i o is hardly improved further.

I N F O R M A T I O N SCIENCES 84, 39 65 (1995) ELsev,er Science Inc., 1995 !355 Avenue of the Americas. New York. NY 10010

0020-0255/95/$9.50 SSDI o020-0255(94)00079-Q

40 1.

Y.-B. LIN E T AL. INTRODUCTION

M a n y applications need to dynamically request and return system resources such as m e m o r y cells, processors, peripheral devices, and communication bandwidth. To effectively utilize a limited n u m b e r of resources, algorithms have been proposed to m a n a g e the "dynamic resource allocation" problem (e.g., see algorithms in [11, 6] for dynamic storage allocation: and policies in [4, 8 10] for sharing resources in c o m m u n i c a t i o n networks). XYaditionally, the requests to be dealt with by these algorithms are rigid, in the sense t h a t in each request the desired n u m b e r is precisely specified for each type of resources. An algorithm has to make a decision either to fulfill a request entirely or to reject it. However, in some applications a user m a y prefer to be granted a significant portion of requested resources even when the request cannot be satisfied completely. For example, a user m a y wish to execute a p r o g r a m in parallel with a certain n u m b e r of processors, but might be willing to settle for fewer processors as long as the performance is still better t h a n t h a t of a sequential execution. We refer to this kind of resource request as a soft request. In general, a soft request specifies not only the n u m b e r of resources it desires, but also the m i n i m u m n m n b e r of resources it can tolerate. In order to increase the possibility of a request being accepted, the user who sends in the soft request is willing to compromise with the system by reducing the n u m b e r of requested resources if necessary. A resource allocation algorithm dealing with soft requests can decide whether to sal, i s ~ a request entirely or partially, provided the resource granted is within the range specified by the user. A particularly interesting application area is provided by the shared resources in a public communications network. In a telecommunication system, resources can be trunks, bandwidth, switches, peripherals, cust o m e r premises equipment, or anything t h a t is needed to provide services to customers. In response to serwce requests, the system allocates resources based upon some preset strategies. As technologies advance, more and more services are being designed to a c c o m m o d a t e various user requests d y n a m ically. For example, a new service concept called Switched Fractional-DS1 (or S W F - D S 1 , for short) [2] will s u p p p o r t real-time switching of fractional DS1 rate services from 128 kbps to 1.536 Mbps in 64-kbps increments. S W F - D S 1 will allow a customer to establish digital connections with another customer at various rates between 128 kbps and 1.536 Mbps in less t h a n ten seconds. It has been suggested t h a t potential applications such as videoconferencing, customer network survivability/overflow, bulk d a t a t r a n s f e r / d a t a b a s e backup, and electronic imaging could benefit from the S\VF-DS1 [3!. Viewing the 64-kbps rate as one type of resource, S W F DS1 is a service that. can be operated on 2 to 24 such resources: in the

A L L O C A T I N G RESOURCES F O R SOFT REQUESTS

41

future a customer may request applications be operated on a bandwidth within a range specified in terms of nmltiples of 64 kbps, and rely on the system to allocate a proper bandwidth (and bill accordingly) based upon the system traffic. As another example, a Metropolitan Area Network (MAN) experimental research test-bed [1] has demonstrated the feasibility of adaptable-bit-rate (ABR) packet video transmission [17]. In an envisiorLed future scenario [16], a Virtually Private Metropolitan Area Network (VP-MAN) service within a public MAN may offer a guaranteed minimum access bandwidth to a multi-user customer with several access nodes at different locations. Based upon factors such as traffic load and user apFlications, the public operating company owning the MAN may dynamically allocate bandwidth to allow customers to transmit information at bit rates higher than their guaranteed minimum bandwidth during network low usage time. A third example is variable-bit-rate applications in personal conmmnications services (PCS) such as channel allocation for hand-off [12]. Such a PCS channel allocation scheme provides for hand-off to radio ports on which there is no free channel by %ub-rating" an existing connection. Wi~;h sub-rating, an occupied full-rate channel is temporarily divided into twc half-rate channels: one to serve the existing call and the other to serve the hand-off request. The blocking probabilities (combined forced terminations of existing calls and blocking of new call attempts) of this new scheme compare favorably with the standard (nonprioritizing) schemes [13]. T h e dynamic resource allocation problem for soft requests is described as :(ollows. Suppose that a system has a number of resources shared by multiple users) A resource allocation module in the system is responsible for managing the usage of system resources dynamically at run time. Users can initiate soft requests: each soft request Ri specifies the desired number d~ and the minimum number mi, m~ _< di; hence each soft request Ri is a pair (m~, d~). The softness si of Ri is then defined as d~ - m~ S i

--

d~

Upon receiving a soft request Ri from a user, the module decides, based upon some resource allocation algorithm, whether to accept the request and grant a certain number ai of resources to the user, mi < ai < di. The decision should be made within a predetermined time-out period T, 0 :~ ~- < Oc; otherwise the request R~ is rejected. Once resources are granted to the user who issued Ri, they will not be available to other users until they are released. The period that these resources are unavailable to LFor simplicity, we a s s u m e t h a t all s y s t e m resources are of t h e s a m e t ype . T h e s t u d y can be g e n e r a l i z e d to s y s t e m s w i t h m u l t i p l e t y p e s of resources.

42

Y.-B. LIN E T AL.

other users is called the holding time t~ of the accepted request R~. Given an objective expressed in terms of some performance measures, tile problem is to find an algorithm that can better achieve the objective. Soft requests can lead to many interesting consequences. Assuming that the quality of a service is a function of the number of resources allocated to the service (e.g., the higher the bit rate at which a video image is transmitted, the better the video quality), a user may request a desired number of resources for the best service quality, as any extra resources over the desired number will not improve tile service quality significantly (e.g., the video quality at the destination cannot be better than the one at the source, no matter how high the bit rate is for transmission). The user may also specify a minimum quality of service, because a service quality worse than that is totally unacceptable (e.g., a video image compressed to coo low a bit rate for transmission cannot be recognized at the receiving end). Therefore, a soft request reflects a customer's willingness to exchange a decrease in service quality for an increased chance of acceptance. On the other hand, the system may decide to accept more requests but provide lower service quality, if the acceptance of requests (e.g., higher call-completion rate) is a bigger concern than a slight degradation of service quality. AIternatively, the system may want to accept fewer requests but offer higher service quality for each accepted request, if the service quality proves to be a more valuable measure (e.g., generates more revenue). The above discussion is based upon the assumption that the holding time of a soft request is independent of the number of resources allocated for the r e q u e s t - - t h e differences in the number of allocated resources only alter the service quality. This is true of real-time video services, but not necessarily so for other services such as bulk data transfer, processor scheduling, and memory management. For example, given a higher bit rate (i.e., more resources), a file can be transferred in a shorter period of time (i.e., less holding time). Having the holding time of a soft request as a function of the number of resources granted further complicates resource allocation algorithms, since the marginal benefit (i.e., the reduction in the time-resource product, which also affects when and how many resources will be available for serving other requests) of assigning one extra resource to two different soft requests could be dramatically different. This paper presents our empirical results on the impact of soft requests on various resource allocation algorithms. The study has focused on the types of applications for which the number of resources allocated to a soft request R~ has no effect on its holding time ti. Moreover, the nuInber of resources allocated with respect to Ri remains unchanged throughout ti. Four allocation algorithms are studied in this paper. H1 (always allocates maximum), H2 (always allocates minimum), $1 (allocates minimum

ALLOCATING RESOURCES FOR SOFT REQUESTS

43

unless extra resources are available), and $2 (allocates m a x i m u m unless available resources are not enough). Each of them a t t e m p t s to strike a balance between two common performance measures: the utilization of system resources and the acceptance ratio of requests. Unlike other algorithms (see [7] for examples) t h a t solve various static resource allocation problems based upon linear and nonlinear programming techniques, the algorithms we discuss in this paper must incorporate some heuristics to achieve their respective objectives. For example, H1 and $2 assume that resources will be available for new requests most of the time; therefore, to achieve high utilization they have to grant m a x i m u m number of resources whenever possible (or, in the case of H I , all the time). To understand the percentage changes in the service quality (note that the quality of a service is a function of the number of resources allocated to the service), we introduce the third performance measure, allocation ratio, which represents the average percentage of the number allocated with respect to the number desired for all the soft requests accepted. In our simulation results, we found t h a t H2, $1, and $2 usually have better acceptance ratio measures (at the cost of the allocation ratio), but they hardly outperform H1 in terms of the utilization; it implies t h a t the effect of "squeezing in a few requests" (i.e., accepting a soft request, when the number of available resources is running low, by allocating fewer number of resources) on the utilization is minimal. However, algorithms that tend to fulfill the minimum needs of most requests before attempting to satisfy any request entirely (e.g., $1) can gracefully adapt to different system loads better and achieve high acc e w a n c e ratio and high utilization. Provided that the system is not in an extraordinarily overloaded situation, we also found that the performance measures are dependent upon the combined changes of several input parameters (which are reflected in two derwed parameters, the batch size and the offered load, to be formally defined in Section 2.1), rather than upon the changes of some individual parameter (see Section 4.3). This observation has made it possible for us to study the impact of soft requests more effectively. Intuitively, one may think that if a user is willing to wait for a decision for a bit longer (i.e., a longer time-out period), the requests the user issues will have the better chance of being accepted. Although this phenomenon does occur in our simulation when the time-out period is small, our results also show t h a t it is not always cost-effective to boost the acceptance ratio by making the time-out period arbitrarily large--trade-offs (marginal improvements in the acceptance ratio vs. larger buffer size in the module and longer waiting time for a decision) must be considered before a t t e m p t i n g to increase the time-out period. The paper is organized as follows. Section 2 describes our system model,

44

Y.-B. LIN ET AL.

including the definition of input parameters and performance measures. Section 3 discuss various resource allocation algorithms to be studied. Performance results are presented in Section 4, followed by concluding remarks in Section 5. 2.

T H E SYSTEM MODEL

Figure 1 shows the system model for our study. The resource allocation module consists of a front-end, a server, and an internal queue. The front-end is the interface to users, processing incoming (request and 7"etuT-n) messages at P1 and outgoing (9r'ar~.t) messages at P2. The server runs a chosen resource allocation algorithm. If the server can accept a request R~ forwarded by P1, it immediately sends a 9rarzt message to the user through P2. Otherwise R~ is placed in the internal queue waiting for additional resources to become available. On the other hand, each user, after being granted the number a,~ of resources for Ri, will keep ttlem for ti units of time before returning them to the allocation module via a retur'~, message. Note that each request message that arrives at the resource allocation module will be time-stamped with the time it reaches P1. Any request that has been in the module longer than the time-out period (i.e., cur-vent-time- stamped-time >_ r) without being awarded resources will be removed from the internal queue and rejected. We also assume that the message processing time at the front-end is a constant p for all types of messages. As shown in Figure 1, two types of messages arrive at P1. Due to the possible delay of message processing, the order in which P1 chooses to process them may affect the utilization of resources. In our model, P1 constantly switches processing priorities among these two types based upon the length of the internal queue: request messages have a higher priority when the internal queue is empty, and return messages have a higher priority otherwise. Intuitively this strategy should result in better performance for the following reasons. An empty internal queue implies a fairly good chance that the remaining resources could satisfy a new request; hence for the sake of utilization, it is not wise to delay the decision by processing return messages first. On the eonrrary, a nonempty internal queue means that the remaining resources are not sufficient to fulfill the needs of requests in the queue; therefore to increase the acceptance ratio as well as the utilization, it is better to see if increasing the number of available resources (by processing return messages first) could make the module accept some old requests before they are rejected due to the expiration of the time-out period, and at, the same time reduce the idle time of each resource (i.e., the period in which no user is using it).

ALLOCATING RESOURCES FOR SOFT REQUESTS resource

allocation

• . . . . . . . . . . . . . . . . . . . . . . . .

request

t.........

~

J

i

45 module ~

server

,,,,"" ',,'

return

i

i

'2Y;SE-. ! Z/L' l

. . . . . . . . .

,,, I i terna

grant

queue

I

i i i

.

.

.

.

.

.

.

.

.

I

delay front-end • . . . . . . . . . . . . . . . . . . .

J

users

Fig. 1. The system model.

2.1.

INPUT P A R A M E T E R S

T h e s y s t e m is characterized by the following i n p u t parameters: • • • • • • •

n: the A: the d: the s: the t: the p: the ~-: the

t o t a l n u m b e r of resources in the system. rate of i n c o m i n g soft requests. average desired n u m b e r of resources for a request. average softness for a request. average holding time for a request. message processing time at the front-end. t i m e - o u t period.

We a s s u m e t h a t the arrival of soft requests at the resource allocation m o d ule is a Poisson process. A soft request can be described in terms of the n u m b e r of resources desired, the softness, and the holding time. For each request in our study, the desired n u m b e r is d r a w n from a b i n o m i a l distrib u t i o n with the m e a n d; the softness is d r a w n from a t r u n c a t e d n o r m a l d i s t r i b u t i o n in the range [0, 1] with the m e a n s and the s t a n d a r d d e v i a t i o n (1 -- s ) / 3 ; and the holding t i m e is d r a w n from a n e x p o n e n t i a l d i s t r i b u t i o n w i t h the m e a n t. p and T are constants, p <_ T. T h e above p a r a m e t e r s are referred to as the primary p a r a m e t e r s of the system. For ease of discussion, we also introduce three derived p a r a m e t e r s based on the p r i m a r y parameters.

46

Y.-B. LIN E T AL. ~t • c ( = 2): t h e capacity of t h e system, r e p r e s e n t i n g t h e average m a x i m u m n u m b e r of soft requests t h a t can be fully satisfied at a n y given time. • p ( = --~ _: t h e offered load, r e p r e s e n t i n g t h e average s y s t e m l o a d should all requests be fully satisfied. We a s s u m e t h a t t h e s y s t e m has been engineered to h a n d l e t h e offered load p = 1. • g ( = AT): t h e batch size, i n d i c a t i n g t h e average n u m b e r of r e q u e s t s t h a t arrive w i t h i n t h e t i m e - o u t period. 2

T h e s e derived p a r a m e t e r s have some i n t e r e s t i n g p r o p e r t i e s . For e x a m p l e , should p be sufficiently small (which is g e n e r a l l y t r u e ) , t h e n a c c o r d i n g to Little's result [14], ~ is t h e u p p e r b o u n d of t h e average n u m b e r of r e q u e s t s p e n d i n g to be processed by t h e server at any time. 3 Moreover, as we will show in Section 4, given a softness s a n d a processing t i m e p, c h a n g i n g t h e values of p r i m a r y p a r a m e t e r s n, A, d, t, a n d ~- will have no effect on t h e p e r f o r m a n c e , as long as p and 6 r e m a i n c o n s t a n t .

2.2.

PERFORMANCE MEASURES

T h r e e p e r f o r m a n c e measures, utilization, acceptance ratio, a n d allocation ratio, serve as t h e criteria for e v a l u a t i n g different resource a l l o c a t i o n a l g o r i t h m s . L e t I be t h e set of requests s u b m i t t e d to t h e s y s t e m d u r i n g t h e o b s e r v a t i o n p e r i o d T, a n d IA be t h e set of requests accepted. Let [It a n d IIAI be t h e n u m b e r of requests s u b m i t t e d a n d a c c e p t e d w i t h i n T, respectively. For each request Ri = (mi,d~) t h a t is a c c e p t e d , let ai be t h e a l l o c a t e d n u m b e r of resources a n d ti be t h e holding time. We define t h e s e t h r e e m e a s u r e s as

Utilization:

bt

1

nT

ait~, RiEIn

A c c e p t a n c e Ratio:

A - IIAt III '

a l l o e a t i o n Ratio:

1 $-IIAI

E

ai d-~i"

RiEIA

2In [5], 5 is called the ievel of concurrency. 3When p is sufficiently small, a request cannot be pending in the module for a period longer than ~-. since it will have been either accepted or rejected (due to time-out) by then. Therefore by applying Little's result, the upper bound is AT = &

ALLOCATING RESOURCES FOR SOFT REQUESTS 3.

47

RESOURCE ALLOCATION ALGORITHMS

Four resource allocation algorithms, H I , H2, $1, and $2, for serving soft requests are studied in this paper. B o t h S1 and $2 a t t e m p t to allocate the desired number di (or ai, mi <_ ai _< d~, if only ai resources are available) to a new soft request Ri. New requests t h a t cannot be satisfied will be placed in the internal queue. S1 and $2 differ in the way t h e y process the requests in the internal queue when resources are returned to the m o c u l e (i.e., more resources become available). Intuitively, S1 tries to accept as m a n y requests as possible by only allocating the m i n i m u m n u m b e r of resources t h e y requested, and will not grant additional resources to t h e m unless the system still has resources to spare. O n the other hand, $2 tries to flflly satisfy every request unless the remaining system resources are not enough for it to do so. In terms of performance objectives, S1 emphasizes the acceptance ratio, while $2 is geared toward the allocation ratio. The Algorithm $1: Let n ~ be the number of resources which are still available for allocation (including those t h a t were just returned), and R be the set of requests currently in the internal queue. M = Y~(m~,a,)eR rni and D = ~(m,,a~)eR d~ represent total m i n i m u m numbers and total desired n u m b e r of the requests in the internal queue, respectively. C A S E I: If n ~ _> D, then it allocates di for every R~ in R. C A S E II: If M < n ~ < D, then it first allocates mi for every Ri in R. After that, if there are still resources available, then it allocates additional (dj - m j) for the first k - 1 requests Rj in the queue, and the remaining (ak - ink) to the kth request Rk, where k is chosen such t h a t

l
1

C A S E III: If n ~ < M , then it allocates rn~ for the first k requests in the queue, where ~ l < i < k rni _< n' < ( ~ l < i < k + l mi). After that, if some resources are still available, it then allocates additional resources to those k requests in sequence as it does in the previous case, until either it runs out of available resources or all k resources are fully satisfied. Note t h a t in the first two cases all requests in the internal queue are accepted, but in the third case only the first k requests are accepted. 1he Algorithm $2: If n' _> D, this algorithm does the same thing as $1 does. Otherwise, it allocates di for the first k - 1 requests Ri in the internal

48

Y.-B. LIN ET AL.

queue, and ak = (n'-- Y'~.l<_j<_k-1 dj) for the kth request (if m k <

ak < dk),

where El
PERFORMANCE

This section presents our simulation results on the performance of the four resource allocation algorithms mentioned in Section 3. This eventdriven simulation is developed on top of an object-oriented simulation environment called DOSE [15]. In all experiments, the observation period T is set for 20,000 time units, and statistics collected in the first 500 time units are discarded to avoid transient behaviors.

4.1.

E F F E C T S OF ALLOCATION ALGORITHMS

Figure 2 shows the performance of different algorithms. In the experiments, d = 1000, t = 120 time units, n = 1,200,000, ~- = 0.5 time units, p = 0.001 time units, s = 25%, and ~ ranges from 5 to 50 requests per each time unit in increments of 5. Since p = d)~t/n, and d, t, and n are fixed in these experiments, the offered load p is in proportion to the arrival rate £. For the given values of d, t, and n, the offered load reaches 1 (i.e., the engineered offered load) when £ is equal to 10.

ALLOCATING RESOURCES FOR SOFT REQUESTS

49

1.0

0.8

0.6 m

Sl

0.4

H1 H2

4-

0.2 5

10

20

lS

25

30

3S

40

45

SO

a

val-rate

(a)

1.0

0.9 0.8

8

0.7 0,6

[]

$1

4

Hl S2 H2

,-

o.s

" 1'o " ~'s " z;

" 2; (~)3;

" is

'4;

' 4s

" so

,,'r',,a,r,,,~

0.9 o

0.8 0.7 0.6

-

$1

8

$2

0.5 0.4

•

|

10

•

i

15

•

l

20

•

|

•

25

|

30

•

l

35

•

|

40

•

i

45

50

(C)

Fig. 2. Effects of various allocation algorithms (s = 25%).

arrival rate

50

Y.-B. LIN E T AL.

When the system is below the engineered offered load (i.e., A _< 10), the system has enough resources to fully accommodate most requests; hence Algorithm H1 performs well in terms of both the utilization and the acceptance ratio. However, the acceptance ratio drops significantly when the arrival rate is greater than 10 (i.e., when the system becomes overloaded). This is not surprising, as this is what we will normally expect to see in overload situations when requests cannot be satisfied. Algorithm H 2 in these experiments only assigns on average 75% (i.e., 1 s) of the desired number of each request. Thus, the acceptance ratio of this algorithm is expected to be higher than that of other algorithms, especially when the system is heavily loaded. The experimental results shown in Figure 2b justify our intuition. However, compared with H1, Algorithm H2 yields poor utilization when the system is under the engineered offered load. For the same reason wily H1 is doing so well in a lightly loaded system, H 2 can accept ahnost every request, but its utilization performance suffers for its conservativeness in allocating resources. Clearly, when the acceptance ratio for H1 is nearly 100% (i.e., every request is accepted), H 2 can degrade the system utilization to a level which is close to the 1 - s (in this case 75%). Figure 2a shows the phenomena. H1 and H2 are two extremes in handling soft requests: H1 suffers for the acceptance ratio at heavy load, while H2 performs badly in the utilization measure at light load. With a simple strategy, Algorithm $1 remedies these deficiencies easily. As shown in Figure 2a and b, $1 performs as well as H1 does in terms of the utilization, and nearly the same as H 2 can do in terms of the acceptance ratio. The allocation ratio measure of $1 shown in Figure 2c gives us some insights why $1 performs well. As shown in the figure, S1 gracefully shifts the allocation ratio from 1 (i.e., allocating the desired number, like H1) to 0.75 (i.e., allocating the minimum number, like H2) when the load increases. $2 also tries to take advantage of the flexibility in allocating resources for soft requests. However, since $2 is basically the same as H1 except t h a t it will occasionally "squeeze in" one or two partially satisfied requests when the resources are almost used up, its performance is not much different from t h a t of H1. Nevertheless, as the offered load becomes higher, the number of requests waiting in the internal queue gets larger; therefore, $2 has more chances of partially satisfying some requests immediately when resources are returned to the system. As a result, $2 does not degrade the acceptance ratio as much as H1 does, especially when the arrival rate (consequently, the offered load) gets higher (see Figure 2b). On the other hand, Figure 2c shows t h a t $2 does not even up the allocation ratio as much as S1 wants to; hence the acceptance ratio of $2 is much worse than t h a t of $1 when the system load is high.

ALLOCATING RESOURCES FOR SOFT REQUESTS

51

To summarize, soft requests will not (with the exception of H2, which is too conservative) affect performance measures when a system is under the engineered offered load. When the system is overloaded, soft requests have no effect on the utilization either, since resources are already highly utilized ( ~ 99%). However, in that situation different algorithms may yield different trade-offs between the acceptance ratio and the allocation ratio.

4.2.

EFFECTS OF SOFTNESS

To get an idea of how softness can affect the performance measures, we run the same set of experiments as we did for Section 4.1, this time s = 50%, and then compare their results. Figure 3 shows the performance results for s = 50%, and Figure 4 plots the effects of having "softer" reques-:s by comparing Figure 2 with Figure 3 for each performance measure, respectively. A~ we have stated in Section 4.1, except for H2, soft requests have no effect: on the utilization. This is illustrated by a nearly straight line in Figure 4a for $1, $2, and H1. The changes for H 2 can also be explained. Since H 2 effectively scales down the offered load by s, for two percentages of softness Sl and s2, we will expect H 2 to start fully utilizing system resources at two different system loads that bear roughly the same proportion as sl and s2: the higher the softness, the larger the offered load. Our results, A = 15 (i.e., p = 1.5) for s = 25% in Figure 2a and A = 30 (i.e., p = 3) for s = 50% in Figure 3a, show exactly that. In the case t h a t almost all requests are accepted, which is when the system is under the engineered offered load, switching from Sl to s2, H2 will change the utilization by ((1 - s 2 ) - (1 - s l ) ) / ( 1 - sl), or (Sl - s2)/(1 - sl). In Figure 4a it shows a ch~mge of (0.25 - 0.5)/(1 - 0.25) = 0.33 for H 2 when A < 10. Increasing the softness from 25% to 50% will increase the acceptance ratio at heavy load, as we show in Figure 4b. In this figure, the improvement is defined as (A(s = 50%) - A(s = 25%))/A(s = 25%). Once again, we show t h a t soft requests have no effects on the acceptance ratio when < 10. At heavy load (e.g., 10 < A < 50), however, 10%-20% improvements for S1 and 5%-10% improvements for $2 are observed. The gap between the curves for S1 and H2 in Figure 4b indicates t h a t it is possible to develop other algorithms with different performance trade-offs to fill the gap. Due to the scaled-down effect of H2, we notice t h a t for H 2 the accept~mce ratio begins to decrease significantly when the scaled-down load roughly equals the engineered offered load (e.g., see Figure 3b for H 2 at = 20). By comparing Figure 2b with Figure 3b, it is also interesting to see t:hat doubling the softness (from s = 25% to s = 50%) can more than double the acceptance ratio improvement for S1 over H1.

52

Y.-B. LIN ET AL. l.O

0.8

0.6

0.4

"

HI S2 H2

0.2 5

10

15

20

25

30

35

40

45

50

arrival-rate

(a) 1.0 0.9 0.8

eL

8

0.7

,(t~

Sl HI

0.6 ~0.5

$2 H2

, .

5

10

15

20

25

30

35

40

50

45

arrival rate

1.0

0.9 0.8 0.7 0.6

-

Sl

*

$2

0.5 0.4

•

5

!

10

•

i

15

,

|

20

•

l

•

25

|

30

•

|

35

•

l

40

•

i

45

,

50

(c)

Fig. 3. Effects of various allocation algorithms (s = 50%).

arrival rate

ALLOCATING RESOURCES FOR SOFT REQUESTS

53

-0,I -0.2

-0.3 ---m----

~

"0,

S

•

S 0.3

~

,

•

lO ,

i

15

•

,

-

,

•

,

•

,

•

20 25 30 35 (a) Effects on the U t i l i z a t i o n

,

40

•

,

45

S1

•

HI

--

S2 H2

-0.4

•

50

arrival-rate

.

0.2

[]

Sl

I

HI

--

S2 H2

arrival rate

~

-0,2

~

-0.3

-0.4 /

5

.

.

10

.

.

15

.

.

2o

.

.

2s

.

.

.

3~

(c) Effects on the A l l ~ a t i o n

[]

Sl

•

S2

,

3'5

4o

~'s

5o arrival rate

Ratio

Fig. 4. Effects of softness (s = 50% vs. s = 25%) on performance measures.

54

Y.-B. LIN E T AL.

I m p r o v i n g the acceptance ratio is not without a cost. W h e n the softness gets larger, more requests are accepted with a close to the m i n i m u m number; therefore, as shown in Figure 4c, the allocation ratio at s = 50% gets lower. T h e degradation is much worse when the system load is heavy. Between $1 and $2, $1 has lower allocation ratio, since it acts p r e t t y much like H 2 (i.e., allocating only the m i n i m u m n u m b e r for accepted requests) when the system is heavily loaded.

4.3.

BATCH SIZE AND OFFERED LOAD

In Section 2.1., we mentioned one interesting observation regarding some derived p a r a m e t e r s - - A s long as p and 6 remain constant for the given values of s and p, changiflg the values of p r i m a r y parameters n, A, d, t, and w will have no effect on the performance measures. Figures 5 and 6 illustrate that. In these figures, only the results for $1 with s = 25% are presented; results for other algorithms and percentages of softness are similar. In Figure 5, we show t h a t with a constant batch size (6 = 5), the results of changing the offered load via different p r i m a r y parameters (e.g., capacity c = n / d , holding time t, and arrival rate A), plotted as different curves, are the same for the performance measures we are interested in. Note t h a t when A changes, the time-out period 7 must be adjusted accordingly to keep (5 = AT at 5 in the experiments. In Figure 6, we show t h a t the performance measures remain constant for different values of time-out period 7, once we have made appropriate adjustments at each time-out period to keep the offered load and the batch size c o n s t a n t - - p - 2 and 6 = 5. This p r o p e r t y is quite useful in our study. Instead of working with five p r i m a r y parameters, we are able to consider only various combinations of two derived parameters for a given s and p. Should the time each request stays in the module (i.e., from when it enters the front-end till it is either accepted or rejected) be no longer t h a n the time-out period T, then the batch size 6 represents the m a x i m u m nmnber of requests t h a t can coexist in the module (Little's result). However, in the cases where the message processing time is not zero, before being served by the server a request m a y have already expired for the reasons t h a t either the processing time is too long, the requests arrival is too frequent, or the time-out period is too short. Thus, in such cases the batch size no longer represents the m a x i m u m number of "concurrent" requests. Consequently, as we will show in the next section, performance measures cannot remain constant even if we fix p and 6.

ALLOCATING RESOURCES FOR SOFT REQUESTS

55

1.00

J

0.98

0.96

0.94

*

0.92

-0.90 1.0

1~s

2Jo

21s

(a)

Lo

31s

4.0

capacity holding time arrival rate

offered load

1.0 0.9'

..= ==

0.8 -

8_

0.7-

0.6-

S --

0.50.4 1.0

1's

210

21s (b)

Lo

£s

4,0

capacity holding time arrival rate

offered load

1.0 0.9 o

0.8 0.70.6-

w

O.S

-

0.4

1.0

1'.s

2:0

21s

3'.0

3:s

4.0

capacity holding time arrival rate

offered load

(e) Fig. 5. Effects of p r i m a r y p a r a m e t e r s on performance measures (5 is fixed at 5).

56

Y.-B. LIN E T AL. 1.0 -

.~

0.9.

~-

0.7-

:

=

:

utilization •

~.

--

•

acceptance r a t i o

•

allocation ratio

0.6 ttmeout

Fig. 6. Effects of fixed p and 5 on performance measures. At each time-out period, A is properly adjusted to keep p = 2 and 5 = 5. ~.~.

E F F E C T S OF NONZERO M E S S A G E PROCESSING TIME

S u p p o s e t h a t t h e message processing t i m e is in t h e range of 0 to 0.01 t i m e units. 4 For t h e s a m e d, n, t, a n d s as those p r e s e n t e d in Section 4.1, F i g u r e 7 shows how relative values of p, % a n d A can affect t h e p e r f o r m a n c e . In t h e s e e x p e r i m e n t s , we fix p and r at 0.01 t i m e unit and 0.5 t i m e unit, respectively. A is r a n g e d from 5 to 90 requests per each t i m e u n i t to reflect an offered load of 0.5 to 9. W h e n A is sufficiently large (e.g., g r e a t e r t h a n 70 requests p e r t i m e unit in our e x p e r i m e n t s ) , t h e average queue l e n g t h at P 1 is long e n o u g h such t h a t t h e t i m e each request takes, including w a i t i n g in t h e queue a n d being processed, is way over t h e t i m e - o u t period. As a result, o n l y a few r e q u e s t s will be c o n s i d e r e d by t h e server, a s i t u a t i o n similar to t h a t w h e n t h e a r r i v a l r a t e is low. F i g u r e 7a and c show m i r r o r images in t h e u t i l i z a t i o n a n d t h e a l l o c a t i o n r a t i o between high and low arrival rates. Moreover, t h o s e requests t h a t reach t h e server are likely to be a c c e p t e d , no m a t t e r which a l l o c a t i o n a l g o r i t h m is in use. Therefore, t h e a c c e p t a n c e r a t i o s of various a l g o r i t h m s converge at high arrival rates, as shown in F i g u r e 7b. A c c o r d i n g to our definition of t h e offered load p, t h e r e are ways to increase t h e offered load in our study. We can increase t h e arrival r a t e A, increase t h e holding t i m e t, or decrease t h e s y s t e m c a p a c i t y c either b y increasing t h e average desired n u m b e r d or by r e d u c i n g t h e n u m b e r of s y s t e m resources n. Since changing n , d , or t will n o t affect t h e queue l e n g t h at P 1 , we can e x p e c t t h a t increasing p by ways of changing rz, d, or t s h o u l d not have t h e s a m e results as t h o s e shown in F i g u r e 7. In o t h e r words, 4Assuming 10,000 instructions per message processing, and the unit of time is seconds, p = 0.01 implies a processing power of 1 MIPS.

ALLOCATING RESOURCES FOR SOFT REQUESTS -

1.0

-

=

-

=

57

-

0.8

0.6 =

0.4

0.2

0.0

,

5 1.0-

1S

.

25

,

,

35

,

.

45

,

,

55 (a)

,

.

65

,

,

75

,

.

85

=

$ I

t =

HI $2 H2

,

95

arrival r a t e

-

0.8 ._e 0.6

0.4 0.2

0 . 0

.

5

,

.

15

,

.

25

,

.

35

,

.

45

,

.

55

,

.

65

,

.

75

,

.

85

=

$1

!

HI $2 H2

,

95

arrival r a t e

(b) 1,0 --

0.9'

0.80.7-

0.6-

0.5

•

5

,

15

,

,

25

,

,

35

,

,

45

•

,

55

,

,

65

,

,

7S

,

,

85

,

m

$I

•

$2

,

95

arrival r a t e

(c)

F i g . 7. E f f e c t s o f n o n z e r o m e s s a g e p r o c e s s i n g t i m e (p = 0 . 0 1 , ~- = 0.5, a n d s = 2 5 % ) .

58

Y.-B. LIN ET AL.

depending on whether they will alter the queueing effects at P1, different ways of achieving the same p can have different performance results when p is sufficiently large. Thus our statement in the previous section about the nice property of derived parameters p and A holds only if p and A are within certain ranges, respectively. Our experiments suggest that when p < 7 and T > 0.1, the performance measures are affected only by different values of p and A, given p = 0.01. Although the results are not shown in this paper, we also found that when p is sufficiently small (e.g., p < 0.001), each algorithm performs as well as if when p = 0 up to a very high arrival rate (e.g., 100 requests per time unit). Therefore, for parameters in the reasonable ranges, we can safely assume in our study that the message processing takes zero time. The above discussion is due to the fact that all request messages are processed in the FIFO order at P1. To improve the acceptance ratio and the utilization, a LIFO (least-in-first-out) strategy (i.e., to process the most recent request arrival on a non-preemptive basis) may be more adequate. 4.5.

E F F E C T S OF B A T C H SIZE

In Section 4.3, we have shown that, given s,p, and p, the batch size determines the performance of an algorithm. This section describes how the performance measures are dependent upon ~ in different algorithms. Figure 8 presents the results of comparison for the utilization and the acceptance ratio at two different ~'s, ~ = 0.5 and ~ = 5. 5 In Figure 8a, the improvement of the utilization with respect to 6 for each offered load Pi, :2b/6(pi), is defined as z u ~ ( p ~ ) = u ( ~ = 5, p = ~ ) - u ( ~ = 0.5, ~ = p~) u ( 6 = o.5, p = ¢~)

Z~4~(p~), the improvement of the acceptance ratio, is equivalently defined and presented in Figure 8b. From these figures, it is evident that changing has almost no influence (<0.3%) on the utilization. However, the acceptance ratio is improved significantly for a larger batch size. Intuitively, a larger batch size results in more requests waiting to be accepted by the server; hence the server has a better chance to accept one or two requests each time some resources are returned to the module. One interesting note 5For simplicity, t h i s is a c c o m p l i s h e d by keeping every p r i m a r y p a r a m e t e r c o n s t a n t e x c e p t t h e t i m e - o u t p eriod T. Not to be considered a d u p l i c a t e t o w h a t we will p r e s e n t in t h e n e x t section (i.e., t h e effects of different t i m e - o u t periods), we also s a m p l e d s o m e c o m b i n a t i o n s of A, n, d, a n d t, b u t found no s u b s t a n t i a l c h a n g e s to t h e r e s u l t s we p r e s e n t here. T h i s is not s u r p r i s i n g at all, given w h a t we have ob s e rve d in Section 4.3.

ALLOCATING RESOURCES FOR SOFT REQUESTS

59

0.020 0.016 0.012 0.008 0.004

!

Sl HI S2 H2

0.000

0.5

1.0"

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0 o f f e r e d load

(a) Effects on the Utilization 0.3

0.2

,= 0.1

-

Sl

-,~

S2 H2

HI

0.0 0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0 offered load

(b) Effects on the Acceptance Ratio 0.0

-0.1

-0.2

•"

SI 82

-0.3

•

0.5

Fig.

8.

measures.

Effects

|

1,0

•

,

•

|

•

|

•

|

•

|

•

,

1.5 2.0 2.5 3.0 3.S 4.0 (c) Effects on the Allocation Ratio

o f t','~,) b a t c h

s i z e s (6 =

5 over 6 =

0.5,

•

,

4.5

:; =

.

S.0 offered load

25%)

on performance

60

Y.-B. LIN E T AL. 1.0

v

0.9

o

0.8 0.7 0.6

$1 i-

0.5

0.4

•

0.5

,

1.0

•

i

1.5

•

|

•

2.0

i

2.5

•

|

•

3.0

|

3.5

•

,

4.0

•

i

4.5

H1 $2 H2

•

5.0 offered load

(a) B a t c h size = 0.5 1.0. 0.9

.-~

0.8

{

8

0.7

•~

0.6

I

--I

°'Sl

I I

1

O.4 ~

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

,',

$1

4

H1

"

sz .2

5.0 offered load

(b) Batch size = 5 1.0 0.9 Q

0.8

{

8

0.7

8

0.6

"~

-

°'sl

1

1 I

-

"

S1 m

s2

0.4 ~

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

(c) B a t c h size = 10

Fig. 9. Effects of 6 on the a c c e p t a n c e ratio.

5.0 offered load

A L L O C A T I N G RESOURCES F O R S O F T R E Q U E S T S

61

is t]mt the acceptance ratio increases despite a flat utilization performance, especially in the case of Algorithm H1 (which is independent of the softness). Apparently, increasing the batch size will favor smaller requests. In Figure 8b, we also observed that for all p,

Z.4~(p) for $1 > ZM~(p) for 5'2 > Z`4~(p) for H1 > Z`4e(p) for H2. This implies t h a t when 6 is increased, $1 provides more marginal improvement on the acceptance ratio than other algorithms do. Figure 9 shows thal; as 6 increases, the acceptance ratio curves for $1 and $2 move from the "lower bound" curve for H1 to the "upper bound" curve for H2. In Figure 9c, the curve for $1 is ahnost identical to that for H2. Note that the p wdues shown in Figure 9 are calculated at the engineered offered load. Since the utilization remains almost unchanged while the acceptance ratio improves significantly, we expect that increasing 6 will degrade the allo:ation ratio. Figure 8c shows the changes in the allocation ratio for $1 and $2 when 6 moves from 0.5 to 5.

~,.6.

EFFECTS OF TIME- 0 UT PERIOD

As we just discussed in the previous section, increasing the batch size could improve the acceptance ratio. Given an arrival rate, the only way to increase the batch size is to make the time-out period longer. However, the marginal improvement in the acceptance ratio must justify the cost of having a longer time-out period--larger buffer size in the module and longer waiting time for a decision. Figure I0 shows the effects of the time-out period on the acceptance ratio. Let us define Z`4,(pj), the improvements of the acceptance ratio with respect to the time-out period T for a given offered load pj, as zA.(pj)

=

=

=

¢j)

-

=

o,p

=

= 0, p =

In Figure 10a, we present the results for d = 1000, n = 1,200,000, t = 120, A = 20, s = 25%, p = 0, and T = .5, 1, 2, 4, 6, 8. Note that p = 2 in these experiments. This figure indicates that when z is small (i.e., 7- < 1), a large "marginal Z A , ( 2 ) " (i.e., oz.a.(2)~ o. j can be achieved by increasing z. When T > 1, increasing z provides little marginal improvement on .4. This implies t h a t a short time-out period is sufficient to boost the acceptance ratio. Among different algorithms, $1 performs the best, which

62

Y.-B. LIN ET AL. 0.4

0.3 0.2 Sl

$

f

0.1

•

HI

--

S2

0.0 timeout period

(a) Effects of varying timeout period at a specific offered load (=2)

1.0 0.8

0.6 =

0.4

----m--

Sl (s=0.2S) HI

sz (s=O.2S) Sl (s=O.S)

0.2 •

0.0

o.s?.o

,is-21o2;s-31o

Ls-,,io4'.s

$2 (s=O.S)

o,orodJo,d

(b) Effects of a specific timeout period (=1) at various offered load Fig. 10. Effects of time-nut period on the acceptance ratio.

is consistent with our observation in the previous section (note that the longer the time-out period, the larger the batch size). Figure 10b shows how the effects of time-out vary at different offered loads. The time-out period is fixed at 1 time unit. It shows that for the same time-out period, the improvement is more significant when the offered load is larger. It also shows that larger softness together with high offered load can almost double the acceptance ratio.

ALLOCATING RESOURCES FOR SOFT REQUESTS 5.

63

CONCLUDING REMARKS

We have presented a new perspective to the dynamic resource allocation problem, namely allocating resources for soft requests, and presented our event-driven simulation results. Four allocation algorithms for soft requests are ~tudied in this paper: H1 only allocates the m a x i n m m requested number; H 2 only allocates the minimum requested number; $1 tries to partially satisfy as m a n y requests as possible before fully satisfying any request; and $2 tries to fully satisfy as m a n y requests as possible before partially satislying any request. The results indicate that H1 has poor acceptance ratio in heavy load situations, and H2, despite its significant improvements over H1 in the acceptance ratio, behaves poorly in the utilization when the system is under the engineered offered load. The other two algorithms, especially S1, gracefully adapt to different system loads and achieve high acceptance ratio (as good as H2) and high utilization (as good as H1) at the cost of the allocation ratio. ~[he results suggest that a system can take advantage of soft requests to accept more requests in transient overload situations without having to physically increase the load-handling capacity of the system. Similarly, given a requirement on the minimmn acceptance ratio, a system need not be overengineered to handle less frequent heavy load situations. Both could be economical alternatives, especially when the needs for system resources grow rapidly and become difficult to anticipate. Note that with a steady system load, $1 and $2 can accept more requests than H1 can, but cannot outperform H1 in the utilization measure. Whether algorithms such as $1 can yield better resource utilization in a bursty load is a subject for further investigation. In our event-driven simulation results, we also showed t h a t increasing the ,~of~ness is better for enhancing the acceptance ratio than for improving utilization, and that a short time-out period (and thus a small batch size) is sufficient to boost the acceptance ratio. Trade-offs (marginal imp r o w m e n t s in the acceptance ratio vs. larger buffer size in the module and longer waiting time for a decision) must be considered before a t t e m p t i n g to increase the time-out period. An interesting observation has significantly reduced the p a r a m e t e r space to be investigated in our study: Given a softness and a message processing time, the performance measures depend only upon the two derived parameters, batch size and offered load, rather than five primary input parameters, when the queueing effects for incoming messages are not overwhelming. B~sed upon our results, it appears that $1 has the best performance: it yields more marginal improvements in the acceptance ratio than other algorithms when the batch size is increased (due to a higher arrival rate or

64

Y.-B. LIN E T AL.

a longer time-out period). However, it should be noted that $1 is primarily designed to improve the acceptance ratio at the cost of the allocation ratio by partially satisfying as many requests as possible first. In a marketplace where an allocation module must strike a balance between the acceptance ratio and the allocation ratio, different algorithms need to be developed to achieve different objectives. To an operating company, for example, if accepting a call generates a fixed amount of revenue and the quality of connection (in terms of the amount of bandwidth allocated to the call) has negligible effects on the customer satisfaction, then $1 is probably a good choice. On the other hand, if calls are charged based upon how closely the resources allocated match the desired amount, and/or the business in the future is strongly dependent upon how often soft requests are fully satisfied at the present time, then other algorithms may be more appropriate. More experiments are needed to understand the relationships between algorithms and trade-offs. As we mentioned, only one type of soft requests has been studied in this paper. In the future, we will consider requests that consist of multiple classes of resources, with priorities or constraints among different classes of resources. We will also look into the effects of soft requests on applications in which the holding time of each request is not a constant function over the amount it is granted. Examples of such applications are bulk data transfer and process scheduling, as we stated in Section 1. In a distributed system, resources are likely to be managed by several administrative domains. For the sake of fault tolerance and scalability, another challenge is to extend the present centralized model to a distributed system, and develop and study various resource allocation algorithms for soft requests.

The authors would like to thank Paul Wang, the reviewers, Ernst Biersack, Jane Cameron, Brian Coan, Gita Gopal, and Mario Vecchi for their many valuable comments on the earlier draft of this paper.

REFERENCES 1.

2. 3. 4.

A. Albanese, M. W. Garrett, A. Ippoliti, H. Idzapanah, M. A. Karr, M. Maszczak, and D. Shia, Overview of Bellcore METROCORE network, In Proceedings of the [EEE G L O B E C O M '88, Hollywood, FL, November 1988. Bellcore, Generic Requwements for the Public Switched DS1/Swztched Fractional DS1 Servzee Capability, June 1990. Technical Advisory TA-TSY-001068, Issue 1. Bellcore, Expanding public circuit switched services beyond 64 Kbps, Bellcore Dzgest of Technical Information 7(12) (March 1991). G . J . Foschini and B. Gopinath, Sharing memory optimally, IEEE Transactions on Communications COM-31(3):352-360 (March 1983).

ALLOCATING RESOURCES FOR SOFT REQUESTS 5.

6. 7. 8. 9.

10.

11. 12.

13. 14. 15. 16. 17.

65

G. Gopal, N. Griffeth, and A. Weinrib, Distributed implementation of real-time resource counters, In Proceedings of the IEEE I N F O C O M '91, 1991, pp. 04150425. D . S . Hirschberg, A class of dynamic memory allocation algorithms, Comrnunica~'.ions of the A C M 16(10):615 618 (October 1973). 'F. Ibaraki and N. Katoh, Resource Allocation Problems: Algorithmic Approaches, MIT Press Series in the Foundations of Computing, The MIT Press, 1988. M . I . Irland, Buffer management in a packet switch, IEEE Transactions on Com:nunications COM-26(3):328-337 (March 1978). ~. Jordan and P. Varaiya, Control of multiple service, multiple resource communication networks, In Processing of I E E E I N F O C O M '91, Bal Harbour, FL, April :991, Vol. 2, pp. 648 657. ]7. Kamoun and L. Kleinrock, Analysis of shared finite storage in a computer network node environment under general traffic conditions, IEEE Transactions on ~Jommunications COM-28(7):992 1003 (July 1980). D . E . Knuth, The Art of Computer Programming, 2nd ed., Addison-Wesley, Reading, MA, 1968, Vol. 1, pp. 435-455. "(.-B. Lin, S. Mohan, and A. Noerpel, Channel assignment strategies for hand-off ~Lnd initial access for a PCS network, IEEE Personal Communications Magazine ] (3):47-56 (1994). "(.-B. Lin, A. Noerpel, and D. Harasty, Sub-rating channel assignment strategy for hand-offs, Proc. I E E E I C U P C (1994). ~. D. C. Little, A proof for the queueing formula L = AW, Operations Research 9(3):383-387 (May 1961). V. Mak, DOSE: A modular and reusable object-oriented simulation environment, SCS Multieonferenee on Object-Oriented Simulation, 1991, pp. 3 11. M. Marini and A. Albanese, Management of an adaptable-bit-rate video service in ~ MAN environment, In SPIE's OE//FIBERS '90, San Jose, CA, September 1990. M. Maszczak, A. Albanese, A. Ippoliti, M. Modena, and S. Cucchi, Packet video in a MAN environment, In E F O C - L A N 90, Munich, June 1990.

Received 15 July 1993; revised 1 August 1994