IMPROVEMENT
IN TCP PERFORMANCE
The
protocols to improve the performance of TCP are:
Link-layer
protocols
There
have been several proposals for reliable link-layer protocols. The two main
classes of techniques employed by these protocols are: error correction (using techniques
such as forward error correction (FEC)), and retransmission of lost packets in
response to automatic repeat request (ARQ) messages. The link-layer protocols
for the digital cellular systems in the U.S. — both CDMA and TDMA — primarily
use ARQ techniques. While the TDMA protocol guarantees reliable, in-order
delivery of link-layer frames, the CDMA protocol only makes a limited attempt
and leaves it to the (reliable) transport layer to recover from errors in the
worst case.
The
AIRMAIL protocol employs a combination of FEC and ARQ techniques for loss
recovery. The main advantage of employing a link-layer protocol for loss
recovery is that it fits naturally into the layered structure of network
protocols. The link-layer protocol operates independently of higher-layer
protocols (which makes it applicable to a wide range of scenarios), and
consequently, does not maintain any per-connection state. The main concern
about link-layer protocols is the possibility of adverse effect on certain
transport-layer protocols such as TCP.
Indirect-TCP
(I-TCP) protocol
This
was one of the early protocols to use the split-connection approach. It
involves splitting each TCP connection between a sender and receiver into two
separate connections at the base station — one TCP connection between the
sender and the base station, and the other between the base station and the
receiver. In our classification of protocols, ITCP is a split-connection
solution that uses regular TCP for its connection over wireless link. I-TCP,
like other split-connection proposals, attempts to separate loss recovery over
the wireless link from that across the wireline network, thereby shielding the
original TCP sender from the wireless link.
However,
as experiments indicate, the choice of TCP over the wireless link results in
several performance problems. Since TCP is not well-tuned for the lossy link,
the TCP sender of the wireless connection often times out, causing the original
sender to stall. In addition, every packet incurs the overhead of going through
TCP protocol processing twice at the base station (as compared to zero times
for a non-split-connection approach), although extra copies are avoided by an
efficient kernel implementation.
Another
disadvantage of this approach is that the end-toend semantics of TCP
acknowledgments is violated, since acknowledgments to packets can now reach the
source even before the packets actually reach the mobile host. Also, since this
protocol maintains a significant amount of state at the base station per TCP
connection, handoff procedures tend to be complicated and slow.
The
Snoop Protocol
The
snoop protocol introduces a module, called the snoop agent, at the base
station. The agent monitors every packet that passes through the TCP connection
in both directions and maintains a cache of TCP segments sent across the link
that have not yet been acknowledged by the receiver. A packet loss is detected
by the arrival of a small number of duplicate acknowledgments from the receiver
or by a local timeout.
The
snoop agent retransmits the lost packet if it has it cached and suppresses the
duplicate acknowledgments. In classification of protocols, the snoop protocol
is a link-layer protocol that takes advantage of the knowledge of the
higher-layer transport protocol (TCP). The main advantage of this approach is
that it suppresses duplicate acknowledgments for TCP segments lost and
retransmitted locally, thereby avoiding unnecessary fast retransmissions and
congestion control invocations by the sender.
The
per-connection state maintained by the snoop agent at the base station is soft,
and is not essential for correctness. Like other link-layer solutions, the
snoop approach could also suffer from not being able to completely shield the
sender from wireless losses.
Selective
Acknowledgments
Since
standard TCP uses a cumulative acknowledgment scheme, it often does not provide
the sender with sufficient information to recover quickly from multiple packet
losses within a single transmission window. Several studies have shown that TCP
enhanced with selective acknowledgments performs better than standard TCP in
such situations. SACKs were added as an option to TCP by RFC 1072. However,
disagreements over the use of SACKs prevented the specification from being
adopted, and the SACK option was removed from later TCP RFCs. Recently, there
has been renewed interest in adding SACKs to TCP.
Two
of the more interesting proposals are the TCP SACKs Internet Draft and the
SMART scheme. The Internet Draft proposes that each acknowledgment contain
information about up to three non-contiguous blocks of data that have been
received successfully. Each block of data is described by its starting and
ending sequence number. Due to the limited number of blocks it is best to
inform the sender about the most recent blocks received.
An
alternate proposal, SMART, uses acknowledgments that contain the cumulative
acknowledgment and the sequence number of the packet that caused the receiver
to generate the acknowledgment (this information is a subset of the
three-blocks scheme proposed in the Internet Draft). The sender uses these SACKs
to create a bitmask of packets that have been successfully received. This
scheme trades off some resilience to reordering and lost acknowledgments in
exchange for a reduction in overhead to generate and transmit acknowledgments.