Rethinking Traffic Management: Design Optimizable Networks
-
Upload
scorpio-goldberg -
Category
Documents
-
view
19 -
download
2
description
Transcript of Rethinking Traffic Management: Design Optimizable Networks
Rethinking Traffic Management:Design Optimizable Networks
Jiayue HeMay 9th, 2008
2
Approach: Theory Meets Practice
Using optimization theory: Analyze system properties Derive protocols and architectures
Practical solutions: Understand limitations of today’s
protocols and architectures Propose new protocols and architectures
implementable using existing technology
3
Traffic Management
Determines traffic rate along each path Supports multiple Internet applications
Application
Transport
Network
Link
Physical
TrafficManagement
4
Traffic Management Today
User (RTTs):Congestion Control
Operator (hours): Traffic Engineering
Routers (seconds):Routing Protocols
Evolved organically without conscious design
Goal: Redesign Traffic Management
Resource Allocation between Multiple Traffic Classes (Part III: 18
min)Throughput-Sensitive
Traffic Analysis (Part I: 10 min)Design (Part II: 22 min)
Other Traffic Classes
6
Scope of This Talk
Single Internet Service Provider backbone Control and visibility of network Traffic management of aggregate flows No inter-network economicsMultipath with flexible splitting
PART ONE
Can Congestion Control and Traffic Engineering Be at Odds?
8
Motivation
Congestion Control:
maximize user utility
Traffic Engineering:minimize network
congestionGiven routing Rli, how to adapt end rate xi?
Given traffic xi, how to perform routing Rli?
9
Goal: Understand Interaction
xi Rli
Congestion Control
Traffic Engineering
Understand system properties: Convergence to a stable value? What is a reasonable overall objective?
10
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 function represents user satisfaction and elasticity
routing matrix
Fair rate allocation among greedy users
Kelly98, Low03, Srikant04…
11
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 represents penalty for approaching capacityand approximates average queuing delay
To avoid bottlenecks in the network
link utilization
FortzThorup04
12
Model of Interaction
xi Rli
Congestion Control (RTTs):
max ∑i Ui(xi), s.t. ∑i Rlixi ≤ cl
Traffic Engineering (hours): min ∑l f(ul),
s.t. ul =∑i Rlixi/cl
Assume the TCP session is between two customers of same ISP
f is controlled by the operators and can be modified
13
Numerical Experiments MATLAB experiments:
Different topologies and capacity distributions Benchmark:
Observations: System converges Utility gap exists between the joint system
and benchmark
max. ∑i Ui(xi)s.t. Rx ≤ cVar. x, R
14
Simulation of the joint system suggests that it is stable, but suboptimal
Gap reduced if we change f to red curve
Backward Compatible Design
Link utilization ul
Cost f
ul =1
f(ul)
0
15
Theoretical Results
Theorem: the joint system model converges if Replace the capacity constraint in congest control with a penalty function Ui’’(xi) ≤ -Ui’(xi) /xi holds for all TCP variants
Master Problem:min. g(x,R) = - ∑iUi(xi) + γ∑lf(ul)
Congestion Control:argminx g(x,R)
Traffic Engineering:argminR g(x,R)
Gauss-Siedel
16
Pros and Cons of Changing f
Pros: Backwards compatible Can maximize aggregate user utility
Cons: Creates bottleneck links Fragile to high volume traffic bursts
Motivation for redesign in Part II
17
Contributions and Related Work
Related Work: Separate analysis of CC and TE Use congestion price as link weights
(WangLiLowDoyle05, HeChiangRexford06)
Contributions: Modeled the interaction between CC/TE Studied the interaction Proposed backward compatible design
PART TWO
TRUMP: TRaffic-management Using Multipath Protocol
Joint work with Ma’ayan Bresler and Martin Suchara
19
Motivation for Redesign
Shortcomings of today’s traffic management: Congestion control assumes routing is fixed;
traffic engineering assumes traffic is inelastic Traffic engineering occurs at the timescale of
hours, slower than traffic shifts Not taking full advantage of path diversity
Goal: redesign traffic management from scratch using optimization tools
20
Top-down Redesign
Problem Formulation
Distributed Solutions
TRUMP algorithm
Optimization decomposition
Compare using simulations
TRUMP Protocol
Translate into packet version
21
A Balanced Objective
max. ∑iUi(xi) - w∑lf(ul)
Congestion Control:Maximize
throughput Generate
bottlenecks
Traffic Engineering:Minimize congestion
Avoid bottlenecks
Penalty weight
22
Topologies with Different Pattern of Bottleneck Links
Abilene Internet2
Access-Core
Multihome
23
Effect of Penalty Weight w
Can achieve high aggregate utility for a range of w
User utility w Operator penalty
Depends on # of flows on each bottleneck link(U
-wf)
/U
24
Top-down Redesign
Problem Formulation
Distributed Solutions
TRUMP algorithm
Optimization decomposition
Compare using simulations
TRUMP Protocol
Translate into packet version
25
i source-destination pair, j path number
Multipath Formulation
max. ∑i Ui(∑j zji) – w∑l f(ul)
s.t. link load ≤ cl
var. path rates zz1
1
z21
z31
Path rate z captures source rate and routing
26
Overview of Distributed Solutions
Edge node: Update path rates zRate limit incoming traffic
Operator: Tune w, U, f Parameters tuned very rarely
Routers: Set up multiple pathsMeasure link loadUpdate link prices s
ss
s
Distributed algorithm runs on the timescale of RTTs
27
Four decompositions differ in number of tunable parameters
Theoretical results and limitations: All proven to converge to global optimum for
well-chosen parameters Little guidance for choosing parameters Only loose bounds for rate of convergence
Sweep large parameter space in MATLAB Compare rate of convergence Compare sensitivity of tunable parameters
Evaluating Four Decompositions
28
Convergence Properties
Tunable parameters impact convergence time
Best rate
Parameter sensitivity
Itera
tion
s to
co
nverg
en
ce
o average valuex actual values
Tunable parameter
29
For all algorithms: Parameter sensitivity correlated to rate of
convergence Trade-off between convergence and utility
Comparing between algorithms: Extra parameters do not improve
convergence Allowing packet loss improves convergence Direct update converges faster than
iterative update (with constant tunable parameter)
Convergence Properties (MATLAB)
30
Top-down Redesign
Problem Formulation
Distributed Solutions
TRUMP algorithm
Optimization decomposition
Compare using simulations
TRUMP Protocol
Translate into packet version
Construct TRUMP with different parts of previous algorithms
31
TRUMP Algorithm
Source i: Path rate zj
i(t+1) = max. Ui(∑kzki) – (zj
i )(path price)
Link l: pl(t+1) = [pl(t) – (βp)(cl – link load)]+
ql(t+1) = wf’(ul)
Price for path j = ∑ l on path j (pl+ql)
32
Theorem: TRUMP converges if: w is sufficiently large such that p=0 nl < αf '(ul) (1/ α + 1)/f ''(ul) , nl number of flows
Proof technique: contraction mapping TRUMP trumps previous distributed
algorithms (MATLAB): Observe convergence to optimum Faster convergence Converges in many scenarios if βp = 0.05/cl
2
TRUMP Properties
33
Top-down Redesign
Problem Formulation
Distributed Solutions
TRUMP algorithm
Optimization decomposition
Compare using simulations
TRUMP Protocol
So far, assume fluid model and constant feedback delay
Translate into packet version
34
TRUMP: Packet-Based Version
Link l: link load = (bytes in period T) / T Update link prices every T
Source i: Update path rates at maxj {RTTj
i}
Arrival and departure of flows areimplicitly conveyed through price changes
35
Set-up: Topologies and delays of large ISPs
(Rocketfuel data) Selected flows and paths Link failures and recoveries ON-OFF traffic model
Questions: Does TRUMP react quickly to dynamics? How many paths does TRUMP need?
Packet-level Experiments (NS-2)
36
TRUMP Link Dynamics (NS-2)
Link failure or recovery
Time (s)
Th
rou
gh
pu
t (M
bp
s)
TRUMP reacts quickly to link dynamicsSame observation for ON-OFF flows
TRUMP: A Few Paths Suffice
Sources benefit the most with a few alternative paths
Time (s)
Th
rou
gh
pu
t (M
bp
s)
38
Summary of TRUMP Properties
Property TRUMP
Tuning Parameters
Universal parameter settingOnly 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 algorithmsTwo or three paths suffice
39
Multiple decompositions (PalomarChiang06)
Design traffic-management protocols: Congestion control (FAST TCP) Dynamic traffic engineering (REPLEX,
TeXCP) Traffic management
(KeyMassoulieTowsley07, LinShroff06, Shakkottai et al 06, Voice07)
Related Work
40
Contributions Design process
Formulated new objective for traffic management
Compared four distributed algorithms (from decomposition)
Constructed TRUMP based on insights TRUMP
Universal parameter setting Packet-level protocol and simulations
PART THREE
DaVinci: Dynamically Adaptive Virtual Networks for a Customized Internet
Joint work with Rui Zhang-Shen, Ying Li, Mike Lee, Martin Suchara, and Umar Javed
42
Internet Has Many Applications
Different application requirements Throughput-sensitive: file transfer, web Delay-sensitive: VoIP, IPTV, online gaming
43
Support Multiple Traffic Classes
Key research areas: QoS: provides separate resources to support
multiple traffic classes in parallel Overlays: provide customized protocols for
each traffic class
Network virtualization is emerging Current applications: router consolidation,
experimental test beds, VPNs Router virtualization: separate resources Programmable routers: customized protocols
44
Virtual Networks
Each virtual node/link has isolated resources
45
Two traffic classes: Delay-sensitive traffic (DST): fixed demand Throughput-sensitive traffic (TST): elastic
Motivation for Virtualization
21
Single queue TST can fill up both
links DST may not be
satisfied
Shared routing DST chooses shorter
path Capacity wasted
5ms, 100 Mbps
10ms, 1000 Mbps
46
How to partition resources? Static partitioning
Simple, but can be inefficient One virtual network could be congested
while another is idle
Dynamically allocate bandwidth shares!
Adaptive Network Virtualization
47
DaVinci is an architecture to realize adaptive network virtualization
Virtual networks indexed by (k)
One per traffic class Run customized traffic-management
protocols
Substrate network Provides separate queues Computes per link bandwidth shares Enforce bandwidth shares with traffic shapers
Dynamically Adaptive Virtual Networks for a Customized Internet
48
DaVinci: Substrate Link
Bandwidth shares
computationlink load
yl(1)
yl(2)
yl(N)
Congestion price
computation
s l(1)
Use optimization to determine the computations
49
ISP: Maximize Aggregate Performance
max. ∑k w(k)U(k)(z(k), y(k))s.t. ∑k H(k)z(k)
≤ cvar. z(k) , y(k)
weighted aggregate performance objective
bandwidth sharespath rates
users + efficiently using resources = $$$
50
ISP problem decomposes into multiple subproblems (per traffic class):
Master problem update y(k) using Indication of congestion s(k)
Indication of performance d/dy(k) U(k)(z(k), y(k))
Primal Decomposition
max. U(k)(z(k), y(k))s.t. H(k)z(k)
≤ y(k)
var. z(k)
51
Bandwidth Allocation for Link l
v(k)l(t+1) = [y(k)
l(t) + (βy)(w(k)λ(k)
l)]+
Adjust bandwidth in two steps:
Projection onto feasible region:
∑k y(k)l ≤
cl
v
λ(k)l = s(k)
l +d/dy(k) U(k)(z(k), y(k))
Theorem
Theorem: the bandwidth share computation together with per traffic class problem maximizes aggregate performance if
The objective function and constraints are convex
The stepsize βy is diminishing
The bandwidth shares are updated when the congestion prices have converged
Proof technique: primal decomposition
System Properties from Theorem
Resources are efficiently utilized to maximize aggregate performance
Bandwidth shares converge to a stable value and the computation is
Based only on local link information
Each virtual network runs its own protocols independently
Bandwidth shares updated more slowly than congestion prices
53
54
DST on High Capacity, High Delay Link
DST does not use all the allocated bandwidth
21
Number of iterations
Mb
ps
5ms, 100 MbpsDST: 50Mbps
10ms, 1000 MbpsDST: 500Mbps
55
Related Work: QoS, overlays, and network virtualization Primal decomposition
Contributions: Introduced adaptive network virtualization Introduced DaVinci Proved stability and optimality of DaVinci
Related Work and Contributions
56
Traffic management today is An organic evolution Complex for operators
Redesign of traffic management to support multiple traffic classes:
TRUMP: design of an individual traffic class
DaVinci: design of resource allocation between traffic classes
Conclusions
57
Future Research Directions
Extending DaVinci: Tailoring to application-specific
requirements, e.g. R-factors for voice traffic
Running sub-optimal but simpler protocols
Interdomain traffic management requires
Economic incentives Protection against malicious users
58
Part One: Globecom, JSAC Part Two: CoNext, submitted to ToN Part Three: under preparation Related publications:
Multipath survey: IEEE Network Magazine
Design Optimizable Protocols: CCR Editorial, invited book chapter
Publications Related to Thesis
The End
Thank you!
60
Abilene Topology: f = e(yl/cl)
Gap exists
Standard deviation of capacity
Aggre
gate
uti
lity g
ap
61
Abilene Continued: f = n(yl/cl)n
Gap shrinks with larger nn
Aggre
gate
uti
lity g
ap
62
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
63
Rewrite capacity constraint:
Subgradient feedback price update:
Stepsize controls the granularity of reaction Stepsize is a tunable parameter
Effective capacity keeps system robust
Effective Capacity (Links)
sl(t+1) = [sl(t) – stepsize*(yl – link load)]+
link load ≤ cl
link load = yl
effective capacity yl≤ cl
64
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
65
Four Decompositions - Differences
Algorithms Features Paramete
rs
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 stepsizes:They affect the dynamics of the distributed algorithms
Differ in how link & source variables are updated
TRUMP versus File Size
TRUMP’s performance is independent of variance
Average File Size (Mbps)
Ach
ieved
ag
gre
gate
rate
s (%
)
TRUMP’s is better for large files
67
Delay-sensitive Traffic Minimizes Delay
min. ∑l
Hljizj
i(pl+f(ul))s.t. ul =∑i Rlixi/cl
∑i zji ≥ xD
i
var. z Link Utilization ul
Costf(ul)
Propagation delayLinks are indexed by l
ul =1
Cost function represents penalty for long queues
Traffic demand
68
Voice Traffic: R-factor
constants
R-factor: 50-60, 60-70, 70-80, 80-90, 90-100 Voice quality: poor, low, medium, high, best
R = Ra-α1δ – α2(δ – α3)H – β1 – β2log(1+β3φ)
End-to-end delay
Packet loss