On the Cost of Agentawareness for Negotiation Services

1

• On the Cost of Agent-awareness for Negotiation
  Services
• Andrea Giovannucci
• Juan A. Rodríguez-Aguilar

Artificial Intelligence Research
Institute Spanish Council for Scientific Research
Utrecht July 26th 2005
2
Agenda
Motivation Goal Methodology Ibundler Experime
ntal Settings Experimental Results
3
Motivation

• A significant number of agent-based applications
  for electronic commerce have been prototyped.
• Little attention devoted to analysing the
  practical benefits and shortcomings of agent
  technology when applied to such domain.

4
Goal

• What? To assess the computational cost added by
  agent technology in this type of applications.
• Why? To diagnose the improvements required by
  state-of-the-art agent technology.
• How? We report on a particular, actual-world case
  study.

5
Agenda
Motivation Goal Methodology Ibundler Experime
ntal Settings Experimental Results
6
Case study Ibundler

• Ibundler is an agent-aware negotiation service
  for combinatorial negotiations designed to be
  employed as
• An open agent service in the Agentcities.RDT
  platform (http//www.agentcities.org/EURTD).
• An agent façade to Quotes (iSOCOs
  (http//www.isoco.com) commercial negotiation
  tool), to allow for the participation of
  third-party business agents in actual-world
  procurement events.
• We study the computational cost of agent
  awareness for Ibundler so that its users are
  aware of the type of negotiation scenarios that
  Ibundler can acceptably handle.

7
Methodology Performance Evaluation

• We have measured time and memory performances of
  Ibundler through a wide range of artificially
  generated negotiation scenarios.
• For each scenario we sampled at several stages
  both the time and memory required by Ibundler.

8
Agenda
Motivation Goal Methodology Ibundler Experime
ntal Settings Experimental Results
9
Example Parts Purchasing
FRONT SUSPENSION, FRONT WHEEL BEARING ACQUISITION
GOAL BUY PARTS TO PRODUCE 200 CARS
10
Sourcing
Typical negotiation (sourcing) event in
industrial procurement
11
iBundler Goal

• To provide a negotiation service for buying
  agents to help them determine the optimal bundle
  of offers based on a large variety of constraints
  and preferences.
• assistance to buyers in one-to-many negotiations
  and
• automated winner-determination in combinatorial
  auctions.
• To relieve buying agents with the burden of
  solving too hard a problem and concentrate on
  strategic issues.

12
Service Architecture
RFQ
RFQ
RFQ
RFQ
13
Service Architecture
SOLUTION
SOLUTION
PROBLEM
PROPOSE (BIDS)
PROPOSE (BIDS)
14
AUML Interaction protocol
IP-CFP
IP-RFQ
IP Request Solution
Protocols implemented as JADE behaviours
(extensions of the FSMBehaviour class)
IP-AWARD
15
Service Ontology (I)
RFQ
ProviderResponse
Buyers Constraints
Providers Constraints
16
Service Ontology (II)
Bid Solution
Problem
17
Implementation features

• All agents in the agency implemented in JADE
• FIPA as ACL (agent communication language)
• Two implementations of SOLVER
• ILOG CPLEX
• MIP modeller based on GNU GLPK library
• Ontology editor Protegé2000
• Ontology generator The Beangenerator Protege2000
  plugin to generate ready-to-use Java classes

18
Agenda
Motivation Goal Methodology Ibundler Experime
ntal Settings Experimental Results
19
Artificial Negotiation Scenarios

• Time needed by Ibundler to receive an RFQ from a
  Buyer agent and to collect bids from providers is
  considered of no interest.
• We simulate such an ideal situation generating
  multiple data sets, each one standing for a
  different input negotiation problem.
• Each data set contains a set of FIPA messages
  one standing for an RFQ and the rest for the bids
  received as a response.
• We use each data set as if it was the incoming
  message stream, and perform all subsequent
  message manipulations as if messages had been
  received from a socket.

20
Artificial Negotiation Scenarios (2)

• We sampled time and memory at some established
  checkpoints through the process carried out by
  Ibundler when solving a negotiation problem.
• We observed time and memory at the beginning and
  the end of these stages.

21
The Artificial Negotiation Scenarios Generator

• We developed a generator of artificial
  negotiation scenarios.
• Input. Mean and variance values for
• Number of providers participating in a
  negotiation
• Number of bids each provider sends to the Manager
  agent
• Number of items to be negotiated by the Buyer
  agent
• Number of items within each bid sent by a
  provider
• Number of units per item per bid
• Bid cost per item
• Output. Negotiation problem ( RFQ bids).

22
Artificial Negotiation Scenarios

• Generated artificial negotiation scenarios result
  from combining values for the following
  parameters
• Number of providers 25, 50, 75, 100
• Number of bids per provider 5, 10, 15, 20
• Number of RFQ items 5, 10, 15, 20
• Number of items per bid 5, 10, 25, 50

23
Jade Message Cycle
24
Hardware Settings

• A PC with a
• Pentium IV processor, 3.1 Ghz
• 1 Gbyte RAM
• OS Linux Debian (kernel v.2.6)
  (http//www.debian.org)
• Java SDK 1.4.2.04 (http//java.sun.com)
• JADE v2.6
• ILOG CPLEX 9.0 optimisation library
  (http//www.ilog.com)

25
Agenda
Motivation Goal Methodology Ibundler
Architecture Experimental Settings Experimental
Results
26
Varying the number of bids per provider

• Similar trends when varying number of items per
  bid and number of providers
• Time distribution along stages independent from
  parameter setting

27
Average time spent at the different evaluation
stages

• dt1,dt3,dt4,dt5,dt9,dt10 involve ontology
  checking message encoding/decoding
• dt1,dt3,dt4,dt5,dt9,dt10 require 92 of total
  time
• Solving the negotiation problem (dt7) and
  manipulating classes (dt2,dt6,dt8,dt11)
• is far less expensive.

28
Memory consumption
Memory required by both cases is close!
29
Analysis

• Offering Ibundler as an agent service involves a
  significant time overload, while memory use is
  only slightly affected.
• Main cause of time overload related to the
  encoding and decoding of ontological objects and
  messages.
• Message serialisations and deserialisations,
  along with ontology checkings, heavily overload
  the system as the dimensions of the negotiation
  scenario grow.
• Although the automation of the negotiation
  process with agents helps in saving time in
  managing negotiations, the scalability in terms
  of time response of Ibundler is limited (it can
  acceptably handle small-size, medium-size
  negotiations).

30
Future actions

• Most information gathered in representing bids.
• We suggest to
• use, at ontology design time, a more synthetic
  bidding language, in which bids can be expressed
  more concisely (Ex. grouping similar bids) and
• improve the performance of the JADE modules
  devoted to the ontology checking and
  serialisation processes.

31
Thank you ... Any questions?
32

• Backup/Extra Slides

33
Evaluation Stages (1)

• ?t1 JADE decodes all the FIPA messages contained
  in the data set file with the input negotiation
  problem, converting them into instances of the
  ACLMessage Java class.
• ?t2 the Manager agent composes the problem by
  creating an instance of the Problem Java ontology
  class and setting its fields after merging the
  RFQ and the collected bids.
• ?t3 the ACLMessage to be sent to the Translator
  Agent is filled with the Java class representing
  the Problem ontology class. At this stage an
  ontology check occurs.
• ?t4 the above-mentioned ACLMessage is now
  encoded by the Manager agent, and subsequently
  sent to the Translator agent through a socket.
  Once received, the Translator agent decodes it
  into an ACLMessage class.
• ?t5 the Translator agent extracts from the
  received message the Problem ontology class
  containing the RFQ and all the collected Bids.
  Another ontology check occurs.
• ?t6 this stage is devoted to the transformation
  of the Problem ontology class into a matrix-based
  format to be processed by the Solver component.

34
Evaluation Stages (2)

• ?t7 at this stage the Solver component solves
  the MIP problem using ILOG CPLEX.
• ?t8 the output generated by Solver in
  matrix-based format is decoded by the Translator
  agent into the Solution ontology class.
• ?t9 the Translator agent fills the response
  message with the Solution ontology class, encodes
  the corresponding ACLMessage class, and sends it.
  Then, the Manager agent decodes the message upon
  reception.
• ?t10 the Manager agent extracts the Solution
  concept from the received ACLMessage with a last
  ontology check.
• ?t11 the solution is decomposed into different
  parts, one per provider owning an awarded bid.
• ?t12 the solution containing the set of winning
  offers is sent from the Manager agent to the
  Buyer agent. Note that this object is small with
  respect to the originalproblem since it only
  contains the winning bids.

35
Acceptability
36
Conclusions and future work

• We believe that state-of-the-art agent
  technologies require further improvements to
  tackle actual-world domains.
• We propose a future comparison of Ibundler with
  other distributed solutions such as
• CORBA (http//www.corba.org)
• JAVA RMI (http//java.sun.com).

37
Multi-dimensional knapsack problem
Winner determination in combinatorial auctions is
an instance of the multi-dimensional knapsack
problem
knapsacks
Xi i-th bid decision variable pi
(combinatorial) bid value
C12
C22
C34
Knapsacks capacities
Bid 2
Units required to fill knapsack
38
Conversion to FIPA compliant message
39
The contract-net protocol(III)
40
Conversion to FIPA compliant message
41
Demo Contract Allocation. Unconstrained RFQ
FRONT SUSPENSION, FRONT WHEEL BEARING ACQUISTION
UK Parts Ltd.200
GHL Motor 200
UK Parts Ltd. 200
Alfa Ricambi 50
GHL Motor 350
Alfa Ricambi 600
GHL Motor 200
Alfa Ricambi 200
UK Parts Ltd. 200
42
Demo Contract Allocation. Constrained RFQ
FRONT SUSPENSION, FRONT WHEEL BEARING ACQUISTION
UK Parts Ltd. 300
GHL Motor 100
UK Parts Ltd. 100
GHL Motor 100
Alfa Ricambi 200
GHL Motor 400
Alfa Ricambi 800
Alfa Ricambi 300
UK Parts Ltd. 100