Review: Resilient Overlay Networks

Paper: Resilient Overlay Networks

Name: Robert Danek.
Course: CS2209, Fall '06.

    The purpose of this paper is to discuss Resilient Overlay Networks
(RONs). A RON consists of a subset of nodes in a larger network, and
each of those nodes has an application-level protocol for communicating
with the other nodes in the RON. The protocol ensures that high-speed
recovery of path failures, low-latency, and improved loss rate and
throughput exist among the nodes participating in the RON.

    The motivation for having a RON arises from the desire to improve on
the poor performance of the underlying Internet routing protocols, such
as the Border Gateway Protocol (BGP). BGP can take upwards of tens of
minutes for a consistent view of the network topology to be established
after routing failures occur. This could lead to delays in packets being
delivered, and a higher frequency of packet loss. It is also possible
that when a routing failure occurs, BGP won't be able to reestablish a
new route for the packet to travel. RONs, on the other hand, take tens
of seconds to repair network paths, and in certain cases they can also
find routes for packets to travel even when the underlying BGP protocol
cannot. Not only are RONs quick to find alternate routes when routing
failures occur, but it's also possible that delivering packets along
certain routes take an unacceptable amount of time; a RON can detect
this condition and route the packet through a better path.

    Two other design goals for RON that the authors discuss is that of
having tighter integration with applications and having expressive
policy routing. The requirement of tighter integration with applications
arises from the observation that different applications can tolerate
different types and amounts of failure; an application should be able to
select the performance metrics that are important to it. The need for
expressive policy routing arises from the observation that one can
define only coarse-grained policies with BGP. Given that RON nodes are
expected to be running on powerful end-points, they are better suited
for providing fine-grained policy routing.

    Each node in the RON consists of a number of different components.
These components include: a conduit, a forwarder, a router, and a
probing mechanism. The conduit is the API that clients participating in
the RON make use of, and it consists of a send call for transmitting
packets to other RON nodes, and a recv (receive) callback for when
packets arrive. The forwarder is used in conjunction with the router for
determining the next node to which a packet should be sent. Quality of
the different paths in the RON is monitored via the probing mechanism,
which sends packets out periodically to measure the virtual links
between RON nodes based on a number of different metrics.

    The authors evaluated their design on two different RON instances,
which they dubbed RON_1 and RON_2. RON_1 consisted of 12 nodes, and
RON_2 consisted of 16 nodes. The authors point out that their
"experiments and results are not typical or representative of anything
other than their deployment." Having said that, though, they then go on
to demonstrate that their design goals are achieved fairly well in RON_1
and RON_2. They also demonstrate that in the face of routing failures or
performance degradation, forwarding packets through one intermediate RON
node is sufficient for fixing or improving a path.

    Overall this was a decent paper. There are some drawbacks to RONs
that the authors acknowledge, including the problem of Network Address
Translators (NATs), and the possibility of violating underlying BGP
policies. The latter problem the authors argue can be handled by
administrative means, since RONs are designed to be not much larger than
50 nodes. The former problem with NATs is a little trickier, but the
authors also suggest means for reducing its impact.
Received on Mon Oct 16 2006 - 12:18:41 EDT