1. Scalability Aspects of Agent-based Naming Services Todd Wright, Karl Kleinmann BBN Technologies twright@bbn.com, kkleinmann@bbn.com

2. 2Outline Introduction to Agent Naming ServicesIntroduction to Agent Naming Services Cougaar White Pages DesignCougaar White Pages Design Experimental ResultsExperimental Results Accuracy of Model-Based PredictionsAccuracy of Model-Based Predictions Conclusions and Future WorkConclusions and Future Work

3. 3Introduction Why do agents need a naming service?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...)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?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. 4 Cougaar Background Cougaar Agent ArchitectureCougaar 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:Significant WP requirements: –Support 1000+ agents distributed over 100+ hosts –Rapid, dynamic agent mobility –Focus on Security and Robustness TRANSCOM 1BDE 2BDE http://www.cougaar.org

5. 5 Agent 2 Cougaar White Pages Design Agent-based designAgent-based design –Implemented WP servers as agents –Integrated client-side WP caches Two-tier designTwo-tier design –Clients can talk to any server –Servers replicate between one another Leases used throughoutLeases 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:Many additional features: –Server selection, bootstrap, security… –See AAMAS’04 “Naming Services in Multi-Agent Systems”, T.Wright. Server 2 Server 1 Server 3 Fully connected Server-to-Server replication Agent 1 Clients select any server Clients..

6. 6 Design: Lookup There are two patterns: lookup and bind. The figure on the right shows the lookup pattern.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 anotherTo 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 cachingLeases 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 WP Cache + Bind Renewer + Server Selector Agent 1 Agent 2 Server 1 4: renew after ttl.. Server 2 Server 3.. 2: lookup3: data + ttl 1: lookup

7. 7 4: fwd Design: Bind To bind data, a client can tell any server, then that server forwards the message to all the other serversTo 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 dataLeases 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 tradeoffThe 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 WP Cache + Bind Renewer + Server Selector Agent 1 Agent 2 Server 1 Server 2 Server 3 2: bind3: ack + ttl 5: fwd 1: bind 6: renew after ttl..

8. 8 Experimental Results: Scalability A 10x increase in the number of agents produces a 6x increase in messages and 14x increase in byte trafficA 10x increase in the number of agents produces a 6x increase in messages and 14x increase in byte traffic Small Config. 115 agents 10 hosts 3 servers 8 minute bind ttl 4 minute lookup ttl Large Config. 1146 agents 52 hosts 7 servers 8 minute bind ttl 4 minute lookup ttl Global msg/min: Measured19 110 110 Global kB/min: Measured30 425 425 10x 6x 14x Scalability Comparison:

9. 9 Experimental Results: Model Accuracy Small Config. 115 agents 10 hosts 3 servers 8 minute bind ttl 4 minute lookup ttl Large Config. 1146 agents 52 hosts 7 servers 8 minute bind ttl 4 minute lookup ttl Global msg/min: Measured19 110 110 Predicted10 78 78 Global kB/min: Measured30 425 425 Predicted22 372 372 Good Accuracy of our Predictive Model: We created a simple model based on our design, which was found to be accurate in our experimentsWe created a simple model based on our design, which was found to be accurate in our experiments

10. 10 Model Analysis Our model is accurate enough to predict the overall WP message trafficOur model is accurate enough to predict the overall WP message traffic Model simplifications did not significantly impact the model accuracy: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 scalabilityConfirmed design scalability

11. 11Conclusions Naming services can benefit from agent-based solutionsNaming 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 testsScalability estimated through models & verified through large-scale tests –Models clarify your design & guide system tuning –Verification refines the model & guides future enhancements Cougaar’s naming service is scalableCougaar’s naming service is scalable –Well-defined models –Can be enhanced, since it’s component-based & open source

12. 12 Future Work Implement models for non-steady-state statesImplement 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 modelImplement 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 insightsEnhance 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. 13 For more information … BBN Technologies:BBN Technologies: –http://www.bbn.com http://www.bbn.com Cougaar Agent Architecture:Cougaar Agent Architecture: –http://www.cougaar.org http://www.cougaar.org Other Cougaar-related KIMAS’05 papers:Other Cougaar-related KIMAS’05 papers: –“ Watching Your Own Back: Self Managing Multi-Agent Systems ”, M. Thome, T. Wright, et al –“, J. Zinky, S. Siracuse, 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. 15 WP Design detail