Equation-Based Congestion Control for Unicast
Applications
Sally Floyd, Mark
Handley
AT&T Center for Internet
Research at ICSI (ACIRI)
Jitendra Padhye
University of Massachusetts at
Amherst
J¨org Widmer
International Computer
Science Institute (ICSI)
ABSTRACT
This paper proposes a mechanism for equation-based congestion
control for unicast traffic. Most best-effort traffic in the current
Internet is well-served by the dominant transport protocol, TCP.
However, traffic such as best-effort unicast streaming multimedia
could find use for a TCP-friendly congestion control mechanism
that refrains from reducing the sending rate in half in response to
a single packet drop. With our mechanism, the sender explicitly
adjusts its sending rate as a function of the measured rate of loss
events, where a loss event consists of one or more packets dropped
within a single round-trip time. We use both simulations and ex-
periments over the Internet to explore performance.
We consider equation-based congestion control a promising avenue
of development for congestion control of multicast traffic, and so
an additional motivation for this work is to lay a sound basis for the
further development of multicast congestion control.
1. INTRODUCTION
TCP is the dominant transport protocol in the Internet, and the cur-
rent stability of the Internet depends on its end-to-end congestion
control, which uses an Additive Increase Multiplicative Decrease
(AIMD) algorithm. For TCP, the ‘sending rate’ is controlled by
a congestion window which is halved for every window of data
containing a packet drop, and increased by roughly one packet per
window of data otherwise.
End-to-end congestion control of best-effort traffic is required to
avoid the congestion collapse of the global Internet [3]. While
TCP congestion control is appropriate for applications such as bulk
data transfer, some real-time applications (that is, where the data is
being played out in real-time) find halving the sending rate in re-
sponse to a single congestion indication to be unnecessarily severe,
This material is based upon work supported by AT&T, and by
the National Science Foundationunder grants NCR-9508274, ANI-
9805185 and CDA-9502639. Any opinions, findings, and conclu-
sions or recommendations expressed in this material are those of
the author(s) and do not necessarily reflect the views of AT&T or
the National Science Foundation.
May 2000. To appear in SIGCOMM 2000.
Copyright by ACM, Inc. Permission to copy and distribute this document is
hereby granted provided that this notice is retained on all copies, that copies
are not altered, and that ACM is credited when the material is used to form
other copyright policies.
as it can noticeably reduce the user-perceived quality [22]. TCP’s
abrupt changes in the sending rate have been a significant impedi-
ment to the deployment of TCP’s end-to-end congestion control by
emerging applications such as streaming multimedia. In our judge-
ment, equation-based congestion control is a viable mechanism to
provide relatively smooth congestion control for such traffic.
Equation-basedcongestion control was proposed informally in [12].
Whereas AIMD congestion control backs off in response to a sin-
gle congestion indication, equation-based congestion control uses
a control equation that explicitly gives the maximum acceptable
sending rate as a function of the recent loss event rate. The sender
adapts its sending rate, guided by this control equation, in response
to feedback from the receiver. For traffic that competes in the
best-effort Internet with TCP, the appropriate control equation for
equation-based congestion control is the TCP response function
characterizing the steady-state sending rate of TCP as a function
of the round-trip time and steady-state loss event rate.
Although there has been significant previous research on equation
based and other congestion control mechanisms [8, 18, 17, 22,
15, 21], we are still rather far from having deployable conges-
tion control mechanisms for best-effort streaming multimedia. Sec-
tion 3 presents the TCP-Friendly Rate Control (TFRC)proposal for
equation-based congestion control for unicast traffic. In Section 5
we provide a comparative discussion of TFRC and previously pro-
posed mechanisms. The benefit of TFRC, relative to TCP, is a more
smoothly-changing sending rate. The corresponding cost of TFRC
is a more moderate response to transient changes in congestion,
including a slower response to a sudden increase in the available
bandwidth.
One of our goals in this paper is to present a proposal for equa-
tion based congestion control that lays the foundation for the near-
term experimental deployment of congestion control for unicast
streaming multimedia. Section 4 presents results from extensive
simulations and experiments with the TFRC protocol, showing that
equation-based congestion control using the TCP response func-
tion competes fairly with TCP. Both the simulator code and the
real-world implementation are publicly available. We believe that
TFRC and related forms of equation-based congestion control can
play a significant role in the Internet.
For most unicast flows that want to transfer data reliably and as
quickly as possible, the best choice is simply to use TCP directly.
However, equation-based congestion control is more appropriate
for applications that need to maintain a slowly-changing sending
rate, while still being responsive to network congestion over longer
1
time periods (seconds, as opposed to fractions of a second). It is
our belief that TFRC is sufficiently mature for a wider experimental
deployment, testing, and evaluation.
A second goal of this work is to contribute to the development
and evaluation of equation-based congestion control. We address
a number of key concerns in the design of equation-based conges-
tion control that have not been sufficiently addressed in previous
research, including responsiveness to persistent congestion, avoid-
ance of unnecessary oscillations, avoidance of the introduction of
unnecessary noise, and robustness over a wide range of timescales.
The algorithm for calculating the loss event rate is a key design is-
sue in equation-based congestion control, determining the tradeoffs
between responsiveness to changes in congestion and the avoidance
of oscillations or unnecessarily abrupt shifts in the sending rate.
Section 3 addresses these tradeoffs and describes the fundamental
components of the TFRC algorithms that reconcile them.
Equation-based congestion control for multicast traffic has been an
active area of research for several years [20]. A third goal of this
work is to build a solid basis for the further development of conges-
tion control for multicast traffic. In a large multicast group, there
will usually be at least one receiver that has experienced a recent
packet loss. If the congestion control mechanisms require that the
sender reduces its sending rate in response to each loss, as in TCP,
then there is little potential for the construction of scalable multi-
cast congestion control. As we describe in Section 6, many of the
mechanisms in TFRC are directly applicable to multicast conges-
tion control.
2. FOUNDATIONS OF EQUATION-BASED
CONGESTION CONTROL
The basic decision in designing equation-based congestion control
is to choose the underlying control equation. An application us-
ing congestion control that was significantly more aggressive than
TCP could cause starvation for TCP traffic if both types of traffic
were competing in a congested FIFO queue [3]. From [2], a TCP-
compatible flow is defined as a flow that, in steady-state, uses no
more bandwidth than a conformant TCP running under comparable
conditions. For best-effort traffic competing with TCP in the cur-
rent Internet, in order to be TCP-compatible, the correct choice for
the control equation is the TCP response function describing the
steady-state sending rate of TCP.
From [14], one formulation of the TCP response function is the
following:
!#"$
(1)
This gives an upper bound on the sending rate
in bytes/sec, as a
function of the packet size
, round-trip time
, steady-state loss
event rate
, and the TCP retransmit timeout value
.
An application wishing to send less than the TCP-compatible send-
ing rate (e.g., because of limited demand) would still be character-
ized as TCP-compatible. However, if a significantly less aggressive
response function were used, then the less aggressive traffic could
encounter starvation when competing with TCP traffic in a FIFO
queue. In practice, when two types of traffic compete in a FIFO
queue, acceptable performance for both types of traffic only results
if the two traffic types have similar response functions.
Some classes of traffic might not compete with TCP in a FIFO
queue, but could instead be isolated from TCP traffic by some
method (e.g., with per-flow scheduling, or in a separate differenti-
ated services class from TCP traffic). In such traffic classes, appli-
cations using equation-based congestion control would not neces-
sarily be restricted to the TCP response function for the underlying
control equation. Issues about the merits or shortcomings of vari-
ous control equations for equation-based congestion control are an
active research area that we do not address further in this paper.
2.1 Viable congestion control does not require
TCP
This paper proposes deployment of a congestion control algorithm
that does not halve its sending rate in response to a single conges-
tion indication. Given that the stability of the current Internet rests
on AIMD congestion control mechanisms in general, and on TCP
in particular, a proposal for non-AIMD congestion control requires
justification in terms of its suitability for the global Internet. We
discuss two separate justifications, one practical and the other the-
oretical.
A practical justification is that the principle threat to the stability of
end-to-end congestion control in the Internet comes not from flows
using alternate forms of TCP compatible congestion control, but
from flows that do not use any end-to-end congestion control at all.
For much current traffic, the alternatives have been between TCP,
with its reduction of the sending rate in half in response to a sin-
gle packet drop, and no congestion control at all. We believe that
the development of congestion control mechanisms with smoother
changes in the sending rate will increase incentives for applications
to use end-to-end congestion control, thus contributing to the over-
all stability of the Internet.
A more theoretical justification is that preserving the stability of
the Internet does not require that flows reduce their sending rate
by half in response to a single congestion indication. In particular,
the prevention of congestion collapse simply requires that flows
use some form of end-to-end congestion control to avoid a high
sending rate in the presence of a high packet drop rate. Similarly,
as we will show in this paper, preserving some form of “fairness”
against competing TCP traffic also does not require such a drastic
reaction to a single congestion indication.
For flows desiring smoother changes in the sending rate, alterna-
tives to TCP include AIMD congestion control mechanisms that
do not use a decrease-by-half reduction in response to congestion.
In DECbit, which was also based on AIMD, flows reduced their
sending rate to 7/8 of the old value in response to a packet drop
[11]. Similarly, in Van Jacobson’s 1992 revision of his 1988 paper
on Congestion Avoidance and Control [9], the main justification
for a decrease term of 1/2 instead of 7/8, in Appendix D of the
revised version of the paper, is that the performance penalty for a
decrease term of 1/2 is small. A relative evaluation of AIMD and
equation-based congestion control in [4] explores the benefits of
equation-based congestion control.
3. THE TCP-FRIENDLY RATE CONTROL
(TFRC) PROTOCOL
The primary goal of equation-based congestion control is not to ag-
gressively find and use available bandwidth, but to maintain a rel-
atively steady sending rate while still being responsive to conges-
tion. To accomplish this, equation-based congestion control makes
2
the tradeoff of refraining from aggressively seeking out available
bandwidth
%
in the manner of TCP. Thus, several of the design prin-
ciples of equation-based congestion control can be seen in contrast
to the behavior of TCP.
&
Do not aggressively seek out available bandwidth. That is,
increase the sending rate slowly in response to a decrease in
the loss event rate.
&
Do not halve the sending rate in response to a single loss
event. However, do halve the sending rate in response to
several successive loss events.
Additional design goals for equation-based congestion control for
unicast traffic include:
&
The receiver should report feedback to the sender at least
once per round-trip time if it has received packets in that in-
terval.
&
If the sender has not received feedback after several round-
trip times, then the sender should reduce its sending rate, and
ultimately stop sending altogether.
3.1 Protocol Overview
Applying the TCP response function (Equation (1)) as the control
equation for congestion control requires that the parameters
and
are determined. The loss event rate,
, must be calculated at the
receiver, while the round-trip time,
, could be measured at either
the sender or the receiver. (The other two values needed by the TCP
response equation are the flow’s packet size,
, and the retransmit
timeout value,
, which can be estimated from
.) The receiver
sends either the parameter
or the calculated value of the allowed
sending rate,
, back to the sender. The sender then increases or
decreases its transmission rate based on its calculation of
.
For multicast, it makes sense for the receiver to determine the rel-
evant parameters and calculate the allowed sending rate. However,
for unicast the functionality could be split in a number of ways. In
our proposal, the receiver only calculates
, and feeds this back to
the sender.
3.1.1 Sender functionality
In order to use the control equation, the sender determines the val-
ues for the round-trip time
and retransmit timeout value
.
The sender and receiver together use sequence numbers for mea-
suring the round-trip time. Every time the receiver sends feedback,
it echoes the sequence number from the most recent data packet,
along with the time since that packet was received. In this way
the sender measures the round-trip time through the network. The
sender then smoothes the measured round-trip time using an expo-
nentially weighted moving average. This weight determines the re-
sponsiveness of the transmission rate to changes in round-trip time.
The sender could derive the retransmit timeout value
'()
using
the usual TCP algorithm:
+*,
.-
0/$132
where
440/$132
is the variance of RTT and
*,
is the round-trip
time estimate. However, in practice
only critically affects the
allowed sending rate when the packet loss rate is very high. Dif-
ferent TCPs use drastically different clock granularities to calculate
retransmit timeout values, so it is not clear that equation-based con-
gestion control can accurately model a typical TCP. Unlike TCP,
TFRC does not use this value to determine whether it is safe to re-
transmit, and so the consequences of inaccuracy are less serious.
In practice the simple empirical heuristic of
-
works
reasonably well to provide fairness with TCP.
The sender obtains the loss event rate
in feedback messages from
the receiver at least once per round-trip time.
Every time a feedback message is received, the sender calculates a
new value for the allowed sending rate
using the response func-
tion from equation (1). If the actualsending rate
(165798:13;
is less than
, the sender may increase its sending rate. If
16578<13;
is greater
than
, the sender decreases the sending rate to
.
3.1.2 Receiver functionality
The receiver provides feedback to allow the sender to measure the
round-trip time (RTT). The receiver also calculates the loss event
rate
, and feeds this back to the sender. The calculation of the loss
event rate is one of the critical parts of TFRC, and the part that has
been through the largest amount of evaluation and design iteration.
There is a clear trade-off between measuring the loss event rate
over a short period of time and responding rapidly to changes in
the available bandwidth, versus measuring over a longer period of
time and getting a signal that is much less noisy.
The method of calculating the loss event rate has been the subject
of much discussion and testing, and over that process several guide-
lines have emerged:
1. The estimated loss rate should measure the loss event rate
rather than the packet loss rate, where a loss event can con-
sist of several packets lost within a round-trip time. This is
discussed in more detail in Section 3.2.1.
2. The estimated loss eventrate should track relativelysmoothly
in an environment with a stable steady-state loss event rate.
3. The estimated loss event rate should respond strongly to loss
events in several successive round-trip times.
4. The estimated loss eventrate should increase only in response
to a new loss event.
5. Let a loss interval be defined as the number of packets be-
tween loss events. The estimated loss event rate should de-
crease only in response to a new loss interval that is longer
than the previously-calculated average, or a sufficiently-long
interval since the last loss event.
Obvious methods we looked at include the Dynamic History Win-
dow method, the EWMA Loss Interval method, and the Average
Loss Interval method which is the method we chose.
&
The Dynamic History Window method uses a history win-
dow of packets, with the window length determined by the
current transmission rate.
&
The EWMA Loss Interval method uses an exponentially-
weighted moving average of the number of packets between
loss events.
&
The Average Loss Interval method computes a weighted av-
erage of the loss rate over the last
=
loss intervals, with equal
weights on each of the most recent
=?>
"
intervals.
The Dynamic History Window method suffers from the effect that
even with a perfectly periodic loss pattern, loss events entering and
leaving the window cause changes to the measured loss rate, and
hence add unnecessary noise to the loss signal. In particular, the
3
Dynamic History Window method does not satisfy properties (2),
(3), (4), and (5) above. The EWMA Loss Interval performs better
than the Dynamic History Window method. However, it is difficult
to choose an EWMA weight that responds sufficiently promptly to
loss events in several successive round-trip times, and at the same
time does not over-emphasizethe most recent loss interval. The Av-
erage Loss Interval method satisfies properties (1)-(5) above, while
giving equal weights to the most recent loss intervals.
We have compared the performance of the Average Loss Interval
method with the EWMA and Dynamic History Window methods.
In these simulation scenarios we set up the parameters for each
method so that the response to an increase in packet loss is similarly
fast. Under these circumstances it is clear that the Average Loss
Interval method results in smoother throughput [13].
Time now
@
Interval
since most
recent loss
interval 1
A
interval 2
A
interval n
A
weight 1
weight n
weighted
interval 1
weighted
interval 2
weighted
interval n
Sequence
B
Number
Time
@
Packet
Arrival
Packet
lost
Figure 1: Weighted intervals between loss used to calculate loss
probability.
The use of a weighted average by theAverage Loss Interval method
reduces sudden changes in the calculated rate that could result from
unrepresentative loss intervals leaving the set of loss intervals used
to calculate the loss rate. The average loss interval
C
EDF'G HEI
is calcu-
lated as a weighted average of the last
=
intervals as follows:
C
D9F'G H#I
KJ
HLNM
FPO
L
L
J
H
LNM
F
O
LRQ
for weights
O
L
:
O
L
Q
TSVUWS
=>
"
Q
and
O
L
X
U?X
=>
"
=?>
"Y
Q
=?>
"[ZVUWS
=]\
For
=
_^
, this gives weights of 1, 1, 1, 1, 0.8, 0.6, 0.4, and 0.2 for
O
F
through
O
, respectively.
The sensitivity to noise of the calculated loss rate depends on the
value of
=
. In practice a value of
=
`^
, with the most recent
four samples equally weighted, appears to be a lower bound that
still achieves a reasonable balance between resilience to noise and
responding quickly to real changes in network conditions. Section
4.4 describes experiments that validate the value of
=
a^
. How-
ever, we have not carefully investigated alternatives for the relative
values of the weights.
Any method for calculating the loss event rate over a number of
loss intervals requires a mechanism to deal with the interval since
the most recent loss event, as this interval is not necessarily a re-
flection of the underlying loss event rate. Let
L
be the number of
packets in the
U
-th most recent loss interval, and let the most re-
cent interval
3b
be defined as the interval containing the packets
that have arrived since the last loss. When a loss occurs, the loss
interval that has been
:b
now becomes
F
, all of the following loss
intervals are correspondingly shifted down one, and the new loss
interval
:b
is empty. As
3b
is not terminated by a loss, it is dif-
ferent from the other loss intervals. It is important to ignore
b
in
calculating the average loss interval unless
:b
is large enough that
including it would increase the average. This allows the calculated
loss interval to track smoothly in an environment with a stable loss
event rate.
To determine whether to include
3b
, the interval since the most re-
cent loss, the Average Loss Interval method also calculates
C
ED
b
G Hdc?FeI
:
C
#D
b
G HfcFeI
J
HdcF
LM
b
O
Lg
F
L
J
H
LM
FPO
L
\
The final average loss interval
C
is
hji<k
C
D9F'G H#I
Q
C
D
b
G HfcFeI
Q
and the
reported loss event rate is
>(C
.
Because the Average Loss Interval method averages over a number
of loss intervals, rather than over a number of packet arrivals, this
method with the given fixed weights responds reasonably rapidly
to a sudden increase in congestion, but is slow to respond to a sud-
den decrease in the loss rate represented by a large interval since
the last loss event. To allow a more timely response to a sustained
decrease in congestion, we deploy history discounting with the Av-
erage Loss Interval method, to allow the TFRC receiver to adaptthe
weights in the weighted average in the special case of a particularly
long interval since the last dropped packet, to smoothly discount
the weights given to older loss intervals. This allows a more timely
response to a sudden absence in congestion. History discounting is
described in detail in [5], and is only invoked by TFRC after the
most recent loss interval
3b
is greater than twice the average loss
interval. We have not yet explored the possibility of allowing more
general adaptive weights in the weighted average.
0
50
100
150
200
250
300
3 4 5 6 7 8 9 10 11 12 13 14 15 16
Loss Interval
l
Time (s)
current loss interval (s0)
estimated loss interval
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
3 4 5 6 7 8 9 10 11 12 13 14 15 16
Loss Rate
Time (s)
estimated loss rate
square root of estimated loss rate
0
100
200
300
400
3 4 5 6 7 8 9 10 11 12 13 14 15 16
TX Rate (KBytes/s)
Time (s)
Transmission Rate
Figure 2: Illustration of the Average Loss Interval method with
idealized periodic loss.
Figure 2 shows a simulation using the full Average Loss Interval
method for calculating the loss event rate at the receiver. The link
loss rate is 1% before time 6, then 10% until time 9, and finally
4
0.5% until the end of the run. Because the losses in this simulation
are perfectly periodic, the scenario is not realistic; it was chosen
to illustrate the underlying properties of the Average Loss Interval
method.
For the top graph, the solid line shows the number of packets in
the most recent loss interval, as calculated by the receiver once
per round-trip time before sending a status report. The smoother
dashed line shows the receiver’s estimate of the average loss in-
terval. The middle graph shows the receiver’s estimated loss event
rate
, which is simply the inverse of the average loss interval, along
with
m
. The bottom graph shows the sender’s transmission rate
which is calculated from
.
Several things are noticeable from these graphs. Before
+n
, the
loss rate is constant and the Average Loss Interval method gives
a completely stable measure of the loss rate. When the loss rate
increases, the transmission rate is rapidly reduced. Finally, when
the loss rate decreases, the transmission rate increases in a smooth
manner, with no step increases even when older (10 packet) loss
intervals are excluded from the history.
3.1.3 Improving stability
One of the goals of the TFRC protocol is to avoid the character-
istic oscillations in the sending rate that result from TCP’s AIMD
congestion control mechanisms. In controlling oscillations, a key
issue in the TFRC protocol concerns the TCP response function’s
specification of the allowed sending rate as inversely proportional
to the measured RTT. A relatively prompt response to changes in
the measured round-trip time is helpful to prevent flows from over-
shooting the available bandwidth after an uncongested period. On
the other hand, an over-prompt response to changes in the mea-
sured round-trip time can result in unnecessary oscillations. The
response to changes in round-trip times is of particular concern in
environments with Drop-Tail queue management and small-scale
statistical multiplexing, where the round-trip time can vary signifi-
cantly as a function of changes in a single flow’s sending rate.
2
8
32
64
buffer size
0
20
40
60
80
100
120
140
160
180
time (s)
0
100
200
300
Send Rate
(KByte/s)
Figure 3: Oscillations of a TFRC flow over Dummynet, EWMA
weight 0.05 for calculating the RTT.
2
8
32
64
buffer size
0
20
40
60
80
100
120
140
160
180
time (s)
0
100
200
300
Send Rate
(KByte/s)
Figure 4: TFRC flow over Dummynet: oscillations prevented
If the value of the EWMA weight for calculating the average RTT is
set to a small value such as 0.1 (meaning that 10% of the weight is
on the most recent RTT sample) then TFRC does not react strongly
to increases in RTT. In this case, we tend to see oscillations when
a small number of TFRC flows share a high-bandwidth link with
Drop-Tail queuing; the TFRC flows overshoot the link bandwidth
and then experience loss over several RTTs. The result is that they
backoff together by a significant amount, and then all start to in-
crease their rate together. This is shown for a single flow in Figure
3 as we increase the buffer size in Dummynet [19]. Although not
disastrous, the resulting oscillation is undesirable for applications
and can reduce network utilization. This is similar in some respects
to the global oscillation of TCP congestion control cycles.
If the EWMA weight is set to a high value such as 0.5, then TFRC
reduces its sending rate strongly in response to an increase in RTT,
giving a delay-based congestion avoidance behavior. However, be-
cause the sender’s response is delayed and the sending rate is di-
rectly proportional to
>
, it is possible for short-term oscillations
to occur, particularly with small-scale statistical multiplexing at
Drop-Tail queues. While undesirable, the oscillations from large
EWMA weights tend to be less of a problem than the oscillations
with smaller values of the EWMA weight.
What we desire is a middle ground, where we gain some short-
term delay-based congestion avoidance, but in a form that has less
gain than simply making the rate inversely proportional to the most
recent RTT measurement. To accomplish this, we use a small value
for the EWMA weight in calculating the average round-trip time
in Equation (1), and apply the increase or decrease functions as
before, but then set the interpacket-spacing as follows:
L
H
79o2
c
165pqo7
r
m
b
s
(2)
where
b
is the most recent RTT sample, and
s
is the average
of the square-roots of the RTTs, calculated using an exponentially
weighted moving average with the same time constant we use to
calculate the mean RTT. (The use of the square-root function in
Equation (2) is not necessarily optimal; it is likely that other sub-
linear functions would serve as well.) With this modification of
the interpacket-spacing, we gain the benefits of short-term delay-
based congestion avoidance, but with a lower feedback loop gain so
that oscillations in RTT damp themselves out, as shown in Figure
4. The experiments in Figure 3 did not use this adjustment to the
interpacket spacing, unlike the experiments in Figure 4.
3.1.4 Slowstart
TFRC’s initial rate-based slow-start procedure should be similar to
the window-based slow-start procedure followed by TCP where the
sender roughly doubles its sending rate each round-trip time. How-
ever, TCP’s ACK-clock mechanism provides a limit on the over-
shoot during slow start. No more that two outgoing packets can be
generated for each acknowledged data packet, so TCP cannot send
at more than twice the bottleneck link bandwidth.
A rate-based protocol does not have this natural self-limiting prop-
erty, and so a slow-start algorithm that doubles its sending rate ev-
ery measured RTT can overshoot the bottleneck link bandwidth by
significantly more than a factor of two. A simple mechanism to
limit this overshoot is for the receiver to feed back the rate that
packets arrived at the receiver during the last measured RTT. If loss
occurs, slowstart is terminated, but if loss doesn’t occur the sender
sets its rate to:
(1q5798:13;
G
LNg
F
_t
U
=vu
"
(165798:13;
G
L
Q
"
02ow5o
L
/xowy
G
Lez
5
