1. Automated Negotiation for Grid Notification Services
Richard Lawley, Keith Decker, Michael Luck, Terry Payne and Luc Moreau
Intelligence, Agents, Multimedia Group
School of Electronics & Computer Science
University of Southampton

2. Automated Negotiation for Grid Notification Services
Outline
Introduction
Notification Services
Negotiation
Negotiation Engine
Evaluation of Negotiation Engine
Future Work & Conclusion
Introduction
Overview of Notification Services, the motivation behind this work
Brief discussion of negotiation
Design of our negotiation engine
Evaluation of the negotiation in terms of scalability and performance
Future work & conclusion
17/04/2019
Automated Negotiation for Grid Notification Services

3. Automated Negotiation for Grid Notification Services
Introduction
Providers need to inform clients of:
Changes to database content
New releases of tools or services
State changes in long-running jobs
Message-Oriented Middleware layer
Provider notifies middleware layer
Middleware layer informs clients
e.g. MQ Series, JMS, MSMQ
Distributed systems inform clients of updates
- Changes to db content, releases of tools & services, change in workflow execution state
More apparent when client can disconnect
Middleware layers remove need for the providers to deal with the comms
Message-Oriented Middleware solutions allow async, reliable comms.
Queuing products such as MSMQ, MQSeries, JMS -> robust implementations, reliable async comms
17/04/2019
Automated Negotiation for Grid Notification Services

4. Publish-Subscribe Model
Information is published on a topic
Consumers subscribe to an information topic
Publishers publish information on a topic
Updates are sent to subscribers S1 P1 NS S2
Publisher
Common model for MoM is publish-subscribe.
Information consumers subscribe to a topic
Publishers are information sources – the publish information on a topic
Published information is delivered by middleware layer to subscribed consumers
Scalable model, allows many publishers/subscribers for a topic
Notification Service
Subscriber
17/04/2019
Automated Negotiation for Grid Notification Services

5. Notification Services
Message-Oriented Middleware layer using Publish-Subscribe model
Responsible for asynchronous delivery of messages between publishers and subscribers
Can Filter & Combine Notifications allowing selective notifications and regular digest delivery
NS are form of MoM using publish-subscribe
Intermediaries responsible for async delivery of notifications between publishers & subscribers
NS receives updates from publishers, handles distribution & delivery to subscribed consumers.
NS can simply pass on notifications, or process
Allows filters, e.g. stock price updates – all vs. selected
Batch updates into digests – useful without permanent connection
NS used in many distributed systems – myGrid.
Other subs services used in grid systems, e.g. Grid Monitoring Architecture, logging comp of OGSA.
17/04/2019
Automated Negotiation for Grid Notification Services

6. Notification Service Examples
Grid Monitoring Architecture
(Tierney, Aydt, Gunter, Smith, Swany, Taylor and Wolski 2002)
Grid Notification Framework
(Gullapalli, Czajkowski and Kesselman 2001)
OGSA Notification Framework
(JaiPaul 2003)
NaradaBrokering
(Fox and Pallickara 2001)
myGrid
17/04/2019
Automated Negotiation for Grid Notification Services

7. Automated Negotiation for Grid Notification Services
myGrid
e-Science project aimed at Bioinformatics
Workflow-based in-silico experiments
Workflow specified how an experiment should be composed
Experiments can be long-running
Notification Service communicates results
NS also used between services
17/04/2019
Automated Negotiation for Grid Notification Services

8. myGrid - Bioinformatics
Bioinformatics is data-intensive
SWISS-PROT Protein Knowledgebase
Over past 14 months has grown by 20%, with approximately 200 changes per day
 Constantly expanding
Query to find new annotations or sequences that are similar to existing sequences
17/04/2019
Automated Negotiation for Grid Notification Services

9. Notification Services - Problems
Providers and Consumers can specify QoS constraints
Notification frequency
Price paid
Mismatch in preferences of provider & consumer
Consumer wants updates immediately and for free
Producer wants to publish regular updates and charge
Notification Services do not address this problem
Negotiation can find mutually acceptable values
Mechanisms for async notifications understood & implemented, issues:
Current NS, consumers specifies topic & delivery constraints
Delivery constraints are QoS issues. Provider and consumer have different prefs. [eg]
Not aware of NS addressing this
Negotiation can find mutually acceptable values for QoS issues
17/04/2019
Automated Negotiation for Grid Notification Services

10. Automated Negotiation for Grid Notification Services
“The process by which two or more parties exchange proposals in order to reach a mutually acceptable agreement on a particular matter”
Components of negotiation
Item – the object under negotiation
Proposals – set of values suggested by one party
Preferences – values acceptable to a party
Utility functions – a method of evaluating the utility of a particular proposal
Negotiation is “The process by which two or more parties exchange proposals in order to reach a mutually acceptable agreement on a particular matter”.
Key in autonomous systems where components have no direct control, need to work together by persuading each other.
Negotiations concern items & negotiation terms.
Items – what the negotiation is over [car]
Terms – attributes of item under negotiation [length of warranty, price]
Negotiations work by exchanging proposals
Proposals accepted  successful termination
Proposal rejected  turn down or offer counter-proposal
Proposal evaluated for utility – how much a proposal is worth to a participant
Prefs represent ranges of acceptable values
17/04/2019
Automated Negotiation for Grid Notification Services

11. Automated Negotiation for Grid Notification Services
Negotiation Protocols
Set of rules governing a negotiation
Types of participants
Valid negotiation states & actions
Negotiation Strategies
How a participant will behave (within protocol)
How to generate proposals
When to accept proposals
Negotiation – protocols & strategies
Protocols – rules governing interactions (types of participant, valid states & actions, constraints [each bid must exceed current highest by…])
Strategies – define how participant will behave within protocol. (How to respond to an offer, how to generate initial offers, when to accept)
Strategies kept private, as knowing opponent’s strategy can give you an advantage at their expense.
17/04/2019
Automated Negotiation for Grid Notification Services

12. Automated Negotiation for Grid Notification Services
Cooperative Negotiation
Preferences and utility functions shared
Social Welfare (benefit to all parties) is primary objective
Competitive Negotiation
Private preference and utility functions
Personal benefit is primary objective
Competitive Negotiation chosen for Notification Service
Hard to share utility functions & preferences if they depend on locally-sensed environmental factors
Notification Service may be used in competitive environment, e.g. service providers competing for business
Protocols – competitive/cooperative
Cooperative – Prefs & Utility functions shared. Optimal can be found. Maximise social welfare
Competitive (opposite) – Prefs & Utility functions kept private. Maximise own welfare.
Some cases in distributed systems warrant cooperative, competitive selected.
Prefs & Utility functions can’t always be shared – Dynamic, locally-sensed environmental values
Competitive negotiations keep this local even if privacy isn’t really required
Allows competitive scenarios, e.g. competing for business
17/04/2019
Automated Negotiation for Grid Notification Services

13. Negotiation Engine – Definitions
Negotiations are between requester and requestee
Conditions negotiated over are negotiation terms
A proposal contains values for negotiation terms
Conversation between requester & requestee is a Negotiation Thread
Number of proposals exchanged is the Negotiation Thread Length
Preferences specify acceptable ranges
Ideal value – sensible “ideal world” value
Reservation value – limit of acceptability
Definitions:
Negotiations between requester & requestee. Requester normally client.
Conditions being negotiated are negotiation terms. Proposal = set of suggested values for all terms.
Conversation between requester & requestee = negotiation thread
Number of proposals exchanged = negotiation thread length
Prefs specify ranges of acceptable values – two values
Ideal – sensible ideal world value
Reservation – Beyond this is unaccaptable
Negotiation Engine conceptually regarded as single shared entity, implemented as one component in each of the requestee & requester, allowing privacy of prefs & utility functions and access to local sensors.
17/04/2019
Automated Negotiation for Grid Notification Services

14. Automated Negotiation for Grid Notification Services
Negotiation Process
Diagram- Interactions occurring in negotiation with our engine.
Start – both parties initialise prefs
Requester initiates negotiation
NC generates proposal using prefs, sends it
Proposal is received and counter-proposal generated
Both proposal evaluated
Previous two steps can include callbacks
Utility of each proposal compared
Utility of incoming proposal highest, accept negotiation and both components signal acceptance
Utility of generated proposal highest, check deadline before sending counter-proposal back. If deadline expired, terminate negotiation and indicate failure.
Repeat cycle until termination state.
Termination States:
Proposal Accepted
Deadline Expired
Explicit Termination (not shown)
If accepted, no commitment. Allows many negotiations to run, making commitment with one offering the best deal.
Dynamically discovering parties with which to negotiate is beyond the scope of this- use a Service Discovery broker for that.
17/04/2019
Automated Negotiation for Grid Notification Services

15. Automated Negotiation for Grid Notification Services
Negotiation Model
Bilateral Service-Oriented Negotiation Model
Based on Negotiation Decision Functions
(Faratin, Sierra & Jennings 1998)
Automated negotiation using external factors in proposal generation/evaluation
Model only handles negotiation protocol
External program provides inputs to proposal generation & evaluation process
Negotiation model based on bilateral service oriented model (one party, many issues)
Taken from Faratin et al 1998
Allows much of the negotiation process to be automated still allowing external factors.
A program can use negotiation engine to negotiate without knowing the protocol, but retaining some influence over the strategy.
17/04/2019
Automated Negotiation for Grid Notification Services

16. Automated Negotiation for Grid Notification Services
Negotiation Model
Proposals generated by tactics and strategies
Tactics – function evaluating a single negotiation term
Time-dependant
Resource-dependant
Imitative
Strategies – way of weighting different tactics
Can vary over course of negotiation
Favour time-dependant tactics towards deadline
Proposal utility = weighted summation of utility of each term in proposal
Proposal accepted when U(Pincoming) > U(Pgenerated)
Proposals generated using tactics & strategies
Tactics – Functions generating a value for a single negotiation term for inclusion in a proposal
Types: Time-dependant, Resource-Dependant, Imitative
Multiple tactics can be used with weightings
Weightings can vary throughout negotiation [eg]
Strategy determines weightings and how to vary
Utility functions applied to each term, Proposal utility = weighted summation of individual utilities
Proposals acceptable when incoming proposal higher utility than generated one
17/04/2019
Automated Negotiation for Grid Notification Services

17. Evaluation of Negotiation Engine
Evaluate suitability for Notification Service
Experiment setup based on original evaluation
Variables grouped into environments
Preferences and Deadlines
Repeatedly running in same environment yield identical results
Range of environments generated and used for all of the experiments
Single tactic used for each party
All tactics played against each other
Verify suitability of NE for Grid NS, check performance & scalability.
Number of expts performed.
Setup:
All variables (Deadline, Prefs) grouped into environments
Running negotiation in same envt twice should yield same results
Single tactic used by each participant in a negotiation
All tactics played against each other
Imitative tactics ignored, previously found to be out-performed by time & res dependant. Maybe considered again later.
17/04/2019
Automated Negotiation for Grid Notification Services

18. Exp1: Variable Deadline
“What affect does varying the deadline have on utility and success rate?”
Deadlines measured in number of messages
No communication overhead in test setup
Vary deadline (1-100 messages). Measure utility and success rate.
Hypothesis – Utility and success rate will be poor with shorter deadlines.
Often important to negotiate quickly to acquire service in time to start soon.
What affect does varying deadline have on utility & success rate?
Deadlines = number of messages exchanged (no comms overhead). Real world, comms time significant.
Prediction: Deadline will be poor with short deadlines, increasing as deadlines extend. Success rate similar.
17/04/2019
Automated Negotiation for Grid Notification Services

19. Exp1: Variable Deadline – Results
Higher utilities achieved with longer deadlines
Approaches optimal utility
Higher success rates with longer deadlines
Moves towards 100% success rate
Left Graph- Utility of both parties as deadline varied. Optimal utilities calculated and plotted (straight lines)
With very short deadlines, very poor utility. As deadlines increase, utility moves towards optimal.
Right Graph- Success rate as deadline varied. Short deadline, most negotiations fail. As deadline increases, success rate increases.
Given long enough to negotiate, almost all negotiations would be successful.
17/04/2019
Automated Negotiation for Grid Notification Services

20. Exp1: Variable Deadline - Results
Plot time used against utility achieved
Utility increases as time used decreases
Explained by plotting overlap of prefs (Φ) against messages
Examining results more closely, how much of available time used in each case?
Plot utilities & time used, sort by requester utility.
Unexpected trend- negotiations completing quicker were getting better results.
Only solution we could think of- the short negotiations had more favourable environments.
Plotted messages against Phi, controlling overlap.
This was indeed the case, so the only reason that this was happening was that these were the more favourable randomly-generated environments.
17/04/2019
Automated Negotiation for Grid Notification Services

21. Automated Negotiation for Grid Notification Services
Exp2: Multiple Terms
Negotiations typically over many terms
e.g. price, duration, frequency
Is Utility affected by number of terms?
Number of terms varied between 1 and 25
All terms weighted equally
Deadline varied between 30 and 60 (random)
Record utilities and execution time (CPU time)
Prev experiment had only 1 term.
Normally service-oriented negotiations would use multiple terms [price, duration, frequency]
How does system behave when using more terms?
Vary terms between 1 & 25, equally weighted.
Vary deadline randomly.
Measure utilities & execution time
17/04/2019
Automated Negotiation for Grid Notification Services

22. Multiple Negotiation Terms - Results
As number of terms increases, utility remains fairly constant
Only valid when all terms weighted equally
Execution time is linearly related to the number of terms
Top Graph= Average & Optimal Utilities.
As number of terms increases, utilities remain constant & close to optimal.
Because equally weighted, and the negotiation engine conceded on all terms simultaneously.
Different story if unequal weightings or model is changed to concede on single terms at a time.
Bottom Graph= Execution time.
CPU usage is linearly related to number of terms.
Fluctuations explained by garbage collection?
17/04/2019
Automated Negotiation for Grid Notification Services

23. Automated Negotiation for Grid Notification Services
Exp3: Execution Time
Is execution time linearly related to number of messages?
Deadlines varied between 30 and 60
Minimum, average (over 100 runs) and maximum execution times measured for each deadline
Communication delays are ignored as in test setup components are coupled directly together
Third experiment measures execution time with number of messages exchanged, so that longer negotiations don’t behave unexpectedly.
Deadlines varied 30-60
Min, Av & Max execution times recorded over 100 runs.
Again, comms delays ignored
17/04/2019
Automated Negotiation for Grid Notification Services

24. Exp3: Execution Time - Results
Minimum and mean execution times linearly related to number of messages
Maximum execution time has unpredictable peaks
Garbage collection?
Only in minority of cases as mean is close to minimum
Graph shows min, mean & max times related to number of messages.
Min & Mean (Green & Red) appear to be linearly related to number of messages
Max time (blue) has spikes. Most likely Garbage collection, only occurs in minority of cases (mean is close to minimum)
Conclude that execution time is linearly related to number of messages.
17/04/2019
Automated Negotiation for Grid Notification Services

25. Notification Service Example
Example from Bioinformatics field
SWISS-PROT Protein Knowledgebase
Over past 14 months has grown by 20%, with approximately 200 changes per day
 Constantly expanding
Query to find new annotations or sequences that are similar to existing sequences
Example of how Notification Service would benefit from Negotiation Engine, example from Bioinformatics field.
SWISS-PROT is a curated protein sequence knowledgebase, with High level of annotation, minimal redundancy, high integration with other DBs
Last 14 months, 20% growth, 200 changes per day
Constantly expanding
KB can be queries for annotations/sequences that match existing specified sequences
17/04/2019
Automated Negotiation for Grid Notification Services

26. Notification Service Example
Assumptions
1000 Subscribers, each with 100 sequences they want matched
Searches can be run iteratively to refine results
Subscriber would like to be notified of changes every 5 hours
For our example:
1000 Subscribers
Each want to get results for queries against 100 sequences
Searches can be iterative to refine results
Subscribers would like results every 5 hours
17/04/2019
Automated Negotiation for Grid Notification Services

27. Notification Service Example
By accepting subscriber requests, 5,000,000 searches per day required
Use negotiation over two terms:
Frequency (time between notifications)
Provider preference: hours
Subscriber preference: hours
Number of iterations
Provider preference: 1-3
Subscriber preference: 5-1
Accepting requests  5m searches/day
Negotiation allows provider to persuade client to use lower figures
Experiment uses 2 terms
Frequency (Provider: h/1-7d, Client: 5-120h)
Iterations (Provider: Max 3, ideally 1. Client, ideally 5, low 1)
17/04/2019
Automated Negotiation for Grid Notification Services

28. Notification Service Example
Provider preferences kept constant
Consumer preferences vary by a small random amount
Deadlines between 30 and 60 messages
After running negotiations:
Average Frequency: 67.6 hours
Average Iterations: 2.31
 651,000 searches per day (87% reduction)
Provider prefs remain constant
Consumer prefs varied by small random amount
Deadlines randomly varied
After running:
Average Frequency: 67.6h
Average Iterations: 2.31
 651,000 searches per day (87% reduction)
Introducing negotiation over QoS instead of accepting client’s original request has significantly reduced amount of work needed to be done by provider
17/04/2019
Automated Negotiation for Grid Notification Services

29. Notification Service Example
Number of queries required for each outcome plotted against provider utility
Shows how utility decreases as the number of queries increases
Show how provider utility in the system is related to the amount of work they do:
Calculate number of queries for each outcome
Plot this against utility
Utility observed by provider decreases quickly as amount of work required increases.
17/04/2019
Automated Negotiation for Grid Notification Services

30. Notification Service Example
Greater utility is represented by needing to do fewer queries for a provider
Using Negotiation allows the provider to increase their utility and still satisfy needs of consumer
Introducing Negotiation may reduce consumer utility, but would allow more consumers to be serviced
We have demonstrated: Provider sees greater utility in this situation by doing fewer queries
Using Negot allows provider to increase utility while satisfying consumers
NB: Increasing utility of provider comes at cost of consumer utility.
Introducing negotiation may lower consumer utility, but as load on provider has decreased it can satisfy more consumers
Negotiation also opens new opportunities
Being able to pay for a higher QoS if required, while still allowing basic service for free/low cost.
17/04/2019
Automated Negotiation for Grid Notification Services

31. Automated Negotiation for Grid Notification Services
Future Work
Peer-to-peer Notification Services
Notification Services talking to Notification Services
Consumers subscribing to single service, receiving updates from elsewhere
Future work.
Our future work is motivated by peer-to-peer notification services
Similar to NS discussed earlier, but using many interconnected notification services.
Instead of publisher & subscriber connecting to same NS, connect to different ones
* Notification Service handles the distribution of notifications throughout the network from the publisher to the subscriber.
Also possible for subscribers to disconnect from one and reconnect to another NS and still receive their notifications.
NS1
NS2 P2 S1
Publisher
Notification Service S2 P1
NS3
Subscriber
NS4
17/04/2019
Automated Negotiation for Grid Notification Services

32. Automated Negotiation for Grid Notification Services
Future Work
Support negotiations for peer-to-peer notification service by supporting chained negotiation
Negotiations with intermediaries
Negotiations where intermediaries may be able to satisfy request with existing commitments
Integrate with myGrid Notification Service
To support P2P NS
Negotiation process needs to support Chained Negotiations
Negotiations with Intermediaries between provider & subscriber
Simplest case: Proxy (pass proposals through)
Medium case: Take a cut
Final case: Chained negotiation is series of simple negotiations. Intermediary tries to satisfy with existing commitments.
Negotiation should look no different to end provider & subscriber.
We then intend to integrate this work with the myGrid Notification Service, which is a peer-to-peer notification service.
17/04/2019
Automated Negotiation for Grid Notification Services

33. Automated Negotiation for Grid Notification Services
Conclusion
Negotiation in a Notification Service allows differences in QoS preferences to be resolved
Negotiating over QoS allows a provider to support more clients
In conclusion,
Shown need for negotiation in Notification Services
allows requesting mutually acceptable quality of service levels
Shown design of negotiation engine & demonstrated suitability for Grid NS
Specific Example for NS, showing negotiation over QoS would allow a provider to service more clients.
17/04/2019
Automated Negotiation for Grid Notification Services

34. Automated Negotiation for Grid Notification Services
Questions?
17/04/2019
Automated Negotiation for Grid Notification Services