Rethinking Traffic Management: Design Optimizable Networks

1. Rethinking Traffic Management:Design Optimizable Networks Jiayue He May 9th, 2008

2. Approach: Theory Meets Practice • Using optimization theory: • Analyze system properties • Derive protocols and architectures • Practical solutions: • Understand limitations of today’s protocols and architectures • Propose new protocols and architectures implementable using existing technology

3. Application Transport Network Link Physical Traffic Management • Determines traffic rate along each path • Supports multiple Internet applications Traffic Management

4. Traffic Management Today Operator (hours): Traffic Engineering Evolved organically without conscious design Routers (seconds): Routing Protocols User (RTTs): Congestion Control

5. Goal: Redesign Traffic Management Resource Allocation between Multiple Traffic Classes (Part III: 18 min) Throughput-Sensitive Traffic Analysis (Part I: 10 min) Design (Part II: 22 min) Other Traffic Classes

6. Scope of This Talk • Single Internet Service Provider backbone • Control and visibility of network • Traffic management of aggregate flows • No inter-network economics Multipath with flexible splitting

7. PART ONE Can Congestion Control and Traffic Engineering Be at Odds?

8. Motivation • Congestion Control: maximize user utility • Traffic Engineering: minimize network congestion Given routing Rli, how to adapt end rate xi? Given traffic xi, how to perform routing Rli?

9. Goal: Understand Interaction Congestion Control xi Rli Traffic Engineering • Understand system properties: • Convergence to a stable value? • What is a reasonable overall objective?

10. 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 among greedy users routing matrix source rate Source Rate xi Utility function represents user satisfaction and elasticity Kelly98, Low03, Srikant04…

11. 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 To avoid bottlenecks in the network ul =1 link utilization Link Utilization ul Cost function represents penalty for approaching capacity and approximates average queuing delay FortzThorup04

12. Model of Interaction Assume the TCP session is between two customers of same ISP Congestion Control (RTTs): max ∑i Ui(xi), s.t. ∑i Rlixi ≤ cl xi Rli Traffic Engineering (hours): min ∑l f(ul), s.t. ul =∑i Rlixi/cl f is controlled by the operators and can be modified

13. Numerical Experiments • MATLAB experiments: • Different topologies and capacity distributions • Benchmark: • Observations: • System converges • Utility gap exists between the joint system and benchmark max. ∑i Ui(xi) s.t.Rx ≤ c Var. x, R

14. Backward Compatible Design • Simulation of the joint system suggests that it is stable, but suboptimal • Gap reduced if we change f to red curve Cost f f(ul) ul =1 0 Link utilization ul

15. Theoretical Results Theorem: the joint system model converges if • Replace the capacity constraint in congest control with a penalty function • Ui’’(xi)≤-Ui’(xi)/xi holds for all TCP variants Master Problem: min. g(x,R) = - ∑iUi(xi) + γ∑lf(ul) Gauss-Siedel Congestion Control: argminx g(x,R) Traffic Engineering: argminR g(x,R)

16. Pros and Cons of Changing f • Pros: • Backwards compatible • Can maximize aggregate user utility • Cons: • Creates bottleneck links • Fragile to high volume traffic bursts Motivation for redesign in Part II

17. Contributions and Related Work • Related Work: • Separate analysis of CC and TE • Use congestion price as link weights (WangLiLowDoyle05, HeChiangRexford06) • Contributions: • Modeled the interaction between CC/TE • Studied the interaction • Proposed backward compatible design

18. PART TWO TRUMP: TRaffic-management Using Multipath Protocol Joint work with Ma’ayan Bresler and Martin Suchara

19. Motivation for Redesign Shortcomings of today’s traffic management: Congestion control assumes routing is fixed; traffic engineering assumes traffic is inelastic Traffic engineering occurs at the timescale of hours, slower than traffic shifts Not taking full advantage of path diversity Goal: redesign traffic management from scratch using optimization tools

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

21. A Balanced Objective max. ∑iUi(xi) - w∑lf(ul) Penalty weight Congestion Control: Maximize throughput Generate bottlenecks Traffic Engineering: Minimize congestion Avoid bottlenecks

22. Topologies with Different Pattern of Bottleneck Links Access-Core Abilene Internet2 Multihome

23. Effect of Penalty Weight w (U-wf)/U Depends on # of flows on each bottleneck link User utility wOperator penalty Can achieve high aggregate utility for a range of w

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

25. Multipath Formulation • Path ratez captures source rate and routing max. ∑i Ui(∑j zji) – w∑l f(ul) s.t.link load≤ cl var.path ratesz isource-destination pair, jpath number z11 z21 z31

26. Overview of Distributed Solutions Operator: Tune w, U, f Parameters tuned very rarely s s s Routers: Set up multiple paths Measure link load Update link prices s Edge node: Update path ratesz Rate limit incoming traffic Distributed algorithm runs on the timescale of RTTs

27. Evaluating Four Decompositions • Four decompositions differ in number of tunable parameters • Theoretical results and limitations: • All proven to converge to global optimum for well-chosenparameters • Little guidance for choosing parameters • Only loose bounds for rate of convergence • Sweep large parameter space in MATLAB • Compare rate of convergence • Compare sensitivity of tunable parameters

28. Convergence Properties Iterations to convergence o average value x actual values Parameter sensitivity Best rate Tunable parameter Tunable parameters impact convergence time

29. Convergence Properties (MATLAB) • For all algorithms: • Parameter sensitivity correlated to rate of convergence • Trade-off between convergence and utility • Comparing between algorithms: • Extra parameters do not improve convergence • Allowing packet loss improves convergence • Direct update converges faster than iterative update (with constant tunable parameter)

30. Top-down Redesign Problem Formulation Optimization decomposition Distributed Solutions Compare using simulations TRUMP algorithm Translate into packet version TRUMP Protocol Construct TRUMP with different parts of previous algorithms

31. TRUMP Algorithm Link l:pl(t+1) = [pl(t) – (βp)(cl –link load)]+ ql(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)

32. TRUMP Properties Theorem: TRUMP converges if: • w is sufficiently large such that p=0 • nl < αf '(ul) (1/ α + 1)/f ''(ul) , nl number of flows • Proof technique: contraction mapping • TRUMP trumps previous distributed algorithms (MATLAB): • Observe convergence to optimum • Faster convergence • Converges in many scenarios if βp = 0.05/cl2

33. 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 and constant feedback delay

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

35. Packet-level Experiments (NS-2) • Set-up: • Topologies and delays of large ISPs (Rocketfuel data) • Selected flows and paths • Link failures and recoveries • ON-OFF traffic model • Questions: • Does TRUMP react quickly to dynamics? • How many paths does TRUMP need?

36. TRUMP Link Dynamics (NS-2) Link failure or recovery TRUMP reacts quickly to link dynamics Same observation for ON-OFF flows Throughput (Mbps) Time (s)

37. TRUMP: A Few Paths Suffice Throughput (Mbps) Time (s) Sources benefit the most with a few alternative paths

38. Summary of TRUMP Properties

39. Related Work • Multiple decompositions (PalomarChiang06) • Design traffic-management protocols: • Congestion control (FAST TCP) • Dynamic traffic engineering (REPLEX, TeXCP) • Traffic management (KeyMassoulieTowsley07, LinShroff06, Shakkottai et al 06, Voice07)

40. Contributions • Design process • Formulated new objective for traffic management • Compared four distributed algorithms (from decomposition) • Constructed TRUMP based on insights • TRUMP • Universal parameter setting • Packet-level protocol and simulations

41. PART THREE DaVinci: Dynamically Adaptive Virtual Networks for a Customized Internet Joint work with Rui Zhang-Shen, Ying Li, Mike Lee, Martin Suchara, and Umar Javed

42. Internet Has Many Applications • Different application requirements • Throughput-sensitive: file transfer, web • Delay-sensitive: VoIP, IPTV, online gaming

43. Support Multiple Traffic Classes • Key research areas: • QoS: provides separate resources to support multiple traffic classes in parallel • Overlays: provide customized protocols for each traffic class • Network virtualization is emerging • Current applications: router consolidation, experimental test beds, VPNs • Router virtualization: separate resources • Programmable routers: customized protocols

44. Virtual Networks Each virtual node/link has isolated resources

45. Motivation for Virtualization • Two traffic classes: • Delay-sensitive traffic (DST): fixed demand • Throughput-sensitive traffic (TST): elastic • Single queue • TST can fill up both links • DST may not be satisfied • Shared routing • DST chooses shorter path • Capacity wasted 5ms, 100 Mbps 2 1 10ms, 1000 Mbps

46. Adaptive Network Virtualization • How to partition resources? • Static partitioning • Simple, but can be inefficient • One virtual network could be congested while another is idle Dynamically allocate bandwidth shares!

47. Dynamically Adaptive Virtual Networks for a Customized Internet • DaVinci is an architecture to realize adaptive network virtualization • Virtual networks indexed by (k) • One per traffic class • Run customized traffic-management protocols • Substrate network • Provides separate queues • Computes per link bandwidth shares • Enforce bandwidth shares with traffic shapers

48. DaVinci: Substrate Link s l(1) Congestion price computation Bandwidth shares computation link load yl(1) yl(2) yl(N) Use optimization to determine the computations

49. ISP: Maximize Aggregate Performance weighted aggregate performance objective max. ∑kw(k)U(k)(z(k), y(k)) s.t.∑k H(k)z(k)≤ c var.z(k) , y(k) pathrates bandwidth shares  users + efficiently using resources = $$$

50. Primal Decomposition • ISP problem decomposes into multiple subproblems (per traffic class): • Master problem update y(k) using • Indication of congestion s(k) • Indication of performance d/dy(k) U(k)(z(k), y(k)) max. U(k)(z(k), y(k)) s.t.H(k)z(k)≤ y(k) var. z(k)