Overview of Multicast Streaming - Scalable Continuous Media Streaming Systems - page 291

data flow with its upstream counterparts and begin forwarding to the receiver a copy of the
data currently being multicast to the requested group address. A host can also join more than
one multicast group at the same time to receive data from multiple groups simultaneously.
Note that in IP multicast the data delivery model is many-to-many, i.e., any host can
send/receive data to/from the multicast group. Any data sent to the multicast group (i.e.,
with the multicast group address as the destination address in the IP packet header) will be
forwarded to all hosts that have joined the multicast group, including the sender itself. To leave
a multicast group, the application again can call an appropriate API function provided by the
operating system, which will stop forwarding data from the multicast group to the application.
Note that depending on the version of IGMP used [13, 14], the router may keep forwarding
multicast data to the host (which are then discarded by the operating system) for a period of
time until it discovers that the host no longer wants to receive data from the multicast group.
From the above discussions we can see that IP multicast involves processing at the appli-
cation, the operating system, and the routers. The implication is that the processing will take
some time to complete, depending on the implementation. For example, after the media client
calls an API function to join a multicast group, it will take some time for the operating system
and the network routers to set up the multicast dataflow and then forward the multicast packets
to the receiving host. Thus, when implementing a multicast streaming application, we will
need to take such processing delay into account in order to provide smooth and glitch-free
playback to the end user.
16.3 Multicast Media Streaming
Generally speaking, we can classifymulticast media streaming into three categories: broadcast-
ing, on-demand multicast streaming, and interactive multicast streaming. Media broadcasting
is similar to the terrestrial counterpart in that the objective is to deliver the media contents to
anyone who wants to receive the data subject to conditions set forth by the service provider
(e.g., subscription, geographical boundary, etc.).
In this broadcasting model the viewer can choose among the list of available media broad-
casting channels which channel to view and when to view. However, the user has no control
over the contents being broadcast in a channel and can only receive whatever is being broad-
cast in the channel. This is illustrated in Figure 16.4 where two clients join the same multicast
channel at different times. Client j having joined the multicast channel later will have missed
the content segment “A” and can only play back segment “B” and onwards. Moreover, like the
TV, the user cannot alter the playback schedule, such as jumping to a future playback point.
However, limited controls such as pause/resume or even rewinding to a previous playback
point (or time-shifted playback) can be made possible by storing in local storage (e.g., hard
disk) the media data that have already been played back.
In on-demand multicast streaming the user is allowed to choose when to begin playback of
the selected contents similar to unicast-based video-on-demand services. While this is common
in unicast-based streaming systems (also known as true-video-on-demand or TVoD), allowing
the users to choose their own playback schedule inherently conflicts with the nature of network
multicast (see Figure 16.5), where every user of the same multicast group receives the same
set of media data. Researchers have conducted many studies in recent years to address this
challenge, and some of the techniques will be presented in subsequent chapters.