TCP-FIT - A Novel TCP Congestion Control Algorithm for Wireless ...

TCP-FIT - A Novel TCP Congestion Control
Algorithm for Wireless Networks
Jingyuan Wang, Jiangtao Wen, Jun Zhang and Yuxing Han
State Key Laboratory on Intelligent Technology and Systems
Tsinghua National Laboratory for Information Science and Technology (TNList)
Department of Computer Science and Technology, Tsinghua University, Beijing, China
Email: wangjingyuan06@mails.tsinghua.edu.cn, jtwen@mail.tsinghua.edu.cn,
zhangjun06@mails.tsinghua.edu.cn, and erica.yuxing.han@gmail.com
Abstract—The Transport Control Protocol (TCP) has been
widely used in wired and wireless Internet applications such
as FTP, email and HTTP. However, performances of traditional
TCP congestion algorithms degrade significantly when deployed
over wireless networks. In this paper, we proposed an improved
TCP congestion control algorithm for wireless networks, named
TCP-FIT, and compared its performance with existing state-ofthe-art
congestion control algorithms as well as an application
layer Parallel TCP scheme. Experiment results show significant
performance improvement, good fairness and lower end-to-end
latency for TCP-FIT.
I. INTRODUCTION
The Transport Control Protocol (TCP) has been widely
used in wired and wireless Internet applications such as FTP,
email and HTTP. Performances of traditional TCP congestion
algorithms degrade significantly when deployed over wireless
networks [14]. Although many congestion control algorithms
such as TCP Westwood [10], and TCP Veno [6] were proposed
for application over wireless networks, improving TCP
performance for large delay variation, high packet loss rate
wireless networks and intermittent connectivity, such as LTE
[9] and WiMax [1] networks, remains a challenge. A different
approach to improving the quality of experience for
applications utilizing TCP over wireless networks is Parallel
TCP [7]. The core idea of Parallel TCP is to create multiple
actual or virtual TCP sessions that are controlled jointly so as
to fully utilize network bandwidth. Parallel TCP in wireless
networks can achieve very good performance, e.g. as reported
in [4] and [5]. In [5], an application layer Parallel TCP system
named E-MULTCP was proposed for TCP-based multimedia
streaming over wireless networks. E-MULTCP system requires
that the contexts of multiple TCP sessions be monitored,
and the applications layer software modified. The requirement
to modify the application layer software severely limits the
applicability of the system.
In this paper, we proposed a novel TCP congestion control
algorithm for wireless networks, named TCP-FIT. In TCP-
FIT, N virtual TCP sessions are utilized in a single TCP
connection. The algorithm uses both packet loss and queuing
delay as inputs to the congestion window control algorithm.
The congestion window of each sessions is controlled in
an AIMD (Additive Increase and Multiplicative Decrease)
manner based on packet loss information, whereas the number
N of virtual sessions is adjusted dynamically based on delay.
Experimental results demonstrate significant performance
improvements under various channel conditions. Compared
with application layer Parallel TCP, the proposed algorithm
has the additional advantage of not requiring changes to the
application layer software.
The rest of this paper is organized as the following: Section
II describes the TCP-FIT algorithm in detail. Simulations
results of TCP-FIT and comparisons with E-MULTCP are
given in section III. Section IV is the conclusion.
II. THE TCP-FIT CONGESTION CONTROL ALGORITHM
To better describe the proposed congestion control algorithm,
we imagine that each physical session consists of
N virtual Reno [2] sessions, where the congestion control
window for each virtual Reno session is adjusted in an AIMD
manner as the following:
Each RTT : cwnd ← cwnd + 1
Each Loss : cwnd ← cwnd − (cwnd/2)
As a result, the congestion window of the actual FIT-TCP
connection is adjusted as:
Each RTT : Cwnd ← Cwnd + N
Each Loss : Cwnd ← Cwnd − (Cwnd/2N)
where Cwnd is the congestion window for the actual physical
TCP session, consisting of N virtual sessions of congestion
window cwnd.
A potential issue with (2) is that for two TCP-FIT sessions
sharing the same bottleneck, because the value of the Cwnd
is updated every RTT (Round-Trip Time), the session with the
longer RTT will have fewer chances to update its Cwnd and
thereby at a disadvantage. In order to mitigate this problem,
instead of using (2) directly, we introduce a normalization
factor into the calculation of Cwnd:
Each RTT : Cwnd ← Cwnd + γN
Each Loss : Cwnd ← Cwnd − (Cwnd/2N)
in which γ = RTT/RTT 0 , and RTT 0 is a baseline RTT value
representing the statistical “floor” of the RTT values in the
network.
(1)
(2)
(3)

In TCP-FIT, the number N of virtual parallel Reno-like
sessions is also dynamically adjusted using the following
equation:
N i+1 = max{1, N i + (α −
Q
Cwnd N i)} (4)
where α is a preset parameter, Q is an estimate of the number
of in-flight packets that are currently queued in the network
router, calculated as:
Cwnd
Q = (ave rtt − rtt min) ·
ave rtt . (5)
where avg rtt and rtt min are the average of TCP RTT
samples and minimal avg rtt respectively.
Form (4) we know, TCP-FIT use the amount of in-flight
packets that are currently queued in the network router to
determine the number of virtual sessions should be used. If
there are more in-flight packets in the router buffer, the number
of virtual sessions would be decreased to balance the in-flight
traffic.
Combining equations (3 - 5) gives the complete formula for
updating TCP-FIT congestion control window:
Each RTT : Cwnd ← Cwnd + γN i
Each Loss : Cwnd ← Cwnd − (Cwnd/2N i )
ave rtt − rtt min
N i+1 = max{1, N i + (α − N i )} (7)
ave rtt
It is important to note that although the proposed TCP-
FIT algorithm was motivated by the concept of virtual parallel
Reno sessions, when implementing the algorithm, the concept
is no longer needed. Rather, for each TCP session in TCP-
FIT, the congestion window is directly calculated according
to equations (6) and (7), wherein N i is simply a variable in
the calculation. No changes to any other parts of the protocol
stack on both the sender and receiver ends are needed.
III. EXPERIMENTAL RESULTS
We compared the performance of TCP-FIT with stateof-the-art
TCP congestion control algorithms as well as an
application layer Parallel TCP system, named E-MULTCP.
We will briefly introduce E-MULTCP in Subsection III-A,
while detailed experimental results will be discussed in the
remaining subsections.
A. Application Layer Parallel TCP: E-MULTCP [5]
A system diagram for E-MULTCP is shown in Fig.1 [5].
There are two components in the system, namely the RTT
Measurer Subsystem (RMS) and the Connections Controller
Subsystem (CCS). The gray blocks in Fig. 1 represents
the RMS. It measures round trip time samples (denoted by
rtt sample’s) by computing the difference between the time
a packet is sent, and the time the sender receives the corresponding
ACK for the same packet using a UDP connection.
After each fixed time interval, the RMS computes the average
(ave rtt) of the rtt sample’s, and reports the value to the
CCS.
(6)
CCS Server
RMS Server
TCP
UDP
UDP
CCS Client
RMS Client
Fig. 1. System diagram of E-MULTCP [5]
Hub
TCP-FIT Server
Linktropy Network
Emulator
Fig. 2.
E-MULTCP
Server
Layout of experiments testbed
Client
The CCS is shown as the white blocks in Fig.1. Based on
route congestion status, the CCS controls the number of TCP
connections n in an Inversely Increase and Multiplicatively
Decrease (IIMD) manner. Specifically, when an ave rtt is
reported to CCS by RMS, CCS sets the rtt min as the
minimum of all ave rtt’s seen so far, and then updates the
value of n using:
{
δn + ξ/n, if avg rtt > (1 + µ) × rtt min
n =
(8)
n + ξ/n ; otherwise.
where δ = 1 − ξ < 1 and µ is a preset parameter, the
recommendation values of δ, ξ and µ are explained in [5].
For a given route, rtt min is a constant approximating the
physical propagation delay of the route, whereas ave rtt -
rtt min corresponds to the current queuing delay. Under
ideal conditions, E-MULTCP keeps increasing the number of
connections to make ave rtt as close to (1 + µ)rtt min as
possible without exceeding it.
B. Performances
The setup of our experiments is shown in Fig. 2. In each
comparison, two Linux servers were connected via a hub to
a Linktropy emulator. The Linktropy emulator provides the
capability of setting the bandwidth, packet loss rate, delay,
delay distribution and other parameters of the network. For
application layer Parallel TCP experiments, an E-MULTCP
server and an E-MULTCP client were used. Experiments with
other TCP variants used a standard Linux client, while the
corresponding TCP congestion algorithm was loaded on the

4000
8
TCP Throughput (kbps)
3000
2000
1000
TCP−FIT
TCP−FIT
E−MulTCP
Westwood
TCP Reno
CTCP
CUBIC
FAST TCP
End−to−End Delay (sec)
6
4
2
TCP−FIT
FIT
Mul−TCP
Westwood
Reno
0
50 100 150 200 250 300 350
Propagation Delay (ms)
0
0.02 0.04 0.06
Packet Loss Rate
Fig. 3. Performance comparison for random packet loss link. In the
experiments, the network bandwidth was set to 4 Mbps with a packet loss
rate of 5% and propagation delay from 50 ms to 350 ms.
Fig. 5. End-to-end latency comparison. In the simulations, the network
bandwidth was set to 4 Mbps with a 50 ms propagation delay and packet loss
rate 1% to 7%.
2000
25
TCP Throughput (kbps)
1500
1000
500
TCP−FIT
TCP−FIT
E−MulTCP
Westwood
TCP Reno
CTCP
CUBIC
FAST TCP
End−to−End delay (sec)
20
15
10
5
TCP−FIT
FIT
E−MulTCP
Westwood
Reno
0
50 100 150 200 250 300 350
Delay Mean and Standard Deviation (ms)
0
0.02 0.04 0.06
Packet Loss Rate
Fig. 4. Performance comparison for Gaussian distributed random delay. In
the experiments, the network bandwidth was set to 4 Mbps with a PLR of
5% and propagation delay mean and standard deviation from 50 to 350 ms.
Fig. 6. End-to-end latency comparison. In the simulations, the network
bandwidth was set to 4 Mbps with a 250 ms propagation delay and packet
loss rate 1% to 7%.
Linux TCP server. The TCP variants tested in the experiments
include TCP-FIT TCP Reno, Westwood, CUBIC [8],
Compound TCP [12], and FAST TCP [15]. TCP CUBIC and
Compound TCP (CTCP) are widely used as the congestion
control algorithms for the Linux and Windows Vista operating
systems. TCP Westwood is a congestion control algorithms
optimized for wireless. We used the CTCP implementation
from CalTech [3] and implemented the FAST TCP algorithm
based on [13]. Other TCP congestion control algorithms are
available from the Linux kernel v2.6.31. In all experiments, for
each given scenario, only one client/server pair was actually
used, even though two different servers might be connected to
the same hub.
We first compared the performance of the TCP-FIT with E-
MULTCP and other TCP variants in the presence of wireless
packet losses. In the experiments, we set the bandwidth of
Linktropy to 4 Mbps. In Fig. 3, the packet loss rate was set to
5% respectively. In each experiment, we varied the propagation
delay of link from 50 ms to 350 ms. As can be seen from the
figures, TCP-FIT achieved higher throughput than E-MULTCP
and other TCP congestion control algorithms.
We then tested performance of TCP-FIT over random
delay links. We ran simulations with Gaussian distributed
propagation delay generated by the Linktropy emulator. In the
experiments, the bandwidth was again set to 4 Mbps. In Fig.
4, the packet loss rate was set to 5%. In each experiment,
the average propagation delay varied from 50 ms to 350 ms,
and the standard deviation of the propagation delay in each
case was set to equal the average propagation delay. The
results of Fig. 4 showed that, similar to the cases with random
packet losses but fixed delay, even with both random Guassian
distributed delays and packet loss, TCP-FIT still achieved
higher throughput than E-MULTCP and other TCP congestion
control algorithms.
A critical characteristic of TCP application is the resulted
end-to-end latency in the application layer, especially for
multimedia applications such as video streaming or VOIP. We
measured the end-to-end latency on the application layer with
the bandwidth set to 4 Mbps, the packet loss rate varying from
1% to 7%, and the average propagation delay set to 50 ms (Fig.

LTE base
station (eNB)
LTE User
Equipment
(Live-UE)
Fig. 7. Bandwidth occupation among competing TCP flows. In the simulations,
the network bandwidth was set to 10 Mbps with a 10 ms propagation
delay and no random packet loss.
Fig. 9.
Network topology of LTE emulator test-bed
TABLE I
LTE EMULATOR PARAMETERS SETTING
Parameter
Tx Power
Bandwidth
Penetration Loss
Pathloss
Inter Site Distance
DL Antenna Config
Channel Model
Shadowing
Scheduler
Value
46dBm (eNB), 24dBm (UE)
10MHz
20dB
128.1dB+37.6dB*log10(d/km)
500m
1x2(Rx diversity a UE)
Typical Urban 3km/h
2D uncorrelated grid
Proportional Fair
Fig. 8. Bandwidth occupation among competing TCP flows. In the simulations,
the network bandwidth was set to 10 Mbps with a 100 ms mean
propagation delay, 80 ms delay standard deviation and 0.5% random packet
loss.
5) and 250 ms (Fig.6). In both cases the end-to-end latency of
TCP-FIT was lower than E-MULTCP and other TCP congestion
control algorithms. Another interesting observation can
be made by comparing the end-to-end latency and throughput
of E-MULTCP for identical network conditions in Fig. 3, Fig.
4 and Fig. 5 and Fig. 6. As can be seen from the figures,
given the same network condition, although the throughput
for E-MULTCP was usually much higher than that of TCP
Westwood or Reno, the end-to-end latency for E-MULTCP
was not much different in many cases. This is partly due to the
fact that E-MULTCP uses multiple physical TCP connections
that are managed separately by the server. Therefore, the client
must reorder the received packets at the client, which creates
additional latency on the application layer, and increases the
complexity of the client.
Yet another comparison we did was the Inter Protocol
Fairness of TCP-FIT and other TCP congestion control algorithms.
Fig. 7 contains the results of our experiments.
In this experiment, one connection of the TCP algorithm
to be tested competed with four TCP Reno sessions. The
combined bandwidth was set to 10 Mbps, with a propagation
delay of 10 ms and no random packet losses. As shown in
Fig. 7, TCP-FIT and Compound TCP both occupied about
20% of the total bandwidth, i.e. the theoretical ”fair share”.
FAST TCP and TCP CUBIC on the other hand, occupied
up to 35% bandwidth, which means these algorithms might
be overly aggressive and not inter protocol friendly. Similar
experiments were conducted for Fig.8, with the total network
bandwidth still set to 10 Mbps but with 0.5% packet loss, and
Gaussian (mean 100 ms, 80 ms standard deviation) distributed
propagation delay. In this case, as a result of the worsened
network conditions, the 5 TCP sessions combined were only
able to use less than 40% of the total network bandwidth. TCP-
FIT in this case was able to pick up some of the capacity that
the other Reno sessions left unused. It is important to note that
in the case of TCP-FIT with 4 Reno sessions, the percentages
(i.e. between 5% and 10%) of the bandwidths that the 4 Reno
sessions used were still comparable to their respective numbers
for the case with 5 Reno sessions, indicating that the additional
throughput that TCP-FIT was able to utilize did not come at
the expense of the Reno sessions.
To evaluate the performance of TCP-FIT in real life wireless
networks, we conducted experiments using the Nomor
Neatbox LTE emulator[11]. The Neatbox provides realistic and
real time emulation of LTE networks and is widely used by
wireless carriers and equipment manufacturers. The wireless
network topology of one of our experiments is shown in Fig.

Cumulative Probability
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
TCP−FIT
CTCP
CUBIC
TCP−FIT
RENO
WESTWOOD
Throughput(kbps)
10000
9000
8000
7000
6000
5000
4000
3000
2000
1000
CTCP
CUBIC
TCP−FIT
RENO
WESTWOOD
TCP−FIT
0
0 2000 4000 6000 8000
Throughput(kbps)
0
0 5 10 15
SNIR(db)
Fig. 10. Throughput Cumulative Probability of different TCP variant on the
LTE emultaor test-bed.
Throughput (kbps)
SNIR(dB)
8000
6000
4000
2000
0
15
10
5
0
−5
TCP−FIT
20 40 60 80 100 120 140
TCP−FIT
CUBIC
RENO
CTCP
WESTWOOD
20 40 60 80 100 120 140
Time (min)
Fig. 11. Throughput change of different TCP variants with the LTE UE
SINR fluctuation.
9, which contained one LTE base station (eNB) and 10 LTE
User Equipments (UE) in a cell of 600-m radius. The eNB
is connected to a Linux TCP server, which is connected to
one of the LTE UEs, called Live-UE in the figure. The other
9 UEs, called Non-live-UEs, provided the background traffic
in the experiments, generated by a Neatbox built-in 3GPP
video simulation model. The emulation parameters of the LTE
network are listed in Table I. Fig. 10 showed the cumulative
probability function of the throughput achieved by each TCP
variant during a 3-hour period for each algorithm. Fig. 11
showed the throughput change of different TCP variants with
the LTE UE SINR fluctuation in the 3 hours and shows the
throughput of the various TCP congestion algorithms over the
LTE network as a function of the SINR. 12. As shown from
Fig. Fig. 10 to Fig. 12, the performance of TCP-FIT was
significantly better than the other algorithms and TCP-FIT is
very effective in a large range of SINR.
IV. CONCLUSION
In this paper, we proposed a new TCP congestion control
algorithm named TCP-FIT for lossy networks such as
wireless. Experimental results show significant performance
improvements under various channel conditions over existing
Fig. 12. Throughput comparison between different TCP variants for varied
SINR. In the experiments, the SINR of LTE UE varied from -1 dB to 15 dB
and other parameters are set as Table I.
state-of-the-art TCP congestion control algorithms as well as
application layer Parallel TCP techniques such as E-MULTCP,
including higher throughput, lower end to end latency and
good fairness. The algorithm also does not require modifications
to the client and application softwares.
REFERENCES
[1] Z. Abichar, Y. Peng, and J. M. Chang. Wimax: The emergence of
wireless broadband. IT Professional, 8(4):44–48, July 2006.
[2] M. Allman, V. Paxson, and W. Stevens. Tcp congestion control. RFC
2581, April 1999.
[3] L. ANDREW. Compound TCP in Linux.
http://netlab.caltech.edu/lachlan/ctcp/.
[4] R. Chakravorty, S. Katti, J. Crowcroft, and I. Pratt. Flow aggregation
for enhanced tcp over wide-area wireless. In Proc. IEEE INFOCOM,
page 1754C1764, March 2003.
[5] M. Chen and A. Zakhor. Flow control over wireless network and
application layer implementation. In Proc. IEEE INFOCOM, pages 103–
113, March 2006.
[6] C.P.Fu and S.C.Liew. Tcp veno: Tcp enhancement for transmission over
wireless access networks. IEEE J. Select.Areas Commun., 21(2):216–
228, February 2003.
[7] J. Crowcroft and P. Oechslin. Differentiated end-to-end internet services
using a weighted proportional fair sharing tcp. SIGCOMM Comput.
Commun. Rev., 28(3):53–69, July 1998.
[8] S. Ha, I. Rhee, and L. Xu. Cubic: a new tcp-friendly high-speed tcp
variant. SIGOPS Oper. Syst. Rev., 42(5):64–74, February 2008.
[9] Khan and Farooq. LTE for 4G Mobile Broadband: Air Interface
Technologies and Performance. Cambridge University Press, New York,
NY, USA, 2009.
[10] S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi, and R. Wang. Tcp
westwood: Bandwidth estimation for enhanced transport over wireless
links. In Proc. MobiCom, pages 287–297, July 2001.
[11] Nomor. neatboxTM - Network Emulator for Application
Testing. http://www.nomor.de/home/solutions-andproducts/products/application-tester.
[12] K. Tan, J. Song, Q. Zhang, and M. Sridharan. A compound tcp approach
for high-speed and long distance networks. In Proc. IEEE INFOCOM,
APRIL 2006.
[13] T.Cui and L. Andrew. FAST TCP simulator module for ns-2, version
1.1. Technical White Paper, http://www.cubinlab.ee.mu.oz.au/ns2fasttcp.
[14] Y. Tian, K. Xu, and N. Ansari. Tcp in wireless environments: Problems
and solutions. IEEE Communications Magazine, 43:27–32, 2005.
[15] D. X. Wei, C. Jin, S. H. Low, and S. Hegde. Fast tcp: motivation, architecture,
algorithms, performance. IEEE/ACM Trans. Netw., 14(6):1246–
1259, March 2006.