2011 International Conference on Communications and Information Technology (ICCIT), Aqaba
A Transport Layer Interoperability Model For Mobile
Ad-hoc Environment
Haidar Safa, Marcel Karam, Rawad Abou Assi
Hamid Mcheick
Department of Computer Science
American University of Beirut (AUB)
Beirut, Lebanon
{hs33, mk62, ria21}@aub.edu.lb
Department of Computer Science
University of Quebec at Chicoutimi
Chicoutimi, Qc, Canada
Hamid_Mcheick@uqac.ca
Abstract—Mobile ad-hoc networks (MANETs) are dynamic in
nature. Links between nodes may constantly change due to
mobility. The performance of the transmission control protocol
(TCP) degrades in such an environment mainly due to its
inability to differentiate between congestion and link failures
which are frequent in MANETs. Several TCP variants were
proposed to adapt TCP to a mobile environment. In addition,
other reliable transport protocols were especially designed for
MANETs as an alternative to these TCP variants. Several
network settings might require different transport protocols to
coexist and interoperate. In this paper we present a model that
can be used to achieve interoperability between reliable transport
protocols. The proposed model consists of forming an
intermediate easy-to-implement thin layer between the network
layer and the transport layer in the TCP/IP stack. Such layer will
be invoked at the receiver side and will preserve the semantics of
the sender’s transport protocol. Our proposed model focuses on
TCP and ATP, the ad-hoc transport protocols, but it can be
expanded to accommodate other protocols.
Keywords-TCP; wireless networks; interpoerability; transport
layer;
I.
INTRODUCTION
The transmission control protocol (TCP) is an end-to-end
connection-oriented transport layer protocol that was primarily
designed to support reliable data delivery in wired networks
[10]. However, its performance degrades in mobile ad-hoc
networks (MANETs) because some properties related to the
nature of such networks (such as high bit error rate and
frequent link failures due to mobility) were not taken into
consideration in the initial design phase of the protocol [13].
TCP considers that the loss of data is mainly due to network
congestion and not to hardware or link failure. Therefore, the
basic problem that results from using TCP in MANETS lies in
invoking the congestion control algorithms in case of packet
losses that are not caused by congestion. Several studies were
made to investigate the performance of TCP in mobile
environments [2-4, 13]. As a result, many TCP variants were
proposed to overcome its limitations. Some of these variations
are TCP-ELFN [4], ATCP [5], TCP-BuS [6], TCP-F [7], etc.
On the other hand, other reliable transport protocols such as
the ad-hoc transport protocol (ATP) [1] and the datagram
transport protocol over ad-hoc networks (DTPA) [12] were
978-1-4577-0400-0/11/$26.00 ©2011 IEEE
136
especially designed for MANETs and can be thought of as an
antithesis for TCP. The problem arises when the sender wants
to use a transport protocol that is not part of the transport layer
of the receiving end. In this paper we design and propose an
interoperability model between TCP variants for mobile
environment and ATP, referred to as TAIP (TCP and ATP
Interoperability Protocol). The proposed TAIP can be
implemented as a thin layer between the network layer and the
transport layer in the TCP/IP stack. TAIP is invoked at the
receiver side which preserves the semantics of the transport
protocol at the sender. Moreover, TAIP is transparent to both
the sender and the receiver in the sense that both of them will
“feel” that they are communicating with a similar counterpart.
This approach eliminates the need to alter the implementation
of TCP or ATP. Another important feature is that the proposed
approach can be expanded to accommodate other reliable
transport protocols. The rest of the paper is organized as
follows: Section II reviews the basic concepts of TCP, surveys
TCP variants proposed to improve the performance of TCP in
MANETs, and describe the ATP protocol. Section III
introduces the proposed TAIP to achieve interoperability
between TCP and ATP. Finally, section IV concludes with
some future work.
II.
BACGROUND AND RELATED WORK
A. TCP
The transmission control protocol (TCP) is a window-based
protocol that provides mechanisms to achieve reliability, flow
control and congestion control [10, 11]. These mechanisms are
tightly coupled by the common reliance on acknowledgements
(ACKs). Concerning reliability, TCP assumes that a segment is
lost when its retransmission timeout expires before an ACK is
received. Also, receiving duplicate ACKs for a previous
segment is interpreted as a loss of the followed segments. In
any case, the lost segment is retransmitted. As for congestion
control, TCP uses a three-phase protocol: slow start, additive
increase, and multiplicative decrease. To do this, the TCP
sender maintains two parameters: the slow start threshold
(initially its value is set to the receiver’s advertised window
size) and the congestion window (which is the number of
packets that are allowed to be in transit simultaneously). TCP
detects congestion when it assumes that a packet is lost. In such
a case, it triggers the slow start phase (this phase is also
triggered just after the connection is established between the
sender and the receiver). In this phase, TCP responds with two
packets for every incoming ACK. This continues until the
value of congestion window becomes greater than or equal to
the value of the slow start threshold. In such a case, TCP enters
the additive increase phase in which it responds by one packet
for every incoming ACK. When a retransmission timeout
occurs or when duplicate ACKs are received, TCP enters the
multiplicative decrease phase in which it sets the slow start
threshold to half the value of congestion window and sets the
latter to 1. Afterwards, the slow start phase is entered and the
same cycle is repeated.
the ATCP is moved from the normal state to the congested
state and leaving TCP to activate its own congestion control
algorithm. Both previous transitions enable the differentiation
of the link failure and packet loss giving back the control to
TCP on normal state of ATCP. On the other hand, a transition
of ATCP to the disconnected state happens upon receiving an
ICMP destination unreachable message only, and puts TCP
again in the persist mode with a reset to the congestion window
to 1. Accordingly TCP will keep probing the network until
receiving an acknowledgment to return both ATCP and TCP to
normal modes.
B. TCP Variants for Mobile Environment
Several protocols were proposed to improve the
performance of TCP in mobile environments such as MANETs
[4, 5, 6, 7, 9, 14]. In this context, TCP feedback (TCP-F) was
proposed in [7]. This protocol allows the TCP sender to
distinguish between losses due to route failures and those due
to network congestion. This is done by having intermediate
nodes explicitly report to the source a Route Failure
Notification. Upon receiving this notification, the source goes
into a snooze state in which it stops sending packets and
freezes all its variables. It remains in this state until it is
notified of the restoration of the route through a Route Reestablishment Notification. Upon receiving such notification,
the TCP sender leaves the snooze state and resumes
transmission. TCP with explicit link failure notification (TCPELFN) is another TCP variant protocol was proposed in [4] to
support mobility. Similar to TCP-F, in TCP-ELFN upstream
nodes notify the sender about any failures in the link.
Accordingly, it stops all data transmission by disabling timers
and sending probe frames to detect restored routes. In contrast
to TCP-F, the evaluation of TCP-ELFN is based on an ad hoc
network whereas in the former the authors used a black-box
that does not include the evaluation of the routing protocol.
Another TCP variant is TCP-Eifel that was proposed in [9].
TCP-Eifel uses timestamp option of TCP to solve
retransmission ambiguity where the sender’s spurious
retransmissions can be detected by differentiating between
original transmission and retransmission using the original
source. TCP-Eifel shows robust behavior to sudden delay
points where it requires the use of timestamp option or
modification of TCP header. Unlike TCP, the ad hoc TCP
protocol (ATCP) that is introduced in [5] works transparently
with hiding errors from TCP sender as the timeout and the
duplicate ACKs. It employs explicit congestion notification
(ECN) and ICMP route failure notification messages to assist
TCP’s decision. The behavior of ATCP is described by a state
machine with four states: normal, congested, loss, and
disconnected. Accordingly, since ATCP works as interlayer
between the TCP and IP, it is at the normal state when no
congestion is detected, i.e. neither ICMP nor ECN messages
were received. When the retransmission timeout expires or
when duplicate acknowledgments are received, ATCP enters
the loss state and puts TCP in the persist state hiding packet
loss from it and taking the responsibility of resending the
packets from the TCP buffer without going back the slow start
or the congestion avoidance phases. Upon receiving an ECN,
137
C. ad hoc transport protocol (ATP)
The ad hoc transport protocol (ATP) was proposed in [1] as
an antithesis of TCP. In ATP, Instead of window based
transmissions, an ATP sender uses a timer to schedule
transmissions; therefore the need for ACK arrival to trigger
further transmissions is eliminated. This property allows ATP
to decouple congestion control from reliability. Congestion
control is performed in coordination with intermediate nodes
that provide congestion feedback in terms of available rate and
reliability is achieved using selective ACKs to inform the
sender about any missing packets.
Before explaining the processing that occurs at intermediate
nodes, it is important to mention that the packet header in ATP
contains, in addition to the TCP header fields, an extra field D
that is used to store the delay experienced by the packet
through its path to the receiver. Intermediate nodes are used to
provide feedback about the delay in the network as follows:
Each intermediate node traversed by packets along the
path to the receiver maintains two indicators of delay:
the average queuing delay per packet at the node (Qt)
and the average transmission delay (Tt).
The values of Qt and Tt are computed over all the
packets traversing the node irrespective of the specific
flow the packets belong to.
For every outgoing packet, the intermediate node first
updates its Qt and Tt values as follows.
Qt = α*Qt + (1- α) * Qsample
(1)
(2)
Tt = α*Tt + (1- α) * Tsample
where Qsample and Tsample are the queuing delay and the
transmission delay experienced by the outgoing
packet and α is a constant between 0 and 1.
After updating the values of its Qt and Tt, the
intermediate nodes checks if the D field in the packet
header is smaller than the sum Qt + Tt. If it is, the
intermediate node updates the D field to Qt + Tt before
forwarding it. Consequently, when the receiver
receives a packet, the D field in the packet will indicate
the maximum delay experienced at the intermediate
nodes.
The ATP receiver provides periodic feedback to the sender.
This feedback contains information about 1) the delay
experienced by packets to help the sender in congestion control
and 2) information about packet losses to help in achieving
reliability. In each period, the receiver computes a value Davg
by exponential averaging of the D values as follows:
Davg = *Davg + (1-)*D
Application
(3)
Transport
TAIP
where is a value between 0 and 1.
Network
As for reliability, in each period the ATP receiver keeps
track of the packets that were missing from the data stream in
that period and uses selective acknowledgements (SACKs) to
inform the sender about them. Therefore, the feedback reported
to the sender at each period consists of Davg and the SACKs.
Data Link
Physical
The ATP sender performs congestion control and achieves
reliability using feedback from the network as follows:
Figure 1. TAIP in the TCP/IP stack
1)
Congestion Control: The ATP sender maintains a
value S which indicates the current rate at which it is sending.
Every time the sender receives a feedback from the network, it
computes the value R=1/Davg and one of the following three
possible cases will be encountered:
If R > S + φ* S (where φ is a constant to prevent
fluctuations), then S is set to the value S + (R-S)/k where
k is a constant (Increase phase)
If R < S, then S is set to R (Decrease phase)
If S ≤ R ≤ S + φ* S, then S remains the same (Maintain
phase)
2) Reliability: In the periodic feedback received by the
sender, any holes in the data stream are specified and thus the
corresponding packets can be retransmitted. In this way,
congestion control mechanism is decoupled from the
reliability mechanism
III.
B. Scenario1: ATP sender – TCP receiver
In this scenario, TAIP at the receiver acts as an ATP
receiver with respect to the sender. Every time it receives a
packet from the sender, it delivers it to the TCP layer which
will assume that this is received from a TCP sender.
Accordingly, it will respond with an ACK. This ACK is
captured by TAIP and discarded because the ATP sender is
not expecting any ACK and when a packet is lost (such as
packet 3 in Figure 2), TAIP adds it to the lost packets list.
Also, in this setting TAIP maintains a parameter Davg which is
updated upon the arrival of every new packet as explained in
section II. At the end of each ATP period, TAIP sends a
feedback to the sender containing Davg as well as SACKs for
all lost packets. In this scenario, TAIP will be invoked at
intermediate nodes as well because the ATP sender expects
them to participate in computing the feedback. So, at each
intermediate node TAIP will update the D field in packets
forwarded to the sender as explained in section II.
PROPOSED INTEROPERABILITY MODEL BETWEEN TCP
AND ATP
As far as we know, no previous work has been done to
achieve interoperability between transport protocols.
Nevertheless, in our interoperability protocol, we restricted
ourselves by the constraint that this protocol should be
transparent for the communicating entities and that the
implementation of TCP and ATP should not be altered. In this
section we introduce our proposed TCP and ATP
Interoperability Protocol (TAIP)
A. The TAIP Thin Layer
In our proposed solution, we introduce a thin layer in the
TCP/IP stack between the Network layer and the Transport
layer. The only interoperability scenarios that need to be
considered are: an ATP sender communicating with a TCP
receiver and a TCP sender communicating with an ATP
receiver. In both scenarios, TAIP is invoked at the receiver’s
side. This will preserve the semantics of the transport protocol
at the sender’s side and will result in an easier implementation
of the TAIP protocol.
138
Figure 2. TAIP invoked at a receiver that is using TCP
hybrid settings. Another idea to be tested is the feasibility of a
general interoperability protocol for TCP in which several
protocols other than ATP can coexist with TCP.
C.
Scenario2: TCP sender – ATP receiver
In this scenario, TAIP is invoked at the receiver that is
using ATP to act as a TCP receiver. Upon the receipt of every
packet, TAIP passes this packet to ATP and sends an ACK on
the behalf of the receiver. In case of packet loss, TAIP
behaves as a typical TCP receiver. Therefore, it keeps sending
ACKs corresponding to the lost packet upon the receipt of
subsequent packets as shown in Figure 3 where TAIP sends
ACKs corresponding to packet 3 upon the receipt of packets 4,
5, and 6. When the sender receives three duplicate ACKs, it
retransmits the lost packet. In this case, TAIP buffers the
retransmitted packet in a buffer so that at the end of the ATP
period, when the ATP receiver sends a feedback to the virtual
ATP sender including SACKs for all missing packets, TAIP
will capture this feedback and respond by passing all the lost
packets that are stored on its buffer to the ATP in the receiver.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
Figure 3. TAIP invoked at a receiver that is using ATP
IV.
CONCLUSION AND FUTURE WORK
In this paper, we presented TAIP, a protocol for achieving
interoperability between TCP and ATP. TAIP can be
implemented as a thin layer between the network layer and
transport layer in the TCP/IP stack and it is transparent to both
the sender and the receiver. TAIP is invoked at the receiver
side so that it appears to the sender (using TCP or ATP) that it
is communicating with a similar counterpart. For future work,
it remains to implement TAIP and analyze its performance in
View publication stats
139
K. Sundaresan, V. Anantharaman, H. Hsieh, and R. Sivakumar, “ATP:
A Reliable Transport Protocol for Ad-hoc Networks,” IEEE
Transactions on mobile Computing, vol. 4, no.6, pp. 588-603, Nov.-Dec.
2005.
X. Yu, “Improving TCP Performance over Mobile Ad Hoc Networks by
Exploiting Cross-Layer Information Awareness,” Proceedings of the 10th
Annual International Conference on Mobile Computing and Networking
(MobiCom'04), pp. 231 – 244, 2004.
Z. Fu, X. Meng, and S. Lu, “How Bad TCP Can Perform in Mobile Ad
Hoc Networks,” Proceedings of the 7th IEEE International Symposium
on Computers and Communications, 2002.
G. Holland, and N. Vaidya, “Analysis of TCP Performance over Mobile
Ad Hoc Networks,” Wireless Networks 8, 275–288, 2002.
J. Liu and S. Singh, “ATCP: TCP for Mobile Ad Hoc Networks,” IEEE
Journal on Selected Areas in Communications, vol. 19, no. 7, pp. 1300 –
1315, 2001.
D. Kim, C. Toh, and Y. Choi, “TCP-BuS: Improving TCP Performance
in Wireless Ad hoc Networks,” Journal of Communications and
Networks, vol. 3, no. 2, pp. 175 – 186, 2001.
K. Chandran, S. Raghunathan, S. Venkatesan, and R. Prakash, “A
Feedback Based Scheme for Improving TCP Performance in Ad hoc
Wireless Networks,” Proceedings of the 18th International Conference on
Distributed Computing Systems (ICDCS’98), pp. 472 – 479, 1998.
S. Kopparty, S. Krishnamurthy, M. Faloutous, and S. Tripathi, “Split
TCP for Mobile Ad Hoc Networks,” Proceedings of IEEE GLOBECOM
2002, vol. 1, pp. 138 – 142, 2002.
R. Ludwig and R. H. Katz, “The Eifel algorithm: Making TCP Robust
Against Spurious Retransmissions,” ACM SIGCOMM Computer
Communication Review, vol. 30, no. 1, pp. 30 – 36, 2000
RFC793 - Transmission Control Protocol
RFC 2581, TCP Congestion Control
X. Li, P.-Y. Kong, K-C. Chua, "DTPA: A Reliable Datagram Transport
Protocol over Ad Hoc Networks," IEEE Transactions on Mobile
Computing, , vol.7, no.10, pp.1285-1294, Oct. 2008.
Y. Tian, K. Xu, N. Ansar , "TCP in wireless environments: problems
and solutions," IEEE Communications Magazine, vol.43, no.3, pp. S27S32, March 2005
R. de Oliveira and T. Braun; , "A Smart TCP Acknowledgment
Approach for Multihop Wireless Networks," IEEE Transactions on
Mobile Computing, , vol.6, no.2, pp.192-205, Feb. 2007
V. Anantharaman, S.-J. Park,K. Sundaresan, R. Sivakumar "TCP
performance over mobile ad hoc networks: a quantitative study Wireless
Communications and Mobile Computing" Wirel. Commun. Mob.
Comput., vol.4, issue 2, pp. 203-222, 2004