1. The Network Weather Service A Distributed Resource Performance Forecasting Service for Metacomputing Rich Wolski, Neil T. Spring and Jim Hayes Presented By: Mohammad Al-Saeed

2. Organization Introduction Motivation: why the NWS? The NWS: what is the NWS? Related work NWS system architecture Design goals System components NWS components NWS interface Conclusion and future work

3. Motivation Searching for the environment that delivers the most Dynamic nature of metacomputing environments Adaptive applications Adapt to changing environments Knowledge needed for adaptation Resource discovery and allocation

4. The Network Weather Service A distributed system for producing short- term deliverable performance forecasts Goal: dynamically measure and forecast the performance deliverable at the application level from a set of network resources Measurements currently supported: Available fraction of CPU time End-to-end TCP connection time End-to-end TCP network latency End-to-end TCP network bandwidth

5. Related Work TReno: performance at transport layer using TCP Pathchar: bandwidth over a path bprobe/cprobe: bottleneck link speed and competing traffic Topology-d: uses ping and netperf to find bandwidth between hosts in a group then analyzes this data to find minimum-cost logical topology ReMoS: network resource monitoring

6. NWS System Architecture Design objectives Scalability: scales to any metacomputing infrastructure Predictive accuracy: provides accurate measurements and forecasts Non-intrusiveness: shouldn ’ t load the resources it monitors Execution longevity: available all time Ubiquity: accessible from everywhere, monitors all resources

7. System Components Four different component processes Persistent State process: handles storage of measurements Name Server process: directory server for the system Sensor processes: measure current performance of different resources Forecaster process: predicts deliverable performance of a resource during a given time

8. NWS Processes

9. NWS Components Persistent State Management Naming Server Performance Monitoring: NWS Sensors CPU Sensor Network Sensor Sensor Control Cliques: hierarchy and contention Adaptive time-out discovery Forecasting Forecaster and forecasting models Sample forecaster results

10. Persistent State Management All NWS processes are stateless The system state (measurements) are managed by the PS process: Storage & retrieval of measurements Measurements are time-stamped plain-text strings Measurements are written to disk immediately and acknowledged Measurements are stored in a circular queue of tunable size

11. Naming Server Primitive text string directory service for the NWS system The only component known system-wide Information stored include Name to IP binding information Group configuration Parameters for various processes Each process must refresh its registration with the name server periodically Centralized

12. Performance Monitoring Actual monitoring is performed by a set of sensors Accuracy vs. Intrusiveness A sensor ’ s life: { Register with the NS; Query the NS for parameters; Generate conditional test; Forever { if conditions are met then { perform test; time-stamp results and send them to the PS refresh registration with the NS } }

13. CPU Sensor Measures available CPU fraction Testing tools: Unix uptime: reports load average in the past x minutes Unix vmstat: reports idle-, user- and system- time Active probes Accuracy: Results assume a full priority job Doesn ’ t know the priority of jobs in the queue

14. Active Probing Improvements Measurements produced using uptime Measurements produced using vmstat

15. Network Sensor Carries network-related measurements Testing: using active network probes Establish and release TCP connections Moving large (small) data to measure bandwidth (delay) Measures connections with all peer sensors Problems Accuracy: depends on socket interface Complexity: N 2 -N tests, collisions (contention)

16. Network Sensor Control Sensors are organized into sensor sets called cliques Each clique is configurable and has one leader Clique sets are logical, but can be based on physical topology Leaders are elected using a distributed election protocol A sensor can participate in many cliques Advantages Scalability by organizing cliques in a hierarchy Reduce the N 2 -N Accuracy by more frequent tests

17. Clique Hierarchy National UTenn SDSC PCL UCSD

18. Contention Each leader maintains a clique token (and time between tokens) The sensor that has the token performs all its tests then passes the token to the next sensor in the list Adaptive time-out discovery Tokens have time-out field Tokens have sequence numbers The leader adaptively controls the time-out

19. Forecaster Process A forecasting driver and a set of compile- time prediction modules Forecasting process: Fetching required measurements from the PS Passing the time series to each prediction module Choosing the best returned prediction Incorporate sophisticated prediction techniques?

20. Sample Forecaster Results UC Santa Barbara – Kansas State U. Recorded Bandwidth UC Santa Barbara – Kansas State U. Forecasted Bandwidth

21. NWS Interface C API Quick short-term forecasts for applications InitForecaster() RequestForecasts() CGI interface Continuous access to NWS forecasts through the web Interactively produces graphs for performance and forecasts http://nws.cs.utk.edu

22. Sample CGI-Generated Graph

23. Conclusion and Future Work NWS is scalable, stable and always available NWS relies on adaptivity to achieve its design goals NWS is open (adding sensors and forecasting models) Current forecasting is excellent compared to powerful sophisticated forecasting techniques Enhancements Basing the NS on LDAP Automatic clique configuration Forecasting methodologies