Analysis of the Interaction between TCP Variants and Routing Protocols in

Transcription

1 Analysis of the Interaction between TCP Variants and Routing Protocols in MANETs Λ Dongkyun Kim, Hanseok Bae, Jeomki Song Department of Computer Engineering Kyungpook National University, Daegu, Korea fbae, Juan-Carlos Cano Department of Computer Engineering Polytechnic University of Valencia, SPAIN Abstract IETF MANET (Mobile Ad Hoc Network) working group has standardized AODV (Ad Hoc On-demand Distance Vector) and OLSR (Optimized Link State Routing) as its reactive and proactive routing protocols, respectively. In addition, from the transport layer s perspective, TCP (Transmission Control Protocol) is still needed for MANET since it is widely used in the current Internet and suitable for smooth integration with the fixed Internet. Particularly, TCP has its variants, namely TCP-Reno and TCP-Vegas. However, there has been no research work on extensive performance comparison of TCP-Reno and TCP-Vegas over AODV and OLSR. This paper is the first trial to perform the research by using ns-2 simulator. Through the extensive simulations, we found that which to select among routing protocols is more important than which to select among TCP variants, because the performance difference between TCP- Reno and TCP-Vegas over any selected routing protocol is not so much outstanding. 1 Introduction Recently, research interest in the MANET (Mobile Ad Hoc Networks) has increased because of the proliferation of small, inexpensive, portable and mobile personal computing devices. A MANET is viewed as a special network where all nomadic nodes are able to communicate with each Λ This work was supported by grant No. R from Korea Science & Engineering Foundation. This work was also partially supported by the Ministerio de Educacion y Ciencia, Spain, under Grant TIN C2-1. other through packet forwarding by the intermediate nodes. The IETF MANET working group [1] has standardized OLSR (Optimized Link State Routing) [2] and AODV (Ad Hoc On-Demand Distance Vector) [4] as its proactive and reactive routing protocols, respectively. In proactive protocols like OLSR and DSDV (Destination-Sequenced Distance Vector) [], all nodes should maintain their routing tables for all possible destinations, without regard to the actual desire for the route between source and destination nodes. However, in reactive routing protocols such as AODV and DSR (Dynamic Source Routing) [3], only when a source node needs to send data packets to the destination node, it attempts to acquire the path in on-demand manner. Reactive approaches avoid the need of maintaining routing tables when there are no desires of routes between sourcedestination pairs. In addition to the above-mentioned network layer protocols, a transport layer protocol like TCP (Transmission Control Protocol) is also needed to provide reliable end-toend message transmission. TCP is still needed for MANETs since it is widely used in the current Internet and we would like to achieve a smooth integration with the fixed Internet. In particular, TCP has its variants such as TCP-Reno and TCP-Vegas. In the fixed Internet, some research works holds that TCP-Vegas is better than TCP-Reno. Research interest in finding more suitable TCP variant for MANET has increased. However, most of research works evaluated TCPs over one selected routing protocol, or evaluated the routing protocols with one chosen TCP. Recently, some research performed the comparison of TCPs over AODV and DSDV [13]. Although the authors selected DSDV as a proactive routing protocol, OLSR is getting more attention because it has been standardized in IETF. However, to the Proceedings of the International Conference on Parallel Processing Workshops (ICPPW ) 13-16/ $. IEEE

2 best of our knowledge, this paper is the first trial to extensively compare the two TCPs over AODV and OLSR. Although much research work performed some modifications to the current TCP in order to improve the TCP performance for MANET [6, 8, 9, ], prior to such researches, we believe that it is more important to know that which TCP variant is suitable for which routing protocol. The rest of this paper is organized as follows. Section 2 describes the key operations of routing protocols (AODV and OLSR) and TCP variants (TCP-Reno and TCP-Vegas) compared in this paper. Section 3 presents the extensive performance comparison of TCP-Reno and TCP-Vegas over AODV and OLSR by using ns-2 network simulator. Section 4 describes some trials to modify the existing TCPs in order to improve TCP performance for MANET along with our future work. Finally, some concluding remarks are given in Section. 2 Routing Protocols and TCPs compared 2.1 AODV (Ad hoc On-demand Distance Vector) In AODV, a typical reactive routing protocol, when a source needs to send data packets to the destination, it initiates a route discovery procedure by broadcasting an RREQ (Route REQuest) message in on-demand manner. The RREQ message contains Broadcast ID in order to avoid unnecessary retransmission of duplicate RREQ message. The Broadcast ID increases by 1 whenever a new RREQ is flooded in order to acquire a new path. Each node compares the Broadcast ID contained in a received RREQ message with the stored Broadcast ID contained in the RREQ message received before from the same source. If the Broadcast ID is greater than the stored one, the RREQ message is rebroadcasted and the node from which it is broadcasted is recorded into the routing table as the next node towards the source. Otherwise, the RREQ message is silently discarded. During this flooding of the RREQ message, a destination or an intermediate node which knows the path towards the destination responds to the RREQ message by unicasting an RREP (Route REPly) message back to the source. After acquiring a route, the source starts sending the data packet and each intermediate node can forward the packet by looking up its routing entries. When a route breakage occurs during data transmission, the intermediate node which detected the route breakage executes a local discovery or sends an RERR message towards the source. When receiving the RERR message, the source attempts to acquire a new route by performing the aforementioned route discovery procedure. 2.2 OLSR (Optimized Link State Routing) Most proactive routing protocols create routing information periodically through blind flooding technique. In OLSR, however, a node requires a subset of nodes, called MPR (Multi-Point Relay) set, instead of all nodes within two-hop distance from itself to re-broadcast its TC (Topology Control) message in order to provide all nodes within two-hop distance with the message. A B C D E Multipoint Relays Figure 1. An Example of the MPR set in OLSR protocol. For example, as shown in Figure 1, node A can create its MPR set consisting of nodes C and E, whose rebroadcasting can cover all nodes within two-hop distance from node A. Every node in the network exchanges hello message with its neighboring nodes every hello intervals. The hello message also contains a list of nodes which are reachable within one-hop distance from itself. Therefore, the MPR set can be determined on the basis of the hello message. Using the MPR set, OLSR enables the network to reduce the traffic for allowing each node to build its topology table created with link state information gathered from all nodes. In particular, only the nodes which are selected as an MPR node of other nodes can construct their TC message. The TC message sent from a node also contains only the links with the nodes which selected itself as their MPR node (called MPR selector), instead of its all one-hop physical links. In addition, during the propagation of the TC message, only the MPR nodes participate in rebroadcasting the received TC message. Finally, with the topology table, each node can create its routing tables for all possible destinations. A route recovery relies on the propagation of a TC message with changed link state information. 2.3 TCP-Reno TCP-Reno is the most widely used TCP variant with three functions: Slow Start, Congestion Avoidance and Fast Recovery. Slow Start is activated at the start of TCP connection or when a timeout event occurs. During Slow F G H I Proceedings of the International Conference on Parallel Processing Workshops (ICPPW ) 13-16/ $. IEEE

3 Start phase, the congestion window size (called CWND) increases exponentially until a Slow Start threshold from which CWND increases linearly. The period during which CWND increases linearly is called Congestion Avoidance phase. In TCP-Reno, a lost packet is detected and retransmitted when triple duplicate ACKs are received (called Fast Retransmit) or a timeout event occurs at the sender. For a timeout event, TCP considers a serious congestion and enters Slow Start phase. On the other hands, after Fast Retrasmit, Fast Recovery phase to cancel the Slow Start phase and increase its CWND linearly thereafter is executed. 2.4 TCP-Vegas Unlike TCP-Reno which increases its CWND until a packet loss is detected, TCP-Vegas however utilizes the congestion avoidance mechanism to avoid packet loss by decreasing its CWND as soon as it detects an incipient congestion. In TCP-Vegas, CWND is determined by difference between expected throughput and actual throughput as follows. Expected = W indowsize(cw ND)=BaseRT T Actual = W indowsize(cw ND)=currentRT T Diff = (Expected Actual) BaseRT T, where BaseRT T is the minimum of all measured RT T s. TCP-Vegas defines two thresholds, namely ff and fi. If Diff is <ff, it considers the absence of congestion and increases its CWND by 1. If Diff is >fi, it expects an incipient congestion and decreases its CWND by 1. Otherwise, it keeps the current CWND. For the purpose of retransmitting lost packets, TCP-Vegas maintains fine-grained RTO (Retransmission Time-Out) value for each transmitted packet, which is used to determine the occurrence of a timeout event when a duplicate ACK for a corresponding packet is received. If the timeout event occurs, the TCP sender thinks that the packet is lost and retransmits it without waiting for additional duplicate ACKs. 3 Performance Evaluation We conducted performance evaluation by using ns-2 simulator [16]. In this paper, Random waypoint model was adopted to simulate nodes movement, where the motion is characterized by two factors: the maximum speed and the pause time. Each node starts moving from its initial position to a random target position selected inside the simulation area. The node speed is uniformly distributed between and the maximum speed. When a node reaches the target position, it waits for the pause time, then selects another random target location and moves again. Therefore, we simulated node mobility by varying the maximum speed and pause time. For the simulations, nodes were initially positioned at random location over m x m area. Each simulation is seconds long. Also, every node has its limited transmission range of 2 meters. Additionally, 2 Mbps Wireless LAN was used as lower protocol. In particular, Hello INTERVAL of 2 seconds and TC INTERVAL of seconds were used for Hello and TC intervals, respectively, which are OLSR-related parameters. A TCP connection for a random pair of sender and receiver was selected with the background traffic of five UDP connections. We averaged different mobility scenarios to obtain each result. In addition, for the purpose of showing the sequencing of TCP segments and the progress of CWND change, the simulation results using the maximum speed of 1 m/s are shown as examples. First, we measured the throughput of TCP-Reno over AODV and OLSR according to node mobility. Irrespective of node mobility, TCP-Reno showed off better throughput over OLSR than AODV (see Figure 2). A long latency of route discovery due to route breakage in AODV causes TCP sender to experience many timeout events before acquiring a new path and TCP sender therefore reduces its CWND because it regards the situation as congestion. However, OLSR forces a node with changed link topology to promptly flood the change in order to allow other nodes to update their topology tables. Therefore, every node using OLSR finds another next-hop node towards the destination quickly and then continues transmitting its TCP segments before a timeout event occurs. Unlike AODV, it results in avoiding unnecessary reduction of CWND. Particularly, during recovery of a broken route, the transmitted TCP segments are lost in the network. The long latency taken to recover a route in AODV causes more TCP segments to be lost than in OLSR. In addition, OLSR obtains easily the shortest path between source and destination because each node can view the network topology, while AODV cannot guarantee the usage of shortest path because an RREP corresponding to the RREQ which has reached the receiver earliest is simply sent to the sender according to the broadcasting performed by each intermediate node at random time. The inability of using the shortest path indicates that the performance of TCP throughput decreases as the hop distance between source and destination nodes increases, which also was reported in [14]. Figure 3 shows how each CWND changes and we observed that using OLSR reduces the dropping of CWND size. Thus, the sequencing of TCP segments over OLSR progresses faster than over AODV (see Figure 4). In the fig- Proceedings of the International Conference on Parallel Processing Workshops (ICPPW ) 13-16/ $. IEEE

4 (a) pause time = 1 (b) pause time = 1 (c) pause time = Figure 2. Performance Comparison of TCP-Reno over AODV and OLSR Window Size Figure 3. Window Size Progress of TCP-Reno over AODV and OLSR. Figure 4. Sequence Trace of TCP-Reno over AODV and OLSR. ure, the frequent occurrences of a long-term discontinuity of sequencing indicate that AODV experiences more timeout events. We also measured the throughput of TCP-Vegas over AODV and OLSR. Due to the aforementioned characteristics of underlying routing protocols, TCP-Vegas over OLSR shows better performance than over AODV (see Figure ). As a result, we can see that OLSR is better than AODV without regard to TCP variants. In addition, we traced the progress of sequencing of TCP segments for AODV and OLSR. Obviously, we observed that TCP-Vegas over OLSR produces more throughput than over AODV (see Figure 6). Next, we measured the throughput performance of TCP- Reno and TCP-Vegas over a selected routing protocol (see Figure 7). When AODV is used as a reactive routing protocol, we observed that TCP-Vegas shows better performance than TCP-Reno, which is the same result as shown in [13]. TCP-Reno aggressively increases its CWND, while the small size of sending window of TCP-Vegas (see Figure 8) allows the occurrences of unnecessary route rediscovery caused by hidden node problem to be reduced [14]. In other words, unnecessary increase of window size causes much contention on the shared channel. Thus, it is possible that packet transmissions continue to be failed and the reaching of retry limit finally notifies the source of route failure and requires it to obtain a new route. Therefore, it is more important that the window size is maintained in an appropriate range as in TCP-Vegas. TCP-Vegas controls such traffic that unnecessary occurrences of route recovery can be reduced. As shown in Figure 9, although TCP-Reno increased its sequencing of TCP segments faster in the early stage, much traffic injection caused many route recovery activities, which resulted in performance degradation in the final stage. On the other hand, when OLSR is applied to the two TCPs as a proactive routing protocol, TCP-Reno is better than TCP-Vegas (see Figure ). Unlike window-based TCP-Reno, the sending rate of a source using TCP-Vegas is determined according to the difference between expected throughput and actual throughput. As mentioned before, Proceedings of the International Conference on Parallel Processing Workshops (ICPPW ) 13-16/ $. IEEE

5 (a) pause time = 1 (b) pause time = 1 (c) pause time = Figure. Performance Comparison of TCP-Vegas over AODV and OLSR (a) pause time = 4 1 (b) pause time = 4 1 (c) pause time = Figure 7. Performance Comparison of TCP-Reno and TCP-Vegas over AODV Window Size Figure 6. Sequence Trace of TCP-Vegas over AODV and OLSR. Figure 8. Window Size Progress of TCP-Reno and TCP-Vegas over AODV. TCP-Vegas designates the minimum of measured RTTs as its base RTT and calculates its expected throughput based on this base RTT. If TCP-Vegas begins using a new route due to node mobility, its base RTT is not a new base RTT, but the base RTT over the old route, whose inaccuracy results in performance degradation. Furthermore, AODV ad- heres to the same route until the route is broken. In OLSR, however, a link change triggers nodes to update their routing tables, which allows another route to be selected. The frequent change of route causes the inaccuracy of base RTT to be exaggerated. As shown in Figure 11, TCP-Reno shows better progress Proceedings of the International Conference on Parallel Processing Workshops (ICPPW ) 13-16/ $. IEEE

6 (a) pause time = 1 (b) pause time = 1 (c) pause time = Figure. Performance Comparison of TCP-Reno and TCP-Vegas over OLSR Figure 9. Sequence Trace of TCP-Reno and TCP-Vegas over AODV. Figure 11. Sequence Trace of TCP-Reno and TCP-Vegas over OLSR. of TCP segments sequencing than TCP-Vegas due to the inaccuracy of base RTT. 4 Trials to modify the existing TCPs with our Future works Many research works indicated that the existing TCPs are not able to distinguish between packet loss caused by node mobility and that by congestion. Therefore, for the purpose of improving TCP performance for MANETs, several approaches have been proposed. In TCP-feedback [6], two special messages, RFN (Route Failure Notification) and RRN (Route Reestablishment Notification), are generated when route breakage occurs and a new path is acquired, respectively. On receiving the RFN message, TCP sender freezes all its variables such as TCP-related timers and CWND (Congestion Window) size, and resumes the TCP process from the frozen state after receiving the RRN message. In the ELFNbased approach [7], ELFN (Explicit Link Failure Notification) message like the RFN message can be used to inform the TCP sender of the route breakage. However, instead of using RRN message as in TCP-Feedback, probe messages are sent regularly toward the destination in order to detect the route restoration. Additionally, in TCP-BuS (TCP with Buffering capability and Sequence Information) [8], the buffering mechanism at intermediate nodes helps to improve TCP performance, in addition to using explicit notification messages related to route breakage and restoration. Unlike the approaches mentioned above, ATCP [9] implements an intermediate layer between network and transport layers rather than imposing changes to the standard TCP. ATCP relies on ECN (Explicit Congestion Notification) mechanism for congestion control and ICMP protocol for detecting route failures. TCP-DOOR [] utilizes only out-of-order packet information for detecting route failures. In this paper, however, prior to such researches, we tried to know that which TCP variant is suitable for which routing protocol by extensive performance comparisons. As pointed out in the simulations, TCP-Vegas experiences an inaccuracy problem of Base RTT due to frequent path change caused by node mobility, which results in perfor- Proceedings of the International Conference on Parallel Processing Workshops (ICPPW ) 13-16/ $. IEEE

7 mance degradation. Therefore, some modification in order to estimate an exact Base RTT over a new path is needed to improve TCP performance for MANET. On the other hand, the aggressive window increasing attitude of TCP- Reno also invokes throughput decrease caused by hidden node problem. Although some research work [1] attempted to maintain the small size of TCP window, it did not reflect hop-distance between source and destination. Therefore, a dynamic determination of the window size according to the hop-distance between source and destination can improve the performance of TCP-Reno. On the basis of the results observed in this paper and some trials in the literature, we are planning to develop an efficient technique to improve TCP performance over MANET, which is our interesting future work. Conclusion Recently, IETF MANET working group has standardized AODV and OLSR as its reactive and proactive routing protocols, respectively. In addition, from the perspective of transport layer, we believe that TCP will be on top of the routing protocols for reliable data transmission. Since TCP has its variants, namely TCP-Reno and TCP-Vegas, we performed the throughput comparison of TCP-Reno and TCP-Vegas over AODV and OLSR. In summary, from the view of throughput, OLSR is the best routing protocol irrespective of TCP variants. However, TCP-Vegas performs better for AODV. On the other hand, TCP-Reno is more suitable for OLSR. Through the extensive simulations, we found that which to select among routing protocols is more important than which to select among TCP variants, because the performance difference between TCP-Reno and TCP-Vegas over any selected routing protocol is not so much outstanding. On the basis of the results observed in this paper and some trials in the literature, we can develop a technique to improve TCP performance over MANET, which is our interesting future work. References [1] Internet Engineering Task Force, Manet working group charter, [2] T. Clausen, P. Jacquet, A. Laouiti, P. Minet, P. Muhlethaler, A. Qayyum, and L. Viennot, Optimized Link State Routing Protocol(OLSR), IETF RFC [3] D. B. Johnson, D. A. Maltz, and Y. Hu, The Dynamic Source Routing Protocol for Mobile Ad-hoc Networks (DSR), IETF Internet Draft, draft-ietfmanet-dsr-8.txt, February 3. [4] C. E. Perkins, E. M. Belding-Royer, and S. R. Das, Ad-hoc On-Demand Distance Vector (AODV) Routing, IETF RFC 361. [] C. E. Perkins and P. Bhagwat, Highly dynamic Destination-Sequenced Distance-Vector routing (DSDV) for Mobile Computers, SIGCOMM Symposium on Communications Architectures and Protocols, Sept [6] K.Chandran, S. Raghunathan, S. Venkatesan, and R. Prakash, A Feedback Based Scheme For Improving TCP Performance In Ad-Hoc Wireless Networks, IEEE ICDCS [7] G. Holland and N. H. Vaidya, Analysis of TCP Performance over Mobile Ad Hoc Networks. th Annual International Conference on Mobile Computing and Networking, ACM Mobicom, August [8] D. Kim, C.-K. Toh, and Y. Choi, TCP-BuS : Improving TCP Performance in Wireless Ad Hoc Networks, Journal of Communications and Networks, Vol. 3, No. 2, 1. [9] J. Liu, S. Singh, ATCP: TCP for Mobile Ad Hoc Networks, IEEE Journal on selected areas in communications, vol. 19, No. 7, July 1. [] F. Wang and Y. Zhang, Improving TCP Performance over Mobile Ad-Hoc Networks with Out-of- Order Detection and Response, ACM Mobihoc2, June 2. [11] V.Jacobson, Congestion avoidance and control, ACM SIGCOMM 88, Aug [12] L. Brakmo and L. Peterson, TCP Vegas: End to End Congestion Avoidance on a Global Internet, IEEE Journal on Selected Areas in Communications, vol. 13, pp , October 199. [13] S. Papanastasiou, M. Ould-Khaoua, Exploring the performance of TCP Vegas in Mobile Ad hoc Networks, International Journal of Communication Systems, pp , Vol. 17, Issue 2, March 4. [14] Fu Z, Zerfos P, Luo H, Lu S, Zhang L and Gerla M, The impact of multihop wireless channel on TCP throughput and loss, IEEE INFOCOM 3. [1] S. Xu,T. Saadawi and M. Lee, Comparison of TCP Reno and Vegas in wireless mobile ad hoc networks, IEEE LCN. [16] K.Fall and K.Varadhan, ns notes and documents, The VINT Project, UC Berkeley, LBL, USC/ISI. and Xerox PARC, February, Available at Proceedings of the International Conference on Parallel Processing Workshops (ICPPW ) 13-16/ $. IEEE