Building a Strong Foundation for a Future Internet

Jennifer Rexford

Princeton University

http://www.cs.princeton.edu/~jrex

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, …– <your wish list here>

• 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)

1

2

3

4

5

67

ClientWeb 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 2 3

d

“I can reach d”“I can reach d via AS 1”

data traffic 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 d1 d

2 3 d2 d

3 1 d3 d

1

3

2

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

2 3

1

d

4

5 6

7 8

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

2 3

1

d

4

5 6

7 8

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

1

2

3

n

…

Route Assignment(based on policy)

e3=rnfrom R

rn

…e1 e2 en

from R

…r1 r2 r3 rn { } = 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 zRate limit incoming traffic

ss

sRouters: Set up multiple pathsMeasure link loadUpdate 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

filevs.

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