1 / 27

An Approach to Alleviate Link Overload as Observed on an IP Backbone

An Approach to Alleviate Link Overload as Observed on an IP Backbone. Tuesday, April 1 st Infocom 2003. Sundar Iyer 1,2 , Supratik Bhattacharrya 2 , Nina Taft 2 , Christophe Diot 2 1 Stanford University, 2 ATL SprintLabs. Contents. Introduction Pathology of link overload

caine
Télécharger la présentation

An Approach to Alleviate Link Overload as Observed on an IP Backbone

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. An Approach to Alleviate Link Overload as Observed on an IP Backbone Tuesday, April 1st Infocom 2003 Sundar Iyer1,2, Supratik Bhattacharrya2, Nina Taft2, Christophe Diot2 1Stanford University, 2ATL SprintLabs

  2. Contents • Introduction • Pathology of link overload • Alleviate overload - deflection routing • Performance analysis

  3. There should be no link overload • Overload: More than 50% utilization • IP backbones are • Overprovisioned  low average utilization • Have multiple paths • Routing algorithms • balance load across multiple shortest paths • should reduce the likelihood of overload

  4. But there is link overload • Shortest path routing • puts load on a small set of equal cost shortest paths • causes unequal use of link capacity • Unpredictable traffic • Short term load fluctuations e.g. hotspots • Failure • Link failures, fiber cuts, network maintenance • Hard to predict all factors apriori

  5. Why bother about link overload? • Operators upgrade persistently overloaded links • Peaks in link utilization  cannot increase average utilization • Severe link overload causes packet drops • Interactive, real-time applications make it mandatory to overcome overload

  6. Contents • Introduction • Pathology of link overload • Alleviate overload - deflection routing • Performance analysis

  7. Methodology • Measurement of data from the Sprint backbone • Analyzed 138 backbone links for 9 months • SNMP link utilization data polled every 5 minutes • The link utilization is an exponentially weighted moving average (EWMA) • Measurements under-estimate overload • Short term fluctuations are missed

  8. Maximum load Maximum Load • Observation 1: There is always some overloaded link

  9. Contribution of links to overload Non-Overloaded links Overloaded links • Observation 2: Most of the links are not overloaded

  10. Observation 3: Two types — Persistent and temporary overload Types of link overload Periods of link overload • Observation 4: Often just 1-2 links are simultaneously overloaded

  11. Causes of temporary link overload Link Utilizations • Observation 5: Link failures cause temporary overload • Observation 6: Fiber cuts cause severe overload

  12. Contents • Introduction • Pathology of link overload • Alleviate overload - deflection routing • Performance analysis

  13. Allow normal network operation most of the time The case for deflection routing • Previous techniques • useful for long term overload • change normal functioning of the network • useful when overload is common • We observe that link overload • is relatively rare (0.1% of the time on any link) • are typically caused due to link failures/maintenance • lasts for minutes-hours on average • occurs on maximum of 1-2 links simultaneously • can be easily overcome by deflecting packets

  14. Problem • Problem: • How can we design a simple, stateless, loop-free deflection algorithm to overcome link overload? • Theorem 1: (sufficiency) • Any deflection algorithm which deflects packets with “strictly decreasing cost” is loop-free

  15. Explanation of Theorem 1 • A packet is forwarded from node s to d according to the strictly decreasing cost criteria as follows • If shortest path not overloaded Forward the packet on the shortest path with cost C • If link to neighboring node n is not overloaded Forward the packet to n if n’s cost to d is  C • Else Forward the packet on the shortest path

  16. Yes No • Loop-free deflection routing: • we do not consider the cost of reaching the deflection node Intuition for Theorem 1 20 15 30 Router: n1 10 10 Router: s Router: d Router: n2 20 25 Router: n3 • Shortest path routing: • forward packet on the shortest path • the sequence of costs to a destination is strictly decreasing

  17. Problem • Problem: • Can we always find loop-free deflection paths according to the strictly decreasing cost criteria? • Theorem 2: (sufficiency) • A network with redundant equal length paths always has a loop-free deflection path if the link weights are in a ratio 1 + 1/(d-1), where d is the diameter of the network

  18. Requirements • Intuition: • All link weights are in the range [Wmin ,Wminx] • the minimum cost of the shortest path is dWmin • the maximum cost of the deflection path is (d-1)Wminx • (d-1)Wminx  dWmin  x  1 + 1/(d-1) • Criteria for Theorem 2 • Need equal length shortest paths between any two nodes • Weights need to be within a bounded ratio “1 + 1/(d-1)” • The diameter d of the network should be small

  19. ANA-1 SJ-1 NYC-1 CHI-1 RTP-1 FW-1 CHI-4 ANA-4 NYC-4 RTP-4 SJ-4 FW-4 SJ-2 RTP-2 NYC-2 CHI-2 FW-2 ANA-2 ANA-3 RTP-3 CHI-3 NYC-3 SJ-3 FW-3 Topology ConsiderationsInter-PoP Network PoP New York PoP San Jose PoP Chicago Small diameter, d=3 Redundant equal length paths are guaranteed PoP Anaheim PoP RTP PoP Fort-Worth Large inter-POP weights are within ratio

  20. Perfect Mesh in PoPs SJ-1 NYC-1 RTP-1 FW-1 NYC-4 RTP-4 SJ-4 FW-4 SJ-2 NYC-2 RTP-2 FW-2 Redundant equal length paths not guaranteed RTP-3 FW-3 NYC-3 SJ-3 Small (wmax) Intra-POP Weights Topology ConsiderationsComplete Network CHI-1 CHI-2 CHI-4 CHI-3 Diameter is larger ANA-1 ANA-2 ANA-4 ANA-3 Large Inter-POP Weights

  21. Problem • Inter-PoP Network: PoPs as a single ‘logical node’ + All criteria for theorem 2 are satisfied • The complete network - Equal length redundant paths does not exist - Diameter of the network is not small - Maximum intra-PoP link weight wmax is unrelated and very small compared to inter-PoP link weights • Problem - Cannot satisfy theorem 2 for the complete network

  22. Inter- PoP Intra- PoP Practical deflection routing algorithmSolution: Clumping a PoP • A packet is forwarded from node s to d as follows, where wgain = wmax • If shortest path not overloaded Forward the packet on the shortest path (with cost C) • If link to neighboring node n is not overloaded Forward the packet to n if n’s cost to d is C –wgain • Else if link to (intra-PoP) node n’ is not overloaded Forward the packet if its cost to d is  C +wmax • Forward the packet on the shortest path

  23. Theorem 3 • Theorem 3: • The practical deflection routing algorithm has no inter-PoP loops • Comments • The sequence of costs strictly decreases across PoPs • This is in keeping with the idea of ‘PoPs’ • Link failures • The algorithm is extended by setting wgain = (n-1)wmax

  24. Contents • Introduction • Pathology of link overload • Alleviate overload - deflection routing • Performance analysis

  25. Simulations • Simulation parameters • 14 node inter-PoP network and 4-5 node intra-PoP network • Estimated traffic matrix with gravity models & link measurements • Deflection threshold was set to 45% • Deflection based on fast EWMA • Simulations for link failures and fiber cuts

  26. Link overload due to a fiber cut • Deflection routing decreases the maximum load amongst all links in the backbone

  27. Conclusions • Deflection routing algorithm • Based on practical considerations and overload pathology • Exploits backbone architecture, meshed topology • Mandates a condition on weights which is not too restrictive • Is loop-free across PoPs • Note • Needs a redundant backbone network with equal-length paths • Useful when average utilization is low • Future Work • Stability needs to be investigated

More Related