Rethinking Traffic Management: Design Optimizable Networks Jiayue He May 9 th, 2008

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