TCP/IP Over Satellites

Kofi Weusi-Puryear
Sridhar Dhulipala
Sanjay Jain
Tejaswi Redkar

SJSU, CMPE 206, Spring 1998

Why TCP/IP over satellite?

Ease of installation, remote accessibility, and low
cost of running/maintenance.
Useful for areas or countries that have little
terrestrial infrastructure.
Mobility of the devices; ease of adding/removing
subsystems
Applications:
Internet connectivity.
Telecom industries (pagers, cell phone,
wireless modem..)
Defense

Disadvantages:
Long delay, especially in geosynchronous systems
High probability of bit errors.

Objectives:

Highlight TCP/IP performance issues with improvements/suggestions

The following mechanisms(current and proposed are discussed):
Path-Maximum Transmission Unit (MTU) discovery and Forward Error Correction (FEC)
Selective Acknowledgements
Congestion Control using slow start, congestion avoidance, fast transmit and fast recovery algorithms.
TCP window size.

Path-MTU discovery
A non-TCP mechanism, uses Internet Control Message
Protocol (ICMP)
MTU: limit on the maximum datagram size on a network
media.
Path MTU discovery: Maximum packet size on a network
path without IP packet fragmentation.
Allows TCP to use the largest possible packet size, without
incurring the cost of fragmentation and reassembly.
Disadvantage: may cause a long pause before TCP is able
to start sending data.
In practice, not very time consuming due to wide support
of common MTU values.

Forward Error
Correction(FEC)
Sender adds repair data to a media stream so packet
loss can be repaired by the receiver.
Repair data can be media specific or media independent.
Media specific: Employs knowledge of a media
compression scheme.
+ Low latency. Only a single-packet delay being added. Suitable for
interactive applications which require low end to end delays.
- Complex encoding/decoding slows sender & receiver

Media independent:
+ Uses parity based FEC, simplified encoding/decoding
- High latency (due to more lost packets).

Selective
Acknowledgements
(SACKs)
Recently approved extension to TCP.
Makes it possible for TCP to acknowledge data received
out of order.
Previously TCP had only been able to acknowledge data
received in order. This could lead to needless
retransmissions, in case the sender transmits out of order.
Improves the efficiency of TCP retransmissions by reducing
the retransmission period.
Helps TCP better evaluate the available path bandwidth in
a period of successive losses and avoids doing a slow
start.

TCP Congestion Control

Mechanisms
TCPs start a connection with the sender injecting multiple
segments into the network, up to the window size advertised by
the receiver.
Problem with this Approach ?
Congestion at an intermediate router (which causes packets to be
discarded) can reduce the throughput of a TCP connection drastically.

To avoid generating an inappropriate amount of network traffic

TCP employs four congestion control mechanisms. These
algorithms are slow start, congestion avoidance, fast retransmit
and fast recovery
TCP uses two variables to accomplish congestion control.
The first variable is the congestion window (cwnd): The amount of
data the sender can inject into the network.
The second variable is the slow start threshold (ssthresh) which is
used to decide which algorithm is to be used.

Slow Start Algorithm

When a host begins sending data on the network it is required to use
the slow start algorithm at the beginning of the transfer.
Slow start begins by initializing cwnd to 1 segment (i.e., the segment
size announced by the other end, or the default, typically 536 or 512
bytes).
This forces TCP to transmit one segment and wait for the
corresponding ACK.
For each ACK that is received, the value of cwnd is increased by 1
segment.
For Example after the first ACK is received the cwnd will be 2
segments and the sender will be allowed to transmit 2 data packets
This continues until either the cwnd reaches the maximum window
size or packet loss is detected.

Congestion Avoidance
Congestion avoidance algorithm deals with packet loss which
occurs due to congestion of the network.
In the congestion avoidance mode the cwnd is increased only one
segment at a time until the max window size is reached.
When congestion occurs (indicated by a timeout or the reception of
duplicate ACKs), one-half of the current window size is saved in
into the ssthresh .
If cwnd <= ssthresh, TCP is in slow start; otherwise TCP is
performing congestion avoidance.
Congestion avoidance and slow start are independent algorithms
with different objectives, but in practice are always implemented
together. The following diagram explains how the algorithms work
together.

Slow Start and Congestion

Avoidance combined
implementation.

Slow Start and Congestion

Avoidance (Summary)
The TCP protocol reacts to packet loss by using Slow
Start and Congestion Avoidance because it assumes
there is network congestion.
The above method works well for shared networks,
but not for wireless networks (for example Satellite
links) where the cause of the problem could be due to
bit errors. The solution for bit errors is retransmission.
Therefore the Slow Start and Congestion Avoidance
Algorithms do not enhance the TCP performance over
Satellite links, but are required in case of a network
collapse.

Fast Retransmit and Fast

Recovery
Found in many Unix variants of TCP for
several years.
Not documented as a Standards Track
TCP mechanism until Stevens in 1997
(RFC 2001).
TCP Reno does use Fast Retransmit
and Fast Recovery.

Fast Retransmit
TCP's default mechanism to detect
dropped segments is the retransmission
timeout (RTO) based on observations of
the Round-Trip Timeout.
TCP ACKs always acknowledge the
highest in-order segment that has
arrived. If a segment arrives out-oforder the ACK triggered will be for the
highest in-order segment, rather than
the segment that just arrived. Thus the
receiver is going to send a duplicate
ACK if a segment is lost.

Fast Retransmit (continued)

The fast retransmit algorithm uses
these duplicate ACKs to detect lost
segments.
If 3 duplicate ACKs arrive at the data
originator, TCP assumes that a
segment has been lost and
retransmits the missing segment
without waiting for the RTO to expire.
Thus Fast Retransmit reduces the time
it takes a TCP sender to detect (and
react to) a single dropped segment.

Fast Recovery
After a segment is resent using fast
retransmit, the fast recovery
algorithm is used to adjust the
congestion window.
Fast recovery halves the segment
sending rate and begins congestion
avoidance phase immediately,
skipping slow start.
By skipping slow start Fast Recovery
reduces wasting satellite pipe
bandwidth.

Fast Retransmit and Recovery

(continued)

When multiple segments are lost in a given

window of data, only one of the segments will
be resent using Fast Retransmit. The rest of the
dropped segments must wait for the RTO to
expire, which causes TCP to revert to slow start.
TCP knows that packets are still flowing through
the network when retransmitting due to
duplicate ACKs. However, when resending a
packet due to a the expiration of the RTO, TCP
cannot infer anything about the state of the
network and therefore must proceed
conservatively by using the slow start
algorithm.

Delay and Window Size

One of the limiting factors for throughput is the delay of a

connection.
TCP is designed as a sliding window protocol, hence, a fixed
maximum amount of data (receive window size) is on the link
between sender and receiver as shown in the figure below.

As a consequence the maximum throughput is limited by the Round

Trip Time (RTT) of the link:
throughput(max) = receive buffer size/round trip time
If this equation is rearranged to
round trip time x throughput <= receive buffer size
one will get the condition for the delay bandwidth product (DBP) that
is often used to characterize connections.

Delay and Window Size

(examples)
For a terrestrial connection with 8 KBytes window size
and 10ms RTT this leads to
throughput(max) = 8KBytes/10ms ~ 800,000 Bytes/s.
For a satellite connection with 64 KBytes window size
maximum in standard TCP) and 560 ms RTT follows:
throughput(max) = 64KBytes/560ms ~ 115,00
Bytes/s
As a result, at least a 100 KByte window is needed to
fully utilize a T1-link (1.544 Mbps) with 560 ms RTT.

Solutions to Round-Trip Time

Measurement (RTTM)
Problem:Window
Scale Option
Problem:

The window scale extension expands the definition of the TCP

window to 32 bits and then uses a scale factor to carry this 32-bit
value in the 16-bit Window field of the TCP header (SEG.WND in RFC793).
The scale factor is carried in a new TCP option, Window Scale. This
option is sent only in a SYN segment (a segment with the SYN bit
on), hence the window scale is fixed in each direction when a
connection is opened.
The maximum receive window, and therefore the scale factor, is
determined by the maximum receive buffer space.
In a typical modern implementation, this maximum buffer space is
set by default but can be overridden by a user program before a TCP
connection is opened.
This determines the scale factor, and therefore no new user
interface is needed for window scaling.

Round-Trip Time Measurement

(RTTM)

Accurate and current RTT estimates are necessary

to adapt to changing traffic conditions and to avoid
an instability known as "congestion collapse" in a
busy network.

When the window size is tens or hundreds of

packets, the RTT estimator may be seriously in
error, resulting in spurious retransmissions.
It is vitally important to use the RTTM mechanism
with big windows; otherwise, the door is opened to
some dangerous instabilities due to aliasing.
Furthermore, the option is probably useful for all
TCP's, since it simplifies the sender.

PAWS:Protect against
Wrapped Sequence
The PAWS Mechanism a simple mechanism to reject old
duplicate segments that might corrupt an open TCP connection.
PAWS operates within a single TCP connection, using state that
is saved in the connection control block.
PAWS uses the same TCP Timestamps option as the RTTM
mechanism and assumes that every received TCP segment
(including data and ACK segments) contains a timestamp
SEG.TSval whose values are monotone non-decreasing in time.
The basic idea is that a segment can be discarded as an old
duplicate if it is received with a timestamp SEG.TSval less than
some timestamp recently received on this connection.

Conclusions

Problems:
Long delay, especially in geosynchronous systems
Inefficient use of satellite channel
High probability of bit errors

Mechanisms
Path-MTU Discovery
Forward Error Correction(FEC)
Slow Start and Congestion
Avoidance
Fast Retransmit

Recommendations
Highly
Highly
Required

Fast Recovery
Large TCP Windows
Selective Acknowledgments

Highly
Highly
Highly

Highly

Comments
Reduces IP packet fragmentation.
Effective channel utilization.
Bad for satellite links, but needed
for shared network congestion.
Reduces time to detect lost
segments
Better recovery algorithm.
Avoids delay of connection.
Reduces transmitted packets.