A feedback based rate control algorithm for multicast transmitted video conferencing.
This paper presents a feedback based rate control algorithm for video conferencing on the Internet. This algorithm adaptively controls the transmission rate of a video stream, which is being multicast to a heterogeneous group of receivers. The fact that the sender is transmitting a single video stream to many receivers introduces a number of issues. These issues include the variable nature of the available network resources and the fact that there is no easy way to determine the availability of these resources. In addition, even if we were able to track closely the changing network conditions, the best transmission rate for the aggregate means a trade off between high and low end receivers.  The algorithm presented in this paper, called the Target Bandwidth Rate Control Algorithm, dynamically controls the output rate of the video coder by receiving and processing bandwidth levels from each receiver in the videoconference. The goal of this algorithm is to maximize the aggregate amount of video displayable at the receivers. This algorithm also allows us to limit the worst case loss experienced by the low-end receivers. In addition to considering the available network bandwidth in the feedback information, this algorithm allows for workstation and user requirements to be considered when determining the senders output rate.  In order to show the effectiveness of this approach, we first analyze the algorithms performance in a simulation environment. In this set of tests we study the effects of different configurations of receivers in terms of the number of receivers and availability of resources. Additionally, we have implemented this algorithm in the VIC video conferencing system in order to analyze its effectiveness under real network conditions.
Introduction
The Internet has evolved from being heavily data oriented, to providing a whole range of services
including voice, video telephone and video conferencing. In addition to these different traffic types, the
resources in the Internet are very heterogeneous. From the end user's perspective, this heterogeneity
includes both the network and workstation resources. In order for applications to co-exist in this type of
environment, some type of adaptive control algorithm is needed.
In this paper we present a rate control algorithm designed to work with multicast transmission
videoconferencing applications. The problem we address consists of a videoconference between a sender,
who captures, encodes and transmits the video and one or more heterogeneous receivers. As shown in

Figure

1, this heterogeneity includes differences in workstation resources, local connections to the
Internet, types of Quality of Service (QoS) guarantees, and the amount of bandwidth available on the
different network paths between the sender and the receivers.
In this type of multicast environment we have imperfect knowledge of the current state of the network
resources. At best, a receiver can tell how much they are currently receiving and if they are experiencing
packet loss. In addition, since multicast transmission involves one sender and many receivers, obtaining
timely feedback is difficult without negatively impacting the video sender. The problem is more complex
since the network is dynamic and will change. Even if an algorithm existed that could know the current
state of the network, there would still be a need to determine a transmission rate that trades-off between

Figure

Workstations
under-utilizing the available resources for the high-end users, and high levels of packet loss for the low-end
users. Therefore, videoconferencing control algorithms attempt to pick a rate that maximizes the
bandwidth usable at the receivers and adapt this rate on the basis of estimates of the current network
conditions.
Many algorithms for controlling the amount of bandwidth used by a video application have been proposed
over the past few years. These approaches may be classified on the basis of who manages the control
algorithm, the sender [1, 2, 3, 4, 5, 6] or receiver [7, 8, 9, 10] (see Figure 2). In this paper we are
concerned with sender managed feedback control. These types of algorithms rely on measurements from
the network or receiver of the current availability of resources. Some of the measurements include packet
loss, buffer usage, and packet arrival jitter. In this paper we propose a new feedback control algorithm
developed specifically to support the multicast transmission of video over the Internet. The feedback
metric is the received bandwidth as determined by the receiver. This algorithm is different from its
predecessors because as it adjusts the sender's transmission rate based on receiver's feedback, it attempts
to maximize the usable bandwidth based on the correlation between packets lost in the network and those
discarded on the receiver's workstation.
Motivation
The goal of our video conferencing control algorithm is to pick a transmission rate that maximizes the
usable bandwidth on the receiver's workstation. Usable bandwidth is the amount of video that the
receiver is actually able to display. This quantity is dependent on the transmission rate of the sender, the
Video Control
Sender Controlled Receiver Controlled
Feedback
Control
Network
Information
Receiver
Information
Resource
Reservation
Load
Shedding
Multiple
Multicast
Channels
Multiple
Groups
Multiple
Stripes
Hierarchical Frame Rate

Figure

2: Control Algorithms for Multicasted Video Conferencing
network bandwidth available between the sender and the receiver (and therefore the network loss) and the
characteristics of the video coder.
The reason the displayable bandwidth is not solely dependent on the transmission rate and the packet loss
is due to the restrictions of the encoding/decoding process. These restrictions determine the amount of the
video and therefore, the number of packets that must be received successfully before the decoding process
may be run. The amount of this dependency is called the application level framing (ALF) [11]. This ALF
may range from one packet to an entire frame. If this unit is greater than one packet we have a
dependency between packets. This dependency will cause the loss of usable bandwidth at the receivers to
be greater than the loss in the network. As an example, if the ALF is one video frame and there are 20
packets on average per frame, then the loss of one packet in the network will translate into 19 packets
being thrown-away on the workstation.
A maximization function is required in order for a control algorithm to compensate for the dependency
between packets. This function determines a new transmission rate, which maximizes the usable
bandwidth, based on the receivers' feedback and an estimate of the workstation loss. Figure 3 gives and
example of this type of function. In order to estimate the workstation loss this function uses the
calculated network loss times the current average packets per frame. While a more detailed regression
analysis is possible to determine the relationship between network loss and workstation loss, the use of
average packets per frame gives a good first approximation. We will show that this approximation works
well in practice.
Goal: Find the new Transmission Rate T that maximizes the displayable bandwidth at n receivers:
)_
_
loss
workstatio
estimated
Where
rate
feedback
if
otherwise
frame
per
packets
loss
network
loss
workstatio
estimated _)
_
_

_
_
_
feedback_rate i is the current estimate of the available bandwidth between receiver i and the sender

Figure

3: Maximization Function
Once the new transmission rate has been calculated, a mechanism to modify the video stream needs to be
considered. There are many attributes, which may be adjusted in order to adapt the coder's output rate to
meet the new transmission rate. These attributes may be classified as either temporal or spatial [7]. The
temporal attributes concern adjusting the rate at which frames are encoded. The spatial attributes relate to
the quality of the image transmitted. These quality variables include the number of bits used to represent
the color in the image, the number of pixels in the image, the compression algorithm's key frame
distribution, and the amount of lossy compression (quantization) applied to the image [12, 13]. Since
each of these attributes affect the coder's output rate differently, the feedback control algorithm needs to
allow the sender to determine the best setting for each of these attributes based on the calculated
transmission rate.
As mentioned previously, our algorithm uses feedback from the receivers in order to adjust the output rate
of the video coder. In addition to network constraints, our control algorithm allows for the consideration
of the available workstation resources and the user's priority of the video application [14] in determining
the receivers' feedback rate. If the receiving workstation is unable to provide the necessary resources to
process the incoming video stream, some type of implicit or explicit load shedding will take place [14,
15]. While this load shedding will not cause the video display quality to degrade as quickly as network
packet loss, it may cause a jerky image display and wastes available workstation resources. The
algorithm may also consider the priority of the receiver's application. In a multitasking environment, the
user on the receiving end may determine that the video application is of lower importance and may wish
to limit the amount of resources committed to receiving and displaying the video stream [14]. While this
paper focuses on the impact of network constraints on the control algorithm, our algorithm allows for
workstation resource and user priority requirements to be considered when determining the video coder's
output rate.
The remainder of the paper is organized as follows. In Section 2 we give a brief introduction to the VIC
[16] video conferencing system, the MBone [17, 18] and RTP [19,20]. We then discuss an RTP based
feedback control algorithm, which has been presented in the literature. In Section 3, we present our
Target Bandwidth (TB) control algorithm and give details of how this algorithm was incorporated into
VIC. Section 4 discusses the simulation setup used to test the TB algorithm and presents the performance
results of the simulations. Section 5 contains a simulation performance analysis of the algorithm.
Section 6 presents the VIC performance results. Finally, Section 7 summarizes the paper and identifies
future work.
2. Background
In this section we examine the VIC application and some software it uses to support video conferencing in
the Internet. This software includes the MBone and the Real-Time Transport Protocol (RTP). Following
this discussion is an introduction to an RTP based Packet Loss Rate Control algorithm. This algorithm
was developed to control video conferencing application on the Internet. We will use this algorithm as a
base case as we analyze the performance of our algorithm.
In order to see how the TB algorithm performs in a live networking environment, we have modified a
version of the VIC application to include our rate control algorithm. VIC is a video conferencing system
developed at UCB/LBL. This system, like the earlier video conferencing tools nv and IVS [21], utilizes
IP-multicast and the MBone to deliver video streams over the Internet. VIC provides a flexible user
interface and supports multiple compression algorithms. It utilizes the Real-Time Transport Protocol in
order to transport the video stream and to deliver control messages between the sender and the receivers.
Readers interested in a more detailed description of VIC are referred to [16].
To facilitate the use of IP-multicast over the Internet, VIC utilizes the MBone. The MBone is a virtual
multicast network, which operates on the Internet. To support the distribution of multicast data, the
MBone utilizes MBone servers running a multicast routing daemon called mroute. These routing
daemons are geographically distributed and forward multicast packets to the local receivers. From the
sender's point of view, the MBone environment looks like a rooted tree with the sender as its root, the
mroute daemons as the interior nodes and the receivers as the leaf nodes. We discuss VIC's use of the
MBone later as a way to provide scalability in our rate control algorithm.
Real-Time Transport Protocol (RTP)
VIC utilizes RTP for data and control packet delivery. RTP is under development by the Internet
Engineering Task Force, Audio-Video Transport Working Group [22,23]. RTP is being developed for
applications requiring real-time services such as video conferencing. It will facilitate the implementation
of services such as playout synchronization, active-party identification and media identification. RTP
does not provide the underlying end-to-end transport protocol but will work with transport protocols such
as UDP.
RTP also provides a control protocol called RTCP. An example of how this would work for a video
application is shown in Figure 4. While RTCP packets may be used for many purposes, they are of
interest to us because they provide the means to transmit feedback information between the receivers and
the sender. This feedback is transmitted in an RTCP Receiver Report packet. A Receiver Report packet
is a control packet that is transmitted by all receivers participating in the videoconference. A part of the
receiver report is a QoS feedback field that may be used to convey information such as packet loss and
packet inter-arrival jitter. In the Target Bandwidth algorithm, we propose putting the receivers' feedback
rate in this field. Readers interested in a more detailed description of RTP are referred to [23].
Packet Loss (PL) Algorithm
An example RTP based rate control algorithm is based on measuring packet loss at the receivers. This
packet loss algorithm was initially discussed in [2,4] and was later refined by Schulzrinne et al. in [1].
We present an overview of this algorithm in order to compare its performance against the Target
Bandwidth algorithm.
The packet loss algorithm uses RTP receiver reports to determine the packet loss being experienced by the
receivers. This loss information is used to modify the video coder's output rate. There are four major
steps in this control algorithm. (Figure 5 shows an overview of the algorithm. This figure is a modified
version of the one found in [1].) The steps are:
1) For each receiver determine the packet loss rate.
Classify each receiver as UNLOADED, LOADED or CONGESTED.
Determine the corrective action necessary based on the percentage of users in each
classification. The options are to increase, decrease or hold constant the coder's output rate.
Advantages of this algorithm include its ability to decrease the overall packet loss rate and to follow
changes in network bandwidth. In addition, the packet loss information may be calculated without the aid
of the video application. Therefore, this approach is fairly independent of the application and only
requires application involvement in the final step. On the other hand this algorithm does have some
Sender Application
UDP
IPMulticast Internet
Receiver Application
UDP
IP
Receiver Application
UDP
IP

Figure

4: Video Application with RTP
limitations. One major limitation is that this algorithm does not take into account and adjust to the
dependency between packets. Therefore, the algorithm may over or under transmit depending on the
current size of the application level framing. In addition, since this algorithm does not look at the effects
of its transmission rate on the low-end receivers it may over-transmit and cause the low-end receivers to
be able to display little or none of the video signal. Also, our simulations show this algorithm may
oscillate for certain configurations. This oscillation, or continuous fluctuation between transmission rates,
is due to the dynamic interaction of some of the algorithm's parameters. Finally, since packet loss and
packet size are application and platform dependent it is difficult to make a direct translation between
packet loss and the workstations' available resources or the users' priorities of the video application.
Therefore, considering this information in the control algorithm would be difficult.
3. Target Bandwidth Algorithm
In this section we introduce the Target Bandwidth (TB) Algorithm. The goal of this algorithm is to
maximize the bandwidth utilized at the receivers while attempting to limit the maximum loss experienced
by any individual receiver. In addition to considering the availability of the network resources this
algorithm allows for user and workstation requirements to be considered when generating a receiver's
feedback.
This algorithm consists of two components. These are the receiver feedback component, which is run on
each receiver's machine, and the sender's rate calculation component, which is run on the sending
workstation. The receiver component is responsible for generating the feedback that reflects the receiver's
Packet Loss Low-pass
FilterL c
Loss %
Calculate
new_smoothed_loss_rate:
(for each receiver)
Receiver
Classification:
(for each receiver)
LOADED
CONGESTED
UNLOADED
Determine Action:
Increase Rate
Decrease Rate
Hold Rate Constant
Adjust Rate:
Multiplicative Decrease
Additive Increase

Figure

5:Packet Loss Rate Control Algorithm (modified from [1])
current ability to receive and process the video stream. The sender component is responsible for
collecting the receiver's feedback and calculating a transmission rate, which maximizes the displayable
bandwidth. By displayable bandwidth, we are referring to the amount of the video stream that is usable
by the receivers. This bandwidth will vary from the transmitted bandwidth depending on the amount of
packet loss in the network and the dependency between packets. This dependency between packets,
refers to the number of packets that must be received before the decoder may proceed. In the smallest
case each packet may be independently decoded. In other cases, the entire frame must be successfully
received before any decoding may take place. Therefore the loss of one packet will cause the entire frame
to be lost and translate into a very large loss in usable bandwidth.
Receiver Calculation
The focus of the receiver's calculation is the availability of the network resources. This calculation uses a
slow startup algorithm similar to TCP to estimate the current available bandwidth. If the receiver is
experiencing packet loss, then the receiver's network feedback rate is set to (1+increase_rate) times the
currently received bandwidth, where increase_rate is set to a, a small value such as 0.02. If the receiver is
not experiencing packet loss, then the receiver's feedback rate is calculated by first doubling the
increase_rate (e.g., 0.04, 0.08) and then multiplying (1+increase_rate) times the currently received
bandwidth. In order to prevent very large fluctuations in the feedback rate we limit the increase_rate to
some predetermined maximum. See Figure 6 for the pseudo code for the network feedback rate
calculation.
Unlike many feedback algorithms the actual calculation of the available bandwidth is performed on the
receiver. This allows us to consider requirements in addition to the current network availability.
Examples include the user's priority of the application and workstation conditions. By translating these
requirements into a common unit such as bits/sec (bandwidth) we can include the requirements in our
receiver's feedback calculation. As an example, if the user designates the video application as a lower
priority, we can set the feedback rate to some preconfigured minimum rate. While the actual calculation
of these two rates is beyond the scope of this paper, an example of how they may be used is discussed in
the VIC implementation section.
Sender Calculation
The sender's calculation is focused on maximizing the usable bandwidth at the receivers. Since the sender
wishes to maximize the aggregate, some receivers will receive less then their maximum rate while others
will experience some packet loss. The sender collects the receiver's feedback rates and then determines
the new transmission rate, which maximizes the receiver's usable bandwidth. In order to estimate the
effects of changes in the transmission rate on the receiver's usable bandwidth, the maximization algorithm
takes into account the application level framing and the corresponding dependency between packets.
The sender's algorithm is as follows:
Collect the receivers' feedback: feedback_rate i
Using the estimate of workstation loss find a transmission_rate that maximizes the displayable
bandwidth. (See maximization pseudo code in Figure 7)
Smooth and filter-out fluctuations in the transmission rate and pass the new rate to the sender's
video coder.
The sender's algorithm's second step calculates the new transmission rate. This calculation is based on
the maximization function presented earlier (Figure 3). As discussed earlier this function calculates the
If (packet_loss) {
increase_rate
else {
increase_rate *2
if (increase_rate > MAX_INCREASE)
increase_rate
Note: This part of the algorithm is run on each receiver and the
feedback_rate is transmitted to the sender for use in the
calculation of the sender's transmission rate.

Figure

6:Receiver's pseudo code
For {
{
if (temp_rate > feedback_rate j )
If (estimated_workstation_loss / temp_rate > b) {
break-out-of-inner-loop
if (value > max_value) {

Figure

7: Sender's maximization pseudo code
transmission rate that maximizes the receiver's usable bandwidth by estimating the loss of workstation
bandwidth. This estimation is based on the application level framing and the corresponding dependency
between packets. One shortcoming of this maximization calculation is that some lower-end receivers may
experience unacceptable loss. To prevent this from happening the algorithm has been modified to reject a
transmission rate where any receiver's estimated displayable bandwidth is less than b% of the transmitted
bandwidth.
The final step in the sender's algorithm is to smooth and filter-out large and small short-term (1 to 2
seconds) fluctuations in the transmission rate. The smoothing is done by taking the average of the last h
calculated transmission rates. This smoothing prevents large short-term fluctuations from completely
dominating the transmission rate. The drawback to this smoothing is it decreases the responsiveness of
the algorithm too long-term (tens of seconds or greater) changes in available bandwidth. The second part
of this step is to filter out small fluctuations in the transmission rate. This filtering is done by actually
only changing the sender's transmission rate if the new calculated rate has increase/decreased a small
percentage. Taken together this smoothing and filtering allows the algorithm to remain stable for the
majority of the users while short-term bursts (such as a small file transfer) only effect a few receivers. In
our simulation and applications runs we have seen that as the network noise levels increase the low-end
receivers begin to drag down the transmission rate. To reduce the effects of these variations the
smoothing the filtering values may be increased. It is important to realize that by increasing these values
we are reducing the responsiveness of the algorithm to change and therefore increasing the packet loss on
the low-end receivers.
There are four key details that allow this algorithm to perform well in a heterogeneous environment such
as the Internet. First, the algorithm works with existing network protocols and technologies. Second, the
dynamic transmission rate is based on both changes in the video coder and the receiver's resource
availability. Third, since the receivers are responsible for generating their own estimates of the available
resources, the algorithm allows for the inclusion of other factors such as workstation availability and user
priorities. Fourth, the algorithm uses a calculated packet loss rate to sense the state of the network. In
most transmission paradigms, packet loss is not acceptable. In the case of multicasted video, some loss is
to be expected unless the transmission rate is set to the minimum of all receivers. Therefore, the
algorithm intentionally sets the receiver's target rate to have a minimum of a% packet loss. It then
monitors the actual loss rate to determine if there has been a change in resource availability.
Implementation
In order to incorporate our TB algorithm into VIC, we made several modifications. On the sending side,
VIC was modified to receive and process the receivers' control feedback information via RTP Receiver
Reports. This information is then used to calculate the new target bandwidth rate, which is then passed to
the encoder. The encoder then modifies its quality parameters (i.e., frames per second) to meet this new
target rate. On the receiver side, the VIC application was modified to calculate the receiver's feedback
rate. On a periodic basis, the receiver component of the algorithm is executed and the receiver's feedback
is calculated based on the bandwidth received and the current packet loss status. This feedback is then
transmitted back to the sender via the RTP Receiver Reports.
In order to allow the TB Algorithm to run more efficiently in a real environment, two modifications were
made to the basic algorithm. First, a procedure was needed in order maintain the feedback information
from each receiver. This was implemented via a hash table using the receiver's RTP ID as the hash key.
In addition, a flag was added to each hash table entry in order to facilitate the removal of any outdated
receiver that may have terminated without informing the sender. By maintaining this hash table, we are
able to negate the effects of the asynchronous nature of feedback information.
The second improvement to VIC is the inclusion of user priority of the application into the receiver
feedback calculations. In VIC, the receiver has the ability to leave the video image in a thumbnail size
(icon size) or to increase its size. In our implementation of VIC, if the user does not increase the image
size, we set the maximum feedback rate to 750kb/s. In this way, users are able to specify the priority of
their video application. While more complex uses of the user priority feedback are possible, our VIC
implementation provides insight to the usefulness of this information.
Algorithm Timing
The components of the algorithm on both the sender and receiver are executed periodically. Several
factors need to be considered when setting the algorithm's control cycle time. These factors include the
overhead on the sender for processing the feedback information and the responsiveness of the algorithm
to change. Longer cycle times reduce the overhead of the RTP Receiver Reports on the sending
workstation but decrease the responsiveness of the algorithm to changes in network conditions. Since a
longer response time only significantly affects a receiver if there is a decrease in the available bandwidth,
we are trading off the quality of the video displayed on the low-end receivers versus the overhead of the
control algorithm on the sending workstation. We have found that a cycle time of 5 seconds is responsive
to changes, while generating less than 10kb/s of traffic for 150 receivers.
Scalability
As the number of receivers in the videoconference grows, the issue of scalability of the control algorithm
needs to be addressed. While the overhead of the receivers' control feedback is minimal and may be
adjusted by increasing the duration of the control cycle time, at some point this overhead may become
detrimental to the functioning of the sending machine or the network. One approach to reduce this
overhead is to perform some type of consolidation of the data prior to it reaching the sending machine.
From the sender's point of view, the MBone multicast environment looks like a rooted tree with the
sender as its root. We propose using this MBone multicast tree as a reduction tree allowing the interior
nodes (mroute daemons) to receive the feedback from the receivers, consolidate it and transmit it back to
the root (sender). The consolidation at each interior node will consist of quantizing the incoming
feedback into buckets and keeping track of the number of receivers in each bucket. If the number of
buckets is kept sufficiently small (< 500) the feedback from an interior node to the root may be done in
one packet. This packet would contain the number of receivers in each bucket. In this way, the sender
only receives one message from each interior node with a fixed number of buckets regardless of the
number of users.
Internet Quality of Service Guarantees
There has been significant research for providing Quality of Service (QoS) guarantees on the Internet.
These QoS guarantees involve providing a user's connection with a guaranteed bandwidth given certain
delay and peak rate constraints. One such approach is the Internet Engineering Task Force's Resource
Reservation Protocol (RSVP) [24]. RSVP is being developed to provide QoS guarantees to multicast
connections in the Internet. For the foreseeable future, Internet applications will need to exist in a mixed
RSVP/Non-RSVP environment (see Figure 1). One benefit of the TB algorithm is its ability to support
such an environment. For the RSVP users, the receiver's feedback rate may be the RSVP guaranteed rate.
receivers would use the standard TB algorithm's calculation for their feedback rate.
4. Simulation
We analyze the Algorithm's performance using both a simulation model and the VIC implementation.
The simulation model allows us to analyze the performance of the algorithm under many different
environmental conditions, which would be nearly impossible to control in a real implementation. This
section provides an overview of the simulation model used to generate the performance statistics. The
simulation model was implemented using C++ and CSIM [25], an event driven simulation package. This
model may be broken up into three main components. These components include the Sender, Receiver,
and Rate Control components (see Figure 8). The simulation parameter settings are shown in Figure 9.
The functionality of the Sender component is to generate frames that are broken up into packets and
placed in the receivers' input queues. The input into the Sender is the coder output rate (bandwidth),
which has been determined by the Rate Control component. The Sender determines the frame rate and
average frame size, based on the current coder output rate, and generates frames. These frames are
broken into packets and passed onto the Receiver component.
The second component in the simulation model is the Receiver component. In an actual simulation run,
the set of receivers is modeled as an array of the Receiver components. The Receiver component may be
divided into two subcomponents. These are the network and workstation subcomponents. The network
subcomponent is modeled as a single server with a fixed sized buffer. The inputs into the network are the
current network bandwidth and a packet received from the Sender component. The packets are placed
into each network's buffer and then processed by holding the network's server for
packet_size/network_bandwidth time. Any packets that are received while the buffer is full are discarded.
The second subcomponent of the Receiver is the workstation subcomponent. The main functionality of
the workstation subcomponent is to collect the packets from the network and determine the necessary
information for the rate control algorithm. The workstation subcomponent is also able to provide us with
Frame Rate
Generator
(converts Coder
Output Rate to
Frame Rate)
Create Frames
Network Workstation
Frame Rate
Packets
Packets
Feedback
Rate Control
New Rate Algorithm
New Coder Output Rate
Net_Bandwidth
Network Server
hold
Packsize/Net_Bandwidth
Packet Buffer
of size N Frame buffer
Sender
Networks Workstations

Figure

8: Simulation Model
measurement information regarding frame loss versus packet loss and allows us to test the user priority
aspects of the Target Bandwidth rate control algorithm.
The final component in the simulation is the Rate Control component. This component is responsible for
collecting the control information from the receivers and running the rate control algorithm. We have
implemented both the Target Bandwidth and Packet Loss rate control algorithms. The output of the Rate
Control component is the coder's output rate, which is used as input into the Sender component.
Parameter Value
Max_increase 20%
Min_increase (a) 2%
Max_loss (b) 60%
Smoothing
Filtering -2%

Figure

9: Simulation Parameter Settings
5. Simulation Performance Analysis
There are a number of simulation conditions that may be varied in order to understand the performance of
the algorithm. In this section, we analyze how the following variations affect the
Background network noise levels (short term fluctuations in the network bandwidth)
Changes in video coding parameters (dependency between packets)
Large, long term network fluctuations and changes
Receiver group sizes and different distributions of network resources
The first simulation analyzes the effect of short-term network noise. In this simulation, we model short
term network noise using a negative exponential distribution. The amount of network noise was modified
by varying the noise mean rate from between 1% to 20% of the total network bandwidth. Figure 10-a
shows the transmission rate and Figure 10-b shows the average usable bandwidth for simulation runs with
noise mean rates of 5%, 10%, 15% and 20% for both the TB and PL algorithms. These graphs show that
both algorithms remain fairly stable at noise levels of 5% and 10%, with two exceptions. At simulation
time 343 and again at 438 the TB algorithm experiences a period of large adjustment. These are due to a
small number of receivers experiencing heavy short-term congestion. This identifies one of the
weaknesses of the algorithm. Since the algorithm attempts to adjust quickly to fluctuations and
restricts the maximum loss rates of the lower end users, the algorithm may be strongly affected by the
loss rates of a few low-end receivers. The alternative is to ignore the losses experienced on the low-end
receivers, but as we show later this leads to those receivers experiencing unacceptable loss rates. Figure
also shows the effects of noise mean levels of 15% and 20%. At these levels of noise both algorithms
tend to become unstable, with the TB algorithm being heavily effected by the low-end receivers.
Sender Transmission Rate20000060000010000001400000
Time (sec)
Bandwidth
Trans
PL Trans
5% 10% 15% 20%
Average Usable Bandwidth20000060000010000001400000
Time (sec)
Bandwidth
Usable Bandw
PL Usable Bandw
5% 10% 15% 20%

Figure

In the next set of simulations we examine at the effects of changes in the video coding parameters.
Specifically, changes in the dependency between packets. Figure 11-a,b,c,d shows the results of these
simulations. In Figure 11-a we see the changes in the transmission rate of the video coder as the
dependency between packets moves from an average of 1 packet (e.g., all packets are independent and
may be decoded individually) to a dependency of 20 packets. As can be seen in Figure 11-a, the
transmission rate for the TB algorithm is higher for small packet dependencies but adjusts to lower rates
as the dependency increases. This is due to that fact that as the dependency between packets increases the
effects of packet loss on the receiver's increases. Therefore, a higher dependency between frames
requires a lower transmission rate in order to accommodate the low-end receivers. Since the PL algorithm
does not take packet dependency into account, it does not adjust its transmission rate as the dependency
changes.

Figure

11-b shows how this adjustment in transmission rate effects the average usable bandwidth at the
receivers. As this figure shows, in the smaller dependency case the TB algorithm achieves a much higher
usable bandwidth. As the dependency between packets increases both algorithms begin to converge on
Sender Transmission Rate3000009000001500000
3 48 93 133 178 218 263 308 348 393
Time (sec)
Bandwidth
Trans
PL Trans
~1 Packet
per frame
~5 packets
per frame
Packets
per frame
Packets
per frame
Average Usable Bandwidth3000009000001500000
3 48 93 133 178 218 263 308 348 393
Time (sec)
Bandwidth
Usable Bandw
PL Usable Bandw
Lowest 7 Receivers
Usable Bandwidth20000060000010000003 48 93 133 178 218 263 308 348 393
Time (sec)
Bandwidth
Lowest 7 Receivers
Usable Bandwidth20000060000010000003 48 93 133 178 218 263 308 348 393
Time (sec)
Bandwidth
(D)

Figure

the same average usable bandwidth. If we combine the results from Figure 11-a and Figure 11-b during
the periods of high dependency (simulation time between 213 and 408 seconds), we see that the PL
algorithm is transmitting at a higher rate but the usable bandwidth is the same as the TB algorithm. The
effects of this over-transmission can be seen in Figure 11-c and Figure 11-d. These figures show the
usable bandwidth for the lowest 7 receivers. As these figures show, during the last 200 seconds of the
simulation the low-end users of the PL algorithm experience a significant amount of loss in usable
bandwidth. In some cases 2-3 receivers are receiving none of the video signal for 15 seconds or longer.
In contrast, during the majority of this time the receivers (Figure 11-c) are receiving a significant
portion of the video signal.
Based on many simulation runs over varying distributions we have found that for cases with small packet
dependencies the algorithm tends to have a higher transmission rate and higher average usable
bandwidth without the negatively effecting the low-end receivers. As the dependency grows the
algorithm will tend to transmit at a lower rate than the PL algorithm. While the effects of the higher
transmission rate of the PL algorithm on the average usable bandwidth are mixed, (we show later there are
receiver distributions where the PL algorithms average usable bandwidth is much higher than the
Algorithms) this higher transmission rate has significant negative effects on the low-end receivers.
The final set of simulations study the effects that different distributions of receivers' network resources
and the number of receivers has on the sender's transmission rate, the receiver's average usable bandwidth
and the low-end receiver's usable bandwidth. In our simulations we analyzed runs with receiver sizes of
10, 30, 75 and 150 users. In order to simplify our discussion we have included only data for runs with 75
users. In addition we examine three different distributions of receiver's resources. These receiver
bandwidth distributions are show in Figure 13 for receiver size of 75. These figures show the
approximate mean rate for the receivers at the start of the simulation. While the mean rate of the
receivers' bandwidths varies during the simulation, the overall shape of the distribution remains fairly
constant.
In order to understand the effects of the different distributions and varying number of receivers we ran our
simulation over dynamic network bandwidth conditions. These simulations are meant to look at longer
term (tens of seconds to minutes) and larger fluctuations in available network bandwidth. Figure 12
tracks how the average receiver bandwidth varied over time for our final simulation runs. The actual
bandwidth amounts, in Figure 12, were intentionally left off since they will vary based on the distribution
of the receivers. Figure 14 (a,b,c,d) , Figure 15 (a,b,c,d), Figure 16 (a,b,c,d) show the results of the
simulation runs for 75 receivers using the conditions in Figure 12 for the three distributions in Figure 13.

Figure

14-a, Figure 15-a, and Figure 16-a show the transmission rates for all three distributions for 75
receivers. These figures show that the PL algorithm is more aggressive in its transmission rate, especially
at the higher transmission rates. This is due to the fact that the frame size is greater and therefore the
dependency between packets is greater. The packet dependency forces the TB transmission rate lower.

Figure

16-a, which displays results for the top-heavy distribution, shows that the PL algorithm is
significantly more aggressive. The TB algorithm is constrained in the top-heavy distribution by the loss
rates of the lower end receivers. As you can see in all three figures the PL algorithm tends to oscillate.
As we will show later this oscillation negatively effects the usable bandwidth, especially on the low-end
receivers.
Network Bandwidth Fluctuations
Timing and Relative Magnitude0.30.93 103 203 303 403 503 603 703
Time (sec)
Relative
Bandwidth
Change

Figure

12: Timing and Magnitude of bandwidth changes for the
simulations shown in Figure 14, Figure 15, and Figure 16

Figure

14-b, Figure 15-b, and Figure 16-b show the average usable bandwidth on the receiver's. These
graphs allow us to see the effects of the transmission rates across the entire 75 receivers. The average
usable bandwidth for the PL algorithm in the top heavy and bottom heavy cases (Figure 14-b, Figure 16-
b) is higher than the algorithm. This is due to the constraints of the lower-end users on the
algorithm. While the average usable bandwidth is higher, we will show the negative effects on the lower-end
receivers are significant. Figure 15-b shows that the average usable bandwidth in the normal
distribution is comparable between the two algorithms. This is due to the tightness of the distribution of
receivers. In the normal distribution the low-end receivers do not dominate the transmission rate for the
algorithm.
Top Heavy Distribution515
Receiver Bandwidth in Kb/sec
of
Receivers
Bottom Heavy Distribution5386 547 709 871 1033 1195 1357
Receiver Bandwidth in Kb/sec
of
Receivers
Normal Distribution1030386 547 709 871 1033 1195 1357
Receiver Bandwidth in Kb/sec
of
Receivers

Figure

13: Receiver Distributions
Sender Transmission Rate100000030000005000000
Time (sec)
Bandwidth
PL Trans.75.1
Lowest 7 Receivers
Usable Bandwidth500000150000025000003500000
Time (sec)
Bandwidth
Lowest 7 Receivers
Usable Bandwidth500000150000025000003500000
Time (sec)
Bandwidth
(D)
Average Usable Bandwidth100000030000005000000
Time (sec)
Bandwidth
Usable Bandw.75.1
PL Usable Bandw.75.1

Figure

14 (A,B,C,D):Bottom Heavy Distribution, 75 Receivers
While the average usable bandwidth graphs show how the algorithm's choice of transmission rate impacts
the aggregate, it does not tell the entire story. Figure 14-c,d, Figure 15-c,d, and Figure 16-c,d show the
usable bandwidth for the lowest seven receivers. Key points from these figures are:
While both algorithms experience large dips in usable bandwidth during large drops in
available bandwidth (simulation times 228, 448, 548), on the whole the lower end receivers
fair much better under the TB algorithm. This is due to the algorithm restriction on the
maximum loss in its transmission rate calculation.
2) For the PL algorithm the lowest receiver's experience considerable oscillation and extended
periods of time when no usable bandwidth is being received. This is due to the more
aggressive transmission rate that causes the lowest receivers to experience high packet loss
rates. For the top-heavy distribution all seven low-end receivers experience periods of over 45
Lowest 7 Receivers
Usable Bandwidth500000150000025000003500000
Time (sec)
Bandwidth
(D)
Average Usable Bandwidth50000015000002500000350000045000003 103 203 303 403 503 603 703
Time (sec)
Bandwidth
Usable Bandw.75.4
PL Usable Bandw.75.4
Sender Transmission Rate50000015000002500000350000045000003 103 203 303 403 503 603 703
Time (sec)
Bandwidth
PL Trans.75.4
Lowest 7 Receivers
Usable Bandwidth500000150000025000003500000
Time (sec)
Bandwidth

Figure

(A,B,C,D):Normal Distribution, 75 Receivers
Sender Transmission Rate100000030000005000000
Time (sec)
Bandwidth
PL Trans.75.2
Average Usable Bandwidth100000030000005000000
Time (sec)
Bandwidth
Usable Bandw.75.2
PL Usable Bandw.75.2
Lowest 7 Receivers
Usable Bandwidth500000150000025000003500000
Time (sec)
Bandwidth
(D)
Lowest 7 Receivers
Usable Bandwidth500000150000025000003500000
Time (sec)
Bandwidth

Figure

Receivers
seconds when they are able to display none of the video signal. This can be seen starting at
simulation times: 368, 518 and 593 in Figure 16-d.
While the PL algorithm transmission rate for the normal distribution (Figure 15-d) is only
slightly more aggressive than the algorithms, the oscillation in the transmission rate
accounts for most of the heavy losses on the low-end receivers.
In summary we have found that the TB algorithm adjusts well to fluctuations in network availability and
changes in the video coder. In addition we have shown that the algorithm is successful at maximizing the
displayable bandwidth at the receivers while limiting the maximum loss at the low-end receivers. One
item that must be considered when utilizing this algorithm is the fact that a few low-end receivers may
dominate the transmission rate. This is due to their impact on the maximization function.
6. VIC Results
In order to analyze the performance of the algorithm's implementation in the VIC system we need
to understand how changes in resource availability affect the low-end receivers. Therefore, a small set
of users will be sufficient to test the performance of this implementation in varying network
conditions. The environment used was MSU's ATM test bed. The configuration for this is shown in

Figure

17. This configuration consists of four Sun Ultras connected to two Fore ATM ASX-200
Switches via 155mb/s links. In addition an HP analyzer was connected to the two switches to provide
background traffic. This configuration was chosen because it gives us tight control over the available
network capacity.
In order to monitor the performance of the algorithm in these test environments, we utilized the PGRT
Fore ATM
Switch
Fore ATM
Switch
Sun Ultra
Sun Ultra
Sun Ultra
Sun Ultra
Analyzer

Figure

Test Bed
visualization system [26,27]. This system allowed us to monitor the performance of the VIC
application on each of the workstations in real-time. In addition to providing an on-line performance
tool, the BRISK system enabled us to extract the performance data for off-line analysis.
The focus of these tests was similar to the tests run via simulation. These tests focused on how
variations in network resources impact the algorithm's ability to operate effectively. The first test
examines the effects of TCP traffic on the TB algorithm. In this test the HP analyzer was set up to
consume 154 MB/s of the 155 MB/s link between the two ATM switches. This left a little over 1 MB/s
for VIC and the TCP application. In this test we wish to determine how these two sources will interact.
Using the same parameters as in the simulation model (Figure 9), the TCP source begins to dominate,
see

Figure

18. After one minute, the TCP source has begun to consume more bandwidth than the video
application. In a separate simulation, not shown, we increased the smoothing parameter to 3 cycle times
and the filtering parameter to -6%. These increases had two effects. In some of the runs these increased
parameters tripled the time it took for the TCP source to dominate the link to over 3 minutes. In a subset
of runs the TCP source was unable to acquire any of the link and timed out.
Based on these findings we have come up with three conclusions.
In the first test (2 cycle smoothing and filtering of -2%), long term TCP application will begin to
dominate the link, while TCP applications of a few tens of seconds will interact well with the
application. We tested this last point by FTPing small to medium size files (up to 2MB) over the
congested link while VIC was running. While there was some fluctuations in the video transmission
VIC versus a TCP Application
Calculated Rate2006001000140011.3 51.5 91.6 132 172 212 253 293 333 374 414
Time (sec)
Bandwidth
W2 Receiver
VIC versus a TCP application
Usable Bandwidth2006001000140011 52 92 132 172 212 253 293 333 374 414
Time (sec)
Bandwidth
W2 Receiver

Figure

18: VIC with TCP Traffic
rate and loss in usable bandwidth, the two sources (FTP and VIC) were able to share the link.
In the second test (3 cycle smoothing and filtering of -6%) the video application is fairly greedy.
The tradeoff here is who should dominate the link, the long-term TCP application or the video
source. This highlights the problem of multicasting video. Either the video application must
transmit at the rate of the lowest receiver or there will be periods of congestion and someone will
have to be greedy. This leads us to next point.
In the current Internet, the routers use a drop-tail queue management mechanism. This type
technique allows for some applications to dominate and other applications to starve. Current
research into other queue management algorithms, such as RED [28], will help alleviate this
problem. In this type of algorithm, no source is able to completely dominate the link.
The second test involves the use of two video sources competing over the same link. The VIC
application was first started between the workstation pair W1 and W2 and 130 seconds later on the pair
W3 and W4.

Figure

20 shows the results of this simulation. On this graph the lines for W1 and W3
represent the sender's target bandwidth rate. Lines W2 and W4 represent the receiver's feedback rate.
As can be seen in this figure, as the second source is initiated the target bandwidth as determined by
sender W1 drops to accommodate this new network demand. Once a state of equilibrium is reached, the
two sources maintain a fairly stable target bandwidth rate as seen by lines W1 and W3.
7.

Summary

This paper presented a feedback based control algorithm for video conferencing on the Internet. This
Dual VIC Application
Calculated
Time (sec)
Bandwidth
W3 Sender
W4 Receiver
W2 Receiver
Dual VIC Applications
Usable Bandwidth2006001000140018 58 99 139 179 219 260 300 340 381 421 462 502 542
Time (sec)
Bandwidth
W3 Sender
W4 Receiver
W2 Receiver

Figure

20: Multiple VIC applications
algorithm, called Target Bandwidth (TB), utilizes RTP control packets to transmit feedback information
regarding the availability of the receiver's resources. The algorithm was designed to maximize the
usable bandwidth at the receivers while limiting the maximum loss rate at the low-end receivers. In
order to do this the algorithm estimates the loss at the workstation based on the receivers' feedback, the
calculated network loss and the average packets per frame. From an implementation standpoint this
algorithm uses exiting technologies and is of low complexity.
In order to show the effectiveness of the TB algorithm, we analyzed it using a simulation model and in
the VIC video conferencing application. The simulations allowed us to analyze the algorithms
performance under dynamic networking conditions. We studied the effects of background network
traffic, long-term fluctuations in network resources, changes in receiver group sizes and differences in
the distribution of network resources. The results showed that the TB algorithm is stable under various
network conditions and adjusts well to network rate fluctuations.
As part of the VIC application tests, we analyzed the performance of the TB algorithm while it interacts
with different types of network traffic. Specifically we studied the effects of the algorithm competing
with a TCP based application and the interaction between two VIC applications. The TCP test showed
that with long-term interaction with a TCP application, someone will have to be greedy. This is an
inherent problem with multicasting video in the Internet. Current research into queue management
mechanisms will help to alleviate this problem. In the second set of test we where able to show that two
video applications sharing the same link reach a state equilibrium and remain fairly stable.
Future Research
We are extending the TB algorithm in two areas. First, since the TB algorithm's feedback is generated
at the receiver, we are examining techniques to detect changes in resource availability at the receiver. If
we were better able to identify the occurrence and size of resource changes, we would be able to take
advantage of the TB algorithm's feedback mechanism and quickly jump to a new rate. This is in
comparison to our current approach, which tends "to feel" for changes and progressively move toward a
new rate. Second, one approach to transmit video to a heterogeneous group of receivers is to split the
video across multiple transmission channels [7]. In this way the receivers may choose the level of
resolution of the video stream that best meets their resource availability. We are studying methods to
enable the Target Bandwidth algorithm to support this type of video transmission.



--R

"Dynamic QoS Control of Multimedia Applications based on RTP"
"A Rate Control Mechanism for Packet Video in the Internet"
"Packet Video Transport in ATM Networks with Single-bit Feedback"
"Scaleable Feedback Control for Multicast Video Distribution in the Internet"
"An Adaptive Congestion Control Scheme for Real-Time Packet Video Transport"
"An Application Level Video Gateway"
"Low-Complexity Video Coding for Receiver-Driven Layered Multicast"
"Multipoint Communication by Hierarchically Encoded Data"

"On the use of Destination Set Grouping to Improve Fairness in Multicast Video Distribution"
"A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing"
"A Performance Study of Adaptive Video Coding Algorithms for High Speed Networks"
"Experiments with Digital Video Playback"
"Collaborative Load Shedding for Media-Based Applications"
"Workstation Video Playback Performance with Competitive Process Loads"
"VIC: A flexible Framework for Packet Video"
"MBone Provides Audio and Video across the Internet"
"MBONE: The Multicast Backbone"
"Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications"
"RTP: A Transport Protocol for Real-Time Applications"
"Videoconferencing on the Internet"
"Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications"
"RTP: A Transport Protocol for Real-Time Applications"
"RSVP: A New Resource ReSerVation Protocol"
Based Process Oriented Simulation Language"
"The Application of Software Tools to Complex Systems"
"Modeling, Evaluation, and Adaptive Control of an Instrumentation Systems"
"Random early Detection Gateways for Congestion Avoidance"
--TR

--CTR
Aleksandar M. Bakic , Matt W. Mutka , Diane T. Rover, An on-line performance visualization technology, SoftwarePractice & Experience, v.33 n.15, p.1447-1469, December
C. Bouras , A. Gkamas , A. Karaliotas , K. Stamos, Architecture and Performance Evaluation for Redundant Multicast Transmission Supporting Adaptive QoS, Multimedia Tools and Applications, v.25 n.1, p.85-110, January 2005
video conferencing;video multicasting;rate control;adaptive applications;VIC;RTP