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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.