Overlay

1
OverlayFriendly Native NetworkA 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
MDRFriendly 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
MDRFriendly 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 users
  applications.

19
Actually, Overlays are Not Normal Apps

• Highly distributed, network wide
• Provide service to the end-user
• Contain heavy functionality overlap
• Open QuestionHow 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