A case for end system multicast (keynote address)

Abstract

The conventional wisdom has been that IP is the natural protocol layer for implementing multicast related functionality. However, ten years after its initial proposal, IP Multicast is still plagued with concerns pertaining to scalability, network management, deployment and support for higher layer functionality such as error, flow and congestion control. In this paper, we explore an alternative architecture for small and sparse groups, where end systems implement all multicast related functionality including membership management and packet replication. We call such a scheme End System Multicast. This shifting of multicast support from routers to end systems has the potential to address most problems associated with IP Multicast. However, the key concern is the performance penalty associated with such a model. In particular, End System Multicast introduces duplicate packets on physical links and incurs larger end-to-end delay than IP Multicast. In this paper, we study this question in the context of the Narada protocol. In Narada, end systems self-organize into an overlay structure using a fully distributed protocol. In addition, Narada attempts to optimize the efficiency of the overlay based on end-to-end measurements. We present details of Narada and evaluate it using both simulation and Internet experiments. Preliminary results are encouraging. In most simulations and Internet experiments, the delay and bandwidth penalty are low. We believe the potential benefits of repartitioning multicast functionality between end systems and routers significantly outweigh the performance penalty incurred.

Enabling broadcast of user-generated live video without servers

“…In tree-based approach (such as ESM [6]), peers form multiple multicast trees in application level and relay traffic as interior nodes. The multiple trees are optimized further in terms of peer bandwidth, peer load and latency in SplitStream [7] and Chunkyspread [8].…”

Brocade: Landmark Routing on Overlay Networks

“…We use as our key metric a modified version of Relative Delay Penalty (RDP) [1]. Our modified RDP attempts to account for the processing of an overlay message up and down the protocol stack by adding 1 hop unit to each overlay node traversed.…”

Large-Scale Service Overlay Networking with Distance-Based Clustering

“…However, under such an overlay topology consideration, routing information distribution cost becomes unfeasibly high for a large overlay network, because each proxy would have n − 1 neighbors. A more scalable way is to consider the overlay network as a mesh [1,4,5,6]. However, static mesh configurations do not take the service dependency issue, which is mostly resolved at execution time, into consideration.…”

“…However, most of the existing work, such as [1,2,3,4,5,6], targets at small-or medium-scale overlay networks, as the constructed overlay topologies are mostly meshes of single level.…”

“…(1) While at the network layer, clusters are defined manually by humans based on certain properties of the network (e.g., location, administrative domain, or connectivity), an overlay service network has a virtual, fully-connected topology 1 . Hence the first problem is how to identify virtual clusters and how to define connectivity between nodes and clusters.…”