Rethinking Internet Traffic Management
Using Optimization Theory
Jennifer Rexford
Princeton University
Joint work with Jiayue He, Martin Suchara, Ma’ayan Bresler, and Mung Chiang
http://www.cs.princeton.edu/~jrex/papers/conext07.pdf
Clean-Slate Network Architecture
 Network architecture
 More than designing or refining one protocol
 Definition and placement of function
 Clean-slate design
 Without the constraints of today’s artifacts
 To have a stronger intellectual foundation
 And move beyond the incremental fixes
But, how do we do clean-slate design?
2
Two Ways to View This Talk
1. A design process
based on optimization decomposition
2. A new design
for traffic management
3
Why Traffic Management?
 Traffic management is important
 Determines traffic rate along each path
 Encompasses major resource-allocation issues
 Routing, congestion control, traffic engineering, …
 Some traction studying mathematically




Reverse engineering of TCP
Redesigning protocols (e.g., TCP variants)
Distributed algorithms for shortest-path routing
Optimization techniques for tuning protocols
But still does not have a holistic view…
4
Traffic Management Today
Operator:
Traffic Engineering
Evolved organically without conscious design
User:
Congestion Control
Routers:
Routing Protocols
5
Shortcomings of Today’s
Traffic Management
 Protocol interactions ignored
 Congestion control assumes routing is fixed
 TE assumes the traffic is inelastic
 Inefficiency of traffic engineering
 Link-weight tuning problem is NP-hard
 TE at the timescale of hours or days
 Only limited use of multiple paths
What would a clean-slate redesign look like?
6
Top-down Redesign
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
7
Formulating an Optimization Problem
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
Need to define an objective function for the system
8
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
9
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 is a penalty for approaching capacity
10
A Balanced Objective
max. ∑iUi(xi) - w∑lf(ul)
Penalty weight
Happy users
Maximize throughput
Generate bottlenecks
Happy operators
Minimize delay
Avoids bottlenecks
11
Derive Optimal Distributed Algorithms
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
Optimization decomposition requires convexity
12
Convex Problems are Easier to Solve
Convex
Non-convex
 Convex problems have a global min or max
 Distributed solutions that converge to global
optimum can be derived using decomposition
13
How to make our problem 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
14
Overview of Distributed Solutions
Operator: Tune U, f, w
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
Path rates
Link are
price
updated
is a penalty
basedfor
onviolating
prices along
a constraint
the paths
15
Example Decomposition: Effective Capacity (y)
 Rewrite capacity constraint as two constraints:
link load = yl
link load ≤ cl
yl≤ cl
 Subgradient update for the first constraint:
sl(t+1) = [sl(t) – stepsize*(yl – link load)]+
 Stepsize controls the granularity of reaction
 Stepsize is a tunable parameter
 Gives advanced warning of congestion
16
Effective capacity helps ensure the system is robust
Generating Multiple Decompositions
 Three vary in how they enforce yl≤ cl
 Partial dual (1 parameter)
 Explicit computation of yl
 Primal dual (3 parameters)
 Iterative update to yl
 Full dual (2 parameters)
 Relax the constraint to allow overshoot
 Fourth changes the objective function
 Primal driven (1 parameter)
 Add penalty for high link loads
Differ in how link & source variables are updated
17
Evaluate and Compare the Algorithms
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
Final Protocol
Optimization doesn’t answer all the questions
18
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
19
Effect of Penalty Weight w
Percent of max. achievable utility
Topology dependent
User utility
w
operator penalty
Can achieve high aggregate utility for a range of w
20
Convergence Properties: Partial Dual
Iterations to convergence
o average value
x actual values
parameter sensitivity
Best rate
stepsize
Tunable parameters impact convergence time
21
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
22
Design a More Practical Algorithm
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
Final Protocol
Optimization doesn’t answer all the questions
23
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
 One tunable parameter
24
TRUMP Algorithm
Link l: loss pl(t+1) = [pl(t) – stepsize(cl – link load)]+
queuing delay change 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
25
TRUMP versus Other Algorithms
 TRUMP is not another decomposition
 We can prove convergence, but only
under more restrictive conditions
 From Matlab:
 Faster rate of convergence
 Easy to tune parameter
26
Translate the Algorithm into a Protocol
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
27
Relax simplifying assumptions (greedy flows, fluid model, …)
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}
28
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?
29
TRUMP versus Partial dual
TRUMP trumps partial dual for w=1
30
TRUMP versus Partial dual
TRUMP trumps partial dual for w=1/3
31
TRUMP Link Dynamics
Link failure
or recovery
TRUMP reacts quickly to link dynamics
32
TRUMP versus file size
TRUMP’s performance is independent of variance
33
TRUMP “Trumps” Other Algorithms
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
Independent of variance of file sizes,
more efficient for larger files
Also, may be possible with implicit feedback…
34
Division of Functionality
Today
Operators Tune link weights
Set penalty function
Sources Adapt source rates
Routers Shortest path routing
TRUMP
(Set-up multipath)
Tune w & stepsize
Adapt path rates
(Compute prices)
 Sources: end hosts or edge routers?
 Feedback: implicit or explicit?
 Computation: centralized or distributed?
Mathematics leaves open architecture questions
35
Conclusions
 Contributions:
 Design with multiple decompositions
 New TRUMP traffic-management protocol
 Extensions to TRUMP
 Interdomain realization of the protocol
 Multipath interdomain routing
 Preventing dishonest link feedback
 Implicit feedback about link load
 Monitoring path loss and delay at sources
36
Ongoing Work: Multiple Traffic Classes
 Different application requirements
 Throughput-sensitive: file transfers
 Delay-sensitive: VoIP and gaming
 Optimization formulation
 Weighted sum of the two objectives
 Per-class variables for routes and rates
 Decompose into two subproblems
 Two virtual networks with custom protocols
 Simple dynamic update of bandwidth shares
Toward a theory for adaptive network virtualization
37
Backup Slides
38
Optimization Decomposition
 Deriving prices and path rates
 Prices: penalties for violating a constraint
 Path rates: updates driven by penalties
 Example: TCP congestion control
 Link prices: packet loss or delay
 Source rates: AIMD based on prices
 Our problem is more complicated
 More complex objective, and multiple paths
39
Key Architectural Principles
 Effective capacity
 Advance warning of impending congestion
 Simulates the link running at lower capacity
and give feedback on that
 Dynamically updated
 Consistency price
 Allowing some packet loss
 Allowing some overshooting in exchange for
faster convergence
40