1 / 40

Rethinking Internet Traffic Management From Multiple Decompositions to a Practical Protocol

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. Why Study Traffic Management?. important. Traffic management is important

burian
Download Presentation

Rethinking Internet Traffic Management From Multiple Decompositions to a Practical Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Why Study Traffic Management? important • Traffic management is important • Determines traffic rates and divides resources • Integrates routing, congestion control, traffic engineering, … • The architecture has shortcomings • Suboptimal interactions of components shortcomings • Motivated by recent advancements in optimization theory research

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

  4. Shortcomings of Today’s Architecture 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 What would a clean-slate redesign look like?

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

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

  8. Traffic Engineering ExplicitlyMinimizes Network Congestion Links are indexed byl 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 is a penalty for approaching capacity

  9. A Balanced Objective max. ∑i Ui(xi) - w∑l f(ul) Penalty weight Network users: Maximize throughput Generate bottlenecks Network operators: Minimize delay Avoid bottlenecks

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

  11. Convex Problems are Easier to Solve • Convex problems have a global minimum • Distributed solutions that converge to global minima can be derived using decompositions Non-convex Convex

  12. How to Make our Problem 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 11 isource-destination pair,jpath number z11 1 5 10 6 6 4 z21 9 9 2 8 3 z31 7 Path rate captures source rates and routing

  13. 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 rates z Rate limit incoming traffic

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

  16. Key Principles II: Consistency Price and Subgradient Updates • Consistency price pl • Relax constraint yl≤ clbut penalize violation with price pl • Allow packet loss to converge faster • Subgradient feedback price update: • Stepsize controls the granularity of reaction • Stepsizeis a tunable parameter pl(t+1) = [pl(t) – stepsize*(cl – yl (t))]+

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

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

  19. 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 ofwon convergence • Compare rate of convergence • Compare sensitivityof parameters

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

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

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

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

  24. TRUMP: TRaffic-managementUsingMultipathProtocol • 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

  25. TRUMP Algorithm Linkl: losspl(t+1) = [pl(t) + stepsize*(link load -cl)]+ queuingdelayql(t+1) = wf’(ul) Price forpath j = ∑ l on path j(pl+ql) Sourcei: Path rate zji(t+1) = max. (Ui(∑kzki) – zji *path price)

  26. TRUMP Versus Other Algorithms • TRUMP is not another decomposition • We can prove convergence, but onlyunder more restrictive conditions • From MATLAB: • Faster rate of convergence • Easyto tune parameter

  27. Top-down Redesign Problem Formulation Optimization decomposition Distributed Solutions Compare using simulations TRUMP Algorithm Translate into packet version TRUMP Protocol So far, assumed fluid model, constant feedback delay, greedy traffic sources

  28. TRUMP: Packet-based Version Linkl: link load = (bytes in period T) / (clT) Update link prices every T Arrivals and departures of flows are reflected in price changes Sourcei:Updatepath rates at maxj {RTTji}

  29. Packet-level Experiments in NS-2 • Set-up: • Synthetic topologies + realistic topologies and delays of large ISPs • Multiple paths with 1ms to 400ms of delay • Realistic ON-OFF traffic model • Questions: • Do MATLAB results still hold? • Does TRUMP react quickly to link dynamics? Can it handle ON-OFF flows? • Number of paths needed?

  30. TRUMP Versus Partial Dual in Sprint TRUMP Partial dual Aggregate throughput stabilizes for a range of w’s No stepsize allows satisfactory convergence TRUMP trumps partial dual for w ≤ 1/3

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

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

  33. TRUMP: A Few Paths Suffice Diminishing returns when providing more than 2 paths Worse for smaller files but still faster than TCP Sources benefit the most when they learn a few paths

  34. Summary of TRUMP Properties

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

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

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

  39. Thank You!

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

More Related