Rethinking Internet Traffic Management Using Optimization Theory

1
Rethinking Internet Traffic Management Using
Optimization Theory

• Jennifer Rexford
• Princeton University

Joint work with Jiayue He, Martin Suchara,
Maayan Bresler, and Mung Chiang
http//www.cs.princeton.edu/jrex/papers/conext07.
pdf
2
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 todays artifacts
• To have a stronger intellectual foundation
• And move beyond the incremental fixes
• But, how do we do clean-slate design?

3
Two Ways to View This Talk

• 1. A design process
• based on optimization decomposition
• 2. A new design
• for traffic management

4
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
5
Traffic Management Today
Operator Traffic Engineering
Evolved organically without conscious design
Routers Routing Protocols
User Congestion Control
6
Shortcomings of Todays 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?
7
Top-down Redesign
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
8
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
9
Congestion Control ImplicitlyMaximizes Aggregate
User Utility
Source-destination pair indexed by i
User Utility Ui(xi)
Fair rate allocation amongst greedy users
Source rate xi
Utility represents user satisfaction and
elasticity of traffic
10
Traffic Engineering ExplicitlyMinimizes Network
Congestion
Links are indexed by l
Cost f(ul)
ul 1
Avoids bottlenecks in the network
Link Utilization ul
Cost function is a penalty for approaching
capacity
11
A Balanced Objective
max. ?iUi(xi) - w?lf(ul)
Penalty weight
Happy users Maximize throughput Generate
bottlenecks
Happy operators Minimize delay Avoids bottlenecks
12
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
13
Convex Problems are Easier to Solve
Non-convex
Convex

• Convex problems have a global min or max
• Distributed solutions that converge to global
  optimum can be derived using decomposition

14
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
z11
i source-destination pair, j path number
z21
z31
Path rate captures source rates and routing
15
Overview of Distributed Solutions
Operator Tune U, f, w 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
Link price is a penalty for violating a constraint
Path rates are updated based on prices along the
paths
16
Example Decomposition Effective Capacity (y)

• Rewrite capacity constraint as two constraints
• Subgradient update for the first constraint
• Stepsize controls the granularity of reaction
• Stepsize is a tunable parameter
• Gives advanced warning of congestion

link load yl yl cl
link load cl
sl(t1) sl(t) stepsize(yl link load)
Effective capacity helps ensure the system is
robust
17
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
18
Evaluate and Compare the Algorithms
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
Final Protocol
Optimization doesnt answer all the questions
19
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

20
Effect of Penalty Weight w
Topology dependent
Percent of max. achievable utility
User utility w
operator penalty
Can achieve high aggregate utility for a range of
w
21
Convergence Properties Partial Dual
o average value x actual values
Iterations to convergence
parameter sensitivity
Best rate
stepsize
Tunable parameters impact convergence time
22
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
23
Design a More Practical Algorithm
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
Final Protocol
Optimization doesnt answer all the questions
24
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

25
TRUMP Algorithm
Link l loss pl(t1) pl(t) stepsize(cl
link load) queuing delay change
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
26
TRUMP versus Other Algorithms

• TRUMP is not another decomposition
• We can prove convergence, but onlyunder more
  restrictive conditions
• From Matlab
• Faster rate of convergence
• Easy to tune parameter

27
Translate the Algorithm into a Protocol
Problem Formulation
Optimization decomposition
Distributed Solutions
Compare using simulations
TRUMP algorithm
Translate into packet version
TRUMP Protocol
Relax simplifying assumptions (greedy flows,
fluid model, )
28
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
29
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?

30
TRUMP versus Partial dual
TRUMP trumps partial dual for w1
31
TRUMP versus Partial dual
TRUMP trumps partial dual for w1/3
32
TRUMP Link Dynamics
Link failure or recovery
TRUMP reacts quickly to link dynamics
33
TRUMP versus file size
TRUMPs performance is independent of variance
34
TRUMP Trumps Other Algorithms
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
Also, may be possible with implicit feedback
35
Division of Functionality
Today TRUMP
Operators Tune link weights Set penalty function (Set-up multipath) Tune w stepsize
Sources Adapt source rates Adapt path rates
Routers Shortest path routing (Compute prices)

• Sources end hosts or edge routers?
• Feedback implicit or explicit?
• Computation centralized or distributed?

Mathematics leaves open architecture questions
36
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

37
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
38
Backup Slides
39
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

40
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