Rethinking Internet Traffic Management: From Multiple Decompositions to a Practical Protocol

1. Rethinking Internet Traffic Management: From Multiple Decompositions to a Practical Protocol Jiayue He Princeton University Joint work with Martin Suchara, Ma’ayan Bresler, Mung Chiang, Jennifer Rexford

2. Traffic Management Today Operator: Traffic Engineering Evolved organically without conscious design Routers: Routing Protocols User: Congestion Control

3. RethinkingTraffic Management Shortcomings of today’s traffic management: Congestion control assumes routing is fixed, traffic engineering assumes traffic is inelastic Link weight tuning problem is NP-hard Link weights are tuned at the timescale of hours, slower than traffic shifts What if we redesign traffic management from scratch using optimization tools?

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

5. Congestion Control ImplicitlyMaximizes Aggregate User Utility Source-destination pair indexed by i aggregate utility User Utility Ui(xi) max.∑iUi(xi) s.t.∑i Rlixi ≤ cl var. x Fair rate allocation amongst greedy users routing matrix source rate Source rate xi Utility represents user satisfaction and elasticity of traffic

6. Traffic Engineering ExplicitlyMinimizes Network Congestion Links are indexed by l aggregate congestioncost Cost f(ul) min.∑l f(ul) s.t. ul =∑i Rlixi/cl var. R ul =1 Avoids bottlenecks in the network Link Utilization ul link utilization Cost function represent penalty for approaching capacity

7. A Balanced Objective max. ∑iUi(xi) - w∑lf(ul) Penalty weight Happy users Maximize throughput Generate bottlenecks Happy operators Minimize delay Avoids bottlenecks

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

9. How to make it convex? • Single path routing is non convex • Multipath routing + flexible splitting is convex max. ∑i Ui(∑j zji) – w∑l f(ul) s.t.link load≤ cl var.path ratesz z11 isource-destination pair, jpath number z21 z31 Path rate captures source rates and routing

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

11. Four Decompositions - Differences Differ in how link & source variables are updated Iterative updates contain parameters: They affect the dynamics of the distributed algorithms

12. Top-down Redesign Problem Formulation Optimization decomposition Distributed Solutions Compare using simulations TRUMP algorithm Translate into packet version Final Protocol Optimization doesn’t answer all the questions

13. Evaluating Four Decompositions • 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

14. Convergence Properties (MATLAB) Parameter sensitivity correlated to rate of convergence

15. TRUMP: TRaffic-management Using Multipath Protocol • 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 • TRUMP trumps previous distributed solutions (MATLAB) • Faster rate of convergence • One easy to tune parameter

16. TRUMP Algorithm Link l:losspl(t+1) = [pl(t) – stepsize(cl –link load)]+ queuingdelayql(t+1) = wf’(ul) Price for path j = ∑ l on path j(pl+ql) Source i: Path rate zji(t+1) = max. Ui(∑kzki) – zji *path price

17. Top-down Redesign Problem Formulation Optimization decomposition Distributed Solutions Compare using simulations TRUMP algorithm Translate into packet version TRUMP Protocol So far, assume fluid model, constant feedback delay

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

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

20. TRUMP Link Dynamics Link failure or recovery TRUMP reacts quickly to link dynamics Same observation for ON-OFF flows Throughput (bits/s) Time (s)

21. Summary of TRUMP Properties

22. Concluding Remarks • Contributions: • Design with multiple decompositions • Introduce practical traffic management protocol • Math leaves architectural choices • Feedback: implicit versus explicit • Edge nodes: end hosts versus edge router • Computations: centralized versus distributed

23. The End… Thank you! www.princeton.edu/~jhe/research/conext07.pdf