The convergence of advances in storage, encoding, and networking technologies has brought us to an environment where huge amounts of continuous media content is routinely stored and exchanged between network enabled devices. Keeping track of (or managing) such content remains challenging due to the sheer volume of data. Storing "live" continuous media (such as TV or radio content) adds to the complexity in that this content has no well defined start or end and is therefore cumbersome to deal with. Networked storage allows content that is logically viewed as part of the same collection to in fact be distributed across a network, making the task of content management all but impossible to deal with without a content management system. In this paper we present the design and implementation of the Spectrum content management system, which deals with rich media content effectively in this environment.Spectrum has a modular architecture that allows its application to both stand- alone and various networked scenarios. A unique aspect of Spectrum is that it requires one (or more) retention policies to apply to every piece of content that is stored in the system. This means that there are no eviction policies. Content that no longer has a retention policy applied to it is simply removed from the system. Different retention policies can easily be applied to the same content thus naturally facilitating sharing without duplication. This approach also allows Spectrum to easily apply time based policies which are basic building blocks required to deal with the storage of live continuous media, to content. We not only describe the details of the Spectrum architecture but also give typical use cases.

Abstract Multicast services have been used to transmit multimedia data to large receiver groups. Only recently have counterpart network services been introduced to provide similar scalability and anonymity in the opposite direction (i.e. messages from a group of senders destined for a common receiver). In this paper, we explore how these many‐to‐one services, specifically the concast service, can be used to improve the scalability and performance of multimedia applications. In particular, we show how such services can be used in both the control and data planes to overcome well‐known scalability problems (e.g. with Real Time Protocol) that are difficult to solve effectively with end‐system approaches alone. We validate our solutions by presenting experimental results taken from prototype video and audio applications we designed and implemented. Our initial results show substantial reductions in congestion‐induced loss using these generic services. Copyright © 2003 John Wiley & Sons, Ltd.

Multicast services have been used for many years to transmit multimedia data to large receiver groups. However, only recently have counterpart network services been introduced that provide similar scalability and anonymity in the opposite direction (i.e., messages from a group of senders destined for a common receiver). In this paper, we explore how these emerging services, specifically a concast service (many-to-one communication service), can be used to improve the scalability and performance of multimedia applications. In particular, we show how such services can be used in both the control and data planes to overcome well-known scalability problems (e.g., with RTP) that are difficult to solve effectively with end-system approaches alone. We validate our solutions by presenting experimental results taken from prototype video and audio applications we designed and implemented. Our initial results show a reduction of as much as two orders of magnitude in packet loss rates using these generic services.

Concast is a network layer service that provides many-to-one channels: multiple sources send messages toward one destination, and the network delivers a single "merged" copy to that destination. As we have defined it, the service is generic but the relationship between the sent and received messages can be customized for particular applications. We describe the concast service and show how it can be implemented in a back ward-compatible manner in the Internet. We describe its use to solve a problem that has eluded scalable end-system-only solutions: collecting feedback in multicast applications. Our preliminary analysis of concasting effectiveness shows that it provides significant benefits, even with partial deployment. We argue that concast has the characteristics needed for a programmable service to be widely accepted and deployed in the Internet.

Concast is a scalable "inverse-multicast" network service: messages sent from multiple sources toward the same destination are merged into a single message that is delivered to the destination. The mapping from sent messages to received messages is programmable, so the service can be tailored to the needs of specific applications. However the service can also be used as a building block for other generic network services, such as a packet multiplexing service that encapsulates multiple small packets into a single larger packet and then unencapsulates the small packets at their (common) destination. Such a service offers several potential benefits, including reduced packet processing overhead and increased rate-sharing, but must also be carefully designed to avoid problems caused by added packet delays. We show how concast can serve as the basis for a multiplexing service that can be tailored to the needs of the application. We present simulation results showing that the benefits of our multiplexing service vary with delay. We also show that given certain queue-manipulation capabilities, benefits can be achieved with zero added delay.

This paper introduces concast, a new network service. Concast is the inverse of multicast: multiple sources send messages toward the same destination, which results in a single message being delivered to the destination. The received message appears to come from the concast group rather than any particular receiver. Different forms of concast service can be defined by varying the mapping from the set of sent messages to the received message. The service is useful for preventing implosion and reducing bandwidth consumption in cases where many senders transmit to the same receiver-for example in aggregating (or suppressing) positive (or negative) acknowledgements. We define the semantics of a simple concast service that is the inverse of multicast, as well as a more general custom concast, which allows users to define certain aspects of the service's semantics. We describe how to implement the service so that it scales approximately as well as IP multicast. We also present results from a simulation study showing that concast provides significant benefits in a layered-video application.