Resilient overlay networks

David G. AndersenHari BalakrishnanM. KaashoekRobert Morris

article2001SOSP2,299 citations

Demonstrates that an application-layer overlay network can detect Internet path outages and reroute traffic in under twenty seconds using at most one intermediate node, overcoming slow BGP convergence to substantially reduce packet loss and latency.

Listen

Today's wide-area Internet routing infrastructure relies heavily on the Border Gateway Protocol (BGP-4), which is designed to scale across millions of networks by summarizing routing paths and dampening rapid updates. While this design ensures global scalability, it sacrifices fast fault tolerance; standard wide-area routing frequently takes several minutes to tens of minutes to converge after an outage, and it cannot dynamically circumvent severe performance bottlenecks or packet-flooding attacks. Consequently, critical distributed applications frequently suffer from prolonged connection drops and severe service degradation.

The article sets out to design, implement, and evaluate the Resilient Overlay Network (RON), an application-layer routing architecture that moves path control to end systems. Its goal is to demonstrate that cooperating nodes can detect and recover from wide-area Internet outages and performance failures within seconds while tailoring routing to application-specific metrics.

To evaluate this architecture, the authors deployed working testbeds across universities, commercial companies, broadband home connections, and Internet Service Providers. They analyzed two primary datasets: RON1 (12 nodes, 132 paths measured over 64 hours in March 2001) and RON2 (16 nodes, 240 paths measured over 85 hours in May 2001), supplemented by controlled flood-recovery tests on an emulation testbed. Each node used active probing and passive monitoring to track path quality—including latency, packet loss, and throughput—and routed traffic through intermediate overlay nodes when the direct Internet path faltered. Strict routing policies were enforced to ensure commercial traffic did not traverse non-commercial educational backbones.

The evaluation produced five critical findings. First, RON detected and recovered from 100% of significant outages in RON1 (where direct loss exceeded 30%) and 60% in RON2, averaging an 18-second recovery time compared to minutes for standard Internet routing. Second, the architecture remained resilient against active denial-of-service packet floods, rerouting traffic in approximately 13 seconds. Third, RON improved end-to-end performance during non-outage periods: about 5% of transfers doubled their TCP throughput, and 5% reduced their packet loss rate by at least 0.05. Fourth, latency improved by 40 milliseconds or more in 8% to 11% of measured samples. Fifth, single-hop indirect routing (routing through at most one intermediate overlay node) was sufficient to capture almost all failure recoveries and 98% of latency improvements.

These findings indicate that end-to-end reliability and responsiveness can be substantially enhanced without altering the core Internet routing infrastructure. For enterprise VPNs, collaborative conferencing, and overlay service providers, RON reduces the business and operational risks of unpredictable downtime and performance degradation. Furthermore, different applications benefit from choosing paths based on customized priorities—such as prioritizing low latency over high throughput—rather than relying on a one-size-fits-all network path.

Organizations operating critical distributed applications should consider adopting overlay routing techniques or piloting single-hop overlay forwarders between key data centers and branch locations. Developers must incorporate application-specific metrics and utilize moderate routing hysteresis (around 5% to 10%) to prevent rapid route flapping. Before deploying at scale, operators must also establish administrative trust boundaries and access controls, as open forwarding requires cooperation among participating hosts.

The main limitations of this architecture involve scalability and measurement assumptions. Because active probing overhead scales quadratically with network size, the presented RON design is intended for small cooperating groups of 2 to 50 nodes, consuming roughly 30 Kbps of background bandwidth at the upper limit. Additionally, the prototype estimated one-way loss using two-way probing, which occasionally degraded performance across highly asymmetric links, and complete site disconnections cannot be overcome. Overall, there is high confidence that small-scale overlay routing reliably overcomes transient Internet path failures.

Massachusetts Institute of Technology network architecture p2p overlays Ron Path Routing

Andersen et al (2001).pdf

No sufficiently relevant recommendations were found.

Abstract

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, improving over today’s wide-area routing protocols that take at least several minutes to recover. A RON is an application-layer overlay on top of the existing Internet routing substrate. The RON nodes monitor the functioning and quality of the Internet paths among themselves, and use this information to decide whether to route packets directly over the Internet or by way of other RON nodes, optimizing application-specific routing metrics.

Results from two sets of measurements of a working RON deployed at sites scattered across the Internet demonstrate the benefits of our architecture. For instance, over a 64-hour sampling period in March 2001 across a twelve-node RON, there were 32 significant outages, each lasting over thirty minutes, over the 132 measured paths. RON’s routing mechanism was able to detect, recover, and route around all of them, in less than twenty seconds on average, showing that its methods for fault detection and recovery work well at discovering alternate paths in the Internet. Furthermore, RON was able to improve the loss rate, latency, or throughput perceived by data transfers; for example, about 5% of the transfers doubled their TCP throughput and 5% of our transfers saw their loss probability reduced by 0.05. We found that forwarding packets via at most one intermediate RON node is sufficient to overcome faults and improve performance in most cases. These improvements, particularly in the area of fault detection and recovery, demonstrate the benefits of moving some of the control over routing into the hands of end-systems.

Topics

network architecture p2p overlays

Keywords

Ron Path Routing Internet Loss Packet Node Paths Loss Rate Nodes

1. Introduction
2. Related Work
2.1 Internet Performance Studies
2.2 Network-layer Techniques
2.3 Overlay-based Techniques
3. Design Goals
3.1 Fast Failure Detection and Recovery
3.2 Tighter Integration with Applications
3.3 Expressive Policy Routing
4. Design
4.1 Software Architecture
4.2 Routing and Path Selection
4.2.1 Link-State Dissemination
4.2.2 Path Evaluation and Selection
4.2.3 Performance Database
4.3 Policy Routing
4.4 Data Forwarding
4.5 Bootstrap and Membership Management
5. Implementation
5.1 The IP Forwarder
5.2 Routers
5.3 Monitoring Virtual Links
6. Evaluation
6.1 Methodology
6.2 Overcoming Path Outages
6.2.1 Overhead and Outage Detection Time
6.2.2 Handling Packet Floods
6.3 Overcoming Performance Failures
6.3.1 Loss Rate
6.3.3 TCP Throughput
6.4 RON Routing Behavior
6.4.1 RON Path Lengths
6.4.2 RON Route Stability
6.4.3 Application-specific Path Selection
7. Discussion
8. Conclusion
Acknowledgments
References

Knowls

Knowl 1 — Resilient Overlay Network Architecture and Packet Forwarding Mechanism
model/method
A Resilient Overlay Network (RON) is an application-layer overlay network comprising a small confederation of nodes (between 2 and 50 nodes) situated in diverse routing domains across the Internet. RON nodes monitor the quality of the virtual links between each other and cooperatively forward traffic to circumvent wide-area Internet path outages and performance failures within seconds, bypassing the multi-minute convergence delays of the Border Gateway Protocol (BGP-4).

The software architecture consists of user-level components linked to distributed applications via a conduit API:
1. Conduit Interface: Provides send(pkt, dst, via_ron) to forward packets directly or via the overlay, and a callback recv(pkt, via_ron) that demultiplexes incoming packets to registered client applications based on a packet type identifier.
2. Entry, Intermediate, and Exit Nodes: When a packet enters the RON at an entry node, the input conduit classifies it, attaches a policy tag and a flow ID, encapsulates it in a custom RON header, and determines the initial path from its routing table. Intermediate RON forwarders perform lookups using the packet's destination address, policy tag, and flow ID, forwarding packets over UDP without reclassifying them. The exit node decapsulates the packet and passes it to the receiving client conduit.
3. Decoupled Architecture: Packet classification and policy evaluation are restricted to entry and exit conduits, ensuring intermediate overlay forwarding remains independent of application-specific logic.
Knowl 2 — Single-Hop Indirection Routing Table Generation Algorithm
algorithm
RON nodes compute forwarding tables tailored to specific policies and optimization metrics. The table generation algorithm evaluates direct paths and single-hop indirect paths through every possible intermediate overlay peer, selecting the next-hop node that maximizes a specified evaluation score while satisfying routing policies.
Input: Set of routing policies POLICIES, set of optimization metrics METRICS, set of overlay nodes PEERS, local node me
Output: Multi-level forwarding table table[P][M][Dest] mapping policy P, metric M, and destination Dest to the next hop node
for each P in POLICIES do
    for each M in METRICS do
        for each Dest in PEERS do
            best_score = -\infty
            next_hop = Dest
            for each Hop in PEERS do
                if P.permits(me, Hop) and P.permits(Hop, Dest) then
                    sc = M.eval(me, Hop, Dest)
                    if sc > best_score then
                        best_score = sc
                        next_hop = Hop
            table[P][M][Dest] = next_hop
The algorithm checks whether a policy $P$ permits both virtual links ( $(me, Hop)$ and $(Hop, Dest)$ ) via $P.\text{permits}$ . If permitted, the candidate path is evaluated using the metric scoring function $M.\text{eval}$ . The computational complexity per node is $O(|\text{POLICIES}| \cdot |\text{METRICS}| \cdot N^2)$ , where $N = |\text{PEERS}|$ . Forwarding table entries are updated periodically based on disseminated link-state metrics.
Knowl 3 — Path Quality Evaluation Metrics in Resilient Overlay Networks
model/method
RON routers evaluate virtual links and composite paths using three primary performance metrics:
1. Latency Minimization: Link latency $lat_l$ is estimated using an Exponential Weighted Moving Average (EWMA) with weighting parameter $\alpha = 0.9$ :
$lat_l \leftarrow \alpha \cdot lat_l + (1 - \alpha) \cdot new\_sample_l$

Total path latency for a path composed of virtual links is the additive sum:

$lat_{path} = \sum_{l \in path} lat_l$
1. Loss Rate Minimization: Virtual link loss rates are estimated as the unweighted mean of the last $k = 100$ probe samples. Under the assumption of independent link losses, the composite path loss rate is multiplicative:
$lossrate_{path} = 1 - \prod_{l \in path} (1 - lossrate_l)$
1. TCP Throughput Optimization: Throughput is scored using an upper-bound TCP throughput model combining path round-trip time ( $rtt$ ) and one-way packet loss probability ( $p$ ):
$score = \frac{\sqrt{1.5}}{rtt \cdot \sqrt{p}}$

To prevent infinite scores and mitigate routing oscillations from isolated probe losses, the loss probability is bounded below by a minimum floor of $p \ge 0.02$ (2%).
Knowl 4 — Active Probing and Outage Detection Protocol
model/method
RON monitors the reachability, round-trip time (RTT), and loss rate of all $N-1$ virtual links from each node using active UDP probe packets (69 bytes each) containing a random 64-bit ID.
1. Three-Packet Measurement Exchange: Node A sends an initial probe to Node B. Node B replies with Response 1 and resets its own probe timer for Node A. Node A sends Response 2 back to Node B upon receipt. This 3-packet exchange provides both nodes with reachability and RTT samples without requiring synchronized system clocks.
2. Probing Intervals and Jitter: Probes are scheduled at a baseline interval $PROBE\_INTERVAL = 12\,\text{s}$ with a random uniform jitter of up to $\frac{1}{3} PROBE\_INTERVAL$ , yielding an average inter-probe time of $\frac{7}{6} PROBE\_INTERVAL = 14\,\text{s}$ . The probe loss timeout is $PROBE\_TIMEOUT = 3\,\text{s}$ .
3. Outage Triggering: If a probe is lost, the normal low-frequency schedule is suspended and up to 3 consecutive probe packets are transmitted in rapid succession spaced by $PROBE\_TIMEOUT$ . If 4 consecutive probes fail to elicit a response, the virtual link is declared dead. This detects link failure in a minimum of $4 \times PROBE\_TIMEOUT = 12\,\text{s}$ , a maximum of $PROBE\_INTERVAL + \frac{1}{3} PROBE\_INTERVAL + 4 \times PROBE\_TIMEOUT = 28\,\text{s}$ , and an average of $\frac{1}{2}\left(\frac{7}{6}\right)PROBE\_INTERVAL + 4 \times PROBE\_TIMEOUT = 19\,\text{s}$ .
Knowl 5 — Theoretical Sufficiency of Single-Hop Intermediate Overlay Routing
theoretical result
Consider an overlay network with a source node $s$ , a destination node $t$ , and $R$ other overlay nodes residing in independent Autonomous Systems. Let $p_s$ denote the probability that the lowest-latency path from $s$ to another overlay node is the direct Internet link, and let $p_i$ denote the probability that the lowest-latency path from intermediate node $i$ to $t$ is the direct Internet link.

Assuming independence of path selection across distinct Autonomous Systems, the probability that the optimal latency path between $s$ and $t$ is either the direct Internet path or an indirect path traversing at most one intermediate overlay node is given by:

$P = 1 - (1 - p_s) \prod_{i=1}^R (1 - p_s p_i)$

If $p_s \approx p_i \approx \frac{c}{\sqrt{R}}$ for a positive constant $c$ , the probability satisfies:

$P \ge 1 - (1 - p_s^2)^{R+1} = 1 - \left(1 - \frac{c^2}{R}\right)^{R+1} \approx 1 - e^{-c^2}$

For typical wide-area overlay deployments where $p_s, p_i \approx 0.5$ and $R \ge 10$ , this probability is close to 1. Consequently, forwarding packets through at most one intermediate overlay hop captures nearly all potential latency and reachability improvements over direct Internet paths, rendering paths with two or more intermediate hops largely unnecessary.
Knowl 6 — Empirical Fault Recovery and Outage Avoidance Performance
empirical result
A path outage is defined as an interval where the average packet loss rate over a time window $\tau = 1800\,\text{s}$ (30 minutes) satisfies $p \ge 30\%$ . RON's ability to detect and route around outages was evaluated across two wide-area testbed datasets:
1. RON1 Dataset (12 nodes, 132 paths, 64 hours, March 2001): Covering 6,825 path-hours across 36 Autonomous Systems and 74 inter-AS links. There were 32 thirty-minute sample intervals with loss rate $\ge 30\%$ , including 10 complete outages (100% loss). RON successfully detected and routed around 100% (32 out of 32) of these outage periods via alternate commercial Internet paths.
2. RON2 Dataset (16 nodes, 240 paths, 85 hours, May 2001): Covering 17,000 path-hours. Direct Internet paths experienced 56 path-hours of 100% loss and 1,314 path-hours of $\ge 30\%$ loss. RON routed around 60% of the 100% outage conditions and 53% of the $\ge 30\%$ loss conditions. The remaining ~40% of unrecoverable outages were caused by complete physical edge link failures isolating individual host sites from all peers.
Across both deployments, RON detected path failures and routed around them in an average of 18 seconds.
Knowl 7 — Empirical Performance Gains in Latency, Packet Loss, and TCP Throughput
empirical result
In wide-area deployment measurements comparing RON forwarding against direct Internet routing:
1. Packet Loss Reduction: In the RON1 deployment, RON reduced the end-to-end packet loss probability by at least 0.05 (5 percentage points in absolute loss rate) in 5% of all 30-minute averaged samples (and by 0.04 in 5% of samples in RON2).
2. Round-Trip Latency Reduction: Across 39,683 five-minute averaged round-trip time samples in RON1, 11% of the samples achieved latency reductions of 40 ms or greater when routed through an intermediate RON node rather than the direct Internet path (8.2% of samples in RON2 achieved $\ge 40\,\text{ms}$ improvements).
3. TCP Bulk Throughput Improvement: Across 2,035 paired 1 MB bulk transfers comparing RON throughput-optimized routes to direct paths, 5% of transfers doubled their TCP throughput (a ratio $\ge 2.0$ ), 2% improved by more than a factor of 5, and 9 samples improved by a factor of 10 during periods of degraded direct connectivity. Only 1% of transfers experienced a throughput reduction greater than 50% under RON.
Knowl 8 — Overlay Policy Routing and Acceptable Use Policy Enforcement
model/method
RON provides policy routing to restrict how traffic is forwarded across overlay links, separating policy enforcement into packet classification and routing table construction:
1. Exclusive Cliques: Restricts virtual links such that only traffic whose original source and final destination belong to the designated clique may traverse inter-clique links. This allows compliance with external Acceptable Use Policies (AUPs), such as prohibiting commercial Internet traffic from traversing the non-commercial Internet2 educational backbone.
2. General Policy Matchers: Accepts BSD Packet Filter (BPF) style rules matching arbitrary header fields and evaluates them against an explicit list of denied virtual links.
3. Pre-computed Routing Sub-tables: The router builds isolated forwarding tables for every policy by executing the shortest-path computation solely on links permitted by that policy. The entry conduit tags packets with a policy identifier, allowing intermediate forwarders to index directly into the appropriate sub-table without repeated classification.

Knowl 9 — Route Flapping Mitigation and Route Persistence via Hysteresis

data/table

To prevent route flapping between paths with nearly identical performance scores, RON applies a 5% hysteresis bonus to the currently active ("last good") route. Route stability was evaluated over a 16-hour trace of 5,616 link-state table snapshots representing 876,096 pairwise route instances sampled every 14 seconds.

Hysteresis Bonus	# Route Changes	Average Run	Median Run	Maximum Run
0%	26,205	19.3	3	4,607
5%	21,253	24.0	5	3,438
10%	9,436	49.0	10	4,607
25%	4,557	94.0	17	5,136
50%	2,446	138.0	25	4,703
Random process	260,000	2.0	1	<16

Run-length represents the number of consecutive 14-second sampling intervals over which a route remains unchanged. A 5% hysteresis threshold reduces route changes by ~19% compared to 0% hysteresis, yielding a median route persistence of 5 samples (70 seconds) while maintaining rapid responsiveness to genuine underlying network failures.

Knowl 10 — Soft-State Resilient Dynamic Membership Protocol
model/method
RON manages dynamic overlay group membership through an announcement-based soft-state flooding protocol designed to distinguish between transient path outages and permanent node departures:
1. Bootstrapping: A new node must know the IP address of at least one active peer in the overlay. Upon startup, it broadcasts its presence to the group using a flooder client that routes membership packets across the RON mesh.
2. Periodic State Flooding: Every node periodically (at an average interval of 5 minutes) broadcasts its full list of known active overlay peers to all other nodes.
3. Partition-Resistant Eviction: A node receives up to $N-1$ redundant copies of peer announcements during each broadcast round. A peer is evicted from local routing tables only after no announcements concerning that peer have been received from any overlay node for 60 minutes. This prevents direct path failures between two nodes from triggering false node departures as long as at least one indirect overlay path remains functional.
Knowl 11 — Scalability and Bandwidth Overhead Bounds in Full-Mesh Overlay Probing
limitation
Because each node in an $N$ -node RON actively probes and maintains link-state information for all $N-1$ virtual links, the total network overhead scales as $O(N^2)$ .
1. Probe Traffic Overhead: Each node receives probe traffic at a rate of:
$\text{Probe Traffic} = \frac{2 \cdot S \cdot (N - 1)}{\frac{7}{6} \cdot PROBE\_INTERVAL} \quad \text{bytes/s}$

where probe size $S = 69\,\text{bytes}$ and average inter-probe time is $\frac{7}{6} PROBE\_INTERVAL = 14\,\text{s}$ .
1. Routing Update Overhead: Link-state announcements consume:
$\text{Routing Traffic} = \frac{(N - 1)(H + P \cdot (N - 1))}{ROUTING\_INTERVAL} \quad \text{bytes/s}$

where header size $H = 60\,\text{bytes}$ , per-peer description $P = 20\,\text{bytes}$ , and $ROUTING\_INTERVAL = 14\,\text{s}$ .
1. Scaling Limits: For default parameters, per-node overhead is 2.2 Kbps at $N=10$ , 6.6 Kbps at $N=20$ , 13.32 Kbps at $N=30$ , 22.25 Kbps at $N=40$ , and 33.0 Kbps at $N=50$ . This $O(N^2)$ bandwidth overhead limits the practical size of a single fully-meshed RON to approximately 50 nodes.
Knowl 12 — Asymmetric Denial-of-Service Attack Mitigation via Overlay Rerouting
empirical result
In controlled emulation experiments on a 3-node triangular network (256 Kbps, 30 ms latency links) subject to an active unidirectional UDP packet flooding attack on the primary link:
1. Standard IP Failure: Unidirectional packet flooding severely congested the forward data link, reducing native TCP throughput to near zero. Because TCP acknowledgments trickled through on the reverse path and BGP sessions remained established, BGP did not declare the link down and failed to reroute traffic.
2. RON Recovery: The RON active prober detected packet loss on the forward path and rerouted TCP data packets through the third intermediate node within 13 seconds, restoring full TCP transfer rates.
3. Asymmetric Path Utilization: RON continued routing returning TCP acknowledgments directly over the uncongested reverse direct link, demonstrating that application-level overlay routing can exploit unidirectional link availability that standard BGP path-vector routing would discard.

Coverage note — All major contributions from the paper have been converted into knowls. Specific implementation details regarding FreeBSD divert socket internals, SPAND database schema specifics, and general NAT workarounds were omitted as subsidiary implementation details.

References

1.A\textsc{ndersen}, D. G. Resilient Overlay Networks. Master's thesis, Massachusetts Institute of Technology, May 2001.
2.B\textsc{alakrishnan}, H., S\textsc{eshan}, S., S\textsc{temm}, M., \textsc{and} K\textsc{atz}, R. Analyzing Stability in Wide-Area Network Performance. In \textit{Proc. ACM SIGMETRICS} (Seattle, WA, June 1997), pp. 2–12.
3.C\textsc{handra}, B., D\textsc{ahlin}, M., G\textsc{ao}, L., \textsc{and} N\textsc{ayate}, A. End-to-end WAN Service Availability. In \textit{Proc. 3rd USITS} (San Francisco, CA, 2001), pp. 97–108.
4.C\textsc{lark}, D. Policy Routing in Internet Protocols. Internet Engineering Task Force, May 1989. RFC 1102.
5.C\textsc{ollins}, A. The Detour Framework for Packet Rerouting. Master's thesis, University of Washington, Oct. 1998.
6.E\textsc{riksson}, H. Mbone: The Multicast Backbone. \textit{Communications of the ACM 37}, 8 (1994), 54–60.
7.F\textsc{loyd}, S., H\textsc{andley}, M., P\textsc{adhye}, J., \textsc{and} W\textsc{idmer}, J. Equation-Based Congestion Control for Unicast Applications. In \textit{Proc. ACM SIGCOMM} (Stockholm, Sweden, Sept. 2000), pp. 43–54.
8.G\textsc{oyal}, M., G\textsc{uerin}, R., \textsc{and} R\textsc{ajan}, R. Predicting TCP Throughput From Non-invasive Data. (Unpublished, http://www.seas.upenn.edu:8080/~guerin/publications/TCP_model.pdf).
9.G\textsc{uardini}, I., F\textsc{asano}, P., \textsc{and} G\textsc{irardi}, G. IPv6 Operational Experience within the 6bone. In \textit{Proc. Internet Society (INET) Conf.} (Yokohama, Japan, July 2000). http://www.isoc.org/inet2000/cdproceedings/1e/1e_1.htm.
10.H\textsc{agens}, R., H\textsc{all}, N., \textsc{and} R\textsc{ose}, M. Use of the Internet as a Subnetwork for Experimentation with the OSI Network Layer. Internet Engineering Task Force, Feb 1989. RFC 1070.
11.K\textsc{hanna}, A., \textsc{and} Z\textsc{inky}, J. The Revised ARPANET Routing Metric. In \textit{Proc. ACM SIGCOMM} (Austin, TX, Sept. 1989), pp. 45–56.
12.L\textsc{abovitz}, C., A\textsc{huja}, A., B\textsc{ose}, A., \textsc{and} J\textsc{ahanian}, F. Delayed Internet Routing Convergence. In \textit{Proc. ACM SIGCOMM} (Stockholm, Sweden, September 2000), pp. 175–187.
13.L\textsc{abovitz}, C., M\textsc{alan}, R., \textsc{and} J\textsc{ahanian}, F. Internet Routing Instability. \textit{IEEE/ACM Transactions on Networking 6}, 5 (1998), 515–526.
14.M\textsc{c}C\textsc{anne}, S., \textsc{and} J\textsc{acobson}, V. The BSD Packet Filter: A New Architecture for User-Level Packet Capture. In \textit{Proc. Winter '93 USENIX Conference} (San Diego, CA, Jan. 1993), pp. 259–269.
15.The North American Network Operators' Group mailing list archive. http://www.cctec.com/maillists/nanog/.
16.P\textsc{adhye}, J., F\textsc{iroiu}, V., T\textsc{owsley}, D., \textsc{and} K\textsc{urose}, J. Modeling TCP Throughput: A Simple Model and its Empirical Validation. In \textit{Proc. ACM SIGCOMM} (Vancouver, Canada, September 1998), pp. 303–323.
17.P\textsc{artridge}, C. Using the Flow Label Field in IPv6. Internet Engineering Task Force, 1995. RFC 1809.
18.P\textsc{axson}, V. End-to-End Routing Behavior in the Internet. In \textit{Proc. ACM SIGCOMM '96} (Stanford, CA, Aug. 1996), pp. 25–38.
19.P\textsc{axson}, V. End-to-End Internet Packet Dynamics. In \textit{Proc. ACM SIGCOMM} (Cannes, France, Sept. 1997), pp. 139–152.
20.P\textsc{ostel}, J. B. \textit{Transmission Control Protocol}. Internet Engineering Task Force, September 1981. RFC 793.
21.R\textsc{ekhter}, Y., \textsc{and} L\textsc{i}, T. \textit{A Border Gateway Protocol 4 (BGP-4)}. Internet Engineering Task Force, 1995. RFC 1771.
22.S\textsc{avage}, S., A\textsc{nderson}, T., \textsc{et al}. Detour: A Case for Informed Internet Routing and Transport. \textit{IEEE Micro 19}, 1 (Jan. 1999), 50–59.
23.S\textsc{avage}, S., C\textsc{ollins}, A., H\textsc{offman}, E., S\textsc{nell}, J., \textsc{and} A\textsc{nderson}, T. The End-to-End Effects of Internet Path Selection. In \textit{Proc. ACM SIGCOMM} (Boston, MA, 1999), pp. 289–299.
24.S\textsc{eshan}, S., S\textsc{temm}, M., \textsc{and} K\textsc{atz}, R. H. SPAND: Shared Passive Network Performance Discovery. In \textit{Proc. 1st USITS} (Monterey, CA, December 1997), pp. 135–146.
25.S\textsc{haikh}, A., K\textsc{alampoukas}, L., V\textsc{arma}, A., \textsc{and} D\textsc{ube}, R. Routing Stability in Congested Networks: Experimentation and Analysis. In \textit{Proc. ACM SIGCOMM} (Stockholm, Sweden, 2000), pp. 163–174.
26.T\textsc{ouch}, J., \textsc{and} H\textsc{otz}, S. The X-Bone. In \textit{Proc. 3rd Global Internet Mini-Conference} (Sydney, Australia, Nov. 1998), pp. 75–83.

Citation

MLA

Andersen, D., et al. “Resilient Overlay Networks”. ACM SIGOPS Operating Systems Review, vol. 35, no. 5, 2001, pp. 131–45, https://doi.org/10.1145/502059.502048.

APA

Andersen, D., Balakrishnan, H., Kaashoek, F., & Morris, R. (2001). Resilient overlay networks. ACM SIGOPS Operating Systems Review, 35(5), 131–145. https://doi.org/10.1145/502059.502048

Chicago

Andersen, D., H. Balakrishnan, F. Kaashoek, and R. Morris. 2001. “Resilient Overlay Networks”. ACM SIGOPS Operating Systems Review 35 (5): 131–45. https://doi.org/10.1145/502059.502048.

Harvard

Andersen, D. et al. (2001) “Resilient overlay networks”, ACM SIGOPS Operating Systems Review, 35(5), pp. 131–145. Available at: https://doi.org/10.1145/502059.502048.

Vancouver

1. Andersen D, Balakrishnan H, Kaashoek F, Morris R (2001) Resilient overlay networks. ACM SIGOPS Operating Systems Review 35:131–145

BibTeX

@article{Andersen_2001, title={Resilient overlay networks}, volume={35}, ISSN={0163-5980}, url={http://dx.doi.org/10.1145/502059.502048}, DOI={10.1145/502059.502048}, number={5}, journal={ACM SIGOPS Operating Systems Review}, publisher={Association for Computing Machinery (ACM)}, author={Andersen, David and Balakrishnan, Hari and Kaashoek, Frans and Morris, Robert}, year={2001}, month=Oct, pages={131–145} }

Metadata:Crossref

Access the Paper

This paper is available from its original source. Click below to access the PDF.

Open PDF

Resilient overlay networks

Abstract

Topics

Keywords

Table of Contents

Knowls

Knowl 1 — Resilient Overlay Network Architecture and Packet Forwarding Mechanism

Knowl 2 — Single-Hop Indirection Routing Table Generation Algorithm

Knowl 3 — Path Quality Evaluation Metrics in Resilient Overlay Networks

Knowl 4 — Active Probing and Outage Detection Protocol

Knowl 5 — Theoretical Sufficiency of Single-Hop Intermediate Overlay Routing

Knowl 6 — Empirical Fault Recovery and Outage Avoidance Performance

Knowl 7 — Empirical Performance Gains in Latency, Packet Loss, and TCP Throughput

Knowl 8 — Overlay Policy Routing and Acceptable Use Policy Enforcement

Knowl 9 — Route Flapping Mitigation and Route Persistence via Hysteresis

Knowl 10 — Soft-State Resilient Dynamic Membership Protocol

Knowl 11 — Scalability and Bandwidth Overhead Bounds in Full-Mesh Overlay Probing

Knowl 12 — Asymmetric Denial-of-Service Attack Mitigation via Overlay Rerouting

References

Citation

BibTeX

Access the Paper