Rethinking Internet Traffic Management: From Multiple Decompositions to a Practical Protocol

Jiayue He Princeton University

Joint work with Martin Suchara, Ma’ayan Bresler, Mung Chiang, Jennifer Rexford

2

Traffic Management Today

User:Congestion Control

Operator: Traffic Engineering

Routers:Routing Protocols

Evolved organically without conscious design

3

Rethinking Traffic Management Shortcomings of today’s traffic

management: Congestion control assumes routing is fixed,

traffic engineering assumes traffic is inelastic Link weight tuning problem is NP-hard Link weights are tuned at the timescale of

hours, slower than traffic shifts

What if we redesign traffic management from scratch using optimization tools?

4

Top-down Redesign

Problem Formulation

Distributed Solutions

TRUMP algorithm

Optimization decomposition

Compare using simulations

TRUMP Protocol

Translate into packet version

5

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

6

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 represent penalty for approaching capacity

Avoids bottlenecks in the network

link utilization

7

A Balanced Objective

max. ∑iUi(xi) - w∑lf(ul)

Happy usersMaximize

throughput Generate

bottlenecks

Happy operatorsMinimize delay

Avoids bottlenecks

Penalty weight

8

Top-down Redesign

Problem Formulation

Distributed Solutions

TRUMP algorithm

Optimization decomposition

Compare using simulations

TRUMP Protocol

Translate into packet version

Optimization decomposition requires convexity

9

i source-destination pair, j path number

How to make it convex?

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

s.t. link load ≤ cl

var. path rates zz1

1

z21

z31

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

Path rate captures source rates and routing

10

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

11

Four Decompositions - Differences

Algorithms Features Paramete

rs

Partial-dual Effective capacity

1

Primal-dual Effective capacity

3

Full-dual Effective capacity,Allow packet loss

2

Primal-driven Direct s update 1

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

Differ in how link & source variables are updated

12

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

13

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

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

Evaluating Four Decompositions

14

Convergence Properties (MATLAB)

Algorithms Convergence Properties

All Converges slower for small w

Partial-dual vs.Primal-dual

Extra parameters do not improve convergence

Partial-dual vs.Full-dual

Allow some packet loss may improve convergence

Partial-dual vs.Primal-driven

Direct updates converges faster than iterative updates

Parameter sensitivity correlated to rate of convergence

15

Insights from simulations: Have as few tunable parameters as possible Use direct update when possible Allow some packet loss

Cherry-pick different parts of previous algorithms to construct TRUMP

TRUMP trumps previous distributed solutions (MATLAB) Faster rate of convergence One easy to tune parameter

TRUMP: TRaffic-management Using Multipath Protocol

16

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(cl – link load)]+

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

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

17

Top-down Redesign

Problem Formulation

Distributed Solutions

TRUMP algorithm

Optimization decomposition

Compare using simulations

TRUMP Protocol

So far, assume fluid model, constant feedback delay

Translate into packet version

18

TRUMP: Packet-Based Version

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

Source i: Update path rates at maxj {RTTj

i}

Arrival and departure of flows are notified implicitly through price changes

19

Set-up: Realistic topologies and delays of large ISPs Selected flows and paths Realistic ON-OFF traffic model

Questions: Do MATLAB results still hold? Does TRUMP react quickly to link dynamics? Can TRUMP handle ON-OFF flows?

Packet-level Experiments (NS-2)

20

TRUMP Link Dynamics

Link failure or recovery

Time (s)

Th

rou

gh

pu

t (bits/s)

TRUMP reacts quickly to link dynamicsSame observation for ON-OFF flows

21

Summary of TRUMP PropertiesProperty TRUMP

Tuning Parameters

One easy to tune parameterOnly need to be tuned for small w

Robustness to link dynamics

Reacts quickly to link failures and recoveries

Robustness to flow dynamics

Independent of variance of file sizes, more efficient for larger files

General Trumps other algorithms

Feedback Possible with implicit feedback

22

Contributions: Design with multiple decompositions Introduce practical traffic management

protocol

Math leaves architectural choices Feedback: implicit versus explicit Edge nodes: end hosts versus edge router Computations: centralized versus

distributed

Concluding Remarks

The End…

Thank you!

www.princeton.edu/~jhe/research/conext07.pdf