Experiments with Protocols for Service Negotiation

Transcription

1 PROCEEDINGS OF THE WORKSHOP ON APPLICATIONS OF SOFTWARE AGENTS ISBN , pp , 2011 Experments wth Protocols for Servce Negotaton Costn Bădcă and Mhnea Scafeş Unversty of Craova, Software Engneerng Department Bvd.Decebal 107, Craova, RO , Romana {badca costn scafes Abstract. In ths paper we provde expermental results concernng the mpact of the negotaton protocol onto the qualty of the negotaton outcome as well as onto the communcaton complexty of nteractons ncurred durng negotatons. We evaluate expermentally three negotaton protocols (Drect Task Assgnment, Contract Net and Iterated Contract Net) wth respect to two performance measures: negotaton outcome (.e. utlty) and communcaton complexty (.e. number of messages transferred), by assgnng dfferent busy profles to the contractors. We fnd that the Drect Task Assgnment delvers the worst average outcome, but at the same tme t uses the lowest number of messages. The Contract Net and Iterated Contract Net delver much hgher utlty on average, but the Iterated Contract Net obtans the hghest outcome for some confguratons at the cost of the hghest number of messages. 1 Introducton We have developed a conceptual framework for servce negotaton that addresses protocols, subjects and decson components n a collaboraton system for helpng human experts and populaton to deal wth dsasters (see the FP7 DIADEM project 1 that targets crss management n the context of chemcal ncdents n ndustral and urban areas). Our framework supports generc one-to-many negotatons and t defnes two roles: manager and contractor [4, 2]. The manager s the agent that requests a servce and thus ntates the negotaton. The contractor s the agent that s able to provde the servce requested by the manager. For a more complete revew of the conceptual framework, please see [1]. A bref descrpton of the desgn and mplementaton s gven n [3]. Currently we have confgured our framework wth three negotaton protocols that we have found useful n dsaster and envronment management problems. These protocols are Drect Task Assgnment (DTA), Contract Net (CNET) and Iterated Contract Net (ICNET) 2. For more nformaton see [3]. Negotaton partcpants playng ether the manager or contractor roles use utlty functons to quantfy ther preferences over proposals. In our framework the manager Mhnea Scafeş was supported by IOSUD-AMPOSDRU contract 109/ DIADEM Dstrbuted nformaton acquston and decson makng for envronmental management: 2 CNET and ICNET are standardzed by Foundaton for Intellgent Physcal Agents, see and fpa00030/ 25

2 uses a weghted addtve utlty functon over the negotaton ssues to evaluate proposals and to select the servce provder. 2 Experments Let us assume that a manager agent M s negotatng for contractng a servce from a contractor agent that s member of a set of n contractors C 1,..., C n. Each contractor C s characterzed by her profle defned as a trple ([u mn, u max ], c, b ). Each contractor C can offer a utlty value u to the manager such that u [u mn, u max ] [0, 1]. c [0, 1] s the probablty that she wll be able to satsfy the requrements set by the manager s request. C has a busy profle b = { } b 1, b 2,... b m, where m s the maxmum number of teratons and b j, 1 j m s the probablty of the contractor C beng busy durng teraton j. We assume that always b m = 0, so that C wll propose durng the last negotaton teraton. The busy profles are not taken nto account when usng the DTA and when usng CNET, only the busy probablty of the frst teraton s taken nto account. Busy profles are mostly taken nto account when usng the ICNET protocol, whch s based on multple teratons. Dependng on the utlzed protocol the negotaton wll ncur a certan communcaton cost estmated as the number of messages exchanged between the manager and the contractor durng the negotaton. Moreover the qualty of the negotaton outcome wll be estmated as the utlty perceved by the manager for the contracted servce. If the manager s utlzng the DTA negotaton protocol then she wll randomly assgn the task to one of the contractors. However, a contractor that does not meet the requrements wll not be able to provde the servce, so she wll have to report falure. In ths case the manager wll randomly select another contractor and so on, untl a sutable contractor s found (we assume ths s always the case). Note however that ths traland-error process performed by the manager affects the outcome of the negotaton by decrementng her perceved utlty. More precsely, f the successful contractor C that could perform the task was selected n the k-th tral then the utlty perceved by the manager wll be u (1 (k 1)/n) rather than u. Moreover, the communcaton cost assocated to ths negotaton nteracton conssts of 2 k message exchanges. If the manager s utlzng the CNET negotaton protocol then she wll select the contractor C that provdes her the hghest utlty u from those contractors that met the requrements of the call for proposals and were not busy (.e. they were able to bd). The communcaton cost consumed for a busy contractor conssts of 2 message exchanges, whle for a not busy contractor (t doesn t matter f she could met or not the requrements, accordng to the CNET negotaton protocol [4] she ether proposed or refused to bd) the communcaton cost conssts of 3 message exchanges. If the manager s utlzng the ICNET protocol we assume that she wll perform as many negotaton teratons as needed to select one contractor. We smplfy the negotaton by assumng that contractors do not change ther bds between teratons. Ths assumpton s not as restrctve as t mght look, because some contractors are busy and can bd only n a late teraton. Moreover, we also assume that a busy contractor that meets the requrements of the call for proposals wll always fnd tme to bd durng a certan negotaton teraton. The communcaton cost for a busy contractor conssts n 2 26

3 message exchanges, whle for a non-busy contractor t conssts of 3 message exchanges, for each teraton. In the smulaton we consdered one manager and 100 contractors. There are at most 3 negotaton teratons and we consder 3 busy profles that we can assgn to contractors: 1. avalable durng the frst and the second teraton wth equal probablty. In ths case, b = {0.5, 0, 0. Ths profle says that a contractor wll be able to respond durng the frst or the second teraton, but no later than the second teraton. These contractors respond durng the frst stages of the negotaton. 2. mostly busy durng the frst teraton, but avalable durng the second teraton for sure. In ths case, b = {0.9, 0, 0. Ths profle says that a contractor wll be able to respond durng the frst teraton n few stuatons, but t wll surely respond durng the second teraton. These contractors respond durng the mddle stage of the negotaton. 3. not avalable durng the frst teraton, but avalable durng the second and thrd wth equal probablty. In ths case, b = {1, 0.5, 0. Contractors havng ths profle do not respond durng the frst teraton, but they wll respond durng the second or the thrd teraton, no later than the thrd teraton. These contractors respond durng the last stages of the negotaton. In the experment, we assgn the three busy profles to contractors by followng a certan confguraton and for each confguraton we run a bundle of 2000 negotatons. We vary the percentage of contractors that have been assgned the three busy profles wth a step of 5%. For example, we start from (0, 0, 100), meanng that all the contractors have been assgned the thrd busy profle and then we contnue wth (0, 5, 95), (0, 10, 90),... (100, 0, 0), n the fnal confguraton all the contractors havng been assgned the frst busy profle. The values of the utltes u are randomly selected for each negotaton nstance assumng unform dstrbutons. For ths experment, we consder [u mn, u max ] = [0, 1]. The status of the contractor (as satsfyng or not satsfyng the requrements of the manager) s randomly selected for each negotaton nstance, accordng to the probablty c. We fxed the probablty c to 0.5 for all negotatons, for all confguratons and for all contractors. We are nterested n how each of the studed protocols performs n terms of outcome and message traffc for each confguraton of contractors. We run the negotatons n the experment for each negotaton protocol. Fgure 1 shows the utlty of the manager when usng the DTA protocol. The scale labelled frst shows the percentage of the contractors that can propose mostly durng the frst teratons of the negotaton,.e. they have been assgned the frst busy profle. The scale labelled mddle shows the percentage of contractors that have been assgned the second busy profle. The percentage of the contractors that have been assgned the thrd profle s not shown n the fgure, but t can be obtaned by takng nto account the fact that the sum of all the percentages s 100. The maxmum utlty for DTA s a lttle over 0.5, makng ths the most neffcent protocol n terms of utlty. The status of beng busy s not taken nto account by the 27

4 Fg. 1. Utlty for DTA manager when she s playng the DTA negotaton protocol,.e. f she selects a certan contractor then the task wll be assgned to her n any case. Nevertheless, f the assgned contractor cannot fnalze the task successfully then she wll report falure and consequently the manager wll retry the operaton of servce contractng by assgnng the task to another contractor. However, the utlty s almost the same for all confguratons, the average beng around 0.5. Fg. 2. Messages for DTA Fgure 2 shows the message statstcs for the same protocol. In terms of messages, DTA performs very well, beng the protocol wth the lowest number of messages, outperformng the other protocols by far. 28

5 Fg. 3. Utlty for CNET Fgure 3 shows the utlty for CNET, whch was expected to decrease as the number of contractors that propose durng the frst teraton decreases, because t receves less proposals and the probablty to receve good proposals (.e. of hgh utlty) decreases. An nterestng fact s that the utlty decreases almost exponentally as the number of contractors that propose durng the frst teraton decreases. Fg. 4. Messages for CNET The message count ncreases lnearly wth the number of contractors that propose durng the frst teraton (Fgure 4). For ICNET (Fgure 5), the utlty decreases almost as for CNET untl a pont where almost all contractors propose durng teratons 2 & 3. Then t grows back to the ntal maxmum very fast. 29

6 Fg. 5. Utlty for ICNET Fg. 6. Messages for ICNET 30

7 When most of the contractors propose durng teratons 2 & 3, the message count grows exponentally to over 400 (see Fgure 6. For the rest of the confguratons, the message count vares almost the same as for CNET. As future work we plan to expand the experments n at least two drectons: () to consder more complex negotaton nstances that take nto account more negotaton teratons, as well as that contractors mght change ther bds and managers can change ther strategy for acceptng contractors bds durng each teraton; () to consder more complex workflows nvolvng at least two nterdependent negotatons such that the contracted servce mght also nvolve contractng of other requred servces. References 1. Bădcă, C., Scafeş, M.: Conceptual Framework for Desgn of Servce Negotaton n Dsaster Management Applcatons. In: Ba, Q., Fukuta, N. (eds.), Advances n Practcal Mult-Agent Systems, Studes n Computatonal Intellgence 325, Sprnger Verlag (2010) 2. Paurobally, S., Tamma, V., and Wooldrdge, M.: A Framework for Web servce negotaton. ACM Transactons on Autonomous and Adaptve Systems 2(4), ACM Press (2007) 3. Scafeş, M., Bădcă, C., Pavln, G., and Kamermans, M.: Desgn and Implementaton of a Servce Negotaton Framework for Collaboratve Dsaster Management Applcatons. Proceedngs of the 2nd Internatonal Conference on Intellgent Networkng and Collaboratve Systems INCOS 2010, (2010) 4. Smth, R.G.: The Contract Net Protocol: Hgh-Level Communcaton and Control n a Dstrbuted Problem Solver. IEEE Transactons on Computers 29(12), IEEE Computer Socety (1980) 5. Yang, J., L, W.-L., and Hong, C.-Y.: An Improvement to CNCP n Large-Scale Mut-Agent System. Proccedngs of the 3rd Internatonal Conference on Innovatve Computng Informaton and Control ICICIC 08, 147 (2008) 31