See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220553488

TCP Window Based Congestion Control -Slow-Start Approach

Article in Communications and Network · January 2011

DOI: 10.4236/cn.2011.32011 · Source: DBLP

CITATIONS READS

14 1,398

6 authors, including:

Ayodeji Oluwatope Olusegun Folorunso

Elizade University University of Agriculture, Abeokuta
38 PUBLICATIONS 117 CITATIONS 71 PUBLICATIONS 781 CITATIONS

SEE PROFILE SEE PROFILE

Ganiyu A. Aderounmu Olatunde Abiona

Obafemi Awolowo University Indiana University Northwest
59 PUBLICATIONS 186 CITATIONS 20 PUBLICATIONS 122 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

An Approach for Detection of Data Traffic Attacks Using Fuzzy Based Trust Level in MANET View project

Multimedia Networking and Computing View project

All content following this page was uploaded by Ayodeji Oluwatope on 27 May 2014.

The user has requested enhancement of the downloaded file.

Communications and Network, 2011, 3, 85-98
doi:10.4236/cn.2011.32011 Published Online May 2011 (http://www.scirp.org/journal/cn)

TCP Window Based Congestion Control Slow-Start

Approach
Kolawole I. Oyeyinka1, Ayodeji O. Oluwatope2, Adio. T. Akinwale3, Olusegun Folorunso3,
Ganiyu A. Aderounmu2, Olatunde O. Abiona4
1
Department of Computer Science, Yaba College of Technology, Lagos, Nigeria
2
Comnet Lab., Department of Computer Science and Engineering, Obafemi Awolowo University, Ile-Ife, Nigeria
3
Department of Computer Science, UNAAB, Abeokuta, Nigeria
4
Department of Computer Information Systems, Indiana University Northwest, Garry, USA
E-mail: [email protected], {aoluwato, gaderoun}@oauife.edu.ng, [email protected]
Received February 23, 2011; revised March 1, 2011; accepted April 8, 2011

Abstract

Transmission control protocol (TCP) has undergone several transformations. Several proposals have been
put forward to change the mechanisms of TCP congestion control to improve its performance. A line of re-
search tends to reduce speed in the face of congestion thereby penalizing itself. In this group are the window
based congestion control algorithms that use the size of congestion window to determine transmission speed.
The two main algorithm of window based congestion control are the congestion avoidance and the slow start.
The aim of this study is to survey the various modifications of window based congestion control. Much work
has been done on congestion avoidance hence specific attention is placed on the slow start in order to moti-
vate a new direction of research in network utility maximization. Mathematical modeling of the internet is
discussed and proposals to improve TCP startup were reviewed. There are three lines of research on the im-
provement of slow start. A group uses the estimation of certain parameters to determine initial speed. The
second group uses bandwidth estimation while the last group uses explicit request for network assistance to
determine initial startup speed. The problems of each proposal are analyzed and a multiple startup for TCP is
proposed. Multiple startups for TCP specify that startup speed is selectable from an n-arry set of algorithms.
We then introduced the e-speed start which uses the prevailing network condition to determine a suitable
starting speed.

Keywords: Data Communication, Network Protocols, TCP, Congestion Control, Slow-Start

1. Introduction Worthy of note is the domination of the Internet by

TCP flows carrying data from applications such as FTP,
Originally, the Internet was designed to support best- HTTP, SMTP etc in the early days of TCP. However, the
effort applications meaning that then it could only de- nature of Internet traffic has changed dramatically such
liver data not necessarily guaranteeing the delivery. that it includes traffic from other data transmission pro-
However, before 1988, TCP was used to compliment the tocols, which are TCP unfriendly. Protocols and applica-
Internet by ensuring that data delivery was reliable. This tions that are not malleable to the dynamics of the Inter-
same TCP version did not include congestion avoidance, net are reffered to as TCP-unfriendly. But, TCP in an
fast-recovery and fast-retransmit mechanisms. The direct attempt to respond to the dynamics [8,9] of the Internet,
impact on user applications is low network utility deriva- it penalizes itself by reducing transmission speed spe-
tion as a result of heavy network congestion. This re- cifically, in the face of network congestion. However,
sulted in congestion collapse throughout the mid 80s. these TCP-unfriendly protocols and applications are ag-
This continues until [1] introduced the concept of con- gressive at bandwidth consumption and do not respond
trol through the adaptation of the source rate using to network congestion indications. TCP-unfriendly ap-
packet loss. Jacobson algorithm has been modified vari- plications include video streaming, voice-over-IP, and
ously by several researchers among these were [2-7]. videoconference.

Copyright © 2011 SciRes. CN

86 K. I. OYEYINKA ET AL

In simple terms, congestion control is the adaptation of certain threshold, it switches to linear window size in-
an application’s rate of packets injection into the Internet crease i.e. by one packet per RTT before conges- tion
in response to changing network conditions such as occurs (Additive increase). At this point, Tahoe switches
packets loss and/or end-to-end delay. There are two types to the congestion avoidance state. If the ACK for a
of congestion control techniques—window- and rate- packet is not received before a time out, the thresh- old
based. In window-based approach, data transmission rate is set is reduced by half and the congestion window is re-
adjusted based on setting a congestion window size using duced to one packet (Multiplicative decrease). In sum-
additive increase and multiplicative decrease (AIMD) mary, TCP Tahoe controls congestion as follows:
algorithm. While in rate-based approach, a set of equa-  When congestion window is below the threshold, the
tions is used to control data transimission speed. TCP congestion window grows exponentially (slow start
uses the window-based approach as a congestion control state)
technique.  When the congestion window is above the threshold
The fate of Jacobson’s AIMD algorithm and its sub- the congestion window grows linearly (additive in-
sequent modifications in the face of cross traffics and crease) i.e. congestion avoidance
heterogeneous flows is a motivation for this work. From  Whenever there is a timeout, the threshold is set to
literature, substantial research efforts had been concen- one half of the current congestion window and the
trated no the understanding, modification and imple- congestion window is set to one while the packet is
mentation of window-based congestion control with par- retransmitted (multiplicative decrease)
ticular focus on the congestion avoidance stage. But,  Algorithms implemented are slow start and conges-
recent study has shown that attention should shift to- tion avoidance.
wards better understanding and modification of win-
dow-based congestion control with focus on the slow- 2.2. TCP Reno
start stage and acknowledgement congestion control.
Therefore, the focus of this paper is to review existing Proposal to modify Tahoe was given in [11]. Like its
proposals on TCP congestion avoidance and slow- start predecessor, Reno sets its congestion window to one
mechasims with view to motivating a new direction in packet upon a time out (RTO). However, Reno extended
the network utility maximisation. its algorithm to include the fast retransmit mechanism.
The rest of this paper is organized as follws: Section 2 The fast retransmit involves the re-transmission of a
discusses various variants of TCP implementations, Sec- dropped packet if three duplicate ACKs for a packet are
tion 3 looks at some rate based congestion control pro- received before the RTO. Reno also introduces the fast
posals. Section 4 discusses mathematical modeling of the recovery mechanisms which prevent transmission to
internet congestion control, Section 5 looks at the various re-enter the slow start state after a fast retransmit. Instead
modifications of the slow start state of TCP, Section 6 the window size is halved and the threshold is adjusted
analyses the various problems associated with each TCP accordingly and TCP remain in congestion avoidance
variants, Section 7 suggests future research directions until a timeout occurs. This is discussed in detail in [3,5].
while section 8 concludes the paper. TCP Reno became the standard TCP algorithm imple-
mented in most computers. Algorithms implemented by
2. Variants of TCP Reno are slow start, congestion avoidance, fast retrans-
mit and fast recovery.
Variants of TCP, which are of interest, include those
implemented already, yet to be implemented and em- 2.3. TCP New Reno
ploying convectional slow-start algorithm.
The new-Reno TCP includes a change to the Reno algo-
2.1. TCP Tahoe rithm at the sender end with a view to eliminate Reno’s
wait for a retransmit time-out whenever multiple packets
The TCP Tahoe was released in 1988 by V. Jacobson in are lost from a window [7,12]. This change modifies the
[1] being the first implementation of TCP to employ sender’s behaviour during fast recovery. When this hap-
congestion control mechanism. Tahoe contains the AIMD pens, New Reno does not exit from the fast recovery
(additive increase, multiplication decrease) being its state as in the case of Reno, but waits for the receipt of
control mechanism. Tahoe achieved congestion control all the outstanding ACKS for that window.
through adjusting its windows size additively to increase The followings are the summary of New-Reno fast
and multiplicatively to descrease. AIMD at the initial recovery actions;
stage increases windows size exponentially but, after a  It notes the maximum packet s outstanding while en-

Copyright © 2011 SciRes. CN

 K. I. OYEYINKA ET AL 87

tering fast recovery deduce which packet has not been acknowledged and
 When a new ACK is received and it acknowledges all resend them when it is able.
the outstanding packets, then fast recovery is exited  When a retransmitted packet is dropped, SACKs de-
and cwnd is set to half the value of ssthresh, then it tects this through the retransmit timeout. This packet
transits to the congestion avoidance state. But, if a will be retransmitted and then SACKs transits to the
partial ACK is received, then, it assumes the next slow-start state.
packet in the link is lost and tries to retransmit  Recovery ACK: The sender exits fast recovery when
 It exits fast recovery when all data in the window is a recovery acknowledgement is received acknowl-
acknowledged [6]. edging that all outstanding data when fast fecovery
was entered have been received.
2.4. SACK (TCP with Selective  Partial ACKS: SACK handles partial ACKs in a spe-
Acknowledgement) cial way. Partial ACKs are those received during Fast
Recovery but do not take the sender out of Fast re-
One challenge with the New Reno algorithm is its inabil- covery. When a partial ACK is received, the pipe is
ity to detect other lost packets until the ACK for the first decreased by two packets rather than one, at first,
retransmitted packet was received. This implies that New when fast retransmit is initiated, the pipe is decreased
Reno suffers from the fact that the detection of each by one for the lost packet and increased by one for
packet loss takes one RTT. Hence selective acknowl- the retransmitted packet in subsequent partial ACKs
edgment (SACK) was proposed by [13]. SACK is an received, the pipe was incremented when the packet
extension of TCP Reno and TCP New Reno. It intends to was transmitted initially but the pipe was never de-
solve two problems of TCP Reno and New Reno i.e. creased when that packet is assumed lost and re-
detection of multiple packet loss and Retransmission of transmitted. Hence when the succeeding partial ACK
more than one lost packet per RTT. arrives, it represents two packets (the original packet
SACK retains the slow start and fast retransmits of and the retransmitted packets) Hence the pipe is dec-
Reno. It also has the coarse grained time out of Tahoe. remented by two rather than one.
SACK algorithms specify that instead of cumulative ac-  The max burst parameter: This limits the number of
knowledgement of packets as contained in TCP Tahoe, packets that can be sent in response to a single in-
Reno and New-Reno, Packets should be acknowledged coming ACK packet. This is still at the experimental
selectively. This requires each ACK to contain an entry stage.
for which packet that is being acknowledged. This en- Other TCP congestion control algorithms that use se-
ables the sender to figure out which packets have been lective acknowledgement include that of [4,14] etc. One
acknowledged and which ones are still outstanding. major drawback of the SACK algorithm is the relative
SACK specifies that whenever a sender enters into difficulty in implementation of selective acknowledge-
fast recovery state, a variable “pipe” be initiated and ment.
used to estimate the number of packets that are missing
along the path. It then sets the size of cwnd to half its 2.5. TCP Vegas
current size as usual.
Each time an ACK is received, the size of the pipe is The TCP congestion control schemes that have been de-
decreased by one and when a packet is transmitted or scribed so far use packet loss based approach to measure
retransmitted, the pipe is increased by one. Whenever the congestion. There is a class of congestion control algo-
size of the pipe becomes smaller then cwnd, it checks rithms that adapt its congestion window size based on
which packets are yet to be acknowledged and retrans- end-to-end delay. This approach originated from [15]
mits immediately. If there are no outstanding ACK, it and is presented by [16,17] as TCP Vegas.
sends a new packet. Thus the sender only sends new or The followings are the differences between TCP Ve-
retransmitted packet if the pipe is less the cwnd. This gas and TCP Reno:
way SACK can send more than one lost packet in a sin-  In the slow start-state, congestion control was in-
gle RTT. Use of pipe variable separates the decision of corporated by a deliberate delay in congestion win-
when to send a packet from which packet to send. dow growth.
Other features of SACK are as follows:  When packet-loss occurs, TCP Vegas treats the re-
 The score board: The sender maintains a data struc- ceipt of certain ACKs, as a trigger to check if a time-
ture call scoreboard. This was proposed by [13]. The out should occur [16].
scoreboard remembers all the ACKS that has been  It updates its congestion window based on end-to-end
received for the data sent. Hence the sender is able to delay instead of using packet-loss as the window up-

Copyright © 2011 SciRes. CN

88 K. I. OYEYINKA ET AL

date parameter. propagation delay, e.g. retransmission delay in wireless

Vegas extended Reno re-transmission strategy. It keeps link, a high loaded Internet link etc. There are very few
track of when each packet was sent and calculates an researches done on delay-based congestion control in
estimate of RTT for each transmission. This is done by wireless mobile network with the exception of [18] which
monitoring how long it took each ACK to get back to the proposed delay based congestion control scheme for
sender. Whenever a duplicate ACK is received, it per- commercial CDMA (Code Division Multiple Access).
forms the following check: Other lines of researches are in the area of high-speed,
if (current RTT > RTT estimate) large delay networks. Prominent among these are the
If this is true, it retransmits the packet without waiting High Speed TCP (HSTCP) proposed by [19] and scal-
for 3 duplicate ACK or a time out as in Reno [17]. Hence, able TCP (STCP) proposed by [20] which are experi-
Vegas solves the problem of not detecting lost packets mental protocols that attempt to improve TCP perform-
when the window is very small i.e. less than three and ance under large bandwidth-delay product. They make
could not receive enough duplicate ACKs. TCP increments rule become more aggressive. Loss-
TCP Vegas congestion avoidance behavior is different delay based Strategy was used by TCP Africa, Com-
from other TCP implementations. It determines congest- pound TCP [21] and TCP Illinois [22]. These protocols
ion states using the sending rate. If there is a decrease in try to increase window size more aggressively than TCP
calculated rate of transmission as a result of large queue New Reno as long as the network is not fully utilized and
in the link, it reduces its window. When the sending rate it switches to AIMD behavior of Reno when the network
increases, the window size also increases. is near congestion.

2.6. Delay Based Congestion Control Algorithms 2.7. Summary of Proposed TCP Congestion
Control Implementation
These types of algorithms use queuing delay to signal the
need for window adjustment. The issue of fairness comes Henceforth, TCP Tahoe, Reno and New Reno are re-
with these algorithms. Delay based congestion control is ferred to as New- Reno. This is the transport protocol of
attractive because it can solve the problem of fairness choice and it is implemented in over 90% of Internets
using queuing delay. To implement delay based conges- traffic today. It became officially recognized in 2004 [6].
tion control, it is necessary to measure propagation delay. But, currently, Compound TCP which is the version im-
Propagation delay is the time it takes a packet to travel plemented in Ms-Window 7 is expected to grow in us-
from the sender to its destination. The propagation delay agen across the Internet. Table 1 shows the comparison
is usually set to the smallest observed RTT. There are between TCP New-Reno and other proposed TCP algo-
several observed problems with the estimation of the rithms.
queuing delayed. Estimating queuing delay is challeng- In Table 1, the various proposed TCP variants, are
ing if the RTT contains more elements then affixed categorized based on their control mechanism or type of

Table 1. Variants of TCP congestion control implementation (using TCP new reno as basis).

Protocol Type Purpose

TCP New-Reno [6] Loss based The standard TCP protocol
STCP [20] Loss based Higher throughput with high capacity and large delay
HSTCP [19] Loss based Higher throughput with high capacity and large delay
BIC – TCP [23] Loss based Higher throughput with high capacity and large delay
CUBIC [24] Loss based Higher throughput with high capacity and large delay
TCP Vegas [17] Delay based Higher through puts and reduced loss rate
Fast TCP [25] Delay based Higher throughput with high capacity and large delay
TCP Africa [26] Lossdelay based Higher throughput with high capacity and large delay
Compound TCP [21] Lossdelay based Higher throughput with high capacity and large delay
TCP Illinois [22] Lossdelay based Higher throughput with high capacity and large delay
West wood + [27] Bandwidth estimation Higher throughput over wireless networks. High capacity & large delay networks.
Higher throughput over wireless networks. Also for high capacity and large delays. Smaller
XCP [28] Extra signaling
queues. Separate fairness control

Copyright © 2011 SciRes. CN

 K. I. OYEYINKA ET AL 89

feedback. It also considers the performance challenge of constraints. This is referred to as Kelly’s system problem
New-Reno which it attempts to address. The TCP like and it is an optimization problem.
algorithms highlighted uses control mechanism like loss- Under the rate based congestion control, congestion
based, delay- based, loss-delayed based, bandwidth esti- control schemes can be viewed as algorithms that com-
mating, and extra signalling. TCP New-Reno was up- pute the optimum or sub-optimum solutions to the
graded from experimental status to full protocol status in Kelly’s system optimization problem. Congestion control
2004. Several proposals and researches had been put schemes can be categorized into three: primal, dual and
forward to improve its performance. Many of these pro- primaldual.
posals tend to improve TCP in a high speed network
where it has been showed that TCP mechanism may lead 3.1. Primal Algorithms
to network resources underutilization. [29]. TCP West-
wood proposed bandwidth estimation as congestion Here the endpoints adapt the source rates dynamically
measure [27]. It specified that a TCP sender continuously based on the route prices and the links select a static law
computes the connection bandwidth estimate by properly to determine the links prices directly from the arrival rate
averaging the returning ACKs and the rate at which the [35].
ACKs are received. After a loss has occurred, the sender
uses the estimated bandwidth to properly set the sending 3.2. Dual Algorithms
rate and the congestion window. This is an improvement
on standard TCP which half its window on loss detection This is a direct opposite of the primal algorithms, the
[30]. However, TCP Westwood hase not proved any bet- links adapt the links prices dynamically based on the link
ter in term of stability and fairness when it co-habit with rates and the end points select a static law to determine
the standard TCP and its suitability for general deploy- the source rates directly from the route prices and other
ment has not been ascertained. Other proposed protocols source parameters [28,35,36].
in this category include XCP [31] which requires modi-
fication to router algorithm. However, it is not visible to 3.3. Primal-Dual Algorithm
modify all existing routers’ algorithms hence XCP will
remain experimental protocol for a long time. HSTCP The algorithms in primal family measure congestion us-
[19] was also designed for high bandwidth delay product. ing the links aggregate rate. This involved the averaging
It uses loss-delay to detect congestion. Wei et al. [25] of feedback from the network by end points (sources).
proposed the FAST TCP which uses delay instead of loss On the other hand, the algorithms in the dual family cal-
to signal congestion. Other protocols in this category culate the source rate from the route congestion measures
include BIC TCP [23], STCP [20], CUBIC TCP [24], which corresponds to averaging the source rate before
TCP Illinois [22] etc. These protocols deal with modify- the sources get a feedback of explicit congestion infor-
ing the window growth function to TCP to match large mation. The primal-dual algorithms viewed congestion
bandwidth-delay product. This appears easy but the issue control as decomposable into two parts: Congestion
of fairness that comes with these protocols is enormous avoidance at the source and active queue management at
and remains a challenge. These fairness issues include the links. Primal-dual algorithms relate rate change with
both intra and inter-protocol fairness. In addition, none route congestion measure at the source and relate packet
of these protocols targets the startup behaviour of AIMD. marking probability change with link aggregate rate at
the router [34,37,38]. An example is the work of Liu [34],
3. Rate-Based Congestion Control Scheme where a new class of algorithms is introduced, which is
of primal-dual type. That is, they feature dynamic adap-
According to [32], a great percentage of the current re- tations at both the source and the link ends.
searches on congestion control concentrate on the use of Stability of primal mechanism under communication
network utility maximization framework [33] as guid- is analyzed by [39,40] and reported in [32]. Paganini et
ance for design and analysis [28]. al [41] proposed a dual algorithm and showed that it is
The optimization-based framework introduced by [33] stable in arbitrary topologies and delays. Alpcan and
formed the derived operating point for congestion control Basar’s [37] algorithm for primal-dual was shown to be
algorithms. The framework, according to [34] associates stable in the absence of delay. It was also proved to be
a utility function with each flow and maximizes the ag- stable for networks with a single bottleneck link and
gregate system utility function subject to link capacity several users when each user may have different RTT.

Copyright © 2011 SciRes. CN

90 K. I. OYEYINKA ET AL

4. Mathematical Modelling of the Internet 4.1. Slow Start Phase

Congestion Control
1) cwnd = 1; Start with a window size of 1
Prior to 1997, when Kelly [33] introduced the system 2) while (ssthresh ≠ cwnd OR not 3 DUPACK) {
problem, researches in congestion control was intuitive, IF ACK then
based on laboratory experiment, simulation and valida- cwnd=cwnd + 1; } Increase the window size by 1 for every
ACK received. Repeat until:
tion. But with the Kelly [35] paper titled “Rate control in
The ssthresh is reached OR packet-loss is detected
Communication Networks”, research community began 3) if ssthresh == cwnd then
to model congestion control mathematically. There has Transit to congestion avoidance; If ssthresh is reached, go
been a vast research effort in this area. Currently, re- to congestion avoidance phase.
search activities in this area are large and quite a number 4) if 3DUPACK then
of models have been proposed in literature. One impor- ssthresh = 0.5 * cwnd;
tant research direction is the search for new models to cwnd = 1;
replace the Jacobson algorithm [1]. branch to step 2; If a packet loss is detected
Jacobson AIMD has worked so well on the Internet
metamorphosising from a few number of users/network Note: Set the initial value of ssthresh to fraction (say
to a very big giant networks with million of networks half) of the maximum window size. This is determine at
the beginning of transmission
and over a billion users world wide. However, the ade-
quacy of these models has been questioned by many re-
searchers in today’s and future Internet traffic which is
4.2. Congestion Avoidance Phase
changing rapidly. Currently over 80% of the Internet
1) Increase the window size by 1 (cwnd) for every
traffic is TCP traffic. However this ratio will change
ACK received. This implies that the window size is in-
rapidly in the face of anticipated growth of traffics like
creased by 1 after all ACKs for that window has been
multimedia application protocol, voice over Internet,
received.
video conferencing, games etc. which use protocols that 2) When packets loss is detected, decrease the window
are quite different from TCP. While TCP is self regulat- size, then transit to slow start phase.
ing in the face of congestion, other protocols that these Detecting and decreasing the window size has been
heterogeneous traffics are using are quite aggressive and the major focus of researched in literature and quite a
hence the case of fairness comes in when TCP traffic huge number of proposals have been made resulting in
share a bottleneck link with other traffics on the Internet. the formulation of different TCP variants like TCP-
Hence mathematical models of congestion control are Tahoe, TCP-Reno, TCP SACK, TCP New-Reno etc. For
being proposed in literature. Moller [32] classified mod- the purpose of modeling hence forth we will refer to all
els for congestion control and related tools as; of them as TCP New-Reno. In TCP New-Reno, packet-
 Packet level models: A packet level model accounts loss is detected either through:
for the location of each individual packet as the pack-  The loss of 3 consecutive packets or
ets are queued and forwarded by the network. The  By the RTO time-out
system state evolves as a series of discrete events.
Events in Internet are arrival and departure of packets, 4.3. The Slow Start Phase Analysis
and timeouts.
 Fluid flow models: A fluid flow model sees the data To explain the algorithm of Jacobson [1] further, let the
transport as a continuous fluid, with no packet following example be considered as presented in [42].
boundaries. State variables vary continuously, and are Assume a single TCP source is accessing a single link
described using differential equations. In congestion that was discussed in [43]. Suppose c is the link capacity
control, fluid flow models do not capture all details of in packets/second. Let r denote the round trip propaga-
the dynamics. Instead the state variables represent tive delay and T (the sum of propagation delay and
averages of the true system state. queuing delay) is given by
 Hybrid Models: Here, evolution of the state is a result T = r + 1/c
of discrete events together with continuous changes
between events. A continuous model is used for Now suppose that link capacity is 50 Mbps and packet
queuing dynamics and end host actions while action size of 4000 bytes then
like multiplicative decrease of TCP is modeled as c = 50, 000, 000 4000
discrete event. c = 12,500 packet sec
Jacobson’s congestion control algorithm operates in
two phases: slow start and congestion avoidance phase. 1 c = 0.08 msec

Copyright © 2011 SciRes. CN

 K. I. OYEYINKA ET AL 91

Assume the transmission is over a distance of 2000 km Table 2. Slow start transition cycles (source: modified from
of fibre-optic with speed of light = 3 × 108 m/sec (ignore [42]).
the refractive index of transmission media)
Acked Window Max packet
Round trip propagation delay (r); Cycle Time
packet size released
 
r = 2  103 3  108  Cycle 0 O - 1 1
−5
r = 2 3 × 10 Cycle 1 T 1 2 3
r = 0.66 × 10−5 2T 2 3 5
Cycle 2
r = 6.6 × 10−6 2T + 1/c 3 4 7
r = 6.6 msec. 3T 4 5 9
T = 6.6 + 0.08 msec 3T + 1/c 5 6 11
Cycle 3
3T + 2/c 6 7 13
T = 6.68 msec 3T + 3/c 7 8 15
The Product cT is called bandwidth-delay product.
4T 8 9 17
Denote by B, the buffer size of the link (route). 4T + 1/c 9 10 19
Assumptions: 4T + 2/c 10 11 21
1) cT ≥ B Cycle 4
4T + 3/c 11 12 23
4T + 4/c 12 13 25
2) Propagation delay from source to sink is negligible 4T + 5/c 13 14 27
3) Propagation delay from link to source is T. 4T + 6/c 14 15 29
Note that packets are released by the source at rate c 4T + 7/c 15 16 31
and they are released at 1/c seconds.
5T
ACKs in transit = cT 5T + 1/c
16 17 33
Cycle 5 17 18 35
Number of packets in buffer = B 5T + 2/c
18 19 37
Total unacknowledged packets = cT + B …
Therefore, maximum window size, 1
Cycle = Time for which it takes the window size to double
wmax = cT + B
any increase above this quantity will lead to buffer over- Max queue length is a cycle
flow and packed loss. If packet loss occurs, as explained, Qm = 2n – 1 + 1 (3)
the ssthresh will be set to half the current window size. Max window size in a cycle
(this will be slightly larger than wmax) Wm = 2n (4)
Let us assume that Note that Qm  wm 2 ≤  cT  B  4 and Qm ≤ B
ssthresh =  mT  B  2 At the slow start state, the sufficient condition for
where c ≤  buffer not to overflow;
Hence, the transitions at the slow start can be viewed  cT  B  4 ≤ B
as presented in Table 2. In Table 2, a cycle refers to the B ≥ cT 3
time it takes the window size to double. At time t = 0, the If B  cT 3 , buffer overflow occurs because
source released the first packets, the ACK for this packet Wmax = cT + B, meaning that Q  B.
got to the source after one RTT which is denoted by T Therefore at the point where the window size is
time units. The receipt of this ACK increases the window Wmax 2 ,
size from 1 to 2 and triggers the release of 2 packets into Q = Wmax 4
the network. This begins the next cycle. It takes 1 RTT Q = Wmax =  cT  B  4 B
for the first of the packets to be acknowledged. The from here
window size becomes 3 and only 1 unACKed packet is B  cT 3
in the network, hence 2 additional packets are released and overflow does occur.
into the network when the next ACK is received, win- From the foregoing, there are two possible cases:
dow size is increased to 4 at time t = 3T and the next, Case 1: B ≥ cT 3 (Buffer does not overflow)
cycle is started. Then remains 2 unACKed packets in the Denote the length of the slow-start phase by Tss. From
network, hence 2 additional packets are released [42]. the Table 2 observe that
From the table, we observed the following: W(t)  2t T
Window size is given by Hence Tss is given by
W  nT+ m c  = 2n – 1 + m + 1, 0 ≤ m ≤ 2n–1 (1) 2Tss/T =  cT  B  2
Tss = Tlog2  cT  B  2
Queue length is given by
Q  μT+ m c  = m + 2, 0 ≤ m ≤ 2n–1 (2) Case 2: B  cT 3

Copyright © 2011 SciRes. CN

92 K. I. OYEYINKA ET AL

In this case, there will be two slow start phase. The has extra overhead for the computation of PID and fur-
first phase, buffer overflows and there is a packet loss thermore, it was not designed to work in large BDP net-
which reduces the window size to 1 and slow start is work.
re-entered. Shared Passive Network Performance Discovery
During the first slow start (SPAND) proposed by [48] is another technique classi-
Tss1 = T log2  2B+T  fied into this group. SPAND collects current network
state and gains optimal initial parameters to determine an
(the additional T is added because it takes one RTT to initial sending rate. The weakness of this approach is in it
detect packet loss). needs for leaky bucket pacing for outgoing packets
Nss1 = 2B which can be costly and problematic.
Window size at packet loss is Adaptive Start (Astart) by Ren Wang et al [49] uses
min (4B – 2, ssthresh) the Eligible Rate Estimation (ERE) mechanism proposed
where ssthresh =  cT  B  2 by TCP Westwood adaptively and repeatedly resetting
In the second slow-start ssthresh during the slow start phase. When ERE indicates
ssthresh = min  2B  1,  cT  B  4  that there is more available capacity, the connection in-
creases its cwnd at a faster rate, on the other hand, when
(Since ssthresh is half of window size) ERE indicates that the network is close to congestion, the
Hence connection switches to congestion avoidance limiting the

Tss2 = T log2 min  2B  1,  cT  B  4   risk of buffer overflow.
Capstart proposed by Canvendish et al. [50] estimates
Nss2 = min  2B  1,  cT  B  4  path capacity after the TCP session has been established
Generally and uses it to tune TCP to deliver higher transfer speed.
Tss = Tss1 + Tss2 Capacity estimation is done using two network scenarios.
and These are capacity expansion and capacity reduction
Nss = Nss1 + Nss2 which is defined in relation to TCP sender speed and
path bottleneck speed. If bottleneck link capacity is
5. Modifications of Slow-Start greater than sender speed then the capacity expanded
otherwise, it is capacity reduced. This protocol is capable
There have been several modifications of the slow start of adjusting itself to the available bandwidth whether
stage to overcome the problem of performance associ- high or low, however, it did not take other network con-
ated with it. From literature, there are three lines of stud- ditions into account, for instance, network dynamism
ies. A group of researchers used capacity estimation such as available bandwidth at various moments de-
techniques to estimate available bandwidth and set the pending on changes occurring within the network such as
congestion window size using the estimated bandwidth. connections establishments or terminations. The second
In this group belongs the work of Patridge [44] which group employs parameter-based manipulations to deter-
proposed Swift Start for TCP. Swift Start used an initial mine transmission speed. Commonly used network pa-
window (cwnd) of 4 packets and thereafter estimates the rameters are the ssthresh and cwnd. TCP Fast Start by
available bandwidth in the first round trip time. It uses [51] records the recent network parameters (cwnd and
the estimated bandwidth to calculate the bandwidth- ssthresh) to reduce the start time of a new connection and
delay product (BDP) of the network and set the cwnd to to reduce transmission delays. These parameters may be
a percentage of the calculated BDP. Lawas-Grodek and too aggressive or too conservative when network condi-
Tran [45] carried out a performance evaluation of Swift tion changes. Chen et al. [52] proposed the collection of
Start and submitted that Swift Start improves network recent history information on the network which shall be
performance when the network is not congested however used to initialize parameters for a new connection. Pa-
when the network overflows, the estimation of the cwnd rameter setting based history information can not fit the
drift away from accuracy. This is due to retransmission dynamic changes of network and violates slow start
of delayed or lost ACKs and RTO timeouts. principle.
Another proposal that uses capacity estimation to de- In TCP Vegas, [17] restricts the growth of cwnd by
termine the size of the congestion window is Restricted doubling cwnd only at every other RTT. TCP Vegas can
slow-start by [46]. Restricted Slow start used a PID con- not handle multiple packet losses in one window. Lim-
trol algorithm as proposed by [47] to determine the rate ited slow start by [53] aims at eliminating exponential
of increase at the slow start phase. In PID control ap- growth of cwnd which causes large packet losses. The
proach, the controller calculates an output that deter- approach limits the exponential growth up to a max-
mines the new value of the sender cwnd. This approach ssthresh parameter value over which the cwnd is in-

Copyright © 2011 SciRes. CN

 K. I. OYEYINKA ET AL 93

creased by a fraction of the current cwnd value. This quested sending rate. The quick start mechanism can
replaces the exponential growth with a near linear cwnd detect if there are routers in the path that disapproved or
growth when the congestion window size is greater or do not understand the quick start request. The receiver
equal to max-ssthresh. This will make the congestion communicates its response to the sender in an answering
window grow slowly after max ssthresh is reached and TCP packet. If the Quick start request is approved by all
this makes limited slow start not suitable for large capac- routers along the path, then the sender can begin trans-
ity network. mission at the approved rate. Subsequently, transmis-
Other proposals in the second group include New Pa- sions will be governed by the default TCP congestion
rameter-Config Based Slow Start Mechanism (P-Start) control mechanism. If the request is not approved, then
by [27] increases the congestion window exponentially the sender transmits at the normal TCP startup speed [57].
while the cwnd is less than ssthresh 2 , otherwise in- According to [57], TCP is effective for both flow
creases by  ssthresh  cwnd  2 and gradually appro- control and congestion control. The TCP flow control is
aches ssthresh until (ssthresh-cwnd) is less than the fac- a receiver-driven mechanism that informs the sender
tor of d where ssthresh 2 ≥ d ≥ 2. There after congestion about the available receive-buffer space and limits the
avoidance is entered. The major feature of P-start is in maximum amount of outstanding data. Flow control and
the manner of cwnd increases that is small amplitude at congestion control are independent and the size of re-
start and transition to congestion avoidance. Changing in ceive buffer space depends on the capacity of the re-
sending rate is smooth and has minor impact on the ceiver network. However, if the TCP is used with a link
flows in the network; however, P-start may waste band- with large bandwidth-delay product, both congestion
width and may not get to maximum transmission speed window and flow control window need to be large in
in good time thereby performing worst than slow start. In other for TCP to perform well [55]. This makes both
addition, P-start will perform poorly in a high BDP net- flow control and congestion control to overlap. The
work thereby not suitable for future gigabit networks. Quickstart TCP extension assumes independence of flow
The third group obtains information and/or request and congestion control. This is not true which makes it
assistance from the network/link. Congestion manager inappropriate for the global internet. In addition, most
proposed by [54] collects congestion status information routers and other network components on the global
and feedback from receivers and share it with endpoints Internet are not built with capabilities to be quick start
and connections in the network. This will enable connec- aware which implies that they need either to be replaced
tions determine the congestion status of the network and or modified before it can be used. Hence, we propose a
thereby determine an initial sending rate. The congestion milder approach to fast startup which we call (E-speed
manager has a weakness of being beneficial to only con- startup). This is a form of fast startup that does not need
nections that are initiated almost at the same time and routers’ response or modification; rather it builds
secondly, it is only those connections and endpoints that end-to-end principles. This proposal is compatible with
supplied feedback that can benefit from this scheme. the current Internet as well as the future Internet.
Some techniques require explicit network assistance to Table 3 summarizes the various slow start modifica-
determine a practicable starting sending rate. Prominent tions that exist in literature. E-speed start combines the
among this group is the work of [55] called Quick Start feature of the two groups (Parameter based manipulation
explained below. capacity/bandwidth estimation).
According to Floyd et al. [55], the experimental
Quickstart TCP extension is currently the only specified 6. Discussion on Problems Associated with
TCP extension that realizes a fast startup. A large Individual TCP Variant
amount of work has already been done to address the
issue of choosing the initial congestion window for TCP. The control mechanism of TCP Tahoe has a problem. If
RFC 3390 [56] allows an initial window of up to four a packet is lost, the sender may have to wait a long pe-
packets. Quick start is based on the fact that explicit riod of time for a time-out to occur for such loss to be
feedback from all routers along the path is required to be detected and retransmitted. The data may not be retrans-
able to use an initial window larger than those specified mitted for a very long time in networks with large delay.
by RFC 3390. TCP Reno was designed to solve this problem. Although
In quick start proposals, a sender (TCP host) would Reno perform well over TCP Tahoe when the packet
indicate its intention to send at a particular rate in bytes losses are small, its performance is not good when there
per second. Each router along the path could approve, are multiple packet losses in a single RTT. Reno can
reduce, disapprove or ignore the request. Approval of the handle a single packet loss. If there are multiple losses,
request by the router indicates that it is being underuti- the first duplicate ACKs received will trigger the re-
lized currently and it can accommodate the sender’s re- transmission of the first packet that was lost. The next

Copyright © 2011 SciRes. CN

94 K. I. OYEYINKA ET AL

lost packet will be detected when the sender receive the sion [26]. BIC-TCP and CUBIC try to solve this problem
ACK for the retransmitted data after one RTT. In addi- by monitoring the window size when it experienced a
tion cwnd may be reduced twice for packet losses which packet loss and slows down transmission as the window
occurred in one window. Another problem of RENO is size approach this monitored window size. [24]. Table 4
that if the window is very small when the loss occurs, the summarizes the deficiencies of the various TCP Variants:
sender may not receive enough duplicate ACKS for a
fast retransmit. Hence it has to wait for a time out to oc- 7. Research Direction
cur before detecting that the packet is lost. These prob-
lems are solved with the introduction of TCP New-Reno.
Currently there are three different research directions
One problem with the New-Reno algorithm is its in-
intending to develop or make TCP better: Improving
ability to detect any other packet-loss in the window.
TCP performance over links with large bandwidth delay
This implies that New-Reno suffers from long delay in
product, improving TCP performance over wireless and
detecting each packet loss i.e. it takes more one RTT.
reducing the queuing delay at bottleneck links thereby
Hence selective acknowledgment (SACK) was proposed
improving quality for real time applications. Other focus
by [6]. SACK is an extension of TCP Reno and TCP
New-Reno. It intends to solve the problems of TCP Reno of research includes finding a suitable startup speed for
and New Reno i.e. detection of multiple packet loss and slow start most especially in a high bandwidth delay
Retransmission of more than one lost packet per RTT. product. TCP modifications of the future will work well
One major set back of SACK is in its selective acknowl- with gigabit networks as well as backward compatible
edgement which is a bit cumbersome to implement. with low speed networks, a protocol fair to both itself
Delay-based congestion control algorithms were pro- and to other flows in the network i.e. intra and inter pro-
posed to solve the problems associated with the loss tocol fairness. A new line of research bothers on conges-
based congestion control models. Most delay based con- tion control of ACK packets. Controlling acknowledg-
gestion control algorithm has fairness problems when ment packets congestion is a novel problem and differs
sharing link with TCP New Reno. This is because they from the techniques used in controlling data packet con-
become more aggressive when they are at the peak of gestion. This is a new research direction that requires
transmission when they suppose to slow down transmis investigation.

Table 3. Modifications of slow start.

Protocol Type Purpose

TCP Vegas [16] Parameter based Double cwnd every other RTT.
Used network parameters to reduce connections’ start time and trans-
TCP Fast Start [51] Parameter based
mission delay.
Collects recent history information and use it to initialize connection
Recent history information collection [58] Parameter based
parameters.
Limited slow start [53] Parameter based Eliminates the exponential growth of cwnd.
Increases cwnd with small calculated amplitude after ssthresh/2 has
P-Start [59] Parameter based
been reached.
uses low-priority data segments, namely, supplement segments to
FAST-FOR-WARD START [60] Parameter based
calculate cwnd.
SPAND ([48] Bandwidth Estimation Obtain network state to determine initial sending rate.
Used initial packet of 4 and then estimate available bandwidth in the
Swift Start [44] Bandwidth Estimation
first round trip.
Used the difference between the data packet spacing and the acknowl-
PACED START [60] Bandwidth Estimation
edgement spacing for estimating appropriate cwnd.
Used Eligible Rate Estimation mechanism to determine available band-
Astart [49] Bandwidth Estimation
width to adaptively and repeatedly reset ssthresh and cwnd.
Restricted slow start [46] Bandwidth Estimation Used PID control algorithms to calculate a value of the sender cwnd
Capstart [50] Bandwidth Estimation Estimate path capacity and tune TCP to deliver at higher transfer speed.
Congestion Manager [54] Require network assistance Collects congestion status information and share with endpoints.
Obtain explicit feedback from all routers along the path to transmit at an
Quick Start [55] Require network assistance
approved large rate.

Copyright © 2011 SciRes. CN

 K. I. OYEYINKA ET AL 95

Table 4. Deficiencies of TCP variants.

TCP Variants Issues solved Inherent problems

TCP Tahoe [1] Introduced the concept of congestion control Loss detection is after a time out
TCP Reno (Jacobson, 1990) Introduced fast retransmit and fast recovery Could not detect multiple losses within one RTT
TCP New Reno [6] Solved the problem of multiple losses detection of each packet loss takes one RTT
TCP SACK [13] Introduced Selective Acknowledgement Difficult to implement
TCP Vegas [16] Delay based Fairness issue
Fast TCP [25] Delay based Fairness issue
HSTCP(Floyd S. 2003) Loss based Fairness issue
STCP [20] Loss based Fairness issue
BIC – TCP [23] Loss based Fairness issue
CUBIC [24] Loss-Delay based Fairness issue
TCP Africa [26] Loss-Delay based Fairness issue
Compound TCP [21] Loss-Delay based Fairness issue
TCP Illinois [22] Loss-Delay based Fairness issue
West wood + ([27] Bandwidth estimation Fairness issue
XCP [28] Extra signaling Fairness issue
Obtain network state to determine initial It requires the costly and problematic leaky
SPAND [48]
sending rate. bucket.
Reduced connection start time and transmis-
TCP Fast Start [51] Too aggressive when network conditions change.
sion delay
Beneficial to only connections that are initiated
Collects and share congestion status
Congestion Manager [54] almost at the same time and endpoints that sup-
information
plied feedback.
The estimation of the cwnd drift away from accu-
Swift Start [44] TCP start up using 4 packets.
racy when there is congestion.
Collects recent history information and use it Can not fit the dynamic changes of network and
Recent history information collection [58]
to initialize connection parameters. violates slow start principle
Limited slow start [53] Eliminates the exponential growth of cwnd. May be too conservative in a high BDP.
Restricted slow start (Allcock et al, 2004) used a PID control algorithm extra overhead for the computation of PID
Uses ERE mechanism adaptively and re-
May not be able to use its fair share of available
Astart (Wang R. et al, 2004) peatedly resetting ssthresh during the slow
bandwidth
start phase.
Capstart proposed by estimates path capacity
Did not take other continuously changing network
Capstart [50] and use it to tune TCP to deliver higher
conditions into account.
transfer speed
Increases cwnd by small amplitude after May waste bandwidth resource as it may not get to
P-Start [59]
ssthresh/2 has been reached. a high transmission rate in good time.

congestion indication? A possible answer is that future

8. Conclusions
protocols may have the requirements of matching up
with this aggressiveness while controlling congestion
We have reviewed here, various modifications of TCP in effectively. Furthermore, super gigabit network will re-
history. There is a large number of works done in this place today’s network. How will TCP increase its trans-
area. The review carried out here focused on window mission speed to match this high bandwidth network?
based congestion control. The internet protocol of choice, What should be the slow start behaviour of TCP under
TCP New-Reno, has performed well in today’s inter- this situation? Will TCP be both backward and forward
net,the question is, how will TCP co-habit with other compatible with low speed and high speed network
protocols that are more aggressive and non responsive to without necessarily using network resources sub-

Copyright © 2011 SciRes. CN

96 K. I. OYEYINKA ET AL

optimally? These are questions that must be answered in doi:10.1145/235160.235162

finding a replacement for today’s internet protocol of [13] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, “TCP
choice- the TCP. In addition, it was observed that all Selective Acknowledgment Options,” RFC 2018, Internet
reviewed congestion control techniques used only a sin- Engineering Task Force, October 1996.
http://www.ietf.org/rfc/rfc2018.txt
gle startup for TCP, this is in most cases the slow start or
its modification. However, the option of having multiple [14] S. Keshav and H. Saran, “Semantics and Implementation
of a Native-Mode ATM Protocol Stack,” 1994.
startups for TCP using the prevailing operating condi-
citeseer.ist.psu.edu/52943.html
tions at the time of connection is a research line that
[15] R. Jaine, “A Delay-Based Approach for Congestion Avoid-
should attract the attention of the Internet research com-
ance in Interconnected Heterogeneous Computer Network,”
munity. A research in this area called e-speed start uses ACM Computer Communication Review, Vol. 19, No. 5,
environmental (i.e. operating) parameters to determine 1989. pp. 56-71. doi:10.1145/74681.74686
whether to use the conventional TCP slow start or any [16] L. S. Brakmo, S. W. O’Malley and L. L. Peterson, “TCP
other startup algorithms depending on the network oper- Vegas: New Techniques for Congestion Detection and
ating conditions. It is hoped that when completed, Avoidance,” Proceedings ACM SIGCOMM, London,
e-speed start will address the problem of TCP start up in August 31-September 2, 1994.
both highspeed and lowspeed networks. [17] L. Brakmo and L. Peterson, “TCP Vegas: End-to-End
Congestion Avoidance on Global Internet,” IEEE Journal
9. References on Selected Areas in Communications, Vol. 13, No. 8,
1995, pp. 1465-1480. doi:10.1109/49.464716
[1] V. Jacobson, “Congestion Avoidance and Control,” Pro- [18] R. S. Jayaram and I. Rhee, “A Case of Delay-Based Flow
ceedings of ACM Sigcomm, Scanford, 26-30 August 1988, Control in CDMA 2.5G Networks,” International Confer-
pp. 314-329. ence on Ubitiquitous Computing, Washington, 2003.
[2] V. Jacobson, R. Braden and D. Borman, “TCP Extensions [19] S. Floyd, “High Speed TCP for Large Congestion Wind-
for High Performance,” RFC 1323, Internet Engineering ows,” RFC 3649, 2003.
Task Force, 1992. www.ietf.org/rfc/rfc3649.txt
http://www.left.org/rfc/rfc/1323.txt [20] T. Kelly, “Scalable TCP Improving Performance in High
[3] W. R. Stevens, “TCP/IP Illustrated,” The Protocols, Vol. 1, Speed Wide Area Networks,” Computer Communications
Addison-Wesley, Reading, 1997. Review, Vol. 32, No. 2, 2003, pp. 83-92.
doi:10.1145/956981.956989
[4] M. Mathew and M. Jamshidi, “Forward Acknowledgment:
Refining TCP Congestion Control,” Proceedings of the [21] K. Tang, J. M. Song, Q. Zhang and M. Sridharan, “A
ACM SIGCOMM, Vol. 26, No. 4, 1996, pp. 281-291. Compound TCP Approach for High-Speed and Long Dis-
tance Networks,” Proceedings of IEEE INFOCOM, Bar-
[5] M. Allman, V. Paxson and W. R. Stevens, “TCP Conges- celona, 23-29 April 2006.
tion Control,” RFC 2581, 1999.
www.icir.org/mallman/papers/rfc2581.txt [22] S. Liu, T. Basar and R. Srikant, “TCP-Illinois: A Loss
and Delay-Based Congestion Control Algorithm for
[6] S. Floyd and T. Henderson, “The New Reno Modification High-Speed Networks,” Proceedings of First Interna-
to TCP’s Fast Recovery Algorithm,” RFC 2582, Internet tional Conference on Performance Evaluation Method-
Engineering Task Force, April 1999. ololy Tools, 2006.
http.//www.ietf.org/rfc/rfc2528.txt
[23] L. Xu, K. Harfoush and I. Rhee, “Binary Increase Con-
[7] J. Hoe, “Start-up Dynamics of TCP’s Congestion Control gestion Control for Fast, Long Distance Networks,”
and Avoidance Schemes,” Master Theses, Massachusetts Technology Report, Computer Science Department, NC
Institute of Technology, 1995. State University, Raleigh, 2003.
[8] J, T, Wang, “The Study of Internet Congestion Control: [24] I. Rhee and L. Xu, “CUBIC: A New TCP—Friendly High
Equilibrium and Dynamics,” PhD Thesis, California Insti- Speed TCP Variant,” International Workshop on Protocols
tute of Technology, 2005. for Fast Long—Distance Networks, Lyon, 3-4 February
[9] L. Xu, K. Harfoush and I. Rhee, “Binary Increase Conges- 2005.
tion Control for Fast Long Distance Networks,” Proceed- [25] D. X. Wei, C. Jin, S. H. Low, and S. Hedges, “Fast TCP:
ings of IEEE INFOCOM, 2004. Motivation, Architecture, Algorithms, Performance,” IEEE-
[10] V. Jacobson, “Modified TCP Congestion Avoidance Algo- ACM Transaction on Networking, Vol. 14, No. 6, 2006. pp.
rithm,” Technical Report, April 1990. 1246-1259. doi:10.1109/TNET.2006.886335
[11] J. C. Hoe, “Improving the Start up Behaviour of a Conges- [26] R. King, R. Baraniuk and R. Riedi, “TCP—Africa; an
tion Control Scheme for TCP,” Proceedings of ACM Sig- Adaptive and Fair Rapid Increase Rule for Scalable TCP,”
comm, 1996, pp. 270-280. Proceedings of IEEE INFOCOM, Vol. 3, 2005, pp. 1838-
1848.
[12] K. Fall and S. Floyd, “Simulation Based Comparisons of
Tahoe, Reno and SACK TCP,” ACM SIGCOMM Com- [27] S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi and R.
puter Communication Review, Vol. 26, No. 3, July 1996. Wang, “TCP Westwood: Bandwidth Estimation for En-

Copyright © 2011 SciRes. CN

 K. I. OYEYINKA ET AL 97

hanced Transport over Wireless Links,” Mobile Computing [42] R. Srikant, “The Mathematics of Internet Congestion
and Networking, Rome, 16-21 July 2001, pp. 287-297. Control,” Birkhauser, Boston, 2004.
[28] S. H. Low and D. E. Lapsley, “Optimization Flow Control: [43] T. V. Lakshman, B. Suter and U. Madhow, “Win-
Basic Algorithm and Convergence,” IEEE/ACM Transac- dow-Based Error Recovery and Flow Control with a
tion on Networking, Vol. 7, No. 6, 1999, pp. 861-874. Slow Acknowledgement Channel: A Study of TCP/IP
[29] P. Sarolahti, M. Allman and S. Floyd, “Determining an Performance,” Proceedings of the INFOCOM’97. 16th
Appropriate Sending Rate over an Underutilized Network Annual Joint Conference of the IEEE Computer and
Path,” Computer Networks, Vol. 51, No. 7, 2007, pp. Communications Societies. Driving the Information
1815-1832. doi:10.1016/j.comnet.2006.11.006 Revolution (INFOCOM), Washington, DC, 9-11 April,
1997, p. 1199.
[30] A. O. Oluwatope, A. B. Obadire, G. A. Aderoumu and M.
O. Adigun, “End-to-End Performance of Selected TCP [44] C. Patridge, D. Rockwell, M. Allman, R. Krishman and J.
Variants Across a Hybrid Wireless Network,” Issues in In- Slerbenz, “A Swifter Start for TCP,” Technical Report
formation Science and Technology, Vol. 3, 2006. TR8339 BBN Technologies, 2002.
[31] D. Katabi, M. Handley and C. Rohrs, “Congestion Control [45] F. J. Lawas-Grodek and D. Trans, “Evaluation of Swift
for High Bandwidth-Delay Product Networks,” Pro- Start TCP in Long-Delay Environment,” Tran Glenn Re-
ceedings of the 2002 Conference on Applications, Tech- search Center, Cleveland, 2004.
nologies, Architectures, and Protocols for Computer [46] W. Allcock, S. Hedge and R. Kettimuthu, “Restricted Slow
Communications, Pittsburgh, 19-23 August, 2002. Start,” IEEE International Conference on Cluster Comput-
[32] M. Neils “Window Based Congestion Control, Modeling ing, Boston, 26-30 September, 2005.
Analysis and Design,” Doctoral Thesis, KTH, Stockholns, http://doi.ieee.computersociety.org/10/1109/cluster2005.34
2008. 7079.
[33] F. Kelly, “Changing and Rate Control for Elastic Traffic,” [47] J. Gerry, “A Comparison of PID Control Algorithm,”
European Transactions on Telecommunications, Vol. 8, Journal of Control Engineering, Vol. 34, No. 41, 1987, pp.
No. 1, 1997, pp. 33-37. doi:10.1002/ett.4460080106 102-105.
[34] S. Liu, “Primal-Dual Congestion Control Algorithms and [48] S. Seshan, M. Stemm and R. Katz, “Shared Passive Net-
E-Red AQM Scheme,” PhD Thesis, University of Illinois work Performance Discovery (SPAND),” Proceedings of
Urbana, Illinois, 2003. USITS’97, Monterey, 1-12 May, 1992.
[35] F. P. Kelly, A. K. Maulloo and D. K. H. Tan, “Rate Con- [49] R. Wang, G. Pan, K. Yamada, M. Sanadidi and M. Gerla,
trol for Communication Networks: Shadow Prices, Propor- “TCP Startup Performance in Large Bandwidth Networks,”
tional Fairness and Stability,” Journal of Operational Re- IEEE IFOCOMM, Vol. 2, 2004, pp. 796-805.
search Society, Vol. 49, No. 3, 1998, pp. 237-252. [50] D. Canvendish, K. Kumazoe, M. Tsuru and Y. Oie, “Cap-
[36] H. Yaiche and R. R. Mazumdar, “A Game-Theoretic start: An Adaptive TCP Slow Start for High Speed Net-
Framework for Rate Allocation and Charging of Elastic works,” Department of Computer Institute of Technology,
Connections in Broadband Networks,” IEEE/ACM Trans- Japan, 2009.
actions on Networking, Vol. 8, No. 5, 2000. [51] V. Padmanabhan and R. Katz, “TCP Fast Start: A Tech-
doi:10.1109/90.879352 nique for Speeding up Web Transfers,” Proceedings of
[37] T. Alpcan and T. Basar, “A Globally Stable Adaptive IEEE GLOBECOM, Sydney, 8-12 November, 1998, pp.
Congestion Control Scheme for Internet-Style Networks 41-46.
with Delay,” IEEE Wireless Communications, Vol. 12, No. [52] J. Chen, M. Zhang and Q. Meng, “A Network Congestion
6, 2005, pp. 42-49. Control Algorithm Based History Connections and Its Per-
[38] G. Vinnicombe, “On the Stability of Networks Operating formance Analysis,” Journal of Computer Research and
TCP—Like Congestion Control,” IFAC World Congress, Development, Vol. 40, No. 10, 2003, pp. 1470-1475.
Barcelona, 2002. [53] S. Floyd, “Limited Slow Start for TCP with Large Conges-
Available at http://www.eng.cam.ac.uk/gv. tion Window,” RFC3742, 2004.
[39] R. J. La and P. Ronjan, “Asymptotic Stability of a Ratio www.apps.ietf.org/rfc/rfc3742. html
Control System with Communication Delays,” IEEE Tran- [54] H. Balakrishman, H. Racheal and S. Seshan, “An Integrated
sactions on Automatic Control, Vol. 52, No. 10, 2007, pp. Congestion Manager Architechture for Internet Hosts,”
1920-1925. Proceedings of ACM SIGCOM, Cambridge, August 30-
[40] L. Ying, G. E. Dullerud and R. Srikant, “Global Stability September 3, 1999.
of Internet Congestion Controllers with Heterogeneous [55] S. Floyd, M. Allman, A. Jain and P. Sarolahti, “Quick-Start
Delays,” IEEE/ACM Transactions on Networking, Vol. for TCP and IP,” RFC 4782, 2007.
14, No. 3, 2006, pp. 579-591. www.rfc-editor.org/rfc/rfc4782.txt;
doi:10.1109/TNET.2006.876164
[56] M. Allman, S. Floyd and C. Partridge, “Increasing TCP’s
[41] F. Paganini, J. Doyle and S. Low, “Scalable Laws for Sta- Initial Wiondow,” RFC 3390, 2002.
ble Network Congestion Control,” Proceedings of the 40th www,icir.org/mallman/papers/rfc3390.txt
IEEE Conference on Decision and Control, Orlando, 4-7
December 2001, pp. 185-190. [57] M. Scharf, S. Floyd and P. Sarolahti, “TCP Flow Control

Copyright © 2011 SciRes. CN

 98 K. I. OYEYINKA ET AL

for Fast Startup,” 2009. ellite IP Networks,” Computer Communications, Vol. 31,
http://www.ietf.org/ietf/1id−abstracts.txt. No. 10, 2008, pp. 2541-2561.
[58] Z. Chen, X. Deng, L. Zhang and B. Zeng, “A New Pa- doi:10.1016/j.comcom.2008.03.029
rameter-Config Based Slow Start Mechanism,” Journal of [60] N. Hu and P. Steenkiste, “Improving TCP Startup Per-
Communication and Computer, Vol. 2, No. 5, 2005, pp. formance Using Active Measurements: Algorithm and
56-62. Evaluation,” Proceedings of the 11th IEEE international
[59] S. Utsumi, S. M. S. Zabir and N. Shiratori, “TCP-Cherry: Conference on Network Protocols (ICNP), Washington,
A New Approach for TCP Congestion Control Over Sat- DC, 30 September 2003, p. 107.

Copyright © 2011 SciRes. CN

View publication stats