1. Resilient Overlay Networks David Anderson, Hari Balakrishnan, Frank Kaashoek and Robert Morris. MIT Laboratory for Computer Science http://nms.lcs.mit.edu/ron/ Rohit Kulkarni University of Southern California CSCI 558L : Fall 2004

2. Outline Introduction What is RON ? Design Goals RON design Evaluation Related Work Future Work Conclusion

3. Introduction Current organization of Internet Independently operating ASes peer together Detailed routing information only within an AS Shared routing information filtered using BGP BGP provides policy enforcement and scalability Problems with this organization Reduced fault-tolerance of e2e communication Fault recovery takes many minutes Vulnerable to router and link faults, configuration errors..

4. Introduction [2] : Other studies Studies highlighting problems “delayed routing convergence” - inter-domain routers take 10s of mins to reach a consistent view after a fault “e2e routing behavior” - routing faults prevent internet host from communicating up to 3.3% of time avg over long period “e2e WAN availability” - 5% of all detected failures last more than 10,000 secs (2 hrs 45mins) Studies trying to solve problems “Multi-homing” - addressing issues with active connections. Still no quick fault recovery “Detour” - path selection in internet sub-optimal w.r.t latency, loss-rate. throughput. Showed benefits of indirect routing No wide-area system that provides quick failure-recovery

5. What is RON ? Resilient - “to recover readily from adversity” Overlay Network - “an isolated virtual network deployed over an existing physical network” Figure taken from X-bone project [2]

6. What is RON ? [2] “RON is an architecture that allows distributed Internet applications to detect and recover from path outages and periods of degraded performance within several seconds” An application layer overlay on top of existing Internet RON nodes monitor Internet paths among themselves Functioning Quality Route packets directly over internet or using other RON nodes

7. Design Goals Goal 1: Fast failure detection and Recovery Detection by using aggressive probing Recovery by using intermediate RON nodes for forwarding Goal 2: Integrate routing & path selection w/ Applications application specific notions of failures application specific metric in path selection Goal 3: Framework for policy routing Fine-grained policies aimed at users or hosts E.g. e2e per-user rate control, forwarding rate controls based on packet classification.

8. RON Design: Software Architecture RON Client Conduit RON nodes: entry node, exit node Forwarder Router Membership manager Performance database

9. Design [2]: Routing and Path Selection Link-state propagation Link-state routing protocol Routing protocol is RON client with a packet type Path evaluation and selection Outage detection using active probing Routing metrics Latency-minimizer - uses EWMA of RT latency samples w/ parameter  (0.9) Loss-minimizer - uses avg of last k (100) probe samples. TCP throughput-optimizer - combines latency and loss rate metrics using simplified TCP throughput equation Performance database Detailed performance information

10. Design [3]: Policy routing Allows users to define types of traffic allowed on network links Classification Data classifier module Incoming (via conduit) packets get policy tag Tag identifies set of routing tables to be used Routing table formation Policy identifies which virtual links to use Separate set of routing tables for each policy

11. Design [4]: Data forwarding The forwarding control and data paths The RON packet header

12. Evaluation: Methodology wide-area RON deployed at several internet sites ISP, US Univs (I-2), Euro Univs, broadband home users,.coms Internet-2 (I-2) policy for more Internet like measurements Measurements using probe packets, throughput samples 2 datasets RON1 - 12 nodes, 132 paths 2.6m samples, 64hrs trace in March 2001, RON2 - 16 nodes, 240 paths 3.5m samples, 85hrs trace in May 2001, Time-averaged samples averaged over 30mins duration Most RON hosts were: Celeron/733, 256MB RAM, 9GB HDD, FreeBSD. No host was processing bottleneck

13. Evaluation [2]: Overcoming path outages Outage data for RON1 Outage data for RON2 Packet loss rate averaged over 30-min Intervals for direct Internet paths vs. RON paths for RON1

14. Evaluation [3]: Improving loss rates CDF of improvement in loss-rate achieved by RON1. Samples are averaged over 30 mins

15. Evaluation [4]: Improving latency 5-minute avg latencies over direct internet path and over RON, as CDF

16. Evaluation [5]: Improving throughput CDF of the ratio of throughput achieved via RON to that achieved directly via the Internet

17. Evaluation [6]: Route Stability Link-state routing table snapshots every 14 seconds. Total 5616 snapshots RON’s path selection algos on link-state trace This shows hysteresis is needed for route stability Number of path changes and run-lengths of routing persistence for different hysteresis values

18. Evaluation [7]: Major results RON was able to successfully detect and recover from 100% (in RON1) and 60% (in RON2) of all complete outages and all periods of sustained high loss rates of 30% or more. RON takes 18 seconds, on average, to route around a failure & can do so in face of flooding attack RON successfully routed around bad throughput failures, doubling TCP throughput in 5% of all samples. In 5% of the samples, RON reduced the loss probability by 0.05 or more Single-hop route indirection captured the majority of benefits in our RON deployment, for both outage recovery and latency optimization

19. Related Work X-Bone Generic framework for speedy deployment of IP-based overlay networks Management fns & mechanisms to insert packets into overlay No fault-tolerant operation - no outage detection No application controlled path selection Detour Showed benefits of indirect routing Kernel level system - not closely tied to application Focus not on quick failure-recovery for preventing disruptions No experimental results analysis from a real-world deployment

20. Future Work Preventing misuse of established RON Cryptographic authentication and access control Mechanisms to detect misbehaving RON peers Just at administrative level not enough Scalability/Wide spread deployment Keep size of RON within limits (50-100) Have co-existence of many RONs Their interactions Routing stability

21. Conclusion RON can greatly improve reliability of Internet packet delivery by detecting and recovering from outages and path failures more quickly (18 secs) than BGP-4 (several mins) Can overcome performance failures, improving loss- rates, latency, throughput. Forwarding packets via at most one intermediate RON node is sufficient Claims of RON confirmed from experiments Good platform for resilient distributed internet application development

22. References “Resilient Overlay Networks”, D. Andersen, H. Balakrishnan, M. Kaashoek, R. Morris, Proc. 18th ACM SOSP, Banff, Canada, October 2001. “Detour: a Case for Informed Internet Routing and Transport”, S. Savage, T. Anderson, A. Aggarwal, D. Becker, N. Cardwell, A. Collins, E. Hoffman, J. Snell, A. Vahdat, G. Voelker, and J. Zahorjan, IEEE Micro, 19(1):50-59, January 1999. “Dynamic Internet Overlay Deployment and Management Using the X-Bone”, J. Touch, Computer Networks, July 2001, pp. 117-135 “The Case for Resilient Overlay Networks”, D. Andersen, H.i Balakrishnan, M. Kaashoek, and R. Morris, Proc. HotOS VIII, Schloss Elmau, Germany, May 2001. “End-to-End Routing Behavior in the Internet”, V. Paxson, In Proc. ACM SIGCOMM, (Stanford, CA, Aug. 1996). “Delayed Internet Routing Convergence”, C. Labovitz, A. Ahuja, A. Bose, F. Jahanian, In Proc. ACM SIGCOMM (Stockholm, Sweden, September 2000), pp. 175–187. “Modeling TCP Throughput: A simple model and its empirical validation”, J. Padhye, V. Firoiu, D. Towsley, J. Kurose, In Proc. ACM SIGCOMM (Vancouver Canada, September 1998), pp. 303-323 “End-to-End WAN service availability”, B. Chandra, M. Dahlin, L. Gao, A. Nayate, In Proc. 3rd USITS (San Francisco, CA, 2001), pp. 97-108