Change Is Hard: Adapting Dependency Graph Models For Unified Diagnosis in Wired/Wireless Networks

1. Change Is Hard: Adapting Dependency Graph Models ForUnified 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. Data Center Network Inter-Building Network Campus user Servers RAS Firewalls Internet Access Points Remote user via VPN

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

4. Existing solutions • 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 Internet Path Location RAS Server Access Point Routers ... Network Path:CKerberos Path:CWbSrv Path:C  DNS Kerberos server Web Server DNS server Services Name Resolution (C  DNS) Certificate Fetch (C  Kerberos) HTTP Get (C  WebSrv) Remote Gateway RTT Local Gateway RTT Client C accesses http://foo

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

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

12. Example: end-to-end diagnosis HTTP Actuator WiFi Actuator HTTP Expert Inference Engine RTT Monitor WiFi Expert Measurement Response Analysis Fault Observation Observation State Root-cause Analysis RC: AP, Location Recovery: Change AP Agent Inference 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