Abstract:

Techniques are disclosed for optimizing schedules used in implementing
plans for performing tasks in data processing systems. For example, an
automated method of negotiating for resources in a data processing
system, wherein the data processing system comprises multiple sites,
comprises a negotiation management component of a computer system at a
given one of the sites performing the following steps. One or more tasks
from at least one source of one or more plans are obtained. Each plan is
annotated with one or more needed resources and one or more potential
resource providers at one or more sites in the data processing system. An
optimized resource negotiation schedule based on the one or more obtained
tasks is computed. The schedule comprises an order in which resources are
negotiated. In accordance with the optimized resource negotiation
schedule, a request for each needed resource is sent to the one or more
potential resource providers such that a negotiation process is performed
between the negotiation management component and at least one of the
potential resource providers.

Claims:

1. An automated method of negotiating for resources in a data processing
system, wherein the data processing system comprises multiple sites, the
method comprising a negotiation management component of a computer system
at a given one of the sites performing the steps of:obtaining one or more
tasks from at least one source of one or more plans, each plan being
annotated with one or more needed resources and one or more potential
resource providers at one or more sites in the data processing
system;computing an optimized resource negotiation schedule based on the
one or more obtained tasks, wherein the schedule comprises an order in
which resources are negotiated; andin accordance with the optimized
resource negotiation schedule, sending a request for each needed resource
to the one or more potential resource providers such that a negotiation
process is performed between the negotiation management component and at
least one of the potential resource providers.

2. The method of claim 1, wherein when an agreement is reached between the
negotiation management component and the potential resource provider, the
negotiation management component sends the agreement to the task source
from which one or more plans were obtained such that at least one of the
one or more plans are executable using the negotiated agreement.

3. The method of claim 1, wherein the negotiation management component
comprises a scheduler and a proposal generator such that the scheduler
performs the plan obtaining step and the optimized resource negotiation
schedule computing step, and the proposal generator performs the request
sending step in accordance with the optimized resource negotiation
schedule.

4. The method of claim 1, wherein the optimized resource negotiation
schedule is computed in accordance with at least one of a cost constraint
and a time constraint.

5. The method of claim 4, wherein the cost constraint comprises a reserve
price for obtaining resources required for at least one candidate plan.

6. The method of claim 2, further comprising the step of the negotiation
management component revoking a negotiated agreement with a resource
provider subject to a given penalty.

7. The method of claim 6, wherein the penalty is dependent on time.

8. The method of claim 6, wherein the penalty is independent of time.

9. The method of claim 6, wherein the penalty is dependent on which party
revokes the agreement.

10. The method of claim 1, wherein the optimized resource negotiation
schedule is computed for a single plan.

12. The method of claim 1, wherein the step of computing the optimized
resource negotiation schedule further comprises performing a voting-based
methodology in accordance with a given resource set.

13. The method of 12, wherein the voting-based methodology further
comprises searching on a subset of the given resource set and deriving
the optimized resource negotiation schedule for the given resource set
based on a result of searching the subset.

14. The method of claim 1, wherein the step of computing the optimized
resource negotiation schedule further comprises performing a weight-based
methodology in accordance with a given resource set.

15. The method of claim 14, wherein the weight-based methodology comprises
computing a weight for each resource in the given resource set.

16. The method of claim 15, wherein the computed weight for a resource is
a representation of how the given resource affects the optimized resource
negotiation schedule.

17. The method of claim 16, wherein the computed weight for a resource
depends on a cost, a probability of success, and a frequency in all plans
for the resource.

18. The method of claim 1, wherein negotiation comprises multiple rounds,
each round being for one particular resource, and such that an agreement
may be revoked based on latest negotiation results.

19. Apparatus for negotiating for resources in a data processing system,
wherein the data processing system comprises multiple sites, the
apparatus comprising:a memory; anda processor coupled to the memory and
configured to: obtain one or more tasks from at least one source of one
or more plans, each plan being annotated with one or more needed
resources and one or more potential resource providers at one or more
sites in the data processing system; compute an optimized resource
negotiation schedule based on the one or more obtained tasks wherein the
schedule comprises an order in which resources are negotiated; and in
accordance with the optimized resource negotiation schedule, send a
request for each needed resource to the one or more potential resource
providers such that a negotiation process is performed between the
negotiation management component and at least one of the potential
resource providers.

20. An article of manufacture for negotiating for resources in a data
processing system, wherein the data processing system comprises multiple
sites, the article comprising a computer readable storage medium
including one or more programs which when executed by a computer system
perform the steps of:obtaining one or more tasks from at least one source
of one or more plans, each plan being annotated with one or more needed
resources and one or more potential resource providers at one or more
sites in the data processing system;computing an optimized resource
negotiation schedule based on the one or more obtained tasks, wherein the
schedule comprises an order in which resources are negotiated; andin
accordance with the optimized resource negotiation schedule, sending a
request for each needed resource to the one or more potential resource
providers such that a negotiation process is performed between the
negotiation management component and at least one of the potential
resource providers.

Description:

FIELD OF THE INVENTION

[0002]The present invention relates to data processing systems and, more
particularly, to techniques for optimizing schedules used in implementing
plans for performing tasks in such data processing systems.

BACKGROUND OF THE INVENTION

[0003]In cooperating data processing systems such as grid-based systems
and collaborative streaming analysis systems, autonomous sites in the
system can establish "agreements" there between to arrange access to
remote resources for a period of time. For example, A. Andrieux et al.,
"Web Services Agreement Specification (WS-Agreement)," Version 2006/07,
GWD-R (Proposed Recommendation), Grid Resource Allocation Agreement
Protocol (GRAAP) WGGRAAP-WG, July 2006, the disclosure of which is
incorporated by reference herein, describes a protocol for establishing
such agreements. The determination of which resources to reserve to
accomplish a task need not be known a priori, because multiple plans for
accomplishing the same task are available and they may require access to
different resources.

[0004]Given a processing task, multiple functionally equivalent plans can
be generated, e.g., through a planner component at a site. Each plan
requires a set of resources, possibly from other sites in the system. The
site can use any candidate plan to accomplish the processing task, with
different performance/cost tradeoffs. To deploy a plan, the site needs to
obtain all the resources required by that plan. It makes agreements with
other sites, which control access to their resources. These agreements
need to be negotiated between sites before the plan can be executed.

SUMMARY OF THE INVENTION

[0005]Principles of the invention provide techniques for optimizing
schedules used in implementing plans for performing tasks in data
processing systems.

[0006]For example, in one embodiment of the invention, an automated method
of negotiating for resources in a data processing system, wherein the
data processing system comprises multiple sites, comprises a negotiation
management component of a computer system at a given one of the sites
performing the following steps. One or more tasks from at least one
source of one or more plans are obtained. Each plan is annotated with one
or more needed resources and one or more potential resource providers at
one or more sites in the data processing system. An optimized resource
negotiation schedule based on the one or more obtained tasks is computed.
The schedule comprises an order in which resources are negotiated. In
accordance with the optimized resource negotiation schedule, a request
for each needed resource is sent to the one or more potential resource
providers such that a negotiation process is performed between the
negotiation management component and at least one of the potential
resource providers.

[0007]When an agreement is reached between the negotiation management
component and the potential resource provider, the negotiation management
component may send the agreement to the task source from which one or
more plans were obtained such that at least one of the one or more plans
are executable using the negotiated agreement.

[0008]The negotiation management component may comprise a scheduler and a
proposal generator such that the scheduler performs the plan obtaining
step and the optimized resource negotiation schedule computing step, and
the proposal generator performs the request sending step in accordance
with the optimized resource negotiation schedule.

[0009]These and other objects, features and advantages of the present
invention will become apparent from the following detailed description of
illustrative embodiments thereof, which is to be read in connection with
the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010]FIG. 1 illustrates a data stream processing system environment with
negotiation management implemented therein, according to an embodiment of
the invention.

[0011]FIG. 2 illustrates a negotiation management component, according to
an embodiment of the invention.

[0012]FIG. 3 illustrates a voting-based negotiation scheduling algorithm
for individual plans, according to an embodiment of the invention.

[0013]FIG. 4 illustrates a negotiation scheduling algorithm for multiple
plans, according to another embodiment of the invention.

[0014]FIG. 5 illustrates an initialization step of the negotiation
scheduling algorithm in FIG. 4, according to an embodiment of the
invention.

[0015]FIG. 6 illustrates a computer system in accordance with which one or
more components/steps of negotiation management techniques may be
implemented, according to an embodiment of the invention.

DETAILED DESCRIPTION

[0016]While illustrative embodiments of the invention will be described
below in the context of a collaborating, autonomous data stream
processing system, principles of the invention are not limited thereto.
That is, principles of the invention are more generally applicable to any
data processing environment in which improved negotiation scheduling is
desirable. That is, the proposed heuristics described herein can be
applied in scheduling for resource acquisition in many other application
domains, by way of example but not limited to, multi-agent manufacturing
systems, autonomic and service oriented computing, dynamic web/grid
service composition, virtual chain management, workflow, and enterprise
integration.

[0017]Furthermore, it is to be understood that the phrase "optimized
resource negotiation schedule" (or "optimized schedule" or similar forms
thereof) is intended to refer to a schedule that is determined using one
or more of the heuristics described herein, and is also intended to
include the "optimal schedule" if such an ideal schedule is so attainable
given the circumstances.

[0018]Accordingly, in one illustrative embodiment, we propose a
negotiation management (NM) system, which is a subcomponent of a
collaborative stream processing system. One example of a collaborative
stream processing system is the CLASP system disclosed in M. Branson et
al. "CLASP: Collaborating, Autonomous Data Stream Processing Systems," In
Proc. of the ACM/IFIP/USENIX 8th International Middleware
Conference, pp. 348-367, 2007, the disclosure of which is incorporated by
reference herein. However, it is to be understood that principles of the
invention are not limited to implementation in a CLASP system.

[0019]In a CLASP system, a job is an execution unit that accomplishes
certain work through stream analysis. A job takes the form of a
processing graph, comprised of resources, e.g., data sources and
processing elements (PEs), which are interconnected in a certain manner.
Examples of resources may include but not be limited to central
processing unit (CPU) processing power, memory, storage space, data
sources, processing code, etc. These resources might be located at
multiple different sites. Due to the potentially large numbers of data
sources and PEs needed in complex jobs, and the existence of functionally
equivalent processing graphs, it is infeasible for human users to
manually construct and identify the best alternative graph. The CLASP
system has a planner component that can construct processing graphs
automatically from high-level descriptions of desired results. Many
resources needed in plans are accessed exclusively and must be reserved
beforehand.

[0020]In order for a site to reserve a limited resource from another site,
it establishes an agreement with the other site, specifying the price of
sharing the resource. In general, the NM system proposed according to
principles of the invention conducts automated negotiation among multiple
sites in the data stream processing system to select the best candidate
sites with which to negotiate and then select the best execution plan
given the obtained agreements.

[0021]As will be described below in detail, illustrative principles of the
invention provide a negotiation management architecture that includes two
modules: a negotiation scheduler and a proposal generator. In general,
the scheduler receives a number of tasks, each of which is annotated with
the resources needed and potential resource provider sites. Also part of
each task, and thus also negotiated, are such things as cost, a
willingness to pay, and a deadline. The scheduler may adopt sequential
negotiation for obtaining agreements of resources. Given N resources to
accomplish a task, a site may negotiate one resource at a time, although
this is not a requirement. The scheduler sends a negotiation task to the
proposal generator, which will send requests to possibly multiple sites
that can provide the resource. The proposal generator of those sites will
either accept the request, or propose different terms (e.g., asking for a
higher price), upon which this site's proposal generator will send a new
request based on the terms. After possible multiple rounds of
back-and-forth request/proposal, finally an agreement is obtained from
one provider site, or no agreement is obtained from any site. The
scheduler will collect such negotiation results, i.e., the agreements,
and return them to whomever or whatever system submitted the tasks. Based
on the obtained agreements, one candidate plan should be selected and
executed to accomplish the task using the obtained agreements. Any
agreements that have been obtained but are not needed by the candidate
plan may at this point be canceled.

[0022]Canceling an existing agreement raises an important issue for
consideration in the negotiation management protocol. As described later,
the provider or consumer of a resource can "revoke" an agreement before
its negotiated termination date. In general, there is a monetary penalty
for revocation, which compensates the other party for the cost or
inconvenience of lost opportunity (for a resource provider) or an aborted
plan (for a resource consumer).

[0023]Advantageously, as will be shown, principles of the invention
optimize the total negotiation time and payment for making agreements and
revoking agreements given the task set. The scheduler reaches agreements
before the deadline approaches. The scheduler finds the set of favorable
agreements in terms of the cost of agreements. The scheduler considers
the penalty when it needs to revoke some agreements made before. One key
issue is the order in which requests for resources are sent to other
sites. It will determine the total time and budget actually spent.
Principles of the invention consider a number of factors to optimize the
order, including but not limited to, the cost of the resource, the
penalty of revoking an agreement after entering it, the existence and
length of a short grace period for revoking an agreement without penalty
when first establishing an agreement, the ability to reuse a resource
from one task to satisfy an alternative task, and other factors.

[0024]Turning now to the figures, FIG. 1 illustrates a data stream
processing system environment with negotiation management techniques of
the invention implemented therein. As shown, each "site" in the data
stream processing system comprises a NM component. Each site may be a
separate location, remote from another site. Alternatively, two sites may
be collocated. By way of example only, each site could be a separate data
center comprising multiple servers and memory devices or other
processing/storage devices that can be used to perform a requested task.

[0025]As shown in FIG. 1, site 1 is in communication with multiple other
sites (2 through N). Communication can be via a public network (e.g.,
Internet), a private network (e.g., local area network), or some
combination thereof. While each site may comprise many other components,
only components relevant to an understanding of the principles of the
invention are shown in FIG. 1.

[0026]Thus, site 1 (100) comprises NM component 102, site policy
management component 104, resource components 106, and planner component
108. For the sake of simplicity, the other sites in FIG. 1 illustrate
only their respective NM component, i.e., NM component 112 in site 2
(110), and NM component 122 in site N (120).

[0027]The site policy management module specifies site policies. Site
policies can be different for each site. Site policies define negotiation
settings for a site, e.g., the highest price of a resource, negotiation
strategies, etc. Once one or more site policies are set, the site acts in
accordance with its site policies. Further, each site comprises resource
components. While not limited thereto, resources components (or simply
"resources") may comprise data sources and processing elements (PEs).
Also, the planner component (or simply "planner") generates plans for
each task (job) to be performed by the site. It is to be appreciated
that, in one embodiment, the planner is implemented according to the
techniques disclosed in U.S. Patent Application No. 20080071716 entitled
"Apparatus and Method of Planning Through Generation of Multiple
Efficient Plans," the disclosure of which is incorporated by reference
herein. It is also to be appreciated that tasks depend on the particular
application being hosted on the resources, e.g., electronic commerce
applications, complex computation services, data mining services, etc.
Still further, one site may need one or more resources from another site
to perform its own tasks. As will be explained in detail, NM components
of different sites interact with each other to conduct negotiations for
needed resources.

[0028]To conduct negotiation, each NM component should have the following
information: 1) negotiation settings; 2) negotiation tasks; and 3)
resource usage information. In general, the information flows related to
an NM component include the following (referenced as information flows 1.
through 9. in FIG. 1).

[0029]1. Negotiation settings: NM checks out negotiation-related settings
(e.g., negotiation strategy) from its site policies. Data in the flow may
include information pertaining to the reserve price of each resource
(i.e., the highest amount of money the scheduler can use to establish an
agreement for that resource), how to make a concession (i.e., compromise
to bring the price of a resource closer to the other party), etc.

[0030]2. Request for resource availability: When NM receives an incoming
request for a resource, NM needs to check 1) whether its owner has such a
resource, 2) whether the resource is available for the particular
requesting site; and 3) when the resource will be available. Data in the
flow may include constraints on the resource, such as specific attributes
or times when it must be available. There are many ways to represent
constraints on a request, like whether the resource will be available
after 4 PM, whether the resource will be available between 4 PM to 7 PM,
etc.

[0031]3. Resource availability information: Resource components provide
information about resource availability to the NM component. The resource
availability information includes both the present availability and
future availability. Data in the flow may include information on whether
the resource is available and when it will be available and for how long.
Resource components may, for example, only need to list all the periods
during which the resource is not available.

[0032]4. Plans: After planning, the planner will send all the plans to the
NM component. The NM may find that some resource requirements can not be
satisfied at the local site, in which case it will negotiate with other
sites to make agreements. Here we assume that each site will reserve and
use its own resource if available rather than negotiating with another
site for the resource. However, this does not have to be the case. For
example, if other sites can provide the resource at lower cost, it may be
preferable to use that of other sites. Data in the flow may include
information pertaining to the identification of the PEs in each plan, how
the PEs connect to each other, and identification of a set of sites which
can run a specific PE.

[0033]5. Negotiation result: The NM will return negotiation results to the
planner after negotiation finishes or the negotiation deadline is
reached. Data in the flow may include failure of negotiation or a plan
with a set of agreements, each agreement corresponding to one resource in
that plan. Each agreement may have the following properties: negotiation
task ID, agreement ID, resource ID, agreed price.

[0034]6. Incoming request: Each NM may receive requests about resource
sharing from other sites. Data in the flow may include negotiation task
ID, sender site ID, unique identifying indices for a resource, and a
negotiation proposal, which consists of information about how to use a
resource and how much the requesting site is willing to pay.

[0035]7. Response to request: After receiving an incoming request, the NM
responds to the request based on resource availability and its
negotiation strategy. It may accept the request, reject the request, or
make a counter-offer proposal which includes an asking price for the
resource.

[0036]8. Outgoing request: If the resource requested is for a different
site's resource, it will make an outgoing request to other sites to
provide the resource. Data in the flow includes information similar to
that in flow 6.

[0037]9. Incoming response: Other sites' response. Data in the flow may
include information similar to that in flow 7.

[0038]It is to be appreciated that after an agreement is finally made, the
NM component reports the agreement to the subject resource components and
the subject resource components make updates accordingly, such as marking
the resource as reserved for the agreement's ID.

[0039]It is also to be appreciated that the above flows are for
illustration purposes only, and thus principles of the invention are not
intended to be limited to those flows or to their sequential order.

[0040]FIG. 2 shows details of an illustrative NM component 200.

[0041]Interface 202 provides the functions to be used by other components
and local modules to submit plans, resource availability information,
requests, etc. Further, as shown, the NM component has two main modules:
Scheduler 204 and Proposal Generator (PG) 206.

[0042]Scheduler 204 receives multiple plans from the planner (108) and
determines the best negotiation schedule, i.e., the order in which
resources are negotiated. Then the scheduler submits negotiation tasks
(NT) to PG 206 in that order. Each negotiation task asks for one resource
that appears in the plans. PG conducts sequential negotiations to get the
resources specified in negotiation tasks, thus yielding negotiation
results (NR). To be successful, the scheduler should satisfy all the
resources required by at least one plan within the cost and time
constraints specified for the plan.

[0043]Negotiation information is a data structure which stores the
negotiation tasks, incoming proposals, etc. Also, the scheduler stores
plan information and negotiation results from the PG. After a negotiation
is finished, the related information is moved from the negotiation
information structure to negotiation information log 208. The PG may
visit the information log to assist its decision making.

[0044]The remainder of the detailed description focuses on the
optimization problem of the scheduler, i.e., finding the best negotiation
schedule. The schedule determines whether any plan can be satisfied; if
so, which plan is satisfiable, and at what cost. Determining the
optimized negotiation schedule is non-trivial given multiple plans from
which to choose and multiple resources in each plan. The scheduler also
faces both time and budget constraints within which the negotiation
should finish. Moreover, the outcome of negotiated resources affects the
schedule of remaining resources, adding to the complexity of the problem.
Naive methods such as exhaustive search and randomized approach are
either too expensive ((n!) complexity) or yield low performance.

[0045]Advantageously, we propose heuristics that trade between complexity
and utility. We first provide a voting-based heuristic that reduces the
complexity to (mnq). We then present a weight-based heuristic which
has even less complexity (mn), with comparable utility. Experimental
results show that the proposed approaches achieve almost 50% higher
negotiation utility than a randomized approach and produce utilities
within 90% of that of the optimized schedule with reasonable plan sizes.

[0046]The remainder of the detailed description is organized as follows.
The optimization problem is introduced in Section I. Section II
introduces the voting-based heuristic and Section III presents the
weight-based heuristic.

I. Schedule Optimization

[0047]The optimization problem described herein can be treated as a
stochastic scheduling problem. Stochastic scheduling is concerned with
scheduling problems in which the processing times of tasks/jobs are
modeled as random variables. Thus the processing time of a job is not
known until it is complete. Our optimization problem is different from
most stochastic scheduling problems in that there are multiple candidate
plans for a task/job. In addition, the scheduler faces both deadline and
budget constraints.

[0048]As the scheduler (e.g., scheduler 204 shown in FIG. 2) has multiple
plans from which to choose and each plan has multiple resource
requirements, the scheduler needs to determine the order in which to
negotiate resources.

[0049]Some variables used in this formulation are summarized below:

[0050]τ scheduling deadline

[0051]δ the reserve price for the scheduling

[0052] plans submitted to the schedule

[0053] feasible plans at the scheduling round t

[0054] the set of resources in the plan PL

[0055]t(r) the negotiation time for getting resource r

[0056]c(r) the price for getting resource r

[0057]p(r) the probability that PG can get resource r successfully

[0058]Tt the resource in the negotiation task at round t

[0059]AGt the set of agreements at round t

[0060]The planner (e.g., planner 108 shown in FIG. 2) generates a set of
plans , and each plan is comprised of a set of resources. The resources
in plan PL are . Without loss of generality, we assume a resource appears
at most once in any single plan. However, our approach can be extended to
accommodate the situation that one resource appears more than once in a
plan. The planner will then submit the plans to the scheduler and ask the
scheduler to make agreements to satisfy the resource requirements of any
one of the plans. The planner will also specify: (1) the reserve price
δ, i.e., the highest amount of money the scheduler can use to make
agreements; and (2) the deadline τ, i.e., the longest amount of time
the scheduler can use to do scheduling and ask PG (e.g., proposal
generation module 206 shown in FIG. 2) to make agreements. In one
embodiment, the planner submits all plans to the scheduler at the same
time before scheduling.

[0061]After receiving plan(s) from the planner, the scheduler submits one
task (a resource) to PG. After receiving the negotiation result from PG,
scheduling enters the next round: the scheduler selects another task to
submit to PG. The result of a negotiation task could be "success," which
indicates that PG made an agreement, or "failure," which indicates that
PG failed to get the resource.

[0062]Resource consumers can revoke agreements made before at the cost of
paying a penalty. The penalty depends on the price of the agreement and
the period from the agreement making time to the revocation time. In
general, the higher the price, or the later the revocation of an
agreement, the greater the penalty. Assume the price of an agreement Ag
is Prc(Ag), the agreement making time is Tmk(Ag) and the agreement
revoking time is Truk(Ag). We assume a linear penalty function as a
function of price and duration: specifically, the penalty is
ρ(Prc(Ag), Truk(Ag)-Tmk(Ag))=min
(αPrc(Ag)(Truk(Ag)-Tmk(Ag)), Prc(Ag)), where
αε(0,1]. Other forms of penalty functions are possible but
we take this simple form in this illustrative embodiment.

[0063]The planner gives the reserve price (budget) to the scheduler, whose
goal is to minimize the spending for getting all the agreements for one
plan. The scheduler will report the scheduling result to the planner
before the deadline approaches. A scheduling result could be either a
"failure" notification or a plan with a set of agreements which can
satisfy resource requirements of the plan. The cost of the planner
includes the prices of the agreements for that plan and penalties
incurred by revocation. For ease of analysis, we treat the utility of the
planner as the utility of the scheduler. The scheduler attempts to
minimize the spending, thus maximizing its own utility, defined as:

u = { ( 1 + β ) δ - Prc ( ) - ρ ( )
- ρ ( ) ##EQU00001##

if scheduling succeeds otherwise where Prc() is the price of all
non-revoked agreements and ρ() is the penalty for revocation. When
scheduling succeeds, the scheduler needs to pay for agreements and
penalties and δ-Prc()-ρ() is a bonus for cost savings.
βδ is another bonus for successful scheduling; it ensures that
the scheduler gets some utility for succeeding, even it has spent all the
budget δ for negotiation. Without this extra bonus, a scheduler
that succeeds but spends all the budget gets zero utility, as if it had
done nothing at all.

[0064]If scheduling fails, the scheduler receives no bonus but needs to
pay for penalties. (Note that the maximum revocation penalty for any
agreement is the full price.)

[0065]PG receives two types of tasks from the scheduler: negotiation tasks
and revocation tasks. The scheduler has incomplete information about how
PG will behave given each negotiation task. Given a resource r,t(r) is
the expected negotiation time for getting resource r,c(r) is the price
for getting resource r, and p(r) is the probability that PG can get
resource r successfully. Without loss of generality, a resource in
different plans has the same t(r), c(r), and p(r). After receiving a
revocation task, PG will: (1) notify the other party involved in the
agreement; (2) pay a penalty to the other party; (3) report to the
scheduler. For ease of analysis, here we assume that: (1) revocation
tasks cost PG no time; (2) each negotiation task involves only one
resource; and (3) PG can only negotiate for one resource at each time.
Therefore, the scheduler can submit another task if and only if PG
finishes the previous task.

[0066]After receiving plans from the planner, the scheduler has the
following choices: (1) submit a negotiation task to PG if it can
presumably earn positive utility by scheduling; and (2) report "failure"
to the planner if the scheduler finds that it could not schedule any plan
within the reserve price δ and scheduling deadline τ. The
following observation shows the conditions under which the scheduler will
return "failure" directly at the beginning of scheduling:

the scheduler will directly return failure information to the planner, as,
in the first case, it is impossible for the scheduler to find a plan with
agreements within the given scheduling time, and, in the latter case, NM
cannot gain any positive utility.

[0068]Feasible plans refer to the set of plans whose resource requirements
can still be possibly satisfied by future negotiation. Assume PG fails to
reach an agreement for resource r, all plans which include the resource r
will become infeasible. Therefore, the feasible resource set at
scheduling round t has the following property: . After getting the
feedback from the PG at scheduling round t, the scheduler has the
following four choices: [0069]Submit another negotiation task to PG: If
no plan's resource requirements have been satisfied and there is an
opportunity to get all agreements for the resource requirements of one
plan, the scheduler may submit a new negotiation task to PG. If one
plan's resource requirements have been satisfied, the scheduler can still
submit a negotiation task in order to satisfy the resource requirements
of a better plan with lower cost. [0070]Revoke one or more agreements: As
scheduling continues, some agreements may become unnecessary. For
example, resource r and r' appears and only appears in plan PL. If PG
fails to get resource r, plan PL is unfeasible. Then the agreement for
resource r' becomes unnecessary. Unnecessary agreements should be revoked
as early as possible to minimize penalty. [0071]Return a plan with
agreements to the planner: Once all the resource requirements of one plan
have been satisfied and there is no opportunity to satisfy the resource
requirements of a better plan, the scheduler will return the plan with
agreements to the planner and stop scheduling. [0072]Return "failure" to
the planner: If the budget constraint or the deadline constraint makes
the scheduler unable to satisfy the resource requirements of any plan,
the scheduler will return "failure" to the planner and stop scheduling.

[0073]A naive way to calculate the optimized schedule is by exhaustive
search. If there are n resources in all the plans, the complexity of
exhaustive search is (n!). An alternative is to randomly choose a
resource to negotiate during each scheduling round. Although the
randomized approach has low complexity (1), its scheduling results may be
far from optimal. Principles of the invention therefore propose a
voting-based approach and a weight-based approach to allow tradeoffs
between complexity and utility.

II. Voting-Based Algorithm

[0074]As the complexity of exhaustive search factorially increases with
the number of resources in the plans, it is infeasible to run the
exhaustive search to find out the optimized schedule. To permit tradeoffs
between the high complexity and utility, this section presents a
voting-based approach which performs exhaustive searches on small
resource sets and derives the negotiation schedule for large resource
sets based on the search results.

[0075]A. Algorithm for Single-Plan Case

[0076]We begin with a simpler version of the problem in which there is
only one plan PL, i.e., ={PL}. At each step of scheduling, the scheduler
needs to find out the next resource to be submitted to the PG for
negotiation. The set of resources having not been negotiated at
scheduling round t is RTt(PL)=-∪t'=0t-1 Tt',
where Tt' is resource submitted at round t'. RT0 (PL)=.
|RTt(PL)|=||-t is the number of resources in RTt(PL). At round
t, the scheduler finds the optimized schedule Λot
εΛt in which Λt represents all the
possible schedules at round t and Tt' () is the negotiation task at
round t' according to the schedule εΛt. If
negotiation for resource Tt-1 fails, PL's resource requirements
cannot be satisfied and the scheduler will stop scheduling and revoke all
agreements made before.

[0077]Given a schedule at round t, the expected utility while conducting
the schedule is U ()=Usuc()-Pfail() where Usuc() is the
utility of the scheduler when it gets all resources and Pfail is the
penalty the scheduler needs to pay if scheduling fails. We have:

[0079]It can be found that any schedule εΛt has the
same Usuc() because changing the order of resources in any schedule
has no effect on Usuc(). Thus, the schedule minimizing Pfail()
would be the optimized schedule.

[0080]Let |RTt()|=n, then the complexity of finding the optimized
schedule by exhaustive search is (n!), which is computationally
intractable. The intuition behind the voting-based approach is based on
order invariability, which indicates the following: if resource r appears
before resource r' in the optimized schedule for resource set R', then
resource r appears before resource r' in the optimized schedule for
resource set R'' where R'.OR right.R''. Empirical evidence suggests that,
in most cases (more than 90% in all our experiments), order invariability
is valid. Given the deadline constraints and the high complexity of the
problem, it is worthwhile to exploit the order invariability property
when it almost applies.

[0081]Rather than exhaustively searching in the optimized schedule for
remaining resources RTt(), in the voting-based approach, we only
search the optimized schedule for a small set of resources RTt().
Then we compute the schedule for RTt() using the optimized schedules
for all combinations of a smaller number of resources. Let |=q, there are

( n q ) ##EQU00006##

different combinations of resources of size q. The complexity of computing
the optimized schedules for all

( n q ) ##EQU00007##

combinations is

( ( n q ) q ! ) ( ( n q ) )
##EQU00008##

(nq)) when q is constant). The complexity is reduced by

n ! ( n q ) q ! = ( n - q ) !
##EQU00009##

[0082]Algorithm 1 in FIG. 3 shows how to find the schedule for RTt()
using voting. The input is the current agreement set , the plan PL, and
the deadline τ', which is the maximum time the algorithm can run. The
output of the algorithm is a schedule for RTt().

[0083]V(r) denotes how many "votes" r receives; it is used to represent
how desirable it is to negotiate resource r earlier. The resource with
the highest V(r) will be negotiated first. Size represents the number of
resources which will be used to run exhaustive search. At the beginning,
Size is set to 2 and the scheduler will first find the optimized schedule
of every pair of resources. Then Size will be set to 3 and all
combinations of three resources are searched, then Size is set to 4, 5,
and so on.

[0084]For each combination of resources , the scheduler will search all
possible schedules and choose the one with the highest utility as the
optimized schedule Γ. The i th resource in an optimized schedule of
q resources receives a "vote" of q+1-i and V(r) is increased by the
"votes" from all combinations where r appears.

[0085]After scheduling all the combinations of Size resources, the output
schedule will be updated. if V(r)<V(r'), resource r will be
negotiated later than resource r' in the plan . The algorithm will stop
when the scheduling deadline is reached or all possible schedules have
been searched, i.e., Size=|RTt()|. When the algorithm stops, the
latest schedule will be returned.

[0086]The algorithm is an anytime algorithm in the sense that with more
time, the algorithm will search the optimized schedule of a larger number
of negotiation tasks with the increase of Size. With more time, the
schedule returned by the algorithm is better.

[0087]B. Algorithm for the Multi-Plan Case

[0088]If there is more than one feasible plan, we can run the voting
algorithm for each plan, and then compute the overall weight w(r) for
each resource rεRTt() at round t where
RTt()=∪PLεPSt RTt() is the set of all
possible negotiation tasks.

[0089]Algorithm 2 in FIG. 4 describes the procedure to determine the
negotiation task at each round t. The input of the algorithm is the set
of plans submitted by the planner, deadline τ, and reserve price
δ. The output is the plan PLo with agreement if scheduling
succeeds or "failure" otherwise. During scheduling, the scheduler
maintains the following data structure: task set , agreement set ,
feasible plan set . Algorithm 2 includes the following three main steps:

[0090]At the beginning of each round, the scheduler updates its data
structure given the last round's negotiation result. This is illustrated
in Algorithm 3 in FIG. 5. If t=0, these plans which cannot satisfy the
budget and deadline constraints will be removed from . When t>0, if PG
fails to get resource Tt-1, it will first remove plans which need
resource Tt-1 from . Then it will check whether the remaining
scheduling time τ-Σt'=0t-1 t (Tt') is enough to
get the resources having not been negotiated in plan PL. If not, it will
remove PL from . If PG's negotiation at round t-1 is successful, some
plans' resource requirements may have been satisfied. Assume the
satisfied plans are and a plan PLε needs a set of agreements
(PL). The following plan will be chosen as PLo:

[0091]In other words, PLo is the plan that minimizes the sum of the
cost for the agreements needed by the plan and the penalty for revoking
the remaining agreements.

[0092]The second step is revoking unnecessary agreements and checking
whether to stop scheduling. There are three situations:

[0093](1) PLo!=null, i.e., one plan's resource requirements have been
satisfied. The scheduler will revoke all unnecessary agreements
(PLo) and return plan PLo with agreements (PLo) to the
planner.

[0094](2) ||=0, which means that scheduling fails because there is no
satisfiable plan left. The scheduler will revoke all agreements and
return "failure" to the planner.

[0095](3) PLo=null and >0, which indicates scheduling will
continue and the scheduler will revoke agreements which are not needed in
any plan in .

[0096]The most important part is deciding which resource to negotiate at
round t. For each resource rεRTt(), its weight w(r)
represents how desirable it is to negotiate it first. That is, the
negotiation task during round t is the resource with the highest weight,
i.e.:

T t = max r .di-elect cons. RT t ( ) w ( r )
##EQU00011##

in which w(r) is given by:

w ( r ) = w ( r , PL ) ##EQU00012##

where w(r,PL) is the weight of resource r in plan PL.

[0097]To compute w(r,PL), the scheduler will first run the voting
algorithm to generate the schedule for RTt(). To get the schedule
for the remaining resource RTt, the scheduler decides the deadline
τ' to run Algorithm 1. Let τ'' be the remaining scheduling time
and it follows that τ''≧max(r) as otherwise, the plan PL will
not be feasible. Here we use a heuristic to decide the value of τ':

τ ' = τ '' ( r ) RT t ( )
##EQU00013##

where

( r ) ##EQU00014##

is the average negotiation time for each remaining plan and |RTt()|
is the number of resources in all the remaining plans.

[0098]After getting the schedule for RTt() of the plan PL using
Algorithm 1, the weight w(r,PL) of resource rεRTt() is

[0099]It can be found that the higher the order of resource r in the
scheduler for PL, the higher the value of w(r,PL). If r appears first in
all the schedulers for plans , r will be chosen as Tt.

[0100]It can be found in Algorithm 2 that the scheduler will stop
scheduling once the resource requirements of one plan are satisfied. This
is partly because in our approach, a plan with lower cost has a higher
chance to be satisfied before a plan with higher cost. In addition, given
a plan with agreements, the scheduler needs to revoke agreements made
before if it finds another plan with agreements. Moreover, uncertainty
about negotiation results makes it possible that the scheduler fails to
satisfy the resource requirements of another plan but pays more
penalties.

[0101]Let n=|| be the number of resources in all plans and m=|| be the
number of plans. If Size=q, the complexity of using the voting-based
approach to determine the negotiation task at round t is

( m ( n q ) q ! ) = ( mn ! / (
n - q ) ! ) = ( mn q ) . ##EQU00016##

We can find that even we choose very small voting depth q, the complexity
of the voting-based approach is still high. In the next section, we
present a weight-based approach, which has a lower complexity of (mn).

III. Weight-Based Approach

[0102]This section presents a weight-based approach. Rather than doing an
exhaustive search on a small scale, the weight of each resource is
computed directly by considering the characteristics of the multiple
plans and resources in these plans.

[0103]A. Analysis for the Single-Plan Case

[0104]Different resources have different prices, probabilities of
successful negotiation, and negotiation times. It would help the
scheduler to find the optimized schedule if we can find how those
resource properties will affect the optimized schedule.

[0105]We observe that resources with higher prices should be negotiated
later. In other words, cheaper resources should be negotiated before the
expensive resources.

[0106]This observation corresponds to the intuition that if we negotiate a
resource with a higher price first, the revocation penalty later will
also be higher when the agreement becomes unnecessary as the penalty
increases with the price in the agreement.

[0107]Further we observe that resources with higher success probabilities
should be negotiated later. In other words, resources with higher success
rates should be negotiated first.

[0108]This observation corresponds to the intuition that if we negotiate
resources with lower success probabilities later, the scheduler will have
higher probability of failing to obtain those resources and will have to
revoke agreements made before, thus paying more penalties. Therefore, we
would like to first negotiate resources which are difficult to get, in
order to reduce such revocation penalties.

[0109]B. Analysis for the Multi-Plan Case

[0110]The two observations above are helpful while developing scheduling
algorithms. However, different resources have different success
probabilities and prices. Thus, the scheduler makes tradeoffs to solve
the conflicts between different properties. In addition, the two
observations are valid for the single-plan case. In the multiple-plan
case, in addition to success probability and price, the following factors
also are considered: [0111]Appearance frequency. Assume there are two
resources r and r'. r appears in most plans and resource r' appears much
less than r. Assume there is no big difference in r and r''s other
properties like price. It is intuitive to negotiate resource r first
because if PG cannot get resource r, PG does not need to consider those
plans which need resource r anymore. An extreme situation is that
resource r appears in all the plans. Clearly, we need to get resource r
first. If PG fails to get resource r, scheduling stops. If the scheduler
lets PG negotiate for r' first and PG successfully gets resource r', then
the scheduler later needs to pay for revoking the agreement about r' when
PG fails to get resource r. [0112]Plan cost: The cost of a plan PL is
C(PL)=(r). The costs of different plans may vary. Regardless of other
factors like negotiation time, the scheduler would like to satisfy the
resource requirements of the plan with lower cost first as the scheduler
will try to maximize its utility, which will decrease with the increase
of the plan cost.

[0113]Based on our observations and intuitions, we propose a heuristic to
compute the weight w(r,PL) of resource r as follows:

where (r) is the cost of the plan PL,|RTt()| is the number of
resources to be negotiated in plan PL. w(r,PL) will satisfy the following
properties: [0114]w(r,PL) decreases with (r). That is, if the cost of
the plan is high, any resource of this plan has a lower probability to be
negotiated first. [0115]w(r,PL) decreases with p(r), which corresponds to
our previous proposition that the resource with lower success probability
should be negotiated first. [0116]w(r,PL) decreases with |RTt()|.
With fewer remaining resources to be negotiated, the scheduler can know
whether it can satisfy the resource requirements of the plan in shorter
rounds. Thus, it is reasonable to negotiate plans with less resources
first because those plans seem more likely to succeed.

[0117]w(r) is the sum of the weight of resource r in all the plans. If the
resource r appears more in those plans, it will have a higher weight.
Therefore, it has a higher probability of being negotiated first. In
other words, frequently appearing resources will be negotiated first. An
example function to compute w (r,PL) is:

[0118]Given w(r,PL) of each resource in plan PL, we can compute the weight
w(r) of each resource rεRTt(). Then we can use Algorithm 2
to determine the negotiation task at each round.

[0119]The complexity of the weight-based approach at each scheduling round
is (nm) where n=|| is the number of resources in all the m=|| plans.
Clearly, the weight-based approach has much lower complexity than the
voting-based approach, even when the voting depth is small. When the
voting depth is q, the complexity of the voting based approach is
(nqm), which is higher than (nm).

[0120]Referring lastly to FIG. 6, a computer system 600 is shown in
accordance with which one or more components/steps of negotiation
management techniques of the invention may be implemented. It is to be
further understood that the individual components/steps may be
implemented on one such computer system or on more than one such computer
system. In the case of an implementation on a distributed computing
system, the individual computer systems and/or devices may be connected
via a suitable network, e.g., the Internet or World Wide Web. However,
the system may be realized via private or local networks. In any case,
the invention is not limited to any particular network.

[0121]Thus, the computer system shown in FIG. 6 may represent one or more
servers or one or more other processing devices capable of providing all
or portions of the functions described herein. Alternatively, FIG. 6 may
represent a mainframe computer system.

[0122]That is, computer system 600 may be one or more computer systems
that are part of a data stream processing system at a particular site,
such that one or more of the NM component, the planner, the site policy
management component, and resource components are implemented thereon.

[0124]It is to be appreciated that the term "processor" as used herein is
intended to include any processing device, such as, for example, one that
includes a CPU and/or other processing circuitry. It is also to be
understood that the term "processor" may refer to more than one
processing device and that various elements associated with a processing
device may be shared by other processing devices.

[0125]The term "memory" as used herein is intended to include memory
associated with a processor or CPU, such as, for example, RAM, ROM, a
fixed memory device (e.g., hard disk drive), a removable memory device
(e.g., diskette), flash memory, etc. The memory may be considered a
computer readable storage medium.

[0126]In addition, the phrase "input/output devices" or "I/O devices" as
used herein is intended to include, for example, one or more input
devices (e.g., keyboard, mouse, etc.) for entering data to the processing
unit, and/or one or more output devices (e.g., display, etc.) for
presenting results associated with the processing unit.

[0127]Still further, the phrase "network interface" as used herein is
intended to include, for example, one or more transceivers to permit the
computer system to communicate with another computer system via an
appropriate communications protocol.

[0128]Accordingly, software components including instructions or code for
performing the methodologies described herein may be stored in one or
more of the associated memory devices (e.g., ROM, fixed or removable
memory) and, when ready to be utilized, loaded in part or in whole (e.g.,
into RAM) and executed by a CPU.

[0129]In any case, it is to be appreciated that the techniques of the
invention, described herein and shown in the appended figures, may be
implemented in various forms of hardware, software, or combinations
thereof, e.g., one or more operatively programmed general purpose digital
computers with associated memory, implementation-specific integrated
circuit(s), functional circuitry, etc. Given the techniques of the
invention provided herein, one of ordinary skill in the art will be able
to contemplate other implementations of the techniques of the invention.

[0130]Although illustrative embodiments of the present invention have been
described herein with reference to the accompanying drawings, it is to be
understood that the invention is not limited to those precise
embodiments, and that various other changes and modifications may be made
by one skilled in the art without departing from the scope or spirit of
the invention.