YouCast: Tree-based Peer-to-Peer Video Streaming Service

Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Recitation: Girod 1PM

May 10, 2007
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

YouCast: Tree-based Peer-to-Peer Video Streaming Service

1. Introduction
The YouCast system is a scalable and reliable peer-to-peer streaming solution that allows multiple users
to watch video streams in real-time. In the system, a video server obtains video content from a camera,
and streams the content to subscribers in the peer-to-peer network. Since there can be many video
servers, a tracking server maintains a list of IP addresses of all active video servers.

In this paper, we describe a tree-based video dissemination architecture with the video server as the root.
Peers in the tree are both clients as well as servers for peers in the next level of the tree. The tree has an
average branching factor of 3. Thus, more than 170,000 peers can be accommodated with a tree of only
10 peer levels.

Our system operates according to a set of protocols that govern how new nodes join the system, how
video is disseminated, how node failures are repaired, and how private streams are encrypted. All video
data is streamed over UDP. All other communication between machines on the system is over TCP/IP.

Our design is based on the key principles of keeping the design simple, minimizing the network traffic,
and ensuring that our system is scalable. We choose a relatively simple tree structure over more other
more complex structures. We minimize network traffic by eliminating unnecessary pinging and
messaging between machines on the network. We ensure that our system is scalable by choosing a
dissemination structure and private stream encryption method that allow our system to easily
accommodate thousands of peers.

2. Tree-based Dissemination Architecture

The structure of our dissemination network is represented by a tree with a branching factor of three for
most of the nodes. As shown in Figure 1, each node in the tree corresponds to a peer in the network.
Each peer can handle on average five concurrent streams. One of these streams is used for receiving
video content from the peer’s parent. Three outgoing streams are used for streaming video to the peer’s
children. The fifth stream is normally left unused so that repair operations can be accomplished swiftly.

2
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Tracking Server
Video Server

Peer
Peer Peer Video Server

Peer Peer Peer Peer Peer Peer

Peer

Peer Peer

Figure 1. Tree architecture of the YouCast system. Arrows correspond to dependencies between the nodes of the
network. Each peer has a primary parent (solid arrow), and a backup parent (dashed line), which are assigned when
it joins the network.

Each peer in the tree has a primary parent as well as a backup parent. A peer only streams video from its
primary parent. The peer retains the IP address of a backup parent in case its primary parent fails. When
new peers join the network, the video server attempts to assign backup parents to each new peer such that
different backup parents are assigned to peers streaming from the same primary parent. The video server
also attempts to assign backup parents to new peers such that the backup parent is on the same level of the
tree as the primary parent of the new peer.

The video server stores the state of the tree in its memory. This is feasible because if each node needs 1
KB of memory, then a tree with 1 million nodes will use 1 GB of memory – a reasonable amount by
today’s standards. Table 1 lists the specific information that the video server stores about each peer in the
network. The video server gathers all information in this table when the peer joins the network.

Table 1. Data stored about each peer at the video server. This information is stored in each node of the tree data
structure in the video server’s memory.

Information Description

IP Address Node’s IP address

Bandwidth Node’s connection bandwidth in Mb/s

Connection Type How this node is connected to the Internet (wired or wireless)

Primary Parent IP IP address of this node’s primary parent

3
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Backup Parent IP IP address of this node’s backup parent

Children IP Addresses List of IP addresses of children of this node

Backup Children IP Addresses List of IP addresses of nodes that use this node as backup parent

Join Score Used to determine best parents for new peers (see Section 3)

IP addresses serve as the identification of each peer on the network. For basic functionality, either the
parent or the children IP addresses needs to be saved for each node. However, to make the video server
efficient, we choose to store both the parent and children IP addresses for each node. The connection type
data is used to evaluate the reliability of the peer. Wired connections are considered much more reliable
than wireless connections because wireless connections have a higher packet drop rate. Using the
bandwidth and reliability data of each peer, the video server periodically reshuffles adjacent peers (i.e.
parent-children relationship) in the tree to maximize the chance that the peers with the highest bandwidth
and strongest reliability are positioned near the top of the tree.

The state of the tree stored at the video server is not necessarily the exact current state, but is adequate for
our protocols to function correctly. The video server updates the tree when a new peer joins or when a
peer tells the video server that the peer’s parent has failed. The video server also updates the tree when a
leaf drops out, in which case the parent of the leaf sends a message to the video server. The parent of the
leaf knows about the leaf’s state because when a leaf is functional, it sends frame-resend requests (when
frames get lost in the network) or keep-alive messages to its parent such that at least one message is sent
every three seconds.

An alternative design choice is to have the video server ping every peer periodically so that it can
maintain the latest version of the tree. We chose to avoid this solution because it requires too much
network traffic, which would decrease the efficiency of our system.

3. Join Protocol
When a new peer joins the network, the new peer first asks the tracking server for the IP address of the
video server. The new peer then uses this information to ask the video server for the IP addresses of a
primary parent and a backup parent. The video server responds by giving the new peer the IP address of
the available parent with the highest join score (see next paragraph), along with a feasible backup parent.

4
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

If the primary parent is unavailable, the new peer will ask the video server for another set of primary and
backup parents. During join, the video server also does its best to ensure that children of the same peer
are given different backup parents on the same level of the tree.

The join score is a score calculated for each peer in the client tree when the peer joins. This score takes
into account the bandwidth and the reliability of the node. Each peer can find out about its bandwidth and
connection type (wired vs. wireless) by asking its network card. The peer then sends this information to
the video server. If the peer has a wireless connection, the peer’s join score is calculated by the formula:
2/3*bandwidth. If the peer has a wired connection, then its bandwidth is the join score. The formula is
based on the common estimate that a wireless connection can drop 33% of the packets when its
bandwidth is fully utilized [1]. The video server maintains a priority queue of leaf nodes with the join
score as the key. This way, IP addresses of the best leaf nodes can be given out with little processing
time when a new peer requests it.

There are rare cases where the video server may ask a new peer to connect to a failed peer because the
video server does not yet know that the peer failed. One case is that a leaf fails, and then its parent fails
before the parent can notify the video server. Another case is when a new peer is asked to connect to a
leaf that has just dropped out, before the leaf’s parent can notify the video server. In both cases, the new
peer can still join correctly by asking the video server for alternative parents. These cases are also likely
to be rare, so a new peer usually receives a valid parent IP address on the first try.

4. Dissemination Protocol
The dissemination protocol governs how video data is dispersed among clients and servers. In our model,
the video server functions only as the main server and the machines that connect to it function as both
clients and servers.

4.1 Dataflow
The flow of data begins at the video server, which sends packets to the clients connected directly to it.
Each packet contains a frame of video and a sequence number of that frame. The server has a buffer that
contains 1 minute of video data. This buffer is needed because if one of the clients is missing a frame, it
can request the server to resend it.

5
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Each peer receives the frame data and places it into its buffer. These frames may be out of order and some
may be missing. The peer sends the unordered frame data to all of its clients immediately as it is received
to minimize network latency. It then rearranges the frames and requests its parent to retransmit ones that
have not yet been received. If it has not received some frames by the time it should play them, the peer
ignores the gap and plays the preceding frame instead. The peer’s children can request missing frames
from the peer’s buffer. If a peer has not requested a frame for 3 seconds, it sends a keep-alive message to
its parent. It is through these keep-alive messages and frame requests that a parent knows that its child
should be given content. A child cannot distinguish whether its parent is a peer or the main video server.

The YouCast system is optimized for smooth streaming in a tree that is up to 11 levels deep (10 levels of
peers). This tree will contain 177,146 peers, assuming that each peer can support an average of 5 streams.
One stream will be the incoming data, three will be outgoing data to children, and one will be kept open,
so that the peer can serve as a backup parent in case of failure in other nodes. The system will function
with deeper trees, but peers at the lower levels of the tree may miss several frames of data in the case of a
failure or when the nodes in the tree are reordered.

The frame data is sent using the UDP protocol, which does not guarantee delivery. We take this approach
in order to send the frame data in a timely manner. The other messages, such as requests for missing
frames, are sent using TCP/IP, which is much more reliable.

4.2 Reshuffling
In order to optimize the network and prevent situations where less reliable peers are closer (in terms of
hops in the tree) to the main server, we utilize a reshuffling algorithm. After a peer has joined the
network, and has its buffer nearly full, the main server reshuffles the system to optimize it, placing the
closest, most reliable peers at the top of its tree structure. It does this reshuffling two levels at a time,
switching in a parent-child pairwise fashion. For example, a parent and a child may switch, but nodes
within the same level cannot. Also, nodes may not skip levels. For example, a node in the seventh level
can switch with a node in the sixth level, but not with a node in the second level. It can move this high in
the tree, however, if it does so progressively, moving up one level at a time. This technique allows the
buffers of nodes to fill as much as possible before moving. After moving the server updates the backup
parents of the switched peers. This strategy helps minimize latency.

6
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

4.3 Buffering
The YouCast system streams video data from servers to clients. The clients, in turn, function as servers to
their children. When the data travels across a network, the packets with video frames may arrive out of
order or be lost entirely. This method requires that the peers in the network, as well as the main video
server, have buffers in which they can store video frames. As servers, they may need to retransmit frames
to their children. As clients, they need to place the frame packets in the correct order before displaying
them on the screen.

The challenge of designing a buffering scheme for a real-time peering network lies in network latency.
Frames require a certain amount of time to travel between nodes. If it takes one second to travel between
two given nodes, then, in a tree with 11 levels, the maximum difference in time from the main video
server to the lowest level of the tree will be 10 seconds. If a server sends a frame at time t seconds, a leaf
at the lowest level will receive it at t + 10 seconds. In addition, if a peer’s parent fails and its backup is not
available, it will need a maximum of 9 seconds to reestablish a connection with a new parent (1 second to
realize that it is no longer receiving content, 2 seconds to send a message to its parent and determine that
there is no response, 2 seconds to contact a backup parent and establish that it is unavailable, 2 seconds to
contact the main video server and obtain a new parent, and 2 seconds to connect to the new parent). The
repair section of this document contains a more detailed explanation of how a peer deals with parent
failure. Because the maximum latency from the main server to a peer plus the time for repair is 20
seconds and peers can move within the tree, a given peer needs to have 20 seconds of buffer space in
which to store frames before playing them.

As described earlier, peers in the YouCast system may periodically move up or down in the tree to
optimize network function. Peers with higher bandwidth, for example, are better to have at the top of the
tree (closer to the main video server), rather than close to the bottom. Because the position of the nodes is
not static, the peers’ buffers need to account for network latency, as well as being able to handle being
clients and servers either higher or lower in the tree structure without interrupting the video stream or
playback.

Taking into account that the maximum smoothly supported depth of the tree is 11 levels, our system
provides each peer with a 60-second buffer. This buffer is divided into three parts: the section into which
frames arrive and are sorted before being played (20 seconds), the section into which data is stored after
having been played (20 seconds), and extra buffer space for frames that are sequentially newer than the

7
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

20-second sorted frames to be played (20 seconds). The played buffer is used to allow for smooth video
playback in case of parent failure. The buffer section with the old data is used so that if a node that was
originally at the top of the tree moves to a place near the bottom, it can support its children’s requests for
missing frames. The buffer section with the new data is used in case a peer moves from the bottom of the
tree to the top. It will have gained extra frame data in the process of its progressive move upward. It will
need this space so that its buffer does not overrun. It also needs to store this data to be able to support its
children’s requests for missing frames. Please see Figure 3 for an illustration of how these buffers are
allocated and Figure 4 to see the how the video content changes for nodes that move up or down in the
tree structure.

Sequence #
New Frame

Peer’s Video Buffer (30 MB)

Post-Play Section (20 Sec) Pre-Play Section (20 Sec) Flexible Section (20 sec)

Oldest Frames Newest Frames

Play
Frame

Figure 3. Three sections of each peer’s video buffer.

Buffer Content of Peer Bubbling Down 10 Consecutive Times

st
Joins at 1 Level

At 6th Level

At 10th Level
+20 sec 0 sec -20 sec -40 sec

Buffer Content of Peer Bubbling Up 10 Consecutive Times

th
Joins at 10 Level

At 6th Level

At 1st Level
+20 sec 0 sec -20 sec -40 sec

Buffer Space Occupied by Content

Unused Buffer Space

Figure 4. Occupied and unused buffer space for peers moving up or down the tree for 10 consecutive times. The 0-
second mark corresponds to the current frame being played.

8
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

The peers begin playing the video after they have received approximately 20 seconds of data. If a client
has not received a needed frame within 100 milliseconds (2 frames) of the time it must be played, it
simply displays the previous frame. It does, however, request this frame from its parent, so that it can
transmit it to its children. Parents obtain the frame data that they transmit to their children from any of the
three sections of the buffer.

Video Server
0th Level

1st Level Node B

. . .

2nd Level . . .
Peer Peer
Max Latency
10 sec
. . . . . .

9th Level Peer

10th Level Node A

Figure 5. Illustration of positions of Node A and Node B. Each link between consecutive levels of the tree
contributes to a max latency of 1 second. Arrows point from child to primary parent.

To illustrate how the buffering works, consider a node (Node A) at the tenth level of a tree (considering
the server to be the 0th level) with a total network latency of 10 seconds (Figure 5). It receives data 9
seconds after a node (Node B) at the first level of the tree receives it, and 10 seconds after the video
server disseminates it. Node A buffers the frames for 20 seconds and begins to play the video. Since Node
B also buffered its data for 20 seconds before playing it, Node A is now playing its video 9 seconds after
Node B. In this case, Node A plays a given frame 30 seconds after the main video server has disseminated
it.

Suppose now that because Node A is a very high-bandwidth node with a wired connection, it gets
promoted to the top of the tree structure. It is still playing frames 30 seconds behind the server, but its

9
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

children are playing their video only 22 seconds behind the server. The other 8 seconds of data need extra
buffer space to prevent buffer overrun. Also, even though Node A transmits frames as soon as it receives
them, it needs to be able to answer its children’s requests for missing frames. In case one of Node A’s
parents breaks before Node A reaches the top of the structure, it needs to be able to recover within 10
seconds. To allow for both repair and movement up the tree, the flexible buffer space is designed to hold
up to 20 seconds of frames.

Now suppose that Node B is a low-bandwidth node and gets demoted to the ninth level of the tree (one
above the lowest level). It is playing its video 21 seconds behind the server, while its children are playing
it 30 seconds behind. In case they request frames, Node B needs to provide them with data that it has
already played. In this case, it needs to store old data. We allocate 20 seconds to this buffer to allow for
the 10-second difference and repair.

Because the nodes keep data from the past and potentially, to them, more than the standard buffering time
of 20 seconds into the future, the nodes are free to move within the tree. The server maintains 60 seconds
of frames to support all children’s frame requests, regardless of where they originally joined the tree. This
scheme allows the tree to be dynamically optimized.

4.4 Pseudocode
Functions for handling frames run on each server in the network. There are two versions of these
modules, one runs on the main video server, while the other runs on each of the peers.

On the video server, the camera that is generating the visual output calls the function
Frame_Handler(frame_ptr pt) every 50 milliseconds. The frame handler places the frame into
its buffer and sends it to all of the server’s direct children. It places the frame into the buffer first, so that
if one of its children requests a frame before the server is finished sending it to all the children, it can
fulfill the request. When a child is missing a frame, it can send a message back to the server, asking for a
particular frame. The module that handles retransmission of frames runs as a separate thread on the
server. When called, it finds a needed frame and sends it to the child that requested it.

The following pseudocode is a representation of these modules. These are modules that run on the main
video server.

10
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Frame_Handler(frame_ptr pt) {
Place_frame_in_buffer(pt, frame_buffer);
for_each(child, children) {
Send_Frame(ptr, get_ip(child));
}
}

Retransmit_Missing_Frame(sequence_number frame_num, IP_address child) {

frame_ptr pt = Find_frame_in_buffer(frame_num,
frame_buffer);
Send_Frame(pt, child);
}

Each peer runs four threads: one for receiving frames, placing them in the appropriate buffers,
and disseminating them, one for sorting and otherwise managing the buffers, one for playing
frames, and one for retransmitting missing ones to the children. The pseudocode is shown in
below.

Receive_Frame(frame_ptr pt, IP_address source) {

Place_frame_in_preplay_buffer(pt);
for_each(child, children) {
Send_Frame(ptr, get_ip(child));
}
}
Manage_Buffers() {
Sort_preplay_buffer(); // Sorts all but 2 frame slots
// closest to play time
if(missing_frame) {
frame_ptr ptr = request_missing_frame_from_parent(
Get_Frame_Seqn(frame));
place_frame_into_buffer(ptr);
}
if(not_requested_frame_for_3_seconds) {
send_keep_alive_to_parent();
}
}
Play_Control() {
every(50 milliseconds) {
frame_ptr pt = get_current_frame();
Play_Frame(pt);
move_frames_in_buffer(); // Moves played frames to
// post play section of
// buffer, moves new
// frames closer to play time
}
}
Retransmit_Missing_Frame(sequence_number frame_num, IP_address child) {
frame_ptr pt = Find_frame_in_buffer(frame_num,
frame_buffer);
if(frame_in_buffer) {
Send_Frame(pt, child);
}

11
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

This code runs on the peers and manages the flow of the data in the network. It is optimized for
fast dissemination.

4.5 Backups
Each client in the network has one parent and one backup parent to which it can connect in case
its primary parent fails. The number of children each parent has is one less than the maximum
number of streams it can support, so that it is capable of fulfilling its backup parent
responsibilities. We keep only one stream open because we assume that only one node in the
network may fail at any one time. Also, the server, to the best of its ability, assigns backup
parents to nodes in such a way that children of one primary parent do not share backup parents. It
attempts to assign backup parents that are on the same level as the primary parents. Because
these children do not have the same backup parent, if their primary parent fails, the backup
parents, each of which keeps one stream open for such emergencies, can support these nodes. It
is possible that a backup parent is unavailable at the time its child requests a stream. In this case,
the child asks the server to rejoin the tree.

5. Repair Protocol
If during a one second interval, a peer receives little (less than 20%) or no content, it contacts its parent to
check if it has failed. If the parent responds, then the peer will continue to receive content from the parent
as usual. If there is no response, then the peer deems that its parent has failed.

Upon determining that its parent has failed, a peer will first request the stream from its backup parent. If
the backup parent is able to handle an additional outgoing stream, it begins streaming to the peer. Once
the peer begins receiving content from the backup parent, it sends a message to the video server to update
its tree structure. The server responds to the peer with a new backup parent in case of another failure.

Since peers can disconnect from a stream at any time, it is possible that a peer’s backup parent is no
longer a part of the system. In this case, the peer uses the join protocol to request new primary and backup
parents.

12
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Although all parents maintain one open outgoing stream each to fulfill their backup parent
responsibilities, it is feasible that this slot is filled by a different peer from either another failure or the
same failure. A backup parent can be a part of the system, but simply unable to handle an additional
outgoing stream. Similarly to the above case, the peer uses the join protocol to request new primary and
backup parents.

In the case where a parent has no available outgoing streams, we do not reshuffle any of its children to
reopen a slot. Thus, this parent can no longer fulfill its backup parent responsibilities. The video server
instead will send a message to every peer that has a backup parent with no open slots, updating these
peers with new backup parents. This allows these peers to receive content more quickly after a failure
because they no longer have to contact a full backup parent.

Our failure design does not introduce large overhead. In most situations, there is only one roundtrip of
communication before a peer begins receiving content from its backup parent. If a backup parent is
unavailable or unable to handle an additional outgoing stream, there are three roundtrips of
communication before a peer begins receiving content again. By minimizing this overhead, our system is
able to maintain scalability.

6. Private Streams
Our system uses shared-secret cryptography for private streams. Using e-mail correspondence, the camera
owner sends each user the same shared-secret key. Thus, only one secret key is distributed to every peer
in the system. The server will encrypt each frame before it is sent to its children. Note that the server only
encrypts the video content of the frame, and not the entire packet which includes the sequence number,
because we are interested in securing only the video content. No significant changes are necessary to the
system, except that a peer must now decrypt any content received for a private stream using the shared-
secret key that the camera owner sent. Also, peers will only decrypt the content immediately before it is
played so that it can respond to a child’s request for a specific (encrypted) frame very quickly.

Since the video content is encrypted as it is sent across the network, peers without the shared-secret key
are unable to watch the stream. Nonetheless, these peers are still able to stream the content to their
children. All peers transmit encrypted video content so that only peers with the shared-secret key are able
to view the stream.

13
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Although using public-key cryptography is theoretically possible for this situation, it is far less efficient
than shared-secret cryptography. Public-key cryptography is computationally more costly. In fact, it can
be hundreds or even thousands of times slower than shared-secret cryptography [2].

Public-key cryptography with multiple public keys is not a scalable solution because every peer would
need to receive a unique encrypted frame. For each peer, the server would have to encrypt the frame with
the peer’s public key. If there are n peers, then for every frame of video content, n unique frames will
need to be sent out. Since all the peers share the same key in shared-secret cryptography, it is only
necessary for the video server to send out a single encrypted frame.

7. Scalability and Fault Tolerance

7.1.1 Scalability – Join
By using a simple tree structure, our system is able to maintain scalability. On average, a machine can
handle 5 streams. In our system, there is only one incoming stream for a given peer, leaving four outgoing
streams. In general, all parents leave one of their four streams open to fulfill their backup parent
responsibilities. To simplify our analysis, we will assume that our tree has a consistent breadth of three
for each peer and that it is balanced.

Even if there are over 170,000 peers connected to a single stream, the tree only has ten peer levels. Thus,
the amount of time it takes for a frame to travel from the top of the tree to the bottom is a maximum of 10
seconds. For each additional level of the tree, the system grows exponentially. For example, with 13 peer
levels our system can accommodate over 4.7 million peers with a maximum delay of 13 seconds from the
top to the bottom.

One weakness of our design with respect to scalability is that it can be somewhat slow when numerous
peers all join at the same time. This occurs because the video server needs to determine where each peer
in a certain level resides. Then, it focuses on the next level of peers and so on. The system slows down in
this situation, but we chose to avoid implementing a workaround to maintain a simple design.

7.1.2 Scalability – Dissemination

14
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Our system scales well because the video server does not have to support every client. The system
minimizes latency by having the peers transmit received packets as quickly as possible (without buffering
them first) and by reshuffling peers, putting the most capable ones at the top of the hierarchy. The
capabilities of the system are not infinite, however.

Although we describe our system as being optimized for a tree of maximum depth 11, it can be extended
to account for a greater number of nodes by increasing the size of the buffers on the video server and
peers. The administrator of the system would adjust the size of the buffers before beginning to transmit
the stream to the peers. The number of clients would be estimated before running a given stream on a
video server.

7.2 Fault Tolerance

As a peer attempts to reconnect to its backup parent or to a new parent, it consumes video content from its
buffer. In most cases, it takes the peer a maximum of 9 seconds to begin receiving content again. In
general, it takes the peer a maximum of 3 seconds to determine its parent has failed and, in the case of the
backup parent being unavailable, a maximum of 6 seconds to begin receiving content from a new parent
(assuming a maximum network latency of 1 second). Thus, a buffer size of 20 seconds is large enough to
ensure that a peer maintains a quality stream for the viewer.

One specific situation where a peer may have a loss of performance in the video stream is when its parent
fails, backup parent is unavailable, and rejoining the system takes a significant amount of time. In this
case it takes the peer longer than 6 seconds to begin receiving content from a new parent. We estimate
this situation to be rare and because the buffer maintains roughly 20 seconds of content, we do not foresee
this problem having a significant impact on the system.

8. Conclusion
We have designed a scalable, robust, and high-performance video streaming system that operates
according to the join, dissemination, repair and private stream protocols. The tree-structure and
the absence of unnecessary communication make our system scalable. Our repair algorithm
allows for a peer to quickly find a new parent while using its buffer to maintain the stream of
video content. Our dynamic node reshuffling algorithm makes our system perform well by
moving the most reliable nodes to the top of the tree.

15
 Natalia Chernenko
Stanley (Xinlei) Wang
Matt Zitzmann

Before our design can be implemented, some specific parameters should be tested empirically.
These parameters include the 3-second keep-alive message interval, as well as the 20% content
threshold for running the repair protocol. The low level details of the algorithm for assigning
backup parents according to our criteria also need to be determined. Efficient methods of storing
the tree structure in memory of the video server should be explored. Geographical location of
peers could be considered in more advanced versions of this system. Finally, video network
traffic flow properties should be studied to optimize the system.

9. Acknowledgements
We acknowledge our recitation instructor, Lewis Girod, and our teaching assistant, David
Schultz for providing us with valuable feedback on our design.

10. References
[1] M. G. Arranz, R. Aguero, L. Munoz, and P. Mahonen, “Behavior of UDP-based
applications over IEEE 802.11 wireless networks,” IEEE International Symposium on Personal,
Indoor and Mobile Radio Communications, vol. 2, no. 2, Sep.-Oct., pp: F-72-F-77, 2001.

[2] D.A. Menasce, “Security performance,” IEEE Internet Computing, vol.7, no. 3, May-Jun.
pp: 84-87, 2003.

Word Count: 5360

16