Rethinking Internet Traffic ManagementFrom Multiple Decompositions to a Practical Protocol

Martin Suchara

in collaboration with:J. He, M. Bresler,

J. Rexford and M. Chiang

2

Why Study Traffic Management?

Traffic management is important Determines traffic rates and divides resources Integrates routing, congestion control, traffic

engineering, …

Motivated by recent advancements in optimization theory research

The architecture has shortcomings Suboptimal interactions of components

important

shortcomings

3

Traffic Management Today

User:Congestion Control

Operator: Traffic Engineering

Routers:Routing Protocols

Evolved organically without conscious design

4

Shortcomings of Today’s Architecture

Protocol interactions ignored Congestion control assumes routing is fixed TE assumes the traffic is inelastic

What would a clean-slate redesign look like?

Inefficiency of traffic engineering Link-weight tuning problem is NP-hard TE at the timescale of hours or days

5

Contributions of This Talk

1. Case study of a design process Based on optimization decompositions Evaluations using simulation also needed

2. The new design Of network traffic management

The next steps: Towards virtualized networks

6

Top-down Redesign

Problem Formulation

Distributed Solutions

TRUMP Algorithm

Optimization decomposition

Compare using simulations

TRUMP Protocol

Translate into packet version

7

Congestion Control ImplicitlyMaximizes Aggregate User Utility

max.∑i Ui(xi)s.t. ∑i Rlixi ≤ cl

var. x

aggregate utility

Source rate xi

UserutilityUi(xi)

Source-destination pair indexed by i

source rate

Utility represents user satisfaction and elasticity of traffic

routing matrix

Fair rate allocation amongst greedy users

8

Traffic Engineering ExplicitlyMinimizes Network Congestion

min. ∑l f(ul)s.t. ul =∑i Rlixi /cl

var. R Link Utilization ul

Costf(ul)

aggregate congestion costLinks are indexed by l

ul =1

Cost function is a penalty for approaching capacity

Avoids bottlenecks in the network

link utilization

9

A Balanced Objective

max. ∑i Ui(xi) - w∑l f(ul)

Network users:Maximize throughput Generate bottlenecks

Network operators:Minimize delay

Avoid bottlenecks

Penalty weight

10

Top-down Redesign

Problem Formulation

Distributed Solutions

TRUMP Algorithm

Optimization decomposition

Compare using simulations

TRUMP Protocol

Translate into packet version

Optimization decomposition requires convexity

11

Convex Problems are Easier to Solve

Convex Non-convex

Convex problems have a global minimum Distributed solutions that converge to global

minima can be derived using decompositions

12

i source-destination pair, j path number

How to Make our Problem Convex?

max. ∑i Ui(∑j zji) – w∑l

f(ul)s.t. link load ≤ cl

var. path rates zz11

z21

z31

Single path routing is non convex Multipath routing + flexible splitting is convex

Path rate captures source rates and routing

1

2

3

4

5

7

8

1

0

1

1

69 69

13

Overview of Distributed Solutions

Edge node: Update path rates zRate limit incoming traffic

Operator: Tune w, U, f Other parameters

Routers: Set up multiple pathsMeasure link loadUpdate link prices s

ss

s

14

Role of Optimization Decompositions

Derive price and path rate updates Prices: penalties for violating a constraint Path rates: updates driven by penalties

Example: TCP congestion control Link prices: level of packet loss or delay Source rates: adjust window based on prices

Our problem is more complicated More complex objective, multiple paths

15

Rewrite capacity constraint:

Key Principles I: Effective Capacity

link load ≤ cl

link load = yl

effective capacity yl ≤ cl

Effective capacity keeps system robust

Effective capacity yl

Dynamically updated Advance warning of impending congestion Simulates the link running at lower capacity

and give feedback on that

16

Key Principles II: Consistency Price and Subgradient Updates

Consistency price pl

Relax constraint yl ≤ cl but penalize violation with price pl

Allow packet loss to converge faster Subgradient feedback price update:

Stepsize controls the granularity of reaction Stepsize is a tunable parameter

pl(t+1) = [pl(t) – stepsize*(cl – yl

(t))]+

17

Four Decompositions – Differences

Iterative updates contain stepsizes:They affect the dynamics of the distributed algorithms

Differ in how link & source variables are updated

18

Top-down Redesign

Problem Formulation

Distributed Solutions

TRUMP Algorithm

Optimization decomposition

Compare using simulations

Final Protocol

Optimization doesn’t answer all the questions

Translate into packet version

19

Theoretical results and limitations: All proven to converge to global optimum

for well-chosen parameters No guidance for choosing parameters Only loose bounds for rate of convergence

Evaluating Four Decompositions

Sweep large parameter space in MATLAB Effect of w on convergence Compare rate of convergence Compare sensitivity of parameters

Simple Topologies Used in MATLAB

20

1

2

3

4

5

6

7

8

9

1

0

1

1

54

3

2

1

6

21

Effect of Penalty Weight w

Can achieve high aggregate utility for a range of w

Topology dependent

User utility w Operator penalty

22

Convergence Properties: Partial Dual in Access Core Topology

Tunable parameters impact convergence time

● average valuex actual values

Parameter sensitivity

Best convergence

23

Convergence Properties (MATLAB)

Parameter sensitivity correlated to rate of convergence

24

Insights from simulations: Have as few tunable parameters as

possible Use direct update when possible Allow some packet loss

TRUMP: TRaffic-management Using Multipath Protocol

Cherry-pick different parts of previous algorithms to construct TRUMP

One tunable parameter

25

TRUMP Algorithm

Source i: Path rate zj

i(t+1) = max. (Ui(∑kzki) – zj

i *path price)

Link l: loss pl(t+1) = [pl(t) + stepsize*(link load - cl )]+

queuing delay ql(t+1) = wf’(ul)

Price for path j = ∑ l on path j (pl+ql)

26

TRUMP is not another decomposition We can prove convergence, but only

under more restrictive conditions

TRUMP Versus Other Algorithms

From MATLAB: Faster rate of convergence Easy to tune parameter

Top-down Redesign

Problem Formulation

Distributed Solutions

TRUMP Algorithm

Optimization decomposition

Compare using simulations

TRUMP Protocol

So far, assumed fluid model, constant feedback delay, greedy traffic sources

Translate into packet version

27

28

TRUMP: Packet-based Version

Link l: link load = (bytes in period T) / (clT) Update link prices every T

Source i: Update path rates at maxj {RTTji}

Arrivals and departures of flows are reflected in price changes

29

Set-up: Synthetic topologies + realistic topologies

and delays of large ISPs Multiple paths with 1ms to 400ms of delay Realistic ON-OFF traffic model

Packet-level Experiments in NS-2

Questions: Do MATLAB results still hold? Does TRUMP react quickly to link

dynamics? Can it handle ON-OFF flows? Number of paths needed?

30

TRUMP Versus Partial Dual in Sprint

TRUMP trumps partial dual for w ≤ 1/3

TRUMP Partial dual

Aggregate throughput stabilizes for a range of w’s

No stepsize allows satisfactory convergence

31

TRUMP Link Dynamics

TRUMP reacts quickly to link dynamics

Link connecting NJ and IN in the Sprint network fails and recovers

32

TRUMP Versus File Size

TRUMP’s performance is independent of variance

Worse for smaller files but still faster than TCP

33

TRUMP: A Few Paths Suffice

Sources benefit the most when they learn a few paths

Worse for smaller files but still faster than TCP

Diminishing returns when providing more than 2 paths

34

Summary of TRUMP Properties

35

Division of Functionality

Sources: end hosts or edge routers? Feedback: implicit or explicit?

Mathematics leaves open architecture questions

36

The Next Steps So far the utility function maximizes utility of

throughput sensitive traffic

However, not all traffic throughput sensitive:

37

The Next Steps: Virtualization Need to support multiple types of applications

Throughput-sensitive: file transfers Delay-sensitive: VoIP and gaming

Questions What should the utility for each application

look like? How to share network resources

dynamically?

38

Conclusions

Traffic engineering Started with multiple decompositions Designed TRUMP: new traffic-

management protocol

What to do next? Support of different traffic classes

39

Thank You!

40

Related Work

Advancements in optimization theory Protocol reverse engineering (Kelly98, Low03)

Design of new protocols (Low06)

Multiple decompositions (Chiang06)

Traffic management protocols consider congestion control or traffic engineering Congestion control alone (FAST TCP,

RCP, XCP, etc.) Use of multiple paths without adjusting

source rates (MATE, REPLEX, etc.)