The management applications make use of a set of man- agement services which we organise as four subsystems: the repository services subsystem, the con ...
A TESTBED FOR OPTIMIZING THE MONITORING OF DISTRIBUTED SYSTEMS H. ABDU, H. LUTFIYYA and M. A. BAUER Department of Computer Science The University of Western Ontario London, Ontario, Canada
Abstract Monitoring distributed systems is essential in maintaining reliability and correctness of their behaviour. However, inecient use of resources by monitoring can degrade the performance of the monitored system's components. We are especially interested in strategies to determine con gurations of management agents that allow for distributed data collection, analysis and the dynamic formulation of monitoring requests, with minimal performance degradation, and in conformance with user/system requirements. We present an algorithm that generates the optimal con guration for a given set of agents, managed objects and constraints. The algorithmis embeddedinto an optimizationtestbed. Experimental results are also presented. Keywords: monitoringoverhead, monitoringcon guration,monitoring queries, optimization
1 INTRODUCTION Distributed computing systems typically consist of large numbers of heterogeneous computing devices connected by communication networks, various operating system resources and services, and user applications running on them. These resources and applications are becoming indispensable to many enterprises, but as distributed systems become larger and more complex, more things can go wrong, potentially interrupting or crippling critical operations. Management applications are used to perform management tasks, such as system con guration, analysis of performance bottlenecks, report generation, visualisation of network or system activity, simulation, and modelling. The management applications make use of a set of management services which we organise as four subsystems: the repository services subsystem, the con guration services subsystem, the monitoring services subsystem and the control services subsystem.
The management services in turn interact with the management agents. Each management agent monitors and collects data about a set of managed objects. Agents decouple management applications from their managed resources. There are several standards for management protocols that de ne the communication between agents and management applications, including SNMP [1] and CMIP [2, 3]. The arrangement of management agents throughout a distributed system is referred to as a monitoring con guration. Existing management techniques are based on static monitoring con gurations. The monitoring con gurations need to be dynamic to accommodate changing user and system requirements. Monitoring con gurations sometimes
result in excessive use of resources that can lead to performance degradation (e.g. processing load, memory, disk, network trac), since resource availability and other system and user requirements are not taken into consideration. We use the term monitoring overhead to refer to the resource usage by monitoring. Researchers have recently begun to address these issues using di erent approaches. Earlier work (e.g. [4, 5, 6]) focusses on the control of the amount of data to be transferred from managed objects to management agents, by specifying queries. Queries are directives issued to management agents, specifying the managed objects to be monitored, the data to be collected and the analysis to be done on the collected data. The drawback is that they do not provide a means to dynamically formulate queries to the management agents. More recent approaches, such as in [7], provide a framework to dynamically change con guration of agents, as well as the data collected and/or analyzed , according to changes that may occur in the system. These approaches make use of mobile agents. We assume that all requests made by management application are issued to management agents in the form of monitoring directives. Our de nition of monitoring directives include synchronous polling done by management applications, as well as asynchronous events sent by managed objects to the management application. There are multiple con guration of agents that can execute a given set of directives. Currently, there are no algorithms that, for a given set of management agents and directives, minimize monitoring overhead based on a set of user requirements and resource availability. The goal of this work is to develop an algorithm such that, given a set of management agents, monitoring directives, constraints on resource usage and availability, and user requirements, will determine a monitoring con guration that minimizes overhead. In addition, the algorithm has the characteristic that if a new directive is added (or taken away) the algorithm will determine a new con guration based on the existing con guration, i.e. does not have to start all over. This paper is organized as follows. Section 2 describes a model for describing monitoring con guration costs. Section 3 describes the algorithm. Section 4 describes a prototype. Sections 5 and 6 describe the experimental design and results. Concluding remarks and future work are presented in Section 7.
2 A COST FUNCTION FOR CONFIGURATIONS There are di erent ways in which a given set of agents can be con gured to execute a monitoring directive [8]. For example, consider the following monitoring directive (for purpose of illustration, we use a very simple example): What is the average amount of memory used by processes p1 , p2 , p3 , p4 , p5 and p6 ? Figure 1 presents two examples of con gurations for this directive. - Agent
P
avg(m12,m34,m56) m34= avg(m3,m4) m12= avg(m1,m2)
m2
m1
m3
m4
m5
p2 p3
m56= avg(m5,m6)
m6 m1
p1
m2
m3
m4
m5
m6
p1
p2
p3
2
p4 p5 p6 (b)
Figure 1: Mapping to (a) single agent con guration (b) distributed con guration In Figure 1(a), the data collection and analysis is centralized in one agent. This agent could be a bottleneck when the number of managed objects is large. In Figure 1(b), we have an extra level of agents that compute the average of the memory values collected from their subtree. This reduces the execution time of the directive. However, there is a trade-o since there are more resources being used as the result of an increased number of agents. As the number of managed objects increases, the number of possible monitoring con gurations increases accordingly. The choice of a \good" con guration must take system and user requirements into account, as well as the monitoring directives to be executed. For example, some management applications may demand low response time from the monitoring system as their rst priority. Others require that network trac is minimized. Di erent requirements require di erent number and arrangement of management agents. Monitoring directives specify di erent information to be collected and analysis to be performed. Di erent operations require different types of agents. The type of agent has a direct e ect on the resources used from the system. For example, some agents execute complex analysis operations, while others include simple operations such as average and standard deviation. In case of synchronous polling, monitoring directives also specify the method and frequency of collecting data. The more frequent the polling, the more network bandwidth is used, increasing the cost of a given con guration. Monitoring directives and system/user requirements are examples of factors that a ect the monitoring overhead of a con guration. We measure this overhead by assigning costs to monitoring con gurations, as follows.
P
i
i;j
The cost associated with the nodes and edges of a graph is de ned by a cost function cost : V; E ! Z (Z is the set of integers) executed on its nodes and edges. The cost of node vi 2 V is de ned as follows:
De nition. cost(vi) = c (vi )+ c (vi )+ : : : + cn (vi ), where 1
p4 p5 p6 (a)
1
represents the set of nodes (i.e. managed objects and management agents), and E represents the data ow between nodes in V . There is an outgoing edge from node vi to node vj , represented by ei;j = (vi ; vj ), if and only if vi requests information from vj , or vj asynchronously sends data to vi. For example, if vi is an agent collecting information from a managed object represented by node vj , then there is an outgoing edge, ei;j , from vi to vj . Similarly, if vj is a process that noti es vi that it has timed out too many times, then there is an edge ei;j from vi to vj . The cost of a con guration MC is the sum of the costs associated with its nodes and edges, as follows: De nition.cost(MC) = v 2V cost(vi )+ e 2E +cost(ei;j )
- Managed Object
avg(m1, m2, m3, m4, m5, m6)
De nition. A monitoring con guration MC is de ned as a directed graph MC = (V; E ), where V = fv ; v ; : : : ; vn g
2
c1 ; c2 ; : : : ; cn are the costs associated with metrics that
measure overhead, such as CPU, memory and disk. An edge ei;j = (vi ; vj ) 2 E is associated with a variable representing the network trac between vi and vj . This cost is de ned as follows: De nition. cost(ei;j ) = c(ei;j ) where c represents network trac cost, that varies according to factors such as location of agents, type of collected data and polling frequency. Minimizing overhead consists of nding the monitoring con guration MC such that cost(MC ) is minimal. Minimizing the cost associated with all the attributes and considering all user requirements is not simple, as there are clear trade-o s. For example, assume that the user requirements ask for minimal directive execution time. Allocating agents in a binary-tree structure will execute a directive faster, but there will be an increased resource usage, especially network trac, due to the large number of agents and their interactions. We focus on minimizing the network trac produced by monitoring. Next section describes our algorithm.
3 ALGORITHM Determining the monitoring con guration that produces minimal network trac consists of nding the monitoring con guration MC = fV; E g such that the network traf c cost ( e 2E cost(ei;j )) is minimal, assuming that the following are given: AG = fa1 ; a2 ; a3 ; : : : ; an g is the set of n management agents. MO = fmo1; mo2; : : : ; momg is the set of m managed objects from which data has to be collected and analyzed. Req is the set of user requirements that determines constraints on the choice of monitoring con gurations. Examples include: (i) A managed object sends data to only one collector agent. (ii) A collector agent sends data to only one analysis agent. (iii) An analysis agent can collect data from a maximum of two agents.
P
i;j
D = fd ; d ; : : : ; dp g is a set of p monitoring direc1
2
tives. The above problem can be modelled as a minimization problem to be solved employing techniques used in Linear Programming (LP)[9].
3.1 MODELLING AS AN LP PROBLEM
Managed objects mo1 ; mo2 ; : : : ; mom are monitored by collector agents. Collector agents then pass the collected data to one or more analysis agents that perform partial or complete analysis, as speci ed in the monitoring directive. Analysis agents can, in turn, pass the partial results to another layer of analysis agents, etc. This can be represented by setting up the array shown in Figure 2. y
z aa1
zz21
.
zzn1
zz22
.
zz11 zz12
.
.
analysis agents
.
.
.
xyn1
mo1
xy12
xy22
.
.
.
xyn2
mo2
.
.
. .
.
zznn aak
zx1n
zx2n
managed objects
.
.
.
.
moi
xynm
mom x
.
xy1m xy2m . zz1n aa1 ac1 ac2 zz2n zx11 zx21 aa2 zx12 zx22 . . . . . . .
aan aan
xy21
.
aa2 .
xy11
.
.
acj
acn
zxn1 .
collector agents
.
zxnn
z
Figure 2: The minimal cost problem A point (i; j ) represented by the xy variables in Figure 2 represents the thcommunication between the j th managed object and the i collector agent, in the monitoring con guration. Next, the agents interact with each other to analyze the collected information. This is represented by the zx (collector-analysis communication) and zz (analysisanalysis communication) variables. These variables can be either 0 or 1, representing the absence or existence of an edge between corresponding nodes. The network trac is represented by costs associated with every edge in the resulting monitoring graph (cyij , cxij or czij ). Network trac is generated when two processes located in di erent hosts communicate over the network. Thus, if an edge connects nodes (managed object or agent) located in the same host, its cost is zero. If the nodes are located in di erent hosts, the edge has an associated non-zero cost that depends on factors already described. Finding the monitoring con guration with minimal network trac, using the structure de ned in Figure 2, consists of determining the values of each position in the array (that represents the edges to be created, and thus, the nodes to be included in the monitoring con guration) in such a way that the sum of their associated costs (cyij , cxij and czij ) is minimal, taking into consideration the requirements in Req. In an LP format, this is formulated as:
P
P
P
min f = ij cyij xyij + ij cxij zxij + ij czij zzij subject to Ax B
Where A and B are obtained by translating constraints given in Req into an equation format. For our sample Req, the resulting equations are the following: 1. ni=1 xyij 1, 8j; 1 j m - managed objects send information to not more than one collector agent. 2. nj=1 zxij 1, 8i; 1 i n - a collector agent sends data to only one analysis agent. 3. ni=1 zzij 2, 8j; 1 j n - an analysis agent collects data from a maximum of two agents.
P P P
Where n is the number of management agents and m is the number of managed objects. Note that these constraints result in a hierarchical structure. We do not restrict the problem to this type of con gurations, but we are focussing on it for sake of simplicity. This minimization problem belongs to a subset of LP problems known as 0-1 ILP (Integer Linear Programming), since the values assigned to its variables are either zero or one. ILPs are harder to solve than LPs. The simple method of solving the LP and rounding the solution to the closest integer does not always result in a feasible solution. Some of the well-known techniques currently used to solve ILPs include cutting plane, branch and bound and implicit enumeration. Implicit enumeration [10] enables the search for an optimal solution to start from an existing feasible solution (one that satis es all constraints, but that is not necessarily the optimal solution). This can drastically accelerate the search, especially for large number of variables. Since our problem is such that a feasible initial solution is very simple to determine (e.g. a single agent con guration, with all managed objects communicating with one agent), we chose this method over others.
3.2 THE METHOD OF IMPLICIT ENUMERATION
Implicit enumeration [10] may be considered a special case of the branch and bound algorithm, applied to 0-1 ILPs, where all solutions are enumerated but the vast majority are enumerated implicitly. Only a few are explicitly enumerated.
In an n-variable 0,1 problem there will be 2n possible solutions, most of which may be infeasible. The explicit enumeration consists of enumerating all possible solutions, rejecting those which are infeasible (those which violate one or more constraints) and selecting that feasible solution which minimizes (or maximizes)n the objective function. This involves generating all the 2 solutions and verifying the feasibility of each one of them. For larger n's this method can be very time and storage consuming. The implicit method, on the other hand, starts with one of the 2n solutions. If there are constraints violated by this initial solution, the algorithm selects a set of candidate variables that, if raised to 1, can bring about feasibility. A variable can be a candidate if it has a negative coecient in matrix vector A (due to the \" sign), and a cost c that, when added to the current value of f will not increase it more than a speci ed limit (determined by an upper bound for f ). If there is more than one candidate, the one with most negative coecient in A is chosen. f is updated by adding the coecient of the new variable, and the value of the variable is set to 1.
The above process is continued until a partial solution is fathomed, either by feasibility or in-feasibility. \Fathoming" occurs once a partial solution that cannot be completed in such a way as to avoid violating one or more of the constraints is found. For example, in a 3 variable (x1 ; x2 ; x3 ) problem, if the combination (0, 0, 1) is tested, and it is veri ed that none of the constraints can be satis ed with x3 = 1, then all the 4 solutions (22 ) having x3 = 1 have been implicitly enumerated and can be ignored, thus being fathomed. Similarly, once we nd a feasible completion of a partial solution we say that that partial solution is fathomed because no other completion of it is more attractive than that completion in which all other variables are equal to zero. In other words, all combinations where the current variables in the solution are equal to one have been implicitly fathomed. Thus, in a problem with 5 variables, if 2 variables are set to 1 in the feasible solution, then 2(5?2) possible solution have been implicitly fathomed. Once a solution is fathomed (due to feasibility or infeasibility), the algorithm \backtracks". Backtracking consists on fathoming a partial solution in which the last variable included in the current partial solution (xi ) is set to zero. This way all solutions are enumerated, since the solutions in which xi is set to 1 were already fathomed before backtracking.
agents (see Figure 4). Users can also set constraints to the problem, by selecting topology options (e.g. single agent, binary tree, etc.), depending on the resources available in the system, and by selecting the resource to be minimized (e.g. CPU, memory, network trac) (see Figure 6 and 5). Once the data is input, the application executes the enumeration algorithm, and returns the optimal con guration graph (see Figure 7).
Figure 4: Choosing location of managed objects
The algorithm ends when a new feasible solution is found during a backtracking due to feasibility, or if no more variables can be set to zero during backtracking. In the latter situation, the algorithm returns the last existing feasible solution. At any iteration of the algorithm, it is obvious by inspection of the current partial solution exactly how many and which solutions have been implicitly enumerated so far. It is clear that every time fathoming occurs, 2n?1 solutions have been implicitly enumerated. Thus, an optimal solution can be found in very few steps. In case of recon guration due to changes in the system (e.g. adding/removing an agent or a managed object, or changes in resource availability) the algorithm nds a new optimal con guration, using the existing one, instead of redoing all previous computations. main()
backtrack()
begin feasible = 0 while not optimal do begin if there are violated constraints in A then begin look for candidate to bring feasibility if no candidates then optimal = backtrack() else add new variable to solution end else feasible = 1 optimal = backtrack() end if feasible then return last feasible solution else no feasible solution end
begin
Figure 5: Topology options
if no elements to be complemented then return 1 else begin complement last non-zero element update function return 0 end end
Figure 3: Enumeration algorithm
4 PROTOTYPE The enumeration algorithm for minimizing network traf c is used as the basis of our Optimization Testbed. The Testbed consists of a Java application that enables users to specify the number and location of managed objects and
Figure 6: Resources to minimize
5 EXPERIMENT We carried out an experiment to test the e ectiveness of the formulated problem and algorithm. We compared the
of edges between managed objects and agents. There are a total of 48 ((10 3) + (3 3) + (3 3)) variables representing the possible edges in the monitoring con guration (X = fxy1148; : : : ; xy103 ; zx11 ; : : : ; zx33 ; zz11 ; : : : ; zz33 g), resulting in 2 possible con gurations. y
z zz11 zz21
Figure 7: The optimal con guration
(spud) aa1
zz31
(dada) aa2
zz32
zz22
Our monitoring system is based on the OSI Management Framework, where the CMIP protocol is used for agent-to-agent communications. We have two types of agents: a DCE Collector Agent and Statistics Agent. The DCE Agent is used to collect information from DCE application processes (we use a sample OSF DCE based distributed Linear Programming application). It has a CMIP Interface to communicate with the OSI environment and a DCE Knowledge Source that enables the use of DCE RPC to communicate with DCE application processes. The Statistics Agent analyzes the data collected by DCE agents. Currently, statistics agents support four operations: max, min, avg, and total. We use a distributed application management testbed, running on RS/6000 machines, to specify application processes to be managed and their location, the number of management agents and their location, and the interactions between all agents (i.e. monitoring con guration). Once the con guration is speci ed, the testbed provides means to start all the application processes, management agents and the directives issued to agents. The network trac produced by hosts was measured using the UNIX netstats utility. Our sample monitoring system consists of DCE collector agents, analysis agents, and application processes that can be con gured to run in three RS/6000 machines (dada, kimchi and spud). We vary the number of managed objects (i.e. 2; 4; 6; 8 and 10) for each set of experiments. The optimization algorithm was executed for each set of managed objects, and the corresponding optimal con guration was compared to three other con gurations: single agent, \expensive", and binary con guration. In the single agent con guration, one centralized agent collects information from all the managed objects. In the \expensive" con guration, all the edges in the graph are between agents and managed objects in di erent hosts. The binary con guration has the feature of limiting the number of outgoing edges from an analysis agent to a maximum of two. The comparison between con gurations was done in terms of the number of packets remotely transmitted during monitoring. For example, consider the input with 10 managed objects. Figure 8 shows the possible combination
zz13 zz23
(kimchi) aa3
network trac generated by our \optimal" con guration with the trac generated by other possible con gurations.
zz12
xy21 xy22
xy31 xy32
mo1 (spud) mo2 (spud)
xy13
xy23
xy33
mo3 (spud)
xy14
xy24
xy34
mo4 (spud)
xy15
xy25
xy35
mo5 (dada)
xy16 xy17
xy26 xy27
xy36 xy37
mo6 (dada) mo7 (dada)
xy18
xy28
xy38
xy19
xy29
xy39
mo8 (kimchi) mo9 (kimchi) mo10 (kimchi) x
xy1 10 xy2 10 x y3 10 ac1(spud) ac2 (dada) ac3 (kimchi)
aa1 (spud)
zz33
xy11 xy12
zx11 aa2 (dada)
zx12
zx21 zx22
zx31
zx32
(kimchi) aa3 zx13
zx23
zx33
z
Figure 8: A sample input for the optimization algorithm The solution given by the enumeration algorithm was
X = f100100100100010010010001001001100010001000101
000g, which corresponds to the \optimal" con guration shown in Figure 9(b). The other con gurations are also illustrated in Figure 9 (a, c and d). The main di erence between (b) and (d) is that, in (d), the managed objects located in a given host send their information to a collector agent located in a remote host, as opposed to an agent in the same host (as in (b)). The graph in Figure 10 illustrates the network trac (in number of packets) that monitoring generates in the system. It also shows that the network trac was a ected by simply switching the location of agents from the \optimal" con guration in Figure 9(b) to the \expensive" con guration in (c). 111 000 - Managed Application Process 000 111 000 111 k
- DCE Management Agent sp
Kimchi
- Statistics Management Agent
Spud
d - Dada
(b) ‘‘optimal’’
(a) ‘‘single agent’’
d
d
sp
k
d
sp
sp
sp
sp
k
k
k
(c) ‘‘binary’’
d
d
sp
d
d
sp
sp
sp
k
d
d
d
d
d
k
d
k
k
k
k
d
sp
k
k
d
00 11 000 11 111 00 11 000 111 00011 111 00 11 00011 111 00 11 000 111 00 11 11 00 000 111 00 000 111 000 111 00 000 111 00 000 111 00 00 11 000 111 00 000 111 000 111 00 000 111 00 00011 111 00 11 00 11 000 11 111 00 11 000 111 00011 111 00 11 00011 111 00 11 sp
sp
k
sp
sp
sp
(d)‘‘expensive’’
sp
k
00 11 000 11 111 00 11 000 111 00011 111 00 11 00011 111 00 11 000 111 00 11 11 00 000 111 00 000 111 000 111 00 000 111 00 000 111 00 00 11 000 111 00 000 111 000 111 00 000 111 00 00011 111 00 11 00 11 000 11 111 00 11 000 111 00011 111 00 11 00011 111 00 11
1 0 000 111 0 1 1 0 0 1 00 11 00 11 000 111 0 1 00 11 0 1 000 111 0 1 0 1 1 00 00 11 000 111 1 00 0 0 1 000 111 0 0 0 1 0 11 1 00 11 00 11 000 111 0 11 1 11 00 0 1 0001 111 0 1 1 0 0 1 1111 00 00 000 111 sp
d
sp
00 11 00 11 00 111 000 000 111 000 111 00 00 00 00 0011 11 0011 11 00 11 00011 111 00011 111 00011 111 0011 11 0011 11 00 11 00 11 00 00 00 000 111 000 111 000 111 00 00 00 00 0011 0011 00 11 00011 111 00011 111 00011 111 0011 11 0011 11 00 11 sp
sp
sp
sp
d
d
d
k
k
k
k
Figure 9: Di erent con gurations with ten managed objects
#pck (K)
28 26 24 22 20 18 16 14 12 10 8 6 4 2
01 10
single agent binary
Factor Contribution
expensive optimal
Number of - 32.1% managed objects Monitoring - 49.7% Configuration
01 1010 10 2
01 1010 10 4
01 1010 10 6
(a)
01 1010 10 8
0110 1010 10
10
Combination - 15% of both factors Errors - 3% (and system specific factors) # mo
(b)
Figure 10: Network trac generated by monitoring The measured network trac was not only due to monitoring, but also due to the monitored application itself, and other activities in the system. Due to the dynamic nature of distributed systems, resulting in constant uctuations in network trac values and other resources, there were many outliers that a ected our nal results. Finding adequate techniques to isolate these outliers, and to overcome the problem of uctuating values is our next step. Figure 10(b) illustrates the e ect that the di erent contributing factors (i.e. monitoring con guration, managed objects, errors) had on the network trac produced by monitoring. We also observed a trade-o between network trac and other resource usage, such as the amount of memory used by agents. This con rms the fact that monitoring overhead involves di erent metrics, and the choice of what resource is to be minimized is a trade-o decision that depends on user and system constraints.
6 CONCLUDING REMARKS We motivated the need for minimizing the cost of monitoring by considering user requirements and monitoring directives. We presented an algorithm that determines an optimal con guration for a given set of agents, managed objects, directives and user requirements. The algorithm is part of our optimization testbed, which enables users to specify constraints to the optimization algorithm, such as the resources to be minimized, and the type of con guration to be selected (according to resource availability). The algorithm and our assumptions on the e ects of monitoring were con rmed through experiments. We focussed on network trac, and are currently working on minimizing CPU and memory usage. We observed the need of ecient techniques to assign cost functions to the communication between agents and between agents and managed objects, by taking into account dynamic and random nature of distributed systems. We believe that this work is an important contribution towards minimizing the cost of monitoring. There are, however, some facts that still need to be investigated, and are part of our future research. These include the cost of optimization, how frequent it should be done, and how costly it is to dynamically recon gure the system.
References [1] A.Ben-Artzi, A. Chandna, and U. Warrier. Network management of TCP/IP networks: Present and future. IEEE Network Magazine, pages 35{43, July 1990. [2] ISO. Information processing systems - open systems interconnection - basic reference model - part 4: Management framework, 1989. ISO 7498-4, Geneva. [3] ISO. Information processing systems - open systems interconnection - systems management overview, 1992. ISO 10040, Geneva. [4] G. Goldszmidt, S. Yemini, and Y. Yemini. Network management by delegation - the MAD approach. In Proceedings of the 1991 CAS Conference, pages 347{ 359, 1991. [5] D. Ogle, K. Schwan, and R. Snodgrass. Applicationdependent dynamic monitoring of distributed and parallel systems. IEEE Transactions on Parallel and Distributed Systems, 4(7):762{778, July 1993. [6] R. Snodgrass. A relational approach to monitoring complex systems. ACM Transactions on Computer Systems, 6(2):157{196, 1988. [7] A. Liotta, G. Knight, and G. Pavlou. Modelling Network and System Monitoring Over the Internet with Mobile Agents. IEEE/IFIP Network Operations and Management Symposium Conference Proceedings, pages 303 { 312, 1998. [8] H. Abdu, H. Lut yya, and M. Bauer. Investigating Monitoring Con gurations. Proceedings of the 1996 ACM Symposium on Applied Computing, pages 366{ 373, 1996. [9] D. G. Luenberger. Linear and Nonlinear Programming. Addison Wesley, 1984. [10] D. R. Plane and C. McMillan. Discrete Optimization. Prentice-Hall Inc, 1971.
