Introduction - Scalable Continuous Media Streaming Systems - page 7

Send data

Server

. . .

Client

Send req

Present data

Figure 1.4 Interaction between client and server under the download data delivery model

1.4 Streaming versus Download
Delivering data over a network is not new and there are many different methods already
available. Among them, download is the most common method to deliver data from a server to
a client. The download model, depicted in Figure 1.4, is relatively straightforward: the client
first sends a request to the server indicating the data object to be downloaded; the server then
retrieves the data object (e.g., from the local file system) and start sending it over the network
to the client using some application/transport protocol. Take the WWW as an example, the
web browser first sends a HTTP GET request using TCP to a web server, which then retrieves
the required file object and sends it back over the same TCP connection using a HTTP reply
message. After completely receiving the data object, the client (e.g., web browser) then decodes
and displays the data object to the user.
The key characteristic of the download model is that the data object is first completely
received, and possibly cached either in memory buffer or in the local file system, before being
decoded and played back. Clearly, as the complete data object is available to the client, the
decoding processing and presentation can be done in the same way as local data objects. This
download model works well in many applications but, unfortunately, is not very suitable for
continuous media data delivery.
Let us reconsider the download process as shown in Figure 1.5. Ignoring processing time, the
delay from the instant the user initiates the request to the instant the requested data object can
be presented is determined by the size of the data object and the rate at which it is transmitted
across the network. For applications such as WWW, the data objects are often text-based
HTML web pages or small images/graphics, and thus the delay is relatively small.
Continuous media data objects, however, will likely be significantly larger and thus the delay
incurred in downloading, say, a video object will become unacceptably long. Take MPEG2
video as an example. A 2-hour MPEG2 system stream (e.g., a movie) encoded at an average bit-
rate of 6Mbps will generate 5.4GB of data. Delivering this amount of data even over broadband
access networks, say, at 8Mbps, will take an unacceptably long time (e.g., 5.4GB × 8/8 =

1.5 hours) before playback can start.
The fundamental problem in the download model, as evident in Figure 1.6, is the re-
quirement to wait until the whole video object is downloaded before playback can begin.
While this requirement is necessary for many discrete media data types such as image or
graphic, continuous media such as video possess the unique characteristics that partial data