1. 1 Automating Network Diagnostics to Help End-Users Dave Thaler dthaler@microsoft.com

2. 2 Motivation User needs are becoming more dependent on the Internet Problems can occur anywhere in the Internet Users have no control over these problems, and often neither do their direct providers! Increased support calls are NOT the answer

3. 3 Poor error messages today User doesn’t understand the problem, only the symptom Error message pop-ups often aren’t helpful to users Event logs aren’t really any better Technical information is only useful to technical experts who don’t have access to end-users’ machines

4. 4 Goals Reduce number of support calls –Help the user/app help itself where possible –Locate the correct party to contact if not Reduce the time spent on support calls that do occur

5. 5 Focus on what the user wants! User doesn’t want to have to call anyone User doesn’t want to get email about an outage User doesn’t want to go to some web site to find out User just wants the application to work If it doesn’t work, user often wants to know when it will work If application is non-interactive, application may want to retry as soon as it is fixed (e.g. search engine) User also wants to know that someone is working on fixing the problem If user policy decision needed, user wants choices

6. 6 Multiple Adminstrative Entities Policy Principles –Freedom of information: Outage info should be available to all those affected by it. –Privacy: Outage info should be available only to those affected by it. –Freedom of speech: Any entity should be able to report a problem, whether or not it is trusted. –Conservation of effort: Perform the minimum work needed to troubleshoot the problem.

7. 7 Solution Framework Self-diagnosing, self-healing: –Naming: identification of a problem instance –Message routing: getting problem instance to capable agent –Methodology: structured process for confirming, diagnosing, repairing, etc. –Domain-specific classes/agents Self-improving: –Learning what possible causes are the most likely –Learning what is normal/abnormal within a class –Reporting on agent behavior for improvements

8. 8 Architecture Application or Monitoring Tool Client API Engine Helper Class Component Protocol Component Engine Helper Class Helper Class Component Helper Class

9. 9 Separation of Roles Engine –Maintains cause-effect tree –Handles message routing –Implements core methodology Helper Classes –Implement simple API –Embed knowledge about one component type –Generate causal hypotheses that are treated just like client reports

10. 10 Example TCPIP-related Helper Classes

11. 11 Summary It’s not just about one network being self- managing –We need to improve the end-user experience –Handling multiple administrative domains is a core issue Structured methodology aids in problem analysis –Today too many things are ad hoc High-level methodology should be independent of component-specific knowledge –Provides extensibility –Facilitates appropriate learning at both levels