Flexible interaction protocols

As mentioned in the description of this component of automated negotiation, the interaction protocol determines what actions can be taken by which participants in the negotiation for each of its possible states. In determining these rules of interaction the negotiation protocol not only establishes the basis for the actions of software agents, but also restricts them. Such restrictions are good where necessary, however, in our opinion they reduce the flexibility of agents and thereby maybe negatively impact their performance. Therefore, where possible, decisions should remain with the software agent, which then can decide whether to take actions according to a more restricted protocol but also is free to take other actions when this is considered beneficial. In case of possible gains enabled by more open and flexible interaction protocols the computational complexity should be no counter-argument, as simulation is an adequate technique for complex and analytically intractable problems.

As can be derived from the review the predominant protocol used is an alternating offers protocol or variants of it, where the software agents alternate in making their offers until they reach an agreement. Most often there exists an exogenously determined fixed deadline until which an agreement has to be reached or otherwise negotiations are broken off and in many studies the agents do not have the choice to break off the negotiation. This concern about fixed deadlines actually is not about the nature of deadlines itself, which might be important constitutes of the context in which a negotiation takes place. Actually automated negotiation – due to its fast proceeding – is beneficial for meeting such deadlines – a run in our simulation for example takes on average less than a second as reported in Chapter 5 – so that these deadlines will be no binding constraint in the majority of automated negotiations. Our criticism rather bases on the fact that these deadlines in current simulation studies are imposed in form of a predetermined number of possible rounds or turns for the automated negotiation. Alternating offer protocols with fixed deadlines cause no inconveniences for the agents’ decision making algorithms studied in simulations so far. Actually they are beneficial to them, as fixed deadlines introduce the notion of time – in form of a certain number of turns – that is necessary for any time-based strategy to determine the offer for a given point in time or turn. Fixed deadlines also only make it possible to determine sequential threshold rules chromosomes in evolutionary computing, where otherwise there is no possibility to determine their length.

3.2. Future challenges 69

However, as mentioned, these software strategies are not readily applicable for operative systems. Though the continuous concession strategies, proposed as a viable alternative in the previous section, function in such an alternating offers protocol without exit option, the denial of non- alternating offer sequences and the exogenous termination of negotiations could result in inferior performance of these strategies. In case of a fixed deadline in form of a maximal number of turns for negotiations opponents of continuous concession strategies can simply wait until this deadline and accept the last offer before the negotiation expires, without making any offer or concession at all. Thereby they could squeeze out the maximal possible of continuous concession strategies. Even if such exploitative strategies would not exist, fixed deadlines could inhibit agreements when there are only some more concession steps required to reach an agreement. In our opinion, the termination of negotiations should be the outcome of a decision of the software agents. Having this opportunity, they can themselves decide to break off negotiations if the progress is not satisfactory and therefore no satisfactory outcome can be expected for the combination of agents’ strategies and the given negotiation problem.18

As mentioned continuous concession strategies can be exploited easily if the interaction protocol provides no means to circumvent this. Even if there is no fixed deadline, if agents do not have the possibility to discontinue their strategy they could be exploited by other agents that wait until the continuous concession strategy makes the offer with highest utility to them. The possibility to break off negotiations could prevent this but would also cause many opportunities for a good outcome to be forgone. A way to circumvent both, exploitation and missing agreements due to negotiation abort, is the stipulation of possibilities in the interaction protocol, that enable a software agent to interrupt its strategy.19 _{Such an option can easily be implemented in an}

interaction protocol by allowing an agent to send a reject message instead of an offer when it is its turn. This modification of the interaction protocol not necessarily results in a non- alternating offer sequence, but the decision whether to alternate in the offering process or not is up to the software agents. This possibility to reject offers and thereby interrupt the continuous concession strategy until the opponent catches up can avoid exploitation, however, the possibility to reject offers, is not only beneficial for agents following a continuous concession strategy when negotiating with exploitative agents, but also when such software agents negotiate with each other. As mentioned above human users can have various preferences over one and the same negotiation object. Consider the case where one negotiator assigns different utility values to all possible agreements, while the other one is indifferent between many of them. In a protocol without the possibility to reject offers a continuous concession strategy could cause disadvantages to the later negotiator.

18_{Model validation considerations contribute a further argument in favor of termination by the agents – in real}

world there also exist no (absolutely) fixed deadlines. However, to avoid infinite negotiations, the negotiation protocol could overrule the agents decisions if they fail to make progress and still not terminate the negotiation. Here one rule adopted from the Zeuthen-Nash bargaining game could be, that the protocol terminates negotiations if the two agents both reject the last offer of the opponent – see Chapter 4.

19_{For example the fair concession making approach proposed by Bartos (1977) in his ’simple model of negotia-}

tion’ could be applied for this purpose. Basing on the egalitarian norm of reciprocity Bartos (1977) proposes that if the opponent makes an unfairly small concession, an agent should stop to make further concessions and wait until the opponent catches up. A concession is unfairly small if the reduction of utility between the last two offers of the opponent is smaller than the reduction of utility between the last two offers of the focal software agent.

Chapter 4

Model Development and

Conceptual Model

This chapter documents the model development process and the resulting conceptual model for the simulation of automated negotiation, covering the steps outlined in Chapter 2. As men- tioned in Chapter 3 many studies investigating automated negotiation make use of simulation techniques, however they do not document the model development process (e.g. validation pro- cedures, etc.) though this is an important prerequisite for the transparency and the traceability of a study. We therefore follow the steps outlined in Chapter 2, making and justifying necessary decisions, together with a detailed description of the resulting model.1

The conceptual model resulting from the development process aims at addressing the draw- backs of existing simulation studies on automated negotiation, summarized in the conclusions of Chapter 3 which systematically reviewed these studies. These concerns were organized along the components of automated negotiation – (i) the negotiation problem, (ii) the interaction protocol, and (iii) the software agents’ decision making algorithms – and generally dealt with the avoid- ance of unnecessary assumptions and the exploitation of the simulation technique’s potential to cope with complex interdependencies. For the negotiation problem we argued that more realistic preferences should be assumed and validated, or even elicited from users, so that the negotiation problems used in simulations better represent the variety and complexity of the environment in which actual automated negotiations will take place. Immanent decisions in negotiations, like rejecting offers or breaking off negotiations, should rather be made be the software agents than being imposed by an overly restrictive negotiation protocol – like the alternating offers protocol (with fixed deadline), which was used in the majority of simulation studies so far. Concern- ing the methods applied for determining the decision making of software agents, we argue that generic concession strategies are more appropriate than evolutionary computing-, learning-, or time-based approaches for an inherently open medium as the the Internet, over which auto- mated negotiations take place in some seconds only, for various negotiation problems, and with an unknown population of opponent agents.

1_{Considerations concerning experimentation are not discussed in this chapter but in Chapter 5, where the}

experimental design for the computer experiments, as well as the dependent and independent variables are deter- mined.

Applying simulation techniques for the design of systems for automated negotiation (system de- sign) implies performing computer experiments with various system configurations to evaluate their outcomes and accordingly chose an appropriate one. The objects of an automated negotia- tion system, relevant for system analysis and modeling, mainly are the components of automated negotiation – discussed in detail in Chapter 3 – i.e. the negotiation problem, the interaction pro- tocol, and the software agents. The interaction protocol and the software agents constitute the entities in an automated negotiation systems. They can be described in more detail through their attributes e.g. whether the protocol allows reject or quit messages or which offer generation strategy and concession strategy a software agent follows. These entities represent the static structure of the system and thereby form the ’automated negotiation system’.2 _{Besides these}

’permanent’ entities there also exist temporary entities in automated negotiation systems, which are the messages exchanged by the software agents, that only exist in the system as long as it takes to generate, transmit, and evaluate them – or as long as they are stored by the software agents in case they keep a track of the negotiation history. These messages and their succession have to be in accordance with the rules imposed by the interaction protocol and change the state of the system. For example an offer message sent by one software agent implies a change of the ’last offer sent’-attribute of the focal software agent and a change of the ’current opponent offer’ attribute of its opponent, or an agree message of one software agent to an offer of the opponent causes the negotiation protocol to terminate the negotiation and save its outcome. Consequently the flow of these temporary message entities represents the dynamic behavior of the system. For their operations, the software agents need information concerning the negotiation object – which is common to the software agents – and their users’ preferences over this negotiation object – which is private information. These components form – as discussed in Section 3.1.1 – the ne- gotiation problem, as the input to the automated negotiation system. Furthermore, as already mentioned in the example above, some types of messages like the acceptance of an offer or mes- sages indicating that the software agent intends to abort negotiations lead to the satisfaction of termination criteria so that the interaction protocol terminates the automated negotiation, in this case the system terminates the specific negotiation which produces some kind of output. We therefore consider a system for automated negotiation to consist of one software agent for each user and an interaction protocol (as illustrated in Figure 3.2 in Chapter 3). The inputs to this automated negotiation system are the negotiation object and the users’ preferences – as private information to the user’s software agent – over this negotiation object, which together form the negotiation problem. A conceptual model for simulation of automated negotiation has to represent these entities accordingly. The following Section 4.1 discusses the input component i.e. the negotiation object and the preference functions, provides information on data acquisition, and presents descriptive statistics on this data. Section 4.2 afterwards discusses the conceptual model’s entities that represent the automated negotiation system, i.e. the interaction protocol and the software agents.

2_{The system configuration – the static structure of an automated negotiation system – actually only needs to}

be static for the time it takes to conduct the specific negotiation at hand. For this time, i.e. the duration of the focal negotiation, the interaction protocol and the software agents can be conceived as permanent entities of the system for automated negotiation. Clearly if the automated negotiation system is an open system software agents can freely join or leave the system for different negotiation instances and alternative interaction protocols can be chosen.

4.1. Input 73

4.1

Input

Basing on the review of existing simulation studies on automated negotiation we criticized in Chapter 3, that these studies often fall short in representing the potential complexity of real negotiation problems by assuming simple preferences and in most cases considering only one negotiation problem in their studies, for which different software agent strategies are tested and compared. Actually only one of the reviewed studies (Bosse and Jonker, 2005) elicited preferences from humans as input for their software agents. If preferences, that form the input to the simulation of automated negotiation, are assumed rather than elicited then they should be validated as any input to a simulation model, which however is often neglected in simulation studies on automated negotiation. So either way there is a need to collect data on the users’ preferences to use them as an input or for validation of assumed preferences.

A further concern was that the true problem solving potential of negotiations lies with multi- issue problems where joint gains could be achieved through cooperative integration of interests, however, many studies focused on single-issue negotiations (most often the price of an other- wise specified deal), which normally are more competitive. Additionally multi-issue negotiation objects seem to be the more realistic use case, as they are more frequent in real negotiation situations. For such multi-issue objects integrative negotiation problems can emerge easily from the users’ utility functions, as the prerequisites for an integrative negotiation problem are not very demanding.3 _{The problem of higher complexity should not be an argument against the}

consideration of many different negotiation problems, as the simulation technique evidenced to be able to cope with such complexity.

Addressing these concerns, we used the preferences elicited from subjects in negotiation exper- iments as input for the software agents in our study. The multiple-issue negotiation object for which the preferences were elicited, and the utility functions resulting from this elicitation procedure, are the topic of this section.4