Theory Lunch

2

Problem Areas

• Network Virtualization for Experimentation and Architecture– Embedding problems– Economics problems (markets, etc.)

• Network Monitoring– Distributed network troubleshooting– Traffic monitoring

3

Fixed Infrastructure

VINI nodes embedded in Abilene

4

Shared Infrastructure

Experiments given illusion of dedicated h/w

5

Flexible Topology

VINI supports arbitrary virtual topologies

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 Providers Role 2: Service Providers

No single party has control over an end-to-end path.

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

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

Problem Areas

• Network Virtualization: VINI/Cabo– Embedding problems– Economics problems (markets, etc.)

• Network Troubleshooting and Monitoring– Distributed network troubleshooting– Traffic monitoring

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

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

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

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 can’t talk to each other?

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?