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
[email protected]
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
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
