Acceleration of TCP Throughput
over Satellite-basedInternet Access using TCP Gateway
Yutaka Miyake Teruyuki Hasegawa
KDD R & D Laboratories Inc.
2- 1- 15 Ohara Kamifukuoka-shi
Saitama 356-8502, JAPAN
{ miyake, teru, hasegawa, kato} @hsc.kddlabs.co.jp
Abstract
Satellite communication is able to provide wide band-
width, and satellite-based Internet access is expected to be
a high speed Internet access method of the next genera-
tion. However, the propagation delay of a satellite link de-
grades the TCP throughput. The reason for this problem
is that TCP performs window based flow control and most
communicating hosts use the default window size such as 8
Kbytes through 24 Kbytes. To deal with this problem, we
propose a TCP gateway for satellite-based Internet access.
The communication throughput of TCP is improved with-
out any modijications to equipment and terminals of sub-
scribers by introducing this system only at a satellite earth
station. In this papec we describe the protocol architecture
of the TCP gateway and its performance by comparing with
conventional methods. The results of a performance eval-
uation show that the proposed TCP gateway can provide
more than 20 times higher throughput than communication
without it over a link with 6 Mbps bandwidth and 350 msec
round trip time.
1. Introduction
In order to provide comfortable Internet access, the
bandwidth of the access line should be wide enough to
transfer a large volume of data in a short time. However,
traditional access methods using PSTN (Public Switched
Telephone Network) or ISDN (Integrated Service Digital
Network) provide only a small bandwidth, and faster ac-
cess methods are strongly expected. For this reason, high
speed access lines, such as satellite links, CATV networks
and ADSL (Asymmetrical Digital Subscriber Loop), have
been introduced recently.
Of these various methods, access by satellite link can
provide large bandwidth easily in the direction from Inter-
$10.000 2000 IEEE
0-7695-0722-O/OO
Toru Hasegawa Toshihiko Kat0
net to subscribers, and some Internet service providers have
started the internet access service using it. However, it has
the problem that the propagation delay between the sender
and receiver is increased. Since most Internet applications
use TCP (Transmission Control Protocol) as a transport pro-
tocol for reliable data transfer, this large propagation delay
influences the communication performance of those appli-
cations. TCP performs window based flow control to avoid
buffer overflow on the receiver side, and its default window
size is 8 Kbytes through 24 Kbytes in many cases. For ex-
ample, if the round trip time between a sender and a receiver
is 350 msec that corresponds to the satellite-based Internet
access, and the maximum window size for flow control is 16
Kbytes, the theoretical maximum throughput is about 365
Kbps, no matter how large the bandwidth provided.
In order to increase the communication throughput, vari-
ous enhancements for TCP have been proposed[ 11. In these
enhancements, it is thought that a window scale option[2]
which can enlarge the maximum window size to 1 Gbytes is
most effective for the satellite-based internet access. How-
ever, use of this option is not sufficient because of the fol-
lowing reasons.
0 Some operating systems have installed the window
scale option recently, but it is not expected that all
computers used as clients and servers support this op-
tion. For example, although the TCP software in Win-
dows 98 supports this option, those in Windows 95 and
Macintosh OS do not.
0 A client connected to a satellite link may know that it
needs to use a large window size, which corresponds
to the receiver buffer size. However, servers connected
to the Internet with which the client communicates do
not know that they need to use a large send buffer size,
and the send buffer size of servers was typically deter-
mined at 8 Kbyte through 24 Kbyte. Recently, some
operating systems, such as SUN Solaris 2.6, cope with
245
 this issue by using a function to enlarge the send buffer
size when a large window size is advertised in an in-
coming TCP connection. However, from a practical
point of view, it is not expected that many servers sup-
port this functionality.
In order to cope with this problem, there are some pro-
posals to introduce boosting gateways inside the network,
including our proposals[3, 4,51. These proposals suggest
introducing a pair of gateways at both ends of a long dis-
tance segment such as an international link or a satellite
link, the gateways providing an end-to-end TCP connection
establishment and a link-by-link flow control. One gateway
communicates with clients and servers according to the na-
tive TCP they are using, and communicates with the other
gateway using a larger window size and, in some cases,
more efficient retransmission mechanism such as selective
retransmission[5].
These approaches are well-suited for the case where a
backbone link has a long propagation delay, and the gate-
ways can be located at the both ends of this link. However,
in the case of satellite-based Internet access, although the
access link has a long propagation delay, each subscriber
should have an additional gateway system on his premises
to use these approaches.
This paper proposes a new approach to accelerate the
TCP throughput in satellite-based Internet access by intro-
ducing only one gateway system at a satellite earth sta-
tion. When this gateway system, called TCP gateway for
satellite-based Internet access or TCP gateway for short,
receives data (DATA) segments from a server, it replies
with acknowledgment (ACK) segments requesting follow-
ing data to the server and pushes received DATA segments
out to a satellite link using a larger window size than that ad-
vertised by clients. Although the TCP gateway violates the
flow control rule of TCP, we expect that DATA segments ex-
ceeding the advertised window size will arrive at the clients
after the clients process the “send ahead” DATA segments
one after another and send ACK segments that open the
window to receive more DATA segments in reply to them.
As a result, clients will feel as if the servers were located
near to them. In the cases where there is segment loss or
where the processing speed in clients is slower than the
rate of transmitted DATA segments, the DATA segments ex-
ceeding the upper window edge will be discarded by clients.
In order to cope with these situations, the TCP gateway in-
troduces an efficient retransmission scheme. This scheme
is designed taking account of the fact that the TCP gateway
communicates with clients using the native TCP. In sections
2 and 3, we describe the design principles and mechanism
of the proposed TCP gateway system, respectively. In sec-
tion 4,we describe the implementation and a performance
evaluation of the TCP gateway. Finally, we discuss the re-
sults in section 5.
246
2. Design principles
2.1. Overview of satellite-basedInternet access
Figure 1 shows a typical network configuration of
satellite-based Internet access. In this configuration, a per-
sonal computer (PC) at the subscriber premises receives
data from the Internet via a satellite link. Since a satel-
lite link has wide bandwidth, high speed communication is
expected. As for the reverse direction, PSTN or ISDN is
generally used, because it is difficult for each subscriber to
have transmitting equipment to the satellite. Even if satellite
communication is used in both directions, the bandwidth
from the subscriber to an earth station will be small due
to the limitation of antenna size and transmission power.
Although the bandwidth to the Internet is small, most sub-
scribers feel this type of Internet access to be comfortable
because the main purpose of Internet access is to retrieve
information from the Internet.
atellite
/
Internet -
PSTN
or
ISDN
Earth Station Subscriber Premises
Figure 1. Network Configuration of Satellite-
based Internet Access
However, the propagation delay of the satellite link is a
big problem for this network. In the case of a stationary
satellite, there is about 300 msec propagation delay. Since
TCP uses a flow control mechanism by a sliding window,
the sender should suspend transmission of data after trans-
mitting data of the window size until an acknowledgment
for the data returns from the receiver. The longer propaga-
tion delay makes this duration of suspending transmission
longer, and the communication throughput will be lower
even if the bandwidth of the satellite link is sufficiently
wide. Therefore, a mechanism to prevent throughput de-
cline due to propagation delay is required for Internet ac-
cess.
2.2. Design principles of TCP gateway for satellite-
based Internet access
This section describes design princeples of the TCP gate-
way for satellite-based Internet access.
1. The TCP gateway is located next to the router in
the earth station, as shown in figure 2. It handles
all TCP segments transmitted between servers on the
Internet side and clients on the subscriber premises
side. It maintains TCP connections established be-
tween servers and clients, and therefore, servers and
clients do not need to establish TCP connections with
the gateway, which is different from application level
gateways such as proxy or SOCKS servers[6].
llite
(3
internet
Earth Station Subscriber Premises
Figure 2. Satellite-based Internet Access us-
ing TCP Gateway
The gateway performs data transmission control, such
as the acknowledgment of DATA segments, flow con-
trol and retransmission, on a link-by-link basis. For
servers, it performs data transmission control accord-
ing to the procedures of the native TCP. For clients, it
will try to send more DATA segments than the native
TCP using the mechanisms described below. Since ac-
knowledgment of DATA segments is performed sepa-
rately, the TCP gateway retains copies of DATA seg-
ments until they are acknowledged by each side.
The TCP gateway has a maximum window size in-
ternally for data transfer to the clients on subscriber
premises. This value is determined by taking ac-
count of the bandwidth of the satellite link, the prop-
agation delay and the throughput requirement of sub-
scribers. When the TCP gateway receives DATA seg-
ments from the servers connected to the Internet, it will
forward those segments and receive ACK segments
from clients. The flow control of the data transfer from
the TCP gateway to clients uses a predetermined max-
imum window size that is independent of the window
size advertised by clients. This allows the TCP gate-
way to push out DATA segments to the satellite link.
Since the satellite link is an access link and it will be
connected to clients directly or to a LAN on subscriber
premises, we assume that congestion will not occur be-
tween the TCP gateway and PCs if the gateway sends
247
IP datagrams within the transmission rate of the satel-
lite link as described below. Therefore, the TCP gate-
way does not use the congestion control function on
the subscriber side.
When a segment loss is detected, the TCP gateway
considers that a transmission error occurred or a sub-
scriber PC could not process some DATA segments
temporarily, and the gateway will retransmit DATA
segments without invoking any congestion control al-
gorithms. As for the detection of segment losses, the
TCP gateway supports a timeout based mechanism and
fast retransmit-based mechanism similarly to the na-
tive TCP.
4. In order to avoid buffer overflow at the router con-
nected to the satellite equipment in the earth station,
the TCP gateway provides a rate control mechanism
so that the transmission rate of IP datagrams from the
gateway to the router is limited by the bandwidth of the
satellite link. This rate control is applied to the whole
IP datagram stream which may include multiple TCP
connections.
3. Detailed communication procedures of TCP
gateway for satellite-based Internet access
3.1. Normal communication sequence
Figure 3 shows a communication sequence in a satellite-
based Internet access when the TCP gateway is not used.
The communication sequence comprises three phases, i.e.,
(a) connection establishment, (b) data transfer, and (c) con-
nection release. In the data transfer phase in figure 3, after
the server on the Internet side has sent DATA segments cor-
responding to the advertised window size, it suspends trans-
ferring DATA segments until the arrival of an ACK segment
from the client on the subscriber premises side. This dura-
tion of suspending data transfer will degrade the throughput
of TCP communication here.
3.2. Communication sequence of TCP,gateway
Figure 4 shows how a communicationsequence changes
when the TCP gateway is introduced. The communication
sequence of the data transfer phase is changed to accelerate
the data transfer speed. The detailed procedures of the TCP
gateway are summarized as follows.
0 Connection Establishment Phase (a)
1. When the TCP gateway receives a SYN segment
to establish a connection, it records TCP connec-
tion information such as source and destination
 in Earth Station Client in Sewer in Earth Station Client in
Internet Side Subscriber Side Internet Side , Subscriber Side
I Satellite Link --- --4

Figure 4. Communication Sequence of TCP

Notations: Gateway for Satellite-based Internet Access
DATA p : q - datapacket.
p : sequence n u m b in TCP headn
q : (last byte sequence number + I ) in user data
SYN p - SYNflagisON.
p : sequence numbcr in TCP header Although this procedure violates the TCP spec-
FIN p - FINflagisON.
ification, it can accelerate the TCP throughput.
p : sequence numkr in TCP header
ACK r - acknowledgementpacket. Since there is a long delay in a satellite link, we
r : acknowledgementnumber in TCP hcader
expect, optimistically, that DATA segments sent
ahead of the advertised window size will arrive
Figure 3. Communication Sequence of Gen- at the receiver after the receiver sends ACK seg-
eral TCP ments that permit it to receive these DATA seg-
ments. However, if the processing speed of the
receiver is not fast enough to receive DATA seg-
IP addresses, source and destination port num- ments continuously, some of them may arrive at
bers, initial sequence number and advertised win- the receiver before it sends an ACK segment to
dow size, and forwards this segment to the other update the window for subsequent DATA seg-
side. ments. In this case, these segments will be dis-
2. If the TCP gateway receives segments for this carded by the receiver. In order to maintain high
connection, it forwards these segments until the speed communication, the TCP gateway needs to
connection phase (three-way handshake) com- minimize these DATA segment losses. There-
pletes. fore, the TCP gateway can adjust the transmis-
sion speed according to the processing speed of
0 Data Transfer Phase (b) the receiver and the bandwidth of the satellite
link.
1. When the TCP gateway receives a DATA seg- 3. The TCP gateway maintains copies of for-
ment from a sender (server on the Internet side), warded DATA segments for possible retransmis-
it generates an ACK segment for this segment in sion. When the TCP gateway receives an ACK
place of the receiver (a client on the subscriber segment from the receiver that corresponds to the
side) according to the TCP specification, and forwarded DATA segments, it deletes their copies
sends it to the sender. and discards the ACK segment.
2. The TCP gateway forwards this DATA segment 4. As for the reverse direction, the TCP gateway
to the receiver without restriction of the adver- merely forwards the received DATA segments.
tised window size specified in ACK segments Connection Release Phase (c)
from the receiver, instead using the predefined
window size as described previously. 1. When the TCP gateway receives a FIN seg-

248
 ment and corresponding connection information
is recorded, the TCP gateway forwards it to the
other side.
2. When the TCP gateway receives an ACK seg-
ment that is replying to a previously forwarded
FIN segment, it forwards this ACK segment to
the other side. At this point, one direction is
closed, and other direction is still open (TCP
half-close).
3. The TCP gateway deletes the connection infor-
mation after both directions are closed by ex-
changing FIN and ACK segments.
3.3. Error recovery procedures
When the TCP gateway detects segment losses, it must
recover those errors. This error recovery needs to be con-
sistent with TCP protocol procedures in the communica-
tion with senders (servers on the Internet side) and receivers
(clients on the subscriber premises side).
In the case where there are some segment losses between
a sender and the TCP gateway, the TCP gateway behaves as
a receiver for those segments according to the native TCP,
and makes the sender retransmit the lost segments using a
standard TCP error recovery procedure.
When some segment losses occur between the TCP gate-
way and a receiver, the TCP gateway retransmits the lost
segments. This retransmission will be performed based on
the following approaches.
0 Similarly to the native TCP, the TCP gateway supports
two types of retransmission; timeout-based retrans-
mission, and duplicate acknowledgment-based fast
retransmit[7].
0 The timeout-based retransmission is the same as that
of the native TCP. When the TCP gateway detects a
timeout while awaiting ACK segments, it retransmits
the corresponding DATA segment and the following
outstanding segments using a go-back-N algorithm.
0 The fast retransmit of the native TCP allows a
sender TCP to retransmit one missing DATA seg-
ment when three duplicate ACK segments are received
continuously[7, 81. In the case of the TCP gateway,
the predetermined window size which the gateway
uses is much larger than the advertised window size.
For example, the former is 256K bytes and the lat-
ter is 8760 bytes in our performance evaluation de-
scribed later. The DATA segments larger than the
upper window edge of the advertised window, which
are the major part of the outstanding DATA segments,
need to be retransmitted even in the case of duplicate
acknowledgment-based fast retransmit. Therefore, we
249
decided to use the go-back-N algorithm with fast re-
transmit supported by the TCP gateway. However,
this go-back-N retransmission may generate duplicate
ACK segments although there are no segment losses.
The TCP gateway needs to ignore these unnecessary
duplicate ACK segments.
0 As described in section 2.2, congestion control such
as slow start and congestion avoidance algorithms[7]
do not accompany the retransmission by the TCP gate-
way. This resolves the throughput degradation due to
the segment losses resulting from transmission errors.
The detailed processing of error recovery at the TCP
gateway may be summarized as follows.
0 In the case of timeout-based retransmission:
1. The TCP gateway measures the round trip time
with a receiver and calculates the retransmission
timeout value in the same way as the native TCP.
2. If the TCP gateway detects timeout, it starts the
error recovery process.
3. The TCP gateway retransmits the outstanding
DATA segments from the oldest unconfirmed
segment in sequence number order using a go-
back-N algorithm. It should be noted that the
multiple DATA segments may be retransmitted
at once, because the TCP gateway does not use a
slow start algorithm.
0 In the case of duplicate acknowledgment-based fast re-
transmit:
1. If the TCP gateway receives three duplicate
ACKs (ACK segments that have the same ac-
knowledgment number as a previous one) con-
tinuously, it starts an error recovery process.
2. The TCP gateway retransmits DATA segments
from the one corresponding to the duplicate
ACK. The TCP gateway uses the go-back-N al-
gorithm for this retransmission.
3. If the receiver implements a TCP that has fast re-
transmit and fast recovery algorithms[7], it saves
DATA segments following the lost segment in
its receive buffer. When the receiver receives
this retransmitted lost segment, all the segments
saved in the receive buffer will be processed and
it will expect the next new DATA segment. If
the TCP gateway retransmits all DATA segments
sequentially from the lost segment, the receiver
may send ACK segments whose acknowledg-
ment number indicates a new segment in reply
to these retransmitted DATA segments. The TCP
 gateway should not treat these ACK segments as
duplicate ACKs. Therefore, it counts the number
of DATA segments included in the receive buffer,
and it avoids detecting this number of ACK seg-
ments as duplicate ACKs.
Figure 5 describes the error recovery sequence of the sec-
ond case. In this figure, the size of a DATA segment is 1024
bytes, and the receive buffer size of the receiver of the sub-
scriber is 4096 bytes. The notation “1:1025(1024)” used in
this figure means that this is a DATA segment whose se-
quence number starts at 1 and finishes at 1024, and size is
1024 bytes. A notation “ack 2049” indicates an ACK seg-
ment whose acknowledgment number is 2049.
sewerin Earth Station
Internet Side ewG)ay-t(
- -- - -
Satellite Link
Figure 5. Sequence of Duplicate ACK-based
Fast Retransmit
DATA segments sent by a sender on the Internet are
forwarded to the receiver by the TCP gateway. In fig-
ure 5 , the third segment forwarded by the TCP gateway
(“2049:3073( 1024)”) is lost before arriving at the receiver.
When the receiver receives the fourth and subsequent DATA
segments, it sends, in response to each DATA segment,
ACK segments whose acknowledgment number is 2049. If
the receiver TCP supports a fast recovery algorithm, it saves
DATA segments within the advertised window following
the lost segment. In this example, the receiver saves data
from 3073 to 6145 in the receive buffer, and discards other
overflowing DATA segments.
The four continuous ACK segments that have the
same acknowledgment number (“ack 2049”, 0) make
the TCP gateway start retransmission of DATA seg-
ments. The TCP gateway knows that the upper win-
dow edge of the receiver just before starting retrans-
mission is 6145. While it performs the retransmis-
sion, it remembers that it has retransmitted four DATA
segments, i.e. “2049:3073( 1024)”, “3073:4097( 1024)”,
“4097:5121(1024)” and “5121:6145(1024)”, within the up-
per window edge of the receiver.
On the receiver side, when the retransmitted third seg-
ment arrives at the receiver, the three saved segments are
passed to the application, and the sequence number ex-
pected to be received becomes 6145. When the receiver re-
ceives the following three retransmitted segments, it sends
ACK segments with the same acknowledgment number
6145 (“ack 6145”). These are duplicate ACKs.
However, the TCP gateway knows that it needs to skip
four ACK segments to avoid detecting duplicate ACKs (0).
Hence, these ACK segments are not handled as duplicate
ACKs, and any additional retransmission is not performed.
Client in
The error recovery procedure between the TCP gateway
Subscriber Side and the receiver is different from that used by the native
-
TCP. However, this does not violate TCP specification, and
allows high speed communication to be maintained.
to application
(HOLE)
(saw 1024 bytcr) 4. Implementation and performance evalua-
(rave 1024 bytes)
(rave IU24 byicr) tion
(discard)
(discard)
(discard)
4.1. Implementation
-
to application)
We implemented the TCP gateway for satellite-based In-
-
(discard)
(discard)
(dixard) ternet access in order to evaluate our approach. The princi-
ples adopted for this implementation were as follows.
1. We selected a UNIX operating system (Solaris 2.6) as
a platform of the TCP gateway for satellite-based In-
ternet access.
2. Software is implemented inside a UNIX kernel using
STREAMS[9].
3. Although the TCP gateway architecture is independent
of network interfaces, two Ethernet interfaces were
used for this implementation.
4. The TCP gateway works like a network bridge, so it
does not have IP addresses at both interfaces like a
router. If a network operator wants to access the TCP
gateway through a network, it should have an another
interface that has an IP address.
Figure 6 shows a block diagram of the TCP gate-
way. This software consists of a “TCP/TCP Module”
(STREAMS Module) and “Relay Multiplexer” (STREAMS
Multiplexer). The “Relay Multiplexer” is mainly used for
relaying segments between the Internet side and subscriber
premises side. The “TCP/TCP Module” is the core of the
TCP gateway software, and consists of multiple parts.
The “TCP for Internet Side” of the “TCPKCP Mod-
ule” communicates with servers on the Internet using the
250
 Internet side, and a “Personal Computer (FTPclient)” is a
receiver on subscriber premises. “Workstation A” is con-
nected to Ethernet only when the TCP gateway is used, oth-
UNlX erwise, “Workstation B” is connected to directly to “Router
OPERATING A.” The networks between a data channel simulator and
SYSTEM
routers use a serial line (6.0 Mbps), and the other networks
use the Ethernet (10 Mbps). In order to simulate a satellite
link, the data channel simulator generates a propagation de-
Ethernet Device Driver
lay of 300 msec from the TCP gateway to the receiver and
50 msec for the reverse direction. It also generates random
bit errors by specified bit error rates. The specification of
lntemet Side Subscriber Side the equipment used for this evaluation is shown in table 1.

Data Channel Simulatoi

Figure 6. Structure of TCP Gateway Software

native TCP protocol. It manages TCP connection infor-

mation, generates and sends ACK segments, saves DATA I 650msec delav I
segments until it receives ACK segments from clients, and
recovers errors between itself and the servers. The “TCP Ethernet (10Mbps)
for Subscribers Side” communicates with clients on sub-
scriber premises. It manages TCP connection information,
forwards DATA segments, and recovers errors between it-
self and the clients.
“Traffic Shaping” parts control the data transfer speed of
output segments for both sides. The procedures adopted by --
these parts are as follows. Personal Computer
Ethernet (10Mbps)
(Fl’P Client)
1. All output segments including UDP and ICMP are the
target of traffic shaping.
2 . A tcp-fasttimo0 routine (called every 200 msec) of
TCP is used.
3. The number of maximum bytes (max-tx-byte) that the
TCP gateway is able to forward within 200 msec is Figure 7. Network Configuration for Perfor-
calculated using a transmission rate configured by a mance Evaluation
system operator.
Workstation A HW Sun Ultra 30
4. The transmission counter (tcp-tx-count) counts the to- (TCP Gateway) OS Solaris 2.6
tal number of transmitted data in byte units. Workstation B HW Sun SPARC station 5
I 1 OS I
I

(FITServer) I Solaris 2.6

5 . If the tcp-tx-count is greater than mu-tx-byte, the Personal Computer HW I Desktop PC (PI1450MHz)
TCP gateway suspends forwarding of DATA segments. (FIT Client) OS I Windows98
Router A & B Cisco 2500
6. Timer interrupts (200 msec interval) clear the Data channel simulator ADTECH SW14
tcp-tx-count to 0. If the transmission queue is not
empty at this point, the TCP gateway forwards seg-
ments in this queue.

4.2. Network configurationfor performance evalu-

ation
Figure 7 shows a network configuration used for per-
formance evaluation. This configuration assumes that a
“Workstation B” working as FTP server is a sender on the
4.3. Evaluation results
The throughput of file transfer from Workstation B (FTP
server) to the PC (FTP client) is measured in five differ-

251
 -0- Default with TCP Gateway 5. Discussions
--.c Default +J- 64K
-&- 256K + 512K
5.1. Performance improvement by TCP gateway in
6 . 0 ~
default condition
- .5
Most operating systems use 8 through 24 Kbytes as a
default receive buffer size, and that of Windows 98 is 8760
bytes. In the case of this buffer size, the theoretical maxi-
mum throughput is

I- 8760( bytes) * 8( bits/ byte)

1.
m a
v v
O.O+
10 -lo 10 -9 10 10 .?
Bit Error Rate
Figure 8. Throughput of File Transfer
Table 2. Parameters Used in Measurement
ent ways with various random bit errors (bit error rate is
lo-’’ through generated by the data channel simu-
lator. Figure 8 shows these results. The measurement con-
ditions of file transfers in the figure 8 are shown in table
2. “Default” means that there are no parameter modifica-
tions for Workstation B and Personal Computer. In this
case, the Personal Computer (Windows 98) uses 8760 bytes
as the default receive buffer size, which corresponds to the
maximum window size. In the case of “Default with TCP
Gateway”, Workstation A which executes the function of
the TCP Gateway was used. In this case the window size
used by the TCP gateway internally is 256 Kbytes. The
other cases (64K, 256K, 512K) use a larger maximum win-
dow size by configuring the receive buffer size for PC (Win-
dows 98), the send buffer size for Workstation B (Solaris
2.6), and some other parameters to enable the window scale
option[ 101. In the case of “64K’, the window scale option
is not used because the maximum value for the advertised
window size is 64 Kbytes, and the other cases (“256K’ and
“512K’) have to use the window scale option.
A detailed analysis of these results is given in the next
section.
= 0.20(Mbits/sec).
0.35(sec) * 106(bits/Mbits)
When the receiver uses the default receive buffer size
in the evaluation in section 4 (“Default”), the maximum
throughput is 0.18 Mbps. In the case where the TCP gate-
way for satellite-based Internet access is enabled using the
same default parameters in the sender and receiver, the
throughput increases up to 5.12 Mbps when the bit error
rate is 10-l’ and lo-’. This occupies about 85% band-
width of the bottleneck link. This result shows that the TCP
gateway is able to maintain high throughput without any
modifications of communication parameters.
In this case, there were some retransmitted data, because
the TCP gateway sent data ahead which exceeds the window
size advertised by receiver. However, the data retransmitted
by the TCP gateway is only 2.5% of the total of transmitted
data in this evaluation.
5.2. Comparison of TCP gateway and window scale
option
In order to compare the acceleration by the TCP gateway
and the enlargement of window size by the window scale
option, we measured the throughput using maximum win-
dow sizes of 64 Kbytes (without the window scale option),
256 Kbytes and 512 Kbytes. When 64 Kbytes is used, the
throughput is 1.37 Mbps. However, this is not sufficient for
a serial link speed of 6 Mbps. Since the bandwidth of the
bottleneck is 6 Mbps and the round trip time between the
sender and receiver is 350 msec, the bandwidth delay prod-
uct is 262.5 Kbytes (= 6.0 (Mbytes) x 0.35 (sec)). There-
fore, 256 Kbytes is the optimal window size for this network
configuration. In this case, the throughput is 3.91 Mbps
when the bit error rate is loM1’ and lo-’. This through-
put is lower than that of the TCP gateway. The behavior in
data transfer is as follows. At the beginning of data trans-
fer, the congestion window grows quickly due to the slow
start algorithm, and this causes an overflow of the buffer
of “Router A” and stops the transmission. After this buffer
overflow, the congestion window grows slowly using a con-
gestion avoidance algorithm, and there is no buffer overflow
at “Router A.” In the case of 5 12 Kbytes, on the other hand,

252
the data transfer speed becomes very low because buffer
overflows occur continuously at the congestion avoidance
stage.
This kind of problem depends on network configuration.
In this case, an overflow in “Router A” was caused because
“Workstation B” (FTP server) was connected directly via a
10 Mbps Ethernet which has wider bandwidth than the se-
rial line. However, generally speaking, the use of the win-
dow scale option increases the chances of buffer overflow
in network equipment.
5.3. Data transfer over high bit error rate link
When bit errors increase, the throughput decreases grad-
ually. In the case of the TCP gateway, because there is no
slow start and congestion avoidance after segment losses,
the throughput does not decrease very much even over a
high bit error link. On the other hand, the native TCP stops
data transfer after detecting segment losses, retransmits the
missing segments, and restarts data transfer under the con-
gestion avoidance algorithm that shrinks congestion win-
dow size. This is the reason why the throughput of “256K’
decreases rapidly with increasing bit errors compared with
“Default with TCP Gateway.”
5.4. Results with slow receivers
In the results described above, a high speed desktop PC
(with a 450 MHz CPU clock) was used as a receiver. It is re-
quired to test whether the TCP gateway works well even if a
slow personal computer is used as a receiver. Therefore, we
evaluated the performance of the TCP gateway using a note-
book type personal computer (with a Pentium 166 MHz) as
a ftp client.
The evaluation indicates that the difference of through-
put between the high speed PC (PentiumII 450MHz) and
low speed PC (Pentium 166MHz) is very small. In the case
of a low noise environment and because the
low speed PC drops some segments at the beginning of the
data transfer, the retransmitted data is about 4.7% of the to-
tal of transmitted data. Therefore, it is considered that the
TCP gateway is able to provide high performance commu-
nication even if the client is a low speed computer.
6. Conclusions
In this paper, we proposed a TCP gateway to improve
TCP communication performance in a satellite-based Inter-
net access environment. Although the satellite link has a
large bandwidth, TCP communication over it is slow be-
cause of the propagation delay and window-based flow con-
trol. The TCP gateway accelerates the throughput of TCP in
253
such networks without any modifications for sender and re-
ceiver by generating acknowledgment segments in place of
the receiver and transferring data segments with transmis-
sion rate control. The results of a performance evaluation
show that TCP communication using the TCP gateway can
provide over 20 times higher throughput than general TCP
over a 6 Mbps satellite link. Moreover, the retransmission
procedure we designed for the TCP gateway improves com-
munication performance especially in a noisy environment.
Acknowledgments
The authors wish to thank Dr. T. Muratani, President of
KDD R & D Laboratories Inc., for his continuous encour-
agement of this study.
References
[1] M. Allman, D. Glover and L. Sanchez, “Enhancing
TCP Over Satellite Channels using Standard Mecha-
nism,” RFC-2488, January 1999.
D.Borman, R. Braden and V. Jacobson, “TCP Exten-
sions for High Performance,” RFC-I 323, May 1992.
D. M. Chitre and T. Henderson, “Seamless Integra-
tion of Satellite and Terrestrial Networks,” Proc. of
ICDSC-10, pp. 220-227, May 1995.
T. Kato, K. Hokamura, M. Yamada, T. Hasegawa,
T. Hasegawa and K. Sawada, “TCP Gateway Improv-
ing Throughput of TCP/IP over Wide Area ATM Net-
works,’’ Proc. ofISS ’97, pp. 35-42, September 1997.
T. Hasegawa, T. Hasegawa, T. Kato, K. Yoshiizumi,
T. Miki, K. Hokamura and K. Sawada, “Protocol Ar-
chitecture of High Speed TCPAP Service over Inter-
national ATM Network,” Proc. of 1998 IEEE ATM
Workshop,pp. 159-168, May 1998.
M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas
and L. Jones, “SOCKS protocol version5,” RFC- 1928,
March 1996.
W. Stevens, “TCP Slow Start, Congestion Avoidance,
Fast Retransmit, and Fast Recovery Algorithms,”
RFC-2001, January 1997.
G. R. Wright and W. R. Stevens, “TCPAP Illustrated,
Volume 2,” Addison Wesley, ISBN 0-201-63354-X,
January 1995.
SunSoft, “STREAMS Programming Guide,” Novem-
ber 1995.
URL: http://www.psc.edu/networking/perf-tune.html.