My Experience Writing anNSF NeTS FIND Proposal

Nick FeamsterGeorgia Tech

2

This Talk

• My goal: explain the process of how we came up with our ideas.

• Your ideas will be different, but perhaps you can apply a similar process.

3

What I Think Architecture Is About

• It’s not about trying to find nails for your hammer• Some cases: maybe it’s about designing a hammer

• Our case– Looking in the toolbox and finding a screwdriver– Realizing that we’d rather use screws to build the house

4

Thinking About Architectures

• Re-think assumptions, change the question• Look for how problems are solved in other domains

• Pain points• Problems that are solved with strange hacks• Problems that can’t be solved with any hacks

From the Top Down: A Chance to Avoid Hacks

From the Bottom Up: Solving Real Problems

In a way, architecture is like cheating:“This problem would be easy if only…”

5

An Assumption We Started With

Architectures must be evaluated empirically so that a “winner” can be selected.

First Problem: No way to evaluate architectures experimentally

6

VINI: A Way to “Test” Architectures

• Testbed for evaluating new routing protocols and architectures– Single, shared experimental infrastructure– Simultaneous experiments

• Initial goal: Evaluate new BGP tricks on PlanetLab testbed– Proved to be rather difficult– Why? Creating virtual links in parallel, each with their

own namespace, reservations, etc.

Bavier, Feamster, Huang, Rexford, Peterson, “In VINI Veritas: Realistic and Controlled Network Experimentation”, ACM SIGCOMM, September 2006

7

What We Need to Build VINI

• Mechanisms for constructing virtual topologies– Nodes, links, etc.

• Ways to embed virtual topologies Inventory/resource provisioning tools

• Ways to virtualize nodes and links• Flexible forwarding paradigms• Support for customized routing software• Interface to experimenters

8

VINI: Our Screwdriver

9

Questioning Our Assumptions

• Single, shared experimental infrastructure• Support for multiple experiments

What if the testbed…

…were the architecture itself?

• Single, shared deployment platform• Support for multiple architectures

10

What We Need to Build VINI Useful Architectural Building Blocks

• Mechanisms for constructing virtual topologies– Nodes, links, etc.

• Ways to embed virtual topologies Inventory/resource provisioning tools

• Ways to virtualize nodes and links• Flexible forwarding paradigms• Support for customized routing software• Interface to experimenters

11

Questions

• What are the components of the architecture?– Top-down thinking

• Is it really useful?– Bottom-up

• How do we build it?

12

Top-Down: Analogies

• Commercial aviation– Infrastructure providers: Airports– Infrastructure: Gates, “hands and eyes”, etc.– Service providers: Airlines

• Other examples: Automobile industry

SFOATL

BOS

ORD

13

Applying Thinking to the Internet

• 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

14

Proposal: Concurrent Architectures are Better than One (“Cabo”)

• Infrastructure: physical infrastructure needed to build networks

• Service: “slices” of physical infrastructure from one or more providers

The same entity may sometimes play these two roles.

15

Similar Industry Trends

• Packet Fabric: share routers at exchange points• FON: resells users’ wireless Internet connectivity

• Infrastructure providers: Buy upstream connectivity, broker access through wireless

• Nomads: Users who connect to access points• Service provider: FON as broker

Two commercial examples

Broker

16

Bottom-Up: Hacks and Pain Points

• Network Operators– Mailing list: Complaints, problems, etc.– Operator’s group meetings

• Your own research problems

• Paper introductions and conclusions

17

Hack: Something “Screwy”…

• April 2005: Checking configurations in rcc• All iBGP-speaking routers fully connected

– Configurations violated in a large tier-1 ISP (Not AT&T or Sprint)

– Partition?

• Actually, this was a hack– iBGP: Good scaling, but converges slowly– IGP: Fast convergence– Some routers served as VoIP gateways

• Every route for which they forwarded traffic injected into IGP

18

Applying the Cabo Screwdriver

Internal BGP Link-State Protocols

Dissemination Hierarchical, incremental Flooding

Computation BGP-style decision process Shortest Paths

Better ScalabilityFaster

Convergence

• Today: Optimize a single set of protocols• Instead: Parallel deployment

– Run multiple networks, each catered to specific applications

Example

19

Pain Point: End-to-End Deployment

• Secure routing protocols• Multi-provider VPNs• Paths with end-to-end performance guarantees

Today Cabo

Competing ISPs with different goals must coordinate

Single service provider controls end-to-end path

20

Pain Point: Deployment

Online Banking Web Surfing

Routing Secure control plane for participating parties

Insecure control plane for all parties

Addressing Self-certifying address associated with person

Ephemeral address related to the topology

More SecurityMore Complete

Reachability

• Today: Deployment logjam– Deployment requires consensus and coordination

• Instead: Parallel deployment– Determined service provider leases infrastructure and deploys technology end-to-end

Example

21

Challenges: From Testbed To Architecture

• Thinking independently of IP– Testbed: Can assume an IP substrate, build X-in-IP

tunnels, etc.– Architecture: Is IP a suitable substrate?

• Considering incentives– Testbed: We provide the infrastructure– Architecture: Who provides the infrastructure?

Stepping away from assumptions presents new interesting questions.