Summary

From: Kiran Gollu <kirank.gollu_at_gmail.com>
Date: Tue, 17 Oct 2006 08:15:12 -0400

A Resilient Overlay Network (RON) is an architecture that allows distributed
Internet applications to detect and recover from path outages and periods of
degraded performance within several seconds. The motivation comes from the
fact that routing protocols such as BGP take several minutes to recover from
path outages and periods of degraded performance.

The three design goals of RON are:
1. Fast Failure detection and recovery in (< 20 seconds). RON is able to
detect problems quickly by using active probing and passive observations of
ongoing transfers to determine key metrics such as latency, packet loss
rate, and available throughput

2. Tighter integration of routing and path selection with the application
because poor conditions for one application may be acceptable by another. It
also assumes that application will be able to select the performance metrics
that are important to it.

3. Expressive policy routing that govern the choice of paths in the network.
It is possible to choose a path based on latency, loss and throughput.

Each node in the RON consists of a number of four components: a conduit, a
forwarder, a router, and a probing mechanism. The conduit is an API which
can be used by nodes participating in RON. It provides send and recv calls
for RON nodes. The forwarder is used in conjunction with the router for
determining the next node to which a packet should be sent.

To evaluate the performance over the internet, a RON was deployed on the
internet, implemented as a resilient IP forwarder. RON was able to route
around between 60% and 100% of all significant outages. The suggested
implementation in the paper takes 18 sec to recover from badly performing
internet paths. Additionally, the paper explains why one-intermediate-hop
strategy is effective as compared to general alternatives.

The paper further shows that how design goals are achieved in RON1 and RON2.
The paper finally discusses some problems such as scalability issues. The
authors also discuss about the problems caused by nodes behind firewall and
NAT but also suggest ways to reduce the effect.

-- 
~Kiran
Received on Tue Oct 17 2006 - 08:22:26 EDT

This archive was generated by hypermail 2.2.0 : Tue Oct 17 2006 - 08:22:31 EDT