1. Network Performance Management S. Keshav C/NRG (with Rosen Sharma, Andy Choi, Wilson Huang, Lili Qiu, Russell Schwager, Rachit Siamwalla, Jia Wang, and Yin Zhang)

2. Motivation p Networks are increasing in breadth…. –greater density of connections –PCs come with built-in networking –ADSL and cable modems –wireless networking p as well as in depth –variety of qualities, policies, and media

3. The current situation p Loss of productivity from –slow file access –web site disconnection –slow access to a web site –no one knows exactly why! p Greater breadth and depth => even more dependency on the network => even more problems

4. Is QoS enough? p Lots of research in the area of QoS –RSVP, differential service etc. provide a good overall user experience, one stream at a time –Is QoS all there is to a good user experience? p An incorrect reservation  poor service for one stream p A misconfigured router  complete loss of service to one or more ports!

5. Aha! p User experience is affected more by ‘mundane’ network management than by ‘exotic’ QoS research p This motivates our entire research effort

6. Why networks fail p Link or router failure p Transient overload p Unanticipated increase in load p Misconfiguration Increasingly harder to detect

7. Need Better Network Management p Current approaches –GUI-centric –lots of flashing lights, but no intelligence p Can detect failures but... –ad hoc capacity planning –ad hoc configuration no way of testing other than “just try it!” p Can’t manage network performance

8. Performance management Topology discovery Fix problems (AI and simulation) Collect statistics (monitoring) Identify problems (display and simulation) Configure new hardware (simulation)

9. Discovery: Project Octopus Permanent Set Temporary Set Heuristic

10. Techniques p DNS-ls p SNMP p Random probe p Traceroute p Directed broadcast ping

11. Results p Have automatically discovered entire CS department topology p As well as entire Stanford topology (> 220 subnets) p Cornell topology is being discovered as we speak! –info being shared with CIT

12. Monitoring p A PERL script uses SNMP and queries a router using various MIB entries. p The MIB entries are stored in an input file. p The values gathered from the router are stored in a file. p The script works on both UNIX and WinNT.

13. Monitoring (contd.) p Other PERL scripts parse the data and convert it to other formats. p Currently supported formats: –HTML - The data is presented in a table format in HTML. –GNUPlot graphs - The data can be graphed or saved in pbm format

14. A Case Study: CSGate2 p From 2/19/98 to 2/23/98, the router CSGate2 was probed every 5 minutes recording various statistics on the data coming into and going out of the router. Incoming bytes at CSgate2

15. Display goals p We want to display multiple views p Views should be dynamic p Shoul allow expansion and contraction p Rapid creation of user interface p Reusability of GUI components

16. Solution: Script Java p Component-based system p Reusable manageable components p Can build large manageable applications p Sharing over the web p Record and playback

17. Architecture p Use JavaScript/Visual Basic as the scripting language p Use Java to write components p Create a adapter hierarchy for the current AWT components

18. Script Java Objects p HTML pages p Java structures intelligence p protection by namespace Data Model p linearized data structures p java  perl  javascript Communication Abstraction p multicast channels

19. Advantages p Allows us to glue components using a scripting language, allowing rapid prototyping and development p New components can be easily integrated p For large applications, a lot of the complexity and chaos can be taken out of scripting

20. Advantages(cont.) p JavaScript can be streamed from the server, allowing for presentations and sharing p Dynamic Html –layers are windows –these windows render html

21. Storage goals p We need to store topology and monitoring results somewhere p Database: too structured and too much overhead p File system: not enough semantics p Idea: treat URL as a file system link and HTML tags as associated semantics

22. WebFS p HTML tags allow arbitrary semantic abstractions p Manipulate these abstractions to present a virtualized file system p grep -headings *.html p sed ‘/ /jdbc(“tags.db”, “foo”)/’

23. The magic bullet: simulation p Realistic simulation where networking subsystem interacts with other parts of kernel p Fast simulation for large networks ( > 1000 hosts) p Hide the abstraction of simulated network, same API as system calls

24. FreeBSD kernel  User Space Kernel core Telnetd ping gated machine Kernel wrapper msg Network Stack Telnetd ping gated Sockets traps 

25. Simulated machine p Task based approach – a trap sends a message to kernel – an upper call is a message from kernel p All components of simulated machine live on same process Kernel core Telnetd ping gated machine Kernel wrapper msg Simulated link

26. More on simulated machine p Capture network related system calls, file descriptor auto re-mapping. p Virtual file system root p Single-thread kernel, therefore no need for locking

27. Simulated network Kernel core Telnetd ping gated machine msg

28. Integrating with real network p Use U-Net to interact with external device p Router has the illusion of being in a physical network p Test equipment before actual deployment Physical Router Unet

29. Tradeoffs p Balance between realism and speed –Using FreeBSD as basis for realistic simulation –Using session level simulation to speed up p Ease of porting applications

30. Open issues p Fault identification –Bayesian networks? –Ensemble of experts? –Other AI approaches? p How to do session-level simulation? p Configuring real systems –IP9000