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 a single 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

• A design process
• Based on optimization decomposition
• A new design
• For traffic management

4
Why Traffic Management?

• Traffic management is important
• Determines traffic rate along each path
• Major resource-allocation issues
• Routing, congestion control, traffic engineering,
  
• Some traction studying mathematically
• Reverse engineering of TCP
• Redesigning protocols (e.g., TCP variants)
• Mathematical tools 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
Shortcoming 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
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
9
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 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
Top-down Redesign
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
Non-convex
Convex

• Convex problems have a global minimum
• Distributed solutions that converge to global
  minimum 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
z11
i source-destination pair, j path number
z21
z31
Path rate captures source rates and routing
14
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
15
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, multiple paths

16
Effective Capacity (Links)

• Rewrite capacity constraint
• Subgradient feedback price update
• Stepsize controls the granularity of reaction
• Stepsize is a tunable parameter
• Effective capacity keeps system robust

link load yl effective capacity yl cl
link load cl
sl(t1) sl(t) stepsize(yl link load)
17
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

18
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
19
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
20
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

21
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
22
Convergence Properties Partial Dual
o average value x actual values
Iterations to convergence
parameter sensitivity
Best rate
stepsize
Tunable parameters impact convergence time
23
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
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 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
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
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
Worse for smaller files Still faster than TCP
TRUMPs performance is independent of variance
34
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
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
• Implicit feedback based on loss and delay
• Interdomain realization of the protocol

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 to bandwidth shares

Theoretical foundation for adaptive network
virtualization