Deciding on Satisfiable Expectations

The range-matching step discussed previously marks an expectation as satisfiable if the system could satisfy the contained requirements by adapting certain capabilities. Mechanisms for adapt- ing the system have their own costs in addition to the costs for operating capabilities at a certain level. Thus, the MOM has to assess the expected costs and adapt if the expected benefits outweigh the calculated costs [79, 80, 381].

Whether a satisfiable expectation should be satisfied or not is an abstract decision problem to be solved by the MOM. While every decision problem can be decomposed into a decision tree with objectives, goals and attributes [249, 424], their nature and hierarchy depend on the preferences of the decision maker. Thus, our model allows to express such preferences from the perspective of the MOM that acts as the decision maker4. These preferences are orthogonal to the prefer- ences articulated by subscribers and formalized in expectations. We follow the definitions of Keeney [249] in that objectives describe outcomes that can be achieved to a certain degree while

goals describe outcomes that are achieved either completely or not.

Examples for objectives in the context of QoI in EBS: • Maximize total utility.

• Maximize utility per subscriber.

• Maximize generated fidelity per subscriber.

• Maximize total number of subscribers with satisfied expectations. • Minimize adaptation costs.

• Minimize operational costs. Respectively, examples for goals are:

• Every subscriber has at least one satisfied expectation. • No subscriber is put into disadvantage by an adaptation.

• No publisher is responsible for more than 40% of all satisfied expectations.

The preferences defined by the decision maker can consist of a single objective or of multiple objectives and goals that can be conflicting due to limitations of the system.

In case that the preferences of the decision maker require the MOM to optimize multiple objec- tive functions at the same time, the decision problem becomes an optimization problem. The resulting optimization problem consists of a set of attributes (here: capabilities to adapt, utility generated by an expectation, etc.), a set of objective functions that formalize objectives and goals as well as a set of constraints [437]. In general, the optimization problems to solve are min-max or max-min problems, i.e., some target function has to be maximized subject to several auxiliary functions that need to be minimized or vice-versa; a feasible solution for such a problem does not violate any constraints [297].

By abstracting the decision about a satisfiable expectation as an optimization problem, we can rely on the huge body of work done for decades about optimization approaches in the area of Multi-Objective Optimization Problem (MOOP) and Multi-Criteria Decision Making (MCDM). However, the computational complexity of MOOPs is NP-hard if attributes require integer solu- tions [83, 161], e.g., the number of alternative publishers to be chosen. Thus, heuristics and 4 _{In practice, we assume these preferences to be defined by the party deploying and operating the MOM.}

relaxing assumptions are usually used in practice to find approximate (weak pareto-optimal) solutions [36, 79, 80, 346, 381].

We summarize the general types of optimization approaches that build on preferences of the decision maker and refer the interested reader to [83, 133, 151, 270, 272, 283, 297, 437] for a more detailed presentation of the different approaches.

In general, three categories of approaches can be distinguished based on the point in time when the preferences of the decision maker are defined [83, 133, 270, 437]:

1. A priori: the preferences of the decision maker are known beforehand. In this case, the objectives and goals can be aggregated into a single objective function, e.g., using scalar- ization, ε-constraints, goal programming, lexicographical ordering, weighted global crite- ria, or weighted sums; if the preferences establish a meaningful hierarchy of objectives, multi-level programming can be used as well.

2. A posteriori: the preferences of the decision maker are not known beforehand. Thus, dif- ferent alternative solutions are provided to the decision maker to choose from.

3. Interactive: the decision maker is included into the optimization process itself. At each step, preferences can be defined that establish a hierarchy of objectives and narrow down the solution space.

None of the above approaches is superior as such: the information available, the types of pref- erences as well as system limitations determine feasible approaches for a specific optimization problem [297].

Runtime negotiation in our model does not require a specific optimization approach to decide on satisfiable expectations. Our model allows any custom approach to be used based on the deployment scenario: how the decision is reached is encapsulated and transparent for all other steps of the runtime negotiation phase.

4.2.1 Decision Strategies Encapsulating the Decision Process

In our approach, a decision strategy encapsulates an individual decision tree of minor and major objectives or goals together with their attributes and optimization approach (optimal algorithms, prediction models, or heuristics). We assume that the party deploying or operating the MOM provides at least one decision strategy. In the remainder of this section we will discuss an example for a simple decision strategy to illustrate the general principle.

A decision strategy encapsulates the two steps shown in Figure 4.7: calculating costs and deciding on whether the expected benefits outweigh these costs. For a single satisfiable expectation, applying a decision strategy results in a final state (satisfied or unsatisfied) for that expectation as well as an updated adaptation plan.

Load-balancing approaches can be included when calculating the costs for adaptation, e.g., to include resource utilization as a weighting factor; or it can be included in the second step when deciding on whether the benefits outweigh the costs. For example, using the FIT score [169] to weigh the total costs for adapting a publisher can be used to avoid overloading publishers. Including or excluding those considerations, however, depends on the preferences of the decision maker or the party defining a decision strategy.

Runtime negotiation Matching expectations to capabilities Safeguarding decision Decide on satisfiable expectations 4.1 4.2 4.3 Calculate costs

Decide if benefits > costs Decision strategy 1 2 Final state for expectation (satisfied or unsatisfied) Minimal adaptation plan {a1, . . . , am} Decision strategies can include load- balancing strategies

Figure 4.7.: Two-step approach to decide whether to satisfy a satisfiable expectation.

4.2.2 Example Strategy: First-Come, First-Served while Minimizing Costs

A valid decision strategy does not necessarily have to include aspects of multi-objective optimiza- tion. For example, it could be based on a First-come, First-served (FCFS) policy just as well: the MOM tries to satisfy expectations in the chronological order they are registered or updated. An expectationXe

i,k by subscriber Si should only be declined if the cost for providing it exceeds the

total cost of an already satisfied expectationX0e

i,s by the same subscriber.

Algorithm 1 shows a simple heuristic to implement this strategy for each subscriber S_i: 1. Select minimum adaptation plan to satisfyXe_i,k (line 1).

2. Calculate total costs expected for satisfyingXe_i,k (line 4). 3. Calculate total costs for the currently satisfiedX0e

i,s (line 3).

4. SatisfyXe

i,k if satisfying it is less expensive than operatingX0ei,s (line 6).

Algorithm 1: Decide if a satisfiable expectation should be satisfied with the example strategy. Function decideOnSatisfiable(Xe

i,new,ADAPTATIONPLANXe_i,new)is

Result: minimal ADAPTATIONP_LANXe i

1 ADAPTATIONPLANmin_Xe

i,new ← getAdaptationPlanMinimalCosts(X

e

i, ADAPTATIONPLANXei,new)

2 costs_new← getTotalCosts(ADAPTATIONP_LANXe i,new)

3 Xe_{i,cur r ent}← getCurrentSatisfiedExpectation(i) // Get currently satisfied expectation 4 costscur r ent← getTotalCosts(Xei,cur r ent)

5 st at e← unsatisfied

6 if costs_new< costs_{cur r ent}then // Does it cost less on the long run?

7 st at e← satisfied

8 else

9 ADAPTATIONP_LANXe

i,new← ;

10 return ADAPTATIONP_LANXe i,new

The total costs for satisfying an expectation in steps 2 and 3 include the costs for executing all necessary adaptations as well as the costs for a publisher to continuously provide notifications with certain capabilities. Thus, we do a rough break-even analysis in step 3 by calculating the operational costs for providingδ notifications that conform to Xe

i,k orX0ei,s. In case that there is

no other expectation satisfied for S_i so far, the costs forX0e

i,sare set to∞, automatically resulting

in the decision to satisfyXe_i,k.