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

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

• Jiayue He
• Princeton University

Joint work with Martin Suchara, Maayan Bresler,
Mung Chiang, Jennifer Rexford
2
Traffic Management Today
Operator Traffic Engineering
Evolved organically without conscious design
Routers Routing Protocols
User Congestion Control
3
Rethinking Traffic Management

• Shortcomings of todays 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
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
5
Congestion Control ImplicitlyMaximizes Aggregate
User Utility
Source-destination pair indexed by i
aggregate utility
User Utility Ui(xi)
max.?i Ui(xi) s.t. ?i Rlixi cl var. x
Fair rate allocation amongst greedy users
routing matrix
source rate
Source rate xi
Utility represents user satisfaction and
elasticity of traffic
6
Traffic Engineering ExplicitlyMinimizes Network
Congestion
aggregate congestion cost
Links are indexed by l
Cost f(ul)
min. ?l f(ul) s.t. ul ?i Rlixi/cl var. R
ul 1
Avoids bottlenecks in the network
Link Utilization ul
link utilization
Cost function represent penalty for approaching
capacity
7
A Balanced Objective
max. ?iUi(xi) - w?lf(ul)
Penalty weight
Happy users Maximize throughput Generate
bottlenecks
Happy operators Minimize delay Avoids bottlenecks
8
Top-down Redesign
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
Optimization decomposition requires convexity
9
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
z11
i source-destination pair, j path number
z21
z31
Path rate captures source rates and routing
10
Overview of Distributed Solutions
Operator Tune w, U, f Other
parameters
s
s
s
Routers Set up multiple paths Measure link
load Update link prices s
Edge node Update path rates z Rate limit
incoming traffic
11
Four Decompositions - Differences
Differ in how link source variables are updated
Algorithms Features Parameters
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
12
Top-down Redesign
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
Final Protocol
Optimization doesnt answer all the questions
13
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

14
Convergence Properties (MATLAB)
Parameter sensitivity correlated to rate of
convergence
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
15
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

16
TRUMP Algorithm
Link l loss pl(t1) pl(t) stepsize(cl
link load) queuing delay ql(t1)
wf(ul)
Price for path j ? l on path j (plql)
Source i Path rate zji(t1) max. Ui(?kzki)
zji path price
17
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
18
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
19
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?

20
TRUMP Link Dynamics
Link failure or recovery
TRUMP reacts quickly to link dynamics Same
observation for ON-OFF flows
Throughput (bits/s)
Time (s)
21
Summary of TRUMP Properties
Property TRUMP
Tuning Parameters One easy to tune parameter Only 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
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

23
The End

• Thank you!
• www.princeton.edu/jhe/research/conext07.pdf