presentation for the web - Goldsmiths, University of Londonmas01mu/presentations/distarms.pdf · 2 Distributed Resource Allocation via Local Strategies presentation by Marian Ursu,

1

Distributed Resource Allocation via Local Strategiespresentation by Marian Ursu, 1 December 2003 @ Adastral Park, BT © Marian Ursu & Botond Virginas

Distributed Resource Allocation via Local Strategies

BT Exact & Goldsmiths College, University of LondonDr. Marian Ursu & Dr. Botond Virginas


Collaborator

formulate as single optimisationproblem and employ iOpt formulate as multiple

optimisation problem and attempt to extend iOpt for this formulation

formulate as multiple optimisation problem and develop own optimisation algorithm

formulate as trading problem and develop own trading algorithms

not considered


outline

• part #1: reiterate basic principles• part #2: prototype solution: design and implementation• part #3: prototype solution: results and analysis• part #4: general directions for further work


part #1basic principles


location Blocation C

location H

location Y location Z

formulation as a trading problem

shortages agent

surpluses agent

location A

GUI

GUI

local manager

configuration

control

beginning of process

during process


results may be portable to other areas, outside ‘resource allocation’

more flexible : provides better means for controlling local behaviour

resource allocation via agents and local strategies

more accurate representation of the “real life” system

natural formulation for distributed computations

motivation

does not mean it will achieve better performance

gives local managers a better sense of control and thus its prospects of acceptance/success are higher

possible increase in efficiency over other solutions

travelling planning problem – “hot” research area (Chris)

2


basic design : 4 step communication protocol

• [shortages] local choices; broadcast requests (not binding) • [surpluses] local choices; reply with offers (not binding)• [shortages] local choices; reply with contract proposal (binding)• [surpluses] local choices; reply with agreed contracts (binding)

shortages agent

location X

surpluses agent

location Y

• simple but versatile process; many extensions possible:• surpluses have initiative; bidding; more steps in

communication protocol … (discuss later)


part #2prototype solution — design and implementation


data model — assumptions

• a jobs-agent holds a number of jobs that have to be carried out at a particular site

• each job has the duration of one day• a job is characterised by an id a required skill and a day when it is

required• a shortage is a job to which the requesting job-agent and its location

are associated• an engineers-agent holds a number of engineers and the days when

they are idle• an engineer has an id and a set of skills• a surplus is an engineer with an attached day when he is idle and the

jobs agent to which he is assigned


sam

ple

data

SURPLUSES Skills

Engineers Agent Location Engineer Id Skills Day 1 Job Day 2 Job Day 3 Job 1 2 3 4 5 6 7 1 5 e1 1, 2 e2 1, 2 e3 2, 3, 4, 5 2 6 e4 2, 3 e5 1, 2 e6 5 3 7 e7 5, 6 e8 6, 7

SHORTAGES

Jobs Agent Location Job Id Skill Day 1 Eng Day 2 Eng Day 3 Eng 1 1 job1 1 job2 2 job3 5 job4 3 job5 4 2 2 job6 4 job7 5 job8 5 job9 1 job10 2 3 3 job11 1 job12 2 job13 1 job14 3 job15 5


implementation

• technology: Java’s BEA Web-Logic Business Platform• employ one topic for all messaging• synchronisation required for the implementation of the 4 step

communication protocol• via one monitor (agent) and messaging

• “extra” 2 steps implemented • reporting• reset of iteration-variables (implementation motivated)


basic algorithm — step 0 — launch

Master start broadcasting

_JobsAn

_JobsA1

TOPIC

‘broadcast’ can start

Monitor start broadcasting

3


basic algorithm — step 1

• jobs agents broadcast requests for jobs to engineers agents• all local shortages are broadcast to all engineers agents


step 1 — broadcast requests for jobs

_JobsAn

Monitor

_JobsA1

source skill day

JA1 S1 1

JA1 S2 1

JAn S3 1

JA1 S2 2

JAn S4 5

broadcasting complete

_EngsAm

_EngsA1

TOPIC

‘compileAndSendOffers’ can start

‘compileAndSendOffers’ can start

JA1 finished broadcast

JAn finished broadcast



• engineers agents compile and respond with offers for jobs• the offers for each jobs agent are compiled independently from the

others• the offers for each day are compiled independently from the

others• the algorithm for compiling offers is “first found first served”• offers are non-binding


step 2 — send offers

_EngsAm

Monitor

_EngsA1

to skill day

JA1 S1 1

JA3 S2 1 JA1 S3 1

JA6 S2 2

_JobsAn

_JobsA1

TOPIC

‘selectAndSendProposals’ can start

‘selectAndSendProposals’ can start

from

EA1

EA1

EAm

EA1

JAn S4 5 EAm

offering complete complete

EA1 finished offers

EAm finished offers



• jobs agents select offers and send contract proposals• selection:

• if more than one offers are made for one job, select the one from the nearest location

• if more than one job are similarly near, select the first one (yet again, “first found first served”)

• if a single offer is made for one job, select it• contract proposals are binding


step 3 — send contract proposals

_JobsAn

Monitor

_JobsA1

to skill day

EA4 S1 1

EA1 S2 1 EAm S3 1

EA7 S2 2

_EngsAm

_EngsA1

TOPIC

‘selectAndSendContracts’ can start

‘selectAndSendContracts’ can start

from

JA1

JA1

JAn

JA1

EA2 S4 5 JAn

proposals complete complete complete

JA1 finished proposals

JAm finished proposals

4



• engineers agents select contract proposals and sendcontracts• selection:

• if more than one contact proposals are made for one surplus (engineer-day), select the one from the nearest location

• if more than one propsal are similarly near, select the first one (yet again, “first found first served”)

• if a single contract proposals is made for one surplus, select it• contracts are binding


step 4 — send contracts (endorse proposals)

_EngsAm

Monitor

_EngsA1

to skill day

LA S2 1

LZ S3 1

LQ S2 2

_JobsAn

_JobsA1

TOPIC

next iteration

from

L1

LX

L2

start broadcasting complete

EA1 finished offers

EAm finished offers next iteration


overall design

EngsAcollectAndFilterRequestscompileAndSendOfferscollectAndFilterProposalssetAndSendContracts

JobsAbroadcastJobscollectandFilterOfferscompileAndSendProposalsreceiveContracts

MonitorlaunchBroadcastingcheckFinishedBroadcastingcheckFinishedSendingOfferscheckFinishedSendingProposalscheckFinishedSendingContractsallocationStepCompleted

for other details refer to the source code


part #3prototype solution — results and analysis


user interface

• data inputted directly in the source code (‘Master.java’)• results reported both to the standard output and to files• data imported from files to Excell• visualisation – “by hand”• for a prototype, this was the simplest solution


dist

AR

MS

_v.9

—da

tase

t #1

—1

itera

tion

1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

��

��

� ��

� ��

��

LO C AT IO N S

5


distARMS_v.9 — dataset #1 — 1 iteration

S U RP L US E S D ay-w hen-id le is hashed S k il ls

E n gin eers Agen t L ocation E ng ineer Id S k ills D ay 1 Jo b D ay 2 Jo b D ay 3 Job 1 2 3 4 5 6 7 1 5 e1 1 , 2 job11 e2 1 , 2 job12 e3 2 , 3, 4 , 5 job6 job14 2 6 e4 2 , 3 job2 e5 1 , 2 job1 e6 5 job15 3 7 e7 5 , 6 job3 e8 6 , 7

S H O R TAG E S

Job s Ag en t L ocation Job Id S k ill D ay 1 Job sA D ay 2 Job sA D ay 3 Jo bsA 1 1 job1 1 e5 job2 2 e4 job3 5 e7 job4 3 job5 4 2 2 job6 4 e3 job7 5 job8 5 job9 1 job10 2 3 3 job11 1 e1 job12 2 e2 job13 1 job14 3 e3 job15 5 e6


dist

AR

MS

_v.9

—da

tase

t #2

—1

itera

tion

1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

� ��

� ��

��

� ��

��

��

LO C A T IO N S


SURPLUSES Day-when-idle is hashed Skills

Engineers Agent Location Engineer Id Skills Day 1 Job Day 2 Job Day 3 Job Day 4 Job Day 5 Job 1 2 3 4 5 1 5 e1 1, 2, 4 job10 job4 job20 e2 1, 2 job11 job5 e3 4, 5 job12 job14 2 6 e4 1, 3 job13 e5 2, 3 e6 2, 3 3 7 e7 2, 3 job22 job24 e8 2, 3 job25




SHORTAGES

Jobs Agent Location Job Id Skill Day 1 Eng Day 2 Eng Day 3 Eng Day 4 Eng Day 5 Eng 1 1 job1 1 e1 job2 2 job3 5 job4 1 e1 job5 2 e2 job6 1 job7 5 job8 3 job9 3 2 2 job10 1 job11 2 e2 job12 5 e3 job13 1 e4 job14 5 e3 job15 5 job16 5 job17 3 3 3 job18 3 job19 5 job20 2 e1 job21 4 4 4 job22 3 e7 job23 5 job24 2 e7 job25 3 e8


1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

��

��

��

��

��

��

s1, s2, s4

s1, s2 s4, s5

s1

s2

s5

s1

s5

s2

DAY1

dist

AR

MS

_v.9

—da

tase

t #2

—1

itera

tion the offer for s1 (J2)

from E1 was made via the eng {s1, s2, s4}

(the same as for J1); this is why the eng

{s1, s2} was assigned to s2 in J2

in one run of the program, the eng {s1, s2, s4} was assigned to J1 (see above) and in another run to J2

(still for s1); the behaviour of the

program is “non-deterministic”


1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

��

��

��

��

��

��

s1, s2, s4

s1, s2 s3

s5

s1, s3

s2, s3

s2, s3 s2, s3 s2, s3 s3

s2

s4

s2 s3

DAY5

dist

AR

MS

_v.9

—da

tase

t #2

—1

itera

tion

an example of a bad allocation

this is due to the “first found first served” algorithm

eng {s1, s2, s4} is the one to be offered to J3 for s2 and thus s4(J3) remains uncovered; both jobs would have been covered if {s1, s2} had been offered for s2(J3)

6


distARMS_v.11 — dataset #2 — 3 iterations

SURPLUSES Day-when-iddle | Allocation (iteration) Skills

Engineers Agent Location Engineer Id Skills Day 1 Job Day 2 Job Day 3 Job Day 4 Job Day 5 Job 1 2 3 4 5

1 5 e1 1, 2, 4 •••••••••••• j1(1) •••••••••••• j4(1) •••••••••••• j20(1)

e2 1, 2 •••••••• j2(1) •••••••• j5(1) ••••••••

e3 4, 5 •••••••• j12(1) •••••••• •••••••• j14(1)

2 6 e4 1, 3 •••••••• j13(1) •••••••• j8(3) •••••••• j17(2)

e5 2, 3 •••••••• •••••••• j9(3)

e6 2, 3 •••••••• ••••••••

3 7 e7 2, 3 •••••••• j22(1) •••••••• j24(1)

e8 2, 3 •••••••• j18(2) •••••••• j25(1)


distARMS_v.11 — dataset #2 — 3 iterations

SHORTAGES

Jobs Agent Location Job Id Skill Day 1 Eng Day 2 Eng Day 3 Eng Day 4 Eng Day 5 Eng

1 1 job1 1 e1(1) job2 2 e2(1) job3 5 job4 1 e1(1) job5 2 e2(1) job6 1 job7 5 job8 3 e4(3)

job9 3 e5(3) 2 2 job10 1 job11 2 job12 5 e3(1)

job13 1 e4(1) job14 5 e3(1) job15 5 job16 5

job17 3 e4(2) 3 3 job18 3 e8(2) job19 5 job20 2 e1(1)

job21 4 4 4 job22 3 e7(1) job23 5 job24 2 e7(1)

job25 3 e8(1)

the

algo

rithm

con

verg

esan

d te

rmin

ates


distARMS_v.11 — datasets #3 and #4

• 5 runs are exemplified• non-deterministic behaviour due to:

• technology• small alterations to program, but which did not alter at all the

algorithm and the data structures employed• e.g., changes to a “System.out.println” statement

• changes to data structures (but not to the “arrangement” of data)• e.g., use of vector instead of array, but preserved the order of the

elements

• good performance in terms of convergence • even with this simple algorithm!

• run takes less than 1 minute; terminates in 2 iterations


1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

10

12

11

10 11 12

1

2

3

4

5

6

7

8

9

10 11

12

13

2 ��

3 ��

1 ��

4 ��

5 �� 7 ��

6 ��

8 ��

9 ��

11 ��

12 �� 10 ��

13 ��

14 ��

18 ��

17 ��

15 ��

16 ��

20 ��

19 �� 21 ��

22 ��

23 ��

1

2

3

4

5

6

dist

AR

MS

_v.1

1 —

data

set #

3 —

1 ite

ratio

n —

run#

1

drawback:e13 should have been allocated to JA6 (purple), because it is nearerexplanation:- EA2 made offer (e8 or e9) for the same job of JA6(purple) for which EA4 made the offer (via e13);- JA6 chose an engineer from EA2 (although EA2 and EA4 are at the same distance, the offer from EA2must have arrived first);- in next step EA2 chose the proposals made by JA2solution- make offers for skills not for jobs- the drawback would have still remained if EA2 would have made offers for both purple jobs


dist

AR

MS

_v.1

1 —

data

set #

3 —

1 ite

ratio

n —

run#

2

1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

10

12

11

10 11 12

1

2

3

4

5

6

7

8

9

10 11

12

13

2 ��

3 ��

1 ��

4 ��

5 �� 7 ��

6 ��

8 ��

9 ��

11 ��

12 �� 10 ��

13 ��

14 ��

18 ��

17 ��

15 ��

16 ��

20 ��

19 �� 21 ��

22 ��

23 ��

1

2

3

4

5

6


dist

AR

MS

_v.1

1 —

data

set #

3 —

2 ite

ratio

ns

1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

10

12

11

10 11 12

1

2

3

4

5

6

7

8

9

10 11

12

13

2 ��

3 ��

1 ��

4 ��

5 ��

7 ��

6 ��

8 ��

9 ��

11 ��

12 �� 10 ��

13 ��

14 ��

18 ��

17 �� 15 ��

16 ��

20 ��

19 �� 21 ��

22 ��

23 ��

1

2

3

4

5

6

7


dist

AR

MS

_v.1

1 —

data

set #

4 —

1 ite

ratio

n —

run#

3

1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

10

12

11

10 11 12

1

2

3

4

5

6

7

8

9

10 11

12

13

2 ��

3 ��

1 ��

4 ��

5 �� 7 ��

6 ��

8 ��

9 ��

11 ��

12 �� 10 ��

13 ��

14 ��

18 ��

17 ��

15 ��

16 ��

20 ��

19 �� 21 ��

22 ��

23 ��

1

2

3

4

5

6

26 ��

24 ��

25 �� 27 ��

30 ��

31 ��

29 ��

28 ��

32 ��

33 ��


dist

AR

MS

_v.1

1 —

data

set #

4 —

2 ite

ratio

ns

1 2 3 4 5 6

1

2

3

4

5

6

7

8

9

7 8 9

10

12

11

10 11 12

1

2

3

4

5

6

7

8

9

10 11

12

13

2 ��

3 ��

1 ��

4 ��

5 �� 7 ��

6 ��

8 ��

9 ��

11 �� 12 ��

10 ��

13 ��

14 ��

18 ��

17 ��

15 ��

16 ��

20 ��

19 �� 21 ��

22 ��

23 ��

1

2

3

4

5

6

26 ��

24 ��

25 ��

27 ��

30 �� 31 ��

29 ��

28 ��

33 ��

32 ��


analysis of this particular implementation


simple algorithm yet very promising results

• simple algorithm• “first found first served” for offers [Engs]” +

“nearest location” + then, “first found first served” for proposals [Jobs] + “nearest location” + then, “first found first served” for contracts [Engs]

• day-independent allocations• offers compiled independently for different jobs agents

• good results• good convergence towards optimal solution

• use of resources is maximised within smallest neighbourhood

• more refined/complex algorithms should lead to even better results


non-deterministic behaviour

• non-deterministic behaviour within similarly good solutions• due to technology (message handling by the topic)• due to syntax (within same semantics); both

• syntax of parts not related to allocation algorithm• syntax of parts related to allocation algorithm

• sensitive to ordering of data


offers

• first found first served (illustrated)• surpluses that match unallocated shortages may be left unused;

possible (partial) solutions:• run many iterations of the algorithm – OK • do not use an engineer in more than one offer per day (too restrictive)• explore heuristics

• e.g. “if an engineer was used in an offer for a certain day, then attempt to use another engineer for another offer for that day (assuming that the former engineer could be used in the latter offer as well); however, if no other engineer is available for the other offer, then still use the first engineer (rather than not being able to make an offer)”

• in other words: balance the number of offers in which engineers are involved

• explore optimisation criteria• maximise number of offers made and minimise number of engineers sent (or

travelling distance)

• drawback due to offers being made on jobs not on skills (illustrated)

8


other directions for development

• go beyond the model of independent days• balance allocations on periods greater than one day

• employ database in implementation• data analysis could be substantially facilitated

• extend the data model• engineers’ preferences (for jobs, locations, days, …)• composite jobs (requiring different skills, prerequisite jobs, …)• importance of jobs; variable duration of jobs; …• …

• …


part #4general directions for further work


emergent behaviour + intelligence in leaves

• the behaviour of the distributed algorithm proposed here is difficult to predict as soon as the number of resources and surpluses becomes a second digit figure • experiments and good analysis tools (both analytical and visual)

are required for the identification of trends

• hypothesised trends may then be proved mathematically

• this is a rich research area• the AI community displays an ever growing interest in emergent

behaviour in distributed intelligent systems• there is a conceptual move towards the principle “the

intelligence is in the leaves” (MIT Media Lab)


heuristics vs. local optimisation

• a local strategy (within an agent) can be expressed either as a set of rules or as a set of criteria • rules – describe how the solution is to be constructed• criteria – describe what the solution should look like

• although rules seem to lead to a procedural approach, it is possible to develop a (declarative) language in which to expressheuristics and have this language interpreted


algorithm

• collaboration heuristics• e.g., use “preferred partners” have preference (sic!)

• competition heuristics• strategies to attract resources/requests

• ask for more than you need

• system of penalties• pay if you cannot honour what you requested/advertised for

• ordering/importance of heuristics• e.g., soft and strong (heuristics/constraints)

• timing• eliminate the 4 step synchronisation algorithm

• resources: keep local reserves


analysis of results

• define• acceptable/satisfactory solution• good and bad solution• better, when comparing two solutions

• define algorithms and tools that can be used in the measuring ofthese qualitative descriptors • DB queries• statistical measures (data mining like algorithms)• visualisation techniques

Documents

presentation for the web - Goldsmiths, University of Londonmas01mu/presentations/distarms.pdf · 2 Distributed Resource Allocation via Local Strategies presentation by Marian Ursu,