OverlayFriendly Native Network: A Contradiction in Terms?
21
OverlayFriendly Native Network: A Contradiction in Terms? HOTNETS IV Srinivasan Seetharaman Mostafa Ammar College of Computing Georgia Institute of Technology
description
OverlayFriendly Native Network: A Contradiction in Terms?. HOTNETS IV Srinivasan Seetharaman Mostafa Ammar College of Computing Georgia Institute of Technology. Overlay-Friendly Native Network (OFNN). A native network that caters to the overlay applications - PowerPoint PPT Presentation
Transcript of OverlayFriendly Native Network: A Contradiction in Terms?
OverlayFriendlyNativeNetwork:
AContradictioninTerms?
HOTNETS IV
Srinivasan SeetharamanMostafa Ammar
College of ComputingGeorgia Institute of Technology
HOTNETS IV
Overlay-Friendly Native Network (OFNN)
A native network that caters to the overlay applicationswithout compromising on the performance of the non-overlay applications.
“Non-overlay” refers to anything other than the current overlay we are aiding
HOTNETS IV
Network VirtualizationAddressing the impasse in progress of the Internet:
Purist – “overlay functionality will eventually be deployed in the native layer”OFNN–“needforoverlaysareinevitable,withsomealterationofthenativenetwork”Pluralist – “overlay applications should become a fundamental part of the native network”
HOTNETS IV
Constructing OFNNs
We make the distinction between:Functions (Eg: Token bucket policing)Parameters (Eg: burst size, token rate)
Native layer operation = Functions(Parameters)
Function
Parameter
HOTNETS IV
Different Approaches for OFNN
Provide overlay function
Add/Modify
function
HOTNETS IV
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.
HOTNETS IV
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.
HOTNETS IV
Different Approaches for OFNN (contd.)
Provide overlay functionTune
parameter
Add/Modify
function
HOTNETS IV
Classification of OFNNs
Function alteration / reprogramming
Invasive
Parameter tweaking / tuning
Non-invasive
Contradictory OFNN Non-Contradictory OFNN
HOTNETS IV
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
HOTNETS IV
Example1: Application Layer Multicast (ALM)
Extra copies on two different links
AD
CB
HOTNETS IV
Reduce extra copies on some linksNo extra copies on each linkLatency to reach C is less
ALM-Friendly Native Network
D
B
New packet replication capability
C
A
Similar in spirit to REUNITE, Packet reflection
HOTNETS IV
Packet Replication, A Contradiction?
The previous alteration begs question – “Why not put capability in all routers?”
Who needs Application level multicast? Contradictory OFNN
HOTNETS IV
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.
Multi-layer Dynamic Routing (contd.)Hello-intervals: Native = 5 secs
Failure detection time: Native = 3 x 5 secsHello-intervals: Native = 5 secs / Overlay = 3 secsFailure detection time: Native = 3 x 5 secs / Overlay = 3 x 3 secs
Overlay will detect first
A
D
CB
HOTNETS IV
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 detectionwhile maintaining same or better:
Overall protocol overhead Effective failure detection time
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!
AD
CB
HOTNETS IV
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.
HOTNETS IV
Actually, Overlays are Not Normal Apps
1. Highly distributed, network wide2. Provide service to the end-user3. Contain heavy functionality overlap
Open Question:”How does this change the nature of the native network tuning required?”
HOTNETS IV
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
HOTNETS IV
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
