walking the tightrope responsive yet stable traffic
play

Walking the tightrope : Responsive yet stable Traffic Engineering - PowerPoint PPT Presentation

Walking the tightrope : Responsive yet stable Traffic Engineering Presented by Aparna Sundar Problem Definition and current solutions TE problem definition Offline Methods OSPF-TE , MPLS Online Methods MATE, TeXCP Inadequecy of


  1. Walking the tightrope : Responsive yet stable Traffic Engineering Presented by Aparna Sundar

  2. Problem Definition and current solutions TE problem definition Offline Methods – OSPF-TE , MPLS Online Methods – MATE, TeXCP

  3. Inadequecy of Offline methods ● Cannot react to real-time traffic reroutes. ● Load distribution not guarenteed to be optimal. ● Suboptimal reaction to failure.

  4. Online methods ● Should react to real-time traffic demands and failures. ● Prior approaches – centralized, assuming a global oracle, lacking stability analysis. Eg MATE. ● TeXCP – distributed and stable.

  5. Summary of Results ● For same traffic demands, TeXCP supports same utilisation and failure resiliance with a third of the capacity as traditional offline methods. ● Network utilization is always within a few percentage points of optimal value. ● Prefers shorter routes while trimming long routes that are not useful.

  6. Big Picture ● Two Components ● Load Balancer : multiple paths delivering demands from ingress to egress router, moving traffic from over-utilized to under utilized paths. ● Closed loop Feed Back controller: collects network feedback at faster time scale than LB to ensure traffic stability.

  7. Diagram, Explanation of terms

  8. LP Formulation at each IE pair

  9. Path Selection,Probing Network state ● Path Selection: ● ISP picks set of K shortest paths that it can use. ● Probing Network state: ● Maintain probe timer, Tp, to maintain track of path utilization. Tp > RTT. ● Probe packet with updatable utilization field sent by ingress node. Egress node sends it back to app agent. ● Probe loss: estimate util to max(1,p u_sp)

  10. Load Balancer ● Each agent maintains a decision timer, which fires every Td sec, > 5Tp. ● each time the agent,computes change in fraction of IE traffic sent on path p. ● At eqbm, x_sp is constant, traffic is conserved, no negative traffic possible,updates should decrease max utilization.

  11. Load Balancer (contd) ● ● ● Intuition:path whose util is greater than avg shd dec its rate while path whose util isbelow avg should increase its rate. ● Change in traffic is proportional to current traffic on path (which is prop to util). ● Use of epsilon – to re-use or restart util on a path.

  12. Preventing Oscillations , Managing Congestion ● Two agents working independantly may shift flow to link that was previously under-utilized. ● Solution (inspired by XCP) ● Compute aggregate feedback: ● Compute per IE flow feedback based on a Max- Min approach: ● ● Positive feedback added, negative multiplied.

  13. Preventing Oscillations , Managing Congestion(contd) ● Sending feedback to agents using probe. ● g_sp is allowed rate on path p. ● Actual rate = min(g_sp, x_sp R_s). ● Prefer to use shorter paths: Use weighted max-min fairness to push a preference for shorter paths. ● Heuristic : Shorter paths better for better network utilisations

  14. Analysis ● Computation of explicit feedback for each pair, by load balancer, that leads to more stable per- IE flow rates and subsequently utilizations. ● Effect of feedback on network, “mostly” done by the time load balancer kicks into action ie,the explicit feedback brings path util to 90% of desired value, before the next time any of the load balancers need to make a decision.

  15. Results and Comparision

  16. Results and comparision (contd)

  17. Discussion ● Look at source-dest paths, instead of ingress- egress paths? ● Metric for network utilization ● ● Including estimate for egress-ingress links?

Recommend


More recommend