1. Rethinking Internet Traffic Management From Multiple Decompositions to a Practical Protocol Martin Suchara in collaboration with: J. He, M. Bresler, J. Rexford and M. Chiang

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

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

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

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

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

10. 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. 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. 12 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 1 2 3 4 5 7 8 10 11 6 9 6 9

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

14. 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. 15 Rewrite capacity constraint: Key Principles I: Effective Capacity link load c l link load = y l effective capacity y l c l Effective capacity keeps system robust Effective capacity y l Dynamically updated Advance warning of impending congestion Simulates the link running at lower capacity and give feedback on that

16. 16 Key Principles II: Consistency Price and Subgradient Updates Consistency price p l Relax constraint y l c l but penalize violation with price p l Allow packet loss to converge faster Subgradient feedback price update: Stepsize controls the granularity of reaction Stepsize is a tunable parameter p l (t+1) = [p l (t) – stepsize* (c l – y l (t))] +

17. 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. 18 Top-down Redesign Problem Formulation Distributed Solutions TRUMP Algorithm Optimization decomposition Compare using simulations Final Protocol Optimization doesnt 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 Evaluating Four Decompositions Sweep large parameter space in MATLAB Effect of w on convergence Compare rate of convergence Compare sensitivity of parameters

20. Simple Topologies Used in MATLAB 20 1 2 3 4 5 6 7 8 9 10 11 54 3 2 1 6

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

22. 22 Convergence Properties: Partial Dual in Access Core Topology Tunable parameters impact convergence time average value x actual values Parameter sensitivity Best convergence

23. 23 Convergence Properties (MATLAB) 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 TRUMP: TR affic-management U sing M ultipath P rotocol Cherry-pick different parts of previous algorithms to construct TRUMP One tunable parameter

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* ( link load - c l )] + 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 TRUMP Versus Other Algorithms From MATLAB: Faster rate of convergence Easy to tune parameter

27. 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. 28 TRUMP: Packet-based Version Link l : link load = (bytes in period T ) / (c l T) Update link prices every T Source i : Update path rates at max j { RTT j i } Arrivals and departures of flows are reflected in price changes

29. 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. 30 TRUMP Versus Partial Dual in Sprint TRUMP trumps partial dual for w 1/3 TRUMPPartial dual Aggregate throughput stabilizes for a range of ws No stepsize allows satisfactory convergence

31. 31 TRUMP Link Dynamics TRUMP reacts quickly to link dynamics Link connecting NJ and IN in the Sprint network fails and recovers

32. 32 TRUMP Versus File Size TRUMPs performance is independent of variance Worse for smaller files but still faster than TCP

33. 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. 34 Summary of TRUMP Properties

35. 35 Division of Functionality Sources: end hosts or edge routers? Feedback: implicit or explicit? Mathematics leaves open architecture questions

36. 36 The Next Steps So far the utility function maximizes utility of throughput sensitive traffic However, not all traffic throughput sensitive:

37. 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. 38 Conclusions Traffic engineering Started with multiple decompositions Designed TRUMP: new traffic- management protocol What to do next? Support of different traffic classes

39. 39 Thank You!

40. 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.)