Results 1 - 10
of
163
Bayeux: An architecture for scalable and fault-tolerant wide-area data dissemination
, 2001
"... The demand for streaming multimedia applications is growing at an incredible rate. In this paper, we propose Bayeux, an efficient application-level multicast system that scales to arbitrarily large receiver groups while tolerating failures in routers and network links. Bayeux also includes specific ..."
Abstract
-
Cited by 465 (12 self)
- Add to MetaCart
(Show Context)
The demand for streaming multimedia applications is growing at an incredible rate. In this paper, we propose Bayeux, an efficient application-level multicast system that scales to arbitrarily large receiver groups while tolerating failures in routers and network links. Bayeux also includes specific mechanisms for load-balancing across replicate root nodes and more efficient bandwidth consumption. Our simulation results indicate that Bayeux maintains these properties while keeping transmission overhead low. To achieve these properties, Bayeux leverages the architecture of Tapestry, a fault-tolerant, wide-area overlay routing and location network.
Internet Indirection Infrastructure
- In Proceedings of ACM SIGCOMM
, 2002
"... Attempts to generalize the Internet's point-to-point communication abstraction to provide services like multicast, anycast, and mobility have faced challenging technical problems and deployment barriers. To ease the deployment of such services, this paper proposes an overlay-based Internet Indi ..."
Abstract
-
Cited by 396 (26 self)
- Add to MetaCart
(Show Context)
Attempts to generalize the Internet's point-to-point communication abstraction to provide services like multicast, anycast, and mobility have faced challenging technical problems and deployment barriers. To ease the deployment of such services, this paper proposes an overlay-based Internet Indirection Infrastructure (i3) that offers a rendezvous-based communication abstraction. Instead of explicitly sending a packet to a destination, each packet is associated with an identifier; this identifier is then used by the receiver to obtain delivery of the packet. This level of indirection decouples the act of sending from the act of receiving, and allows i3 to efficiently support a wide variety of fundamental communication services. To demonstrate the feasibility of this approach, we have designed and built a prototype based on the Chord lookup protocol.
Efficient and Secure Source Authentication for Multicast
- In Network and Distributed System Security Symposium, NDSS ’01
, 2001
"... One of the main challenges of securing multicast communication is source authentication, or enabling receivers of multicast data to verify that the received data originated with the claimed source and was not modified enroute. The problem becomes more complex in common settings where other receivers ..."
Abstract
-
Cited by 273 (8 self)
- Add to MetaCart
One of the main challenges of securing multicast communication is source authentication, or enabling receivers of multicast data to verify that the received data originated with the claimed source and was not modified enroute. The problem becomes more complex in common settings where other receivers of the data are not trusted, and where lost packets are not retransmitted.
IP Multicast Channels: Express Support for Large-scale Single-source Applications
, 1999
"... In the IP multicast model, a set of hosts can be aggregated into a group of hosts with one address, to which any host can send. However, Internet TV, distance learning, file distribution and other emerging large-scale multicast applications strain the current realization of this model, which lacks a ..."
Abstract
-
Cited by 201 (4 self)
- Add to MetaCart
In the IP multicast model, a set of hosts can be aggregated into a group of hosts with one address, to which any host can send. However, Internet TV, distance learning, file distribution and other emerging large-scale multicast applications strain the current realization of this model, which lacks a basis for charging, lacks access control, and is difficult to scale. This paper proposes an extension to IP multicast to support the channel model of multicast and describes a specific realization called EXPlicitly REquested SingleSource (EXPRESS) multicast. In this model, a multicast channel has exactly one explicitly designated source, and zero or more channel subscribers. A single protocol supports both channel subscription and efficient collection of channel information such as subscriber count. We argue that EXPRESS addresses the aforementioned problems, justifying this multicast service model in the Internet.
High-Speed Policy-based Packet Forwarding Using Efficient Multi-dimensional Range Matching
- In ACM SIGCOMM
, 1998
"... The ability to provide differentiated services to users with widely varying requirements is becoming increasingly important, and Internet Service Providers would like to provide these differentiated services using the same shared network infrastructure. The key mechanism, that enables differentiatio ..."
Abstract
-
Cited by 172 (0 self)
- Add to MetaCart
(Show Context)
The ability to provide differentiated services to users with widely varying requirements is becoming increasingly important, and Internet Service Providers would like to provide these differentiated services using the same shared network infrastructure. The key mechanism, that enables differentiation in a connectionless network, is the packet classification function that parses the headers of the packets, and after determining their context, classifies them based on administrative policies or real-time reservation decisions. Packet classification, however, is a complex operation that can become the bottleneck in routers that try to support gigabit link capacities. Hence, many proposals for differentiated services only require classification at lower speed edge routers and also avoid classification based on multiple fields in the packet header even if it might be advantageous to service providers. In this paper, we present new packet classification schemes that, with a worst-case and tr...
The Evolution of Multicast: From the MBone to Inter-Domain Multicast to Internet2 Deployment
- IEEE NETWORK
, 2000
"... Without a doubt, multicast communication---the one-to-manyormany-to-many delivery of data---has become a hot topic. It is of interest in the research community, among standards groups, and to network service providers. For all the attention multicast has received, there are still issues that have ..."
Abstract
-
Cited by 160 (23 self)
- Add to MetaCart
Without a doubt, multicast communication---the one-to-manyormany-to-many delivery of data---has become a hot topic. It is of interest in the research community, among standards groups, and to network service providers. For all the attention multicast has received, there are still issues that have not been completely resolved. One result is that protocols are still evolving and some standards are not yet finished. From a deployment perspective, the lackof standards has slowed progress, but efforts to deploymulticast as an experimental service are in fact gaining momentum. The question nowishow long it will be before multicast becomes a true Internet service. The goal of this paper is to describe the past, present, and future of multicast.
A Survey on TCP-Friendly Congestion Control
- IEEE Network
, 2001
"... New trends in communication, in particular the deployment of multicast and real-time audio/video streaming applications, are likely to increase the percentage of non-TCP traffic in the Internet. These applications rarely perform congestion control in a TCP-friendly manner, i.e., they do not share th ..."
Abstract
-
Cited by 137 (1 self)
- Add to MetaCart
New trends in communication, in particular the deployment of multicast and real-time audio/video streaming applications, are likely to increase the percentage of non-TCP traffic in the Internet. These applications rarely perform congestion control in a TCP-friendly manner, i.e., they do not share the available bandwidth fairly with applications built on TCP, such as web browsers, FTP- or email-clients. The Internet community strongly fears that the current evolution could lead to a congestion collapse and starvation of TCP traffic. For this reason, TCP-friendly protocols are being developed that behave fairly with respect to co-existent TCP flows. In this article, we present a survey of current approaches to TCP-friendliness and discuss their characteristics. Both unicast and multicast congestion control protocols are examined, and an evaluation of the different approaches is presented.
Core based trees (CBT) multicast routing architecture
- IETF Request For Comments, RFC
, 1996
"... This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. CBT is a multicast routing architecture that builds a single delivery ..."
Abstract
-
Cited by 130 (0 self)
- Add to MetaCart
(Show Context)
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group’s senders and receivers. Most multicast algorithms build one multicast tree per sender (subnetwork), the tree being rooted at the sender’s subnetwork. The primary advantage of the shared tree approach is that it typically offers more favourable scaling characteristics than all other multicast algorithms. The CBT protocol [1] is a network layer multicast routing protocol that builds and maintains a shared delivery tree for a multicast group. The sending and receiving of multicast data by hosts on a
REUNITE: A Recursive Unicast Approach to Multicast
- IN PROCEEDINGS OF IEEE INFOCOM’00, TEL AVIV
, 1999
"... We propose a new multicast protocol called REUNITE. The key idea of REUNITE is to use recursive unicast trees to implement multicast service. REUNITE does not use class D IP addresses. Instead, both group identification and data forwarding are based on unicast IP addresses. Compared with existing IP ..."
Abstract
-
Cited by 110 (2 self)
- Add to MetaCart
We propose a new multicast protocol called REUNITE. The key idea of REUNITE is to use recursive unicast trees to implement multicast service. REUNITE does not use class D IP addresses. Instead, both group identification and data forwarding are based on unicast IP addresses. Compared with existing IP multicast protocols, REUNITE has several unique properties. First, only routers that are acting as multicast tree branching points for a group need to keep multicast forwarding state of the group. All other non-branching-point routers simply forward data packets by unicast routing. In addition, REUNITE can be incrementally deployed in the sense that it works even if only a subset of the routers implement the protocol. Furthermore, REUNITE supports load balancing and graceful degradation such that when a router does not have resources (forwarding table entry, buffer space, processing power) to support additional multicast groups, the branching can be automatically migrated to other less load...
Administratively scoped IP multicast
- IETF RFC 2365. http://www.faqs.org/rfcs/rfc2365.html
, 1998
"... This document specifies an Internet Best Current Practice for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Internet Drafts This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineerin ..."
Abstract
-
Cited by 93 (4 self)
- Add to MetaCart
This document specifies an Internet Best Current Practice for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Internet Drafts This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ‘‘work in progress.’’ To learn the current status of any Internet-Draft, please check the ‘‘1id-abstracts.txt’ ’ listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document defines the "administratively scoped IP multicast space " to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of
