# A Stream Tapping Protocol Involving Clients in the Distribution of Videos on Demand

Authors: Santosh Kulkarni; Jehan-François Pâris; Purvi Shah
Journal: Advances in Multimedia
 (2008)

---

## Abstract

We present a stream tapping protocol that involves clients in the video distribution process.  As in conventional stream tapping, our protocol allows new clients to tap the most recent broadcast of the video they are watching. While conventional stream tapping required the server to send to these clients the part of the video they missed, our protocol delegates this task to the clients that are already watching the video, thus greatly reducing the workload of the server.  Unlike previous solutions involving clients in the video distribution process, our protocol works with clients that can only upload video data at a fraction of the video consumption rate and includes a mechanism to control its network bandwidth consumption.


---

## Body

## 1. Introduction

Distributing videos on demand is a
costly proposition, mostly because of the high bandwidth requirements of the
service. Assuming that the videos are in MPEG-2 format, each user request will
require the delivery of approximately six megabits of data per second Hence, a video server allocating a separate
stream of data to each request would need an aggregate bandwidth of six
gigabits per second to accommodate one thousand overlapping requests.This situation
has led to numerous proposals aimed at reducing the bandwidth requirements of
VOD services. These proposals can be
broadly classified into two groups
Proposals in the first group are said to beproactive because they distribute each video according to a fixed
schedule that is not affected by the presence—or the absence—of requests for
that video. They are also known as broadcasting protocols. Other solutions are purely reactive:
they only transmit data in response to a specific customer request. Unlike proactive protocols, reactive
protocols do not consume bandwidth in the absence of customer requests.Nearly all these
proposals assume a clear separation of functions between the server, which
distributes the video and the customers, who watch it on their personal
computers or on their television sets. As a result, they cannot take advantage
of the upstream bandwidth of the clients to lower the server’s workload.The stream
tapping protocol we present here is the first protocol that can harness the
collective bandwidth of clients with limited individual upstream
bandwidths As in conventional stream
tapping, our protocol requires the server to start a new video broadcast
whenever a client cannot get enough video data by “tapping” a previous
broadcast of the same video. Unlike
conventional stream tapping, our protocol uses the available upstream bandwidth
of previous clients to reduce the amount of video data that the server will
still have to send to the clients that “tap” a previous broadcast of the
video As we will see, delegating these
tasks to the clients results in a dramatic reduction of the server workload at
medium to high request arrival rates.The remainder of
this paper is organized as follows
Section2 reviews previous work
Section 3 introduces our stream tapping protocol Section 4 discusses its performance and shows
how we can limit the network bandwidth consumption of the protocol at high
arrival rates Section 5 presents a
simple probabilistic model of our protocol and Section 6 discusses its
applicability to actual networks
Finally, Section 7 has our conclusions


## 2. Previous Work

Two of the earliest reactive
distribution protocols are batching and piggybacking.Batching [1] reduces the bandwidth requirements of individual user requests by
multicasting one single data stream to all customers who request the same video
at the same time. Piggybacking [2]
adjusts the display rates of overlapping requests for the same video until
their corresponding data streams can be merged into a single stream Consider, for instance, two requests for the
same video separated by a time interval of three minutes. Increasing the
display rate of the second stream by 10 percent will allow it to catch up with
the first stream after 30 minutes.Chaining [3]
was the first video distribution protocol to take advantage of the upstream
bandwidth of its clients It constructs
chains of clients such that (a) the first client in the chain receives its data
from the server, and (b) subsequent clients receive their data from their
immediate predecessor As a result,
video data are “pipelined” through the clients belonging to the same chain. Since
chaining only requires clients to have very small data buffers, a new chain has
to be restarted every time the time interval between two successive clients
exceeds the capacity β of the buffer of the first client Figure 1
shows three sample client requests
Since client a is the first
customer, it will get all its data from the server As client b
arrives less than β minutes after customer a, it can receive all its data
from client a Finally, client c arrives more than β
minutes after client a and must be serviced directly by the server. Optimized
chaining [4] exploits
the buffers of other clients in order to construct longer chains and reduce the
server workload.Figure 1
How chaining works.The cooperative
video distribution protocol [5] extends the chaining protocol by taking
advantage of the larger buffer sizes of modern clients Hence, it should be better named extended
chaining If all clients have
buffers large enough to store the entire video, the server will never have to
transmit video data at more than the video consumption rate.Stream tapping [6, 7], also known
as patching [8], requires each client set-top box to have a buffer
capable of storing at least 10 to 15 minutes of video data and to be able to
receive data at at least twice the video consumption rate This buffer will allow the set-top box to
“tap” into data streams that were originally created for previous clients, and
then store these data until they are needed
In the best case, clients obtain most of their data from an existing
stream.In particular,
stream tapping defines two types of streams.Complete streams broadcast a
video in its entirety. Full tap streams can be used if a
complete stream for the same video started β≤ b minutes in the past, where b is the size of the client buffer, measured in minutes of video
data. In this case, the client begins receiving the complete stream right away,
storing the data in its buffer
Simultaneously, it receives
a full tap stream and uses it to display the first Δ minutes
of the video. After that, the client will consume directly from its
buffer Stream tapping also defines partial tap streams, which can be used
when Δ>β. In this case, clients must go through cycles of
filling up and then emptying their buffer, since the buffer is not large enough
to account for the complete difference in video position.To use tap streams, clients need only receive at
most two streams at any one time. Clients that
can receive data at three times the video consumption rate can use an option of the protocol calledextra tapping. Extra tapping allows
clients to tap data from any stream on the VOD server, and not just from
complete streams. Figure 2 shows some samples of client
requests As client a is the first client, it is serviced by a complete stream, whose
duration is equal to the duration D of
the video. Since client b arrives  Δt minutes
after client a, it can share D−Δt minutes of
the complete stream and only requires a full tap of duration Δt minutes Finally, customer c can use extra tapping to tap data from both the complete stream
and the previous full tap, and so its service time is smaller than Δc.Figure 2
How stream tapping works.Eager and Vernon'sdynamic skyscraper broadcasting (DSB)
[9] is another reactive protocol based on Hua and Sheu’s skyscraper broadcasting protocol [10, 11] Like skyscraper broadcasting, it
never requires the STB to receive more than two streams at the same time Their
more recent hierarchical multicast stream
merging (HMSM) protocol requires less server bandwidth than DSB to
handle the same request arrival rate [12]
Its bandwidth requirements are indeed very close to the upper bound of
the minimum bandwidth for a reactive protocol that does not require the STB to
receive more than two streams at the same time, that is,(1)η2ln⁡(1+Niη2), where η2=(1+5)/2, and Ni is the request arrival rate.Selective catching [13] combines both
reactive and proactive approaches. It dedicates a certain number of channels
for periodic broadcasts of videos, while using the other channels to allow incoming
requests to catch up with the current broadcast cycle. As a result, its
bandwidth requirements are O(log⁡(λıLi)), where λı is the request arrival rate and Lı the duration of the video.


## 3. Our Protocol

Both chaining and the cooperative
protocol require clients capable of sending video data at the video consumption
rate As a result, they exclude clients
that have limited upstream bandwidths, say, no more than one eighth to one
fourth of their downstream bandwidths
While these clients might be able to download video data at twice their
video consumption rate, they might only be able to forward video data at one fourth
to one half of that rate.We wanted to
develop a video distribution protocol that allowed clients to participate in
the video distribution process even if they could only retransmit data at a
fraction of the video consumption rate [14]
We thus assumed the
following:(1)
clients would be able to receive
video data at twic their video
consumption rate,(2)
clients would only be able to
forward video data at a rate equal to a fractionα of the same video consumption rate,(3)
clients would not be able to
multicast video data,(4)
clients would not have to forward
video data after they have finished watching that video,(5)
clients should have enough buffer
space to store the previously viewed portion of the video they are watching
until they have finished watching it.As we can see,
our protocol makes few demands on the transmission capabilities of the client
hardware In contrast, it requires
client buffers capable of storing an entire video, that is, several gigabytes
of compressed video data Two factors motivated
this choice First, the diminishing cost
of every kind of storage makes this requirement less onerous today than it
would have been a few years ago Second,
we expected many clients to keep the previously viewed portion of the video
they are watching in their buffers in order to provide the equivalent of a VCR
rewind feature.Our protocol is a fairly straightforward
implementation of stream tapping without extra tapping as extra tapping would
have required clients to be able to receive videos at three times the video
consumption rate It only differs from
the original stream tapping protocol in the way it handles its tap streams While tap streams originally were the sole responsibility
of the server, this task is now shared by the server and  clientb. Let us consider the scenario described in Figure 3 and focus on the request issued by client c. Let Δt′ denote the time interval between that request and a request issued byclient b, and let Tc denote the time
elapsed since the start of the last request that was serviced by a complete
stream.Figure 3
How the full tap streams are distributed
among the server and the previous clients.(1) IfTc ≥ D,
the two requests do not overlap and client c  cannot tap any data from
the last complete stream As in the
original stream tapping protocol, the server will then start a new complete
stream.(2) IfTc < D, there is an overlap between
the current request and the last complete stream As in the original stream tapping protocol,
the server will then evaluate whether it would be more advantageous to keep
tapping from the last complete stream or to start a new one If the server decides to keep tapping from
the last complete stream, it will have to provide client c  with a full
tap stream of duration Tc Two alternatives must now be considered:(a)
ifTc≤D−Δt′, client b will provide a fraction α of the full tap stream and the server the remaining 1 – α fraction of the stream;(b)
ifTc>D−Δt′, client c will finish watching the
video before being able to transmit all its share of the full tap stream, and
will only be able to transmit a fraction α(D−Δt′)/Tc of the
full tap stream with the server transmitting the remainder of the stream.If the video is long enough, the new request is
likely to overlap with more than one previous request We propose to harness the available bandwidth
of the clients that issued these requests in order to further reduce the
workload of the server. The
contributions of these clients will be subject to two restrictions. First,
upstream bandwidth restrictions prevent any client to upload data for two
different clients at the same time. Second, we will never require a client to transmit video data after the
client has finished watching the video.In our example, the request form clienta is entirely serviced by a complete stream coming from the server The request from client b gets the
last D−Δt minutes of the video by tapping client a's complete stream and the first Δt minutes
from a full tap stream of duration Δt A
fraction α of this stream will be sent by customer a, and the remaining 1−α fraction
will come from the server Assuming that
the server decides not to start a new complete stream for customer c, that customer would get the following.(1)
The lastD−(Δt+Δt′) minutes of the video by tapping client a's complete stream.(2)
A fractionα of the first D−(Δt+Δt′) minutes of the video from a tap stream
sent by customer a; this tap stream
will end when customer a will finish
watching the video D−(Δt+Δt′)
minutes after the arrival of customer c.(3)
A fractionα of the first D−Δt′ minutes
of the video from a tap stream sent by customer b; this tap stream will end when customer b will finish watching the video D−Δt′ minutes after the arrival of customer c.(4)
The remaining portion of the
firstΔt+Δt′
minutes of the video from the server.One last issue to consider is when to halt tapping
from the current complete stream and start a new one.To achieve
this goal, our protocol keeps track of the minimum average request service time
of all requests sharing the same complete stream Before adding a new request to a group, it
computes what would be the new average request service time of the group if the
new request was added to the group
Should this new average request service time be lesser than or equal to
the minimum average request service time of the group, our protocol adds the new
request to the group; otherwise, it starts a new group This criterion is similar but not identical
to that used by Carter and Long [6, 7].


### 3.1. Handling Client Failures

To
operate correctly, our protocol requires all clients to forward video
data to the next customers for the same video
Any client failure will deprive all subsequent customers from their
video data.There is a simple solution to the problem Let us return to the scenario of Figure3,
where client c receives most of its tap stream from clients a and b, while client b receives almost half of its tap stream from client a Any failure of either
client a or client b would immediately affect the correct
flow of data to client c A failure of client a will require the server to take over the role of client a and send the missing video data to
clients b and c. A
failure of client b would have less
impact on the server workload as it would also free client a from its obligation to send client b a fraction of its tap stream, thus freeing enough upstream
bandwidth to let client a take over
the role of client b and send most of
the missing video data to client c Making the protocol fault tolerant will thus
require the server to keep track of which client is sending video data to each
client.


## 3.1. Handling Client Failures

To
operate correctly, our protocol requires all clients to forward video
data to the next customers for the same video
Any client failure will deprive all subsequent customers from their
video data.There is a simple solution to the problem Let us return to the scenario of Figure3,
where client c receives most of its tap stream from clients a and b, while client b receives almost half of its tap stream from client a Any failure of either
client a or client b would immediately affect the correct
flow of data to client c A failure of client a will require the server to take over the role of client a and send the missing video data to
clients b and c. A
failure of client b would have less
impact on the server workload as it would also free client a from its obligation to send client b a fraction of its tap stream, thus freeing enough upstream
bandwidth to let client a take over
the role of client b and send most of
the missing video data to client c Making the protocol fault tolerant will thus
require the server to keep track of which client is sending video data to each
client.


## 4. Performance Evaluation

To evaluate the performance of our
new protocol, we designed a simulator modeling the distribution of a two-hour
video assuming that request arrivals could be modeled by a Poisson process
[14]. It is based on
similar simulators used for previous papers on stream tapping and was modified
to model clients that could not forward video data at a rate equal to the video
consumption rate [15, 16].Figure4 displays
the server bandwidth requirements of our new stream tapping protocol for
selected values of α and request arrival rates varying between one
and one thousand requests per hour All
bandwidths are expressed in multiples of the video consumption rates In addition, the dotted line represents the
server bandwidth requirements of the original stream tapping protocol with
extra tapping Let us observe that the
comparison between the two protocols is not totally fair since extra tapping
requires clients capable of receiving video data at three times the video
consumption rate, while our protocol only requires clients capable of receiving
video data at two times that rate.Figure 4
Server bandwidth requirements of the new
stream tapping protocol.As we can see,
our new stream tapping protocol outperforms conventional stream tapping even
when clients can only forward data at one fourth of the video consumption rate,
that is, whenα = 0.25. These results are much better than those of an earlier version of the
protocol that would not allow clients to receive video data from more than one
client [16].This excellent
performance comes however at a stiff price
As seen in Figure5, the network bandwidth requirements of our stream
tapping protocol increase much more rapidly than those of the original stream
tapping protocol when the client request arrival rate exceeds ten requests per
hour. This phenomenon can be explained in part by the fact that our protocol
does not allow extra tapping A more
important factor is the way the server decides when to start a new complete
stream. Since the clients handle most of the tap streams, adding extra requests
to any existing group has a negligible impact on the server workload As a result, the server never starts a new
complete stream before the end of the previous one. Thus the average duration
of a tap stream is equal to half the duration of the video and the average
network bandwidth is roughly equal to one half the bandwidth required by a
unicast scheme.Figure 5
Network bandwidth requirements of the new
stream tapping protocol.A simplistic
solution to this problem would be to limit the size of the tap streams to a
fractionβmax of the duration of
the video. This would reduce the average duration of these streams and
proportionally reduce the network bandwidth. This solution would however affect
the performance of the protocol at low-arrival rates, where long tap streams are
the norm Having investigated several
other options, we found out that the best way to limit the growth of the
network bandwidth was to limit the size of the tap streams at high arrival
rates. At the same time, we
did not want to complicate the design of the server by requiring it to maintain
some moving average of the request arrival rates for each video.We decided
instead to use as threshold the number of clients sharing the same complete
stream and force the server to start a new complete stream whenever (a) the
size of the tap stream would otherwise exceed a fractionβmax o the duration of the video, and (b)
more than Nmax⁡ requests were already sharing the current
complete stream.Figures6 and 7
display the impact of this modification to the server and network bandwidth of
our protocol. We considered clients capable of uploading data at one-fourth the
video consumption rate and set our βmax to 0.25. Each individual curve corresponds to a
different value of Nmax⁡. We see that limiting the tap stream
length to one
quarter of
the video duration reduces by a factor of four the network bandwidth of the
protocol, while increasing the server bandwidth at the highest arrival rates by
the same factor. Even under these conditions, the server bandwidth remains well
below that of the original stream tapping protocol.Figure 6
Server bandwidth requirements of the protocol forα =
0.25, and βmax = 0.25.Figure 7
Network bandwidth requirements of the
protocol forα = 0.25, and βmax = 0.25.


## 5. An Analytical Model

As in a previous paper [17], we
consider stream tapping without extra tapping for a video of duration D that is being accessed at a rate λ.
We assume that we will restart a new complete stream whenever the length of the
next full tap exceeds βD, where 0 < β ≤ 1 is a parameter to be determined.In other words,
we will wait for an incoming request, start a complete stream of durationD, tap this stream over a time interval
of duration βD, then restart the process.During this time
interval, the server will process an average of λβD requests in addition to the request that prompted the complete stream Hence the average number of requests sharing
the same complete stream is(2)navg=1+λβD.Since the lengths
of the λβD full tap streams in the group will be uniformly distributed over the interval
(0, βD],
the average duration of each of these streams will be equal to βD/2
The total duration of the streams required for processing these
1 + λβD requests will thus be(3)W=D+(λβD)(βD2)=D+λβ2D22.We define the average service timeTavg for the requests in a group as the total duration W of the streams
required for processing these requests divided by the number navg of requests in the group We will then
have(4)Tavg=Wnavg=D+λβ2D2/21+λβD.Our protocol
assumes that previous clients will share with the server the task of sending
the full tap streams Letγ≤1
denote the fraction of the tap streams that the clients will be able to send. This
fraction γ will depend both on the factor α characterizing the upload bandwidth of the
clients and the existence of previous clients whose requests overlap with the
current requests. As
the request arrival increases, the number of these clients will also increase,
which will allow them to send a larger fraction γ of the tap
streams.For a given
value ofγ, the contribution of the server to the average
request service time will be(5)Ts,avg=D+(1−γ)λβ2D2/21+λβD, and
that of the previous clients will be(6)Tc,avg=γλβ2D2/21+λβD. To find the value βopt of the coefficient β that minimizes the server workload, we
differentiate (5) with respect to β,
obtaining(7)(1−γ)λβD2(1+λβD)−λD(D+(1−γ)λβ2D2/2)(1+λβD)2, the only positive root of which(8)βopt=2λD(1−γ)+(1−γ)2−(1−γ)λD(1−γ). When γ equals
zero, clients do not participate in the sending of full tap
streams and (5) reverts to(9)βopt=2λD+1−1λD. When
γ equals 1, clients handle all full tap streams,
the server only handles the complete streams, and βopt goes to infinity As a result, the server will never start a
new complete stream before the end of the previous one, and the server
bandwidth Bs,ST will never exceed one channel.To estimate the total bandwidth
requirements of the clients whenγ=1, let us consider, let us consider an interval of duration 2D starting with the beginning of a new complete stream During this time interval, the system will
receive an average of 2λD requests in addition to the
request that prompted the complete stream and the clients will send an average
of 2λD full tap streams. Since the lengths of these full tap streams
will be uniformly distributed over the interval (0, D), the average duration of each of these streams will be equal to D/2 The total duration of these streams will thus
be(10)Wc=(2λD)(D2)=λD2.The average bandwidthBc,ST used by the clients to send full taps streams is then given by dividing this
expression by the duration of the considered interval,(11)Bc,ST=Wc2D=λD2. The total network bandwidth requirements BST of our protocol are
obtained by adding the average bandwidth Bs,ST used by the server to that expression As we can see in Figure 4, Bs,ST is very close to on for large
values of λ.
We can thus approximate BST as(12)BST=Bc,ST+Bs,ST≈λD2+1.Compare
these requirements with those of a video distribution scheme that does not use
any form of multicast Over an interval
of durationT, it will handle an average of λT requests. Since each request will be serviced by a separate stream of
duration D, the total duration of these streams
will be λDT, and the average bandwidth
requirements of the scheme would be λD, that is, almost twice the average
bandwidth BST requirements
of our cooperative stream tapping protocol.Figures8 and 9 compare our analytical results with our simulation results We
considered the two limit cases when γ = 0 and γ = 1 As we can see, both models predict identical
network bandwidths for all values of α and all arrival rates.Figure 8
Server bandwidth requirements of the new stream tapping protocol.Figure 9
Network
bandwidth requirements of the new stream tapping protocol.This
is not the case for server bandwidths
Both models are in substantial agreement when eitherα = 0
or α≥0.5 and disagree when 0<α<0.5 Let us consider these three cases.(1)α = 0
Whenα = 0, the clients cannot
upload video data Hence, γ = 0
and both models predict identical network bandwidths.(2)α≥0.5
Whenα≥0.5, the clients can upload video data
at at least half the video consumption rate. As a result, they can handle most,
if not all, of the tap streams, and their share γ of the stream tapping data is close to one. This
is less true for request arrival rates below 20 requests per hour, where the
server must still handle a small fraction of the tap streams.(3)0<α<0.5
When0<α<0.5, the clients
have very limited upload bandwidths
They participate in the distribution of tap streams but cannot fully
substitute for the server as long as the request arrival rate remains below 60
requests per hour As a result,
0 < γ <1 and the actual
server bandwidth stands somewhere between the values predicted for γ = 0
and γ = 1.Let
us turn now our attention to the performance of the scheme reducing the network bandwidth consumption
of our protocol at high arrival rates
Recall that this scheme consisted of starting a new complete stream
whenever (a) the size of the tap stream
would otherwise exceed a fractionβmax of the duration of the video, and (b) more than Nmax⁡ requests
were already sharing the current complete stream.On
the average, this scheme will take effect whenever the request arrival rate λ will exceed a threshold,(13)λ*=Nmax⁡βmax⁡D.At
higher arrival rates, the server will restart a new complete stream of duration
eachβmaxD time
units Its bandwidth requirements will
thus be equal to 1/βmax As a result, the average bandwidth
requirements of the server will be(14)Bs,ST={1forλ<λ*,1βmax⁡forλ≥λ*.Let us now focus on the behavior of clients
at arrival rates greater than or equal to λmax Assuming again that the clients will handle
all full tap streams, they will send
an average of λβmaxD full tap streams each βmaxD time units The average length of these tap streams will
be equal to βmaxD/2, and the average
bandwidth Bc,ST used by
the client will be(15)Bc,ST={λD2forλ<λ*,λβmax⁡D2forλ≥λ*.Figures10 and 11 compare our analytical results with our simulation results for α = 0.25, βmax = 0.25, and Nmax⁡=100 As before, both models predict
identical or near identical network bandwidths for all values of α and
all arrival rates This is not the case
for the server bandwidth Here again our
analytical model underestimates the server bandwidth when the request arrival
rate remains below 60 requests per hour because it incorrectly assumes that the
clients can handle all tap streams.Figure 10
Server bandwidth requirements of the protocol
forα = 0.25, βmax =  0.25, and Nmax=100.Figure 11
Network bandwidth
requirements of the protocol forα =
0.25, βmax = 0.25, and Nmax=100.We
can thus say that the results of our probabilistic analysis confirm those
obtained through our simulation study and conclude that our cooperative stream
tapping protocol can effectively harness the collective upload bandwidth of its
clients even when each individual client cannot upload video data at more than
one quarter of the video consumption In
addition, requiring the server to restart complete streams at fixed intervals
provides an effective tool for limiting the network bandwidth consumption of
the protocol.


## 6. Protocol Applicability

Many
organizations such as universities and companies run their own
multicast-capable networks Consider the
example of a local telephone company that decides to increase its service
offerings to include on-demand video entertainment Many of their existing clients are already
subscribed to their high-speed internet access by means of DSL With our solution, the telephone company can
make use of their multicast-enabled infrastructure to deliver videos on demand
to a large number of clients at very low cost.


## 7. Conclusions

We have presented a stream tapping
protocol that involves clients in the video distribution process Our protocol is tailored to multicast-capable
environments where client machines are able to download video data at twice the
video consumption rate but cannot necessarily forward video data at that rate. We
observed that our technique achieved a dramatic reduction of the server
workload at medium to high request arrival rates but also resulted in much
higher network bandwidth consumptions. These increases can however be
controlled by requiring the server to restart complete streams at some specific
intervals Even then, the server
bandwidth requirements of the protocol remain well below those of pure client-server
solutions.Our proposal
differs from conventional peer-to-peer (P2P) solutions in two different
ways First, it assumes the existence of
one or more servers capable of multicasting video data at twice to four times
the video consumption rate This allows
the protocol to make much more efficient use of the network bandwidth as a
single video stream can be broadcast to an arbitrary number of clients Second, it does not require peers to be able
to upload video data at more than one quarter to one half of their video consumption
rates, which would not be possible in a pure P2P solution such as [18] In pure P2P systems, the download rate is
positively correlated to the upload rate
Legout et al. [19] illustrated through experiments that the amount of
data uploaded is very close to the data downloaded in P2P systems such as
BitTorrent [20].  Thus, to sustain a
video streaming service, a peer should have an upload rate at least equal the
video consumption rate.Stream tapping
protocol involving clients is a very good solution, especially over local
networks as it provides a scalable way to distribute on-demand high-bandwidth
videos streams without overtaxing the network bandwidth.



---

*Source: 265309-2008-04-29.xml*