Probabilistic congestion control for non-adaptable flows.
In this paper we present a TCP-friendly congestion control scheme for non-adaptable flows. The main characteristic of these flows is that their data rate is determined by an application and cannot be adapted to the current congestion situation of the network. Typical examples of non-adaptable flows are those produced by networked computer games or live audio and video transmissions where adaptation of the quality is not possible (e.g., since it is already at the lowest possible quality level). We propose to perform congestion control for non-adaptable flows by suspending them at appropriate times so that the aggregation of multiple non-adaptable flows behaves in a TCP-friendly manner. The decision whether or not a flow is to be suspended is based on random experiments. In order to allocate probabilities for these experiments, the data rate of the non-adaptable flow is compared to the rate that a TCP flow would achieve under the same conditions. We present a detailed discussion of the proposed scheme and evaluate it through extensive simulation with the network simulator ns-2.
Introduction
C ONGESTION control is a vital element of computer
networks such as the Internet. It has been widely
discussed in the literature { and experienced in reality
{ that the lack of appropriate congestion control mechanisms
will lead to undesirable situations such as a congestion
collapse [1]. Under such conditions, the network
capacity is almost exclusively used up by trac that never
reaches its destination.
In the current Internet, congestion control is primarily
performed by TCP. During recent years, new congestion
control schemes were devised, supporting networked applications
that cannot use TCP. Typical examples of such
applications are audio and video transmissions over the
Internet. One prime aim that these congestion control
schemes try to achieve is to share the available band-width
in a fair manner with TCP-based applications, thus
falling into the category of TCP-friendly congestion control
mechanisms.
TCP, as well as existing TCP-friendly congestion control
algorithms, require that the data rate of an individual
ow can be adapted to network conditions. Using TCP,
it may take a variable amount of time to transmit a xed
amount of data, or with TCP-friendly congestion control,
the quality of an audio or video stream may be adapted
to the available bandwidth.
While for a large number of applications this not a limi-
tation, there are cases where the data rate of an individual
ow is determined by the application and cannot be adjusted
to the network conditions. Networked computer
games are a typical example, considering the fact that
players are very reluctant to accept the delayed transmission
of information about a remote player's actions. Live
audio and video transmissions with a xed minimum qual-
ity, below which reception is useless, fall into the same
category. For this class of applications there are only two
acceptable states: either a
ow is on and the sender transmits
at the data rate determined by the application or it
is no data is transmitted at all. We call network
ows produced by these applications non-adaptable
ows.
In this paper we describe a TCP-friendly end-to-end
congestion control mechanism for non-adaptable unicast
ows called Probabilistic Congestion Control (PCC). The
main idea of PCC is
to calculate a probability for the two possible states
(on/o) so that the expected average rate of the
ow is
TCP-friendly,
to perform a random experiment that succeeds with
the above probability to determine the new state of the
non-adaptable
ow, and
to repeat the previous steps continuously to account for
changes in the network conditions.
Through this mechanism it is ensured that the aggregate
of multiple PCC
ows behaves TCP-friendly.
The remainder of this paper is structured as follows.
Section II summarizes related work. In Section III we
examine non-adaptable
ows in more detail. A thorough
description of the PCC mechanism is given in Section IV.
The results of the simulation studies that were conducted
are presented in Section V and we conclude the paper with
a summary and an outlook on future work in Section VI.
II. Related Work
Much work has been done on TCP-friendly congestion
control schemes for applications that cannot use TCP.
Prominent examples of these schemes are PGMCC [2],
TEAR [3], TFRC [4], and FLID-DL [5]. A discussion of
such TCP-friendly congestion control mechanisms can be
found in [?]. TCP, as well as all existing TCP-friendly
congestion control schemes, requires that the bandwidth
consumed by a
ow be adapted to the level of congestion
in the network. By denition, non-adaptable
ows cannot
use such congestion control mechanisms.
It is conceivable to use reservation mechanisms such as
Intserv/RSVP [7] or Diserv [8] for non-adaptable
ows
so as to prevent congestion altogether. However, these
mechanisms require that the network supports the reservation
of resources or provides dierent service classes.
This is currently not the case for the Internet. In con-
trast, PCC is an end-to-end mechanism that does not
require support from the network. With PCC it is possible
to \partly" admit a
ow and to continuously adjust
the number of
ows to network conditions.
We are not aware of any previous work that directly
matches the category of probabilistic congestion control.
III. Non-Adaptable Flows
For the remainder of this paper, a non-adaptable
ow
is dened as a data
ow with a sending rate that is determined
by an application and cannot be adjusted to the
level of congestion in the network. A non-adaptable
ow
has exactly two states: either it is in the state on, carrying
data at the rate determined by the application, or
it is o, meaning that no data is transmitted at all. Any
data rate in between those two states is inecient, since
the application is not able to utilize the oered rate.
Examples of applications using non-adaptable
ows are
commercial network games such as Diablo II, Quake III,
Ultima Online, and Everquest. These games typically
employ a client-server architecture. The data rate of the
ows between client and server is determined by the fact
that the actions of the players must be transmitted instan-
taneously. Similar restrictions hold for the
ows between
participants of distributed virtual environments without
a centralized server. If a congestion control scheme delays
the transmission of actions too long, the application
quickly becomes unusable. This can easily be experienced
by experimenting with a state-of-the-art TCP-based networked
computer game during peak hours. For this rea-
son, a number of applications resort to UDP and avoid
congestion control altogether.
A situation with either no congestion control at all or
vastly reduced utility in the face of moderate congestion
is not desirable. A much more preferable approach is
to turn the
ows of some participants o and to inform
the application accordingly. All other participants do not
need to react to the congestion. On average, all users
should be able to participate in the session for a reason-able
amount of time between o-periods to ensure utility
of the application. At the same time, o-periods should
be distributed fairly among all participants.
Other examples of applications with non-adaptable
ows are audio or video transmissions with a xed quality.
There are two main reasons why it may not be possible to
scale down a media
ow: either the user does not accept
a lower quality, or the quality is already at the lowest possible
level. The second reason indicates that a congestion
control mechanism for non-adaptable
ows can complement
congestion control schemes that adapt the rate of a
ow to current network conditions.
IV. Probabilistic Congestion Control
The Probabilistic Congestion Control scheme (PCC)
provides congestion control for non-adaptable unicast
ows by suspending
ows at appropriate times. PCC is an
end-to-end mechanism and does not require the support
of routers or other intermediate systems in the network.
The key aspect of PCC is that { as long as there is
a suciently high level of statistical multiplexing { it is
not important that each single non-adaptable
ow behave
TCP-friendly at any specic point of time. What is important
is that the aggregation of all non-adaptable
ows
on a given link behave as if the
ows were TCP-friendly.
Due to the law of large numbers this can be achieved if
(a) each PCC
ow has an expected average rate which is
TCP-friendly and if (b) each link is traversed by a su-
ciently large number of independent PCC
ows.
At rst glance (b) may be considered problematic, because
it is possible that a link is traversed only by a small
number of PCC
ows. However, further re
ection reveals
that in this case the PCC
ows will only be signicant
in terms of network congestion if each individual PCC
ow occupies a high percentage of the link's bandwidth.
We therefore relax (b) to the following condition (c): a
single PCC
ow is expected to have a rate that is only
a small fraction of the available bandwidth on any link
that it crosses. Given the current development of available
bandwidth in computer networks, this is a condition
that is likely to hold true.
A. Requirements
There are a number of requirements that have to be
fullled in order for PCC to be applicable:
R1: High level of statistical multiplexing. Condition (c)
discussed above is met.
R2: No synchronization of PCC
ows at startup. PCC
ows start up independent of each other.
R3: The average rate of a PCC
ow can be predicted.
In order for PCC to work, it must be possible to
predict the average rate of a PCC
R4: The average rate of a TCP
ow under the same conditions
can be estimated. We expect that there is a
reasonably accurate method to estimate the average
bandwidth that a TCP
ow would have under
the same network conditions.
B. Architecture
A simple overview of the PCC architecture is depicted
in

Figure

1. A PCC sender transmits data packets at
the rate determined by the application, while the PCC
receiver monitors the network conditions by estimating
a TCP-friendly rate using a model of long-term TCP
throughput. Whenever a PCC receiver observes a degradation
in network conditions, it conducts a random experiment
to determine whether or not the
ow should be
suspended. In the case of a negative result, a control
packet is sent to notify the sender that it is temporarily
required to stop. After a certain o-period, a sender may
then resume data transmission. For PCC, we chose to
allocate as much functionality to the receiver as possible
to facilitate a future extension of PCC to multicast.
(data, reflected timestamp, sequence number)
data packets
receiver
sender
control packets
(flow state: on/off, timestamp)
- start stop flow
reflect timestamp
on/off-probability calculation
parameter measurements
TCP-friendly rate and
- random experiment
Fig. 1. PCC Architecture
While a
ow is in the on-state, control packets are sent
at certain time intervals. They allow to continuously measure
the round-trip time required to determine the TCP-friendly
rate and they serve as a backup mechanism in
case of very heavy network congestion. In the absence of
these periodic control messages, the sender stops sending,
thus safeguarding against the loss of notications to stop.
As long as the
ow is in the on-state, the data packets
are transmitted at the rate determined by the applica-
tion. Each data packet includes the timestamp of the
most recent control packet that the sender has received
in order to be able to determine the round-trip time. Each
1 There are multiple ways in which this can be done, ranging from
a constant bit-rate,
ow where this prediction is trivial, to the usage
of application level knowledge or prediction based on past samples
of the data rate.
data packet also contains a sequence number to allow the
receiver to detect packet losses.
For the remainder of this work we use the TCP through-put
formula of Padhye et al. [9] to compute the TCP-friendly
rate. In order to determine the parameters required
for the formula, the current version of PCC uses
the measurement mechanisms proposed for the TCP-Friendly
Rate Control Protocol (TFRC) [4]. However,
it is important to note that PCC is independent of the
method used to estimate the throughput of a TCP
ow
for given network conditions. A possible alternative, for
example, would be to use the rate calculation mechanism
of TCP Emulation At Receivers (TEAR) [3].
C. Continuous Evaluation
To determine the probability with which a PCC
ow
is allowed to send for a certain time interval T , it is necessary
to compare the average rate r NA of PCC to the
TCP-friendly rate r TCP .
r NA
(1)
where p denotes the ratio of r NA to r TCP . When solving
the equation, two outcomes are possible:
1: The non-adaptable
ow consumes less than or
the same amount of bandwidth that would be TCP-friendly
and should therefore stay on.
1: The non-adaptable
ow consumes more
bandwidth than a comparable TCP-friendly
ow. In
this case, p is taken as a probability and the non-
adaptable
ow should be turned
For uniformly distributed random number x
is drawn from the interval (0; 1]. If x > p holds, the PCC
ow is turned o for a time of T . After that time interval
the
ow may be turned on again. If x  p, then the
ow
remains in the on-state. Since we require a sucient level
of statistical multiplexing (R1) and because of the law of
large numbers, the aggregation of all PCC
ows behaves
as if each of them were TCP friendly.
T is an application-specic parameter that is crucial
for the utility of the protocol and thus for the user acceptance
of the congestion control mechanism. For example,
if short news clips are transmitted T should be equal to
the length of these clips. If a networked computer game
is played, T should be determined so that in \normal"
congestion situations the player is able to perform some
meaningful tasks during the average time the
ow stays
on. If the network is designed to carry the required trac
(i.e., congestion is low), then the average on-time will be
a large multiple of T .
Under the assumption of a relatively constant level of
congestion, the further behavior of PCC is very simple.
After a time of T , a
ow that is in the on-state has to repeat
the random experiment using the same r TCP . How-
ever, in a real network the level of congestion is not constant
but may change signicantly within a time frame
much shorter than T . There are two cases to consider:
network conditions may improve (increasing r TCP ) or the
congestion may get worse.
The rst case is not problematic since it does not endanger
the overall performance of the network. PCC
ows
may be treated unfairly in that they are turned
a higher probability than they should be. However, after
a time of T the decision will be reevaluated with the correct
probability and PCC will adjust to the new level of
The second case is much more dangerous to the net-
work. In order to prevent unfair treatment of competing
adaptive
ows or even a congestion collapse, it is very
important that PCC
ows respond quickly to an increase
in congestion. Therefore, PCC continuously updates the
value for p and performs further random experiments if
necessary.
Obviously, it is not acceptable to simply recalculate p
without accounting for the fact that the
ow could have
been turned during one of the previous experiments.
any adjustments, PCC would continue to perform
the same random experiment again and again and
the probability to survive those experiments would drop
to 0. The general idea of how to avoid this drop-to-zero
behavior is to adjust the rate used in the equations to
represent the current expected average data rate of the
ow.
PCC modies the value r NA , taking into account the
last random experiments that have been performed for the
ow. To this end, PCC maintains a set P of the probabilities
i with which the
ow stayed on in the random
experiments during the last T seconds. 2 The so-called effective
rate r EFF is determined according to the following
r NA
r NA for
For the continuous evaluation and the random experiments
r EFF replaces r NA in Equation 1.
D. Initialization
At the initial startup and after a suspended
ow
restarts, a receiver does not have a valid estimate of the
current condition of the network and thus is not able to instantaneously
compute a meaningful TCP-friendly rate.
To avoid unstable behavior, a
ow will stay in the on-state
for at least the protected time T 0 , where T 0 is the
amount of time required to get the necessary number of
2 Note that p i
the corresponding p  1.
measurements to obtain a suciently accurate estimate
of the network conditions.
After T 0 , PCC determines whether it should cease to
send or may continue. In order to take the data transmitted
during the protected time into account, the probability
of turning the
ow increased during the rst
interval of T so that the average amount of data transmitted
during T 0 +T is equal to that carried by a competing
NA denote the average rate of the non-
adaptive
ow during the protected time and r 0
TCP the
average rate a TCP
ow would have achieved during the
same time. For
the adjusted ratio p 0 can be calculated as
Again, for 0  p 0  1 we use p 0 as the probability
for the random experiment. If the
ow is turned o, the
application may resume sending after it has been
a least T seconds, starting again with the initialization
step. 3 If the
ow is not turned o, then the
ow will
stay on for at least T more seconds, provided that the
congestion situation of the network does not get worse.
Note that it is now possible that p 0  0 if the non-
adaptable
ow transmits more data during T 0 than a TCP
ow would carry during Obviously, in this case
cannot be used as a probability for the random exper-
iment. Instead, it is necessary to turn the
ow o and to
increase T , so that p
Through the above mechanism the excess data transmitted
during the protected time T 0 is distributed over a
time span of T . At time T 0 , r 0
but in contrast to r 0
to be updated after T 0 .
When a random experiment has to be conducted, it is
necessary to calculate not only p 0 but also the corresponding
p. Each is included in their respective set P 0 and P .
As long as PCC is in the rst T slot and the protected
time has to be accounted for, the values in P 0 are used
to calculate the eective rate and thus the on-probability.
Later on, the set P is used.
It may be considered problematic to let a
ow send at
its full rate for T 0 as this violates the idea of exploring the
available bandwidth as is done, e.g., by TCP slow-start.
However, requirements level of statistical multi-
plexing) and (no synchronization at startup) prevent
3 T can be adjusted by some random oset to prevent synchronization
in case several
ows with the same value for T were forced
to cease sending simultaneously due to heavy congestion.
this causing excessive congestion. In addition, the value of
usually decrease the more congested the network
is, since the actual measurement of the loss event rate
makes up most of the time interval T 0 . Loss events become
more frequent as congestion increases and therefore
the estimate of the network conditions converges faster
to the real value. While r TCP is determined, the receiver
also calculates the average rate of the non-adaptable
ow
r NA . 4 Summing up, three important values are determined
during initialization: r TCP , r NA , and T 0 .
A nite state machine of a PCC receiver is depicted in

Figure

2.
timeout
INIT
set
timer
OFF
T' over and p'<x/
set timer
over
and
p'>=x/
ON
p'>=x p>=x
p<x/
set
timer
timeout
set
timer
p'<x/
First T
Fig. 2. Finite State Machine of a PCC Receiver
The runtime of the timer used in this state machine is
always T .
F. FEC
Since applications generating non-adaptable
ows frequently
have to obey real-time constraints, they benet
from forward error correction to compensate for packet
loss. However, packet loss typically signals congestion.
Therefore it has long been considered unacceptable to
compensate for congestion-based packet loss by increasing
the data rate of a
ow with redundant information for
forward error correction.
PCC supports the use of forward error correction in a
straightforward fashion: When an application decides to
employ forward error correction, the new r NA is simply
set to the rate of the
ow including the forward correction
information. From the perspective of PCC this is equivalent
to an application increasing its sending rate and thus
needs no special treatment. Increasing r NA results in an
4 In our implementation, we use an exponentially weighted moving
average of past PCC rates, but as noted in requirement R3, other
options are possible.
appropriate decrease of p and is therefore fair towards
competing
ows.
G. Example of PCC Operation
To provide a better understanding of the behavior of
PCC, let us demonstrate how PCC operates by means of
an example. As depicted in Figure 3, the sender starts
transmitting at the rate determined by the application.
After seconds the receiver arrives at an initial
estimate of r
Furthermore, let us assume that the application developer
decided that seconds is a good value for the given
application. Now p can be calculated as:
s
100 KBit
s
The value of p is included in the set P and p 0 is calculated
since we are in the rst T interval and have to make
up for the data transmitted during the protected time.
10s  (100 KBit
s
s
50s  100 KBit
s
rate
time
r TCP
Fig. 3. Example of PCC Operation
Now a random number is drawn from the interval (0; 1],
deciding whether the
ow will stay on or be turned o.
Given a high level of statistical multiplexing, this will
result in roughly 1 out of 4 PCC
ows being turned o,
with the aggregation of the remaining PCC
ows using a
fair, TCP-friendly share of the bandwidth.
Let us assume that the random number drawn is
smaller than p 0 and that the
ow will stay in the on-
state. As depicted in Figure 3, at some later point in
time the bandwidth required by the application increases
to r 200KBit=s. A new value for p is then calculated
as follows:
s
200 KBit
s  0:8
This value for p is saved to the set P for later use. The
adjusted probability p 0 has to be calculated based on the
past value of p 0 .
s
200 KBit
s
0:76
10s  (100 KBit
s
s
50s  200 KBit
s
0:76
Let the random number drawn for this decision be below
0:5 so that the
ow remains on. A few seconds after
this decision the rate a TCP
ow would have under
the same conditions drops to r Consequently
new values for p and p 0 are calculated:
s
200 KBit
s
0:8  0:5
s
200 KBit
s
0:76  0:5
10s  (100 KBit
s
50s  200 KBit
s
0:76  0:5
Again the value p is stored in P while the random number
drawn is below p 0 . At
rst, the data transmitted during the protected time need
no longer be accounted for since PCC has made up for
that during the past T interval. Therefore p 0 is no longer
calculated. Second, the rst value within P times out and
is removed from the set. If the network situation has not
changed this will result in the following new value for p:
s
200 KBit
s  0:5  0:5
This time let the random number be larger than p. As a
result the
ow is suspended for the next T interval before
it may start again with a protected time. It should be
noted that this example was designed to demonstrate how
PCC works. In reality, a situation where the rate of the
non-adaptable
ow is ve times the TCP-friendly rate
indicates that the network resources are not sucient for
this application.
Extensions
While the current version of PCC works as described
above, there are a number of options and possible improvements
that we have investigated. In the following
we outline two modications that have not yet been incorporated
into PCC.
H.1 Probe While O
ows on average may receive less bandwidth than
competing TCP
ows, since a
ow that has been turned
may resume only after a time of T , even if network conditions
improve beforehand. This degrades PCC's perfor-
mance, particularly if T is large. In order to improve
average PCC throughput,
ows that are o could monitor
network congestion by sending probe packets at a very
low data rate from the sender to the receiver. The data
rate r OFF produced by the probe packets needs to be
taken into account in the Equations 1 and 3 by including
an additional factor (1 p)  r OFF  T .
If the loss rate and the round-trip time of the probe
packets signal that r TCP has improved, a
ow that has
been turned o may be turned on again immediately,
without waiting for the remainder of the T to pass, and
without performing an initialization step. This may be
done only if, under the new network conditions, all experiments
within the last T interval had been successful.
If the congestion situation worsens later on, it must be
checked whether any of the experiments during the last
T interval had failed. If this is the case, the
ow must be
turned Only after the last entry in set P has
timed out may the
ow resume normal operation. For
Probe While O to work correctly, it is of major importance
that the estimate of the network parameters work
independent of the data rate PCC is sending at.
The current version of PCC does not include Probe
While O, since it could lead to frequent changes between
the states \on" and \o", which is likely to be
distracting to the user of the application. Furthermore,
probe packets waste bandwidth. Probe While O may be
included in a later version of PCC as an option for the
application. The mechanism can be improved by including
a threshold, so that the
ow is turned on again only if
the available bandwidth increases signicantly. With this
improvement, the number of state changes is reduced to
improve stability.
H.2 Probe Before On
In PCC, a
ow is turned on upon initialization. This
has two drawbacks. First, it violates the idea of exploring
the available bandwidth as in TCP slowstart. Second, the
ow may be turned immediately after the initialization
is complete, so that the user perceives only a brief moment
where the application seems to work, before it is turned
o. An alternative would be to send probe packets at an
increasing rate before deciding whether or not to turn on
the
ow. Only after the parameters have been estimated
and the random experiment has succeeded will real data
for the
ow be transmitted. The drawback to this method
is that bandwidth is wasted by probe packets and that the
initial startup of a
ow is delayed.
H.3 Loss Rate Monitoring
ows do not take into account the impact of their
actions on the network conditions. Assume that the random
experiments of a number of PCC
ows fail due to
increased congestion, but that the congestion was largely
caused by these PCC
ows. Then too many
ows will be
suspended since it is impossible to include the expected
improvement in the network conditions in the calculation
of the on-probability. Similarly, when the bandwidth consumed
by PCC
ows during the protected time is a sig-
nicant fraction of the bottleneck link bandwidth, severe
congestion may be inevitable. Even after the protected
time, the changes in network conditions caused by PCC
ows that consume a large fraction of the bandwidth are
undesirable.
For these reasons it is vital that the condition of a sufcient
level of statistical multiplexing holds and that the
ows do not consume too large a fraction of the
bandwidth of the bottleneck link. By continuously monitoring
the packet loss rate (e.g., through probe packets)
and correlating it with the on- and o-times of the PCC
ow, it is possible to estimate the impact of the
ow on
the network conditions. If the PCC
ow causes very large
variations in the loss rate, the
ow should be suspended
permanently. With this extension it is possible to use
PCC in environments where it is unclear whether the
condition of a sucient level of statistical multiplexing
is fullled.
V. Simulations
In this section, we use network simulations to analyze
PCC's behavior. Simulations are based on the dumbbell
topology (Figure since it is sucient to analyze
PCC fairness and the results can be compared to those of
other congestion control protocols evaluated with it. For
the same reason, simulations were carried out with the
ns-2 network simulator [10], commonly used to evaluate
such protocols. Drop-tail queuing (with a buer size of 50
packets) was employed at the routers. We used the standard
TCP implementation of ns for the
ows competing
with PCC.
Receivers
Senders
Bottleneck Link
Fig. 4. Simulation Topology
A. TCP-Friendliness
A typical example of PCC behavior is shown in Figure
5. For this simulation, 32 PCC
ows and
ows were run over the same bottleneck link with
capacity. At an application sending rate of
750KBit/s, the PCC
ows should ideally be in the on-state
for two thirds of the time. In this example, T was
set to 60s, leading to an expected average on-time of 120s.
The graph depicts the throughput of one sample TCP
ow
and one sample PCC
ow, as well as the average through-put
of all
ows. The starting time of the PCC
ows is spread out over the rst 50s to avoid synchronization
20060010000 100 200 300 400 500 600 700 800 900
Throughput
Time [s]
Fig. 5. PCC and TCP throughput
The TCP rate shows the usual oscillations around the
fair rate of 500KBit/s. PCC's behavior is nearly perfect,
with an average rate that closely matches the fair rate
and an on-o ratio of two to one. Naturally, not all of the
ows achieve exactly this ratio; some stay on for
more, some for less time.
B. Intra-Protocol Fairness
Usually, it is desirable to evenly distribute the necessary
o-times over all PCC
ows instead of severely penalizing
only few. To examine PCC's intra-protocol fairness, a
simulation setup similar to the previous one was used, yet
the number of concurrent PCC and TCP
ows varied between
2 and 128. The probability density function of the
throughput distribution from these simulations is shown
in

Figure

6. As expected, the throughput range is larger
for PCC. The coecient of variation (standard deviation
over mean) for PCC throughput is 15% compared to a
TCP coecient of variation of only about 3%.
This results from the time frame for changes in the
states of the PCC
ows being 60s instead of a few RTTs
for TCP
ows. There is a direct tradeo between the
parameter T and the intra-protocol fairness. Longer on-
times, achieved by a larger T , result at the expense of the
ows that are suspended for a longer time, thus decreasing
intra-protocol fairness. Taken to the extreme, for very
Average Throughput (KBit/s)
Fig. 6. Distribution of Flow Throughput
large T
ows may stay on for the whole duration of the
session or are not permitted at all, leading to a type of
admission control scheme.
C. Responsiveness
In addition to inter- and intra-protocol fairness, su-
cient responsiveness of a
ow to changes in the network
conditions is important to ensure acceptable protocol be-
havior. TCP adapts almost immediately to an increase in
congestion (manifest in the form of packet loss). Through
the continuous evaluation at timescales of less than T , as
described in Section IV-C, PCC can react nearly as fast
as TCP to increased congestion, however, it will react to
improved network conditions on a timescale of T . Figure
7 depicts the average throughput of
ows,
again with parameter T set to 60s, and
ows. A
rather dynamic network environment was chosen where
the loss rate increases abruptly from 2.5% to 5% from
time 200s to 300s and from time 400s to 420s.100300500700100 150 200 250 300 350 400 450 500
Throughput
Time [s]
avg. TCP
avg. PCC
Fig. 7. Loss Bursts
When the loss rate changes at time 200s, PCC does
not adapt as fast as TCP but still achieves an overall average
rate that is quite close to the TCP rate after only
a few seconds. seconds later we can see a little spike
in the average PCC rate, resulting from the PCC
ows
that reenter the protected time to probe for bandwidth
once their o-time is over. Since the loss rate is still high,
the average PCC rate settles at the appropriate TCP-friendly
rate shortly thereafter. As soon as the loss rate
is reduced to its original value, the probability that sus-
pended
ows reentering the protected time will immediately
be suspended again (and the probability that the
random experiment of
ows in the on-state will fail) de-
creases. Thus, after time 300s, the random experiments of
more and more
ows succeed until about 50 seconds later
the TCP-friendly rate is reached again. Although PCC
reacts more slowly than TCP, the average throughput of
TCP and PCC up to time 350s is very similar. In contrast
to long high-loss periods, short loss spikes hurt PCC
performance much more than TCP performance. When
the loss rate increases again at time 400s, suspended PCC
ows will stay in the o-state for at least 60s, while the
actual congestion persists for only 20s. From the time the
congestion ends until the time the PCC
ows are allowed
to reenter the protected time, TCP throughput is considerably
higher than PCC throughput. However, we can
also see from the graph that during periods of congestion
PCC throughput does not quite drop to the level of TCP
throughput but remains slightly higher. In the following
we will analyze this eect in more detail.
D. PCC Throughput for Dierent Application Sending
Rates
Ideally, no PCC
ows would be suspended as long as the
PCC application sending rate is below the TCP-friendly
rate. For higher application sending rates the average
PCC rate should remain at exactly the fair rate through
the use of the random experiments. From Figure 8 we
take it that an average PCC rate of exactly the fair rate
is not reached when the application sending rate equals
the fair rate but for an application sending rate that is
about 25% higher. The latter eect can be explained
by PCC's susceptibility to dynamic network conditions.
TCP's typical sawtooth-like sending rate results in variations
in the network conditions which unduly cause suspension
of PCC
ows. When we compare the average
PCC throughput to TCP throughput for high PCC application
sending rates, we nd that PCC throughput
and thus PCC's aggressiveness continues to increase with
the application sending rate once the fair rate has been
reached.
The eect of increased aggressiveness at higher application
sending rates can be attributed to the TCP model
used by PCC. As stated in [9], the TCP model is based on
the so-called loss event rate. A loss event occurs when one
or more packets are lost within a round-trip time, and the
loss event rate is consequently dened as the ratio of loss
events to the number of packets sent. The denominator of
the loss-event rate increases as more and more packets are
sent during a round-trip time due to a higher application
Average
Rate
[%
of
Fair
PCC Application Sendrate [% of Fair Rate]
Model
Fig. 8. Comparison with Estimated TCP-Friendly Rate
sending rate. At the same time, the number of loss events
does not increase to the same extent since more and more
lost packets are aggregated to a single loss event. An in-depth
analysis of this eect can be found in [11]. When
relating the estimated TCP-friendly rate at dierent application
sending rates to the average PCC rate achieved
in these simulations, it becomes obvious that PCC's aggressiveness
is not caused by PCC's congestion control
mechanism but by the dependence of the TCP model on
the measurement of the loss event rate at sending rates
close to the actual TCP rate (to ensure that for TCP and
the TCP model the lost packets that constitute a loss
event are the same). In addition to PCC's susceptibility
to variations in the network conditions, the dierence between
the TCP-friendly rate and the average PCC rate is
also caused by taking into account only the rate estimates
of
ows in the on-state.
E. PCC Fairness for Dierent Combinations of Flows

Figure

9 shows the average throughput achieved by
PCC for dierent combinations of PCC and TCP
ows
when the fair rate is 500KBit/s and the application sending
rate is 750KBit/s. Generally, PCC throughput increases
with the number of TCP
ows, since the higher
the level of statistical multiplexing, the lower the variations
in the network conditions that degrade PCC per-
formance. This eect is more pronounced, the lower the
number PCC
ows is.
For a more detailed analysis of PCC and further net-work
simulations we refer the reader to [12].
VI. Conclusions
In this paper we presented a congestion control scheme
for non-adaptable
ows. This type of
ow carries data
at a rate determined by the application. It cannot be
adapted to the level of congestion in the network in any
way other than by suspending the entire
ow. Existing41664
Number of PCC flows2832Number of TCP flows250750
Throughput [KBit/s]
Fig. 9. Average PCC Throughput for Dierent Numbers of Flows
congestion control approaches therefore are not viable for
non-adaptable
ows.
We proposed to perform congestion control for such
ows by suspending individual
ows in such a way that
the aggregation of all non-adaptable
ows on a given link
behaves in a TCP-friendly manner. The decision about
suspending a given
ow is made by means of random experiments

In a series of simulations we have shown that PCC
displays a TCP-friendly behavior under a wide range of
network conditions. We identied the conditions under
which PCC throughput does not correspond to the TCP-friendly
rate. To some extent, these eects on the average
PCC sending rate cancel each other out. Nevertheless, the
may degrade PCC performance.
We intend to include Probe While O as an optional
element in PCC, which would improve PCC's behavior in
highly dynamic network environments. Furthermore, we
are currently investigating a method to perform a more
accurate estimate of the fair TCP rate if the loss event
rate is measured at a sending rate that diers considerably
from the TCP-friendly rate. Finally, we plan to evaluate
if and how PCC can complement congestion control for
multicast transmissions.



--R










John Hei- demann


--TR
Promoting the use of end-to-end congestion control in the Internet
Modeling TCP Reno performance
pgmcc
Equation-based congestion control for unicast applications
FLID-DL
Advances in Network Simulation
Issues in Model-Based Flow Control
TCP-friendliness;non-adaptable flows;congestion control