From kwalsh@CS.Cornell.EDU Mon Nov 25 21:44:57 2002 Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQ2iv905762 for ; Mon, 25 Nov 2002 21:44:57 -0500 (EST) Received: from localhost (larry.cs.duke.edu [152.3.140.75]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id VAA02233 for ; Mon, 25 Nov 2002 21:44:56 -0500 (EST) From: kwalsh@CS.Cornell.EDU Received: from 66.218.5.17 ( [66.218.5.17]) as user walsh@imap.cs.duke.edu by login.cs.duke.edu with HTTP; Mon, 25 Nov 2002 21:44:55 -0500 Message-ID: <1038278695.3de2e027e6e68@login.cs.duke.edu> Date: Mon, 25 Nov 2002 21:44:55 -0500 To: egs@CS.Cornell.EDU Subject: 615 PAPER 72 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 66.218.5.17 Overlays are attractive for several reasons. High-level functionality is not typically implemented in the low-level network itself. There are lots of reasons for this: the end-to-end argument, the need/desire to keep the networking hardware and software as simple as possible, and eliciting cooperation from all of the competing interests on the network. Multicast is a good example of all the difficulties putting high-level functionality in the network. In an overlay, end nodes (or special intermediate nodes) can do all sorts of very high-level tricks in order to implement new or improved services, hide faults at low levels, or improve the quality delivered by the low level. Resilient Overlay Networks The focus of RON is mainly to hide network faults and improve network performance. The key observation is that, because of the political and administrative routing decisions (as well as the need for damping to improve stability), routers are very constrained in their choice of routes. This means many routes used will be sub-optimal, or failures reported even though alternate routes exist. At a high level, however, RON can find physical routes not available to routers by forwarding through one or more peers in the network. This is essentially taking advantage of the missing triangle-inequality on the internet. Another advantage is that applications can specify particular metrics (ie, how to evaluate latency, jitter, hop count, bandwidth, etc, when making routing decisions). On the other hand, RON has a much easier time than BGP in some sense. The RON is limited (by design) to a few dozen hosts. The topology is a fully-connected clique (n^2 links), and the routing protocol is fairly heavy weight (n^2 link-state dissemination), with very active monitoring and state sharing. These things are not possible with larger networks. Since there are likely to be few flows, it is reasonable (and beneficial) to also do per-flow monitoring and routing. Failure detection is done with active probing (again, very expensive even with such small networks). And yet not much is done (or probably needs to be done) about routing stability. Overcast: Reliable Multicasting with an Overlay Network The focus of Overcast is to implement multicast. Since the network layer has not yet implemented it and does not appear ready to do so any time soon, overcast instead pushes the functionality to the end nodes by using an overlay network. This allows overcast to be deployed incremenally. Unlike RON, Overcast envisions participants "sprinkled throughout [the] network fabric", not just at the end points. This is needed in order to achieve efficient one-to-many data transfers. Overlay is structured as more of an overlay service, in that it builds overlay tree topologies (multicast trees) on demand, rather than construcing a single overlay topology used for all applications or all packets. From jsy6@postoffice2.mail.cornell.edu Tue Nov 26 02:58:40 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQ7we904588 for ; Tue, 26 Nov 2002 02:58:40 -0500 (EST) Received: from Janet.cornell.edu (syr-24-58-3-36.twcny.rr.com [24.58.3.36]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id CAA27883 for ; Tue, 26 Nov 2002 02:58:40 -0500 (EST) Message-Id: <5.1.0.14.2.20021126025708.00ba9d80@postoffice2.mail.cornell.edu> X-Sender: jsy6@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 02:57:39 -0500 To: egs@CS.Cornell.EDU From: Janet Suzie Yoon Subject: 615 PAPER 72 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Overcast is a single-source multicasting system for an overlay network whose main goal is to provide a means for large-scale on-demand live data delivery. Overcast utilizes multicasting for caching and to create server replicas in order to minimize bandwidth requirements for multiple destinations. Its system contains a central source and internal nodes organized as a distribution tree. These distribution trees must be adaptive and built efficiently without knowledge of the substrate network topology. Since Overcast is single-source, increased bandwidth is more important than low latency. Thus the sole goal of Overcast distribution trees is to create high bandwidth channels from the source to all other nodes. A Resilient Overlay Network (RON) is a system that provides quick failure detection and recovery for distributed Internet applications. By monitoring Internet paths, RON decides whether to route directly over the internet or via other RON nodes based on optimizing application-specific routing metrics. The paper only deals with RON networks of small sizes (2-50 nodes) in order to efficiently support RON's aggressive path maintenance. Larger networks create too much bandwidth overhead since each node must both actively and passively observe data transfers to obtain path metrics needed to determine the quality of paths between it and other nodes. RON not only provides failure detection and recovery, but also application-controlled path selection and an expressive routing policy. One of the main advantages of an overlay network is that it requires no changes to the existing infrastructure. Thus, an overlay network can be deployed incrementally. Also, overlay networks are customizable and adaptable - they can be optimized over metrics that matter to the application (ie latency or bandwidth). Its adaptive property coupled with the increased control it provides, overlay networks also tend to robust and can be designed to route around faults immediately. Finally, Overlay networks are standard since they can be built on the network services of the substrate network. Other applications of overlay networks are providing better end-to-end performance and management functions. From shafat@CS.Cornell.EDU Tue Nov 26 03:06:35 2002 Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQ86Z905551 for ; Tue, 26 Nov 2002 03:06:35 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: 615 PAPER 72 Date: Tue, 26 Nov 2002 03:06:34 -0500 Message-ID: <47BCBC2A65D1D5478176F5615EA7976D134FF6@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 72 Thread-Index: AcKVIrzDldb5ISiTR+KgcffiD6K1Ag== From: "S. Shafat Zaman" To: "Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sundial.cs.cornell.edu id gAQ86Z905551 RON ---- Resilient Overlay Network (RON) is motivated by the fact that in the present architecture of the Internet, routers are required to make the trade-off between scalibility and fault-tolerance by damping routing updates across "borders". This is implemented by the Border Gateway Protocol or BGP. This mechanism results in a much longer delay in fault-recovery, in case of link or path failures for example, which in turn leads to further disruption in the overall communication in the network. In addition, the present infrastructure also does not take any higher level application requirement into consideration while making routing decisions. Different applications may have a varying sense of prioritized order of metrics. RON aims to address these issues by providing a mechanism for fast failure detection and recovery, tighter integration with applications and expressive policy routing. RON nodes are deployed at various locations across the Internet as an overlay network at the application layer. The nodes can talk to each other, periodically exchange routing information, and constantly monitor the quality of links between one another. More specifically, for each virtual link, it maintains information on latency, packet loss rate and throughput. Due to the relatively small size of a RON network, the nodes can maintain such information that enables them to make better routing decisions, and detect problems much sooner. The evaluations carried out also exhibit expected findings. RON was highly successful in detecting and recovering from outages in most cases, with a very low average convergence time. OVERCAST --------- Overcast is a single-source application-level multicasting system that targets certain internet applications that need to transfer large amounts of data to all the other members in the multicast group. It employs an overlay network designed to be highly-scalable and reliable, and focuses mainly on the bandwidth over other metrics due to the nature of its expected applications. In the Overcast tree, a node places itself in the hierarchy according to the bandwidth between the root and itself. The system also makes use of a protocol called the Up/Down protocol to keep a status list of all the nodes below a node. This enables all the nodes, including the root, to keep an up-to-date view of the tree. The paper finally presents results that evaluates the two major protocols presented that shows that Overcast performs well on large-scale networks. From ag75@cornell.edu Tue Nov 26 03:18:34 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQ8IX907896 for ; Tue, 26 Nov 2002 03:18:33 -0500 (EST) Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by travelers.mail.cornell.edu (8.9.3/8.9.3) with SMTP id DAA17020 for ; Tue, 26 Nov 2002 03:18:31 -0500 (EST) Date: Tue, 26 Nov 2002 03:18:31 -0500 (EST) From: ag75@cornell.edu X-Sender: ag75@travelers.mail.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 72 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The first paper we read this week talks about a Resilient Overlay Network (RON). RON allows distributed Internet applications to detect and recover from path outages and periods of degraded performance within about 20 seconds. The design of RON seeks to meet three main design goals: (i) failure detection and recovery in approximately 20 seconds; (ii) tighter integration of routing and path selection with the application; and (iii) expressive policy routing. In order to meet these goals the RON nodes monitor the quality of the paths between them, 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. The authors present an evaluation of this system using a 12 and a 16 node RONs. They admit that these sizes are small and that the system does not scale beyond 50 nodes. Their implementation is able to route around 60% to 100% of all significant outages taking 18 seconds on average and do so even in the face of an active DoS attack. This seems to be the main advantage of RON. The authors also claim that RON improved loss rates, latency and throughput. However, these benefits seem to apply to a very small percentage of samples and the improvements are not thatg great. Finally, participating in a RON implies trust that the other participants will forward your data correctly and will not abuse your forwarding. So, there is nothing in RON in terms of security, which is a a problem that should be addressed. The second paper describes Overcast. Overcast provides scalable and reliable single-source multicast using a protocol for building efficient data distribution trees that adapt to changing network conditions. Overcast is used with the goal of having high bandwidth channels to the root for all nodes. Other issues, such as latency, are not considered as important in this system. Overcast is inherently tolerant of non-root node failures. The single point of failure at the root node can also be eliminated using replication. The simulations done to test the system were executed with a network of 600 overcast nodes that the authors claim simulate multicast groups of approximately 12,000 members. The simulation results show that Overcast succeeds in providing high bandwidth channels to the root, but imposes high network load. Some of the advantages of overlay networks described in this paper are that they are: incrementally deployable, adaptable, robust, customizable and standard. From nbs24@cornell.edu Tue Nov 26 08:36:39 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQDad913415 for ; Tue, 26 Nov 2002 08:36:39 -0500 (EST) Received: by travelers.mail.cornell.edu (8.9.3/8.9.3) id IAA23384; Tue, 26 Nov 2002 08:36:31 -0500 (EST) Date: Tue, 26 Nov 2002 08:36:31 -0500 (EST) From: nbs24@cornell.edu Message-Id: <200211261336.IAA23384@travelers.mail.cornell.edu> To: egs@CS.Cornell.EDU Errors-To: nbs24@cornell.edu Reply-To: nbs24@cornell.edu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9 Sender: nbs24@cornell.edu X-Originating-IP: 64.185.145.94 Subject: 615 PAPER 72 Resilient Overlay Networks This paper describes the design and implementation of RON, a wide-area application-layer overlay network that allows distributed Internet applications to detect and recover from path outages and periods of degraded performance within seconds, instead of the traditional several minutes. Traditional overlay networks, based on BGP-4, do not handle link and path failures well. Since they retain very little traffic information, they take a long time to converge to a new valid route after an outage. Also, despite the need for policy routing and enforcement of acceptable us and other policies, BGP-4 is incapable of expressing fine-grained policies aimed at users or hosts. The goals of RON are: - Failure detection and recovery in less than 20 seconds. - Tighter integration of routing and path selection with the application. - Expressive policy routing. Nodes within the RON perform aggressive monitoring and co-operate with each other to route packets for each other. Information about path-quality is exchanged among RON nodes via a routing protocol and build forwarding tables based on latency, packet loss rate and available throughput. Each RON is designed to have between two and fifty nodes to facilitate aggressive path maintenance without excessive bandwidth overhead. Overcast: Reliable Multicasting with an Overlay Network Overcast is an application-level overlay network consisting of a central source, a number of internal Overcast nodes spread throughout the network and standard HTTP clients located in the network. It provides scalable and reliable single-source multicast using a simple protocol for building efficient data distribution trees that adapt to changing network conditions. It implements a new protocol for efficiently tracking the global status of a changing distribution tree, to support fast joins. To provide high bandwidth links between nodes, Overcast allows data to be sent once to many destinations. Data is replicated at appropriate points in the network to minimize bandwidth requirements while reaching multiple destinations. It takes advantaged of caching and server replication throughout the network. It is designed as an overlay network which allows it to be incrementally deployed. Advantages of Overlay Networks: - incrementally deployable; requires no changes to existing Internet infrastructure - adaptable; set of links constantly being optimized over metrics that matter to the application - robust; provides increased control - customizable; easily outfitted with whatever equipment makes sense - standard; can be built on the least common denominator network services of the substrate network Applications: RON: - multimedia conferencing program may link directly against the RON library, transparently forming an overlay between all participants in the conference, and using loss rates, delay jitter, or application- observed throughput as metrics on which to choose paths. - an administrator may use a RON-based router application to form an overlay network between multiple LANs as an ‘Overlay VPN’. - previous idea can be extended to from an ‘Overlay ISP’, by linking points of presence in different traditional ISPs after buying bandwidth from them. Overcast: - implemented and used to create a data distribution system for businesses Nana From vrg3@cornell.edu Tue Nov 26 09:27:10 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQER8924640 for ; Tue, 26 Nov 2002 09:27:08 -0500 (EST) Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by travelers.mail.cornell.edu (8.9.3/8.9.3) with SMTP id JAA12801 for ; Tue, 26 Nov 2002 09:27:06 -0500 (EST) Date: Tue, 26 Nov 2002 09:27:06 -0500 (EST) From: vrg3@cornell.edu X-Sender: vrg3@travelers.mail.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 72 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The RON paper presents a system whose essential purpose is to work around the difficulties of BGP to route on the internet. BGP is designed to be very scalable, and so when ASs fail, it takes many minutes to recover. Also, BGP is unable to handle special routing metrics such as congestion and bandwidth. RON constructs an overlay network which can route data around problems in the underlying network. The circumlocution is only done if the default internet route is problematic. RON nodes continually exchange huge amounts of path information with all other RON nodes, so the RON network is very resilient and can quickly recover from any problems in a matter of seconds. The RON network's routing can be chosen using any metric which is reasonable to the application. The clear tradeoff made is exactly the opposite of the one made by BGP: RON cannot scale. The designers of the protocol only meant it to have up to about 50 nodes, which is tiny. Their tests only went up to 16. The network load and bandwidth usage rise quadratically with the network size. The Overcast paper attempts to deal with the difficulties of IP multicast: that producer-to-consumer bandwidth is often below that necessary for multimedia broadcasts and that network usage scales linearly with the number of consumers. Overcast uses an overlay network with nodes spread throughout the internet. These nodes are organized into a tree with the source at the root, with links at higher levels having higher bandwidth. Additional nodes can be added incrementally. Each node caches the stream of data so that clients can request to begin the stream from any past point. Overlay networks, as shown by these two papers, can be used to overcome limitations in the underlying network. You can implement your own routing policies and protocols and use the underlying routing as a primitive. They also allow a network to be designed as if it were a very small network (so you can have things scale quadratically and whatnot) but allow the nodes to be far away from each other. It kind of makes sense for applications to use overlay networks to handle the higher-level parts of networking and allow the substrate to handle the lower-level parts. From bd39@cornell.edu Tue Nov 26 09:59:06 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQEx5904995 for ; Tue, 26 Nov 2002 09:59:06 -0500 (EST) Received: from boweilaptop.cornell.edu (r102439.resnet.cornell.edu [128.253.163.42]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id JAA20042 for ; Tue, 26 Nov 2002 09:59:00 -0500 (EST) Message-Id: <5.1.0.14.2.20021126095545.00b6ca10@postoffice2.mail.cornell.edu> X-Sender: bd39@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 09:55:54 -0500 To: egs@CS.Cornell.EDU From: Bowei Du Subject: 615 PAPER 72 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed PAPER 72 - RON and Overcast RON seeks to provide three services: failure tolerance and better performance than standard Internet routing, more tighly integrated routing services and more expressive routing services. Inter-AS BGP routing protocol on the Internet removes a lot of information in order to support scalability, dampening link changes. Also, its interface is not exposed to application, which cannot change routing behavior to fit its own metrics. RON maintains routes to members of the network with a link state protocol, which is possible due to the small size of the forwarding network. The properties of each of these virtual links is maintained using a performance database which maintains currently estimates and measured performance between RONs in the network. Policy based routing is implemented by tagging packet flows with a classification information. The advantages of RON is that it provides short cuts around normal hierarchical Internet routing, which for scalability reasons cannot maintain as much routing information, nor be as tightly integrated with applications. It seems that RON still does not solve the problem of bad BGP routing for any arbitrary hosts on the Internet. A RON network is only as good as its participating members. The evaluation did not examine the performance of routing to a non-RON node through the RON network. This is important because the RON network itself is small, and must remain so in order to be effective. Also, a RON must contain nodes in multiple AS in order to apply its benefits. Overcast Overcast uses an overlay network to efficiently provide multicast services. An Overcast network consists of a single source node and many receiving client nodes. It is targeted towards large data distribution requirements from a single node. Joins to the network are performed by initialy querying the root and iteratively trying to attach as far away from the root as possible in the tree without its bandwidth constraint. Periodically a node's relations are rexamined and the node sees if it can attach itself further away from the root. It seems that the Overcast evaluation did not consider fluctuations in bandwidth or node failures. The tree algorithm seems to be unstable given changes in the network. Node could constantly be changing parents. Also, what if there are many low bandwidth consumers, and few high bandwidth nodes. It seems that this would low imbalance the high bandwidth node that is furthest away from the root node by having all of the low bandwidth clients attach themselves there. Uses of Overlay Networks Overlay networks seem useful in situations in where user needed functionality is hard or inefficient to push into the network layer itself. They are a good solution to making changes in the way routing is performed on the Internet, because protocols have immense inertia once they are deployed, and applications are much more easily changed. From tom_m_roeder@yahoo.ca Tue Nov 26 10:32:37 2002 Received: from web80301.mail.yahoo.com (web80301.mail.yahoo.com [66.218.79.17]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with SMTP id gAQFWa911671 for ; Tue, 26 Nov 2002 10:32:36 -0500 (EST) Message-ID: <20021126153230.77962.qmail@web80301.mail.yahoo.com> Received: from [24.59.73.110] by web80301.mail.yahoo.com via HTTP; Tue, 26 Nov 2002 10:32:30 EST Date: Tue, 26 Nov 2002 10:32:30 -0500 (EST) From: Tom Roeder Subject: 615 PAPER #72 To: egs@CS.Cornell.EDU MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Normally this would be sent from tmroeder@cs.cornell.edu (Thomas Roeder), but I'm have network connectivity problems with CUCS. In today's papers, we were asked to examine two implementations of overlay networks, each serving a different purpose, to evaluate the utility of such networks, and to describe other possible uses of these systems. We have seen overlay networks used in all the applications mentioned last week in the context of DHTs, and here we see them used to reduce latency in multicast and add more robustness to a small group of hosts. The general principle at work here is fairly obvious: overlay networks let you create a level of abstraction, which has been shown to be a Good Thing in general. The other advantages are ease of configuration, or even auto-configuration, and robustness. For examples of their usage, we note that, games can create virtual, linked worlds in an overlay network, anonymous communication can be performed as in dc-nets, and virtual private networks created. The first paper is about Resilient Overlay Networks (RON), and discusses the design and test-implementation of a small-sized RON which can route around potential routing failures in the underlying substrate. Their design is entirely non-scalable, since it sends O(n^2) packets for n the number of hosts in the RON, but the authors argue that it is useful for linking together small numbers of hosts in a VPN-like arrangement. They address only one of the problems that NATs pose to their systems: the first is that two hosts behind the same NAT appear not to able to reach each other, and so RON will route around this "failure". The second comes into play with naming, since two hosts behind the same NAT will appear to have the same address. Their solution is to use the IP address of the host (from behind the NAT) as its identifier. Unfortunately, this leads to problems of uniqueness, since the 192.168.137.0/24 addresses might be used behind other NATs in the RON. The obvious solution is to have the ID of the node actually be something unique, like, for example, 192.168.137.2/24.58.23.232 (ie. appending the two addresses together, which *is* guaranteed to give uniqueness). The second paper is about a system called Overcast (which makes at least me feel homesick for Vancouver :-) which uses overlay networks in the Wide Area to stream high-bandwidth content in real time. They trade off hard-drive space for bandwidth here, by streaming the content to other members of a multicast tree first and then streaming from the closer members to the requesting client. They manage to send it over HTTP to pass it over the regular channels of web broadcast. To construct the tree, they have a way of determining where a node should go, which involves looking down the tree from the root until it finds the lowest place where its bandwidth is still unconstrained. While this does indeed help bandwidth, I would note that it destroys latency, though the authors admittedly do not care about latency in this picture. They too consider the obvious problems of NAT, and also fail to notice the potential for identical private addresses, which has the same solution I proposed above. Note further that here, their claim that the private address gives suitability for parenthood does not hold, unless they happen to have an intimate understanding of the internal structure of an organizations' subnetworks, which is unlikely in the general case. Their measurements show that while the system is linearly dependent on the number of nodes, the slope is very small, at least for relatively small numbers of nodes. ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From smw17@cornell.edu Tue Nov 26 11:31:21 2002 Received: from cornell.edu (cornell.edu [132.236.56.6]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQGVL924686 for ; Tue, 26 Nov 2002 11:31:21 -0500 (EST) Received: from cornell.edu ([128.84.84.84]) by cornell.edu (8.9.3/8.9.3) with ESMTP id LAA29139 for ; Tue, 26 Nov 2002 11:31:21 -0500 (EST) Message-ID: <3DDFD0FF.1040900@cornell.edu> Date: Sat, 23 Nov 2002 14:03:27 -0500 From: Sean Welch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emin Gun Sirer Subject: 615 PAPER 72 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Overcast Overcast seeks to provide a single source multiple consumer distribution system, with the goal of reliable data transmission. The system does not consider schemes to vary the data bandwidth of the data stream, instead aiming for reproduction at additional latency over low bandwidth links. Overcast provides this functionality by building a distribution tree as an overlay network on top of the basic IP infrastructure. Nodes in the tree attempt to place themselves as deep as possible while maintaining approximately the same bandwidth. Nodes periodically re-evaluate their position in the tree, shifting up or down dynamically as necessary. Overcast is a reasonable solution to the problem specified - a single source multiple consumers situation. It has some potential sticking points on scalability, as each node must keep track of all of the nodes located beneath it in the tree. Thus, the root node must store every node in the network, and may occassionally be required to update a significant portion of these node entries when nodes higher in the tree rearrange themselves. RON Reliable Overlay Networks (RONs) are an attempt to improve Internet scale routing. The basic concept is that there exists a relatively small group of nodes that form a single RON. These nodes are located about the net, and agree on a number of different policies that they will implement for forwarding data from other RON nodes to the desired destination. When a node wishes to transmit data to a remote node, it may either send the data directly over TCP/IP, or instead may choose to route the data through a RON in an attempt to either provide a better route or to avoid a current fault in the network. RONs are an effective solution for a few reasons. The first is that the total number of nodes in a RON is fairly small (12 and 16 in the examples provided), so that a fully connected graph is not prohibitive, and the data exchanges required to maintain the scheme is bearable. The second major factor is the relatively slow fault resolution of the BGP. The RON scheme is dependent on the fact that while a direct link between nodes A and B may not exist through the internet, a route may exist from a third node C that is still reachable by both A and B. The final factor is the lack of QoS routing in the current internet. Many of the benefits noted for RONs were in implementation of other routing metrics such as latency or minimum loss rather than maximum bandwidth routing. Additionally, RONs are not as concerned with maintining a stable (if suboptimal) network as BGP. Given that the current internet is not optimized for these metrics, it is little suprise that the RON scheme can improve on them. Overlay networks in general are useful in situations where it is desireable to make use of the currently existing network infrastructure for data transport, where incremental deployment and development are important, and where the ability to work with application specific metrics is necessary. To name a few possibilities, overlay networks can be used for P2P filesharing, wide-area VPN's and WANs, secure IP forwarding/redirection, content distribution, and almost any application that could be envisioned on a large-scale network. The caveats are that overlay networks incur higher latency penalties, are more susceptable to malicious nodes and tampering (as they are user-level programs), and are likely to be operating on less reliable nodes. As such, the implementation of an overlay network must take these factors into accout, and the desired network function must be carefully considered to ensure that an overlay network can provide reasonable performance. From mtp22@cornell.edu Tue Nov 26 11:31:31 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQGVV924708 for ; Tue, 26 Nov 2002 11:31:31 -0500 (EST) Received: from narnia (syr-24-59-96-248.twcny.rr.com [24.59.96.248]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with SMTP id LAA16599 for ; Tue, 26 Nov 2002 11:31:29 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Matt Piotrowski Reply-To: mtp22@cornell.edu To: egs@CS.Cornell.EDU Subject: 615 Paper 72 Date: Tue, 26 Nov 2002 11:32:02 -0500 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <0211261132020D.00168@narnia> Content-Transfer-Encoding: 8bit An advantage of overlay networks is their independence from the routing of the lower layers. This allows them to route packets according to many more metrics than are allowed in Internet routing. For example, Internet routers may consider a link viable as long as it is up; overlay routers may consider the same link down if there is large packet loss. In fact, RON was designed in such a way that applications can specify the routing metric(s). For example, a highly interactive application may care most about latency, while a file transferring application may care most about bandwidth. In the current Internet, these preferences would be ignored. In the overlay network, they could be specified as /the/ routing metrics. Overlay networks also have the advantage that they can be small. The Internet has no choice but to scale to millions of nodes. Overlay networks can be much smaller than this, allowing for aggressive probing. This aggressive probing can result in quick recovery when one of the links go down. In this case, outages are a matter of seconds rather than minutes or hours. Overlay networks can also be designed to route fundamentally differently than the Internet was designed to route. For example, as in the Overcast paper, the Internet was not designed for multicast. In an overlay network, however, this could be the sole purpose of the routers. Moreover, the routers quick recovery properties noted above can be used for quick joins and removes, which is a problem in large networks like the Internet. In the RON paper, it is stated that one approach to resiliency that has been tried in the past is having more than one ISP. They say that this doesn't work because there is no effective way to switch over connections from one ISP to the other in the current Internet. I agree, but I also think that their overlay network can be combined with this technique to make it effective. To do this, you could route by name and have each router in the overlay store the primary IP for the name and the backup IP. This way if a node's primary ISP went down, connections would automatically transfer, as they would be using the name, not the IP address. This technique could also be used for load balancing. From ashieh@CS.Cornell.EDU Tue Nov 26 11:36:58 2002 Received: from zinger.cs.cornell.edu (zinger.cs.cornell.edu [128.84.96.55]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQGaw925932 for ; Tue, 26 Nov 2002 11:36:58 -0500 (EST) Received: from localhost (ashieh@localhost) by zinger.cs.cornell.edu (8.11.3/8.11.3/C-3.2) with ESMTP id gAQGavo19547 for ; Tue, 26 Nov 2002 11:36:57 -0500 (EST) Date: Tue, 26 Nov 2002 11:36:57 -0500 (EST) From: Alan Shieh To: Subject: 615 PAPER 72 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII What are the advantages of overlay networks? What other network properties can be provided by overlay networks? Overlay networks allow new routing techniques and other network-level data services to be deployed on top of existing infrastructure, at the OS or applicaton level, without needing to change the low-level routing software. Since overlay networks are defined above the standard network protocols, such networks may be deployed incrementally, and multiple such networks may potentially coexist on the same infrastructure. Because overlay networks are typically supported by code installed on more flexible servers and rather than monolothic, critical devices like routers, they can support more flexible and ambitious algorithms. The placement of overlay routing software in the logical abstraction and physical space allows overlay network algorithms to exploit higher level application knowledge. In addition to routing and multicast, overlay networks can also be used for distributed load balancing, content distribution, VPNs, and messaging (IRC, SMTP, etc). **** Resilient Overlay Networks This paper contributes an overlay routing system that provides better adaptation and more sophisticated QoS and policy configuration than BGP. BGP is primarily designed to be scalable to global size, and does not propagate detailed routing information about the internals of autonomous systems (AS). Hence, not all possible routes are exploited, and adaptation is slow. A RON consists of geographically diverse nodes in the Internet which are connected to one another using standard IP routing. Since there are typically a small number (<100) nodes in a RON, they may disseminate much more link information, and use more sophisticated, less scalable algorithms. Each node continuously monitors the loss, latency, and throughput of the links to the neighboring nodes using active probing; this information is fed into a database for the benefit of the routing algorithms. RON uses standard link-state routing techniques, with the modification that only a single level of redirection is used in general; more hops are unlikely to provide better latency or loss, and it is difficult to optimize for nonlinear path cost functions if multiple hops are considered. Multiple application-specific routing tables may be active at the same time, which optimize for different metrics (latency, loss, TCP throughput). Routing information is disseminated using the overlay network itself, which allows information to reach nodes that have been disconnected in IP routing, but not in overlay routing. According to the results, RON indeed accomplishes its goals of faster adaptation, at a small latency and bandwidth overhead. It seems able to route around high-loss links, and provide alternate routes during periods of high congestion (for instance, a DoS attack on one link). * Shortcomings The authors prevented dynamic instability (hotspots in the network can induce rapid topology changes due to the feedback-based optimization techniques) using hysteresis. It is therefore difficult to reason about the performance degradation of the system when hotspots arise. The paper does not account for the deviation of latency in selected links, nor does it provide such data. Latency-sensitive interactive applications are typically sensitive to deviations in latencies. * Future work - As mentioned in the paper, RON does not consider the possible interactions between multiple RONs competing for the same bandwidth. It is conceivable that multiple administratively-isolated RONs would detect and use some overlapping set of "nice" paths, which would cause dynamic instability in the system if each RON decides to send significant data through those links. - Add mechanisms for sharing bandwidth cost. **** Overcast: Reliable Multicasting with an Overlay Network Overcast provides one-to-many multicast routing using an overlay network. An overcast network consists of dedicated servers, typically positioned in various positions along the backbone and in LANs. This overlay multicast allows for a richer address space than IP multicast, and can be deployed across WANs independent of ISP cooperation, where IP multicast cannot. An adaptive, locally-greedy algorithm is used to construct the multicast tree. This simplifies the decisions of where to place these servers, as diversity would allow the tree construction algorithm to determine a good overlay topology. Since an overlay network is unaware of the underlying network topology, the tree construction algorithm considers only the currently achievable throughput with the root, and places each node as far away from the root as possible without violating the throughput requirements. Topology changes (in the form of node connection and disconnection; these may occur in response to reorganization or to node failure) are sent to the root, which keeps track of routing information to each node. Overcast assumes that bandwidth transients due to topology changes are absorbed by client buffering. Overcast analysis was performed using a transit-stub model. The dynamic tree construction was able to find multicast trees with the same effective bandwidth as router level multicast algorithms when the Overcast nodes are placed along well-provisioned backbones. However, with completely random placement, Overcast achieves only about 80% of optimal even when all nodes in the network are included in the overcast tree. Hence, the tree building algorithm can be trapped at a local maximum. Overcast induces an overhead of about twice the network load over IP-multicast. ** Shortcomings The anomaly at 600 nodes for minimum multicast bandwidth is poorly explained. It's well-known that a minimum spanning tree is not necessarily unique, therefore the significance of the result is not that the algorithm fails to find a unique tree, but that it fails to find an optimal tree. Moreover, the disparity suggests some problem with the simulation setup, namely a lack of reproducibility. ** Future work - Since media files already require a significant amount of bandwidth, it is reasonable to assume that a high degree of control overhead is acceptable. Hence, a more sophisticated tree construction algorithm might be preferable to a local construction algorithm. From hs247@cornell.edu Tue Nov 26 11:57:10 2002 Received: from mailout6-0.nyroc.rr.com (mailout6-1.nyroc.rr.com [24.92.226.177]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQGvA901350 for ; Tue, 26 Nov 2002 11:57:10 -0500 (EST) Received: from hubby.cornell.edu (syr-24-59-74-55.twcny.rr.com [24.59.74.55]) by mailout6-0.nyroc.rr.com (8.11.6/RoadRunner 1.20) with ESMTP id gAQGv9k16476 for ; Tue, 26 Nov 2002 11:57:09 -0500 (EST) Message-Id: <5.1.0.14.2.20021126115701.00b975f0@postoffice2.mail.cornell.edu> X-Sender: hs247@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 11:57:16 -0500 To: egs@CS.Cornell.EDU From: Hubert Sun Subject: 615 Paper 72 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed These papers deal with Overlay Networks over the Internet. Both papers document several problems with the existing internet. Some of these problems include finding paths with maximum bandwidth and responsiveness to failures. Because of the current hierarchical structure of the internet, it is hard for protocols such as TCP/IP to find the "best route" from one node to the other. The current setup does not allow nodes to gain topology information which results in less then optimal routes and delayed reaction to failures. The following papers try to address some of these issues and provide more stable and reliable functionality for applications. Resilent Overlay Networks tries to solve this problem by having an overlay network of RON nodes that find optimal routes. RON's can be placed at arbitrary nodes on the internet. The job of RON's is to gather route enough information based on different metrics that allow RON's to identify the best path between RON nodes. Therefore if a node receives message and has to forward it to another RON, if regular TCP connection is less efficient, an alternate more efficient route will be used. Because they have to do a lot of monitoring, the protocol is very bandwidth intensive. Therefore the number of nodes in the network has to be kept small. Even with the small number of nodes, through experiments it was found that RON could respond faster to failures and also find routes with better bandwidth. Overcast provides an overlay network for the purpose of multicasting. Again, they identify that the routes found by the Internet may not necessarily offer the best bandwidth which is important in multicast. For their overlay network, they assume there is one source node. From this source node, a distributed tree is built as nodes are added to the system. With these nodes, the overlay network tries to find the optimal path from source to destination. Other services this overlay network offers is caching which can also increase multicast performance. In general, overlay networks can be used to try to mask problems that the regular internet may have (ie failures, optimal path). Also, there are many application specific properties that an application may need that a regular network can not provide. Overlay networks can provide application specific abstractions that allows programmers/users not to have to worry about the underlying network layer. From mr228@cornell.edu Tue Nov 26 11:58:25 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQGwO902091 for ; Tue, 26 Nov 2002 11:58:24 -0500 (EST) Received: by travelers.mail.cornell.edu (8.9.3/8.9.3) id LAA15840; Tue, 26 Nov 2002 11:58:21 -0500 (EST) Date: Tue, 26 Nov 2002 11:58:21 -0500 (EST) From: mr228@cornell.edu Message-Id: <200211261658.LAA15840@travelers.mail.cornell.edu> To: egs@CS.Cornell.EDU Errors-To: mr228@cornell.edu Reply-To: mr228@cornell.edu Cc: mr228@cornell.edu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9 Sender: mr228@cornell.edu X-Originating-IP: 128.84.223.176 Subject: 615 PAPER 72 RON is an overlay network whose goals are to provide certain routing properties that are not present in most underlying networks such as the Internet. The Internet routing protocols such as IP, BGP, etc. were designed with the end-to-end principle and thus provide the minimal amount of services necessary for routing. RON's goals are to add a layer providing better failure tolerance, an increase in performance, and more expressive routing primitives. One key difference between this and current Internet routing is that the application is given a greater voice in how and where packets are routed. RON uses a link state protocol. It maintains statistics on several different metrics (possibly estimates) in order to make better routing decisions. Policy-based routing is done through the use of flow identifiers. The primary advantage of using a system like RON is the potential for an increase in performance, although they stop short of validating this approach. It seems that problems similar to those in the existing Internet still exist and their performance evaluation seems to suggest RON must remain small in order to be efficient. Overcast is another system aimed at providing services to applications that are not present at the network or transport layers. Overcast seeks to provide an efficient broadcast channel -- there is a single origin for data and many receivers. Applications such as streaming media and pub/sub channels would be good candidates for such a system. The broadcast is setup over a tree structure that evolves as nodes join. A node joins to the root node and then works its way down the tree according to performance heuristics. Moving within the tree is then done by all nodes on some regular basis. It seems possible that this is susceptible to a problem of constant flux in the network -- that is readjustment by one node causes other nodes to readjust and this process becomes cyclic and therefore infinite. this may also be triggered by node failures. Future work might consider looking at this system given node failures and/or sharp changes in the underlying networks characteristics. From sc329@cornell.edu Tue Nov 26 12:14:23 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQHEN905998 for ; Tue, 26 Nov 2002 12:14:23 -0500 (EST) Received: from sangeeth.cornell.edu (syr-24-58-5-174.twcny.rr.com [24.58.5.174]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA12139 for ; Tue, 26 Nov 2002 12:14:22 -0500 (EST) Message-Id: <5.1.0.14.2.20021126121231.01f85e90@postoffice2.mail.cornell.edu> X-Sender: sc329@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 12:14:23 -0500 To: egs@CS.Cornell.EDU From: Sangeeth Chandrakumar Subject: 615 PAPER 72 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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. A RON is an application layer overlay on top of existing internet routing substrate. One of the main goal of RON is to integrate routing and path selection with distributed applications more tightly than is traditionally done. RON enables a group of nodes to communicate with each other in the face of problems with the underlying intenet paths connecting them. RON detects problems by aggressively probing and monitoring the paths connecting its nodes. RON allows applications to independently define and react to failures. Data enters the RON from RON clients via a conduit at an entry node. At each node, the RON forwarder consults with its router to determine the best path for the packet, and sends it to the next node. Path selection is done at the entry node, which also tags the packet, simplifying the forwarding path at other nodes. When the packet reaches the RON exit node, the forwarder there hands it to the appropriate output conduit, which passes the data to the client. To choose paths, RON nodes monitor the quality of their virtual links using active probing and passive observation. RON nodes use a link-state routing protocol to disseminate the topology and virtual link quality of the overlay network. ROn also supports dynamic announcement-based, soft-state membership protocol. The new node need to know the identity of atleast one peer in the RN. The new node uses this neighbor to broadcast its existence using a special RON client called flooder that implements a general-purpose, resilient flooding mechanism using a RON forwarder. The evaluations given in the paper suggest that RON was able to overcome more than 60% of the several hundred significant outages observed. The results that RON is a good platform for building various resilient distributed internet applications. From ks238@cornell.edu Tue Nov 26 12:15:24 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQHFO906129 for ; Tue, 26 Nov 2002 12:15:24 -0500 (EST) Received: from ks238.cornell.edu (syr-24-24-18-11.twcny.rr.com [24.24.18.11]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA15792 for ; Tue, 26 Nov 2002 12:15:22 -0500 (EST) Message-Id: <5.1.0.14.2.20021126121450.021ca8e0@postoffice2.mail.cornell.edu> X-Sender: ks238@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 12:15:16 -0500 To: egs@CS.Cornell.EDU From: Karan Suri Subject: 615 Paper 72 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The first paper presents RON , a resilient overlay network, which is an application layer overlay that is built on top of the Internet. The primary purpose of RON is to implement a route maintenance protocol by which routing decisions are made based on the optimization of certain application specific metrics. A big problem with the internet as described in the paper are the numerous connectivity issues making many internet path unreliable. RON seeks to solve this problem through the use of RON nodes that are found within different routing domains of the network. Should the Internet be the provider of the most efficient path, then the Internet path is employed. However, due to an unreliable Internet path the RON nodes may be used and through a select number of intermediate hops data can be transferred reliably by only using these RON nodes. RON has three main design goals of importance: failure detection and recovery in less than 20 seconds, the tighter integration between the path selection and the application and the expressive policy routing. RON nodes are deployed across different locations of the Internet which forms an application-layer overlay which consists of virtual links that communicate with each other through a routing protocol that exchanges quality metrics with each node. Suprisingly, the paper suggests that on average communication amongst RON nodes can be completed in at most one intermediate RON node. Each RON node runs the RON client which allows all RON nodes to collaborate to provide distributed service or application. Each RON node consists of a forwarding table which is used in order to route packets to their respective destinations. In addition, paths are selected optimally based on the path's current latency, packet loss rate and throughput. The next paper presents overcast, which is another overlay network which provides scalable and reliable single source multicast through the use of distribution trees which are robust. The key problem that overcast aims to solve are the limitations imposed by network bottlenecks on applications that are bandwidth intensive. In other words, the paper identifies the viewing of bandwidth intensive video over the internet which may be difficult due to the bottlenecks in the network from the server to the goal client. Overcast aims to rectify this problem through the use of strategic caching at nodes which are not bottlenecked by the network (i.e. have high level of bandwidth capabilities). The selection of these nodes is through the use of distribution trees (the primary contribution of the paper). Distribution trees exploit each nodes bandwidth capabilities from source in order to adapt to a constantly changing network. Also, the root of the distribution tree maintains global knowledge of the overcast group which facilitates efficient responses to node failures. The paper discusses some key features of overlay networks such as the fact that they require no changes to Internet infrastructure and links are used based on application specific metrics. Furthermore, unlike IP Multicast, Overcast supports single source multicast which ensure simplicity and optimality at the cost of flexibility of functionality. The key areas of the protocol are also discussed. These include initialization where a new node notifies the rest of the Overcast group of its existence. Next, the tree building protocol established distribution trees using an algorithm which orders nodes in a manner that maximizes total bandwidth to the root node. The goal of this algorithm is that every node should be placed as far away from the root node without sacrificing bandwidth. The up/down protocol discusses the method in which nodes in the Overcast group can exchange information (i.e. amount of times certain content is viewed). Finally, since the root is a single point of failure which stores vital global information for distribution trees, the paper also discusses methods by which roots can be replicated in case. Overall these overlay networks seem to have positive results from their evaluations. From pj39@CS.Cornell.EDU Tue Nov 26 12:50:53 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAQHoq914357 for ; Tue, 26 Nov 2002 12:50:53 -0500 (EST) Received: from pj39.cornell.edu (dhcp-659.rover.cornell.edu [128.84.26.147]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA24045 for ; Tue, 26 Nov 2002 12:50:53 -0500 (EST) Message-Id: <5.1.0.14.2.20021126124801.0227b1f0@postoffice2.mail.cornell.edu> X-Sender: pj39@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 12:50:53 -0500 To: egs@CS.Cornell.EDU From: Piyoosh Jalan Subject: 615 PAPER 72 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resilient Overlay Networks Overcast: Reliable Multicasting with an Overlay Network What are the advantages of overlay networks ? Overlay networks are networks built over an underlying existing network infrastructure. For example set of nodes could form an overlay network on top of the existing internet infrastructure. The overlay network could provide additional functionalities like detecting and recovering from path outages, support multicast, map Ipv6 to Ipv4 addresses using an ON and P2P services like chord etc. Since ONs are built on top of an existing network they can be made more efficient than the underlying protocol such as RON enables a group of nodes to communicate even when the paths between them suffers from either link failures or path failures. Similarly Overcast provides scalable and reliable single source multicast by building an efficient and adaptable tree. Simulations prove that Overcast builds bandwidth efficient tree and performs better as compared to IP multicast. Since ON as built on top of an existing network they are at application level and hence can use the lower level functionalities of the existing network to build a more fault tolerant, more secure, more scalable network apart from the possibility of providing additional services. What other network properties can be provided by overlay networks ? ONs can be used to solve the end to end loss property due to high use of NATs. An overlay network of nodes along with P2P services like chord be used to form an overlay network over the current ipv4 infrastructure to map ipv6 to ipv4 addresses and help restore the end to end property of the internet. Among other network properties ONs can provide security, ip multicast, ip anycast etc. The disadvantages of ONs being increase in latency. From vivi@CS.Cornell.EDU Sat Nov 30 01:01:11 2002 Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id gAU61B925209 for ; Sat, 30 Nov 2002 01:01:11 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 615paper72 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 30 Nov 2002 01:01:05 -0500 Message-ID: <47BCBC2A65D1D5478176F5615EA7976D11AFB9@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615paper72 Thread-Index: AcKYNd2wrVQSvPEwR5a8gDMgPiiVRA== From: "Vivek Vishnumurthy" To: "Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id gAU61B925209 The first paper describes RON (Resilient Overlay Network), a setup built on top of the existing Internet substrate. It aims to provide robust connectivity, with speedy recovery from path outages. In a RON, nodes that belong to the RON are organized as an overlay, with each node maintaining routing information about the other participating nodes. A different routing table is maintained at each node corresponding to each of the different metrics relevant to the applications that run on the nodes. This allows the overlay to provide optimization of path parameters that caters to the needs of the application. One drawback of RON is that it is not scalable. The number of nodes in an overlay is limited to 50, as the network traffic grows untenably huge for larger number of nodes. A possible improvement: The possibility of route flapping can be reduced by taking into account the effect of routing traffic through the link under consideration, and choosing that link that gives the best performance when the packet is sent through the link. The second paper describes the implementation of a reliable multicast scheme using an overlay network. This paper aims to improve the bottleneck bandwidth, by using abundantly available disk space. Nodes that are part of a multicast group are organized as an overlay tree, with one of the nodes as the root. Easy and incremental deployment of Overcast is one of its main strengths. Also, the paper claims that Overcast saves bandwidth when multiple clients want access the same content at different times, but it is not clear how the cached content can be used to achieve this. A weakness of Overcast is its inapplicability to interactive applications, as there is no upper bound on the latency observed by the application. Advantages of Overlay Networks, and other possibilities: -------------------------------------------------------- Overlay networks provide fault tolerance and redundancy, since it is possible to maintain different paths between the same source-destination pair at the same time. Other network properties: It is possible to realize better transfer times by performing parallel fetches through different paths (when the bottleneck is not the source or the destination node).