formation Systems Engineering Command
Ft. Huachuca, AZ
ABSTRACT
This paper describes the use of a transparent TCP
gateway to improve the performance of applications
operating in a shared secure satellite environment.
Typically, a satellite gateway is installed at each end of the
satellite link, and the Control-in-Shared-Satellite-Environments/' >gateways process all traffic
traversing the link. With the proliferation of virtual
private network (VPN) technologies, multiple encrypted
tunnels can be established over a satellite link. If
transparent TCP Control-in-Shared-Satellite-Environments/' >gateways are used to optimize
application performance, a pair of Control-in-Shared-Satellite-Environments/' >gateways are required
at the egress points of each tunnel. Many TCP Control-in-Shared-Satellite-Environments/' >gateways
perform poorly in this situation because they do not
implement congestion control on their satellite sides,
instead relying mainly on rate-control to send data at or
near the bandwidth capacity of the satellite link
Our approach is to use Space Communications Protocol
Standards (SCPS) transparent transport layer Control-in-Shared-Satellite-Environments/' >gateways,
which are capable of implementing a variety of congestion
control schemes on their terrestrial and satellite sides. By
using a variant of the TCP Vegas congestion control
algorithm, the Control-in-Shared-Satellite-Environments/' >gateways can communicate indirectly (by
detecting changes in packet round-trip times) to efficiently
share the satellite bandwidth. Results show that this
improves performance over end-to-end TCP without
congesting the network between the Control-in-Shared-Satellite-Environments/' >gateways and the
uplink as pure rate-control would do.
INTRODUCTION
A. TCP In Satellite Environments
Transmission Control Protocol (TCP) [1] is the Internet
transport protocol that supports many common
applications, including e-mail, ftp, http, and telnet. TCP
provides reliable, in-order delivery of data from sending to
receiving applications, without duplications. That is, TCP
guarantees that all data sent will arrive at the destination,
the data will be delivered to the destination application in
the order in which it was sent, and that no duplicate data
will be delivered to the receiver. TCP achieves reliability
by having TCP receivers acknowledge data sent to them.
If a TCP sender does not receive an acknowledgement for
a particular piece of data, it will retransmit it until the data
gets to the receiver.
In addition to the services described above, modern TCPs
are also required to implement congestion control
mechanisms [2, 3]. Congestion control prevents senders
from flooding the network with data to the point that
intermediate routers have no buffers left and have to
discard data, which TCP will then have to retransmit. For
example, when a TCP session begins, the sender first
sends one packet to the destination and waits for a
response. TCP then sends two packets before waiting for a
response, and so on. This exponential growth phase is
called slow-start, and its purpose is to allow TCP to
quickly determine the available bandwidth on the path to
the destination. At some point, the sending TCP reaches
the flow control limit imposed by the receiver or it causes
a router buffer to overflow, resulting in data loss. If the
flow control limit imposed by the receiver is reached,
transmission continues at that limit until a loss occurs.
When a loss occurs, the receiving TCP will indicate it to
the sender, who then retransmits the lost segment(s). In
addition to retransmitting the lost segments, the sending
TCP cuts its transmission rate in half, after which it
increases it again linearly, at the rate of one extra TCP
segment per round trip. Thus TCP's transmission rate
grows linearly in this congestion avoidance phase, as
opposed to exponentially as in the slow-start phase. It is
worth noting here that the description above is for the
Reno implementation of TCP/IP, which is the most widely
used and implemented version of TCP/IP. The congestion
control algorithm is known as Van Jacobson congestion
control.
Unfortunately, TCP Reno does not perform well on high-
delay, lossy satellite links. The default TCP window size
on most common operating systems varies between 8 and
32 kilobytes (KB). Ideally the window size should be set
to the bandwidth*delay product (BDP) of the channel,
where the delay is the round-trip time. For 2
geosynchronous satellite links, the round trip time
(including processing time) can exceed 600 milliseconds.
Depending on the bandwidth of the channel, it is common
for terminals to become window limited (BDP exceeds
configured TCP window size), resulting in a sending
terminal having to stop transmission until
acknowledgements (ACKs) are received so the sliding
window can be advanced. Thus the sending terminal
operates in a stop and go manner, which results in an
under utilized transmission link.
If a datagram is corrupt, TCP assumes the link is
congested, retransmits the lost datagram, and backs off its
transmission rate. Unfortunately, reducing the
transmission rate on an uncongested satellite link results in
degraded performance. The congestion avoidance
algorithm allows the sending terminal to grow linearly to
its pre-loss data rate. Unfortunately, the rate of growth is
paced by the ACK traffic, which must traverse a high
delay satellite link before reaching the sender. Thus the
recovery rate for satellite links is much slower than
terrestrial links, resulting in reduced throughput.
A number of TCP options have recently been developed
and widely deployed to increase performance over long fat
networks [4, 5], and research in the area of satellite
networks is ongoing [6].
B.
Split-TCP Gateways
Transport layer Control-in-Shared-Satellite-Environments/' >gateways can improve TCP performance
across stressed environments by breaking the end-to-end
TCP connection into multiple transport layer connections.
Figure 1 shows an illustration of this concept, where the
transport connections are split into three pieces. In Figure
1, each gateway translates between two transport layer
protocols, using one to communicate with end hosts and
another to communicate with the peer gateway. To see
how this can improve performance, recall that the
receiver's receive window needs to be at least the BDP of
the network in order for the sender to fully utilize the
network resources. Since most end host TCPs have their
window sizes set for the BDP of terrestrial connections,
they can significantly under-utilize the communications
resources when communicating through a geosynchronous
satellite. A pair of TCP Control-in-Shared-Satellite-Environments/' >gateways at the ground stations
could terminate the terrestrial communications and
implement the large windows TCP option [4] to increase
the window size over the satellite hop.
TCP
TCP
Inter-Gateway Protocol
Application
TCP
IP
Application
TCP
IP
TCP
IP
Transport
Network
TCP
IP
Transport
Network
Gateway
Gateway
Figure 1. A Split-TCP Connection over a Satellite Channel
Most inter-gateway protocols are a modified TCP stack
running on top of IP at the network layer. Typical gateway
implementations use a pure rate-control strategy to keep
the satellite channel full. Pure rate-control introduces
traffic onto the satellite link at a specified rate (commonly
the rate of the satellite link). The BDP on the satellite side
of the Control-in-Shared-Satellite-Environments/' >gateways is tuned for the satellite link. It is also
assumed that a single pair of Control-in-Shared-Satellite-Environments/' >gateways at either end of the
satellite link will process all the traffic. Generally, all loss
is assumed due to corruption and not congestion, therefore
Control-in-Shared-Satellite-Environments/' >gateways will not back off their rate of transmission when
loss is encountered. Gateways are usually designed to be
transparent to the host systems. Normal default window
sizes, etc., on the host systems are sufficient for proper
gateway functioning. For networks where a single pair of
Control-in-Shared-Satellite-Environments/' >gateways can process all traffic at the egress points of the
satellite link, current gateway implementations will
provide significant TCP throughput enhancement over a
standard end-to-end TCP connection.
THE PROBLEM
Satellite Control-in-Shared-Satellite-Environments/' >gateways may not work well when they dont
process all traffic entering and leaving a satellite link. One
example is when traffic is segregated using virtual private
networks (VPNs). VPNs are typically an incorporation of
tunneling, authentication, and encryption technologies.
TCP Control-in-Shared-Satellite-Environments/' >gateways will interoperate with VPN devices, but
they must be installed on the link prior to entering an
encrypted tunnel. There are two reasons for this:
The Control-in-Shared-Satellite-Environments/' >gateways must see the original IP and transport
headers in order to terminate a TCP connection with a
local host.
The devices installed on the tunnel-side of the VPN
device are normally prevented from communicating
with devices on the non-tunneled side of the VPN
device.
Satellite Internet service providers and very small aperture
terminal (VSAT) IP data service providers have developed
a number of gateway architectures and inter-gateway
protocols. Many of the inter-gateway protocols rely
heavily on pure rate control to send data across the satellite
hop; they do not implement congestion control on their
satellite sides. This can pose difficulties if multiple
independent Control-in-Shared-Satellite-Environments/' >gateways are connected to a single satellite 3
uplink ground station, say through a common router. In
these cases either:
1. The bandwidth of the satellite link can be
partitioned a priori between the various Control-in-Shared-Satellite-Environments/' >gateways
so that even if all of them are transmitting at their
full rates, they do not overrun the uplink
2. The various Control-in-Shared-Satellite-Environments/' >gateways need to communicate
amongst one another to coordinate their
transmission rates so as not to overrun the uplink
3. If each gateway