<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Experiments with Protocols for Service Negotiation</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Costin Ba˘dica˘</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Mihnea Scafes¸</string-name>
          <email>mihneag@software.ucv.ro</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>University of Craiova, Software Engineering Department Bvd.</institution>
          <addr-line>Decebal 107, Craiova, RO-200440</addr-line>
          ,
          <country country="RO">Romania</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2011</year>
      </pub-date>
      <fpage>25</fpage>
      <lpage>31</lpage>
      <abstract>
        <p>In this paper we provide experimental results concerning the impact of the negotiation protocol onto the quality of the negotiation outcome as well as onto the communication complexity of interactions incurred during negotiations. We evaluate experimentally three negotiation protocols (Direct Task Assignment, Contract Net and Iterated Contract Net) with respect to two performance measures: negotiation outcome (i.e. utility) and communication complexity (i.e. number of messages transferred), by assigning different busy profiles to the contractors. We find that the Direct Task Assignment delivers the worst average outcome, but at the same time it uses the lowest number of messages. The Contract Net and Iterated Contract Net deliver much higher utility on average, but the Iterated Contract Net obtains the highest outcome for some configurations at the cost of the highest number of messages.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1 Introduction</title>
      <p>
        We have developed a conceptual framework for service negotiation that addresses
protocols, subjects and decision components in a collaboration system for helping human
experts and population to deal with disasters (see the FP7 DIADEM project1 that targets
crisis management in the context of chemical incidents in industrial and urban areas).
Our framework supports generic one-to-many negotiations and it defines two roles:
manager and contractor [
        <xref ref-type="bibr" rid="ref2 ref4">4, 2</xref>
        ]. The manager is the agent that requests a service and thus
initiates the negotiation. The contractor is the agent that is able to provide the service
requested by the manager. For a more complete review of the conceptual framework,
please see [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. A brief description of the design and implementation is given in [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
      </p>
      <p>
        Currently we have configured our framework with three negotiation protocols that
we have found useful in disaster and environment management problems. These
protocols are Direct Task Assignment (DTA), Contract Net (CNET) and Iterated Contract
Net (ICNET)2. For more information see [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ].
      </p>
      <p>Negotiation participants playing either the manager or contractor roles use utility
functions to quantify their preferences over proposals. In our framework the manager
uses a weighted additive utility function over the negotiation issues to evaluate
proposals and to select the service provider.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Experiments</title>
      <p>Let us assume that a manager agent M is negotiating for contracting a service from a
contractor agent that is member of a set of n contractors C1; : : : ; Cn. Each contractor Ci
is characterized by her profile defined as a triple ([uimin; uimax]; ci; bi). Each contractor Ci
can offer a utility value ui to the manager such that ui 2 [uimin; uimax] [0; 1]. ci 2 [0; 1]
is the probability that she will be able to satisfy the requirements set by the manager’s
request. Ci has a busy profile bi = {bi1 ; bi2 ; : : : bim }, where m is the maximum number
of iterations and bij , 1 j m is the probability of the contractor Ci being busy
during iteration j. We assume that always bim = 0, so that Ci will propose during the
last negotiation iteration. The busy profiles are not taken into account when using the
DTA and when using CNET, only the busy probability of the first iteration is taken into
account. Busy profiles are mostly taken into account when using the ICNET protocol,
which is based on multiple iterations. Depending on the utilized protocol the negotiation
will incur a certain communication cost estimated as the number of messages exchanged
between the manager and the contractor during the negotiation. Moreover the quality
of the negotiation outcome will be estimated as the utility perceived by the manager for
the contracted service.</p>
      <p>If the manager is utilizing the DTA negotiation protocol then she will randomly
assign the task to one of the contractors. However, a contractor that does not meet the
requirements will not be able to provide the service, so she will have to report failure. In
this case the manager will randomly select another contractor and so on, until a suitable
contractor is found (we assume this is always the case). Note however that this
trialand-error process performed by the manager affects the outcome of the negotiation by
decrementing her perceived utility. More precisely, if the successful contractor Ci that
could perform the task was selected in the k-th trial then the utility perceived by the
manager will be ui (1 (k 1)=n) rather than ui. Moreover, the communication cost
associated to this negotiation interaction consists of 2 k message exchanges.</p>
      <p>
        If the manager is utilizing the CNET negotiation protocol then she will select the
contractor Ci that provides her the highest utility ui from those contractors that met
the requirements of the call for proposals and were not busy (i.e. they were able to
bid). The communication cost consumed for a busy contractor consists of 2 message
exchanges, while for a not busy contractor (it doesn’t matter if she could met or not the
requirements, according to the CNET negotiation protocol [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] she either proposed or
refused to bid) the communication cost consists of 3 message exchanges.
      </p>
      <p>If the manager is utilizing the ICNET protocol we assume that she will perform as
many negotiation iterations as needed to select one contractor. We simplify the
negotiation by assuming that contractors do not change their bids between iterations. This
assumption is not as restrictive as it might look, because some contractors are busy and
can bid only in a late iteration. Moreover, we also assume that a busy contractor that
meets the requirements of the call for proposals will always find time to bid during a
certain negotiation iteration. The communication cost for a busy contractor consists in 2
message exchanges, while for a non-busy contractor it consists of 3 message exchanges,
for each iteration.</p>
      <p>In the simulation we considered one manager and 100 contractors.</p>
      <p>There are at most 3 negotiation iterations and we consider 3 busy profiles that we
can assign to contractors:
1. available during the first and the second iteration with equal probability. In this case,
bi = f0:5; 0; 0 . This profile says that a contractor will be able to respond during the
first or the second iteration, but no later than the second iteration. These contractors
respond during the first stages of the negotiation.
2. mostly busy during the first iteration, but available during the second iteration for
sure. In this case, bi = f0:9; 0; 0 . This profile says that a contractor will be able
to respond during the first iteration in few situations, but it will surely respond
during the second iteration. These contractors respond during the middle stage of
the negotiation.
3. not available during the first iteration, but available during the second and third
with equal probability. In this case, bi = f1; 0:5; 0 . Contractors having this profile
do not respond during the first iteration, but they will respond during the second or
the third iteration, no later than the third iteration. These contractors respond during
the last stages of the negotiation.</p>
      <p>In the experiment, we assign the three busy profiles to contractors by following
a certain configuration and for each configuration we run a bundle of 2000
negotiations. We vary the percentage of contractors that have been assigned the three busy
profiles with a step of 5%. For example, we start from (0; 0; 100), meaning that all
the contractors have been assigned the third busy profile and then we continue with
(0; 5; 95); (0; 10; 90); : : : (100; 0; 0), in the final configuration all the contractors having
been assigned the first busy profile.</p>
      <p>The values of the utilities ui are randomly selected for each negotiation instance
assuming uniform distributions. For this experiment, we consider [uimin; uimax] = [0; 1].
The status of the contractor (as satisfying or not satisfying the requirements of the
manager) is randomly selected for each negotiation instance, according to the probability ci.
We fixed the probability ci to 0:5 for all negotiations, for all configurations and for all
contractors.</p>
      <p>We are interested in how each of the studied protocols performs in terms of outcome
and message traffic for each configuration of contractors. We run the negotiations in the
experiment for each negotiation protocol.</p>
      <p>Figure 1 shows the utility of the manager when using the DTA protocol. The scale
labelled “first” shows the percentage of the contractors that can propose mostly during
the first iterations of the negotiation, i.e. they have been assigned the first busy profile.
The scale labelled “middle” shows the percentage of contractors that have been assigned
the second busy profile. The percentage of the contractors that have been assigned the
third profile is not shown in the figure, but it can be obtained by taking into account the
fact that the sum of all the percentages is 100.</p>
      <p>The maximum utility for DTA is a little over 0:5, making this the most inefficient
protocol in terms of utility. The status of being “busy” is not taken into account by the
manager when she is playing the DTA negotiation protocol, i.e. if she selects a certain
contractor then the task will be assigned to her in any case. Nevertheless, if the assigned
contractor cannot finalize the task successfully then she will report failure and
consequently the manager will retry the operation of service contracting by assigning the task
to another contractor. However, the utility is almost the same for all configurations, the
average being around 0:5.</p>
      <p>Figure 2 shows the message statistics for the same protocol. In terms of messages,
DTA performs very well, being the protocol with the lowest number of messages,
outperforming the other protocols by far.</p>
      <p>Figure 3 shows the utility for CNET, which was expected to decrease as the number
of contractors that propose during the first iteration decreases, because it receives less
proposals and the probability to receive good proposals (i.e. of high utility) decreases.
An interesting fact is that the utility decreases almost exponentially as the number of
contractors that propose during the first iteration decreases.</p>
      <p>The message count increases linearly with the number of contractors that propose
during the first iteration (Figure 4).</p>
      <p>For ICNET (Figure 5), the utility decreases almost as for CNET until a point where
almost all contractors propose during iterations 2 &amp; 3. Then it grows back to the initial
maximum very fast.</p>
      <p>When most of the contractors propose during iterations 2 &amp; 3, the message count
grows exponentially to over 400 (see Figure 6. For the rest of the configurations, the
message count varies almost the same as for CNET.</p>
      <p>As future work we plan to expand the experiments in at least two directions: (i) to
consider more complex negotiation instances that take into account more negotiation
iterations, as well as that contractors might change their bids and managers can change
their strategy for accepting contractors’ bids during each iteration; (ii) to consider more
complex workflows involving at least two interdependent negotiations such that the
contracted service might also involve contracting of other required services.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. Ba˘dica˘,
          <string-name>
            <given-names>C.</given-names>
            ,
            <surname>Scafes</surname>
          </string-name>
          <string-name>
            <surname>¸</surname>
          </string-name>
          ,
          <string-name>
            <surname>M.</surname>
          </string-name>
          :
          <article-title>Conceptual Framework for Design of Service Negotiation in Disaster Management Applications</article-title>
          . In: Bai,
          <string-name>
            <given-names>Q.</given-names>
            ,
            <surname>Fukuta</surname>
          </string-name>
          , N. (eds.),
          <source>Advances in Practical Multi-Agent Systems, Studies in Computational Intelligence</source>
          <volume>325</volume>
          ,
          <fpage>359</fpage>
          -375 Springer Verlag (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Paurobally</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tamma</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Wooldridge</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>A Framework for Web service negotiation</article-title>
          .
          <source>ACM Transactions on Autonomous and Adaptive Systems</source>
          <volume>2</volume>
          (
          <issue>4</issue>
          ), ACM Press (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3. Scafes¸,
          <string-name>
            <surname>M.</surname>
          </string-name>
          , Ba˘dica˘,
          <string-name>
            <given-names>C.</given-names>
            ,
            <surname>Pavlin</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G.</given-names>
            , and
            <surname>Kamermans</surname>
          </string-name>
          ,
          <string-name>
            <surname>M.</surname>
          </string-name>
          :
          <article-title>Design and Implementation of a Service Negotiation Framework for Collaborative Disaster Management Applications</article-title>
          .
          <source>Proceedings of the 2nd International Conference on Intelligent Networking and Collaborative Systems INCOS'</source>
          <year>2010</year>
          ,
          <fpage>519</fpage>
          -
          <lpage>524</lpage>
          (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Smith</surname>
            ,
            <given-names>R.G.</given-names>
          </string-name>
          :
          <article-title>The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver</article-title>
          .
          <source>IEEE Transactions on Computers</source>
          <volume>29</volume>
          (
          <issue>12</issue>
          ),
          <fpage>1104</fpage>
          -
          <lpage>1113</lpage>
          IEEE Computer Society (
          <year>1980</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Yang</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Li</surname>
            ,
            <given-names>W.-L.</given-names>
          </string-name>
          , and
          <string-name>
            <surname>Hong</surname>
          </string-name>
          , C.-Y.:
          <article-title>An Improvement to CNCP in Large-Scale Muti-Agent System</article-title>
          .
          <source>Proccedings of the 3rd International Conference on Innovative Computing Information and Control ICICIC'08</source>
          ,
          <issue>147</issue>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>