1. Theory Lunch

2. 2 Problem Areas Network Virtualization for Experimentation and Architecture –Embedding problems –Economics problems (markets, etc.) Network Monitoring –Distributed network troubleshooting –Traffic monitoring

3. 3 Fixed Infrastructure VINI nodes embedded in Abilene

4. 4 Shared Infrastructure Experiments given illusion of dedicated h/w

5. 5 Flexible Topology VINI supports arbitrary virtual topologies

6. 6 Today: ISPs Serve Two Roles Infrastructure providers: Maintain routers, links, data centers, other physical infrastructure Service providers: Offer services (e.g., layer 3 VPNs, performance SLAs, etc.) to end users Role 1: Infrastructure ProvidersRole 2: Service Providers No single party has control over an end-to-end path.

7. 7 Concurrent Architectures are Better than One (Cabo) The business entities that play these two roles may be the same in some cases Infrastructure providers: maintain physical infrastructure needed to build networks Service providers: lease slices of physical infrastructure from one or more providers

8. 8 Network Embedding Problem Given: virtual network and physical network –Topology, constraints, etc. Problem: find the appropriate mapping onto available physical resources (nodes and edges) Many possible formulations –Specific nodes mapping to certain physical nodes –Generic requirements: three diverse paths from SF to LA with 100 MBps throughput –Traffic awareness, dynamic remapping, etc.

9. 9 Problem Areas Network Virtualization: VINI/Cabo –Embedding problems –Economics problems (markets, etc.) Network Troubleshooting and Monitoring –Distributed network troubleshooting –Traffic monitoring

10. 10 Network Troubleshooting Goal: Locate and diagnose network performance (or reachability) problems Status: Lots of (somewhat imperfect) tools –Ping: reachability –Traceroute: IP-layer path to destination –Iperf: throughput –Pathchar: per-hop capacity estimation None of these lead to a solution –Why is the traffic not getting there? (link failure, firewall configuration, etc.) –Which network caused this event?

11. 11 Why Troubleshooting is Hard Misconfigured filters Link failures (between ASes or within an AS) Middlebox problem (NAT, firewall, etc.) Application-level failures (server crash) Service failure (DNS failure) Plethora of causes Key (currently hard) questions Is the problem local or global? If global, where is it? Perhaps asking neighboring networks can help?

12. 12 Distributed Network Troubleshooting How can views of the network from other vantage points assist in locating and diagnosing problems? cnn.com Can you see cnn.com? Georgia Tech Princeton MIT Yes, and my path is… No…

13. 13 Troubleshooting Questions How to alter protocols to make them more amenable to passive measurement? –What are the accuracy bounds for passive measurement algorithms (e.g., sampled NetFlow) How many views are needed to locate a problem? –Perhaps this depends on the problem…things like filtering/reachability might be easier than congestion –The answer may also change depending on the topology and failure model (i.e., what if some nodes cant talk to each other?

14. 14 Traffic Monitoring Problem Conventional monitoring schemes create statistics based on sampled traffic Works for catching high-volume attacks Ineffective for answering who is talking to whom –Useful for things like looking at communication graph structure –Coupon collection with limited resources Flows may be low-volume. How to observe as many as possible?