Chapter 32: Design and Development of a Scalable End-to-End Streaming Architecture


Cyrus Shahabi and Roger Zimmermann
Integrated Media Systems Centre
Department of Computer Science
University of Southern California
Los Angeles, California 90089-0781
[Shahabi,rzimmerm]@usc.edu

1. Introduction

In this chapter, we report on the design, implementation and evaluation of a scalable real-time streaming architecture that would enable applications such as news-on-demand, distance learning, e-commerce, corporate training and scientific visualization on a large scale. A growing number of applications store, maintain and retrieve large volumes of real-time data, where the data are required to be available online. We denote these data types collectively as "continuous media," or CM for short. Continuous media is distinguished from traditional textual and record-based media in two ways. First, the retrieval and display of continuous media are subject to real-time constraints. If the real-time constraints are not satisfied, the display may suffer from disruptions and delays termed hiccups. Second, continuous media objects are large in size. A two-hour MPEG-2 video with a 4 Megabit per second (Mb/s) bandwidth requirement is 3.6 Gigabytes (GB) in size. Popular examples of CM are video and audio objects, while less familiar examples are haptic, avatar and application coordination data [26].

The first research papers on the design of continuous media servers appeared about a decade ago (e.g. [1, 23]), followed by many papers on this topic during the past decade (here is an example for every year [7, 24, 6, 5, 4, 22, 33, 12, 16, 18, 40]). Our research during this past decade started in early 90's [9] and continued through 2002 [11]. Some of the projects described in these papers resulted in prototype servers, such as Streaming-RAID [35], Oracle Media Server [17], UMN system [15], Tiger [2], Fellini [19], Mitra [13] and RIO [20]. These first generation continuous media servers were primarily focused on the design of different data placement paradigms, buffer management mechanisms and retrieval scheduling techniques to optimize for throughput and/or startup latency time.

There are two major shortcomings with these research prototypes. First, since they were implemented concurrently during the same time frame, each one of them could not take advantage of the findings and proposed techniques of the other projects. For example, UMN, Fellini and Mitra independently proposed a seemingly identical design for their data placement technique based on round-robin assignments of blocks to disk clusters. While this approach was already superior in throughput to RAID striping (used by Streaming-RAID), it resulted in a higher worst case startup latency time. In contrast, RIO's data placement, which is based on random block assignment, is more flexible and results in the same throughput as round-robin with a shorter expected startup latency time. On the other hand, UMN's simple scheduling policy resulted in a good performance without complicating the code as opposed to the constrained scheduling policies of Mitra (round-robin), Fellini (cycle-based) and RIO (round-based). We extended UMN's scheduling (to deadline-driven) and adapted the disk cluster (in Mitra's and Fellini's terms) or logical volume striping (in UMN's vocabulary) storage design. We extended RIO's random data placement (to pseudo-random placement for easier bookkeeping and storage scale-up) and instead of the expensive shared-memory architecture of UMN (based on SGI's Onyx), we employed a shared-nothing approach on commodity personal computer hardware.

The second shortcoming is that almost all of these research prototypes were completed before the industry's standardizations for streaming continuous media over the IP networks. Hence, each prototype has its own proprietary media content format, client (and codec) implementation and communication/network protocol. As a matter of fact, some of these prototypes did not even focus on these aspects and never reported on their assumed network and client configurations. They mainly assumed a very fast network with constant-bit-rate media types in their corresponding research publications. Practically, these environment assumptions and the specific content type are not realistic.

Several commercial implementations of continuous media servers are now available in the marketplace. We group them into two broad categories: 1) single-node, consumer oriented systems (e.g., low-cost systems serving a limited number of users) and 2) multi-node, professional oriented systems (e.g., high-end broadcasting and dedicated video-on-demand systems). Table 32.1 lists some examples for both types. RealNetworks, Apple Computer and Microsoft product offerings fit into the first category, while SeaChange and nCUBE offer solutions that are oriented towards the second category. Table 32.1 is a non-exhaustive list summarizing some of the more popular and recognizable industry products.

Table 32.1: A comparison of continuous-media servers. Note that Yima is a prototype system and does not achieve the refinement of the commercial solutions. However, we use it to demonstrate several advanced concepts.

Video Server

Yima

RealNetworks, Microsoft, Apple QuickTime

SeaChange

nCUBE

Prototype

Consumer Level

Professional Level

Authoring Suite

Yes

Yes

Yes

MPEG-1 & 2

Yes

Yes[a]

Yes

Yes

MPEG-4

Yes

Yes[b]

Yes

?

HDTV MPEG-2

Yes

?

?

Multi-node Clusters

Yes

Yes

Yes

Multi-node Fault-tolerance[c]

Yes

Yes

Yes

Synchronized streams[d]

Yes

Selective Retransmissions

Yes

Yes

?

?

Hardware

Commodity PC

Commodity PC

Commodity PC

Proprietary Hypercube

Software

Linux

Windows NT / Mac[e]

Windows NT

Proprietary

[a]These systems support many other codecs that are commonly used in PC/Mac environments.

[b]Supported in Windows Media Player.

[c]Multi-node Fault-Tolerance is defined as the capability of one node taking over from another node without replicating the data.

[d]By synchronized streams we mean the simultaneous playback of multiple independent audio and video streams for, say, panoramic systems.

[e]RealSystem Producer products are also available for several Unix variants.

Commercial systems often use proprietary technology and algorithms; therefore, their design choices and development details are not publicly available and objective comparisons are difficult to achieve. [2] Because these details are not known, it is also unclear as to how much research resulting from academic work have been incorporated into these systems. For example, although a good body of work has been developed on how to configure a video server (e.g., block size, number of disks) given an application's requirements (e.g., tolerable latency, required throughput), as reviewed in [10], there is no indication that any of the commercial products utilize these results. However, those details that we are aware of are referred to throughout this chapter when comparing them with our design choices.

In this chapter we report on our streaming media architecture called Yima. [3] The focus of our implementation has been on providing a high-performance, scalable system that incorporates the latest research results and is fully compatible with open industry standards.

Specifically, some of the features of the Yima architecture are as follows. It is designed as a completely distributed system (with no single point of failure or bottleneck) on a multi-node, multi-disk platform. It separates physical disks (used to store the data) from the concept of logical disks (used for retrieval scheduling) to support fault tolerance [39] and heterogeneous disk subsystems [4] [38]. Data blocks are pseudo-randomly placed on all nodes and the non-deterministic scheduling is performed locally on each node. Yima includes a method to reorganize data blocks in real-time for online adding/removing disk drives [11] (Sec. 4). Also included are a flexible rate-control mechanism between clients and the server to support both variable and constant bit rate media types (see Sec. 3) as well as optimization techniques such as Super-streaming [25]. There are also techniques to resolve stream contentions at the server for ensuring inter-stream synchronization as proposed in [28].

Yima follows open industry standards as proposed by the Internet Streaming Media Alliance (ISMA; www.ism-alliance.org). Content-wise, Yima supports the MPEG-4 file format, MP4, and can stream MPEG-1, MPEG-2, MPEG-4 and Quicktime video formats. It supports the RTP and RTSP communication standards for IP based networks. The clients can be off-the-shelf QuickTime players as well as our own proprietary clients [34] that handle advanced multichannel audio and video playback and HDTV displays. Although our proprietary clients can support specialized playback of multiple media types, they still follow communication and format standards.

A general description of Yima server and its various clients are provided in [34]. In that paper, we also compared our initial architectural design with the new fully distributed design. In [36] we reported on our experiments in streaming MPEG-4 content from a Yima server located at the USC's campus to a residential location connected via ADSL [36]. In [11], we proposed alternative schemes to redistribute media blocks when disks are added to or removed from the Yima server. These schemes were then compared via a simulation study.

In this chapter, however, we describe the details of our fully distributed architecture and report on several experiments we conducted in real-world settings. We show when different components of a node (i.e., CPU, network and disk) become a bottleneck. We have also implemented the superior redistribution scheme of [11], Randomized SCADDAR, in Yima and evaluated it in these real-world settings. Finally, we describe our novel client-controlled transmission rate smoothing protocol and explain its implementation in Yima. Several experiments have also been conducted to evaluate our smoothing protocol.

The remainder of this chapter is organized as follows. After describing the overall system architecture in Sec. 2 we will elaborate in greater detail on three innovative aspects of Yima: 1) a client-controlled transmission rate smoothing protocol to support variable bit rate media (Sec. 3), 2) efficient online scalability of storage where disks can be added or removed without stream interruption (Sec. 4) and 3) the scalable multi-node architecture with independent, local scheduling and data transmission (Sec. 5). Finally, in Sec. 6, we summarize this chapter and lay out our future plans in this area.

[1]This research has been funded in part by NSF grants EEC-9529152 (IMSC ERC) and IIS-0082826, and unrestricted cash gifts from NCR, Microsoft and Okawa Foundation.

[2]One notable exception is Apple Computer, Inc., which has published the source code of its Darwin Streaming Server.

[3]Yima in ancient Iranian religion is the first man, the progenitor of the human race and son of the sun.

[4]Note that our concept of logical disks is very different from the concept of logical volume striping used in the UMN system.




Handbook of Video Databases. Design and Applications
Handbook of Video Databases: Design and Applications (Internet and Communications)
ISBN: 084937006X
EAN: 2147483647
Year: 2003
Pages: 393

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net