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 a single 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  A design process Based on optimization decomposition  A new design For traffic management

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

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

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

10. 10 A Balanced Objective max. ∑ i U i (x i ) - w∑ l f(u l ) Network users: Maximize throughput Generate bottlenecks Network operators: Minimize delay Avoid bottlenecks Penalty weight

11. 11 Top-down Redesign Problem Formulation Distributed Solutions TRUMP algorithm Optimization decomposition Compare using simulations TRUMP Protocol Translate into packet version Optimization decomposition requires convexity

12. 12 Convex Problems are Easier to Solve Convex Non-convex  Convex problems have a global minimum  Distributed solutions that converge to global minimum can be derived using decomposition

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

14. 14 Overview of Distributed Solutions Edge node: Update path rates z Rate limit incoming traffic Operator: Tune w, U, f Other parameters Routers: Set up multiple paths Measure link load Update link prices s s s s

15. 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. 16  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) s l (t+1) = [s l (t) – stepsize* (y l – link load )] + link load ≤ c l link load = y l effective capacity y l ≤ c l

17. 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. 18 Four Decompositions - Differences AlgorithmsFeatures Parameters Partial-dual Effective capacity1 Primal-dual Effective capacity3 Full-dual Effective capacity, Allow packet loss 2 Primal-driven Direct s update1 Iterative updates contain parameters: They affect the dynamics of the distributed algorithms Differ in how link & source variables are updated

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

20. 20  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

21. 21 Effect of Penalty Weight ( w ) Can achieve high aggregate utility for a range of w User utility w Operator penalty Topology dependent

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

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

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 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 Top-down Redesign Problem Formulation Distributed Solutions TRUMP algorithm Optimization decomposition Compare using simulations TRUMP Protocol So far, assume fluid model, constant feedback delay 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 (in Sprint) TRUMP “trumps” partial dual for w ≤ 1/3 TRUMPPartial dual Total sending rate vs. time for TRUMP and Partial Dual

31. 31 TRUMP Link Dynamics (NJ-IN Link) TRUMP reacts quickly to link dynamics Link failure or recovery

32. 32 TRUMP versus file size TRUMP’s performance is independent of variance Worse for smaller files Still faster than TCP

33. 33 TRUMP: A Few Paths Suffice Do not need to incur the overhead of many paths… Worse for smaller files but still faster than TCP Having 2-3 paths is enough.

34. 34 Summary of TRUMP Properties 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 General Trumps other algorithms Feedback 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 Implicit feedback based on loss and delay Interdomain realization of the protocol 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 to bandwidth shares Theoretical foundation for adaptive network virtualization