Open-Loop Algorithms - Scalable Continuous Media Streaming Systems - page 327

switch. The media server sends each of the channel or (group of channels in GCB) in CB/GCB
using UDP over a separate IP multicast address. Each media packet carries 1,400 bytes of
MPEG-1 compressed video data and an 8-byte header comprising sequence number. The packet
size is chosen to match Ethernet's maximum frame size to prevent datagram fragmentation.
To begin a media streaming session, the media client software joins the corresponding
multicast groups as defined by the CB/GCB algorithm by sending out an IGMP Join Group
requests. The IGMP request will be handled by the network switch and thus has no effect on
the video server. Upon receiving the IGMP request the network switch will begin forwarding
to the client packets of the requested multicast group. The client then re-sequences the received
packets based on the sequence number embedded in the packet header. Once a media segment
is completely received, the client will send an IGMP Leave Group request to the network
switch, which then stops the forwarding of data belonging to the requested multicast group.

18.7.1 Practical Issues
Implementing the system prototype reveals a number of practical issues not found in the
theoretical model. First, the time in joining and leaving an IP multicast group is not precise
but subject to delay variations in packet transmission and request processing. In joining a
multicast group, the client may experience a small delay before data packets of the media
segment are received. In a small local area network such as our experimental test-bed, the
channel switching latency is in the order of 10 − 3 seconds. Given that the client has buffered
media segment L 0 comprising multiple seconds of media data before commencing playback,
this channel switching delay can readily be absorbed. For a larger network that involves
multicast routing, the channel switching delay will be larger and thus extra measures (e.g.,
increasing the amount of prefetch data before playback commence) may be needed to prevent
playback starvation during channel switching.
Similarly, the client may not be able to leave a multicast group immediately after receiving
a media segment, and thus additional duplicate data packets may continue to arrive at the
receiver. The client can detect and discard these duplicate packets. Alternatively, the client can
simply process them normally as there is no harm overwriting existing data with the same data.
However, these duplicate data do incur additional bandwidth usage at the client access link.
Another aspect where the implementation deviates from the theoretical model is in data
transmission. Specifically, we have thus far modeled the transmission of media data as a
continuous bit-stream, i.e., using a fluid-flow like model. In practice, the server must packetize
media data into discrete UDP datagrams for transmission. In our implementation, we use
a datagram size of 1,408 bytes (1,400-byte video data plus 8-byte header) excluding UDP
and IP headers. Thus, with a configuration of N

1,000 in our experiments, the inter-packet
transmission time can vary from the order of 10 − 2 seconds (e.g., 0.02 seconds) to a few seconds
(e.g., 5.7 seconds) depending on the broadcast duration.
Our experiments show that the large deviations in the inter-packet transmission time can
result in substantial variations (

=

20% bit-rate variation averaged over a 1 second interval) in
the bit-rate of the aggregate network traffic. We tackle this problem in GCB by combining
all the media segments within the same group into a single data block, and then perform
packetization for the combined data block instead of individually packetizing each media
segment for transmission. Our experiments show that this can reduce the bandwidth variation

∼