1. Rethinking Internet Traffic Management Using Optimization Theory Jennifer Rexford Princeton University Joint work with Jiayue He, Martin Suchara, Ma’ayan Bresler, and Mung Chiang http://www.cs.princeton.edu/~jrex/papers/conext07.pdf

2. 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 today’s artifacts To have a stronger intellectual foundation And move beyond the incremental fixes But, how do we do clean-slate design?

3. 3 Two Ways to View This Talk 1. A design process based on optimization decomposition 2. A new design for traffic management

4. 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. 5 Traffic Management Today User: Congestion Control Operator: Traffic Engineering Routers: Routing Protocols Evolved organically without conscious design

6. 6 Shortcomings of Today’s 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. 7 Top-down Redesign Problem Formulation Distributed Solutions TRUMP algorithm Optimization decomposition Compare using simulations TRUMP Protocol Translate into packet version

8. 8 Formulating an Optimization Problem Problem Formulation Distributed Solutions TRUMP algorithm Optimization decomposition Compare using simulations TRUMP Protocol Translate into packet version Need to define an objective function for the system

9. 9 Congestion Control Implicitly Maximizes Aggregate User Utility Source rate x i User Utility U i (x i ) Source-destination pair indexed by i Utility represents user satisfaction and elasticity of traffic max. ∑ i U i (x i ) s.t. ∑ i R li x i ≤ c l var. x aggregate utility source rate routing matrix Fair rate allocation amongst greedy users

10. 10 Traffic Engineering Explicitly Minimizes Network Congestion Link Utilization u l Cost f(u l ) Links are indexed by l u l =1 Cost function is a penalty for approaching capacity min. ∑ l f(u l ) s.t. u l =∑ i R li x i /c l var. R aggregate congestion cost link utilization Avoids bottlenecks in the network

11. 11 A Balanced Objective max. ∑ i U i (x i ) - w∑ l f(u l ) Happy users Maximize throughput Generate bottlenecks Happy operators Minimize delay Avoids bottlenecks Penalty weight

12. 12 Derive Optimal Distributed Algorithms Problem Formulation Distributed Solutions TRUMP algorithm Optimization decomposition Compare using simulations TRUMP Protocol Translate into packet version Optimization decomposition requires convexity

13. 13 Convex Problems are Easier to Solve Convex Non-convex  Convex problems have a global min or max  Distributed solutions that converge to global optimum can be derived using decomposition

14. 14 i source-destination pair, j path number How to make our problem convex? max. ∑ i U i (∑ j z j i ) – w∑ l f(u l ) s.t. link load ≤ c l var. path rates z z11z11 z21z21 z31z31  Single path routing is non convex  Multipath routing + flexible splitting is convex Path rate captures source rates and routing

15. 15 Overview of Distributed Solutions Edge node: Update path rates z Rate limit incoming traffic Operator: Tune U, f, w Other parameters Routers: Set up multiple paths Measure link load Update link prices s s s s Link price is a penalty for violating a constraintPath rates are updated based on prices along the paths

16. 16  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 Example Decomposition: Effective Capacity (y) s l (t+1) = [s l (t) – stepsize* (y l – link load )] + link load ≤ c l link load = y l y l ≤ c l Effective capacity helps ensure the system is robust

17. 17 Generating Multiple Decompositions  Three vary in how they enforce y l ≤ c l Partial dual (1 parameter)  Explicit computation of y l Primal dual (3 parameters)  Iterative update to y l 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. 18 Evaluate and Compare the Algorithms 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. 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  Sweep large parameter space in Matlab Effect of w on convergence Compare rate of convergence Compare sensitivity of parameters Evaluating Four Decompositions

20. 20 Effect of Penalty Weight w Can achieve high aggregate utility for a range of w Topology dependent User utility w operator penalty Percent of max. achievable utility

21. 21 Convergence Properties: Partial Dual Tunable parameters impact convergence time Best rate parameter sensitivity stepsize Iterations to convergence o average value x actual values

22. 22 Convergence Properties (Matlab) AlgorithmsConvergence 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 Parameter sensitivity correlated to rate of convergence

23. 23 Design a More Practical Algorithm Problem Formulation Distributed Solutions TRUMP algorithm Optimization decomposition Compare using simulations Final Protocol Optimization doesn’t answer all the questions Translate into packet version

24. 24  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 TRUMP: TRaffic-management Using Multipath Protocol

25. 25 TRUMP Algorithm Source i : Path rate z j i (t+1) = max. U i (∑ k z k i ) – z j i * path price Link l : loss p l (t+1) = [ p l (t) – stepsize ( c l – link load )] + queuing delay change q l (t+1) = wf’ ( u l ) Price for path j = ∑ l on path j ( p l +q l )

26. 26  TRUMP is not another decomposition We can prove convergence, but only under more restrictive conditions  From Matlab: Faster rate of convergence Easy to tune parameter TRUMP versus Other Algorithms

27. 27 Translate the Algorithm into a Protocol Problem Formulation Distributed Solutions TRUMP algorithm Optimization decomposition Compare using simulations TRUMP Protocol Relax simplifying assumptions (greedy flows, fluid model, …) Translate into packet version

28. 28 TRUMP: Packet-Based Version Link l : link load = (bytes in period T ) / T Update link prices every T Source i : Update path rates at max j { RTT j i } Arrival and departure of flows are notified implicitly through price changes

29. 29  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? Packet-level Experiments (NS-2)

30. 30 TRUMP versus Partial dual TRUMP trumps partial dual for w=1

31. 31 TRUMP versus Partial dual TRUMP trumps partial dual for w=1/3

32. 32 TRUMP Link Dynamics TRUMP reacts quickly to link dynamics Link failure or recovery

33. 33 TRUMP versus file size TRUMP’s performance is independent of variance

34. 34 TRUMP “Trumps” Other Algorithms PropertyTRUMP 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. 35 Division of Functionality TodayTRUMP Operators Tune link weights Set penalty function (Set-up multipath) Tune w & stepsize Sources Adapt source ratesAdapt 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. 36  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 Conclusions

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

39. 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. 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