My Experience Writing an NSF NeTS FIND Proposal Nick Feamster Georgia 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 Its not about trying to find nails for your hammer Some cases: maybe its about designing a hammer Our case –Looking in the toolbox and finding a screwdriver –Realizing that wed 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 cant 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 SFO ATL 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 ProvidersRole 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. –Operators 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 BGPLink-State Protocols DisseminationHierarchical, incrementalFlooding ComputationBGP-style decision processShortest Paths Better Scalability Faster 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 TodayCabo Competing ISPs with different goals must coordinate Single service provider controls end-to-end path

20 Pain Point: Deployment Online BankingWeb Surfing RoutingSecure control plane for participating parties Insecure control plane for all parties AddressingSelf-certifying address associated with person Ephemeral address related to the topology More Security More 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.