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
Traffic Management Today
Operator:
Traffic Engineering
Evolved organically without conscious design
User:
Congestion Control
Routers:
Routing Protocols
2
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?
3
Top-down Redesign
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
4
Congestion Control Implicitly
Maximizes Aggregate User Utility
Source-destination pair indexed by i
aggregate utility
User
Utility
max.∑i Ui(xi)
Ui(xi)
s.t. ∑ R x ≤ c
i li users
i
l
Fair rate allocation amongst greedy
var. x
Source rate xi
routing matrix
source rate
Utility represents user satisfaction and elasticity of traffic
5
Traffic Engineering Explicitly
Minimizes Network Congestion
Links are indexed by l
Cost
f(ul)
aggregate congestion cost
min. ∑l f(ul)
ul =∑i Rlixi/cl
ul =1 ins.t.
Avoids bottlenecks
the network
var. R
Link Utilization ul
link utilization
Cost function represent penalty for approaching capacity
6
A Balanced Objective
max. ∑iUi(xi) - w∑lf(ul)
Penalty weight
Happy users
Maximize throughput
Generate bottlenecks
Happy operators
Minimize delay
Avoids bottlenecks
7
Top-down Redesign
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
Optimization decomposition requires convexity
8
How to make it convex?
 Single path routing is non convex
 Multipath routing + flexible splitting is convex
max. ∑i Ui(∑j zji) – w∑l f(ul)
s.t. link load ≤ cl
var. path rates z
i source-destination pair, j path number
z11
z21
z31
Path rate captures source rates and routing
9
Overview of Distributed Solutions
Operator: Tune w, U, f
Other parameters
s
s
s
Edge node:
Update path rates z
Rate limit incoming traffic
Routers:
Set up multiple paths
Measure link load
Update link prices s
10
Four Decompositions - Differences
Differ in how link & source variables are updated
Algorithms
Partial-dual
Primal-dual
Full-dual
Primal-driven
Features
Parameters
Effective capacity
Effective capacity
Effective capacity,
Allow packet loss
Direct s update
1
3
2
1
Iterative updates contain parameters:
They affect the dynamics of the distributed algorithms
11
Top-down Redesign
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
Final Protocol
Optimization doesn’t answer all the questions
12
Evaluating Four Decompositions
 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
13
Convergence Properties (MATLAB)
Parameter sensitivity correlated to rate of convergence
Algorithms
All
Partial-dual vs.
Primal-dual
Partial-dual vs.
Full-dual
Partial-dual vs.
Primal-driven
Convergence Properties
Converges slower for small w
Extra parameters do not improve
convergence
Allow some packet loss may
improve convergence
Direct updates converges faster than
iterative updates
14
TRUMP: TRaffic-management
Using Multipath Protocol
 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
15
TRUMP Algorithm
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)
Source i:
Path rate zji(t+1) = max. Ui(∑kzki) – zji *path price
16
Top-down Redesign
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
So far, assume fluid model, constant feedback delay
17
TRUMP: Packet-Based Version
Link l: link load = (bytes in period T) / T
Update link prices every T
Arrival and departure of flows are notified
implicitly through price changes
Source i: Update path rates at maxj {RTTji}
18
Packet-level Experiments (NS-2)
 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?
19
TRUMP Link Dynamics
Link failure or recovery
Throughput (bits/s)
TRUMP reacts quickly to link dynamics
Same observation for ON-OFF flows
Time (s)
20
Summary of TRUMP Properties
Property
Tuning
Parameters
TRUMP
Robustness to
link dynamics
One easy to tune parameter
Only need to be tuned for small w
Reacts quickly to link failures and
recoveries
Robustness to
flow dynamics
General
Independent of variance of file sizes,
more efficient for larger files
Trumps other algorithms
Feedback
Possible with implicit feedback
21
Concluding Remarks
 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
22
The End…
Thank you!
www.princeton.edu/~jhe/research/conext07.pdf