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

3 Rethinking Traffic 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 Distributed Solutions TRUMP algorithm Optimization decomposition Compare using simulations TRUMP Protocol Translate into packet version

5 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

6 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 represent penalty for approaching capacity Avoids bottlenecks in the network link utilization

7 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

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

9 i source-destination pair, j path number How to make it 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

10 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

11 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

12 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

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

14 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

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

16 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 )

17 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

18 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

19  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)

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

21 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

22  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 Concluding Remarks

The End… Thank you!