Published on

Published in: Technology
  • 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
  • Why do we use ALM?
  • Describe MDR
  • Horde of problems from instability to suboptimality
  • Chicken and egg problem
  • Overlay performance is bounded
  • PPT

    1. 1. Overlay­Friendly Native Network: A Contradiction in Terms? HOTNETS IV Srinivasan Seetharaman Mostafa Ammar College of Computing Georgia Institute of Technology
    2. 2. Overlay-Friendly Native Network (OFNN) <ul><li>A native network that </li></ul><ul><li>caters to the overlay applications </li></ul><ul><li>without compromising on the performance of the non-overlay applications. </li></ul><ul><li>“Non-overlay” refers to anything other than the current overlay we are aiding </li></ul>
    3. 3. Network Virtualization <ul><li>Addressing the impasse in progress of the Internet: </li></ul><ul><li>Purist – “overlay functionality will eventually be deployed in the native layer” </li></ul><ul><li>OFNN – “need for overlays are inevitable, with some alteration of the native network” </li></ul><ul><li>Pluralist – “overlay applications should become a fundamental part of the native network” </li></ul>
    4. 4. Constructing OFNNs <ul><li>We make the distinction between: </li></ul><ul><li>Functions (Eg: Token bucket policing) </li></ul><ul><li>Parameters (Eg: burst size, token rate) </li></ul><ul><li>Native layer operation = Functions(Parameters) </li></ul>Function Parameter
    5. 5. Different Approaches for OFNN Provide overlay function Add/Modify function
    6. 6. Approaches represent a Contradiction <ul><li>Overlay networks were conceived to </li></ul><ul><li>obtain new network functionality </li></ul><ul><li>without modification of the underlying native network. </li></ul><ul><li>If it were feasible to modify the native network, the need for the overlay application is obviated. </li></ul>
    7. 7. Fundamental Reasons for Contradiction <ul><li>Overlay service is unable to provide the best performance autonomously </li></ul><ul><ul><li>Limited in number </li></ul></ul><ul><ul><li>Mostly located at the edge of the network </li></ul></ul><ul><ul><li>Users of the native network services. </li></ul></ul>
    8. 8. Different Approaches for OFNN (contd.) Provide overlay function Tune parameter Add/Modify function
    9. 9. Classification of OFNNs Function alteration / reprogramming Invasive Parameter tweaking / tuning Non-invasive Contradictory OFNN Non-Contradictory OFNN
    10. 10. Two Examples of OFNN <ul><li>Adding packet replication functionality to native routers for aiding application-layer multicast </li></ul><ul><ul><li> Contradictory OFNN </li></ul></ul><ul><li>Tuning the routing protocol hello-interval of native routers for earlier failure detection </li></ul><ul><ul><li>  Non-Contradictory OFNN </li></ul></ul>
    11. 11. Example1: Application Layer Multicast (ALM) <ul><li>Extra copies on two different links </li></ul>A D C B
    12. 12. <ul><li>Reduce extra copies on some links </li></ul>ALM-Friendly Native Network <ul><li>No extra copies on each link </li></ul><ul><li>Latency to reach C is less </li></ul>D B New packet replication capability C A Similar in spirit to REUNITE, Packet reflection
    13. 13. Packet Replication, A Contradiction? <ul><li>The previous alteration begs question – “Why not put capability in all routers?” </li></ul><ul><li> Who needs Application level multicast? </li></ul><ul><li> Contradictory OFNN </li></ul>
    14. 14. Example2: Multi-layer Dynamic Routing (MDR) <ul><li>In the native layer and the overlay layer, we assume: </li></ul><ul><li>Independent dynamic link state routing protocol </li></ul><ul><ul><li>Needed in overlay to restore application faults </li></ul></ul><ul><ul><li>Needed in native layer to prevent overlay partitioning </li></ul></ul><ul><li>Hello protocol for link status verification, which declares failure after loss of 3 consecutive hello packets. </li></ul>
    15. 15. Multi-layer Dynamic Routing (contd.) <ul><li>Hello-intervals: Native = 5 secs </li></ul><ul><li>Failure detection time: Native = 3 x 5 secs </li></ul><ul><li>Hello-intervals: Native = 5 secs / Overlay = 3 secs </li></ul><ul><li>Failure detection time: Native = 3 x 5 secs / Overlay = 3 x 3 secs </li></ul><ul><li> Overlay will detect first </li></ul>A D C B
    16. 16. MDR–Friendly Native Network <ul><li>From our work (details in INFOCOM 06), we concluded that if the overlay layer detects failures first, this can cause: </li></ul><ul><ul><ul><li>Large number of route oscillations </li></ul></ul></ul><ul><ul><ul><li>More false positives </li></ul></ul></ul><ul><ul><ul><li>Sub-optimal alternate paths. </li></ul></ul></ul><ul><li>Can we tune the native layer hello- interval to enforce earlier detection </li></ul><ul><li>while maintaining same or better: </li></ul><ul><ul><li>Overall protocol overhead </li></ul></ul><ul><ul><li>Effective failure detection time </li></ul></ul>
    17. 17. MDR–Friendly Native Network (contd.) <ul><li>Hello-intervals: Native = 3 secs / Overlay = 6 secs </li></ul><ul><li>Native detects failure first </li></ul><ul><li>Effective detection time = Min (3 x 3s, 3 x 6s) </li></ul><ul><li>= Same as before! </li></ul><ul><li>Overall protocol overhead = (Native  ) + (Overlay  ) </li></ul><ul><li>= Same as before! </li></ul>A D C B
    18. 18. Tuning, a Contradiction? <ul><li>Of course not! </li></ul><ul><ul><li>Overlays are yet another set of applications. </li></ul></ul><ul><ul><li>Network operators and managers have always tuned and tweaked the “native networks” in order to improve the performance of their user’s applications. </li></ul></ul>
    19. 19. Actually, Overlays are Not Normal Apps <ul><li>Highly distributed, network wide </li></ul><ul><li>Provide service to the end-user </li></ul><ul><li>Contain heavy functionality overlap </li></ul><ul><li>Open Question :”How does this change the nature of the native network tuning required?” </li></ul>
    20. 20. Future Work.. <ul><li>Determine what modifications can be incorporated in the native layer to help the overlay services. </li></ul><ul><li>Design overlay services under the assumption that the native layer is willing to cooperate. </li></ul><ul><li>Develop ways to prevent a misuse by the overlay layer. </li></ul><ul><li>Design a multi-layer testbed for OFNNs </li></ul>
    21. 21. Concluding Remarks <ul><li>OFNNs are needed to improve overlay performance </li></ul><ul><li>Some approaches to building OFNNs represent a contradiction </li></ul><ul><li>Parameter tuning is a viable and useful Non-contradictory approach </li></ul><ul><li>Contradictory-OFNN approaches may have some merit if overlays dominate </li></ul>