762
IEEE COMMUNICATIONS LETTERS, VOL. 9, NO. 8, AUGUST 2005
FAST TCP: Fairness and Queuing Issues
Liansheng Tan, Cao Yuan, and Moshe Zukerman, Senior Member, IEEE
Abstract— This letter considers problems of unfairness and
excessive variations of the router queue associated with FAST
TCP operations due to inaccurate estimation of the round-trip
propagation delay. Using a simple example, we explain unfairness
in FAST TCP caused by this inaccurate estimation. We also
present analytical and simulation performance studies and show
that improving this estimation by giving the first packet in every
flow priority can improve fairness and reduce queuing variations.
Index Terms— FAST TCP, Diffserv, priority queuing, roundtrip time (RTT), congestion control.
Fig. 1.
The dumbbell topology used in the simulations.
Fig. 2.
The active periods of the four flows.
I. I NTRODUCTION
F
AST TCP [3], [4], [5] is a new TCP congestion control
algorithm for high-speed long-distance networks; it aims
to rapidly stabilize networks into steady, efficient and fair
operating points. It uses queuing delay, in addition to packet
loss, as a congestion signal. Queuing delay provides a finer
measure of congestion and scales more naturally with network
capacity than packet loss probability does [4]. Using the
queuing delay as a congestion measure in its window updating
equation [5], allows FAST TCP to overcome difficulties [9]
encountered by currently used algorithms (such as TCP Reno
[1]) in networks with large bandwidth-delay products.
The window updating manipulations of FAST TCP rely on
estimating the round-trip propagation delay (RTPD) using a
parameter called baseRTT which is the minimum round-trip
time (RTT) observed so far. FAST TCP proposals [3], [4]
assume the usual first-in-first-out (FIFO) schedule in routers.
This leads to inaccurate estimation of RTPD by baseRTT
which results in unfairness [4], [8] and excessive variations
of routers’ queues. The contribution of this paper is twofold.
Firstly, we demonstrate that certain flows may consistently
experience higher queuing delay than others. This gives them
higher baseRTT value than others, so they estimate lower
queuing delay than they actually have and therefore they
obtain higher throughput than the less aggressive flows. Secondly, we examine the benefit achieved by improving RTPD
estimation by giving strict priority to the first packet (by
Diffserv) in every flow over all other traffic streams.
Manuscript received January 14, 2005. The associate editor coordinating the
review of this letter and approving it for publication was Dr. Nikos Nikolaou.
The work of the first two authors was supported by the National Natural
Science Foundation of China under Grant Number 60473085; the work of
the third author was supported by the Australian Research Council under
Grant Number DP0559131.
Liansheng Tan and Cao Yuan are with the Computer Science Department of Central China Normal University, Wuhan, PR. China (e-mail:
l.tan@mail.ccnu.edu.cn).
Moshe Zukerman is with the Australian Research Council Special Research
Center for Ultra-Broadband Information Networks (CUBIN), an affiliated
program of National ICT Australia, EEE Dept., The University of Melbourne,
Victoria, Australia (e-mail: mzu@unimelb.edu.au).
Digital Object Identifier 10.1109/LCOMM.2005.08023.
II. FAST TCP W INDOW C ONTROL AND ITS E QUILIBRIUM
In [4] the network model of window congestion control
algorithm is presented, where the network consists of a set of
links with finite capacities and is shared by a set of unicast
flows. Let us introduce the following notation used in [4] for
source i. The component wi is the congestion window, di
is the round-trip propagation delay, qi is the queuing delay
estimated by qi = RT T − di . FAST TCP adapts the source
window size periodically according to the following equation
di wi (t)
+ αi (wi (t), qi (t)) +(1−γ)wi (t),
wi (t+1) = γ
di + qi (t)
(1)
where
αi wi if qi = 0
αi (wi , qi ) =
otherwise.
αi
Subsequently, we rewrite (1) as
wi (t + 1) = wi (t) + γ(αi − xi (t)qi (t)),
(2)
where xi = wi /RT T is the sending rate of source i. From
(2), the unique equilibrium point (x∗i , qi∗ ) of the FAST TCP
system is
αi
(3)
x∗i = ∗ , qi∗ = RT T ∗ − di ,
qi
where RT T ∗ stands for the round-trip time when the router
queue reaches its equilibrium.
When the router queue reaches its equilibrium, every flow
has the same queuing time, by (3), during a period of traffic
congestion, each competing flow with the same value of αi
should theoretically obtain an equal share of the bottleneck
c 2005 IEEE
1089-7798/05$20.00 TAN et al.: FAST TCP: FAIRNESS AND QUEUING ISSUES
Fig. 3.
The sending rate of the four FAST TCP flows under FIFO.
link bandwidth. However, both the experimental results reported in [4] and our simulation results presented in the next
section do not demonstrate such equal sharing.
763
Fig. 4.
The router queue under FIFO.
of RTPD. A similar phenomenon also exists in Vegas [6], [7],
[11].
B. Analysis
III. FAST TCP UNDER FIFO
Considering FAST TCP under the FIFO schedule, we run
the following ns2 [2], [10] simulations on the dumbbell
network topology shown in Fig. 1 with the four FAST TCP
sender and receiver pairs (S1-D1, S2-D2, S3-D3 and S4-D4)
each with different active periods (flows) as shown in Fig.
2. For each flow, we set the parameter αi = 200 packets
(i = 1, 2, 3, 4) and set every packet size to 1 kbyte.
A. Demonstration of unfairness
In FAST TCP [4] the component di is the RTPD of
source i, but in actual implementation this value is set by
minimum RTT observed so far, which is called baseRTT.
Clearly, baseRTT may not be an accurate estimate of RTPD.
The two are equal only when the queuing delay of the packet
that experiences the minimum RTT for each flow is zero.
This is not the case in our example as shown in Fig. 4. A
late joining FAST TCP flow overestimates its RTPD because
ALL its packets experience significant queuing delay thus its
baseRTT is too high. Therefore it underestimates its queuing
delay relative to early joining FAST TCP flows. This makes
the late joining flows more aggressive thus obtaining higher
throughput. Considering the notation used in (3), the late
flow’s rate xi is greater than that of early joining flows.
Flows are said to become active one by one if the next
flow becomes active after the previously activated flow reaches
its equilibrium. Because FAST TCP reaches its equilibrium
quickly [4], the assumption that flows become active one by
one is reasonable. As shown in Fig. 4, while there is only one
flow in the link, the router queue size is 200 packets; as the
late joining flows become active one by one, the router queue
size reaches 520 packets, 916 packets and finally 1368 packets.
Theoretically, at equilibrium state every source with the same
value of α maintains the same number of packets in the router
queue. Therefore, increment of router queue should be equal
when the four flows join one by one. However, the simulation
results shown in Fig. 4 display more rapidly increasing router
queue length than expected. It is due to incorrect estimation
Let us now consider a general dumbbell network model with
n source-destination pairs. In this model, the single bottleneck
link is shared by a set of n unicast FAST TCP flows, identified
by their sources. We further assume that these flows become
active one by one.
For each FAST TCP Flow i, let xi be the sending rate
(i = 1, 2, · · · , n), which allocation is subject to the capacity
constraint:
(4)
x1 + x2 + · · · + xn = C,
where C is the capacity of the link and xi = αi /qi , qi is the
queuing delay. We assume that α1 = α2 = · · · = αn = α
and that the flows enter the router one by one, and let bi be
the increment of router queue when the ith flow enters the
link. When there is only one flow in the link: x1 = C, and
q1 = b1 /C. Using (3) and (4) we have 1/b1 = 1/α. When
the second flow enters the link, because it cannot obtain the
correct RTPD, it observes the queuing delay q2 = b2 /C, and
the first flow observes the queuing delay q1 = (b2 + b1 )/C,
with (3) and (4) we have 1/(b1 + b2 ) + 1/b2 = 1/α.
On the basis of the above analyses, we present the following
recursion procedure to calculate bi
1
1
=
b1
α
1
1
1
+
=
b1 + b 2
b2
α
1
1
1
1
+
+
=
b1 + b 2 + b 3
b2 + b 3
b3
α
..
.
(5)
1
1
1
1
+
+ ··· +
= .
b1 + · · · + bn
b2 + · · · + bn
bn
α
The summation b1 + b2 + · · · + bn is the router queue size,
and (b1 + b2 + · · · + bn )/C is the queuing delay. From (5),
we compute b1 = α, b2 = 1.618α, b3 = 1.9817α, and then
we can prove that bn+1 > bn , and bn is divergent. So when n
increases, bn increases rapidly. That is, the queuing delay of
late arriving flows increases rapidly with the number of flows.
This supports the argument that because of the use of baseRTT
764
IEEE COMMUNICATIONS LETTERS, VOL. 9, NO. 8, AUGUST 2005
Fig. 5. The sending rate of the four FAST TCP flows under the PQ scheme.
Fig. 6.
to estimate RTPD, the unfairness is likely to increase with the
number of flows.
results on the sending rate of the four FAST TCP flows and
the router queue under the PQ scheme are displayed in Figs. 5
and 6, respectively. Just as the theory indicates, the simulation
results demonstrate that, by using the PQ schedule, fairness at
the equilibrium state is successfully achieved among the FAST
TCP flows. If n FAST TCP flows maintain the same bottleneck
router queue length using the same α value, each flow will
obtain a 1/n portion of the bottleneck link bandwidth, and
subsequently the increase of router queue size is lower than
under the FIFO schedule.
IV. FAST TCP WITH P RIORITY Q UEUE
We propose to improve the estimation of RTPD for FAST
TCP by using packet marking and priority queue (PQ). A
similar idea of using PQ has been used in [11]. However,
according to our method, only one flow needs to send one high
priority packet, while according to [11] many high priority
packets are sent, i.e., out-of-band (OB) control packets, which
may overload the priority queue.
PQ gives strict priority to specially marked packets so they
are sent without queuing delay. This scheme provides the
feasibility for FAST TCP to estimate RTPD accurately. We
make a small modification in the FIFO mechanism of FAST
TCP by marking the type of service (ToS) with the highest
priority for the first packet of each flow and assign other
packets the normal priority. When the highest priority packet
enters the router, it will be dispatched immediately even if the
router buffer is not empty. By doing so, FAST TCP obtains
better RTPD estimation.
We now show that FAST TCP can estimate RTPD accurately using the above method. The equilibrium-sending rate
of each flow is x∗i = αi /qi , we still assume that α1 = α2 =
· · · = αn = α, the increment bi is calculated by the follow
recursion procedure:
1
1
=
b1
α
1
1
1
+
=
b1 + b 2
b1 + b 2
α
1
1
1
1
+
+
=
b1 + b 2 + b 3
b1 + b 2 + b 3
b1 + b 2 + b 3
α
..
.
1
1
1
1
+
+ ··· +
= .
b1 + · · · + bn
b1 + · · · + bn
b1 + · · · + bn
α
(6)
Using (4), we solve (6) to obtain: b1 = b2 = · · · = bn = α
and x1 = x2 = · · · = xn = C/n.
To further study the performance of FAST TCP under this
PQ schedule, we now repeat the simulation of Section 3. The
model and the parameter settings are kept as before; we only
change the FIFO queuing schedule in the PQ. The simulation
The router queue under the PQ scheme.
V. F INAL R EMARKS
We have demonstrated the benefits of giving priority to
some packets to better estimate baseRTT in FAST TCP for the
case of a single bottleneck model. However, in the case of a
real network, there are many effects that need to be discovered
and understood before implementation. For example, with
many short flows, the priority queue itself could be congested
and when the network topology changes, the RTPD estimation
may not be accurate.
R EFERENCES
[1]
M. Allman, V. Paxson, and W. Stevens, “TCP congestion control,” IETF
RFC2581, Apr. 1999.
[2] T. Cui and L. Andrew, “FAST TCP simulator module for ns-2, version
1.1” (online). Available: http://www.cubinlab.ee.mu.oz.au/ns2fasttcp.
[3] C. Jin, D. Wei, and S. H. Low, “FAST TCP for high-speed long-distance
networks,” Internet draft draft-jwl-tcp-fast-01.txt (online). Available:
http://netlab.caltech.edu/pub/papers/draft-jwl-tcp-fast-01.txt.
[4] C. Jin, D. Wei, and S. H. Low, “FAST TCP: Motivation, architecture,
algorithms, performance,” in Proc. IEEE INFOCOM 2004, vol. 4, Mar.
2004, pp. 2490-2501.
[5] C. Jin et al., “FAST TCP: from theory to experiments,” IEEE Network,
vol. 19, pp. 4-11, Jan./Feb. 2005.
[6] R. J. La, J. Walrand, and V. Anantharam, “Issues in TCP Vegas” (online). Available: http://www.eecs.berkeley.edu/ ananth/19992001/Richard/IssuesInTCPVegas.pdf.
[7] S. H. Low, L. L. Peterson, and L. Wang, “Understanding Vegas: a duality
model,” Journal of the ACM, vol. 49, pp. 207-235, Mar. 2002.
[8] M. Mehyar, D. Spanos, and S. H. Low, “Optimization flow control with
estimation error,” in Proc. IEEE INFOCOM 2004, vol. 2, March 2004,
pp. 984-992.
[9] F. Paganini, Z. Wang, J. C. Doyle, and S. H. Low, “Congestion control
for high performance, stability, and fairness in general networks,”
IEEE/ACM Trans. Networking, vol. 13, pp. 43-56, Feb. 2005.
[10] USC/ISI, Los Angeles, CA. The Network Simulator - ns-2 (online).
Available: http://www.isi.edu/nsnam/ns/.
[11] Y. Xia, D. Harrison, S. Kalyanaraman, K. Ramachandran, and
A. Venkatesan, “Accumulation-based congestion control,” IEEE/ACM
Trans. Networking, vol. 13, pp. 69-80, Feb. 2005.