Media Data Streaming - Scalable Continuous Media Streaming Systems - page 112

Protocol
Processing

Protocol
Processing

Buffer

Buffer

TCP Display

Decoder

TCP

Media
Data

IP

IP

MAC/DataLink

Networ

Network

MAC/DataLink

Media Server

Media Client

Figure 6.1 Media streaming over the Transmission Control Protocol (TCP)

rate, then streamingmedia data over TCPwill likelyworkwell. In fact, manyweb portals simply
host media contents using ordinary web servers. Thus, when the client application requests
the media content using the Hyper-Text Transfer Protocol (HTTP) [6], the web server simply
sends back the media content over HTTP, which in turn makes use of TCP for data delivery.
In this case the web server does not explicitly stream the media content as it simply sends
the media object as fast as TCP will allow, regardless of the media object's intrinsic data rate.
The client application after receiving certain amount of data often can begin playback without
waiting for the whole media object to be completely received. As long as the media data flow
can keep up with the playback data rate, the end result is very much like streaming.
Streaming over HTTP/TCP has many obvious advantages. First, since the web server is used
to serve media contents, the service provider will not need to invest in expensive specialized
media servers. Second, deployment is simplified as the traffic is treated in the same way as
ordinary web traffic, thus enabling them to transparently traverse firewalls and gateways. Third,
the wide support for HTTP enhances compatibility with the client applications. Most media
player software supports pseudo-streaming over HTTP/TCP protocol in addition to their own
proprietary streaming protocols.
The downside of HTTP/TCP streaming, however, is in performance. At the application level,
the web server is not designed to deliver time-sensitive media data and thus it may not always be
able to sustain a smooth and jitter-freemedia playback, e.g., when theweb server load is high. At
the transport level, TCP's features have been developed for generic applications and thus have
no provision for time-sensitive and bandwidth-sensitive applications such as streaming media.
For example, TCP's congestion control algorithm ramps up the transmission speed slowly
after connection set-up (i.e., the slow-start algorithm), regardless of the bandwidth demand
of the application [3, 4]. Moreover, the error control feature in TCP enforces correct and in-
sequence data delivery. This means that if a TCP segment is lost, the TCP sender will simply
keep retransmitting the lost segment until either an acknowledgement is received from the
TCP receiver (see Figure 6.2) or it gives up trying and shuts down the connection. In a media
streaming application this may not always be desirable as media data have intrinsic timing
information, i.e., they have to be played back at a certain time or the data will become useless.
Consequently, if the retransmitted data arrive after the playback deadline, the data will no
longer be useful and are discarded by the receiver. In this case the bandwidth consumed in
retransmitting the data is simply wasted.
Worst still, TCP's congestion control algorithm will interpret packet loss as an indication
of network congestion and thus throttle back its transmission rate by means of reducing the
congestionwindow size [3, 4]. This could end up stalling the sender from sending anymore data