Distributing streaming media content using cooperative networking.
In this paper, we discuss the problem of distributing streaming media content, both live and on-demand, to a large number of hosts in a scalable way. Our work is set in the context of the traditional client-server framework. Specifically, we consider the problem that arises when the server is overwhelmed by the volume of requests from its clients. As a solution, we propose Cooperative Networking (CoopNet), where clients cooperate to distribute content, thereby alleviating the load on the server. We discuss the proposed solution in some detail, pointing out the interesting research issues that arise, and present a preliminary evaluation using traces gathered at a busy news site during the flash crowd that occurred on September 11, 2001.
INTRODUCTION
There has been much work in recent years on the topic of
content distribution. This work has largely fallen into two cat-
egories: (a) infrastructure-based content distribution, and (b)
peer-to-peer content distribution. An infrastructure-based
content distribution network (CDN) (e.g., Akamai) complements
the server in the traditional client-server framework. It
employs a dedicated set of machines to store and distribute
content to clients on behalf of the server. The dedicated in-
frastructure, including machines and networks links, is engineered
to provide a high level of performance guarantees.
On the other hand, peer-to-peer content distribution relies
on clients to host content and distribute it to other clients.
The P2P model replaces rather than complements the client-server
framework. Typically, there is no central server that
holds content. Examples of P2P content distribution systems
include Napster and Gnutella.
In this paper, we discuss Cooperative Networking (Coop-
Net), an approach to content distribution that combines aspects
of infrastructure-based and peer-to-peer content distri-
bution. Our focus is on distributing streaming media content,
both live and on-demand. Like infrastructure-based content
distribution, we seek to complement rather than replace the
traditional client-server framework. Specically, we consider
the problem that arises when the server is overwhelmed by the
volume of requests from its clients. For instance, a news site
may be overwhelmed because of a large \
ash crowd" caused
by an event of widespread interest, such as a sports event or an
earthquake. A home computer that is webcasting a birthday
For more information, please visit the CoopNet project Web
page at http://www.research.microsoft.com/ e padmanab/pro-
jects/CoopNet/.
party live to friends and family might be overwhelmed even
by a small number of clients because of its limited network
bandwidth. In fact, the large volume of data and the relatively
high bandwidth requirement associated with streaming
media content increases the likelihood of the server being
overwhelmed in general. Server overload can cause signicant
degradation in the quality of the streaming media content
received by clients.
CoopNet addresses this problem by having clients cooperate
with each other to distribute content, thereby alleviating the
load on the server. In the case of on-demand content, clients
cache audio/video clips that they viewed in the recent past.
During a period of overload, the server redirects new clients to
other clients that had downloaded the content previously. In
the case of live streaming, the clients form a distribution tree
rooted at the server. Clients that receive streaming content
from the server in turn stream it out to one or more of their
peers.
The key distinction between CoopNet and pure P2P systems
like Gnutella is that CoopNet complements rather than
replaces the client-server framework of the Web. There is still
a server that hosts content and (directly) serves it to clients.
CoopNet is only invoked when the server is unable to handle
the load imposed by clients. The presence of a central server
simplies the task of locating content. In contrast, searching
for content in a pure P2P system entails an often more
expensive distributed search [20, 21, 24].
Individual clients may only participate in CoopNet for a
short period of time, say just a few minutes, which is in contrast
to the much longer participation times reported for systems
such as Napster and Gnutella [23]. For instance, in the
case of live streaming, a client may tune in for a few minutes
during which time it may be willing to help distribute the con-
tent. Once the client tunes out, it may no longer be willing to
participate in CoopNet. This calls for a content distribution
mechanism that is robust against interruptions caused by the
frequent joining and leaving of individual peers.
To address this problem, CoopNet employs multiple description
coding (MDC). The streaming media content, whether
live or on-demand, is divided into multiple sub-streams using
MDC and each sub-stream is delivered to the requesting client
via a dierent peer. This improves robustness and also helps
balance load amongst peers.
The rest of this paper is organized as follows. In Section 2,
we discuss related work. In Section 3, we discuss the operation
of CoopNet for live and on-demand content, and present an
outline of multiple description coding. In Section 4, we use
traces from the
ash crowd that occurred on September 11,
2001 to evaluate how well CoopNet would have performed for
live and on-demand content. We present our conclusions in
Section 5.
2. RELATED WORK
As noted in Section 1, two areas of related work are infrastructure-based
CDNs and peer-to-peer systems. Infrastructure-based
CDNs such as Akamai employ a dedicated network of
thousands of machines in distributed locations, often with
leased links inter-connecting them, to serve content on behalf
of servers. When a client request arrives (be it for streaming
media or other content), the CDN redirects the client to a
nearby replica server. The main limitation of infrastructure-based
CDNs is that their cost and scale is only appropriate for
large commercial sites such as CNN and MSNBC. A second
issue is that it is unclear how such a CDN would fare in the
face of a large
ash crowd that causes a simultaneous spike
in tra-c at many or all of the sites hosted by the CDN.
Peer-to-peer systems such as Napster and Gnutella depend
on little or no dedicated infrastructure 1 . There is, however,
the implicit assumption that the individual peers participate
for a signicant length of time (for instance, [23] reports a
median session duration of about an hour both for Napster
and for Gnutella). In contrast, CoopNet seeks to operate in
a highly dynamic situation such as a
ash crowd where an
individual client may only participate for a few minutes. The
disruption that this might cause is especially challenging for
streaming media compared to static le downloads, which is
the primary focus of Napster and Gnutella. The short life-time
of the individual nodes poses a challenge to distributed
search schemes such as CAN [20], Chord [24], Pastry [21], and
Tapestry [29].
Work on application-level multicast (e.g., ALMI [17], End
System Multicast [3], Scattercast [2]) is directly relevant to
the live streaming aspect of CoopNet. CoopNet could benet
from the e-cient tree construction algorithms developed in
previous work. Our focus here, however, is on using real traces
to evaluate the e-cacy of CoopNet. Thus we view our work as
complementing existing work on application-level multicast.
We also consider the on-demand streaming case, which does
not quite t in the application-level multicast framework.
Existing work on distributed streaming (e.g., [13]) is also
directly relevant to CoopNet. A key distinction of our work
is that we focus on the distruption and packet loss caused
by node arrivals and departures, which is likely to be signi-
cant in a highly dynamic environment. Using traces from the
September 11
ash crowd, we are able to evaluate this issue
in a realistic setting.
Systems such as SpreadIt [5], Allcast [31] and vTrails [33]
are perhaps closest in spirit to our work. Like CoopNet, they
attempt to deliver streaming content using a peer-to-peer ap-
proach. SpreadIt diers from CoopNet is a couple of ways.
First, it uses only a single distribution tree and hence is vulnerable
to disruptions due to node departures. Second, the
tree management algorithm is such that the nodes orphaned
by the departure of their parent might be bounced around
between multiple potential parents before settling on a new
parent. In contrast, CoopNet uses a centralized protocol (Sec-
tion 3.3), which enables much quicker repairs.
It is hard for us to do a specic comparison with Allcast
1 Napster has central servers, but these only hold indices, not
content.
and vTrails, in the absence of published information.
3. COOPERATIVE NETWORKING (COOPNET)
In this section, we present the details of CoopNet as it
applies to the distribution of streaming media content. We
rst consider the live streaming case, where we discuss and
analyze multiple description coding (MDC) and distribution
tree management. We then turn to the on-demand streaming
case.
3.1 Live Streaming
Live streaming refers to the synchronized distribution of
streaming media content to one or more clients. (The content
itself may either be truly live or pre-recorded.) Therefore
multicast is a natural paradigm for distributing such content.
Since IP multicast is not widely deployed, especially at the
inter-domain level, CoopNet uses application-level multicast
instead.
A distribution tree rooted at the server is formed, with
clients as its members. Each node in the tree transmits the
received stream to each of its children using unicast. The out-degree
of each node is constrained by the available outgoing
bandwidth at the node. In general, the degree of the root
node (i.e., the server) is likely to be much larger than that of
the other nodes because the server is likely to have a much
higher bandwidth than the individual client nodes.
One issue is that the peers in CoopNet are far from being
dedicated servers. Their ability and willingness to participate
in CoopNet may
uctuate with time. For instance, a client's
participation may terminate when the user tunes out of the
live stream. In fact, even while the user is tuned in to the live
stream, CoopNet-related activity on his/her machine may be
scaled down or stopped immediately when the user initiates
other, unrelated network communication. Machines can also
crash or become disconnected from the network.
With a single distribution tree, the departure or reduced
availability of a node has a severe impact on its descendants.
The descendants may receive no stream at all until the tree
has been repaired. This is especially problematic because
node arrivals and departures may be quite frequent in
ash
crowd situations. To reduce the disruption caused by node
departures, we advocate having multiple distribution trees
spanning a given set of nodes and transmitting a dierent
MDC description down each tree. This would diminish the
chances of a node losing the entire stream (even temporarily)
because of the departure of another node. We discuss this
further in Section 3.2.
The distribution trees need to be constantly maintained as
new clients join and existing ones leave. In Section 3.3, we
advocate a centralized approach to tree management, which
exploits the availability of a resourceful server node, coupled
with client cooperation, to greatly simplify the problem.
3.2 Multiple Description Coding (MDC)
Multiple description coding is a method of encoding the
audio and/or video signal into M > 1 separate streams, or
descriptions, such that any subset of these descriptions can
be received and decoded into a signal with distortion (with
respect to the original signal) commensurate with the number
of descriptions received; that is, the more descriptions re-
ceived, the lower the distortion (i.e., the higher the quality) of
encoder decoder encoder decoder
base layer

Figure

1: (a) Multiple description coding. (b) Layered
coding.
Bits
Distortion
R
Packet 3
Packet 4
Packet M
RS
Bit stream

Figure

2: Priority encoded packetization of a group
of frames (GOF). Any m out of M packets can recover
the initial Rm bits of the bit stream for the GOF.
the reconstructed signal. This diers from layered coding 2 in
that in MDC every subset of descriptions must be decodable,
whereas in layered coding only a nested sequence of subsets
must be decodable, as illustrated in Figure 1. For this extra
exibility, MDC incurs a modest performance penalty relative
to layered coding, which in turn incurs a slight performance
penalty relative to single description coding.
A simple MDC system for video might be the following.
The original video picture sequence is demultiplexed into M
subsequences, by putting every Mth picture, m
into the mth subsequence, . The
subsequences are independently encoded to form the M de-
scriptions. Any subset of these M descriptions can be decoded
and the pictures can be remultiplexed to reconstruct a video
sequence whose frame rate is essentially proportional to the
number of descriptions received.
More sophisticated forms of multiple description coding
have been investigated over the years; some highlights are [25,
26, 27, 6]. For an overview see [7]. A particularly e-cient and
practical system is based on layered audio or video coding [18,
Reed-Solomon coding [28], priority encoded transmission
[1], and optimized bit allocation [4, 19, 11, 12]. In such a system
the audio and/or video signal is partitioned into groups
of frames (GOFs), each group having duration
or so. Each GOF is then independently encoded, error
protected, and packetized into M packets, as shown in Figure
2. If any m  M packets are received, then the initial
Rm bits of the bit stream for the GOF can be recovered, re-
Layered coding is also known as embedded, progressive, or
scalable coding.
description
description
description
GOF i-1 GOF i+1 .

Figure

3: Construction of MDC streams from packetized
GOFs.
sulting in distortion D(Rm ), where
and consequently D(R0 )  D(R1 )      D(RM ). Thus
all M packets are equally important; only the number of received
packets determines the reconstruction quality of the
GOF. Further, the expected distortion is
where p(m) is the probability that m out of M packets are re-
ceived. Given p(m) and the operational distortion-rate function
D(R), this expected distortion can be minimized using
a simple procedure that adjusts the rate points
subject to a constraint on the packet length [4, 19, 11, 12].
By sending the mth packet in each GOF to the mth descrip-
tion, the entire audio and/or video signal is represented by M
descriptions, where each description is a sequence of packets
transmitted at rate 1 packet per GOF, as illustrated in Figure
3. It is a very simple matter to generate these optimized
M descriptions on the
y, assuming that the signal is already
coded with a layered codec.
3.2.1 CoopNet Analysis: Quality During Multiple Failures
Let us consider how multiple description coding achieves
robustness in CoopNet. Suppose that the server encodes its
AV signal into M descriptions as described above, and transmits
the descriptions down M dierent distribution trees,
each rooted at the server. Each of the distribution trees conveys
its description to all N destination hosts. Ordinarily, all
destination hosts receive all M descriptions. However, if
any of the destination hosts fail (or leave the session), then
all of the hosts that are descendents of the failed hosts in
the mth distribution tree will not receive the mth descrip-
tion. The number of descriptions that a particular host will
receive depends on its location in each tree relative to the
failed hosts. Specically, a host n will receive the mth description
if none of its ancestors in the mth tree fail. This
happens with probability (1 ) An , where An is the number
of the host's ancestors and  is the probability that a host fails
(assuming independent failures). If hosts are placed at random
sites in each tree, then the unconditional probability that
any given host will receive its mth description is the average
hosts in the tree. Thus
the number of descriptions that a particular host will receive is
randomly distributed according to a Binomial(M; N ) distri-
bution, i.e.,
. Hence for large M ,
the fraction of descriptions received is approximately Gaussian
with mean N and variance N (1 N ). This can be seen
in

Figure

4, which shows (in bars) the distribution p(m) for
various values of In
the gure, to compute N we assumed balanced binary trees
with N nodes and probability of host failure
that as N grows large, performance slowly degrades, because
the depth of the tree (and hence 1 N ) grows like log 2 N .
The distribution p(m) can be used to optimize the multiple
description code by choosing the rate points R0 ;

Figure

4: SNR in dB (line) and probabililty distribution
(bars) as a function of the number of descriptions
received, when the probability of host failure is
to minimize the expected distortion P M
subject
to a packet length constraint. Figure 4 shows (in lines),
the quality associated with each p(m), measured as SNR in
as a function of the number
of received descriptions, . In the gure, to
compute the rate points R0 ; we assumed an operational
distortion-rate function which is
asymptotically typical for any source with variance  2 , where
R is expressed in bits per symbol, and we assumed a packet
length constraint given as
3.2.2 CoopNet Analysis: Quality During Single Failure
The time it takes to repair the trees is called the repair
time. If  of the hosts fail during each repair time, then the
average length of time that a host participates in the session
is 1= repair times. When the number of hosts is small
compared to 1=, then many repair times may pass between
single failures. In this case, most of the time all hosts receive
all descriptions, and quality is excellent. Degradation occurs
only when a single host fails. Thus, it may be preferable
to optimize the MDC system by minimizing the distortion
expected during the repair interval in which the single host
fails, rather than minimizing the expected distortion over all
time. To analyze this case, suppose that a single host fails
randomly. A remaining host n will not receive the mth description
if the failed host is an ancestor of host n in the
mth tree. This happens with probability An=(N 1), where
An is the number of ancestors of host n. Since hosts are
place at random sites in each tree, the unconditional probability
that any given host will receive its mth description is
the average
1)). Thus the
number of descriptions that a particular host will receive is
randomly distributed according to a Binomial(M; N ) distri-
bution. Equivalently, the expected number of hosts that receive
descriptions during the failure is (N 1)p(m), where
This distribution can be used to
optimize the multiple description code for the failure of a single
host. Figure 5 illustrates this distribution and the corresponding
optimized quality as a function of the number of descriptions
received, for
Note that as M increases, for xed N , the distribution again
becomes Gaussian. One implication of this is that the expected
number of hosts that receive 100% of the descriptions

Figure

5: SNR in dB (line) and probabililty distribution
(bars) as a function of the number of descriptions
received during the failure of a single host.
decreases. However it is also the case that the expected number
of hosts that receive fewer than 50% of the descriptions
decreases, resulting in an increase in quality on average. Fur-
ther, as N increases, for xed M , performance becomes nearly
perfect, since N  1 log 2 N=N , which goes to 1. However,
for large N , it becomes increasingly di-cult to repair the trees
before a second failure occurs.
3.2.3 Further Analyses
These same analyses can be extended to d-ary trees. It
is not di-cult to see that for d  2, a d-ary trees with
log 2 d  N nodes has the same height, and hence the same
performance, as a binary tree with only N nodes. Thus when
each node has a large out-degree, i.e., when each host has a
large uplink bandwidth, much larger populations can be han-
dled. Interestingly, the analysis also applies when
if each host can devote only as much uplink bandwidth as
its downlink video bandwidth (which is typically the case for
modem users), then the descriptions can still be distributed
peer-to-peer by arranging the hosts in a chain, like a bucket
brigade. It can be shown that when the order of the hosts
in the chain is random and independent for each description,
then for a single failure the number of hosts receiving m out
of M descriptions is binomially distributed with parameters
M and N , where . Although this holds
for any N , it is most suitable for smaller N . For larger N , it
may not be possible to repair the chains before other failures
occur. In fact, as N goes to innity, the probability that any
host receives any descriptions goes to zero.
In this section we have proposed optimizing the MDC system
to the unconditional distribution p(m) derived by averaging
over trees and hosts. Given any set of trees, however,
the distribution of the number of received descriptions varies
widely across the set of hosts as a function of their upstream
connectivity. By optimizing the MDC system to the unconditional
distribution p(m), we are not minimizing the expected
distortion for any given host, but rather minimizing the sum
of the expected distortions across all hosts, or equivalently,
minimizing the expected sum of the distortions over all hosts.
3.3 Tree Management
We now discuss the problem of constructing and maintaining
the distribution trees in the face of frequent node arrivals
and departures. There are many (sometimes con
for the tree management algorithm:
1. Short and wide tree: The trees should be as short
as possible so as to minimize the latency of the path
from the root to the deepest leaf node and to minimize
the probability of disruption due to the departure of an
ancestor node. For it to be short, the tree should be
balanced and as wide as possible, i.e., the out-degree
of each node should be as much as its bandwidth will
allow. However, making the out-degree large may leave
little bandwidth for non-CoopNet (and higher priority)
tra-c emanating from the node. Interference due to
such tra-c could cause a high packet loss rate for the
CoopNet streams.
2. E-ciency versus tree diversity: The distribution
trees should be e-cient in that their structure should
closely re
ect the underlying network topology. So, for
instance, if we wish to connect three nodes, one each
located in New York (NY), San Francisco (SF), and
Los Angeles (LA), the structure NY!SF!LA would
likely be far more e-cient than SF!NY!LA (! denotes
a parent-child relationship). However, striving for
e-ciency may interfere with the equally important goal
of having diverse distribution trees. The eectiveness
of MDC-based distribution scheme described in Section
3.2 depends critically on the diversity of the distribution
trees.
3. Quick join and leave: The processing of node joins
and leaves should be quick. This would ensure that the
interested nodes would receive the streaming content
as quickly as possible (in the case of a join) and with
minimal interruption (in the case of a leave). However,
the quick processing of joins and leaves may interfere
with the e-ciency and balanced tree goals listed above.
4. Scalability: The tree management algorithm should
scale to a large number of nodes, with a correspondingly
high rate of node arrivals and departures. For instance,
in the extreme case of the
ash crowd at MSNBC on
September 11, the average rate of node arrivals and de-
parturtes was 180 per second while the peak rate was
about 1000 per second.
With these requirements in mind, we now describe our approach
to tree construction and management. We rst describe
the basic protocol and then discuss optimizations.
3.3.1 Basic Protocol
We exploit the presence of a resourceful server node to
build a simple and e-cient protocol to process node joins and
leaves. While it is centralized, we argue that this protocol can
scale to work well in the face of extreme
ash crowd situations
such as the one that occurred on September 11. Despite the
ash crowd, the server is not overloaded since the burden of
distributing content is shared by all peers. Centralization also
simplies the protocol greatly, and consequently makes joins
and leaves quick. In general, a criticism of centralization is
that it introduces a single point of failure. However, in the
context of CoopNet, the point of centralization is the server,
which is also the source of data. If the source (server) fails, it
may not really matter that the tree management also breaks
down. Also, recall from Section 1 that the goal of CoopNet is
to complement, not replace, the client-server system.
The server has full knowledge of the topology of all of the
distribution trees. When a new node wishes to join the sys-
tem, it rst contacts the server. The new node also informs
the server of its available network bandwidth to serve furture
downstream nodes. The server responds with a list of designated
parent nodes, one per distribution tree. The designated
parent node in each tree is chosen as follows. Starting at the
server, we work our way down the tree until we get to a level
where there are one or more nodes that have the necessary
spare capacity (primarily network bandwidth) to serve as the
parent of the new node. (The server could itself be the new
parent if it has su-cient spare capacity, which it is likely to
have during the early stages of tree construction.) The server
then picks one such node at random to be the designated parent
of the new node. This top-down procedure ensures a short
and largely balanced tree. The randomization helps make the
trees diverse. Upon receiving the server's message, the new
node sends (concurrent) messages to the designated parent
nodes to get linked up as a child in each distribution tree. In
terms of messaging costs, the server receives one message and
sends one. Each designated parent receives one message and
sends one (an acknowledgement). The new node sends and
receives is the number of MDC
descriptions (and hence distribution trees) used.
Node departures are of two kinds: graceful departures and
node failures. In the former case, the departing node informs
the server of its intention to leave. For each distribution tree,
the server identies the children of the departing node and
executes a join operation on each child (and implicitly the
subtree rooted at the child) using the top-down procedure
described above. The messaging cost for the server would at
most be P
receives, where d i is the number
of children of the departing node in the ith distribution
tree. (Note that the cost would be somewhat lower in general
because a few of the children may be in common across multiple
trees.) Each child sends and receives M messages.
To reduce its messaging load, the server could make the determination
of the designated parent for each child in each
tree and then leave it to another node (such as the departing
node, if it is still available) to convey the information to each
child. In this case, the server would have to send and receive
just one message.
A node failure corresponds to the case where the departing
node leaves suddenly and is unable to notify either the server
or any other node of its departure. This may happen because
of a computer crashing, being turned o, or becoming disconnected
from the network. We present a general approach for
dealing with quality degradation due to packet loss; node failure
is a special case where the packet loss rate experienced by
the descendants of the failed node is 100%. Each node monitors
the packet loss rate it is experiencing in each distribution
tree. When the packet loss rate reaches an unacceptable level
(a threshold that needs to be ne-tuned based on further re-
search), a node contacts its parent to check if the parent is
experiencing the same problem. If so, the source of the problem
(network congestion, node failure, etc.) is upstream of the
parent and the node leaves it to the parent to deal with it.
(The node also sets a su-ciently long timer to take action on
its own in case its parent has not resolved the problem within
a reasonable period of time.) If the parent is not experiencing
a problem or it does not respond, the aected node will contact
the server and execute a fresh join operation for it (and
its subtree) to be moved to a new location in the distribution
tree.
3.3.2 Optimizations
We now discuss a few optimizations of the basic protocol.
The rst optimization seeks to make the distribution trees
e-cient, as discussed above. The basic idea here is to preferentially
attach a new node as the child of an existing node
that is \nearby" in terms of network distance (i.e., latency).
The denition of \nearby" needs to be broad enough to accomodate
signicant tree diversity. When trying to insert a
new node, the server rst identies a (su-ciently large) sub-set
of nodes that are close to the new node. Then using the
randomized top-down procedure discussed in Section 3.3.1, it
tries to nd a parent for the new node (in each tree) among
the set of nearby nodes. Using this procedure, it is quite likely
that many of the parents of the new node (on the the various
distribution trees) will be in the same vicinity, which is ben-
ecial from an e-ciency viewpoint. We argue that this also
provides su-cient diversity since the primary failure mode we
are concerned with is node departures and node failures. So it
does not matter much that all of the parents may be located
in the same vicinity (e.g., same metropolitan area).
To determine the network distance between two nodes, we
use a procedure based on previous work on network distance
estimation [14], geographic location estimation [16], overlay
construction [20], and nding nearby hosts [8]. Each node determines
its network \coodinates" by measuring the network
latency (say using ping) to a set of landmark hosts (about
well-distributed landmark hosts should su-ce in practice).
The coordinate of a node is the n-tuple (d1
n is the number of landmarks. The server keeps track of the
coordinates of all nodes currently in the system (this information
may need to be updated from time to time). When
the new node contacts it, the server nds nearby nodes by
comparing the coordinates of the new node with those of existing
nodes. This comparison could involve computing the
Eucledian distance between the coordinates of two nodes (as
in [16]), computing a dierent distance metric such as the
Manhattan distance, or simply comparing the relative ordering
the various landmarks based on the measured latency (as
in [20]).
The second optimization is motivated by the observation
that it would be benecial to have have more \stable" nodes
close to the root of the tree. In this context, \stable" nodes
are ones that are likely to participate on CoopNet for a long
duration and have good network connectivity (e.g., few dis-
truptions due to competing tra-c from other applications).
Having such nodes close to the root of the tree would benet
their many descendants. As a background process, the server
could identify stable nodes by monitoring their past behavior
and migrate them up the tree. Further research is needed to
determine the feasibility of identifying stable nodes, the ben-
ets of migrating such nodes up the tree, and the impact this
might have on tree diversity.
3.3.3 Feasibility of the Centralized Protocol
The main question regarding the feasibility of the centralized
tree management protocol is whether the server can keep
up. To answer this question, we consider the September 11
ash crowd at MSNBC, arguably an extreme
ash crowd sit-
uation. At its peak, there were 18,000 nodes in the system
and the rate of node arrivals and departures was 1000 per
second. 3 (The average numbers were 10000 nodes and 180
arrivals and departures per second.) In our calculations here,
we assume that the number of distribution trees (i.e., the
number of MDC descriptions) is 16 and that on average a
node has 4 children in a tree. We consider various resources
that could become a bottleneck at the server (we only focus
on the impact of tree management on the server):
Memory: To store the entire topology of one tree in
memory, the server would need to store as many pointers
as nodes in the system. Assuming a pointer size of
8 bytes (i.e., a 64-bit machine) and auxiliary data of 24
bytes per node, the memory requirement would be about
576 KB. Since there are 16 trees, the memory requirement
for all trees would be 9.2 MB. In addition, for each
node the server needs to store its network coordinates.
Assuming this is a 10-dimensional vector of delay values
bytes each), the additional memory requirement
would be 360 KB. So the total memory requirement at
the server would be under 10 MB, which is a trivial
amount for any modern machine.
Network departures are more expensive
than node arrivals, so we focus on departures.
The server needs to designate a new parent in each distribution
tree for each child of the departing node. Assuming
that nodes are identied by their IP addresses
bytes assuming IPv6) and that there are 4 children
per tree on average, the total amount of data that the
server would need to send out is 1 KB. If there are
1000 departures per second, the bandwidth requirement
would be 8 Mbps. This is likely to be a small fraction
of the network bandwidth at a large server site such as
MSNBC.
CPU: Node departure involves nding a new set of parents
for each child of the departing node. So the CPU
cost is roughly equal to the number of children of the departing
node times the cost of node insertion. To insert
a node, the server has to scan the tree levels starting
with the root until it reaches a level containing one or
more nodes with the spare capacity to support a new
child. The server picks one such node at random to be
the new parent. Using a simple array data structure to
keep track of the nodes in each level of the tree that have
capacity, the cost of picking a parent at random can
be made (a small) constant. Since the number of levels
in the tree is about log(N ), where N is the number of
nodes in the system, the node insertion cost (per tree)
is O(log(N)). (With and an average of 4
children per node, the depth of the tree will be about
9.)
A departure rate of 1000 per second would result in
64,000 insertions per second (1000 departures times 4
children per departing node times 16 trees). Given that
memory speed by far lags CPU speed, we only focus
on how many memory lookups we can do per insertion.
Assuming a 40 ns memory cycle, we are allowed about
memory accesses per insertion, which is likely to be
more than su-cient.
3 One reason for the high rate of churn may be that users were
discouraged by the degradation in audio/video quality caused
by the
ash crowd, and so did not stay for long. However, we
are not in a position to conrm that this was the case.
In general, the centralized approach can be scaled up (at
least in terms of CPU and memory resources) by having a
cluster of servers and partitioning the set of clients across the
set of server nodes.
We are in the process of benchmarking our implementation
to conrm the rough calculations made above.
3.3.4 Distributed Protocol
While the centralized tree management protocol appears
to be adequate for large
ash crowd situations such as that
experienced by MSNBC on September 11, it is clear that there
are limits to its scalability. For instance, in the future it is
conceivable that
ash crowds for streaming media content on
the Web will in some cases be as large as television audiences
during highly popular events | hundreds of millions or even
billions of clients. A centralized solution may break down in
such a situation, necessitating an alternative approach to tree
management.
We could leverage recent work on distributed hash tables
(DHTs), such as CAN [20], Chord [24], Pastry [21], and Tapestry
[29], to build construct and maintain the trees in a distributed
fashion. Brie
y, DHTs provide a scalable unicast routing
framework for peer-to-peer systems. A multicast distribution
tree can be constructed using reverse-path forwarding (as in
systems such as Bayeux [30] and Scribe [22]). To construct
multiple (and diverse) distribution trees, each node could be
assigned multiple IDs, one per tree.
There are a number of open research issues. First, while
there exist algorithms to support node joins and leaves, the
dynamic behavior of DHTs is poorly understood. Second,
it is unclear how to incorporate constraints, such as limited
node bandwidth, into the DHT framework. Some systems
such as Pastry maintain multiple alternate routes at each hop.
This should make it easier to construct multicast trees while
accomodating node capacity constraints.
3.4 On-demand Streaming
We now turn to on-demand streaming, which refers to the
distribution of pre-recorded streaming media content on demand
(e.g., when a user clicks on the corresponding link). As
such, the streams corresponding to dierent users are not syn-
chronized. When the server receives such a request, it starts
streaming data in response if its current load condition per-
mits. However, if the server is overloaded, say because of a
ash crowd, it instead sends back a response including a short
list of IP addresses of clients (peers) who have downloaded
(part or all of) the requested stream and have expressed a
willingness to participate in CoopNet. The requesting client
then turns to one or more of these peers to download the
desired content. Given the large volume of streaming media
content, the burden on the server (in terms of CPU, disk, and
network bandwidth) of doing this redirection is quite minimal
compared to that of actually serving the content. So we
believe that this redirection procedure will help reduce server
load by several orders of magnitude.
While the procedure described above is similar to one that
might apply to static le content, there are a couple of important
dierences arising from the streaming nature of the
content. First, a peer may only have a part of the requested
content because, for instance, the user may have stopped the
stream halfway or skipped over portions. So in its initial
handshake with a peer, a client nds out which part of the requested
content is available at the peer and accordingly plans
to make requests to other peers for the missing content, if any.
A second issue is that, as with the live streaming case, peers
may fail, depart, or scale back their participation in CoopNet
at any time. In contrast with le download, the time-sensitive
nature of streaming media content makes it especially susceptible
to such disruptions. As a solution, we propose the use of
distributed streaming where a stream is divided into a number
of substreams, each of which may be served by a dierent
peer. Each substream corresponds to a description created
using MDC (Section 3.2). Distributed streaming improves
robustness to disruptions caused by the untimely departure
of peer nodes and/or network connectivity problems with respect
to one or more peers. It also helps distribute load more
evenly among peers.
4. PERFORMANCE EVALUATION
We now present a performance evaluation of CoopNet based
on simulations driven by traces of live and on-demand content
served by MSNBC on September 11, 2001.
4.1 Live Streaming
We evaluate the MDC-based live streaming design using
traces of a 100kbps live stream. The trace started at 18:25
GMT (14:25 EST) and lasted for more than one hour (4000
seconds).
4.1.1 Trace Characteristics

Figure

6 shows the time series of the number of clients simultaneously
tuned in to the live stream. The peak number of
simultaneous clients exceeds 17,000. On average, there are 84
clients departing every second. (We are unable to denitely
explain the dip around the 1000-seond mark, but it is possibly
due to a glitch in the logging process.) Figure 7 shows
the distribution of client lifetimes. Over 70% of the clients
remain tuned in to the live stream for less than a minute. We
suspect that the short lifetimes could be because users were
frustrated by the poor quality the video stream during the
ash crowd. If the quality were improved (say using CoopNet
to relieve the server), client lifetimes may well become longer.
This, in turn, would increase the eectiveness of CoopNet.
4.1.2 Effectiveness of MDC
We evaluate the impact of MDC-based distribution (Sec-
tion 3.2) on the quality of the stream received by clients in
the face of client departures. When there are no departures,
all clients receive all of the MDC descriptions and hence perceive
the full quality of the live stream.
We have conducted two simulation experiments. In the
rst experiment, we construct completely random distribution
trees at the end of the repair interval following a client
departure. We then analyze the stream quality received by
the remaining clients. The random trees are likely to be diverse
(i.e., uncorrelated), which improves the eectiveness of
MDC-based distribution. In the second experiment, we simulate
the tree management algorithm described in Section 3.3.
Thus the distribution trees are evolved based on the node arrivals
and departures recorded in the trace. We compare the
results of these two experiments at the end of the section.
In more detail, we conducted the random tree experiment
as follows. For each repair interval, we construct M distribution
trees (corresponding to the M descriptions of the MDC
coder) spanning the N nodes in the system at the beginning
of the interval. Based on the number of departing clients, d,
Node Arrivals and Departures200060001000014000180000 500 1000 1500 2000 2500 3000 3500 4000
Time (seconds)
of
Nodes

Figure

Number of clients and departures.
Duration
Minutes
Percentage
of
Nodes

Figure

7: Duration distribution.

Table

1: Random Tree Experiment: probability distribution
of descriptions received vs. number of distribution
trees
recorded through the end of the repair interval, we randomly
remove d nodes from the tree, and compute the number of
descriptions received by the remaining nodes. The perceived
quality of the stream at a client is determined by the fraction
of descriptions received by that client. The set of distribution
trees is characterized by three parameters: the number
of trees (or, equivalently, descriptions), the maximum out-degree
of nodes in each tree, and the out-degree of the root
(i.e., the live streaming server). The out-degree of a node is
typically a function of its bandwidth capacity. So the root
(i.e., the server) tends to have a much larger out-degree than
bandwidth-constrained clients. In our random tree construc-
tion, each client is assigned a random degree subject to a
maximum. We varied the degree of the root and the number
of descriptions to study their impact on received stream qual-
ity. We set the repair time to 1 second; we investigate the
impact of repair time in Section 4.1.3.

Table

shows how the number of distribution trees, M , affects
the fraction of descriptions received (expressed as a per-
centage, P ). We compute the distribution of P by averaged
across all client departures. We set the maximum out-degree

Figure

8: Random Tree Experiment: SNR in dB
(line) and probabililty distribution (bars) as a function
of the number of descriptions received
Quality
(SNR
in
Time (seconds)
Random Trees
Multiple Descriptions (M=16)
Single Description (M=1)

Figure

9: Random Tree Experiment: The SNR over
time for the MDC and SDC cases. At each time in-
stant, we compute the average SNR over all clients.
of a client to 4 and the root degree to 100. We vary the
number of descriptions among 1, 2, 4, 8, or 16. Each column
represents a range of values of P . For each pair of the range
and number of descriptions, we list the average percentage
of clients that receive at that level of quality. For example,
the rst table entry indicates that when using 2 descriptions,
94.80% of clients receive 100% of the descriptions (i.e., both
the descriptions).
As the number of descriptions increases, the percentage of
clients that receive the all of the descriptions (i.e.,
decreases. Nonetheless, the percentage of clients corresponding
to small values of P decreases dramatically. With 8 de-
scriptions, 96% (82.07% + 14.02%) of clients receive more
than 87.5% of the descriptions. For both 8 and
tions, all clients receive at least one description. Figure 8
shows the corresponding SNR. Figure 9 compares the SNR
over time for the 16-description case and the single description
case. MDC demonstrates a clear advantage over
SDC.

Table

shows how the root degree aects the distribution
of descriptions received. We set the number of descriptions
to 8 and the maximum out-degree of a client to 4. As the
root degree increases, the distribution shows an improvement.

Figure

shows the SNR and probability distribution. Compared
to the case where all nodes (including the root) have the
same degree d, a root degree of R shortens the tree by log d R.
This means fewer ancestors for nodes in the tree, which as
discussed in Section 3.2 increases the probability that a node
will receive a particular description.
R 100% [87.5,100) [75,87.5) [50,75) [25,50) 0

Table

2: Random Tree Experiment: probability distribution
of the descriptions received vs. root degree

Figure

10: Random Tree Experiment: SNR in dB
(line) and probabililty distribution (bars) as a function
of the number of descriptions received and the
root degree

Table

3: Evolving Tree Experiment: probability distribution
of descriptions received vs. number of distribution
trees
In our second experiment, we evolved the distribution trees
by simulating the tree management algorithm from Section
3.3. We set the root (i.e., server) out-degree to 100. The
maximum out-degree of a client is set to 4. Table 3 shows
the probability distribution of the descriptions received upon
client departures. Figure 11 shows the corresponding SNR.
The results are comparable to those of the random tree ex-
periment. This suggests that our tree management algorithm
is able to preserve signicant tree diversity even over a long
period of time (more than an hour in this case).
4.1.3 Impact of Repair Time
Finally, we evaluate the impact of the time it takes to repair
the tree following a node departure. Clearly, the longer the
repair time, the greater is the impact on the aected nodes.
Also, a longer repair time increase the chances of other nodes
departing before the repair is completed, thereby causing further
disruption.
We divide time into non-overlapping repair intervals and assume
that all leaves happen at the beginning of each interval.
We then compute fraction of descriptions received averaged
over all nodes (this is the quantity N discussed in Section
3.2). As in Section 3.2, assume a balanced binary tree at all
times.

Figure

12 shows the average number of descriptions received
as a function of time for four dierent settings of repair time:
seconds. With a repair time of 1 second, clients
would receive 90% of the descriptions on average. With a 10
second repair time, the fraction drops to 30%. We believe that
these results are encouraging since in practice tree repair can
be done very quickly, especially given that our tree management
algorithm is centralized (Section 3.1). Even a 1-second

Figure

Evolving Tree Experiment: SNR in dB
(line) and probabililty distribution (bars) as a function
of the number of descriptions received0.10.30.50.70.90 500 1000 1500 2000 2500 3000 3500 4000
Time (seconds)
Average
fraction
of
descriptions
received

Figure

12: The average fraction of descriptions received
for various repair times.
repair interval would permit multiple round-trips between the
server and the nodes aected by the repair (e.g., the children
of the departed node).
4.2 On-Demand Streaming
We now evaluate the potential of CoopNet in the case of on-demand
streaming. The goals of our evaluation are to study
the eects of client cooperation on:
reduction in load at the server
additional load incurred by cooperating peers
amount of storage provided by cooperating peers
likelihood of cooperating with proximate peers to improve
performance.
The cooperation protocol used in our simulations is based
on server redirection as in [15]. The server maintains a xed-
size list of IP addresses (per URL) of CoopNet clients that
have recently contacted it. To get content, a client initially
sends a request to the server. If the client is willing to co-
operate, the server redirects the request by returning a short
list of IP addresses of other CoopNet clients who have recently
requested the same le. In turn, the client contacts
these other CoopNet peers and arranges to retrieve the content
directly from them. Each peer may have a dierent portion
of the le, so it may be necessary to contact multiple
peers for content. In order to select a peer (or a set of peers
when using distributed streaming) to download content from,
peers run a greedy algorithm that picks out the peer(s) with
the longest portion of the le from the list returned by the
server. If a client cannot retrieve content through any peer,
it retrieves the entire content from the server. Note that the
server only provides the means for discovering other CoopNet
peers. Peers independently decide who they cooperate with.
The server maintains a list of 100 IP addresses per URL, and
returns a list of 10 IP addresses in the redirection messages
in our simulations.
We use traces collected at MSNBC during the
ash crowd
of Sep 11, 2001 for our evaluation. The
ash crowd started
at around 1:00 pm GMT (9:00 am EDT) and persisted for
the rest of the day. The peak request rate was three orders
of magnitudes more than the average. We report simulation
results for the beginning of the
ash crowd, between 1:00 pm
to 3:00 pm GMT. There were over 300,000 requests during
the 2-hour period. However, only 6% or 18,000 requests were
Time of Day
Average
Bandwidth
(bps)
Server
Server (CoopNet)
Clients (CoopNet)
(a) Average bandwidth at server and cooperating peers.
Degree of Parallelism
Average
Bandwidth
of
CoopNet
Clients
(bps)
(b) Average bandwidth at peers when using distributed streaming.
100.10.30.50.70.9Bandwidth of Active Peers (bps)
Cumulative
Distribution
(Least Loaded)
(c) Distribution of bandwidth at active peers.

Figure

13: Performance of CoopNet for on-demand
streaming.
successfully served at an average rate of 20 Mbps with a mean
session duration of 20 minutes. Unsuccessful requests were
not used in the analysis because of the lack of content byte-
range and session duration information.
4.2.1 Bandwidth Load
In our evaluation, load is measured as bandwidth usage.
We do not model available bandwidth between peers. We
assume that peers can support the full bit rate (56 kbps, 100
kbps) of each encoded stream. We also do not place a bound
on the number of concurrent connections at each peer. In
practice, nding peers with su-cient available bandwidth and
not overloading any one peer are important considerations,
and we are investigating these issues in ongoing work.

Figure

13(a) depicts the bandwidth usage during the 2-hour
period for two systems: the traditional client-server system,
and the CoopNet system. The vertical axis is average band-width
and the horizontal axis is time. There are two peaks
at around 1:40 pm and 2:10 pm, when two new streams were
added to the server. In the client-server system, the server
was distributing content at an average of 20 Mbps. However,
client cooperation can reduce that bandwidth by orders of
magnitude to an average of 300 kbps. As a result, the server
is available to serve more client requests. The average band-width
contribution that CoopNet clients need to make to the
system is 45 kbps. Although the average bandwidth contribution
is reasonably small, peers are not actively serving content
all the time. We nd that typically less than 10% of peers are
active at any second. The average bandwidth contribution
that active CoopNet peers need to make to the system is as
high as 465 kbps, where average bandwidth of active peers is
computed as the total number of bits served over the total
length of peers' active periods.
To further reduce load at individual CoopNet clients, disjoint
portions of the content can be retrieved in parallel from
multiple peers using distributed streaming (Section 3.4). (The
bandwidth requirement placed on each peer is correspondingly
reduced.) Figure 13(b) depicts the average bandwidth
contributed versus the degree of parallelism. The degree of
parallelism is an upper-bound on the number of peers that can
be used in parallel. For example, clients can retrieve content
from up to 5 peers in parallel in a simulation with a degree of
parallelism of 5. The actual number of peers used in parallel
may be less than 5 depending on how many peers can provide
content in the byte-range needed by the client. The load
at each active peer is reduced as the degree of parallelism in-
creases. When the degree of parallelism is 5, peers are serving
content at only 35 kbps. However, the bandwidth of active
peers (not depicted in this gure) is only slightly reduced to
400 kbps. This is because the large amount of bandwidth required
to serve content during the two surges at 1:40 pm and
2:10 pm in
uence the average bandwidth.
The cumulative distribution of bandwidth contributed by
active CoopNet peers, depicted in Figure 13(c), illustrates
the impact of distributed streaming on bandwidth utiliza-
tion. Each solid line represents the amount of bandwidth
peers contribute when using 1, 5, and 10 degrees of paral-
lelism. The median bandwidth requirement is 390 kbps when
content is streamed from one peer, and only 66 bps for
degrees of parallelism. The bandwidth requirement imposed
on each peer is reduced as the degree of parallelism increases.
Although this reduction is signicant, a small portion of peers
still contribute more than 1 Mbps even when using 10 degrees
of parallelism. We believe that the combination of the following
two factors contribute to the wide range in bandwidth
usage: the greedy algorithm a client uses to select peers and
the algorithm the server uses to select a set of IP addresses
to give to clients.
For better load distribution, the server can run a load-aware
algorithm that redirects clients to recently seen peers that are
the least loaded (in terms of network bandwidth usage). In
order to implement this algorithm, the server needs to know
the load at individual peers. Therefore, peers constantly report
their current load status to the server. We use a report
interval of once every second in our simulations. Because
the server caches a xed-size list of IP addresses, only those
peers currently in the server's list need to send status up-
dates. Given this information, the server then selects the 10
least loaded peers that have recently accessed the same URL
as the requesting client to return in its redirection message.
This algorithm replaces the one described earlier in this section
where the server redirects clients to peers that were re-0.20.40.60.81
Storage Allocated At Each Peer (Bytes)
Cumulative
Distribution

Figure

14: Storage requirement at CoopNet peers.
cently seen. Clients, however, use the same greedy algorithm
to select peers. We nd that using this new algorithm, active
clients serve content at 385 kbps. The dashed line in Figure
13(c) depicts the cumulative distribution of bandwidth
contributed by CoopNet clients when the load-aware algorithm
is used at the server. In this simulation, clients stream
content from at most one other peer (degree of parallelism of
1). For the most part, the distribution is similar to the one
observed when the server redirects the request to recently seen
peers. The dierence lies in the tail end of the distribution.
About 6% of peers contributed more than 500 kbps of band-width
when the server runs the original algorithm, compared
to only 2% when the server runs the load-aware algorithm.
In addition, the total number of active peers in the system
doubles when the load-aware algorithm is used.
We nd that client cooperation signicantly reduces server
load, freeing up bandwidth to support more client connec-
tions. In addition, the combination of distributed streaming
and a load-aware algorithm used by the server further reduces
the load on individual peers.
4.2.2 Storage Requirement
In order to facilitate cooperation, clients also contribute
storage for caching content. In our simulations, peers cache
streams that they have downloaded for the entire duration of
the simulation. Figure 14 depicts the cumulative distribution
of the amount of storage each peer needs to provide. Storage
sizes range from 200 B to 100 MB. Over half of the peers store
less than 1 MB of content, and only 5% of peers store over
6MB of content. The storage requirement is reasonable for
modern computers.
4.2.3 Nearby Peers
Next, we look at the likelihood of cooperating with nearby
peers. Finding nearby peers can greatly increase the e-ciency
of peer-to-peer communications. In our evaluation, peers are
close if they belong in the same BGP prex domain [9]. We
cluster over 9,000 IP addresses of clients who successfully received
content in the 2-hour trace based on BGP tables obtained
from a BBNPlanet router [32] on Jan 24, 2001. The
trace is sampled by randomly drawing ten 5-minute windows.
We look the probability of nding at least n peers in the same
AS domain, where n is the degree of parallelism, ranging from
1 to 10. The sampling is repeated for window sizes of 10 and
minutes.
For a window of 5 minutes, the probability of nding at least
one peer who has requested the same content and belongs to
the same BGP prex cluster is 12%. As the window size increases
to 10 and 15 minutes, the probability slightly increases
to 16% and 17%, accordingly. For distributed streaming, as
the degree of parallelism increases, the probability of nding
nearby peers decreases. Using a 10-minute window, the probability
of nding at least 5 peers and 10 peers in the same
BGP prex cluster are as low as 5% and 2%.
To better understand whether the small number of IP addresses
aects the probabilities of nding proximate peers, we
also clustered over 90,000 IP addresses from the entire 2-hour
trace, including unsuccessful requests. For the most part, the
probabilities are the same or 1-2% higher than those those
reported above for successful requests. Finding a proximate
peer with su-cient available bandwidth is part of ongoing
work.
In summary, our initial results suggest that client cooperation
can improve overall system performance. Distributed
streaming and load-aware server are promising solutions to
reduce load at individual peers while improving robustness.
5. CONCLUSIONS
In this paper, we have presented CoopNet, a peer-to-peer
content distribution scheme that helps servers tide over crisis
situations such as
ash crowds. We have focussed on the
application of CoopNet to the distribution of streaming median
content, both live and on-demand. One challenge is that
clients may not participate in CoopNet for an extended length
of time. CoopNet employs distributed streaming and multiple
description coding to improve the robustness of the distributed
streaming content in face of client departures.
We have evaluated the feasibility and potential performance
of CoopNet using traces gathered at MSNBC during the
ash
crowd that occurred on September 11, 2001. This was an
extreme event even by
ash crowd standards, so using these
traces helps us stress test the CoopNet design. Our results
suggest that CoopNet is able to reduce server load significantly
without placing an unreasonable burden on clients.
For live streams, using multiple independent distribution trees
coupled with MDC improves robustness signicantly.
We are currently building a prototype implementation of
CoopNet for streaming media distribution.

Acknowledgements

We are grateful to Steven Lautenschlager, Ted McConville,
and Dave Roth for providing us the MSNBC streaming media
logs from September 11. We would also like to thank
the anonymous NOSSDAV reviewers for their insightful comments

6.



--R




Joint source and channel coding for image transmission over lossy packet


Multiple description coding: Compression meets the network.



Unequal loss protection: Graceful degradation of image quality over packet erasure channels through forward error correction.
Approximately optimal assignment for unequal loss protection.





Embedded video subband coding with 3D SPIHT.
Multiple description source coding through forward error correction codes.





Design of multiple description scalar quantizers.
Design of entropy-constrained multiple description scalar quantizers
Optimal pairwise correlating transforms for multiple description coding.
Control Systems for Digital Communication and Storage.



BBNPlanet publically available route server

--TR
systems for digital communication and storage
Enabling conferencing applications on the internet using an overlay muilticast architecture
Chord
A scalable content-addressable network
An investigation of geographic mapping techniques for internet hosts
Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility
Towards global network positioning
The Case for Cooperative Networking
Tapestry: An Infrastructure for Fault-tolerant Wide-area Location and
Scattercast

--CTR
Xinyan Zhang , Jiangchuan Liu, Gossip based streaming, Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters, May 19-21, 2004, New York, NY, USA
Duc A. Tran , Kien A. Hua , Tai T. Do, Scalable media streaming in large peer-to-peer networks, Proceedings of the tenth ACM international conference on Multimedia, December 01-06, 2002, Juan-les-Pins, France
Mubashar Mushtaq , Toufik Ahmed , Djamal-Eddine Meddour, Adaptive packet video streaming over P2P networks, Proceedings of the 1st international conference on Scalable information systems, May 30-June 01, 2006, Hong Kong
Meng Zhang , Li Zhao , Yun Tang , Jian-Guang Luo , Shi-Qiang Yang, Large-scale live media streaming over peer-to-peer networks through global internet, Proceedings of the ACM workshop on Advances in peer-to-peer multimedia streaming, November 11-11, 2005, Hilton, Singapore
Guang Tan , Stephen A. Jarvis , Xinuo Chen , Daniel P. Spooner, Performance Analysis and Improvement of Overlay Construction for Peer-to-Peer Live Streaming, Simulation, v.82 n.2, p.93-106, February  2006
Reza Rejaie , Antonio Ortega, PALS: peer-to-peer adaptive layered 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
Karthik Lakshminarayanan , Venkata N. Padmanabhan, Some findings on the network performance of broadband hosts, Proceedings of the 3rd ACM SIGCOMM conference on Internet measurement, October 27-29, 2003, Miami Beach, FL, USA
Chuan Wu , Baochun Li, rStream: resilient peer-to-peer streaming with rateless codes, Proceedings of the 13th annual ACM international conference on Multimedia, November 06-11, 2005, Hilton, Singapore
Zongpeng Li , Baochun Li , Lap Chi Lau, On achieving maximum multicast throughput in undirected networks, IEEE/ACM Transactions on Networking (TON), v.14 n.SI, p.2467-2485, June 2006
Sachin Agarwal , Jatinder Pal Singh , Shruti Dube, Analysis and implementation of Gossip-based P2P streaming with distributed incentive mechanisms for peer cooperation, Advances in Multimedia, v.2007 n.2, p.1-12, April 2007
Song Ye , Fillia Makedon, Collaboration-aware peer-to-peer media streaming, Proceedings of the 12th annual ACM international conference on Multimedia, October 10-16, 2004, New York, NY, USA
Thorsten Strufe , Jens Wildhagen , Gnter Schfer, Towards the Construction of Attack Resistant and Efficient Overlay Streaming Topologies, Electronic Notes in Theoretical Computer Science (ENTCS), 179, p.111-121, July, 2007
Dan Rubenstein , Sambit Sahu, Can unstructured P2P protocols survive flash crowds?, IEEE/ACM Transactions on Networking (TON), v.13 n.3, p.501-512, June 2005
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
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
Raj Kumar Rajendran , Dan Rubenstein, Optimizing the quality of scalable video streams on P2P networks, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.50 n.15, p.2641-2658, October 2006
Chuan Wu , Baochun Li, Optimal peer selection for minimum-delay peer-to-peer streaming with rateless codes, Proceedings of the ACM workshop on Advances in peer-to-peer multimedia streaming, November 11-11, 2005, Hilton, Singapore
Chun-Chao Yeh , Lin Siong Pui, On the frame forwarding in peer-to-peer multimedia streaming, Proceedings of the ACM workshop on Advances in peer-to-peer multimedia streaming, November 11-11, 2005, Hilton, Singapore
Yu-Wei Sung , Michael Bishop , Sanjay Rao, Enabling contribution awareness in an overlay broadcasting system, ACM SIGCOMM Computer Communication Review, v.36 n.4, October 2006
Yohei Okada , Masato Oguro , Jiro Katto , Sakae Okubo, A new approach for the construction of ALM trees using layered video coding, Proceedings of the ACM workshop on Advances in peer-to-peer multimedia streaming, November 11-11, 2005, Hilton, Singapore
Yang Guo , Kyoungwon Suh , Jim Kurose , Don Towsley, P2Cast: peer-to-peer patching for video on demand service, Multimedia Tools and Applications, v.33 n.2, p.109-129, May       2007
Yi-Cheng Tu , Jianzhong Sun , Mohamed Hefeeda , Sunil Prabhakar, An analytical study of peer-to-peer media streaming systems, ACM Transactions on Multimedia Computing, Communications, and Applications (TOMCCAP), v.1 n.4, p.354-376, November 2005
Shiwen Mao , Xiaolin Cheng , Y. Thomas Hou , Hanif D. Sherali, Multiple description video multicast in wireless ad hoc networks, Mobile Networks and Applications, v.11 n.1, p.63-73, February 2006
Kunwadee Sripanidkulchai , Aditya Ganjam , Bruce Maggs , Hui Zhang, The feasibility of supporting large-scale live streaming applications with dynamic application end-points, ACM SIGCOMM Computer Communication Review, v.34 n.4, October 2004
Zhichen Xu , Chunqiang Tang , Sujata Banerjee , Sung-Ju Lee, RITA: receiver initiated just-in-time tree adaptation for rich media distribution, Proceedings of the 13th international workshop on Network and operating systems support for digital audio and video, June 01-03, 2003, Monterey, CA, USA
Leonardo Bidese de Pinho , Claudio Luis de Amorim, Assessing the efficiency of stream reuse techniques in P2P video-on-demand systems, Journal of Network and Computer Applications, v.29 n.1, p.25-45, January 2006
Yi Cui , Baochun Li , Klara Nahrstedt, On achieving optimized capacity utilization in application overlay networks with multiple competing sessions, Proceedings of the sixteenth annual ACM symposium on Parallelism in algorithms and architectures, June 27-30, 2004, Barcelona, Spain
Kunwadee Sripanidkulchai , Bruce Maggs , Hui Zhang, An analysis of live streaming workloads on the internet, Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, October 25-27, 2004, Taormina, Sicily, Italy
Yang Guo , Kyoungwon Suh , Jim Kurose , Don Towsley, P2Cast: peer-to-peer patching scheme for VoD service, Proceedings of the 12th international conference on World Wide Web, May 20-24, 2003, Budapest, Hungary
Padmavathi Mundur , Poorva Arankalle, Optimal server allocations for streaming multimedia applications on the internet, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.50 n.18, p.3608-3621, 21 December 2006
Daria Antonova , Arvind Krishnamurthy , Zheng Ma , Ravi Sundaram, Managing a portfolio of overlay paths, Proceedings of the 14th international workshop on Network and operating systems support for digital audio and video, June 16-18, 2004, Cork, Ireland
Mohamed Hefeeda , Ahsan Habib , Boyan Botev , Dongyan Xu , Bharat Bhargava, PROMISE: peer-to-peer media streaming using CollectCast, Proceedings of the eleventh ACM international conference on Multimedia, November 02-08, 2003, Berkeley, CA, USA
Mohamed M. Hefeeda , Bharat K. Bhargava , David K. Y. Yau, A hybrid architecture for cost-effective on-demand media streaming, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.44 n.3, p.353-382, 20 February 2004
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
Ji Li , Karen Sollins , Dah-Yoh Lim, Implementing aggregation and broadcast over Distributed Hash Tables, ACM SIGCOMM Computer Communication Review, v.35 n.1, p.81-92, January 2005
Alan Kin Wah Yim , Rajkumar Buyya, Decentralized media streaming infrastructure (DeMSI): An adaptive and high-performance peer-to-peer content delivery network, Journal of Systems Architecture: the EUROMICRO Journal, v.52 n.12, p.737-772, December, 2006
Dejan Kosti , Adolfo Rodriguez , Jeannie Albrecht , Amin Vahdat, Bullet: high bandwidth data dissemination using an overlay mesh, Proceedings of the nineteenth ACM symposium on Operating systems principles, October 19-22, 2003, Bolton Landing, NY, USA
Miguel Castro , Peter Druschel , Anne-Marie Kermarrec , Animesh Nandi , Antony Rowstron , Atul Singh, SplitStream: high-bandwidth multicast in cooperative environments, Proceedings of the nineteenth ACM symposium on Operating systems principles, October 19-22, 2003, Bolton Landing, NY, USA
Konstantin Andreev , Bruce M. Maggs , Adam Meyerson , Ramesh K. Sitaraman, Designing overlay multicast networks for streaming, Proceedings of the fifteenth annual ACM symposium on Parallel algorithms and architectures, June 07-09, 2003, San Diego, California, USA
Toufik Ahmed , Mubashar Mushtaq, P2P Object-based adaptivE Multimedia Streaming (POEMS), Journal of Network and Systems Management, v.15 n.3, p.289-310, September 2007
Karthik Lakshminarayanan , Ananth Rao , Ion Stoica , Scott Shenker, End-host controlled multicast routing, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.50 n.6, p.807-825, 13 April 2006
Zongming Fei , Mengkun Yang, A proactive tree recovery mechanism for resilient overlay multicast, IEEE/ACM Transactions on Networking (TON), v.15 n.1, p.173-186, February 2007
Mojtaba Hosseini , Nicolas D. Georganas, End system multicast protocol for collaborative virtual environments, Presence: Teleoperators and Virtual Environments, v.13 n.3, p.263-278, June 2004
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
content distribution networks;multiple description coding;peer-to-peer networks;streaming media