Rethinking Internet Traffic ManagementFrom Multiple Decompositions to a Practical Protocol
Martin Suchara
in collaboration with:J. He, M. Bresler,
J. Rexford and M. Chiang
2
Why Study Traffic Management?
Traffic management is important Determines traffic rates and divides resources Integrates routing, congestion control, traffic
engineering, …
Motivated by recent advancements in optimization theory research
The architecture has shortcomings Suboptimal interactions of components
important
shortcomings
3
Traffic Management Today
User:Congestion Control
Operator: Traffic Engineering
Routers:Routing Protocols
Evolved organically without conscious design
4
Shortcomings of Today’s Architecture
Protocol interactions ignored Congestion control assumes routing is fixed TE assumes the traffic is inelastic
What would a clean-slate redesign look like?
Inefficiency of traffic engineering Link-weight tuning problem is NP-hard TE at the timescale of hours or days
5
Contributions of This Talk
1. Case study of a design process Based on optimization decompositions Evaluations using simulation also needed
2. The new design Of network traffic management
The next steps: Towards virtualized networks
6
Top-down Redesign
Problem Formulation
Distributed Solutions
TRUMP Algorithm
Optimization decomposition
Compare using simulations
TRUMP Protocol
Translate into packet version
7
Congestion Control ImplicitlyMaximizes Aggregate User Utility
max.∑i Ui(xi)s.t. ∑i Rlixi ≤ cl
var. x
aggregate utility
Source rate xi
UserutilityUi(xi)
Source-destination pair indexed by i
source rate
Utility represents user satisfaction and elasticity of traffic
routing matrix
Fair rate allocation amongst greedy users
8
Traffic Engineering ExplicitlyMinimizes Network Congestion
min. ∑l f(ul)s.t. ul =∑i Rlixi /cl
var. R Link Utilization ul
Costf(ul)
aggregate congestion costLinks are indexed by l
ul =1
Cost function is a penalty for approaching capacity
Avoids bottlenecks in the network
link utilization
9
A Balanced Objective
max. ∑i Ui(xi) - w∑l f(ul)
Network users:Maximize throughput Generate bottlenecks
Network operators:Minimize delay
Avoid bottlenecks
Penalty weight
10
Top-down Redesign
Problem Formulation
Distributed Solutions
TRUMP Algorithm
Optimization decomposition
Compare using simulations
TRUMP Protocol
Translate into packet version
Optimization decomposition requires convexity
11
Convex Problems are Easier to Solve
Convex Non-convex
Convex problems have a global minimum Distributed solutions that converge to global
minima can be derived using decompositions
12
i source-destination pair, j path number
How to Make our Problem Convex?
max. ∑i Ui(∑j zji) – w∑l
f(ul)s.t. link load ≤ cl
var. path rates zz11
z21
z31
Single path routing is non convex Multipath routing + flexible splitting is convex
Path rate captures source rates and routing
1
2
3
4
5
7
8
1
0
1
1
69 69
13
Overview of Distributed Solutions
Edge node: Update path rates zRate limit incoming traffic
Operator: Tune w, U, f Other parameters
Routers: Set up multiple pathsMeasure link loadUpdate link prices s
ss
s
14
Role of Optimization Decompositions
Derive price and path rate updates Prices: penalties for violating a constraint Path rates: updates driven by penalties
Example: TCP congestion control Link prices: level of packet loss or delay Source rates: adjust window based on prices
Our problem is more complicated More complex objective, multiple paths
15
Rewrite capacity constraint:
Key Principles I: Effective Capacity
link load ≤ cl
link load = yl
effective capacity yl ≤ cl
Effective capacity keeps system robust
Effective capacity yl
Dynamically updated Advance warning of impending congestion Simulates the link running at lower capacity
and give feedback on that
16
Key Principles II: Consistency Price and Subgradient Updates
Consistency price pl
Relax constraint yl ≤ cl but penalize violation with price pl
Allow packet loss to converge faster Subgradient feedback price update:
Stepsize controls the granularity of reaction Stepsize is a tunable parameter
pl(t+1) = [pl(t) – stepsize*(cl – yl
(t))]+
17
Four Decompositions – Differences
Iterative updates contain stepsizes:They affect the dynamics of the distributed algorithms
Differ in how link & source variables are updated
18
Top-down Redesign
Problem Formulation
Distributed Solutions
TRUMP Algorithm
Optimization decomposition
Compare using simulations
Final Protocol
Optimization doesn’t answer all the questions
Translate into packet version
19
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
Evaluating Four Decompositions
Sweep large parameter space in MATLAB Effect of w on convergence Compare rate of convergence Compare sensitivity of parameters
Simple Topologies Used in MATLAB
20
1
2
3
4
5
6
7
8
9
1
0
1
1
54
3
2
1
6
21
Effect of Penalty Weight w
Can achieve high aggregate utility for a range of w
Topology dependent
User utility w Operator penalty
22
Convergence Properties: Partial Dual in Access Core Topology
Tunable parameters impact convergence time
● average valuex actual values
Parameter sensitivity
Best convergence
23
Convergence Properties (MATLAB)
Parameter sensitivity correlated to rate of convergence
24
Insights from simulations: Have as few tunable parameters as
possible Use direct update when possible Allow some packet loss
TRUMP: TRaffic-management Using Multipath Protocol
Cherry-pick different parts of previous algorithms to construct TRUMP
One tunable parameter
25
TRUMP Algorithm
Source i: Path rate zj
i(t+1) = max. (Ui(∑kzki) – zj
i *path price)
Link l: loss pl(t+1) = [pl(t) + stepsize*(link load - cl )]+
queuing delay ql(t+1) = wf’(ul)
Price for path j = ∑ l on path j (pl+ql)
26
TRUMP is not another decomposition We can prove convergence, but only
under more restrictive conditions
TRUMP Versus Other Algorithms
From MATLAB: Faster rate of convergence Easy to tune parameter
Top-down Redesign
Problem Formulation
Distributed Solutions
TRUMP Algorithm
Optimization decomposition
Compare using simulations
TRUMP Protocol
So far, assumed fluid model, constant feedback delay, greedy traffic sources
Translate into packet version
27
28
TRUMP: Packet-based Version
Link l: link load = (bytes in period T) / (clT) Update link prices every T
Source i: Update path rates at maxj {RTTji}
Arrivals and departures of flows are reflected in price changes
29
Set-up: Synthetic topologies + realistic topologies
and delays of large ISPs Multiple paths with 1ms to 400ms of delay Realistic ON-OFF traffic model
Packet-level Experiments in NS-2
Questions: Do MATLAB results still hold? Does TRUMP react quickly to link
dynamics? Can it handle ON-OFF flows? Number of paths needed?
30
TRUMP Versus Partial Dual in Sprint
TRUMP trumps partial dual for w ≤ 1/3
TRUMP Partial dual
Aggregate throughput stabilizes for a range of w’s
No stepsize allows satisfactory convergence
31
TRUMP Link Dynamics
TRUMP reacts quickly to link dynamics
Link connecting NJ and IN in the Sprint network fails and recovers
32
TRUMP Versus File Size
TRUMP’s performance is independent of variance
Worse for smaller files but still faster than TCP
33
TRUMP: A Few Paths Suffice
Sources benefit the most when they learn a few paths
Worse for smaller files but still faster than TCP
Diminishing returns when providing more than 2 paths
34
Summary of TRUMP Properties
35
Division of Functionality
Sources: end hosts or edge routers? Feedback: implicit or explicit?
Mathematics leaves open architecture questions
36
The Next Steps So far the utility function maximizes utility of
throughput sensitive traffic
However, not all traffic throughput sensitive:
37
The Next Steps: Virtualization Need to support multiple types of applications
Throughput-sensitive: file transfers Delay-sensitive: VoIP and gaming
Questions What should the utility for each application
look like? How to share network resources
dynamically?
38
Conclusions
Traffic engineering Started with multiple decompositions Designed TRUMP: new traffic-
management protocol
What to do next? Support of different traffic classes
39
Thank You!
40
Related Work
Advancements in optimization theory Protocol reverse engineering (Kelly98, Low03)
Design of new protocols (Low06)
Multiple decompositions (Chiang06)
Traffic management protocols consider congestion control or traffic engineering Congestion control alone (FAST TCP,
RCP, XCP, etc.) Use of multiple paths without adjusting
source rates (MATE, REPLEX, etc.)