My Experience Writing an NSF NeTS FIND Proposal Nick Feamster Georgia Tech.
-
Upload
jesse-adkins -
Category
Documents
-
view
214 -
download
1
Transcript of My Experience Writing an NSF NeTS FIND Proposal Nick Feamster Georgia Tech.
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.