Minimizing Bandwidth Requirements for On-Demand Data Delivery.
AbstractTwo recent techniques for multicast or broadcast delivery of streaming media can provide immediate service to each client request, yet achieve considerable client stream sharing which leads to significant server and network bandwidth savings. This paper considers 1) how well these recently proposed techniques perform relative to each other and 2) whether there are new practical delivery techniques that can achieve better bandwidth savings than the previous techniques over a wide range of client request rates. The principal results are as follows: First, the recent partitioned dynamic skyscraper technique is adapted to provide immediate service to each client request more simply and directly than the original dynamic skyscraper method. Second, at moderate to high client request rates, the dynamic skyscraper method has required server bandwidth that is significantly lower than the recent optimized stream tapping/patching/controlled multicast technique. Third, the minimum required server bandwidth for any delivery technique that provides immediate real-time delivery to clients increases logarithmically (with constant factor equal to one) as a function of the client request arrival rate. Furthermore, it is (theoretically) possible to achieve very close to the minimum required server bandwidth if client receive bandwidth is equal to two times the data streaming rate and client storage capacity is sufficient for buffering data from shared streams. Finally, we propose a new practical delivery technique, called hierarchical multicast stream merging (HMSM), which has a required server bandwidth that is lower than the partitioned dynamic skyscraper and is reasonably close to the minimum achievable required server bandwidth over a wide range of client request rates.
Introduction
This paper considers the server (disk I/O and network I/O) bandwidth required for on-demand real-time
delivery of large data files, such as audio and video files 1 . Delivery of the data might be done via the Internet or
via a broadband (e.g., satellite or cable) network, or some combination of these networks.
We focus on popular, widely shared files, such as popular news clips, product advertisements, medical or
recreational information, television shows, or successful distance education content, to name a few examples.
Due to the large size and the typical skews in file popularity, for the most popular files, one can expect many
new requests for the file to arrive during the time it takes to stream the data to a given client.
Prior research has shown that the server and network bandwidth required for on-demand delivery of such
files can be greatly reduced through the use of multicast delivery techniques 2 . A simple approach is to make
requests wait for service, hoping to accumulate multiple requests in a short time that can then all be served by a
single multicast stream [DaSS94]. A second approach (called piggybacking) is to dynamically speed up and
slow down client processing rates (e.g., display rates for video files) so as to bring different streams to the same
file position, at which time the streams can be merged [GoLM95, AgWY96a, LaLG98]. An appealing aspect of
these approaches is that they require the minimum possible client receive bandwidth (i.e., equal to the file play
rate 3 ) and minimal client buffer space. On the other hand, if clients have receive bandwidth greater than the file
* This work was partially supported by the NSF (Grants CCR-9704503 and CCR-9975044) and NSERC (Grant OGP-0000264). A shorter
version of this paper appears in Proc. 5 th Int'l. Workshop on Multimedia Information Systems (MIS '99), Indian Wells, CA, Oct. 1999.
More generally, the delivery techniques we consider may be fruitful for any data stream that clients process sequentially.
We use the term "multicast" to denote both multicast and true broadcast throughout this paper.
3 Throughout the paper we use the term "play rate" to denote the fixed rate at which a file must be transmitted in order for
the client to process or play the stream as it arrives. Data is assumed to be transmitted at this rate unless otherwise stated.
play rate, and some spare buffer space, significantly greater server bandwidth savings can be achieved
[AgWY96b, ViIm96, CaLo97, HuSh97, JuTs98, HuCS98, EaVe98, CaHV99, PaCL99, GaTo99, SGRT99,
EaFV99]. In these stream merging methods, a client receiving a particular stream simultaneously receives and
buffers another portion of the data from a different (multicast) stream, thus enabling greater opportunities for
one client to catch up with and share future streams with another client.
Two of these recent techniques, namely dynamic skyscraper (with channel stealing) [EaVe98] and stream
tapping/patching/controlled multicast [CaLo97, HuCS98, CaHV99, GaTo99, SGRT99], have the key property
that they can provide immediate real-time streaming to each client without requiring initial portions of the file to
be pre-loaded at the client. These two techniques also require client receive bandwidth at most two times the
file play rate. To our knowledge, how these two techniques compare with respect to required server bandwidth
has not previously been studied. This paper addresses this issue as well as the following open questions:
(1) What is the minimum required server (disk and network I/O) bandwidth for delivery techniques that provide
immediate service to clients?
(2) What is the interplay between achievable server bandwidth reduction and client receive bandwidth?
(3) Are there new (practical) delivery techniques that achieve better bandwidth savings than the previous
techniques, yet still provide immediate service to each client request?
How does the best of the techniques that provide immediate service to client requests compare to the static
periodic broadcast techniques (e.g., [AgWY96b, ViIm96, HuSh97, JuTs98]) that have fixed server
bandwidth independent of the client request rate?
The principal system design results, in order of their appearance in the remainder of this paper, are as follows:
. We review the optimized stream tapping/grace patching/controlled multicast method, for which required
server bandwidth increases with the square root of the request arrival rate. This is significantly better than
when immediate service is provided and multicast delivery is not employed, in which case required server
bandwidth increases linearly with the request arrival rate.
. We develop a new implementation of the partitioned dynamic skyscraper technique [EaFV99] that provides
immediate service to client requests more simply and directly than the original dynamic skyscraper method,
and we show how to optimize this partitioned dynamic skyscraper architecture.
. The optimized dynamic skyscraper technique has required server bandwidth that increases logarithmically
(with constant factor between two and three) as a function of the client request rate. Thus, at moderate to
high client request rate, the dynamic skyscraper technique significantly outperforms optimized patching/
stream tapping.
. We derive a tight lower bound on the required server bandwidth for any technique that provides immediate
service to client requests. This lower bound increases logarithmically with a constant factor of one as a
function of the client request arrival rate. Thus, techniques that provide immediate service to each client
request have the potential to be quite competitive with the static broadcast techniques that have fixed server
bandwidth independent of client request rate.
. We define a new family of segmented delivery techniques, called segmented send-latest receive-earliest
(SSLRE). Although not necessarily practical to implement, the SSLRE techniques demonstrate that it is at
least theoretically possible to achieve nearly the lower bound on required server bandwidth if client receive
bandwidth equals twice the file play rate, assuming clients can buffer the required data from shared streams.
. We propose a new practical delivery technique, hierarchical multicast stream merging (HMSM), that is
simple to implement and provides immediate real-time service to clients. Simulation results show that if
client receive bandwidth equals two times the file play rate, the required server bandwidth for the HMSM
technique is reasonably close to the minimum achievable required server bandwidth over a wide range of
client request rates.
For the purposes of obtaining the lower bound and examining the fundamental capabilities of the various
delivery techniques, the above results are obtained assuming that (1) clients have sufficient space for buffering
the data streams, and (2) the entire file is consumed sequentially by the client without use of interactive
functions such as pause, rewind or fast forward. However, each of the techniques that we consider can be
adapted for limited client buffer space, and for interactive functions, with a concomitant increase in required
server bandwidth, as discussed in Section 5.
In this paper, required server bandwidth is defined as the average server bandwidth used to satisfy client
requests for a particular file with a given client request rate, when server bandwidth is unlimited. There are at
least two reasons for believing that this single-file metric, which is relatively easy to compute, is a good metric
of the server bandwidth needed for a given client load. First, although the server bandwidth consumed for
delivery of a given file will vary over time, the total bandwidth used to deliver a reasonably large number of
files will have lower coefficient of variation over time, for independently requested files and fixed client request
rates. Thus, the sum over all files of the average server bandwidth used to deliver each file should be a good
estimate of the total server bandwidth needed to achieve very low client waiting time. Second, simulations of
various delivery techniques have shown that with fixed client request rates and finite server bandwidth equal to
the sum of the average server bandwidth usage for each file, average client waiting time (due to temporary
server overload) is close to zero (e.g., [EaFV99, EaVZ99]). Furthermore, the results have also shown that if
total server bandwidth is reduced below this value, the probability that a client cannot be served immediately
and the average client wait rapidly increase.
The rest of this paper is organized as follows. Section 2 reviews and derives the required server bandwidth
for the optimized stream tapping/grace patching/controlled multicast technique. Section 3 reviews the dynamic
skyscraper technique, develops the simpler method for providing immediate service to client requests, defines
how to optimize the new dynamic skyscraper method, and derives the required server bandwidth. Section 4
derives the lower bound on required server bandwidth for any delivery technique that provides immediate
service to clients and shows the impact of client receive bandwidth on this lower bound. Section 5 defines the
new hierarchical multicast stream merging technique, and Section 6 concludes the paper.

Table

defines notation used throughout the rest of the paper.
Required Server Bandwidth for Optimized Stream Tapping/Grace Patching
Two recent papers propose very similar data delivery techniques, called stream tapping [CaLo97] and
patching [HuCS98], which are simple to implement. The best of the proposed patching policies, called grace
patching, is identical to the stream tapping policy if client buffer space is sufficiently large, as is assumed for
comparing delivery techniques in this paper. The optimized version of this delivery technique [CaHV99,
GaTo99], which has also been called controlled multicast [GaTo99], is considered here.
The stream tapping/grace patching policy operates as follows. In response to a given client request, the
server delivers the requested file in a single multicast stream. A client that submits a new request for the same
file sufficiently soon after this stream has started begins listening to the multicast, buffering the data received.
Each such client is also provided a new unicast stream (i.e., a "patch" stream) that delivers the data that was
delivered in the multicast stream prior to the new client's request. Both the multicast stream and the patch
stream deliver data at the file play rate so that each client can play the file in real time. Thus, the required client
receive bandwidth is twice the file play rate. The patch stream terminates when it reaches the point that the
client joined the full-file multicast.

Table

1: Notation
Symbol Definition
request rate for file i
T total time to play file i (equals total time to transmit file i if
average number of requests for file i that arrive during a period of length i
z
required server bandwidth to deliver a particular file using delivery technique z, in units of
the file play rate
y threshold for file i in optimized stream tapping/grace patching, expressed as a fraction of T i
K number of file segments in dynamic skyscraper
largest segment size in dynamic skyscraper
r stream transmission rate, measured in units of the play rate; default value is
client receive bandwidth, measured in units of the play rate
To keep the unicast patch streams short, when the fraction of the file that has been delivered by the most
recent multicast exceeds a given threshold, the next client request triggers a new full-file multicast. Let
y denote the threshold for file i, and i
T denote the duration of the full-file multicast. Assuming Poisson client
request arrivals at rate i , the required server bandwidth for delivery of file i using stream tapping/grace
patching, measured in units of the play rate, is given by
Ni
Ni
y
y
patching
is the average number of client requests that arrive during time i
T . The denominator in the
middle of the above equation is the average time that elapses between successive full-file multicasts, i.e., the
duration of the threshold period plus the average time until the next client request arrives. The numerator is the
expected value of the sum of the transmission times of the full-file and patch streams that are initiated during
that interval. Note that the average number of patch streams that are started before the threshold expires is
y
and the average duration of the patch streams is /2
y .
Differentiating the above expression with respect to i
y , and setting the result to zero, we obtain
as the optimal threshold value. Substituting this value of i
y into the above expression for
required server bandwidth yields the following result for the required server bandwidth for optimized stream
tapping/grace patching:-2N i
patching
optimized
. (1)
Note that the required server bandwidth grows with the square root of the client request rate for the file,
and that the optimal threshold decreases as the client request rate increases. (The reader is referred to [GaTo99]
for an alternate derivation of these results.)
3 Dynamic Skyscraper Delivery
Section 3.1 reviews the recent partitioned dynamic skyscraper delivery technique [EaFV99] and defines a
particular implementation that provides immediate service to client requests in a simpler and more direct way
than the original dynamic skyscraper method. The required server bandwidth for this version of partitioned
dynamic skyscraper delivery is derived in Section 3.2.
3.1 Providing Immediate Service Using Partitioned Dynamic Skyscraper
The static skyscraper broadcast scheme defined in [HuSh97] divides a file into K increasing-sized
segments largest segment size denoted by W. 4 In a broadband satellite or cable network,
each segment is continuously broadcast at the file play rate on its own channel, as illustrated in Figure 1. Each
client is given a schedule for tuning into each of the K channels to receive each of the file segments. For
example, a client who requests the file just before the broadcast period labelled 3 on the first channel, would be
scheduled to receive segments 1-3 sequentially during the periods that are labelled 3, and segments 4-6 during
the periods labelled 1 on channels 4-6. The structure of the server transmission schedule ensures that, for any
given segment 1 broadcast that a client might receive, the client can receive each other file segment at or before
the time it needs to be played, by listening to at most two channels simultaneously. (The reader can verify this
4 The segment sizes are not strictly increasing, but have the pattern 1,2,2,j,j,k,k,., with each size change being an increase
in size. In the original skyscraper scheme, the progression was specified as 1,2,2,5,5,12,12,25,25,., upper bounded by the
parameter W. This progression appears to have the maximum possible size increases (among progressions with the above
pattern) such that clients never need to listen to more than two streams simultaneously. The progression 1,2,2,4,4,8,8,.,
provides similar performance for skyscraper broadcasts (i.e., same client receive bandwidth, similar segment 1 delivery time,
and similar client buffer space requirement), and increases the efficiency of dynamic skyscraper broadcasts.
in

Figure

1.) Since larger segments are multicast less frequently, clients must be able to receive and buffer
segments ahead of when they need to be played, thus merging with other clients that may be at different play
points. The maximum client buffer space needed by any client transmission schedule is equal to the largest
segment size (W) [HuSh97].
The required server bandwidth for this static skyscraper method is equal to K, independent of the client
request rate for the file. The duration of each segment 1 broadcast is determined by the total file delivery time
divided by the sum of the segment sizes. Thus, larger values of K and W result in lower average and
maximum client wait time for receiving the first segment. A desirable configuration might have K=10 and the
segment size progression equal to 1,2,2,4,4,8,8,16,16,32, in which case segment 1 broadcasts begin every
T , and required server bandwidth for skyscraper is lower than for optimized patching if i
The dynamic skyscraper delivery technique was proposed in [EaVe98] to improve the performance of the
skyscraper technique for lower client request rates and for time-varying file popularities. In this technique, if a
client request arrives prior to the broadcast period labeled 1 on the first channel in Figure 1, the set of segment
broadcasts that are shaded in the figure (called a transmission cluster) might be scheduled to deliver the
segments of the file. The arriving client only needs the segment transmissions labeled 1 on each channel.
However, any client who requests the same file prior to the transmission period labeled 8 on channel 1 will
receive broadcasts from the cluster that was scheduled when the first request arrived. When the broadcast
labeled 8 is complete, the six channels (e.g., satellite or cable channels) can be scheduled to deliver an
identically structured transmission cluster for a different file. Thus, if there is a queue of pending client requests,
the six channels will deliver a cluster of segment broadcasts for the file requested by the client at the front of the
queue. If no client requests are waiting, the six channels remain idle until a new client request arrives, which
then initiates a new transmission cluster. Note that as with optimized patching any queueing discipline, for
example one tailored to the needs of the service provider and clients, can be used to determine the order in
which waiting clients are served during periods of temporary server overload.
To employ the dynamic skyscraper technique over the Internet, the transmission cluster can be implemented
with W multicast streams of varying duration, as shown by the numbering of the cluster transmission periods in

Figure

1. That is, the first stream delivers all K segments, the second stream starts one unit segment later and
delivers only the first segment, the third stream starts one unit segment later than the second stream and delivers
the first three segments, and so on. Total server bandwidth is allocated in units of these clusters of W variable-length
streams. Each cluster of streams uses K units of server bandwidth, with each unit of bandwidth used for
duration W. Note that this implementation requires clients to join fewer multicast groups and provides more
time for joining the successive multicast groups needed to receive the entire file than if there are K multicast
groups each transmitting a different segment of the file.
In the original dynamic skyscraper technique [EaVe98], immediate service is provided for clients that are
waiting for the start of a segment 1 multicast in a transmission cluster using a technique termed channel stealing.
That is, (portions of) transmission cluster streams that have no receiving clients may be reallocated to provide
quick service to newly arriving requests.

Figure

1: Skyscraper and Dynamic Skyscraper Delivery
(K=6, W=8, segment size progression = 1,2,2,4,4,8)
Segment 1:
2:
3:
4:
5:
We propose a more direct way to provide immediate service to client requests that is also simpler to
implement. This more direct approach involves a small modification to the segment size progression, and a
particular implementation of partitioned skyscraper delivery [EaFV99]. The new segment size progression has
the form 1,1,2,2,j,j,k,k,. As in [EaVe98, EaFV99], each size increase is either two-fold or three-fold, and no
two consecutive size increases is three-fold, to limit the number of streams a client must listen to concurrently.
Also as before, the progression is upper-bounded by the parameter W, the purpose of which is to limit the
required client buffer space.
We partition the segments, as illustrated in Figure 2, so that streams that deliver the first two segments can
be scheduled independently and immediately in response to each client request. Thus, when client A requests
the file, the server schedules one stream to deliver the first two segments, and schedules W/2 multicast streams
to deliver a transmission cluster of segments 3 through K. These streams (one that delivers the first two
segments and four that deliver the transmission cluster) are shaded in Figure 2. When client B requests the file,
the server only allocates a new stream (from unscheduled bandwidth not shown in the figure) to deliver the first
two segments of the file to client B. Client B receives segments 3 through K by listening to the streams in the
transmission cluster that was scheduled when client A arrived. The next section computes the average server
bandwidth used when the initial two-segment stream and possible new transmission cluster are scheduled
immediately for each client request.
A key observation is that this partitioned dynamic skyscraper system with each segment size increase being
a two-fold increase (i.e., progression 1,1,2,2,4,4,8,8,.) requires client receive bandwidth equal to only twice
the file play rate. The partitioned system with at least one three-fold segment size increase (such as the
progression 1,1,2,2,6,6,12,12,36,36,.) requires client receive bandwidth equal to three times the file play rate,
as in the corresponding dynamic skyscraper system without partitioning.
3.2 Required Server Bandwidth for Dynamic Skyscraper
Let U denote the duration of a unit-segment multicast, which is determined by the time duration of the
T ) and the sum of the segment sizes. For the partitioned dynamic skyscraper system defined above,
the required server bandwidth for delivery of a file i (measured in units of the streaming rate), given a Poisson
request arrival stream, is given by
(K
skyscraper
dynamic
. (2)

Figure

2: Partitioned Dynamic Skyscraper with Immediate Service
(K=9, W=8, segment size progression = 1,1,2,2,4,4,8,8,8)
Client A Client B
Segment 1:
2:
3:
4:
5:
7:
8:
K=9:
The first term is the required bandwidth for delivering the first two unit segments of the file, which involves
sending a stream of duration 2U at frequency l i . The second term is the required bandwidth for delivering the
transmission clusters for the rest of the file, which use K-2 units of server bandwidth, where each unit of
bandwidth is used for time equal to WU.
The values of K and W that minimize the required server bandwidth given in equation (2), may be found
numerically for any particular segment size progression of interest.
It is also possible to determine the asymptotic behavior for high client request rate. For the progression
1,1,2,2,4,4,8,8,.,

Appendix

A shows that for N i > 128, the required server bandwidth is approximately2
- . (3)
Note that the required server bandwidth grows only logarithmically with client request rate.
Other skyscraper systems may be similarly analyzed. For the progression 1,1,2,2,6,6,12,12,36,36,., the
required server bandwidth for large client request rate can be shown to be0
- . (4)

Figure

3 shows the required server bandwidth as a function of client request rate (N i ) for optimized
dynamic skyscraper systems with two different segment size progressions, and for optimized stream
tapping/grace patching. The required server bandwidth for the skyscraper systems is computed using equation
(2) with optimal choices of K and W determined numerically for each i
N . (Recall that the segment size
progression 1,1,2,2,4,4,8,8,. has the same client receive bandwidth requirement as optimized stream
tapping/patching, namely, two times the file play rate.)
The results show that for i
greater than 64 requests on average per time T i , the optimized dynamic
skyscraper systems have significantly lower bandwidth requirements than optimized stream tapping/patching.
More specifically, the optimized dynamic skyscraper delivery system has required server bandwidth that is
reasonably competitive with optimized stream tapping/patching at low client request rate, and is better than or
competitive with static broadcast techniques over the range of client request rates shown in the figure.
Skyscraper systems in which a second partition is added between channels k and k+1, 2<k<K-2, are also
of interest [EaFV99]. Analysis shows that adding the second partition does not alter the asymptotic behavior
under high client request arrival rates, but does improve performance somewhat for more moderate arrival rates,
at the cost of an increase in the required client receive bandwidth. (For k odd, client receive bandwidth must be
three times the file play rate if the progression is 1,1,2,2,4,4,8,8,., or four times the file play rate if the
progression is
Client Request Rate, N
Required
Server
Bandwidth Optimized Patching
Dyn Sky(1,1,2,2,4,4,.)
Dyn Sky(1,1,2,2,6,6,.)

Figure

3: Required Server Bandwidth for Dynamic Skyscraper & Stream Tapping/Patching
4 Minimum Required Server Bandwidth for Immediate Service
Given the results in Figure 3, a key question is whether there exist multicast delivery methods that can
significantly outperform optimized stream tapping/patching and dynamic skyscraper, over the wide range of
client request arrival rates. In other words, how much further improvement in required server bandwidth is
possible? Section 4.1 addresses this question by deriving a very simple, yet tight, lower bound on the required
server bandwidth as a function of client request rate, for any delivery technique that provides immediate real-time
streaming to clients. The lower bound assumes clients have unlimited receive bandwidth. Section 4.2
considers how much the lower bound increases if client receive bandwidth is only equal to n times the file play
rate, for arbitrary n >1.
4.1 Lower Bound on Required Server Bandwidth
The lower bound on required server bandwidth for delivery techniques that provide immediate real-time
service to clients is derived below initially for Poisson client request arrivals, and then is extended to a much
broader class of client request arrival processes. 5
As before, let i
T be the duration of file i and i be its average request rate. Consider an infinitesimally
small portion of the file that plays at arbitrary time x relative to the beginning of the file. For an arbitrary client
request that arrives at time t, this portion of the file can be delivered as late as time t+x, but no later than t+x, if
the system provides immediate real time file delivery to each client. If the portion is multicast at time t+x, all
other clients who request file i between time t and t+x, can receive this multicast of the portion at position x.
For Poisson arrivals, the average time from t+x until the next request arrives for file i is i
1/ . Thus, the
minimum frequency of multicasts of the portion beginning at position x, under the constraint of immediate real
time service to each client, is )
1/

x . This yields a lower bound on the required server bandwidth, in units
of the file play rate, for any technique that provides immediate service to client requests, of
d
minimum
x , (5)
is the average number of requests for the file that arrive during a period of length i
T .
The above lower bound implies that, for Poisson arrivals and immediate real-time service to each client,
the required server bandwidth must grow at least logarithmically with the client request rate. In fact, this is true
for any client arrival process such that the expected time until the next arrival, conditioned on the fact that some
previous request arrived at the current time minus x for any 0 < x < i
T , is bounded from above by i
c for some
constant c. In this case, we replace i
1/ in the denominator of the integral in equation (5) with i
c , which
yields a lower bound on required server bandwidth of )
c . This result is very similar to that in
equation (5); in fact, c
)/
, a constant independent of i
N . Furthermore, this more
general lower bound on required server bandwidth is tight if arrivals occur in "batches", with c requests per
batch, and the batch arrival times are Poisson with rate c
i . This illustrates the key point that there are
greater opportunities for stream sharing, and therefore the server bandwidth requirement is lower, if arrivals are
more bursty (i.e., for larger values of c). By considering Poisson arrivals, we can expect conservative
performance estimates if the actual client request arrival process is more bursty than the Poisson.
5 The Poisson assumption is likely to be reasonably accurate for full streaming media file requests [AKEV01], although one
would expect the (approximately Poisson) request rate to be time-varying, and in particular, time-of-day dependant. For
relatively short files, the Poisson analysis is directly applicable. For the case that substantive change in request rate occurs
on a time scale similar to the file play duration (e.g., perhaps for a two hour movie), the analysis for the broader class of
arrival processes yields applicable intuition and a similar result.
Further, it is easy to see that the bound in equation (5) can be reformulated as a function of the start-up
delay d in a static broadcast scheme, instead of as a function of the client request rate, simply by replacing i
by d
This result is shown formally in parallel work by Birk and Mondri [BiMo99].
Comparing equation (5) with equations (1) through (4) shows that there is considerable room for
improvement over the optimized stream tapping/patching and dynamic skyscraper delivery methods. However,
the lower bound in equation (5) assumes clients can receive arbitrarily many multicasts simultaneously. The
next section considers the likely lower bound on required server bandwidth if client receive bandwidth is a
(small) multiple of the file play rate.
4.2 Impact of Limited Client Receive Bandwidth
For clients that have receive bandwidth equal to n times the file play rate, for any n >1, we define a new
family of delivery techniques. These techniques may not be practical to implement, but intuitively they are
likely to require close to the minimum possible server bandwidth for immediate real-time service to clients who
have the specified receive bandwidth. Each technique in the family is distinguished by parameters n and r,
where r is the stream transmission rate, in units of the file play rate. (In each of the techniques discussed in
previous sections of this paper, r is equal to one.) We derive a close upper bound on the required server
bandwidth, for any n and r. The results show that for the required
server bandwidth for the new technique is nearly equal to the lower bound on required server bandwidth that
was derived in Section 4.1 for any technique that provides immediate real-time service to clients. This suggests
that it may be possible to develop new practical techniques that nearly achieve the lower bound derived in
Section 4.1, and that require client bandwidth of at most two times the play rate.
The new family of delivery techniques operate as follows when the segment transmission rate
which case n is an integer). A file is divided into arbitrarily small segments and the following two rules are used
to deliver the segments to a client who requests the given file at time t:
1. The client receives any multicast of a segment that begins at a position x in the file, as long as that multicast
commences between times t and t+x, and as long as receiving that multicast would not violate the limit n on
the client receive bandwidth. If at any point in time there are more than n concurrent multicasts that the
client could fruitfully receive, the client receives those n segments that occur earliest in the file.
2. Any segment of the file that cannot be received from an existing scheduled multicast is scheduled for
multicast by the server at the latest possible time. That is, if the segment begins at position x and is
transmitted at the file play rate (i.e., 1), the segment is scheduled to begin transmission at time t+x.
For lack of a better name, we call this family of techniques, and its generalization for r - 1given in Appendix C,
segmented send-latest receive-earliest (SSLRE(n,r)). Note that the SSLRE(-,1) technique achieves the lower
bound on required server bandwidth derived in Section 4.1 to any desired precision by dividing the file into
sufficiently small segments. This demonstrates that the lower bound derived in the previous section is tight. A
similar delivery technique defined only for unlimited client receive bandwidth, but augmented for limited client
buffer space, has been shown in parallel work [SGRT99] to be optimal for the case in which available client
buffer space may limit which transmissions a client can receive.
The SSLRE(n,r) technique may be impractical to implement, as it results in very fragmented and complex
delivery schedules. Furthermore, the SSLRE(n,r) technique does not have minimum required server bandwidth
for finite n because there are optimal rearrangements of scheduled multicast transmissions when a new client
request arrives that are not performed by SSLRE. However, the required server bandwidth for the SSLRE(n,r)
technique, derived below for arbitrary n, provides an upper bound on the minimum required server bandwidth
for each possible client receive bandwidth. We speculate that this bound provides accurate insight into the
lower bound on required server bandwidth for each client receive bandwidth. In particular, the optimal
rearrangements of scheduled multicast transmissions that SSLRE does not perform are, intuitively, likely to have
only a secondary effect on required server bandwidth, as compared with the heuristics given in rules 1 and 2
above that are implemented in the SSLRE technique. This intuition is reinforced by the results below that show
that the required server bandwidth for SSLRE(3,1), or for SSLRE(2,e), is very close to the lower bound derived
in Section 4.1. (That is, the optimal rearrangements of scheduled multicasts have at most very minor impact on
required server bandwidth in these cases.)
For a division of file i into sufficiently many small segments, Appendix B derives the following estimate of
the required server bandwidth for the SSRLE(n,1) technique, in units of the file play rate:
B,
n is the positive real constant that satisfies the following equation:11
n .
The above result assumes Poisson arrivals, but can be generalized in a similar fashion as was done for the lower
bound with unlimited client receive bandwidth. 1
decreases monotonically in n between
- 1.62 and .1
Thus, if the server transmits each segment at the file play rate (i.e., client
receive bandwidth is equal to twice the play rate (i.e., possible (although not necessarily practical) to
provide immediate service with no more than 62% greater server bandwidth than is minimally required when
clients have unbounded receive bandwidth. Further, since 3,1 - 1.19, it is possible to achieve nearly all of the
benefit of unbounded client bandwidth, with respect to minimizing required server bandwidth, when
clients have receive bandwidth equal to just three times the play rate.


Appendix

C defines the SSLRE technique for the more general case that the segment transmission rate, r,
can be different than the file play rate. In this case, a client can listen to at most s concurrent segment
transmissions (each at rate r), and total client receive bandwidth, may not be an integer. For this more
general family of techniques, Appendix C derives an estimate of the required server bandwidth as
r
r
r
where r
n, is the positive real constant that satisfies the following equation:,
r
r
r
r
n .
For fixed n, the value of r
thus the required server bandwidth, is minimized for r tending to zero
(i.e., low-rate segment transmissions). Denoting the value of n,r in this limiting case by n, , we have ,
e
n .
Note 6 that n, decreases monotonically in n, from ,
1.255. Thus, for client receive bandwidth n=2, it is (at least theoretically) possible to provide immediate real-time
streaming with no more than about 25% greater server bandwidth than is minimally required when clients
have unbounded receive bandwidth. Furthermore, for n < 2, there is potential for required server bandwidth to
grow only logarithmically with a small constant factor as a function of client request rate. Practical techniques
that exploit this latter potential are explored in [EaVZ00]. Figure 4 shows the lower bound on the required
server bandwidth for unlimited client receive bandwidth from equation (5), and the estimated required server
6 For ,
which is the expected result.
bandwidth for SSLRE(3,1), SSLRE(2,e) and SSLRE(2,1) from equation (7), as functions of the client request
rate, i
N . Note that SSLRE(3,1)
are very close to B minimum , and that for client request rates
up to at least an average of 1000 requests per file play time, even SSLRE(2,1)
B is reasonably competitive with
static broadcast techniques (which require fixed server bandwidth on the order of five to ten streams).
The SSLRE(n,r) techniques can be extended in a straightforward way to operate with finite client buffer
space. However, since the techniques involve very complex server transmission schedules and client receive
schedules, the principal value of these techniques is to determine, approximately, the lowest feasible required
server bandwidth for providing immediate service to client requests when clients have receive bandwidth equal
to n. In the next section we propose a new practical delivery technique and then evaluate the performance of the
new technique by comparing its required server bandwidth against the required server bandwidth for SSLRE.
We then comment on finite client buffer space in the context of the new practical delivery method.
5 Hierarchical Multicast Stream Merging (HMSM)
The results in Figures 3 and 4 show that there is considerable potential for improving performance over the
previous optimized stream tapping/patching/controlled multicast technique and over the optimized dynamic
skyscraper technique. Motivated by these results, we propose a new delivery technique that we call hierarchical
multicast stream merging (HMSM).
The new HMSM technique attempts to capture the advantages of dynamic skyscraper [EaVe98] and
piggybacking [GoLM95, AgWY96a, LaLG98], as well as the strengths of stream tapping/patching [CaLo97,
HuCS98]. In particular, clients that request the same file are repeatedly merged into larger and larger groups,
leading to a hierarchical merging structure (as in dynamic skyscraper or piggybacking). Furthermore, clients are
merged using dynamically scheduled patch streams (as in stream tapping/patching), rather than using
transmission clusters or altering client play rates.
5.1 HMSM Delivery Technique
Key elements of the hierarchical multicast stream merging technique include: (1) each data transmission
stream is multicast so that any client can listen to the stream, (2) clients accumulate data faster than their file
play rate (by receiving multiple streams and/or by receiving an accelerated stream), thereby catching up to
clients that started receiving the file earlier, (3) clients are merged into larger and larger groups, and (4) once
two transmission streams are merged, the clients listen to the same stream(s) to receive the remainder of the file.
The hierarchical multicast stream merging technique is illustrated in Figure 5 for a particular set of request
arrivals for an arbitrary file, assuming the server transmits streams at the play rate (i.e., clients have
receive bandwidth equal to twice the play rate. In this case, denoted by HMSM(2,1), the most efficient way for
a client (or group of clients) to merge with an earlier client or group that requested the same file, is to listen to
the latter's transmission stream, as well as one's own stream. One unit of time on the x-axis corresponds to the
Client Request Rate, N
Required
Server
Bandwidth Dyn Sky(1,1,2,2,4,4,.)

Figure

4: Required Server Bandwidth for Immediate Real Time File Delivery

total time it takes to deliver the file. One unit of data on the y-axis represents the total data for the file. The
solid lines in the figure represent data transmission streams, which always progress through the file at rate equal
to one unit of data per unit of time. The dotted lines show the amount of useful data that a client or group of
clients has accumulated as a function of time.
In the figure, requests arrive from clients A, B, C, and D at times 0, 0.1, 0.3, and 0.4, respectively. In order
to provide immediate service, each new client is provided a new multicast stream that initiates delivery of the
initial portion of the requested file. Client B also listens to the stream initiated by client A, accumulating data at
rate two, and merging with client A at time 0.2. Client D listens to the stream initiated by client C, and merges
with client C before client C can merge with client A. When C and D merge, both C and D listen to the streams
initiated by A and C until both clients have accumulated enough data to merge with clients A and B.
Note that a hierarchical merging structure would also be formed if clients C and D each listen to and
separately merge with the stream initiated by client A. In this case, the merge of clients C and A (which would
terminate the stream for C) would take place at time 0.6, and the merge of clients D and A (which would
terminate the stream for D) would take place at time 0.8. This alternate hierarchical merging structure, which
would occur in the patching technique with threshold larger than 0.4, would require greater server bandwidth for
delivering the file.
Variants of hierarchical multicast stream merging differ according to the precise policy used to determine
which clients to merge with what others, and in what order, as well as according to what (existing or new)
streams are listened to by clients so as to accomplish the desired merges. For homogeneous clients with receive
bandwidth equal to twice the streaming rate, [EaVZ99] proposes and evaluates several heuristic policies for
merging streams that are transmitted at the file play rate. One particularly simple proposed policy dictates that
each client listens to the closest target (i.e., the most recently initiated earlier stream that is still active) in
addition to its own stream, and that merges occur in time-order (i.e., earliest merge first). The policy
evaluations show that this closest target/earliest merge first (CT) policy performs nearly as well as the off-line
optimal merging policy (in which client request arrivals are known in advance, streams are delivered at the play
rate, and the merges that lead to least total server bandwidth are performed) [EaVZ99]. Hierarchical multicast
stream merging policies for homogeneous clients that have receive bandwidth less than twice the play rate are
considered in [EaVZ00]. On-going research considers other contexts.
5.2 Required Server Bandwidth for HMSM

Figure

6 provides the required server bandwidth for HMSM(2,1), as obtained from simulation, assuming
Poisson arrivals and optimal merges that are computed from known client request arrival times using a dynamic
programming technique adapted from [AgWY96a]. As shown in [EaVZ99], there are simple heuristics for0.10.30.50.70.91.1
Time
Position
in
Media
stream and
progress for
client A
Merged stream
and progress for
clients A and B
Merged stream for
clients C and D
stream for
client B
Progress for
clients C and D
Progress for client D
Stream for Client D
Merged stream and progress
for clients A,B,C,D

Figure

5: Example of Hierarchical Multicast Stream Merging
determining merges with unknown future client request arrival times, such as closest target/earliest merge first,
that yield very nearly the same performance as for the offline optimal merges considered here. Also shown in
the figure are the lower bound given in equation (5), and the required server bandwidths for SSLRE(2,1), for
optimized stream tapping/patching, and for the dynamic skyscraper system with progression 1,1,2,2,4,4,8,8,.
and optimal choices of K and W. The results show that HMSM(2,1) yields uniformly good performance,
substantially improving on previous techniques. In fact, HMSM(2,1) has nearly identical performance to
SSLRE(2,1), which suggests that there is little scope for further improvement for policies that are simple to
implement, assuming that B SSLRE(n,1) provides accurate insight into the lower bound on required server
bandwidth when streams are transmitted at the file play rate, which seems likely to be the case. Note that the
similarity in performance between HMSM(2,1) and SSLRE(2,1) is also perhaps surprising, given the simplicity
of the HMSM streams as compared with the complexity of SSLRE segment schedules.
An analytic expression for the required server bandwidth for hierarchical multicast stream merging appears
to be quite difficult to obtain. However, for Poisson arrivals and N i - 1000, recalling from equation (6) that
B SSLRE(2,1) is approximately equal to 1.62 ln (N / 1.62 + 1), the results in Figure 6 show that the required server
bandwidth for HMSM(2,1) with Poisson arrivals is also reasonably well approximated by 1.62
Furthermore, an upper bound on the required bandwidth with optimal offline merging, client receive bandwidth
equal to twice the file play rate, and an arbitrary client request arrival process, derived in Appendix D, is as
follows:
line
optimaloff
Comparing this upper bound with the approximation for Poisson arrivals shows that the bound is quite
conservative for bursty client request arrivals. However, the bound demonstrates that the required server
bandwidth for HMSM with client receive bandwidth equal to twice the play rate, is logarithmic in the client
request rate for any request arrival pattern.
5.3 Finite Buffer Space and Client Interactivity
This paper has thus far discussed and analyzed multicast delivery techniques assuming that clients can
buffer all data that is received ahead of its scheduled playback time, and assuming the client does not perform
any interactive functions such as pause, rewind, fast forward, skip back, or skip ahead. On the other hand, each
of the techniques is easily extended to handle either limited client storage or interactive client requests. For
example, Sen et al. have explored how the stream tapping/patching delivery technique should be modified to
accommodate constrained client buffer space [SGRT99].
For the HMSM technique, if a client does not have the buffer space to implement a given merge, that
particular merge is simply not scheduled. The impact of limited client buffer space on the performance of
HMSM is studied in [EaVZ99] for client receive bandwidth equal to twice the play rate, and in [EaVZ00] for
Required
Server
Bandwidth Opt imized Patching
Dyn Sky(1,1,2,2,4,4,.)

Figure

Required Server Bandwidth for Hierarchical Multicast Stream Merging
Client Request Rate, N14
client receive bandwidth less than twice the file play rate. Both studies show that, if clients can store 5-10% of
the full file and client request arrivals are Poisson, the impact of limited client buffer space on required server
bandwidth is fairly small [EaVZ99, EaVZ00]. The intuitive explanation for this result is that when client
requests are bursty, buffer space equal to 5-10% of the file enables most of the merges to take place.
The HMSM technique is also easily extended for interactive client requests. For example, with fast
forward, the client is given a new multicast stream during the fast forward operation, and when the fast forward
operation is complete, the new stream is merged with other streams as in the standard HMSM policy. Similarly,
for pause, rewind, skip back/ahead, or other interactive requests, the client is given a new stream at the start or
end of the interactive request (as appropriate), and the new stream is merged with other streams at the end of the
interactive operation. Disk storage techniques that support many of the interactive functions are discussed, for
example, in [SaMR00]. The required server bandwidth for supporting interactive functions depends on the
frequency, type, and duration of the interactive requests. The extra server bandwidth needed during the
interactive requests will be the same for all multicast delivery techniques. Exploring the full impact of client
interactivity on the relative required server bandwidth for various delivery techniques is left for future work.
6 Conclusions
This paper has investigated the required server bandwidth for on-demand real-time delivery of large
popular data files, assuming that a multicast capability is available so that multiple clients can share reception of
a single data transmission. As explained in Section 1, we defined required server bandwidth to be the average
server bandwidth used to deliver a file with a given client request rate, when the server has unlimited (disk and
network) bandwidth.
We developed a new implementation of the partitioned dynamic skyscraper delivery technique that provides
immediate service to clients more simply and easily than the original dynamic skyscraper technique. We
defined a method for determining the optimal parameters (i.e., K and W) of this new dynamic skyscraper system
for a given client request rate, and derived the required server bandwidth, which is logarithmic with a constant
factor between two and three in the client request rate. Thus, at moderate to high client request rates, the
dynamic skyscraper system outperforms the optimized stream tapping/patching/controlled multicast technique,
which has required server bandwidth that increases with the square root of the client request rate.
We derived a tight lower bound on the server bandwidth required for any technique that provides
immediate real-time service, and found that this bandwidth must grow at least logarithmically with the client
request rate. By defining and analyzing the required server bandwidth for a new family of delivery techniques
with complex and fragmented segment delivery schedules (SSLRE(n,r)), we showed that required server
bandwidth generally increases as client receive bandwidth (n) decreases, but that for client receive bandwidth
equal to twice the file play rate there is potential for required server bandwidth to be no more than 25%-62%
greater than the lower bound. The results for SSLRE(n,r) also demonstrated that for client receive bandwidth
less than twice the file play rate (i.e., n < 2) there is potential for required server bandwidth to increase only
logarithmically with a small constant factor as client request rate increases.
We proposed a new practical delivery method, hierarchical multicast stream merging (HMSM), which
merges clients into larger and larger groups that share multicast streams, without altering the client play rate.
This new technique has a number of important advantages. First, it is simple to implement and it is easily
extended to operate in the presence of interactive client requests. Second HMSM with outperforms the
optimized stream tapping/patching and optimized dynamic skyscraper techniques at all client request rates, and
not much further improvement in required server bandwidth is possible. The HMSM technique with
also competitive with static broadcast techniques at high client request rates (and is far superior to static
broadcast techniques when client request rate is low or varying). For example, if on average 1000 client
requests arrive during the time it takes to transmit the full file at the file play rate, the required server bandwidth
for providing immediate real-time service to each client using HMSM (n=2) is approximately equal to 10
streams at the file play rate. (Efficient HMSM techniques with n < 2 are defined in [EaVZ00].) Finally, the
slow logarithmic increase in required server bandwidth as a function of client request rate implies that the
HMSM delivery technique could be used to offer a new service to clients that join a live multicast after it has
begun, namely each such client could start at an earlier point in the multicast and then catch up to the live
multicast stream, without much increase in the server bandwidth expended on the live multicast. Note also that,
like the other multicast delivery methods examined in this paper, the HMSM delivery technique is not dependent
on any particular form of multicast support in the network. IP multicast, application-level multicast, broadband
satellite or cable broadcast, or other multicast mechanisms can be used to deliver the HMSM data streams.
On-going research includes: (1) designing HMSM policies for composite objects and for clients with
heterogeneous receive bandwidths and storage capacities, (2) evaluating the impact of file indexing and client
interactive functions on required server bandwidth for HMSM, (3) developing optimal real-time delivery
techniques that support recovery from packet loss, (4) developing optimized caching models and strategies
[EaFV99, EaFV00] for HMSM systems, (5) designing and evaluating disk load balancing strategies for HMSM
systems, and (6) the design and implementation of a prototype system that supports experimental evaluation of
alternative delivery techniques and caching strategies.



--R

"On Optimal Piggyback Merging Policies for Video-On-Demand Systems"
"A Permutation Based Pyramid Broadcasting Scheme for Video- On-Demand Systems"
"Analysis of Educational Media Server Workloads"
"Tailored Transmissions for Efficient Near-Video-On-Demand Service"
"Optimizing Patching Performance"
"Improving Video-on-Demand Server Efficiency Through Stream Tapping"
"Scheduling Policies for an On-demand Video Server with Batching"
"Dynamic Skyscraper Broadcasts for Video-on-Demand"
"Optimized Regional Caching for On-Demand Data Delivery"
"Optimized Caching in Systems with Heterogeneous Client Populations"
"Optimal and Efficient Merging Schedules for Video-on- Demand Servers"
"Bandwidth Skimming: A Technique for Cost-Effective Video- on-Demand"
"Supplying Instantaneous Video-on-Demand Services Using Controlled Multicast"
"Reducing I/O Demand in Video-On-Demand Storage Servers"
"Skyscraper Broadcasting: A New Broadcasting Scheme for Metropolitan Video-on- Demand Systems"
"Patching: A Multicast Technique for True Video-On-Demand Services"
"Fast Data Broadcasting and Receiving Scheme for Popular Video Service"
Queueing Systems: Vol.
"Merging Video Streams in a Multimedia Storage Server: Complexity and Heuristics"
"A Hybrid Broadcasting Protocol for Video On Demand"
"Comparing Random Data Allocation and Data Striping in Multimedia Servers"
"Optimal Patching Schemes for Efficient Multimedia Streaming"
"Metropolitan Area Video-on-Demand Service using Pyramid Broadcasting"
--TR

--CTR
Yi Cui , Klara Nahrstedt, Layered peer-to-peer streaming, Proceedings of the 13th international workshop on Network and operating systems support for digital audio and video, June 01-03, 2003, Monterey, CA, USA
Zheng , Guobin Shen , Shipeng Li, Distributed prefetching scheme for random seek support in peer-to-peer streaming applications, Proceedings of the ACM workshop on Advances in peer-to-peer multimedia streaming, November 11-11, 2005, Hilton, Singapore
Chow-Sing Lin , Yi-Chi Cheng, P2MCMD: A scalable approach to VoD service over peer-to-peer networks, Journal of Parallel and Distributed Computing, v.67 n.8, p.903-921, August, 2007
Yanping Zhao , Derek L. Eager , Mary K. Vernon, Scalable on-demand streaming of nonlinear media, IEEE/ACM Transactions on Networking (TON), v.15 n.5, p.1149-1162, October 2007
Liqi Shi , Phillipa Sessini , Anirban Mahanti , Zongpeng Li , Derek L. Eager, Scalable streaming for heterogeneous clients, Proceedings of the 14th annual ACM international conference on Multimedia, October 23-27, 2006, Santa Barbara, CA, USA
Klara Nahrstedt , Bin Yu , Jin Liang , Yi Cui, Hourglass multimedia content and service composition framework for smart room environments, Pervasive and Mobile Computing, v.1 n.1, p.43-75, March 2005
Juan Segarra , Vicent Cholvi, Convergence of periodic broadcasting and video-on-demand, Computer Communications, v.30 n.5, p.1136-1141, March, 2007
Marcus Rocha , Marcelo Maia , talo Cunha , Jussara Almeida , Srgio Campos, Scalable media streaming to interactive users, Proceedings of the 13th annual ACM international conference on Multimedia, November 06-11, 2005, Hilton, Singapore
Marcelo Maia , Marcus Rocha , talo Cunha , Jussara Almeida , Srgio Campos, Network bandwidth requirements for optimized streaming media transmission to interactive users, Proceedings of the 12th Brazilian symposium on Multimedia and the web, November 19-22, 2006, Natal, Rio Grande do Norte, Brazil
Xiaobo Zhou , Cheng-Zhong Xu, Efficient algorithms of video replication and placement on a cluster of streaming servers, Journal of Network and Computer Applications, v.30 n.2, p.515-540, April, 2007
Anirban Mahanti , Derek L. Eager , Mary K. Vernon , David J. Sundaram-Stukel, Scalable on-demand media streaming with packet loss recovery, IEEE/ACM Transactions on Networking (TON), v.11 n.2, p.195-209, April
Meng Guo , Mostafa H. Ammar , Ellen F. Zegura, Selecting among replicated batching video-on-demand servers, Proceedings of the 12th international workshop on Network and operating systems support for digital audio and video, May 12-14, 2002, Miami, Florida, USA
Anirban Mahanti , Derek L. Eager , Mary K. Vernon , David Sundaram-Stukel, Scalable on-demand media streaming with packet loss recovery, ACM SIGCOMM Computer Communication Review, v.31 n.4, p.97-108, October 2001
Haonan Tan , Derek L. Eager , Mary K. Vernon , Hongfei Guo, Quality of service evaluations of multicast streaming protocols, ACM SIGMETRICS Performance Evaluation Review, v.30 n.1, June 2002
Bashar Qudah , Nabil J. Sarhan, Towards scalable delivery of video streams to heterogeneous receivers, Proceedings of the 14th annual ACM international conference on Multimedia, October 23-27, 2006, Santa Barbara, CA, USA
Haonan Tan , Derek L. Eager , Mary K. Vernon, Delimiting the range of effectiveness of scalable on-demand streaming, Performance Evaluation, v.49 n.1-4, p.387-410, September 2002
Niklas Carlsson , Derek L. Eager , Mary K. Vernon, Multicast protocols for scalable on-demand download, Performance Evaluation, v.63 n.9, p.864-891, October 2006
Huadong Ma , G. Kang Shin , Weibiao Wu, Best-Effort Patching for Multicast True VoD Service, Multimedia Tools and Applications, v.26 n.1, p.101-122, May       2005
Wun-Tat Chan , Tak-Wah Lam , Hing-Fung Ting , Prudence W. H. Wong, On-line stream merging in a general setting, Theoretical Computer Science, v.296 n.1, p.27-46, 4 March
Yanping Zhao , Derek L. Eager , Mary K. Vernon, Network bandwidth requirements for scalable on-demand streaming, IEEE/ACM Transactions on Networking (TON), v.15 n.4, p.878-891, August 2007
Xiaobo Zhou , Cheng-Zhong Xu, Harmonic Proportional Bandwidth Allocation and Scheduling for Service Differentiation on Streaming Servers, IEEE Transactions on Parallel and Distributed Systems, v.15 n.9, p.835-848, September 2004
Shudong Jin , Azer Bestavros, G
ISMO
Ying Cai , Zhan Chen , Wallapak Tavanapong, Caching collaboration and cache allocation in peer-to-peer video systems, Multimedia Tools and Applications, v.37 n.2, p.117-134, April     2008
Zongpeng Li , Anirban Mahanti, A progressive flow auction approach for low-cost on-demand P2P media streaming, Proceedings of the 3rd international conference on Quality of service in heterogeneous wired/wireless networks, August 07-09, 2006, Waterloo, Ontario, Canada
Stergios V. Anastasiadis , Rajiv G. Wickremesinghe , Jeffrey S. Chase, Circus: Opportunistic Block Reordering for Scalable Content Servers, Proceedings of the 3rd USENIX Conference on File and Storage Technologies, March 31-31, 2004, San Francisco, CA
Shudong Jin , Azer Bestavros, Scalability of multicast delivery for non-sequential streaming access, ACM SIGMETRICS Performance Evaluation Review, v.30 n.1, June 2002
Stergios V. Anastasiadis , Kenneth C. Sevcik , Michael Stumm, Scalable and fault-tolerant support for variable bit-rate data in the exedra streaming server, ACM Transactions on Storage (TOS), v.1 n.4, p.419-456, November 2005
video-on-demand;streaming media;scalable protocols;performance evaluation;multicast