Overlay­Friendly Native Network: A Contradiction in Terms?

1. Overlay­Friendly Native Network:A Contradiction in Terms? HOTNETS IV Srinivasan Seetharaman Mostafa Ammar College of Computing Georgia Institute of Technology

2. Overlay-Friendly Native Network (OFNN) A native network that • caters to the overlay applications • without compromising on the performance of the non-overlay applications. “Non-overlay” refers to anything other than the current overlay we are aiding

3. Network Virtualization Addressing the impasse in progress of the Internet: • Purist – “overlay functionality will eventually be deployed in the native layer” • OFNN – “need for overlays are inevitable, with some alteration of the native network” • Pluralist – “overlay applications should become a fundamental part of the native network”

4. Constructing OFNNs We make the distinction between: • Functions (Eg: Token bucket policing) • Parameters (Eg: burst size, token rate) Native layer operation = Functions(Parameters) Parameter Function

5. Different Approaches for OFNN Provide overlay function Add/Modify function

6. Approaches represent a Contradiction Overlay networks were conceived to • obtain new network functionality • without modification of the underlying native network. If it were feasible to modify the native network, the need for the overlay application is obviated.

7. Fundamental Reasons for Contradiction Overlay service is unable to provide the best performance autonomously • Limited in number • Mostly located at the edge of the network • Users of the native network services.

8. Different Approaches for OFNN (contd.) Provide overlay function Tune parameter Add/Modify function

9. Classification of OFNNs Function alteration / reprogramming Parameter tweaking / tuning Invasive Non-invasive Contradictory OFNN Non-Contradictory OFNN

10. Two Examples of OFNN • Adding packet replication functionality to native routers for aiding application-layer multicast  Contradictory OFNN • Tuning the routing protocol hello-interval of native routers for earlier failure detection  Non-Contradictory OFNN

11. Example1: Application Layer Multicast (ALM) • Extra copies on two different links A D C B

12. ALM-Friendly Native Network • Reduce extra copies on some links • No extra copies on each link • Latency to reach C is less A D New packet replication capability Similar in spirit to REUNITE, Packet reflection C B

13. Packet Replication, A Contradiction? The previous alteration begs question – “Why not put capability in all routers?”  Who needs Application level multicast?  Contradictory OFNN

14. Example2: Multi-layer Dynamic Routing (MDR) In the native layer and the overlay layer, we assume: • Independent dynamic link state routing protocol • Needed in overlay to restore application faults • Needed in native layer to prevent overlay partitioning • Hello protocol for link status verification, which declares failure after loss of 3 consecutive hello packets.

15. Multi-layer Dynamic Routing (contd.) • Hello-intervals: Native = 5 secs • Failure detection time: Native = 3 x 5 secs • Hello-intervals: Native = 5 secs / Overlay = 3 secs • Failure detection time: Native = 3 x 5 secs / Overlay = 3 x 3 secs  Overlay will detect first A D C B

16. MDR–Friendly Native Network From our work (details in INFOCOM 06), we concluded that if the overlay layer detects failures first, this can cause: • Large number of route oscillations • More false positives • Sub-optimal alternate paths. Can we tune the native layer hello-interval to enforce earlier detection while maintaining same or better: • Overall protocol overhead • Effective failure detection time

17. A D C B MDR–Friendly Native Network (contd.) • Hello-intervals: Native = 3 secs / Overlay = 6 secs • Native detects failure first • Effective detection time = Min (3 x 3s, 3 x 6s) = Same as before! • Overall protocol overhead = (Native) + (Overlay) = Same as before!

18. Tuning, a Contradiction? Of course not! • Overlays are yet another set of applications. • Network operators and managers have always tuned and tweaked the “native networks” in order to improve the performance of their user’s applications.

19. Actually, Overlays are Not Normal Apps • Highly distributed, network wide • Provide service to the end-user • Contain heavy functionality overlap Open Question:”How does this change the nature of the native network tuning required?”

20. Future Work.. • Determine what modifications can be incorporated in the native layer to help the overlay services. • Design overlay services under the assumption that the native layer is willing to cooperate. • Develop ways to prevent a misuse by the overlay layer. • Design a multi-layer testbed for OFNNs

21. Concluding Remarks • OFNNs are needed to improve overlay performance • Some approaches to building OFNNs represent a contradiction • Parameter tuning is a viable and useful Non-contradictory approach • Contradictory-OFNN approaches may have some merit if overlays dominate