Scalability Aspects of Agentbased Naming Services

1
Scalability Aspects of Agent-based Naming
Services

• Todd Wright, Karl Kleinmann
• BBN Technologies
• twright_at_bbn.com, kkleinmann_at_bbn.com

2
Outline

• Introduction to Agent Naming Services
• Cougaar White Pages Design
• Experimental Results
• Accuracy of Model-Based Predictions
• Conclusions and Future Work

3
Introduction

• Why do agents need a naming service?
• A White Pages (WP) maps an agent name to a
  physical address (e.g. agent X is on host Y)
• A WP is required in distributed systems that
  contain dynamic entities (e.g. dynamically
  added/removed/mobile agents)
• The WP primarily supports the Message Transport
  Service (MTS)
• Why not use a standard naming solution? (LDAP,
  DNS ...)
• Our target application has custom requirements
  (e.g. frequent agent mobility, integrated
  security policies, ..)
• We wanted to explore the benefits of an
  agent-based approach
• Why build an agent-based WP?
• Ease of integration with the agent system
• Leverage the capabilities of the underlying agent
  framework
• Support complex, agent-like behavior

4
Cougaar Background

• Cougaar Agent Architecture
• Open-Source Java-based Agent Framework
• DARPA-funded research (8 years, multiple
  programs)
• Used in several real-world applications (military
  logistics, inventory control, ...)
• Significant WP requirements
• Support 1000 agents distributed over 100 hosts
• Rapid, dynamic agent mobility
• Focus on Security and Robustness

http//www.cougaar.org
5
Cougaar White Pages Design

• Agent-based design
• Implemented WP servers as agents
• Integrated client-side WP caches
• Two-tier design
• Clients can talk to any server
• Servers replicate between one another
• Leases used throughout
• Client-side leases on cached lookup data
• Server-side leases on bind data
• The lease duration time to live (TTL) values
  control the scalability and performance
• Many additional features
• Server selection, bootstrap, security
• See AAMAS04 Naming Services in Multi-Agent
  Systems, T.Wright.

Server1
Fully connected Server-to-Server replication
Server2
Server3
Clients ..
Clients select any server
Agent1
Agent2
6
Design Lookup

• There are two patterns lookup and bind. The
  figure on the right shows the lookup pattern.
• To lookup data, a client can ask any server,
  since all servers are full replicas of one
  another
• Leases are specified by the server to control
  client-side caching
• Short leases ensures up-to-date data but
  increases traffic
• Long leases reduces traffic but increases stale
  data
• This tradeoff is explicit

Server2
Server3
..
Server1
2 lookup
3 data ttl
WP Cache Bind Renewer Server Selector
4 renew after ttl
1 lookup
Agent1
Agent2
..
7
Design Bind

• To bind data, a client can tell any server, then
  that server forwards the message to all the other
  servers
• Leases are used to control server-side expiration
  of bound data
• Short leases ensure quick cleanup of dead agent
  entries, but this increases traffic
• Long leases reduce traffic but delay the Garbage
  Collection cleanup
• This is another explicit tradeoff
• The number of servers is another tradeoff
• Fewer servers minimizes traffic but increases
  per-server load and single points of failure
• Many servers balance load but increase overall
  traffic

Server2
Server3
..
4 fwd
5 fwd
Server1
2 bind
3 ack ttl
WP Cache Bind Renewer Server Selector
6 renew after ttl
1 bind
Agent1
Agent2
..
8
Experimental Results Scalability

• A 10x increase in the number of agents produces a
  6x increase in messages and 14x increase in byte
  traffic

9
Experimental Results Model Accuracy
Accuracy of our Predictive Model
Good Accuracy

• We created a simple model based on our design,
  which was found to be accurate in our experiments

10
Model Analysis

• Our model is accurate enough to predict the
  overall WP message traffic
• Model simplifications did not significantly
  impact the model accuracy
• Models steady-state costs, not startup
• Assumes evenly balanced clients server
  selections
• Aggregates messaging across all clients
• Confirmed design scalability

11
Conclusions

• Naming services can benefit from agent-based
  solutions
• Autonomous client and server behaviors
• Complex, dynamic behaviors (e.g. server
  selection, leases)
• Leverage agent-internal capabilities (e.g. MTS,
  security)
• Scalability estimated through models verified
  through large-scale tests
• Models clarify your design guide system tuning
• Verification refines the model guides future
  enhancements
• Cougaars naming service is scalable
• Well-defined models
• Can be enhanced, since its component-based
  open source

12
Future Work

• Implement models for non-steady-state states
• Model startup costs
• Model bootstrap server selection
• Model non-uniform layouts access patterns
• Implement a configuration wizard based on our
  model
• Input number of agents, layout, expected rate
  of mobility
• Output number of server agents, lease durations
• Enhance our design, based on our new insights
• Reduce the steady-state cost (e.g. through leased
  server-to-client change callbacks)
• Increase scalability through hierarchical servers
• Implement more complex, adaptive behaviors (e.g.
  server-controlled load balancing)

13
For more information

• BBN Technologies
• http//www.bbn.com
• Cougaar Agent Architecture
• http//www.cougaar.org
• Other Cougaar-related KIMAS05 papers
• Watching Your Own Back Self Managing
  Multi-Agent Systems, M. Thome, T. Wright, et al
• Using QoS-Adaptive Coordination Artifacts to
  Increase Scalability of Communication in
  Distributed Multi-Agent Systems, J. Zinky, S.
  Siracuse, et al
• A Reconfigurable Multiagent Society for
  Transportation Scheduling and Dynamic
  Rescheduling, D. Montana, G.Vidaver, et al
• Adaptive Optimization of Solution Time in a
  Distributed Multi-Agent System, A. Fedyk, et al

14
Backup Slides
15
WP Design detail