The Case for Resilient Overlay Networks

Authors: David G. Andersen, Hari Balakrishnan, M. Frans Kaashoek, Robert Morrise

Complete Citation

• Andersen, David G., Balakrishnan, Hari, Kaashoek, M. Frans, Morrise, Robert. 2001. Proc. of the 8th Annual Workshop on Hot Topics in Operating Systems (HotOS? -VIII), May 2001

Abstract

In this paper, we motivate and describe the architecture of Resilient Overlay Networks (RON), an application-level packet forwarding service that gives end-hosts and applications the ability to take advantage of network paths that traditional Internet routing \emph{cannot} make use of, thereby improving their end-to-end reliability and performance. A RON system consists of a per-host forwarding and routing system; programs to measure the quality of paths between participating hosts; and mechanisms for interpreting this measured data and making routing decisions based upon that interpretation. RONs are usable as a purely user-level library system, with kernel support for packet encapsulation, or as a router to overlay entire leaf networks. We explain the reasons for the architectural design of RON, and argue that end-host controlled Resilient Overlay Networks provide a good framework for distributed applications to transmit data with greater robustness and higher performance over the wide-area Internet.

Annotations

* Purpose: RON provides intelligent application-layer network switching, making decisions based on performance over links between nodes. It reroutes traffic amonst its nodes based on collected information.

* This paper covers many aspects of RON, and of key interest are its reasons for development, and methods of operation. Standard internet routing via BGP is highly scalable, but it does not react quickly. Also, it generally uses a hop-count method of determining optimal routing, as more indepth calculations would be inefficient. Additionally, some routes are not advertised, and thus of limited availability to most internet users. RON circumvents these problems by quickly routing packets around any failed links, while BGP would take minutes to respond. RON also detects and reroutes traffic differently then BGP would when its analysis find a superiour route. Also, if one RON node is privy to knowledge of a non-advertised route that would be advantageous for other nodes, it is able to share this route's specifics, effectively increasing the pool of viable routes for other nodes in the system. Once it determines that rerouting should occur, RON packages packets in a RON wrapper and passes them node-to-node to their destination via the new route.

* My interest in RON is primarily in its ability to reroute packets as it desires. Although the testbed I am developing does not make decisions about routing like RON does, it will be routing packets manually.

* Conclusion: RON's objectives, while beyond the scope of my work, are accomplished by means similar to those I am pursuing, making it worthy of study.

-- DavidMoore - 1 August 2007