thesis proposal Meeyoung Cha Resilient Design Architecture


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Single-source single-destination VoIP, online gaming
  • Shortest path routing
  • Multicast application
  • thesis proposal Meeyoung Cha Resilient Design Architecture

    1. 1. thesis proposal Meeyoung Cha Resilient Design Architecture for Realtime Network Services
    2. 2. <ul><li>Goal Analytic foundation and resilient design architecture for realtime network services </li></ul><ul><li>Outline Challenges for realtime services </li></ul><ul><li>Point-to-point network services </li></ul><ul><li>Point-to-multipoint network services </li></ul><ul><li>Summary and future work </li></ul>Overview
    3. 3. Part 1: Challenges for realtime services
    4. 4. <ul><li>Motivation </li></ul><ul><li>Failures are frequent and routing protocols converge not fast enough for realtime network services. </li></ul><ul><li>How to provide resiliency against temporary outages? Exploit path diversity! </li></ul>What’s the problem?
    5. 5. Exploiting Path Diversity Destination Multiple disjoint paths ISP Network Using multiple disjoint paths gives maximum robustness against single point of failures! Source
    6. 6. Scope of Work Intra-domain Algorithms Modeling Application ISP backbone network Point-to-point Point-to-multipoint Heuristic, optimal Identify new problems, practical considerations
    7. 7. Part 2: Point-to-point Network Services
    8. 8. <ul><li>How to find multiple disjoint paths? </li></ul><ul><li>Use a node inside the network to relay packets </li></ul><ul><li>Problem is: Where to place relay nodes and how many? </li></ul>Idea: Placing Relays overlay path Destination default path relays ISP Network Origin
    9. 9. <ul><li>Idea: use disjoint overlay paths along with the default routing path to route around temporary failures. </li></ul><ul><li>Previous work has focused on selecting good relay nodes assuming relay nodes are already deployed. </li></ul><ul><ul><li>E.g., RON [Anderson SOSP 01], Detour [Savage Micro 99] </li></ul></ul><ul><li>As an ISP, we consider the problem of placing relay nodes well. </li></ul><ul><ul><li>Find a fixed set of relay nodes that offer as much path diversity as possible to all OD pairs. </li></ul></ul>Problem Definition
    10. 10. <ul><li>Equal Cost Multi Paths (ECMP) </li></ul><ul><li>Completely disjoint paths not possible due to ECMP. </li></ul>Impact of ECMP on Overlay Path Selection Intra-PoP AR AR BR BR BR BR AR AR Inter-PoP (Access router) (Backbone router)
    11. 11. Partially Disjoint Overlay Path We allow partially disjoint overlay paths. Overlap decreases resiliency. Introduce penalty to quantify the quality degradation. o d r default path overlay path
    12. 12. Penalty for Overlapped Links <ul><li>Impact of a single link failure on a path </li></ul><ul><li>- prob. a packet routed encounters a link failure </li></ul><ul><li> P[ path o  d fails | link l fails ] </li></ul>0.5 0.5 0.25 0.25 0.5 0.75 0.125 0.125 0.875 0.125 1.0 o d
    13. 13. <ul><li>Penalty –fraction of traffic carried on “overlapped” link </li></ul>Penalty Measures <ul><li>Penalty of a relay r for OD pair (o,d) </li></ul><ul><li> P o , d (r) = P[ both o  r  d and o  d fail | single link failure ] </li></ul><ul><li>Penalty of a relay set R of size k </li></ul><ul><ul><li>sum of minimum penalty of all OD pairs using relays ∑ o,d min( P o , d ( r ) | r ∈ R ) </li></ul></ul>o d r
    14. 14. <ul><li>Goal: find a relay set R of size k with minimum penalty </li></ul><ul><li>Optimal solution </li></ul><ul><ul><li>exhaustive search, 0-1 integer programming (IP) </li></ul></ul><ul><li>Greedy selection heuristic </li></ul><ul><ul><li>start with 0 relays </li></ul></ul><ul><ul><li>iteratively make greedy choice (minimal penalty) </li></ul></ul><ul><ul><li>repeat until k relays are selected </li></ul></ul><ul><li>Local search heuristic </li></ul><ul><ul><li>start with k random relays </li></ul></ul><ul><ul><li>repeat single-swaps if penalty is reduced </li></ul></ul>Placement Algorithms
    15. 15. <ul><li>Performance evaluation </li></ul><ul><ul><li>Number of relays vs. penalty reduction </li></ul></ul><ul><ul><li>Comparison with other heuristics (random, degree) </li></ul></ul><ul><li>Sensitivity to network dynamics </li></ul><ul><ul><li>Based on topology snapshot data, do relays selected remain effective as topology changes? </li></ul></ul><ul><ul><li>Based on network event logs, what is the fraction of traffic protected from failures by using relays? </li></ul></ul>Evaluation Overview
    16. 16. <ul><li>We use an operational tier-1 ISP backbone and </li></ul><ul><li>3-month topology snapshots and 6-month event logs. </li></ul><ul><ul><li>Topology - 100 routers, 200 links </li></ul></ul><ul><ul><li>Assume hypothetical traffic matrix </li></ul></ul><ul><ul><li>- equal amount of traffic between OD pairs </li></ul></ul><ul><li>Also evaluated with 1 real, 3 inferred, 6 synthetic topologies. </li></ul>Dataset
    17. 17. Sensitivity to Network Dynamics Relays are relatively insensitive to network dynamics. 5% of nodes are selected as relays 10% of nodes are selected as relays
    18. 18. Hypothetical Traffic Loss from Failure Event Logs complete protection for 75.3% failures less than 1% of traffic lost for 92.8% failures (failure events)
    19. 19. <ul><li>This is the first work to consider relay placement for path diversity in intra-domain routing. </li></ul><ul><li>We quantify the penalty of using partially disjoint overlay paths; and propose two heuristics for relay placement. </li></ul><ul><li>We evaluate our methods on diverse dataset. </li></ul><ul><ul><li>Our heuristics perform consistently well (near-optimal). </li></ul></ul><ul><ul><li>A small number of relay nodes ( ≤ 10%) is good enough. </li></ul></ul><ul><ul><li>Relays are relatively insensitive to network dynamics. </li></ul></ul><ul><ul><li>Proven also effective against real (multiple) failures. </li></ul></ul>Summary
    20. 20. <ul><li>Publications Meeyoung Cha, Sue Moon, Chong-Dae Park, Aman Shaikh </li></ul><ul><li>“ Placing Relay Nodes for Intra-domain Path Diversity” </li></ul><ul><li>Proc. IEEE INFOCOM poster, Mar 2005 Proc. IEEE INFOCOM conference paper, Apr 2006 </li></ul><ul><li>Talks IEEE INFOCOM 2005, 2006 DIMACS mixer series, Sep 2005 Princeton systems group lunch talk, Dec 2005 </li></ul><ul><li>Action items In preparation of a journal version </li></ul><ul><li>Extended idea to inter-domain setting Meeyoung Cha, Aman Shaikh, Sharad Agarwal, Sue Moon </li></ul><ul><li>“ On AS Level Path Diversity”, submitted to IMC 06 </li></ul>Accomplishments
    21. 21. Part 3: Point-to-multipoint Network Services
    22. 22. <ul><li>IPTV (Internet Protocol TV) distribution of broadcast TV traffic using IP technology </li></ul><ul><li>Growing need for efficient and resilient IPTV design </li></ul><ul><ul><li>4 million IPTV subscribers in 2005 [1] </li></ul></ul><ul><li>What is the best architecture for supporting IPTV? </li></ul><ul><ul><li>technology (IP, optical) </li></ul></ul><ul><ul><li>hierarchy (hub-and-spoke, meshed) </li></ul></ul><ul><ul><li>multicast routing (cost) </li></ul></ul><ul><ul><li>failure restoration (high availability) </li></ul></ul>Motivation [1]
    23. 23. SHE Regional Network Video Hub Office (VHO) 2 SHEs and 40 VHOs across the US customers Regional Network Backbone Distribution Network Super Head Ends (SHE) VHO VHO Service Architecture of IPTV Broadcast TV Regional Network How to design backbone part of IPTV services (e.g., inter-connecting SHEs and VHOs)?
    24. 24. Service Requirements of IPTV <ul><li>Cost-effective design </li></ul><ul><ul><li>Each link associated with port / transport cost </li></ul></ul><ul><ul><li>Find minimum cost multicast trees </li></ul></ul><ul><li>Reliable service </li></ul><ul><ul><li>High availability </li></ul></ul><ul><ul><li>Resiliency against single node or link failures </li></ul></ul><ul><ul><li>Two physically disjoint paths from SHEs to VHOs </li></ul></ul><ul><ul><li>(Multilayer problem) </li></ul></ul>
    25. 25. SRLG (Shared Risk Link Group) <ul><li>Layered architecture </li></ul><ul><li>Single link failure -> multiple failures in the upper layer </li></ul><ul><li>Two disjoint links may belong to a common SRLG </li></ul>
    26. 26. Path Protection Routing How to create two trees such that the total cost is minimized and each VHO has physically disjoint paths connecting SHEs? <ul><li>1+1 protection: resources dedicated, data simultaneously sent on two paths (guarding against each other) </li></ul>SHE SHE VHO VHO VHO SRLG-diverse paths VHO
    27. 27. Link-diverse versus SRLG-diverse D1 and D3 may be disconnected due to a single fiber cut.
    28. 28. Problem Definition <ul><li>Problem </li></ul><ul><li>Given sources S and destinations D , inter-connect S and D such that each destination is connected to at least one of the sources under any single source, link, and SRLG failures. </li></ul>s d i j =1, if link (i,j) is used from s to d =1, if link (i,j) is ever used by s =1, if SRLG b is used from s to d b
    29. 29. Minimize total cost SRLG diversity Flow conservation Integer Programming (IP) Formulation
    30. 30. Evaluation Setup <ul><li>IP modeling </li></ul><ul><ul><li>GAMS tool </li></ul></ul><ul><ul><li>ILOG CPLEX IP solver </li></ul></ul><ul><li>Dataset 2 SHE / 40 VHO locations in the US </li></ul><ul><li>IP formulation amenable to realistic topologies! </li></ul>
    31. 31. Compared Designs <ul><li>Optimal versus heuristic </li></ul><ul><ul><li>Active Path First (APF) heuristic </li></ul></ul><ul><ul><ul><li>Find multicast tree from one SHE </li></ul></ul></ul><ul><ul><ul><li>Remove all the SRLGs used in the first tree </li></ul></ul></ul><ul><ul><ul><li>Find second multicast tree from remaining SHE </li></ul></ul></ul><ul><li>Reduced reliability </li></ul><ul><ul><li>Link diverse (Link-Div) </li></ul></ul><ul><ul><ul><li>Find link diverse paths connecting 2 SHEs 40 VHOs </li></ul></ul></ul><ul><ul><li>Source diverse (Src-Div) </li></ul></ul><ul><ul><ul><li>Find two multicast trees </li></ul></ul></ul>
    32. 32. <ul><ul><ul><li>More economical than heuristic. </li></ul></ul></ul><ul><ul><ul><li>Cost for increased reliability affordable. </li></ul></ul></ul>Cost Comparison Across Designs Most reliable Most Reliable cost Reduced reliability Reduced reliability
    33. 33. Summary <ul><li>The first work to consider IPTV backbone design. </li></ul><ul><li>1+1 path protection routing problem modeled. </li></ul><ul><li>Compact Integer Programming formulation proposed. </li></ul><ul><li>IP formulation evaluated using realistic topologies. </li></ul><ul><ul><li>Real topologies amenable to our method </li></ul></ul><ul><ul><li>Cost gain against heuristics </li></ul></ul><ul><ul><li>SRLG diversity shown affordable </li></ul></ul>
    34. 34. <ul><li>Publications Meeyoung Cha, Gagan Choudhury, Jennifer yates, Aman Shaikh, Sue Moon, “Case Study: Resilient Backbone Design for IPTV Services” </li></ul><ul><li>Proc. WWW IPTV workshop, May 2006 </li></ul><ul><li>Meeyoung Cha, W. Art Chaovalitwongse, Zihui Ge, Jennifer Yates, Sue Moon, “Path Protection Routing with SRLG Constraints to Support IPTV in WDM Mesh Networks”, Proc. IEEE Global Internet Symposium, Apr 2006 </li></ul><ul><li>Talks AT&T research labs, Feb 2006 IEEE Global Internet, Apr 2006 WWW IPTV workshop, May 2006 </li></ul><ul><li>Action items </li></ul><ul><li>In preparation of a journal version </li></ul><ul><li>Incorporate practical considerations and develop new algorithms </li></ul>Accomplishments
    35. 35. Part 4: Summary and Future Work
    36. 36. <ul><li>Point-to-point communication </li></ul><ul><ul><li>VoIP, online-gaming, VPN applications </li></ul></ul><ul><ul><li>Disjoint overlay paths for robustness </li></ul></ul><ul><ul><li>Relay placement algorithms </li></ul></ul><ul><ul><li>Extensive analyses </li></ul></ul><ul><li>Point-to-multipoint communication </li></ul><ul><ul><li>IPTV application </li></ul></ul><ul><ul><li>Shared Risk Link Group (SRLG) consideration </li></ul></ul><ul><ul><li>New Integer Programming (IP) model </li></ul></ul><ul><ul><li>Extensive analyses </li></ul></ul>Summary: Resilient Design Architecture What I have done:
    37. 37. <ul><li>Relay architecture </li></ul><ul><ul><li>Implementation issues </li></ul></ul><ul><ul><ul><li>Protocol design </li></ul></ul></ul><ul><ul><ul><li>Router support </li></ul></ul></ul><ul><ul><ul><li>Billing issues </li></ul></ul></ul><ul><li>Relay placement in inter-domain setting </li></ul><ul><ul><li>Border Gateway Protocol (BGP) path </li></ul></ul><ul><ul><ul><li>Inference </li></ul></ul></ul><ul><ul><ul><li>Asymmetries </li></ul></ul></ul><ul><li>Lower layer path diversity </li></ul><ul><ul><li>Incorporate Shared Risk Link Group (SRLG) </li></ul></ul>Future Work: Point-to-point What I am going to do:
    38. 38. <ul><li>Network design: source placement </li></ul><ul><ul><li>Given fixed destinations, where to place sources? </li></ul></ul><ul><ul><li>New IP formulation, new algorithms,… </li></ul></ul><ul><li>Guaranteed path performance </li></ul><ul><ul><li>Can we guarantee latency bounds on paths? </li></ul></ul><ul><li>Plasticity and scalability </li></ul><ul><ul><li>Adding more sources and destinations </li></ul></ul>Future Work: Point-to-multipoint What I am going to do:
    39. 39. <ul><li>Dynamic change of service requirements </li></ul><ul><ul><li>Change of topology, demand, service expansions </li></ul></ul><ul><ul><li>How to incorporate changes? </li></ul></ul><ul><li>Optimal solutions may be too expensive or infeasible </li></ul><ul><li>What are good heuristics? </li></ul><ul><ul><li>Fast convergence, easy to parallelize </li></ul></ul>Real-world Service Considerations sub-optimal from here Example of immediate work:
    40. 40. <ul><li>Step1: Pool of feasible solutions Use fast heuristic with random parameters </li></ul><ul><li>Step2: Sort solutions (1 st generation) Use cost functions to evaluate solutions </li></ul>Improvement of Existing Algorithm 1 Genetic Algorithm (GA) based heuristic: Feasible solutions S1 S2 Sn … Best (20%) S1 S2 Sn … Mid (75%) Worst (5%)
    41. 41. <ul><li>Step3: Mutate parameters Mix best with mid or worst </li></ul><ul><li>Step4: Sort solutions (2 st generation) </li></ul><ul><li>Step5: Repeat steps 3 and 4 Until no improvement found </li></ul>Best (20%) Mid (75%) Worst (5%) S1 S2 Sn … Sn’ S1’ new feasible solutions mutate parameters Improvement of Existing Algorithm 2 Genetic Algorithm (GA) based heuristic: Best (20%) Mid (75%) Worst (5%) S1’ S3’ Sn’ … S2
    42. 42. Thank you very much!