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
Why do we use ALM? 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.
Describe MDR

15. Multi-layer Dynamic Routing (contd.)
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
Hello-intervals: Native = 5 secs
Failure detection time: Native = 3 x 5 secs 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. 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) A D C B

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?”
Horde of problems from instability to suboptimality

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
Chicken and egg problem

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
Overlay performance is bounded