1 / 23

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

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. Traffic Management Today. Operator: Traffic Engineering.

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

More Related