1. Change Is Hard: Adapting Dependency Graph Models For Unified Diagnosis in Wired/Wireless Networks Lenin Ravindranath, Victor Bahl, Ranveer Chandra, David A. Maltz, Jitendra Padhye, Parveen Patel

2. Enterprise Network (of the Near Future) Stationary servers hosted in wired cloud/DC Nomadic users connect via wireless, VPN, RAS, etc. Inter- Building Network Data Center Network Data Center Network Servers RAS Firewalls Internet Remote user via VPN Campus user Access Points

3. End-to-end performance issues are a result of wired and wireless components URL fetch time: wired desktop client and nomadic laptop client Hard to figure out which component to blame

4. Existing solutions Diagnose end-to-end application performance Unified wired and wireless Consider effects of wireless mobility Ease of deployment Recovery Jigsaw, DAIR, WIT, Airtight √ Sherlock √√ SMARTS √√ No existing scheme works end-to-end in mixed wired/wireless environments

5. MnM Take Aways 1. Unified view of the wireless/wired network 2. User location needs to be a first class consideration 3. A system architecture that can deal with constantly changing dependencies, is easy to deploy and takes corrective action

6. MnM’s hammer: Dynamic Dependency Graphs Dependency graphs – Link observations to root causes – Use a fault inference algorithm, e.g., Sherlock Deal with frequent topology changes due to mobility – Constantly monitor end-systems to detect changes – Apply differences to existing dependency graph Consider location as a first-class component – Bootstrap the location system without help from static infrastructure – Use white-box monitoring to determine location

7. Example scenario: client accesses http://foo DNS Server Kerberos Server Web Server Client C

8. Stationary dependency graph

9. Dynamic dependency Graphs Client C accesses http://foo Name Resolution (C  DNS) Certificate Fetch (C  Kerberos) HTTP Get (C  WebSrv) Path:C  DNS Path:C  Kerbero s Path:C  WbSr v Web Server Kerberos server DNS server Access Point Network Services Local Gateway RTT LocationInternet Path Remote Gateway RTT RAS Server Routers...

10. MnM System Architecture Runs on every monitored machine Runs on a central server

11. Incrementally building an dependency graph Type: Http.Request Instance: http://foohttp://foo Client: C Type: NetworkService Name Resolution (C  DNS) Type: NetworkService Certificate Fetch (C  Kerberos) Type: NetworkService HTTP Get (C  WebSrv) Path:C  DNS Path:C  Kerberos Path:C  WbSrv Web Server Kerberos server DNS server Access Point Remote Gateway RTT Internet Path Location Local Gateway RTT RAS Server Routers... HTTP Expert Service Expert Net Expert WiFi Expert RAS Expert Location Expert

12. Example: end-to-end diagnosis RTT Monitor HTTP Actuator HTTP Expert Inference Engine Measurement Response Analysis Fault Observation Observation State Root-cause Analysis WiFi Actuator WiFi Expert RC: Hand-off Recovery: Change AP AgentInference Engine

13. Evaluation Controlled experiments – Verified accuracy of MnM diagnosis Two week study on 27 user laptops and 10 servers

14. Location Profiling Techniques AP-based location, default Outlook calendar-based, if available Cluster similar looking WiFi signatures to identify unnamed locations, e.g., a coffee shop

15. Calendar-based Location Profiles

16. Location Priors

17. Impact of Using Location Priors

18. Conclusion End-to-end performance diagnosis in mixed wired/wireless environments requires special considerations – The system needs to cope with constantly changing dependencies – Location needs to be a first-class component MnM is an extensible system architecture for diagnosing performance faults using dynamic dependency graphs

19. Backup

20. Accuracy Results Target Root Cause % the target Root Cause is first Other Root Causes in top two Reasons for other root causes Location55Machine, Server, APLocation Error, Real congestion at the server AP100First-hop routerFew positive observations through the first- hop router AP Handoff86Location, Machine, AP Location Error, AP failures Server100Last-hop routerFew positive observations for last-hop router Simultaneous faults100AP First-hop router Few positive observations for the first-hop router