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

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

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

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

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

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

Example scenario: client accesses DNS Server Kerberos Server Web Server Client C

Stationary dependency graph

Dynamic dependency Graphs Client C accesses 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...

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

Incrementally building an dependency graph Type: Http.Request Instance: 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

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

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

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

Calendar-based Location Profiles

Location Priors

Impact of Using Location Priors

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

Backup

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