Building a Strong Foundation for a Future Internet Jennifer Rexford Princeton University

2 The Internet: A Remarkable Story Tremendous success –A research experiment that truly escaped from the lab The brilliance of under-specifying –Best-effort packet-delivery service –Key functionality at programmable end hosts Enabled massive growth and innovation –Ease of adding new services (Web, P2P, VoIP, …) –Ease of adding hosts and links, and new technologies

3 Rethinking the Network Architecture But, the Internet is showing signs of age –Security, mobility, availability, manageability, … Challenges rooted in early design decisions –Weak notions of identity, tying address to location, … –Not a simple matter of redesigning a single protocol Revisiting the definition and placement of function –What are the types of nodes in the system? –What are their powers and limitations? –What information do they exchange?

4 Clean-Slate Network Architecture Clean-slate architecture –Without constraints of today’s artifacts –To have a stronger intellectual foundation –And move beyond the incremental fixes Still, some constraints inevitably remain –Ignore today’s artifacts, but not necessarily all reality Such as… –Resource limitations (CPU, memory, bandwidth) –Time delays between nodes –Independent economic entities –Malicious parties –The need to evolve over time

5 A Big Research Challenge Can we have all three? Under what conditions? Evolvable Protocols (under-specified, programmable) Decentralized Control (autonomous parties, with different economic objectives) X-ities (stability, scalability, reliability, security, managability, …) ?

6 A Real Need for a Theory of Networks Formal definitions of network architecture –Can the theory community do for network architecture what it did for, e.g., cryptography and machine learning? Programmabillity –What are good programming models that strike the right balance been flexibility and restraint? Incentives –How much should we rely on economic incentives to ensure key system properties? System properties –What are the fundamental trade-offs and bounds?

7 Example: Internet Routing Seemingly a simple matter –Computing paths on graphs Many, many design goals –Global connectivity –Flexible local policies –Fast recovery from changes –Good end-to-end paths –Low protocol overhead –Security, scalability, … – Perhaps we cannot satisfy all of these goals –No matter how hard we try…

8 Four Example Problems in Routing Policy-based interdomain routing –Programmable routing policies in each network –While ensuring global stability, efficiency, … –#1: Can economic incentives ensure global stability? –#2: How should a distributed network realize its policy? End-to-end traffic management –Adapting the flow of traffic over each path –While ensuring good aggregate performance –#3: What should hosts, routers, and operators do? –#4: How to support diverse application requirements? Getting a distributed set of nodes to do the right thing.

Policy-Based Interdomain Routing + $$$ = ???

10 What is an Internet? A “network of networks” –Networks run by different institutions Autonomous System (AS) –Collection of routers run by a single institution –With a clearly defined routing policy ASes have different goals –Different views of which paths are good Interdomain routing is what reconciles those views –To compute end-to-end paths through the Internet Wonderful problem setting for game theory and mechanism design

11 Autonomous Systems (ASes) Client Web server Path: 6, 5, 4, 3, 2, 1 Around 30,000 ASes today…

12 Border Gateway Protocol (BGP) ASes exchange reachability information –Destination: block of IP addresses –AS path: sequence of ASes along the path Policies “programmed” by network operators –Path selection: which path to use? –Path export: which neighbors to tell? 1 23 d “I can reach d” “I can reach d via AS 1” data traffic

13 Stable Paths Problem (SPP) Model Model of routing policy –Each AS has a ranking of the permissible paths Model of path selection –Pick the highest-ranked path consistent with neighbors Flexibility is not free –Global system converges slowly, or not at all –Depending on the way the ASes rank their paths 1 2 d 1 d 2 3 d 2 d 3 1 d 3 d d

14 Ways to Achieve Global Stability Detect conflicting rankings of paths? –Computationally intractable (NP-hard) –Requires global coordination Restrict the policy programming languages? –In what way? How to require this globally? –What if the world should change, and the protocol can’t? Rely on economic incentives? –Policies typically driven by business relationships –E.g., customer-provider and peer-peer relationships –Sufficient conditions to guarantee unique, stable solution

15 Bilateral Business Relationships Provider-Customer –Customer pays provider for access to the Internet Peer-Peer –Peers carry traffic between their respective customers d Provider-Customer Peer-Peer Valid paths: “1 2 d” and “7 d” Invalid path: “5 8 d” Valid paths: “6 4 3 d” and “8 5 d” Invalid paths: “6 5 d” and “1 4 3 d”

16 Act Locally, Prove Globally Route export –Do not export routes learned from a peer or provider –… to another peer or provider Route selection –Prefer routes through customers –… over routes through peers and providers Global topology –Provider-customer relationship graph is acyclic –E.g., my customer’s customer is not my provider Guaranteed to converge to unique, stable solution

17 Rough Sketch of the Proof Two phases –Walking up the customer-provider hierarchy –Walking down the provider-customer hierarchy d Provider-Customer Peer-Peer

18 Trade-offs Between Assumptions Three kinds of assumptions –Route export, route selection, and global topology Trade-offs –Relax one assumption, need to tighten the other two Are these assumptions reasonable? –Could business practices change over time? –What if nodes are dishonest about their choices? What if the protocol changes –What if the protocol allows multiple paths?

19 An Incomplete Understanding… Desirable global properties –Convergence to a unique route assignment –Fast convergence after topology changes –Honest announcement of AS paths –Forwarding data packets along chosen paths And how they relate to –Topology, policies, path verification, revenue models, … With basic questions about economic incentives –When are they enough? What else do we need? Where do the economic issues really belong? –In the protocol? In the policies? In routes themselves?

20 An AS is Really a Network How should the nodes inside an AS behave? –To correctly realize the AS’s routing policy –To satisfy the expectations of neighboring ASes –To minimize protocol overhead within the AS Different problem than interdomain routing –Not about reconciling (possibly conflicting) policies –But instead about correctly realizing a single policy

21 The Route Assignment Problem n … Route Assignment (based on policy) e3=rne3=rn from R rnrn … e1e1 e2e2 enen …r1r1 r2r2 r3r3 rnrn { } = R data traffic

22 An Incomplete Understanding… How to define and model an AS –To design and analyze interdomain routing –… without regard to the intra-AS details How to propagate routing information within an AS –So the routers can realize the policy “correctly” –… without introducing excessive overhead What are the overhead-flexibility trade-offs? –How much information must the routers exchange –… and how does it depend on the programming model How to program the policies –Intuitive programming language, rather than path ranking –… without sacrificing too much flexibility

End-to-End Traffic Management

24 Traffic Management Today How much traffic should traverse each path? End hosts: Congestion Control Operator: Traffic Engineering Routers: Routing Protocols

25 Models and Algorithms for Each Part End hosts: congestion control –Maximizing aggregate utility over all users –Additive increase, multiplicative decrease Routers: routing protocols –Minimizing path cost as sum of link weights –Bellman-Ford and Dijkstra’s algorithms Operators: traffic engineering –Minimizing load on the network links –Local-search algorithms for tuning link weights But, is the whole more than the sum of its parts?

26 Shortcoming of Today’s Architecture Ignores protocol interactions –Congestion control assumes routing is fixed –Traffic engineering assumes traffic is inelastic Inefficiency of traffic engineering –Tuning link weights in shortest-path routing –Cannot achieve optimal flow, and is NP-hard –… and is typically performed on long timescale Only limited use of multiple paths –Missed opportunity for better performance What would a clean-slate redesign look like?

27 Distributed Traffic Management Problem Should have a clearly-stated problem –Objectives: maximizing aggregate user utility –Constraints: link load staying below capacity And solutions with well-understood properties –Optimality, convergence, reasonable overhead, … Distributed load-balancing algorithms Edge nodes: Update path rates z Rate limit incoming traffic s s s Routers: Set up multiple paths Measure link load Update link prices s

28 An Incomplete Understanding… Promising initial results –Using optimization theory, game theory, control theory… Simple tuning of the system –Algorithms that are robust across a range of settings? –Self-tuning load-balancing algorithms? Trade-offs in the number of paths –How many paths are really necessary? –How should these paths be computed? Implicit vs. explicit feedback –Most solutions require feedback from network links –Can edge nodes adapt based on path-level metrics? –Robustness to adversaries trying to bias measurements?

Supporting Multiple Classes of Traffic file vs.

30 Different Strokes for Different Folks Applications have different requirements –High throughput: bulk file transfers –Low delay/jitter: VoIP and gaming Could design protocols for each traffic class –Using application-specific objective functions But, how should these applications co-exist? –Multiple customized traffic-management protocols –On a shared underlying network –To maximize the aggregate utility of the users

31 Virtualization to the Rescue Multiple customized architectures in parallel –Multiple virtual nodes on a single physical node –Isolation of resources, like CPU and bandwidth –Programmability for customizing each “virtual network”

32 An Incomplete Understanding How important are customized architectures? –Quantifying the inefficiencies of “one size fits all” –Understanding gains and overheads of customization How to balance isolation and efficiency? –Allowing multiple architectures to run in parallel –Without requiring static resource partitioning How to support other application requirements? –Security/privacy, scalability trade-offs, … –With appropriate support in the underlying substrate What kind of programming model on the nodes? –To enable creation of new networked services –Without compromising efficiency, security, …

33 Virtualization for Economic Refactoring Infrastructure providers: Maintain routers, links, data centers, and other physical infrastructure Service providers: Offer end-to-end services to users Today’s Internet Virtualized Internet Competing ISPs with different goals must coordinate Single service provider controls end-to-end path Economics play out vertically on a coarser timescale.

34 Conclusions These are just a few examples –In the context of Internet routing Meant to illustrate a larger question –Programmability, incentives, and global properties And importance of theoretical disciplines –In putting network architecture on a sound foundation Great opportunities for interdisciplinary research –Grappling with problem formulations and solutions And for significant practical impact –Adding clarity to our understanding of today’s Internet –And leading to a future Internet worthy of society’s trust