From victoria@cs.hmc.edu Wed Apr 5 20:21:42 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from penguin.cs.cornell.edu (penguin.cs.cornell.edu [128.84.96.11]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k360Lgt23379 for ; Wed, 5 Apr 2006 20:21:42 -0400 (EDT) Received: from turing.cs.hmc.edu ([134.173.42.99]) by penguin.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 20:21:41 -0400 Received: by turing.cs.hmc.edu (Postfix, from userid 34382) id 064C053201; Wed, 5 Apr 2006 16:57:48 -0700 (PDT) Date: Wed, 5 Apr 2006 16:57:48 -0700 From: Victoria Krafft To: egs+summary@cs.cornell.edu Subject: PAPER 19 Message-ID: <20060405235748.GA9034@cs.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 06 Apr 2006 00:21:41.0979 (UTC) FILETIME=[1431BAB0:01C65910] Overcast uses an overlay network to provide single-source multicast. In Overcast, nodes which wish to subscribe to some multicast channel self-organize into a content distribution tree, with node providing the data source at the root. Because it has a more limited focus than Narada or yoid, Overcast can eliminate some of the overhead those protocols require. Overcast attempts to maximize the bandwidth between nodes. Individual nodes join as children of the root, and then attempt to move as far down the tree as possible without sacrificing bandwidth. Nodes periodically re-evaluate their place in the network, and move around as needed. In Overcast, each node stores information about the status of all nodes underneath it. When a node fails, its children simply re-join the tree as children of an ancestor. This approach still has some potential issues. Because all nodes start out as direct children of the root node, a flash crowd could overwhelm the link between the root node and the rest of the world, reducing performance for everyone. Because Overcast focuses on bandwidth when creating trees, a large network could produce deep trees, and a large latency between the root node and a leaf. Using a different metric when building the trees could improve this. The general structure of a tree-based system also puts more load on some nodes than others; high-bandwidth nodes will be broadcasting out more data than they are taking in, while leaf nodes use no outgoing bandwidth. -- Victoria Krafft From sh366@cornell.edu Thu Apr 6 01:30:14 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k365UDt24850 for ; Thu, 6 Apr 2006 01:30:13 -0400 (EDT) Received: from orpheus3.dataserver.cornell.edu (orpheus3.dataserver.cornell.edu [128.253.161.167]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k365UClJ025293 for ; Thu, 6 Apr 2006 01:30:13 -0400 (EDT) Message-ID: <1487752533.1144301411648.JavaMail.webber@orpheus3.dataserver.cornell.edu> Date: Thu, 6 Apr 2006 01:30:11 -0400 (EDT) From: Huang Shiang-Jia To: egs+summary@cs.cornell.edu Subject: PAPER 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: uPortal WEB email client 3.0 Overlcast is an application-level multicast system implemented as an overlay network. It builds a data distribution tree, whose goal is to optimize the bandwidth, for single-source multicast, and its protocol provides timely status updates to adapt to the changing network conditions. * Overcast distribution tree emphasizes bandwidth efficiency over other metrics such as latency. It places a node as far away from the root as possible without sacrificing the bandwidth. * To join, nodes contact the root of an Overcast group and move down to the point in the tree where they can still maintain some level of bandwidth. They constantly re-evaluate their positions in the tree, in terms of bandwidth, and move if necessary. * With the up/down protocol, each node periodically checks with its parent, and this information of which nodes are up/down is propagated to the root. The purpose of this protocol is for the root to maintain the global state of the Overcast system. * The source (root) of each distribution tree acts as a single point of failure and carries all loads. To alleviate this, several replicated roots together handle the node joins in round-robin fashion. Some number of nodes starting with the root are configured linearly to address fault tolerance. * In Overcast multicasting, only one non-root sender is active at any particular time. The sender unicasts to the root, which performs the multicast on behalf of the sender. Data are moved between parent sand children using TCP streams. * The participating nodes in this system are supposed to be dedicated machines rather than desktop computers. This protocol is thus less suitable in peer-to-peer systems. * Replication of the root can't change the nature of load imbalance in a multicast distribution tree. Interior nodes carry the load to forward data while leaf nodes don't. Loads are Not evenly distributed to all participants in the system. From niranjan.sivakumar@gmail.com Thu Apr 6 02:05:55 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,HTML_00_10, HTML_MESSAGE autolearn=no version=3.1.0 X-Spam-Level: Received: from penguin.cs.cornell.edu (penguin.cs.cornell.edu [128.84.96.11]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k3665st03123 for ; Thu, 6 Apr 2006 02:05:54 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.193]) by penguin.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 02:05:54 -0400 Received: by xproxy.gmail.com with SMTP id s7so69757wxc for ; Wed, 05 Apr 2006 23:05:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=NFvACHwVy/tAYo+3d7OoCL6DtQFBOG3+3i/KRZPH7WUg8iOgHKCLbTjPyjhqJ/b7cQ+HNXD/Map+nZnqEIGlZLRpwS2VzEq9VjbDXROucmiYCiRxZJsysF4Vr/NivYZXc5/K5hHsxXByJ0nZtKQnapCAaILim91OnnkKEeKqh/E= Received: by 10.70.99.4 with SMTP id w4mr708617wxb; Wed, 05 Apr 2006 22:37:30 -0700 (PDT) Received: by 10.70.128.19 with HTTP; Wed, 5 Apr 2006 22:37:30 -0700 (PDT) Message-ID: Date: Thu, 6 Apr 2006 01:37:30 -0400 From: "Niranjan Sivakumar" To: egs+summary@cs.cornell.edu Subject: PAPER 19 MIME-Version: 1.0 X-Security: message sanitized on sundial.cs.cornell.edu See http://www.impsec.org/email-tools/sanitizer-intro.html for details. $Revision: 1.148 $Date: 2004-12-19 11:59:17-08 X-Security: The postmaster has not enabled quarantine of poisoned messages. Content-Type: multipart/alternative; boundary="----=_Part_21850_31051359.1144301850531" X-OriginalArrivalTime: 06 Apr 2006 06:05:54.0856 (UTC) FILETIME=[2A44AA80:01C65940] ------=_Part_21850_31051359.1144301850531 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Niranjan Sivakumar Overcast: Reliable Multicasting with an Overlay Network Overcast is an overlay network that was designed as an alternate to network level IP multicasting. Overcast is designed to provide a tree-like structure to facilitate single source multicasting in a scalable and efficient manner. Overcast builds a tree through by having nodes that join the network move further and further away from the source until performance drops below a certain threshold. The joining node will successively contacts children of nodes and moves down the tree if the bandwidth achieved through the childre= n is close to that of the parent. In the case that bandwidths between multiple children are similar, the closest node (in terms of network hops) is selected. The system is currently setup to measure bandwidth with 10K transfers, but it is noted that this may not be the optimal solution. Once in the network, nodes periodically update their position by testing bandwidth a few levels up the tree. Since nodes maintain knowledge of node= s further up the tree, they can re-associate themselves in the event of a parent or other higher level node failure. The system also has an up/down protocol to help maintain state in the network. "Death" and "birth" certificates are distributed up the tree when nodes leave the network, join, or find new parents. Parent nodes never initiate contact with children while children periodically check in with parents. Any node in the system knows the parents of all of its descendents. Since the root in this kind of tree is particularly vulnerable, a simple system of linear roots is provided to provide some extra reliability. One of the issues seen in this system is that there could be an issue with latency with the deep tree approach that is advocated. This is noted to no= t be the metric that Overcast is considering, but it seems to be something that could be important given that one of the main applications that Overcast is designed to support is live broadcasting of media. Given this particular application, the analysis section does not seem to consider some of the major churn that could be associated with the broadcast of something like a live TV channel. It seems to be reasonable to expect that a huge number of nodes may join to obtain popular content, and that viewers would fluctuate significantly throughout the day. Also, it seems that load may have been better distributed in the system if there was some mechanism to engage nodes "across" the tree, as seen in some other multicasting systems. ------=_Part_21850_31051359.1144301850531 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Niranjan Sivakumar

Overcast:  Reliable Multicasting with an Ove= rlay Network

Overcast is an overlay network that was designed as an = alternate to network level IP multicasting.  Overcast is designed to p= rovide a tree-like structure to facilitate single source multicasting in a = scalable and efficient manner.

Overcast builds a tree through by having nodes that join the networ= k move further and further away from the source until performance drops bel= ow a certain threshold.  The joining node will successively contacts c= hildren of nodes and moves down the tree if the bandwidth achieved through = the children is close to that of the parent.  In the case that bandwid= ths between multiple children are similar, the closest node (in terms of ne= twork hops) is selected.  The system is currently setup to measure ban= dwidth with 10K transfers, but it is noted that this may not be the optimal= solution.  Once in the network, nodes periodically update their posit= ion by testing bandwidth a few levels up the tree.  Since nodes mainta= in knowledge of nodes further up the tree, they can re-associate themselves= in the event of a parent or other higher level node failure. =20

The system also has an up/down protocol to help maintain state in t= he network.  "Death" and "birth" certificates are = distributed up the tree when nodes leave the network, join, or find new par= ents.  Parent nodes never initiate contact with children while childre= n periodically check in with parents.  Any node in the system knows th= e parents of all of its descendents.  Since the root in this kind of t= ree is particularly vulnerable, a simple system of linear roots is provided= to provide some extra reliability. =20

One of the issues seen in this system is that there could be an iss= ue with latency with the deep tree approach that is advocated.  This i= s noted to not be the metric that Overcast is considering, but it seems to = be something that could be important given that one of the main application= s that Overcast is designed to support is live broadcasting of media. = Given this particular application, the analysis section does not seem to c= onsider some of the major churn that could be associated with the broadcast= of something like a live TV channel.  It seems to be reasonable to ex= pect that a huge number of nodes may join to obtain popular content, and th= at viewers would fluctuate significantly throughout the day.  Also, it= seems that load may have been better distributed in the system if there wa= s some mechanism to engage nodes "across" the tree, as seen in so= me other multicasting systems.
------=_Part_21850_31051359.1144301850531-- From pjk25@cornell.edu Thu Apr 6 02:08:29 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from iago.cs.cornell.edu (iago.cs.cornell.edu [128.84.96.10]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k3668St03385 for ; Thu, 6 Apr 2006 02:08:28 -0400 (EDT) Received: from authusersmtp.mail.cornell.edu ([128.253.83.141]) by iago.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 02:07:24 -0400 Received: from [10.0.1.3] (cpe-69-207-37-155.twcny.res.rr.com [69.207.37.155]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id k3667NXl011791 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 6 Apr 2006 02:07:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <5F5C3C9A-EB0C-4322-A9F5-E98D72883D7B@cornell.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: egs+summary@cs.cornell.edu From: Philip Kuryloski Subject: PAPER 19 Date: Thu, 6 Apr 2006 02:07:25 -0400 X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 06 Apr 2006 06:07:24.0392 (UTC) FILETIME=[5FA2C680:01C65940] OVERCAST The primary purpose of the Overcast overlay network is to provide an efficient and better alternative to IP Multicast. As it is implemented as an overlay, it does not require changes to network routers or other hardware, and thus can be deployed incrementally. Also, it is designed for the multicast of content which must be delivered in its entirety, rather than dynamically shaping content to ensure real time delivery like some other multicast schemes. Overcast also differs from IP multicast in that it allows only single- source multicast. Overcast was implemented as a linux app with a single source and multiple clients, distributing video content. The distribution tree is identified by a url, allowing clients to contact the root through the url, which then directs the requester to download from the nearest client machine with the content. When a node joins the system, it must know the address of an overcast root, which it contacts to receive information indicating which nodes it should contact and what area of the internet it should serve. Nodes attempt to organize themselves in as deep a distribution tree as possible which does not sacrifice their bandwidth connecting them to the source. The root is eliminated as a single point of failure by replicating the root and using traditional DNS resolution techniques to spread request over the replicas. The system has been implemented on 10s of nodes, and so is tested for larger networks (600 nodes) through simulation. They find that if Overcast nodes are placed as if they are part of an IP Multicast backbone, the system is most effective, but achieves 80% of that bandwidth if nodes are randomly placed. However, they have no simulation results to indicate how effective the system may actually seem to the end user. Although the system is self configuring, they simulate nodes placed on relatively high speed links (T1, T3). This indicates that care must be taken when deploying the system, and that it cannot be adopted by "standard users" of the internet who do not have multi-megabit connections. From lackhand@gmail.com Thu Apr 6 02:12:41 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,HTML_00_10, HTML_MESSAGE autolearn=no version=3.1.0 X-Spam-Level: Received: from penguin.cs.cornell.edu (penguin.cs.cornell.edu [128.84.96.11]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k366Cet04211 for ; Thu, 6 Apr 2006 02:12:40 -0400 (EDT) Received: from pproxy.gmail.com ([64.233.166.178]) by penguin.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 02:12:41 -0400 Received: by pproxy.gmail.com with SMTP id c39so72790pyd for ; Wed, 05 Apr 2006 23:12:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=PbhhDJZodhyxhSix5LjDQM1IomhuM6LpibAgflIeamLe4/3w5DwkyansIGafKCLBhdHSXv/Z2G3yh1F4rzZfWdF9syfD3diYxSibfXD6pK55Fihv+Wv8ZJR6xuLfoVkymbcMCanHjhMA6cKqcuLCdEVfJeYbmSEqb0f0VbbDkZE= Received: by 10.35.8.1 with SMTP id l1mr508336pyi; Wed, 05 Apr 2006 22:11:13 -0700 (PDT) Received: by 10.35.125.16 with HTTP; Wed, 5 Apr 2006 22:11:13 -0700 (PDT) Message-ID: <9aa7a97d0604052211n4cb06e9bk61db28a2841df1f3@mail.gmail.com> Date: Thu, 6 Apr 2006 01:11:13 -0400 From: "Andrew Cunningham" To: egs+summary@cs.cornell.edu Subject: PAPER 19 MIME-Version: 1.0 X-Security: message sanitized on sundial.cs.cornell.edu See http://www.impsec.org/email-tools/sanitizer-intro.html for details. $Revision: 1.148 $Date: 2004-12-19 11:59:17-08 X-Security: The postmaster has not enabled quarantine of poisoned messages. Content-Type: multipart/alternative; boundary="----=_Part_3134_22675789.1144300273927" X-OriginalArrivalTime: 06 Apr 2006 06:12:41.0106 (UTC) FILETIME=[1C697F20:01C65941] ------=_Part_3134_22675789.1144300273927 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andrew Cunningham arc39 Overcast: Reliable Multicasting with an Overlay Network John Jannotti, David K. Gifford, Kirk L. Johnson, M. Frans Kaashoek, James W. O'Toole Jr. Slightly showing its age, Overcast is an unsophisticated system that belies considerable power, allowing single transmitter broadcast of arbitrary information through an overlay network. The insight is that it is quite likely that transmitter bandwidth and later nodes' bandwidth are somewhat unrelated; in specific, there exist optimal topologies to perform this distribution. The additions are that it uses permanent storage to boost existing network performance, a simple protocol for forming efficient and scalable distribution trees that adapt to changes in the conditions of the substrate network, a novel protocol for maintaining global status at the root of a changing distribution tree, for quick joins, and to do it all efficiently. Attention is given to deployability, with many choices for the algorithm decided by the actual behavior of firewalls and NATs, using HTTP TCP to perform its activities (for maximum applicability). Joining the network consists of contacting a node already in the distribution tree and then modifying to maintain maximal bandwidth to the root; starting at the root, the node will try to locate itself further from the root based on bandwidth through current and through each of current's children, for current beginning at the root, and breaking ties with number of substrate hops (via traceroute). To keep track of remote events, there are periodic heartbeats sent, which include update information from the child to the parent. To alleviate the burden on the root, some requests are redirected via DNS name of the root resolving to multiple addresses and to improve crash performance, there are multiple copies of the root maintained (linear children). The flaws of this paper are due to age, not the paper itself; it's clear that the behavior of the multicast tree is passed by systems such as Bullet and SplitStream, to name a few. However, as a first stab, the system is quite scalable, though suffering from scalability problems at the root itself, and reasonably efficient. The experimental data support the thesis of the paper, but moreover, the attempts made at tree reassembly and self-assembly are sufficiently advanced to be recognized as an acheivement. The choice of protocol medium is ingenious, allowing easy integration of existing technologies, and the attention to implementability, though accompanying the reminder of lack of actual implementation, is well appreciated. ------=_Part_3134_22675789.1144300273927 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andrew Cunningham
arc39

Overcast: Reliable Multicasting with an Overlay Network
John Jannotti, David K. Gifford, Kirk L. Johnson, M. Frans Kaashoek, James = W. O'Toole Jr.

Slightly showing its age, Overcast is an unsophisticated system that belies considerable power, allowing single transmitter broadcast of arbitrary information through an overlay network. The insight is that it is quite likely that transmitter bandwidth and later nodes' bandwidth are somewhat unrelated; in specific, there exist optimal topologies to perform this distribution. The additions are that it uses permanent storage to boost existing network performance, a simple protocol for forming efficient and scalable distribution trees that adapt to changes in the conditions of the substrate network, a novel protocol for maintaining global status at the root of a changing distribution tree, for quick joins, and to do it all efficiently. Attention is given to deployability, with many choices for the algorithm decided by the actual behavior of firewalls and NATs, using HTTP TCP to perform its activities (for maximum applicability). Joining the network consists of contacting a node already in the distribution tree and then modifying to maintain maximal bandwidth to the root; starting at the root, the node will try to locate itself further from the root based on bandwidth through current and through each of current's children, for current beginning at the root, and breaking ties with number of substrate hops (via traceroute). To keep track of remote events, there are periodic heartbeats sent, which include update information from the child to the parent. To alleviate the burden on the root, some requests are redirected via DNS name of the root resolving to multiple addresses and to improve crash performance, there are multiple copies of the root maintained (linear children).
The flaws of this paper are due to age, not the paper itself; it's clear that the behavior of the multicast tree is passed by systems such as Bullet and SplitStream, to name a few. However, as a first stab, the system is quite scalable, though suffering from scalability problems at the root itself, and reasonably efficient. The experimental data support the thesis of the paper, but moreover, the attempts made at tree reassembly and self-assembly are sufficiently advanced to be recognized as an acheivement. The choice of protocol medium is ingenious, allowing easy integration of existing technologies, and the attention to implementability, though accompanying the reminder of lack of actual implementation, is well appreciated.
------=_Part_3134_22675789.1144300273927-- From asr32@cornell.edu Thu Apr 6 02:45:09 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from authusersmtp.mail.cornell.edu (granite1.mail.cornell.edu [128.253.83.141]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k366j8t10580 for ; Thu, 6 Apr 2006 02:45:08 -0400 (EDT) Received: from dreadnought.cornell.edu (r253240123.resnet.cornell.edu [128.253.240.123]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id k366j8sD013593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 6 Apr 2006 02:45:08 -0400 (EDT) Message-Id: <6.2.1.2.2.20060406023919.030490f8@postoffice8.mail.cornell.edu> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 06 Apr 2006 02:45:32 -0400 To: egs+summary@cs.cornell.edu From: Ari Rabkin Subject: PAPER 19 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Overcast: Overcast is a tree-based multicast system. Nodes connect to a root, and explore down the tree, along the path that yields the greatest bandwidth. As a result, a node will (hopefully) come to rest at the bottom of the tree, with the property that the root-to-node bandwidth is large. Each node keeps track of both ancestors and descendants, so failure recovery is straightforward. The overall throughput is quite high, though not so high as mesh-based systems such as SplitStream and Bullet. Overcast does put significant stress on the root node, requiring chain replication to ensure fault-tolerant behavior. The time to reconnect if a node goes down may be substantial, with the system relying on caches at each node to replay lost content. The high latency of deep trees may make Overcast unsuitable for applications other than streaming content or file distribution. Since the system relies on nodes to execute the protocol properly, Overcast cannot be deployed on untrusted nodes. Overcast is an effective system to run on dedicated multicast servers, but is not a general peer-to-peer multicast system. Ari Rabkin asr32@cornell.edu Risley Hall 454 3-2842 The resources of civilization are not yet exhausted. --William Gladstone From ids3@cornell.edu Thu Apr 6 10:43:28 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from authusersmtp.mail.cornell.edu (granite1.mail.cornell.edu [128.253.83.141]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k36EhSt28918 for ; Thu, 6 Apr 2006 10:43:28 -0400 (EDT) Received: from [128.253.212.208] (r253212208.resnet.cornell.edu [128.253.212.208]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id k36EhRKY023710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 6 Apr 2006 10:43:27 -0400 (EDT) Message-ID: <44352914.5090601@cornell.edu> Date: Thu, 06 Apr 2006 10:43:32 -0400 From: Ivan Stoyanov User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: egs+summary@cs.cornell.edu Subject: PAPER 19 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Overcast builds an overlay network out of dedicated hosts placed at strategic locations. Hosts self-organize themselves into a distribution tree rooted at the source. Clients request content via a HTTP request to the root. The root selects the most appropriate leaf node and redirects the client to it. Link choices are optimized for bandwidth. The tree is generated by maximizing the bandwidth from the candidate node to the root, placing it as deep as possible, without sacrificing bandwidth to the source. This is done by starting at the root and recursively probing the available bandwidth to the current node directly and through each of its children. Bandwidth is measured by determining the download time of 10 Kbytes. Nodes periodically reevaluate their position in the tree by measuring bandwidth to its siblings, parent and grandparent and make decisions based on the same logic. This periodic check allow the tree to adapt to the changing network conditions and serves as a failure recovery mechanism for non-root nodes. In addition, each node periodically reports statistical information up to the root, to facilitate client redirection decisions. The paper makes an interesting point about streaming content delivery. With an IP multicast infrastructure, clients can only receive packets in real time. However, in ALM nodes can leverage the availability of storage in the overlay by serving non-real time client requests . Overcast is a simple protocol for ALM that is designed to will work well in a dedicate infrastructure environment (it is not designed to handle high churn, to quickly recover from failure, etc). If applied for as a peer-to-peer solutions, it will be unfair towards inner nodes in the tree compared to leaf nodes. A deep tree may incur higher latencies, but in a video streaming environment a delay of several seconds is generally not considered an issue. From nsg7@cornell.edu Thu Apr 6 10:45:38 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k36Ejat29694 for ; Thu, 6 Apr 2006 10:45:37 -0400 (EDT) Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k36EjYTh014637 for ; Thu, 6 Apr 2006 10:45:34 -0400 (EDT) Received: from 132.236.227.119 by webmail.cornell.edu with HTTP; Thu, 6 Apr 2006 10:45:35 -0400 (EDT) Message-ID: <1798.132.236.227.119.1144334735.squirrel@webmail.cornell.edu> Date: Thu, 6 Apr 2006 10:45:35 -0400 (EDT) Subject: PAPER 19 From: "Nicholas S Gerner" To: egs+summary@cs.cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Overcast is a system supporting single-source multi-cast on an application overlay focussed on real-world deployment issues. The fundamental goal of Overcast is to easily deploy a system supporting high-bandwidth root-to leaf streams to very large numbers of standard webclients. To achieve this Overcast defines a tree construction and maintenance protocols. Combined these allow a client to contact the root of a multi-cast group which will the automatically select the best node for the client to connect to in order to receive the high-bandwidth stream. Tree construction is carried out by the root and "applicances" which are dedicated tree-internal nodes. These nodes start at the root and descend the tree as it is constructed to locate themselves as deep in the tree as possible while still maintaining high-bandwidth to the root. This is accomplished by testing the bandwidth from the root directly through the current parent (starting at the root), and the bandwidth achieveable from each sibling. If one of the siblings bandwidth to the root is within 10% of that through the current parent, the sibling with fewest hops from the node in question is selected as the new parent and the process repeats until no such sibling can be found. Tree maintenance is accomplished by having children periodically contact parents, grandparents and siblings (to find new parents if necessary). Nodes aggregate these heartbeats and send changes to their parents. This process recurses up the tree (always sending only the deltas) to the root so each node has a full view of the current membership of its subtree. When a client requests the stream it contacts the root via a standard HTTP URL, and the root redirects the client to the "best" appliance (by some metric) given the full view the root has. Overcast is aimed at large-scale, high-bandwidth applications and focusses on ease of deployment. Consideration of nodes behind firewalls are considered (for instance, parents never contact children which may be behind a firewall, and all communications are done over HTTP on port 80), the appliances are assumed to be dedicated machines and so a high churn environment is avoided, and the multi-cast is single-source. It seems that several important problems are left unaddressed. The tree-maintenance load on nodes is argued to be sub-linear in the size of the tree, however in some cases (such as a child of the root choosing a new parent) the load could be linear in the size of the sub-tree involved. This is shown in experimentation, although not the "common case". It also seems as if the bandwidth achieved after the tree is constructed could be very different from the bandwidth achieved during construction. If an internal node is the parent of many nodes its outbound bandwidth will be divided amongst those children and this could be a bottle neck. No discussion of how to avoid overloading nodes is made (although this may not be a problem given the parent selection algorithm). While the paper is aimed at high-bandwidth applications in real-world deployments, the experimentation presented is not of a real-world deployment and does not investigate the end-application bandwidth achieved by unmodified HTTP clients. From tc99@cornell.edu Thu Apr 6 11:01:10 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k36F1At03146 for ; Thu, 6 Apr 2006 11:01:10 -0400 (EDT) Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k36F17gD024994 for ; Thu, 6 Apr 2006 11:01:08 -0400 (EDT) Received: from 132.236.227.122 by webmail.cornell.edu with HTTP; Thu, 6 Apr 2006 11:01:09 -0400 (EDT) Message-ID: <1528.132.236.227.122.1144335669.squirrel@webmail.cornell.edu> Date: Thu, 6 Apr 2006 11:01:09 -0400 (EDT) Subject: paper 19 From: "Theodore Ming Shiuan Chao" To: egs@cs.cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Overcast is an application-level multicasting system that is layered on top of a network overlay. The goals of the authors was to create a scalable, reliable multicast system that can used for a variety of tasks and not just streaming. The authors used the generic multicast tree as a backbone, rendering the system as a single-source multicast, which the authors argue is sufficient for almost all purposes. The tree building protocol works by first comparing the new node to the root's children. If any of the children are suitable, it picks the most suitable one and goes down that brach and recurses, until it reaches a node that does not have any suitable children. Suitability for Overcast is determined by bandwidth. In order to deal with changes in state, Overcast nodes periodically reevaluate suitability with their sibilings and parent, and shifts position accordingly. Additionally, changes in position, whether because of suitability changes or node deaths, result in a propogation of change certificates up the tree to inform parents of the changes (since each parent must know about all of its descendants). The certificates are killed once they reach node that does not see the certificate as a change (ie. the node changed was already a descendent of it, and thus does not reflect a change from its point of view). One problem I noticed about Overcast is that in addition to the certificate race condition that is fixed by using sequence numbers, there seems to be a race condition with the changes themselves. Take two siblings that find that the other is suitable during the reevaluation period. The node that reconnects itself below the other would be dependent on which node notices it first, and it seems possible for each node to try to position itself below the other, resulting either in a failure or two nodes that both think the other one is its parent. The solution for this would simply be to go through the parent to make this change. The parent would then recognize that only one of the requests is valid and only approve one of the two. Another issue is that optimizing bandwidth means that the tree could become extremely unbalanced. Additionaly, I do not see the bandwidth optimization taking into account the number of links a node has since those links will be inactive during the entry phase of a new node with high probability. The bandwidth available to each link would not be accurately estimated until a new file is multicasted and the parent node tries to send it down all the links concurrently. From kelvinso@gmail.com Thu Apr 6 11:42:56 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from penguin.cs.cornell.edu (penguin.cs.cornell.edu [128.84.96.11]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k36Fgut12030 for ; Thu, 6 Apr 2006 11:42:56 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.235]) by penguin.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 11:42:56 -0400 Received: by wproxy.gmail.com with SMTP id 68so150879wra for ; Thu, 06 Apr 2006 08:42:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Mk2SUzctnVyD0pRwTSLsY7A5fEpZ9CEw3bqGfIDdLjJWSd9TLvR2PpbXJXj5qWp6Kf/kmUJP80a/O8IIhjJry6NCY5rioH7+b5R46nePztf2W8FUn0r1boZt7dX5TYWnIkYvuPwqV3D49E8BOV39/obM+tDgj6mfsTtKD1r/8E4= Received: by 10.54.158.9 with SMTP id g9mr2002980wre; Thu, 06 Apr 2006 05:47:05 -0700 (PDT) Received: by 10.54.78.8 with HTTP; Thu, 6 Apr 2006 05:47:05 -0700 (PDT) Message-ID: <6e1ca4560604060547t2ec36f27gf29481e92dac7f98@mail.gmail.com> Date: Thu, 6 Apr 2006 08:47:05 -0400 From: "Chiu Wah Kelvin So" To: egs+summary@cs.cornell.edu Subject: Paper 19 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 06 Apr 2006 15:42:56.0236 (UTC) FILETIME=[C63802C0:01C65990] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id k36Fgut12030 The paper, "Overcast: Reliable Multicasting with an Overlay Network," presents an application-level multicasting system for bandwidth-intensive content. Unlike IP multicast, which is difficult to deploy in real world, application-level multicast is easily and incrementally deployable. Also, it is adaptable, robust and customizable. The main protocol of the system is to build a single source multicast tree. To maximize bandwidth to the root for all nodes in tree construction, each node tries to locate the Overcast root. Then, the new node attempts to locate itself further down in the tree without sacrificing bandwidth to the root. It will also periodically reevaluate its position in the tree by measuring bandwidth with sibling, parent and grandparent, so it can adapt to network changes. Overcast nodes also need to keep track of all the aliveness status of the descendants using a Up/Down protocol. Each node periodically contacts its parent. If the parent doesn't receive the child contact within certain interval, the parent will assume the child and all the descendants to fail and send death certificates up the tree. Birth certificates are also issued when a new node joins. It also tries to replicate the root to avoid single point of failure. This system is designed to use as an infrastructure, so it is not designed to handle high rate of churn. Client doesn't participate in disseminating the data. It locates a closest overcast node to receive a multicast stream. Because this work is one of the first works in application-level multicasting, it doesn't address all the issues, such as scalability, churn, and efficiency. It doesn't scale well under intensive nodes joining the network because the nodes in the top level Overcast hierarchy need to handle large number of join requests. Also, when nodes fails, nodes will need to migrate to other part of the tree to continue receive the streaming. However, Bullet is more resilient to node departures since it can as well receive streaming from perpendicular peers. Second, Overcast doesn't utilize the client upload bandwidth to disseminate the data. SplitStream utilizes the leaf node upload bandwidth to improve efficiency by building multiple disseminating trees. From asg46@cornell.edu Thu Apr 6 11:59:16 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k36FxGt15258 for ; Thu, 6 Apr 2006 11:59:16 -0400 (EDT) Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k36FxEfj005147 for ; Thu, 6 Apr 2006 11:59:14 -0400 (EDT) Received: from 128.84.98.90 by webmail.cornell.edu with HTTP; Thu, 6 Apr 2006 11:59:15 -0400 (EDT) Message-ID: <2700.128.84.98.90.1144339155.squirrel@webmail.cornell.edu> Date: Thu, 6 Apr 2006 11:59:15 -0400 (EDT) Subject: paper 19 - OVERCAST From: "Abhishek Santosh Gupta" To: egs+summary@cs.cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal OVERCAST Overcast provides a scalable and reliable single-source multicast using an overlay network design. an overlay network consists of a collection of nodes placed at strategic locations in existing network fabric. pros of using an overlay network: 1) incrementally deployable - no change in existing Internet infrastructure, only additional servers 2) adaptable - packets can be made to flow over links which are optimized over metrics that matter to the application 3) robust - ability to route around faults immediately 4) customizable cons of using an overlay network: 1) management complexity 2) inefficient - cannot be as efficient as code running in every router 3) information loss due to the presence of firewalls,NATs must be prevented basic goals: 1) deployment must require little or no human intervention 2) costs per node must be minimized 3) unmodified HTTP clients must be able to join multicast groups basic idea: distribution trees are built for single-source multicasting and a "up/down" protocol is used to maintain global state of the network efficiently tree building protocol: a new node contacts the root and becomes its' child. this new node now adjusts its position in the tree by checking the bandwidth from its parent's children to it(from the root node). If the bandwidth available is about as high as the current bandwidth the node now becomes a child of this node (which was a child of its parent) 10K byte packets are used for this measurement - this gives better results than using ping packets when the reported bandwidth is within 10% of each other, the closer node is selected (according to traceroute) nodes also periodically recheck their decision to locate under their parent via packets to its parent,grandparent. this makes the design highly tolerant to failures. However, malicious nodes can choose to respond to these "up" messages but not forward actual data packets - thereby disrupting multicasting (cycles are also prevented while creating trees) UP/DOWN protocol this enables to keep track of alive nodes each node maintains a table of all other nodes in the hierarchy lower than itself. this table is stored on disk and cached in the memory of the node (although size of such tables should be linearly proportional to number of nodes in the system for nodes close to the root) node failures detected by failure to check in than by active probing. this protocols involves birth,death, extra-information certificates along with certificates propagated by a nodes's children(this requires a parent pointer) sequence numbers used to resolve conflicting certificates. robustness increased by replicating the root as a chain on the top. From asg46@cornell.edu Thu Apr 13 12:03:35 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from penguin.cs.cornell.edu (penguin.cs.cornell.edu [128.84.96.11]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.25) with ESMTP id k3DG3Z215422 for ; Thu, 13 Apr 2006 12:03:35 -0400 (EDT) Received: from postoffice10.mail.cornell.edu ([132.236.56.14]) by penguin.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 12:03:05 -0400 Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k3DG33Yw026282 for ; Thu, 13 Apr 2006 12:03:04 -0400 (EDT) Received: from 128.84.98.131 by webmail.cornell.edu with HTTP; Thu, 13 Apr 2006 12:03:04 -0400 (EDT) Message-ID: <3196.128.84.98.131.1144944184.squirrel@webmail.cornell.edu> Date: Thu, 13 Apr 2006 12:03:04 -0400 (EDT) Subject: paper 19 From: "Abhishek Santosh Gupta" To: egs+summary@cs.cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 13 Apr 2006 16:03:05.0296 (UTC) FILETIME=[BFC42D00:01C65F13] DIGITAL FOUNTAIN APPROACH a limitation of the current mirroring technology is that a user must choose a single mirror site from which to access the entire data. performance can be improved substantially if the users are able to download disjoint data (as far as possible) from multiple mirror sites in parallel. erasure codes are utilized for this purpose as this allows an initial file consisting of k packets to be encoded into n packets such that receiving any k of them can reconstruct the original file. CONSTRAINTS: bandwidth on the back-channel (i.e. client sending response to server) is extremely limited.thus, approaches based on renegotiation are not good as they require feedback from the client. ASSUMPTIONS: 1) set of paths from client to mirror sites are bottleneck disjoint TORNADO CODES: they tradeoff a small increase in decoding efficiency for a substantial decrease in decoding and encoding times. each server encodes the file using Tornado codes and then randomly permutes the packets before sending. This random permutation prevents (to a certain extent) duplicate packets at the client when it receives from multiple servers.the stretch factor ( n/k) is chosen sufficiently large so that cycling does not occur (i.e. receiving duplicate packets from server) duplicate packet recieval can be prevented by the client negotiating with each server. Requirements of an ideal protocol : minimize network traffic , reliable , efficient, on-demand , tolerant. the authors also suggest a layering scheme for multiple multicasts based on synchronization points. (the layers are ordered by increasing transmission rate) NETWORK CODING this approach allows intermediate nodes to encode packets. the authors point out that multiple copies of a packet may arrive repeatedly at the client through different paths. this is prevent using network encoding. content propagation : the algorithm to decide which block to transfer is based only on local information. the possible policies are : random block, local rarest. BASIC IDEA : each node picks a random set of co-efficients for all its blocks. each element of each block is multiplied with the corresponding co-efficient and all such results (for all blocks) are added together in a finite field. a node can recover the original file after receiving k blocks for which associated coefficient vectors are linearly independent to each other. the only time that a block is not useful is when the receiver has all blocks which were used to combine into the sent block. thus, each node must know its neighbors coefficients to determine if the block is "innovative" or not. incentive mechanisms can be used to prevent free-riding. BOTH THE SCHEMES DO NOT PREVENT MALICIOUS NODES FROM FORWARDING JUNK PACKETS AND THUS PROBABLY DESTROYING THE MULTICAST. detecting whether a node is malicious seems also very difficult. From gp72@cornell.edu Fri May 12 23:57:21 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from exchfe1.cs.cornell.edu (exchfe1.cs.cornell.edu [128.84.97.27]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.25) with ESMTP id k4D3vL207563 for ; Fri, 12 May 2006 23:57:21 -0400 (EDT) Received: from iago.cs.cornell.edu ([128.84.96.10]) by exchfe1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 23:55:24 -0400 Received: from postoffice10.mail.cornell.edu ([132.236.56.14]) by iago.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 23:55:20 -0400 Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k4D3tJeZ024271; Fri, 12 May 2006 23:55:19 -0400 (EDT) Received: from 128.84.98.245 by webmail.cornell.edu with HTTP; Fri, 12 May 2006 23:55:19 -0400 (EDT) Message-ID: <1157.128.84.98.245.1147492519.squirrel@webmail.cornell.edu> In-Reply-To: <4952.128.84.98.245.1147484280.squirrel@webmail.cornell.edu> References: <2537.128.84.98.245.1147406914.squirrel@webmail.cornell.edu> <3469.128.84.98.245.1147411785.squirrel@webmail.cornell.edu> <4952.128.84.98.245.1147484280.squirrel@webmail.cornell.edu> Date: Fri, 12 May 2006 23:55:19 -0400 (EDT) Subject: PAPER 19 From: "Gopal Parameswaran" To: egs+summary@cs.cornell.edu Cc: gp72@cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-OriginalArrivalTime: 13 May 2006 03:55:20.0799 (UTC) FILETIME=[0E172EF0:01C67641] Overcast: Overcast is a collection of nodes paced at strategic locations in a per to peer network to implement an abstraction over the existing network to provide a reliable and adaptable routing mechanism where the system’s functionality can be provided on an incremental basis. It attempts to reduce bandwidth requirements by replication. Overcast attempts to reduce the sending of same data over the same network multiple times to reduce the bandwidth requirements for multicast systems especially for broadcasting mediums for broadcasting large video files. Overcast builds distribution trees that to create high bandwidth channels from the source node to all nodes by building an adaptable distribution tree with a single root. When a user requests a particular video file that would be advertised at a common source such as a web page the requests gets redirected to a node that is at a close proximity and content is served from that node. However the system does not implement a breakup of the contents of the video file across servers but merely replicates the file. Thus if a particular node gets choked due to a sudden increase in requests from a region the system would be slow to react to the change and could fail. This implementation also assumes that the organization distributing networks would have its own set of nodes spread across the regions it provides service to. In other words it is more of a distributed load balancing protocol where each server handles the complete service for one particular request for a file. This paper really handles issues more with content distribution for service providers rather than for peer-to-peer systems since any node on a public network that is made into a distribution node just because it has a high bandwidth would resist the usage and would limit the applicability. This system does not utilize it resources properly because of the tree architecture and in the authors own words “If a child fails to contact its parents within a preset interval, the parent will assume the child and all of its descendants have died”. So if a set of immediate child nodes leaves he system the whole network would just disappear for that content being distributed. The authors claim that they chose the parents not to initiate contact with their children to enable it to cross firewalls easily. The author has not looked into other topologies such as a grid or a multi ring topology that are more stable to nodes being pulled out of the network. Finally the authors uses certificates for authenticity and availability of the child nodes but fails to consider the effect of a malignant node which might modify the contents of the file. Thus this application is limited to private networks whose nodes are spread across the Internet.