IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 9, NO. 3, JUNE 2001 307
TCP-Peach: A New Congestion Control Scheme for
Satellite IP Networks
Ian F. Akyildiz, Fellow, IEEE, Giacomo Morabito, and Sergio Palazzo, Member, IEEE
Abstract—Current TCP protocols have lower throughput
performance in satellite networks mainly due to the effects of long
propagation delays and high link error rates. In this paper, a new
congestion control scheme called TCP-Peach is introduced for
satellite networks. TCP-Peach is composed of two new algorithms,
namely Sudden Start and Rapid Recovery, as well as the two
traditional TCP algorithms, Congestion Avoidance and Fast
Retransmit. The new algorithms are based on the novel concept
of using dummy segments to probe the availability of network
resources without carrying any new information to the sender.
Dummy segments are treated as low-priority segments and
accordingly they do not effect the delivery of actual data traffic.
Simulation experiments show that TCP-Peach outperforms other
TCP schemes for satellite networks in terms of goodput. It also
provides a fair share of network resources.
Index Terms—Congestion control, high bit error rates, long
propagation delays, satellite networks, TCP protocols.
I. INTRODUCTION
B
OTH experimental and analytical studies [30] confirm that
the current TCP protocols have performance problems in
networks with long propagation delays and relatively high link
error rates such as satellite networks [37], [33], [6]. From the
view of TCP, the throughput is reciprocal to the round-trip time
(RTT) of a connection, and is approximately proportional to the
congestion window (
) which represents the amount of un-
acknowledged data the sender can have in transit to the receiver
[39].
In satellite networks,TCPthroughputdecreases because [37],
[33], [6]:
• the long propagation delays cause longer duration of the
Slow Start phase during which the sender may not use the
available bandwidth;
• the TCP protocol was initially designed to work in net-
works with low link error rates, i.e., all segment losses
were mostly due to network congestions. As a result, the
sender decreases its transmission rate each time a seg-
ment loss is detected. This causes unnecessary throughput
degradation if segment losses occur due to link errors, as
it is likely in satellite networks.
Manuscript received August 1, 2000; revised December 27, 2000; approved
by IEEE/ACM T
RANSACTIONS ON NETWORKING Editor B. Vaduvur. The work
of I. F. AkyildizandG.Morabitowas supported by NASA-Ames under Contract
NAG 2-1262.
I. F. Akyildiz and G. Morabito are with the Broadband and Wireless Net-
working Laboratory, School of Electrical and Computer Engineering, Georgia
Institute of Technology, Atlanta, GA 30332 USA (e-mail: ian@ee.gatech.edu;
giacomo@ee.gatech.edu).
S. Palazzo is with Dip. di Informatica e Telecomunicazioni, University of
Catania, 95125 Catania, Italy (e-mail: palazzo@iit.unict.it).
Publisher Item Identifier S 1063-6692(01)04730-6.
In [5], the TCP standard mechanisms are identified which
provide the best performance in satellite networks. However, to
our knowledge, these identified problems are still not solved to
date [37].
In thispaper,we introduce TCP-Peach, a newcongestion con-
trol scheme for satellite networks which is an end-to-end so-
lution to improve the throughput performance in satellite net-
works.
The paper is organized as follows. In Section II, we present
the problems of TCP in satellite networks and the related work.
We introduce TCP-Peach in Section III and describe its behavior
in Section IV. In Section V,we evaluate the performance of TCP-
Peach through simulation. Finally, in Section VI, we conclude
the paper.
II. TCP I
SSUES IN SATELLITE NETWORKS AND RELATED WORK
A. Slow Start Issues in Satellite Networks and Related Work
In the beginning of a new connection, the sender executes
the Slow Start algorithm to probe the availability of bandwidth
along the path [27]. The time required by the Slow Start to reach
a bit rate
is [37]
(1)
where RTT is the round-trip time and
is the average packet
length expressed in bits. Equation (1) is satisfied if the Delayed
ACK Option [13] is not implemented, i.e., the receiver sends one
acknowledgment (ACK) for each received segment. In Table I,
we give the duration of the Slow Start phase for different types
of satellites, i.e., Low Earth Orbit (LEO), Medium Earth Orbit
(MEO) and Geosynchronous Earth Orbit (GEO) satellites, and
for different values of
, when kB, which is a common
value for segment size.
If the delayed ACK mechanism [13] is implemented, i.e., the
receiver sends one ACK for each two received segments, then
the time required by the Slow Start to reach the bit rate
be-
comes even higher than indicated in Table I. For the sake of
simplicity, in the following we assume that the delayed ACK
mechanism [13] is not implemented.
Many actual TCP applications, like HTTP, are based on the
transfer of small files. Thus, it can happen that the entire transfer
occurs within the Slow Start phase. In other words, it is pos-
sible that a TCP connection is not able to utilize all available
resources in the network.
To cope with the performance problems of the Slow Start
algorithm in long propagation delay networks such as satellite
networks, there have been several proposed solutions in recent
years.
1063–6692/01$10.00 © 2001 IEEE
308 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 9, NO. 3, JUNE 2001
TABLE I
D
URATION OF THE SLOW START PHASE FOR LEO, MEO,
AND GEO SATELLITES
• Increasing Initial Window (IIW) [4]. The congestion
window
1
is initially set to a value larger than 1
but lower than 4, i.e.,
. With this option,
values reported in Table I can be reduced by up
to
which can still be very high.
• TCP Spoofing [29], [10]. A router near the source sends
back ACKs for TCP segments in order to give the source
the illusion of a short delay path. TCP spoofing improves
throughput performance but has some problems [37]:
Problem 1: The router must do a considerable amount
of work because it becomes responsible for the correct
delivery of the TCP segments it acknowledges to the
source.
Problem 2: Spoofing requires ACKs to flow through the
same path as data. On the contrary, in Internet it is very
common that ACKs flow through a different path than
data.
Problem 3: If the path changes or the router crashes,
data may get lost.
Problem 4: If IP encryption is used, the scheme cannot
be applied.
• Cascading TCP or Split TCP [7]. TCP connection is
divided into multiple connections. This solution has the
same problems as TCP spoofing with the exception of
Problem 2 [37].
• Fast Start [36]. The Fast Start algorithm, alternative to
the Slow Start algorithm, is introduced for Web transfers
in [36]. The basic idea of the Fast Start is to reuse the
values of the transmission rate from the recent past. How-
ever, the transmission rate used in the past might be too
high for the current actual network condition, which may
lead to congestion in the network. Thus, the TCP seg-
ments transmitted during this Fast Start period are carried
by low-priority IP packets so that the throughput of ac-
tual data segments treated as high-priority segments will
not be decreased. Note that one of the eight bits of the
Type of Service (TOS) field—now renamed Differentiated
Service (DS) field—in the IP header specifies the priority
of the packet [38], whereas more recent IP implementa-
tions aimed to support the Differentiated Service Model
(DiffServ) can define several priority levels. Experiments
in [36] show the effectiveness of the Fast Start algorithm
compared to Slow Start. However, the Fast Start has the
following problems:
Problem 1: The transmitted low-priority segments carry
new information to the receiver, thus, they are still data
segments, and if they are lost, then they must be recov-
1
In the following, we consider the segment as the unit of data.
ered. Since these low-priority data segmentsmay be lost
easily, the sender needs to enhance its recovery algo-
rithms [36].
Problem 2: Fast Start can be used only if a recent value
of the congestion window for the same path is available
at the sender. This requires that within a short time the
same server (sender) transfers several files to the same
user (receiver), which may often not be the case.
B. Error Rate Issues in Satellite Networks and Related Work
TCP was initially developed for wireline networks where the
link error rate is low, such that the majority of the segmentlosses
is due to network congestions. Thus, the sender assumes that
all segment losses are caused by congestions and accordingly it
decreases its transmission rate.
Although the application of forward error correction (FEC)
algorithms can increase the reliability of satellite links, satellite
networks have several orders of magnitude higher error rates
than the wireline networks [2], [37]. As a result, we cannot ig-
nore the errors in satellite links and assume that all segment
losses occur due to congestions. This assumption may lead to
drastic and unnecessary decrease in resource utilization [2], [8],
[9], [16], [18], [20], [24], [37].
This problem could be solved if TCP could distinguish
whether segment losses occur due to network congestion or due
to link errors [20]. However, this is currently infeasible [37].
In [3], the authors suggest to decouple error and congestion
control. TCP would thenbe responsible onlyfor congestion con-
trol while the error control is handled by the link layer. However,
this solution is impractical because the link layers of all subnet-
works composing the Internet need to be redesigned.
An alternative solution is that the sender could contain an
algorithm which can distinguish between congestion and errors.
However, such an algorithm must be very reliable. In fact, if
this algorithm does not respond correctly to an actual network
congestion, the network utilization decreases drastically [37].
To our knowledge, such a reliable algorithm does not exist to
date.
III. TCP-P
EACH
TCP-Peach contains the following algorithms: Sudden Start,
Congestion Avoidance, Fast Retransmit, and Rapid Recovery,
as highlighted in Fig. 1. The Congestion Avoidance and
Fast Retransmit algorithms may be those proposed either in
TCP-Reno [28] or by TCP-Vegas [14], [15], [1]. Sudden Start
and Rapid Recovery are the new algorithms and are presented
in Sections III-B and III-C, respectively. The new algorithms
AKYILDIZ et al.: TCP-PEACH: NEW CONGESTION CONTROL SCHEME FOR SATELLITE IP NETWORKS 309
Fig. 1. TCP-Peach scheme.
are based on the use of dummy segments, which are explained
in Section III-A.
A. Dummy Segments
Dummy segments are low-priority segments generated by the
sender as a copy of the last transmitted data segment, i.e., they
do not carry any new information to the receiver.
The sender uses the dummy segmentsto probe the availability
of network resources. If a router on the connection path is con-
gested, then it discards the IP packets carrying dummy segments
first. Consequently, the transmission of dummy segments does
not cause a throughput decrease of actual data segments, i.e.,
the traditional segments. If the routers are not congested, then
the dummy segments can reach the receiver. The sender sets one
or more of the six unused bits in the TCP header to distinguish
dummy segments from data segments. Therefore, the receiver
can recognize the dummy segments and acknowledge them to
the sender. The ACKs for dummy segments are also marked
using one or more of the six unused bits of the TCP header and
are carried by low-priority IP segments. This requires simple
modification of the receiver implementation. The sender inter-
prets the ACKs for dummy segments as the evidence that there
are unused resources in the network and accordingly, can in-
crease its transmission rate.
The TCP-Peach sender can verify whether the receiver imple-
ments the required modification during the Sudden Start. If the
required modification is not implemented, TCP-Peach sender
stops transmitting dummy segments, i.e., TCP-Peach behaves
like TCP-Reno [28].
In the following sections we show that the ACKs for the
dummy segmentstransmitted during the Sudden Start and Rapid
Recovery are received during the Congestion Avoidance phase.
Consequently, the Congestion Avoidance is modified in TCP-
Peach.
We introduce the variable
. Upon receiving an ACK for
a dummy segment, the sender checks the value of
. Then:
•If
, then the congestion window is in-
creased by one, i.e.,
.
Fig. 2. TCP-Peach:
Sudden St art
()
Sudden Start
()
Sudden Start
()
:
•If , then the value is decreased by one,
i.e.,
, and the congestion window value
remains the same.
The variable
is used in order to match the behaviors of
TCP-Peach and TCP-Reno [28] when the network is congested,
i.e., this guarantees that TCP-Peach is TCP-friendly [23]. In the
beginning of a new connection,
is set to zero.
TCP-Peach requires that all routers in the connection path
support some priority discipline. In traditional IP networks, the
IP TOScan be used for this purpose [38]. In fact, one of the eight
bits of the TOS field in the IP header gives the priority level of
the IP packet [38]. Instead, more recent IP versions, e.g., IPv6
[19], explicitly provide several priority levels.
Currently, some routers in the Internet do not apply any pri-
ority policy. However, in the near future, the Internet will sup-
port quality of service through the DiffServ [11], which requires
all routers to support multiple service classes. As a matter of
fact, all recent commercial routers, e.g., Cisco series 7000 and
12 000 [17], support at least the IP TOS.
Low-priority segments are used in [12] to measure the avail-
able bandwidth in the network to conduct admission control.
Low-priority segments are also used in [36] to improve the
performance of TCP. However, the low-prioritysegmentsin [36]
are different from the dummy segments because:
1) They are not used to probe the availability of network
resources. In fact, their objective is to carry information
to the receiver more rapidly without harming other flows.
2) Since they carry new information to the receiver, they are
still data segments, and if they are lost, then they must be
recovered.
3) They are used only in the beginning of a new connection.
B. Sudden Start Algorithm
The Sudden Start substitutes the Slow Start [27] in Fig. 1.
Let
, whichis specified by the receiver, be the maximum
value for the congestion window
. As shown in Fig. 2,
the basic idea of the Sudden Start is that in the beginning of
a connection, the sender sets the congestion window
to 1
and after the first data segment, it transmits
dummy
segments every
(2)
As a result, after one
, the congestion windowsize
increases very quickly. Note that the sender can estimate RTT
during the connection setup phase.
Now we explain the Sudden Start algorithm in detail.
310 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 9, NO. 3, JUNE 2001
Fig. 3. Comparison between TCP-Peach and TCP-Reno in the beginning of a new connection.
Suppose that a new TCP connection begins at time .
•
:
The sender transmits a data segment first and
dummy segments, in such a way that
the data and dummy segment transmissions are uniformly
distributed in an interval equal to
. Then, it executes
the Congestion Avoidance.
•
:
The ACKs related to the data and dummy segments
transmitted in the time interval
arrive at
the sender. Since
, for any received ACK re-
lated to a dummy segment, the sender increases its
by 1 and transmits a new data segment. In this period, the
data segments are transmitted at the same rate,
,of
the ACK arrivals. Note that
is approximately
(3)
where
is the maximum achievable rate with the currently
available bandwidth and
is given in (2). As a result, at
time
, the transmission rate of the sender jumps
suddenly from
one segment to . Note that
if the receiver does not implement the modifications re-
quired by the TCP-Peach scheme, then the ACKs for the
dummy segments will not arrive in the expected format. If
this is the case, the sender stops transmitting dummy seg-
ments and starts to use the TCP-Reno [28].
•
At this time, the ACK related to the last transmitted
dummy segment is received by the sender, i.e., the Con-
gestion Avoidance continues as in [28].
In Fig. 3 we compare the TCP-Peach (solid lines) and the
TCP-Reno (dashed lines) in the beginning of a new connec-
tion. In the upper plot, we show the behavior of the conges-
tion window
dependent on time . The time unit consid-
ered in Fig. 3 is set equal to
. In the bottom plot, we show
, which is the number of acknowledged data segments
in the time interval
. These plots were obtained by consid-
ering the
equal to 64 segments. It can be seen that the
Sudden Start reaches
(64 segments) much earlier than
the Slow Start algorithm. Moreover, it can also be seen in the
bottom plot that the Sudden Start algorithm delivers data seg-
ments much faster than the Slow Start.
C. Rapid Recovery Algorithm
The Rapid Recovery substitutes the classical Fast Recovery
algorithm [28] with the objective of solving the throughput
degradation problem due to link errors highlighted in Sec-
tion II-B.
As shown in Fig. 1, when a segment loss is detected through
duplicate ACKs, we use the original Fast Retransmit al-
gorithm [28]. After completing the Fast Retransmit algorithm,
we apply the Rapid Recovery algorithm, as in Fig. 4, which will
terminate at the time,
, when the ACK for the lost data seg-
ment is received, as shown in Fig. 5. Consequently, the Rapid
Recovery lasts for
. Then, the sender will enter the Con-
gestion Avoidance phase as depicted in Fig. 1.
The Rapid Recovery first keeps the classical Fast Recovery
conservative assumption that all segment losses are due to net-
work congestion because the TCP layer does not know anything
about the exactcauses for the losses, i.e., due to network conges-
tion or due to link errors [37]. Accordingly, the sender halves its
congestion window
, as in TCP-Reno [28]. Thus, if
AKYILDIZ et al.: TCP-PEACH: NEW CONGESTION CONTROL SCHEME FOR SATELLITE IP NETWORKS 311
Fig. 4. TCP-Peach:
Rapid Rec ove r y
()
Rapid Recovery
()
Rapid Recovery
()
.
was equal to , then it becomes , which
means that the sender will transmit approximately
data segments during the Rapid Recovery phase.
Moreover, in order to probe the availability of network
resources, the sender transmits a certain number
of
dummy segments. Note that the value for
will be
derived in the following. The ACKs for the dummy segments
will be received after the ACK for the lost data segment,
i.e., they will be received when the sender is in Congestion
Avoidance phase, as shown in Fig. 5.
If the segment loss is due to congestion, then the congested
router can serve
segments per round-trip time, approxi-
mately. As a result, the network will accommodate the
data segments, which have high priority, and dummy
segments out of the
dummy segments transmitted
during the Rapid Recovery phase.
Therefore, the sender must not increase its congestion
window
when it receives the first ACKs for
dummy segments. In fact, these ACKs cannot be considered
as the sign that the loss was due to link errors, i.e., not due
to network congestion. With this objective,
is set to
, i.e., , in Fig. 4. This will prevent
the sender to increase its congestion window when the first
ACKs for dummy segments are received during the
Congestion Avoidance.
After receiving
ACKs for dummy segments, the
sender increases its congestion window
by one segment
each time it receives an ACK for a dummy segment.
We set
equal to . As a result, if all dummy
segments are ACKed to the sender, then the congestion window
reaches the value it had before the segment loss was de-
tected, i.e.,
.
Note that the retransmitted segment may get lost. Let
be the time when the lost segment is retransmitted. If at time
, no ACK has been received for the retransmitted
segment, then this segment may be lost. Accordingly, the Rapid
Recoveryis terminated and the sender executesthe Sudden Start
because the loss may be due to heavy network congestion.
Now we explain the Rapid Recovery Algorithm, shown in
Fig. 4, in detail. In the beginning, the sender sets some variables:
•
.
•
.
The variable, allowed dummy segment number (
),
is the number of dummy segments that the sender is al-
lowed to inject into the network. Initially, the sender sets
adsn equal to
which is given by
(4)
•
.
•
.
The sender can artificially inflate the congestion
window
during the Rapid Recovery phase. The
variable
gives the amount that was
inflated.
•
The variable is set equal to the current time, .
Note that
is approximately the time when the lost
data segment has been retransmitted.
•
The variable is a Boolean. When ,
the Rapid Recovery terminates. The sender initializes
.
Then, until the end of the Rapid Recovery algorithm, upon
receiving an ACK for a data segment
,
the sender artificially inflates
by 1 and then checks
whether it can transmit a new data segment or not. If it cannot,
i.e., if
is lower than or equal to the amount of unac-
knowledged data segments,
,( ),
then the sender checks the
value. If , then
the sender transmits two dummy segments and decreases the
value of adsn by two. Finally, when the lost data segment is
acknowledged
, is reduced by
the amount it was artificially inflated before,
, i.e.,
, is set to 0, the Rapid
Recovery phase is completed (
) and the Congestion
Avoidance is executed. The arrival of an ACK for a dummy
segment
is treated such as the ACK of
data segments, but the congestion window,
, is inflated
