i S E a § 6 E x . A \ 1| M § 3 E i. x’ 3.. 7n... . .334. t . . :3 :9.er . 3-. l i. 1.: wukrhmhamm .. 1&3; I”. wrurfinu; 5-33.“) . 1 HR . .. .. . urtnnrz $9.61.. .ufin “v.53. bnhfil?‘ ‘ ii ”1 fink, .13....339 1. e... .. : \unxul. ff 7 .. 3:71.402: Ii .5? l LIBRARY ‘ , Michigan State - University , \J _ _ This is to certify that the thesis entitled ADAPTIVE SCTP FOR IMPROVED PERFORMANCE IN MOBILE AD-HOC NETWORKS presented by Kanthakumar Mylsamy Pongaliur has been accepted towards fulfillment of the requirements for the MS. degree in Computer Science and quineerinL / Major PryésZSig ure I 04 95”" Date MSU is an Affirmative Action/Equal Opportunity Institution ..-:* - -—--.-L-I,l-I-I-n _.-.--..A_-....— PLACE IN RETURN BOX to remove this checkout from your record. TO AVOID FINES return on or before date due. MAY BE RECALLED with earlier due date if requested. DATE DUE DATE DUE DATE DUE MSW—oz] IR ateouejnddZ—pns‘ ADAPTIVE SCTP FOR IMPROVED PERFORMANCE IN MOBILE AD-HOC NETWORKS BY Kanthakumar Mylsamy Pongaliur A THESIS Submitted to Michigan State University in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Department of Computer Science 2005 l-l.l IDI'I lit ABSTRACT ADAPTIVE SCTP FOR IMPROVED PERFORMANCE IN MOBILE AD-HOC NETWORKS BY Kanthakumar Mylsamy Pongaliur This thesis studies the comparative jperformances of the transport protocols using the different routing strategies, to identify the bottleneck parameters in SCTP to be optimized for improved performance. The state of the path is modeled 'using transport layer‘ parameters. To achieve this, an adaptive algorithm is designed, which observes the changes in the path condition. The preliminary evaluation of these protocols through analysis and sfinmlations using ns-2 showed that the average delay for SCTP is high compared to TCP. The efficiency of packet .delivery is excellent with regards tx> the parameters— packet delivery ratio, routing overhead and goodput. Once the path condition is determined. to be degrading, we identify a backup path to be switched to. This switching of the primary path due to path quality degradation has resulted in the reduction of average delay. Consequently there is increased bandwidth utilization resulting imtaa significant increase in the goodput. The kinds of applications that benefit from increased bandwidth utilization are bandwidth— constrained nmltimedia transport over MANET. Another class of application benefiting from reduction in average delay is real-time applications. I dedicate this thesis to my parents... iii ACKNOWLEDGEMENTS This thesis dissertation would not have. completed, if not for the guidance and perseverance of Dr. Herman Hughes, who not only encouraged me but also challenged me through out my academic program and was never satisfied with the second best. I would like to thank Dr. Li Xiao for the critical assessment of the work throughout. I would also thank Dr. Charles Owen for accepting to be on the committee. Last but not the least I would like to thank my wife for providing me with enduring support during my good as well as difficult times. iv TABLE OF CONTENTS LIST OF TABLES ................. . ....................................................... Vii LIST OF FIGURES ............... . ...................................................... .viii ABBREVIATIONS...........= xi 1 IMRODUCTION 0000000000 OOOOOOOOOOOOOOI00.0.00... OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 1 1.1 Routing and Transport Protocols .................................. 3 1.1 1 Routing Protocols ............................................... 3 1.1.1.1 Destination Sequenced Distance Vector 3 1.1.1.2 Ad-Hoc On Demand Distance Vector ............ 4 1.1.2 Transport Protocols .............................................. 5 1.1.2.1 User Datagram Protocol n. ................................ 5 1.1.2.2 Transmission Control Protocol ................. 5 1.1.2.3 Stream Control Transmission Protocol “6 2 STREAM CONTROL TRANSMISSION PROTOCOL ........................ . ....... 8 2.1 SCTP Overview .................................................................... 8 2.2 SCTP Association Setup ................................................. 9 2.3 Data Transfer ................................................................. 11 2.4 Heartbeat Mechanism ....................................................... 13 2.5 Association Termination ............................................... 14 2.6 Congestion control differences from TCP”.HHH.nnnum16 3 PROBLEM STATEMENT AND PRELIMINARY INVESTIGATION..............18 3.1 Problem Statement ............................................................ 18 3.2 Related Work ................................................................... 19 3.3 Performance Metrics ......................................................... 21 3.4 Preliminary Investigation ............................................. 22 3.4.1 Simulation Setup ................................................... 22 3.4.2 Discussion of Preliminary results ..................... 24 4 ADAPTIVE-SCTP...... ....... ..... ..................................................... .....27 4.1 Statistical inference ...................................................... 27 4.2 Modeling the state of connection using SACK .H ”Hu28 parameters 4.3 Adaptive Algorithm ........................................................... 35 V 5 RESULTS AND ANALYSIS ............................................................... 39 6 CONCLUSION ................................................................................. 48 7 APPENDICES... OOOOOOOOOOOOOOOOOOOOOO O. OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO O ......... 0.0.050 Appendix A ............................................................................ 51 Appendix B ........................................................................... 52 8 BIBLIOGRAPHY..... ............. ...................................... ............60 vi LI ST OF TABLES Table 4.1: Correlation between DUP—TSN and Delay ”nunmu” Table 4.2: Correlation between GAP-ACK and Delay ”nuumuu vii 28 28 LIST OF FIGURES Figure 2.1: SCTP in protocol stack ........... I .......................... 9 Figure 2.2: Establishment Phase of SCTP ............................ 11 Figure 2.3: Data chunks received, before a SACK ............ 12 Figure 2.4: Partial SACK chunk showing GAP—ACK blocks H. 13 Figure 2.5: Heartbeat mechanism in SCTP ............................ 14 Figure 2.6: Graceful termination of association ............ 15 Figure 4.1: SACK Chunk .......................................................... 29 Figure 4.2a: Distribution of packets delay. AODV, .......... Pause time=SOSec, Speed =1m/sec 30 Figure 4.2b: Distribution of packets delay. AODV, .......... 3O Pause time=SOSec, Speed =25m/sec Figure 4.3a: AODV, averaged delay of packets .................... 31 Speed=1m/sec, pause time 50 Sec. Figure 4.3b: AODV, Averaged Delay of packets ................... 32 Speed=25m/sec, pause time 50 Sec. Figure 4.4 GAP—ACK distributions ....................................... 33 Figure 4.5 DUP—TSN distributions ........................................ 34 viii Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure 4.6: Adaptive Algorithm ............................................ 36 4.7 Last hop node depiction ......... , .......................... 37 5.1: GAP-ACK distributions ....................................... 40 5.2: DUP-TSN distributions ....................................... 41 5.3a Average Delay AODV, Mean Speed lm/s ............ 42 5.3b Average Delay AODV, Mean Speed 25m/s .......... 42 5.3c Average Delay DSDV, Mean Speed lm/s ............ 43 5.3d Average Delay DSDV, Mean Speed 25 m/s ........ 43 5.4a Goodput AODV, Mean Speed 1m/s ...................... 45 5.4b Goodput AODV, Mean Speed 25m/s ..................... 45 5.4c Goodput DSDV, Mean Speed lm/s ...................... 46 5.4d Goodput DSDV, Mean Speed 25m/s ..................... 46 A1: Correlation between DUP-TSN and Delay ............ 51 A2: Correlating between GAP—ACK and Delay ............ 51 81.1: Average Delay. AODV, Mean Speed = 1m/s ...... 52 ix Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Bl. B1. B1. B2. B2. B2. B2. .133. B3. B3. BB. B4. B4. B4. B4. Average Delay. AODV, Mean Speed = 25m/s H” Average Delay. DSDV, Mean Speed = 1m/s ...... Average Delay. DSDV, Mean Speed % Delivery. II [\J U1 8 \ U) AODV, Mean Speed = 1m/s .......... % Delivery. AODV, Mean Speed: 25m/s ............ % Delivery. DSDV, Mean Speed n H B \ m OOOOOOOOOOO % Delivery. DSDV, Mean Speed = 25m/s .......... Routing Overhead AODV, Mean Speed=1m/s ...... Routing Routing Routing Goodput Goodput Goodput Goodput Overhead AODV, Mean Speed=25m/s ”n Overhead DSDV, Mean Speed=1m/s ...... Overhead DSDV, Mean Speed=25m/s ”u AODV, AODV, DSDV, DSDV, Mean Mean Mean Mean speed lm/sec .................. speed 25m/sec ................. speed lm/sec ................... Speed 25m/sec ................. 52 53 53 54 54 55 55 S6 56 57 57 58 58 59 59 AODV DSDV DSR DUP-TSN ECN GAP—ACK MANET N52 RTO RTT SACK SCTP SSN TCB TCP TSN UDP Abbreviations Ad-Hoc On Demand Distance Vector Destination Sequenced Distance vector Dynamic Source Routing Number of duplicate chunks received Explicit Congestion Notification Number of Gap Ack blocks in SACK Mobile Ad—Hoc Network Network Simulator 2 Retransmission Time Out Round Trip Time Selective Acknowledgement Stream Control Transmission Protocol Stream Sequence Number Transmission Control Block Transmission Control Protocol Transmission Sequence Number User Datagram Protocol xi Chapter 1: Introduction Wireless networks have been in the forefront of research and development for the past decade. They can be broadly classified into infrastructured networks and infrastructure-less networks. In infrastructured wireless networks, there is a basic need for infrastructure to be present (example— base stations or access points) for the mere existence of the network. The infrastructure-less networks do not place any such demand and mobile ad—hoc networks (MANET) fall in this category. MANETs have been the focus of many research applications ranging from military operations to rescue missions. The fundamental issues involved in mobile ad-hoc networks are that the wireless link interfaces have unique routing interface characteristics and the node topologies within a wireless routing region may experience increased dynamics, due to motion [1]. As a result, the physical layout of mobile ad- hoc networks changes continuously. Hence, the routing algorithm forms a critical part of the ad-hoc network. There are various routing protocols like Dynamic Source Routing (DSR) [2], Destination Sequenced Distance vector (DSDV) [3] and Ad hoc On Demand Distance Vector (AODV) [4] routing. The common features of these protocols are that they are lightweight and provide loop—free operations and responsive routing information. As mentioned earlier, ad- hoc networks are prone to link failures due to the movement of nodes. One of the basic problems with the existing transport layer protocol is its inability to distinguish between the link—failures due to the movement of the mobile nodes and congestion in the network. Consequently, the throughput degrades when the nodes move [5]. Several studies [5] [6] [7][16] have focused on studying TCP and UDP performance in MANET and, as a result, proposed some modifications to these existing protocols. These studies have been largely done on how the MANET performance is affected by the different routing protocols, while assuming the de facto transport layer protocol; namely, transmission control protocol. Since TCP was primarily designed for wired networks, it suffers performance degradation in the mobile ad hoc scenario. Another protocol, which is a new entrant into the family of transport protocols, is the stream control transmission protocol (SCTP) . Its performance in ad-hoc networks has not been studied as exhaustively as TCP, but results from the investigations [8][l3][14][15] have been promising. In this thesis we focus on comparing transport protocol performance, while running routing strategies like AODV and DSDV over MANET. The selection of the routing protocols is made such that AODV is a reactive protocol, while DSDV, a proactive protocol. From our preliminary study we identify the sphere of SCTP, which can be improved for enhanced performance in MANET. We identified the delay in the packet delivery to be high in the case of SCTP, compared to TCP. We had comparable performance in case of data packet delivery percentage. The routing overhead for SCTP is comparatively lower than that of TCP. As a result, we have higher goodput in the case of SCTP. To reduce the delay of packet delivery, we do a switch of activity to a hot-standby path (called co—primary). It has been observed that, by switching we can reduce the average delay by 25% resulting in an increased goodput of 20%. Further, in this chapter we will discuss the various routing and transport protocols used while, doing a detailed summary of SCTP in chapter 2. 1.1 Routing and Transport Protocols 1.1.1 Routing Protocols In this section. we briefly discuss the various routing protocols under consideration for our work. 1.1.1.1 Destination Sequenced Distance vector (DSDV): DSDV [3] is a table driven proactive protocol. In this protocol, each node maintains the distance and the next hop information to each destination node. Also maintained is a sequence number for each route table entry, originated by the destination node. The routing information is transmitted by broadcast and the updates are transmitted periodically or immediately when a significant topology change is available. On receipt of new routing information, the route with a more recent sequence number is used or, if it has the same sequence number, then the route with a better metric is chosen. Each node periodically broadcasts its routing information. A broken link can be identified if we don’t receive a broadcast from the node for a certain period of time. On such identification, all nodes reached through that link are assigned an infinite metric value. It gives good performance when the node mobility is low. 1.1.1.2 Ad-Hoc On Demand Distance Vector routing (AODV): AODV [4] is a hybrid of DSR and DSDV, borrowing the salient features of both. It provides a loop free route even while repairing the routes. When a route is to be discovered, AODV uses a discovery mechanism similar to DSR, but instead of source routing, AODV relies on dynamically establishing route table entries at intermediate nodes. To maintain the routes it uses a concept similar to DSDV, but each node maintains a monotonically increasing sequence number counter, which is used to supersede stale cached routes. A route is considered active as long as there are data packets periodically traveling from the source to the destination along that path. Once the source stops sending data packets, the links will time out. It is eventually deleted from the intermediate node routing tables. If a link break occurs while the route is active, the node upstream of the break propagates a route error (RERR) message to the source node to inform it of the now unreachable~ destination(s). After receiving“ the ZRERR, if the source node still desires the route, it can reinitiate a route discovery. 1 . 1 . 2 Transport Protocols 1.1.2.1 User Datagram.Protocol (UDP): UDP [9] provides just the bare minimum functionalities that are to be provided by the transport layer. There is no connection setup feature like handshaking and hence it is a connectionless protocol. Another characteristic is the lack of a congestion control mechanism. It gives good performance for real-time communication, but does not guarantee QoS. 1.1.2.2 Transmission Control Protocol (TCP): TCP [10] is the de—facto protocol for wired networks and uses a 3—way handshake to set up a connection. TCP is connection oriented, full duplex, and end—to-end communication protocol. Once a connection is established, the two application processes can send data to each other. It supports a congestion control mechanism, error control, guaranteed QoS and delivery of the data. packet unlike UDP. Another important feature is that TCP is a byte streaming protocol. 1.1.2.3 Stream Control Transmission Protocol (SCTP) : SCTP [11] is a general—purpose transport protocol used for the transport of telecommunication signaling messages over an IP based network. The primary purpose of SCTP is to provide a reliable end-to—end message transportation service over IP—based networks. It performs this service within the context of an association between two SCTP endpoints. SCTP is connection—oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations, which may be generated from each endpoint's lists. Thus, the two new capabilities that are designed into SCTP are the support for multi—homed hosts and the support for multiple streams in a single SCTP association. The SCTP data transportation service is message—oriented as compared to the byte oriented data transfer of TCP. The multi—homing feature allows multiple source and/or destination addresses in one SCTP connection (“association” is used in SCTP terminology). When one interface/address fails, the traffic can be automatically transferred to another interface without interrupting the ongoing association. The thesis is organized as follows. We have a detailed description of SCTP in chapter 2. This is followed by the problem statement and preliminary investigation in chapter 3. Related work also forms a part of chapter 3. Chapter 4 details the adaptive algorithm. Chapter 5 tun; the results followed. by conclusion in chapter 6. Then. we have the appendices containing the graphs -for the preliminary investigation and the references follow it. Chapter 2: Stream Control Transmission Protocol In this chapter1 we discuss the core concepts of SCTP from association establishment through transmission of data to association termination. SCTP was developed keeping in mind the drawbacks of TCP, but still it has been designed for wired networks. Hence it too has certain drawbacks, which we will be demonstrating through simulations. We then propose solutions to overcome these drawbacks. 2.1 SCTP Overview SCTP is a transport layer protocol that uses a four—way handshake process to set up an association with another node. Another feature of SCTP is its ability to support multiple IP addresses and this gives rise to the possibility of load—sharing, seamless mobility support in MANET. Since the nodes can support multiple IP addresses, there could be multiple sessions with an association, which can live simultaneously. In the current SCTP, at a given time the two nodes will be communicating over just one pair of addresses. This connection is called the primary 1 Parts of this chapter are adapted from rfc2960. connection. To check the connection status among the other addresses currently not in use, we have a feature called heartbeat in SCTP. The PING utility in UNIX can be an analogy to the heartbeat. Unlike TCP there can be no half open connections in SCTP. SCTP User Application SCTP User App ' ' One or One or IP Network more IP more IP IP Network Serv1ce Address Address Serv1ce Node A Node D Figure 2.1: SCTP in protocol stack Figure 2.1 depicts the overall position of the SCTP in the SCTP—IP stack and also gives a pictorial understanding of how more than one IP addresses per node can be associated in the formation of a connection (association in SCTP). 2.2 SCTP Association Setup The association setup process in SCTP is a 4—way handshake process. This is mainly done to prevent the SYN attack that is possible in TCP. The security from SYN attacks is achieved by using a cookie mechanism in the establishment phase. Let us consider two nodes (node A and node B), where node A (from now on referenced just as A) wants to establish an association with node B (called B). A sends an INIT chunk (message) to B, with its initiate tag set to a particular value. This tag parameter is used to identify the association. B responds with an INIT—ACK chunk with the initiate tag parameter of A copied into the verification tag field of INIT—ACK chunk. Since the INIT chunk is the first chunk in the association, the verification tag value is set to zero. Another important function of the INIT, INIT-ACK chunk exchange is to negotiate the number of out- bound and number of in—bound streams to be supported. A send's its request using INIT chunk, and B responds with INIT-ACK chunk containing the number of in—bound and out— bound streams acceptable. The smaller of the two sets of request is accepted. The INIT and INIT—ACK chunks are used for the exchange of the IP addresses at which each of the nodes can be reached. The INIT-ACK chunk includes a state cookie. The state cookie is used to prevent the SYN—attack. The third stage in the association establishment is the sending of COOKIE ECHO at the receipt of INIT—ACK by A. Node A copies the state cookie from the INIT—ACK as it is, into the COOKIE ECHO chunk and sends the COOKIE ECHO to B. The entire operation is shown in figure 2.2 10 Node A Node B INIT Initiate Tag INIT-ACK Cookie COOKIE ECHO COOKIE ACK Figure 2.2: Establishment Phase of SCTP On the receipt of the COOKIE ECHO, B will create the TCB, and send back the COOKIE ACK chunk. Another important feature of the establishment phase is that in the last two steps, data can be exchanged, and hence the wait period before the actual transmit of data is one RTT, rather than two RTT’S. 2.3 Data Transfer Once the association is established, the address that was used to set up the association is marked the primary address (primary connection) and the transfer of data takes place on this connection. The transfer of data is facilitated by two kinds of chunks, namely the data chunks ll and SACK chunks. As the name specifies the data chunks are used to transfer data while SACK is used to acknowledge the data received. Another characteristic of SCTP is its use of two types of sequence numbers, namely; TSN (transmission sequence number) and SSN (stream sequence number). Data chunks are identified by the TSN, which is unique for the entire association. The SSN is used within a stream for sequenced delivery. The stream identifier identifies each individual stream within the association. Example: [11] TSN 17 e—-Missing TSN 15 TSN l4 ”+—-Missing TSN 12 TSN 11 TSN 10 Figure 2.3: Data chunks received, before a SACK SACK is a: cumulative acknowledgement scheme, 'which acknowledges the receipt of all the data chunks up to the last received TSN. SACK contains the Gap Ack blocks (representing the chunks received after a gap in TSN) and the duplicate TSN blocks. 12 Suppose that the chunks represented in figure 2.3 are the data chunks received at the time of sending the SACK chunk. Chunks 10, 11, 12, 14, 15, 17 are received while l3, 16 are missing. The representation of the SACK chunk will be as shown in figure 2.4. Cumulative TSN ACK = 12 Num of Block = 2 Num of Dup = O 2 Block #1 end = 3 5 Block #2 end = 5 Block #1 strt Block #2 strt Figure 2.4: Partial SACK chunk showing GAP-ACK blocks The duplicate TSN (dup TSN) are the chunks, which were received in duplicate due to retransmission. The computation and management of RTO in SCTP follows closeLy the way TCP manages its retransmission timer. in) compute the current RTO, an endpoint maintains two state variables per destination transport address: SRTT (smoothed round-trip time) and RTTVAR (round—trip time variation). If the computed RTO is less than RTO.Min seconds then it is rounded up to RTO.Min seconds. The reason for this rule is because, RTO’s that do not have a high minimum value are susceptible to unnecessary timeouts. 2.4 Heartbeat Mechanism Heartbeat is the mechanism by which the nodes keep track of the status of the path between addresses that are not in 13 use. The address that is used for the data transfer is called the primary address (connection), the rest are backup address pairs (connection). The backup connection is used if the primary address fails. ‘To use the backup connection, one should know the state of the path as it is rarely used. This is where the path heartbeat mechanism comes in handy. The heartbeat mechanism is used to probe the destination transport address defined in the current association. The sender node sends the HEARTBEAT chunk and the receiver replies with a HEARBEAT ACK. A HEARTBEAT ACK is always sent to the source IP address of the IP datagram containing the ‘HEARTBEAT chunk. to ‘which. the destination node is responding. Node A Node B Heartbeat To unused transport address To originating Heartbeat-ACK transport address Figure 2.5: Heartbeat mechanism.in SCTP The heartbeat chunk is largely undefined, hence it can be used for different purposes like gathering statistics, etc. 2.5 Association Termination SCTP supports two types of association termination, the graceful termination called SHUTDOWN auui the abrupt 14 termination called ABORT. The ABORT is called under different types of error circumstances. The abort chunk may contain the cause parameters to inform the receiver the reason for abort. In case of abort, the node puts the verification tag in the outbound abort packet. It deletes its TCB and goes into closed state. If the abort packet is lost, then it takes a long time for the other peer to realize that the association has been terminated. Data chunks may not be bundled with abort, while it may contain control chunks. Node A Node B SHUTDOWN r SHUTDOWN e SHUTDOWN ACK RECEIVED Delete TCB ——-> SHUTDOWN COMPLETE _ Timer Started CLOSED STATE Figure 2.6: Graceful termination of association Graceful shutdown is depicted in figure 2.6. A sends a SHUTDOWN chunk and waits for a SHUTDOWN ACK. On receiving the SHUTDOWN ACK, it deletes the TCB, and sends a SHUTDOWN complete and goes into the closed state. On receipt of SHUTDOWN COMPLETE by the B, it also goes into the closed 15 state. Suppose the SHUTDOWN COMPLETE gets lost, then B sends the SHUTDOWN ACK a few times before it marks A unreachable. 2.6 SCTP differences from TCP congestion control GAP-ACK Blocks in the SCTP SACK carry the same semantic meaning as the TCP SACK. TCP considers the information carried in the SACK as advisory information only. Similarly SCTP considers the information carried in the GAP-ACK Blocks in the SACK chunk as advisory. In SCTP, any DATA chunk that has been acknowledged by SACK, including DATA that arrived at the receiving end out of order, are not considered fully delivered. until the Cumulative TSN .Ack Point passes the TSN of the DATA chunk (i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack field in the SACK). Consequently, the value of cwnd (congestion window) controls the amount of outstanding data, rather than (as in the case of non—SACK TCP) the upper bound between the highest acknowledged sequence number and the latest DATA chunk that can be sent within the congestion window. SCTP SACK leads to different implementations of fast—retransmit and fast—recovery than non-SACK TCP. The biggest difference between SCTP and TCP, however, is multi—homing. SCTP is designed to establish robust l6 communication associations between two endpoints, each of which may be reachable by more than one transport addresses. Potentially different addresses may lead to different data paths between the two endpoints, thus ideally one may need a separate set of congestion control parameters for each of the paths. TCP guarantees in— sequence delivery of data to its upper—layer protocol within a single TCP session. This means that when TCP notices a gap in the received sequence number, it waits until the gap is filled before delivering the data that was received. with sequence numbers higher than that of the missing data. On the other hand, SCTP can deliver data to its upper—layer protocol even if there is a gap in TSN, provided the Stream Sequence Numbers are in sequence for a particular stream (i.e., the missing DATA chunks are for a different stream) or if unordered delivery iS~fndicated. 17 Chapter 3: Problem Statement and Preliminary Investigation 3 . 1 Problem statement The performance of SCTP is at par with TCP except for the delay it incurs in delivering the packet [14]. This is verified in the preliminary simulations. The delay in the delivery of packets is almost double of that in TCP. The reduction in delay of packet delivery will result in better utilization of the network's bandwidth. The bandwidth utilization is directly proportional to goodput. Hence, an increase in bandwidth utilization will result in increase of goodput. We also want to model the network path condition based on the transport layer statistics. This will enable us to take decisions at a higher level in the protocol stack. In this thesis, we are going to look at modeling the network path based on transport layer parameters and reduce the average delay. The motivational applications are the family of applications which use bandwidth constrained ‘MANETS to transport large quantities of data such as multimedia data. We can also extend the advantages to cater to real-time applications. Hence by reducing average delay in packet delivery, we are able to 18 cater to real—time applications and by increasing the bandwidth utilization, we should be able to cater to bandwidth constrained multimedia applications. 3.2 Related werk Though not much work is done to adapt SCTP for wireless/ mobile networks, a lot of research has gone into adapting TCP for similar networks. Since SCTP borrows the congestion control mechanism. directly from. TCP, most of the optimizations for TCP congestion control can be applied to SCTP as well. Further on, we discuss some of the related work that has been done to improve the performance of SCTP in wireless/mobile environment. In [8], A. Argyriou et al. do a performance evaluation between SCTP and TCP over DSR and AODV. The authors conclude the overall performance of SCTP is far better than TCP. In the paper they specify some modifications to SCTP, but these modifications are source routing (DSR) protocol specific. They modify DSR to give disjoint routes to SCTP, so that when SCTP intends to switch paths, it has the disjoint path. This is advantageous because SCTP maintains congestion control parameters separately for each individual path. This strategy will not work with the table driven routing strategies. The table-driven routing strategy may not know the underlying path. They also 19 conclude that the transport layer allows faster path selection, in case a number of paths exist, leading to improved overall throughput. In [13] G. ye et al. use the existing explicit congestion notification (ECN) as an indicator of congestion loss. It assumes that, if the loss is not accompanied by an ECN, the loss is caused by the wireless link dynamics (e.g. could be corruption of packet). It does not deal with the loss of the ECN messages, and this could lead to the sender believing that the packet loss is not due to congestion and will keep sending data packets at the current high rate. This can lead to drastic deterioration of the network. The authors don’t take any advantage of the alternate paths available in SCTP. DS—SCTP [14] represents a SCTP handover scheme, which selects the path, based on the moving average of end—to—end delay. The scheme considers multi—media traffic over wireless media but in a static environment. The authors assume the presence of a better path and handover the transmission to the second path; basically start using the alternate path. They don’t suggest any method or strategy to take this decision. But they do corroborate our results that the delay in SCTP is cnmatif the factors limiting the goodput. 20 In Collaborative-SCTP [15], the authors propose a cross— layer optimization of SCTP which is adaptive to variable bit errors of wireless channel. 3.3 Performance Metrics The performance metrics used for the comparison of the protocols are the average routing overhead, packet delivery ratio (expressed as percentage), average delay (expressed in seconds) and goodput. We define the average routing overhead as the ratio of the total number of routing bytes sent to the total number of data bytes sent, averaged over all the sources. Routing Bytes Sent Routing Overhead = Data Bytes Sent The ratio of the total number of data packets received to the total number of data packets sent is termed as the useful packet delivery ratio. Data Packets Received Data Packets.Sent Packet Delivery Ratio = The average delay is measured as the difference between the time when the packet was received and the time when the agent sent the packet and averaged over all the packets. 21 2(Receiving time - Sending time) Average Delay 2 1 1’1 where n is the total number of useful packets received. Goodput is measured as the total amount of data bytes delivered to the upper layer protocol (excluding the retransmissions) per unit time. Total.Data.Delivered Connection Time Goodput = 3.4 Preliminary Investigations 3.4.1 Simulation Setup We present a preliminary investigation, which strengthens our stand on high average delay in SCTP. In this investigation, we performed simulation runs in n52 along with the wireless extensions provided by the MONARCH project at the Carnegie Mellon University, to study the performance of three transport layer' protocols. ns-2 is developed by the Lawrence Berkley National Laboratory (LNBL) [12]. At the physical layer, we used a radio propagation (Two-ray Ground Reflection) model, with omni—directional antennas and a shared media interface. The IEEE 802.11 medium access protocol was used as the link layer protocol. The random waypoint model was used to generate the movement of the 22 nodes. 50 mobile nodes move in a flat rectangular topology of size 1500m x 1500m, with each node having a transmission range of 250m. The bandwidth of each link was 2 Mbps and the total simulation time was 200 seconds. The number of connections was restricted to a maximum of 25 over the 200 seconds simulation period. The mobility of a node is characterized by two parameters, the mean speed and the pause time. At the start of the simulation, each node waits for a pause time. It then starts moving towards a randomly selected destination with the mean speed. Once the selected destination is reached, the node remains stationary for a pause time before moving again towards a new destination. This process is repeated until the end of simulation is reached. The simulations were carried out for mean speeds of 1m/s and 25m/s and pause times of Osec, SOsec, 1005ec and 2005ec. This resulted in eight different sets of scenarios and 10 simulations were carried out for each scenario. The results obtained were averaged over the 10 simulation runs. A pause tine: of 200sec, which. is equal to the total simulation time, implies that there is no movement of nodes. On the other hand, when the pause time is 0 seconds, the nodes are continuously moving. Thus, the varying factors in the 23 preliminary simulation studies are the transport protocol, the routing protocol, the mean speed and the pause time. 3.4.2 Discussion of preliminary results The figures referred to, in this analySis are produced in the appendix—8 at the end of the report. We see the average delay associated with the packets of TCP to be around 0.4 seconds, while that of SCTP and UDP to be around 0.8 seconds. This is depicted in figures 81.1, 81.2, 81.3 and 81.4 in appendix B. Another observation is that with an increase in the mean speed the average delay for UDP on DSDV is considerably reduced to be around 0.4 seconds. This is due to the fact that the useful packet delivery of UDP reduces drastically with the increase in the mean speed and here we are calculating the average delay on only those packets that were delivered successfully. The average delay is seen to be consistently the same irrespective of the speed of the node movements. The variation in the overall packet delivery ratio is shown in figures 82.1, 82.2, 82.3 and 82.4 in appendix 8. It is clear from the figures that the packet delivery ratio of TCP and SCTP (in high 90’s) is far better than that of UDP (hovers between 35 and 50). One of the primary factors responsible for such high packet delivery percentage of TCP and SCTP is the connection oriented—ness of two the protocols. A connection is 24 established between the two end-nodes before the packet is sent, whereas in UDP, the packet is transmitted and it is hoped that the destination receives it. In figure 82.4, we see the packet delivery percentage. of UDP increases monotonically’ with the increase in the pause times. In these figures, we observe the high data delivery percentage of SCTP, which is just a couple of percentages lower than that of TCP. Even though SCTP delivers a slightly smaller percentage of its packets, it is able to deliver higher numbers of them, which is shown by the figures 84.1, 84.2, 84.3 and 84.4, i.e. the overall goodput of SCTP is higher than TCP. Figures 83.1, 83.2, 83.3 and 83.4, depict the routing overhead involved in sending the data bytes. SCTP outperforms TCP with regards to the overhead involved. This is because SCTP was designed as a lightweight protocol for PSTN signaling. On an average the amount of routing bytes required by TCP is 5 times the amount of routing bytes required by SCTP to deliver 1 byte of data. The amount of routing information required for UDP is less than TCP, but the number of packets delivered by UDP is far less compared to TCP. From the above discussion it is seen that, the performance of SCTP, is at par with TCP except for the delay it incurs in delivery of packets, which is almost double of that of 25 TCP. We are going to look at methods to reduce the average delay, which is expected to increase the goodput of the network, i.e. increase the bandwidth utilization. 26 Chapter 4: Adaptive SCTP The acknowledgement mechanisnl in SCTP is different from that of TCP and this could be one of the many reasons for delayed packet delivery. In SCTP, the acknowledgement mechanism is (MS a. cumulative type and. implying that ‘we don’t reply to every packet. By the time the cumulative acknowledgement is sent, the network dynamics may have changed, especially in a mobile network. Another reason for the delay in packet delivery is the retransmission time out (RTO) parameter, for which we don’t have a satisfactory solution. The RTO mechanism is borrowed from TCP and currently these two mechanisms are not using the multihoming feature of SCTP to their advantage. 4.1. Statistical inference We do a statistical analysis on the relation between the two parameters; namely, the GAP-ACK parameter and DUP—TSN. The correlation between the two parameters (GAP-ACK parameter and DUP—TSN) is seen to be +0.61. The correlation between the delay in the delivery of packets and the values of DUP—TSN is calculated (refer to table 4.1). Similarly, we calculated the correlation between DUP—TSN and the average delay. The results are presented in table 4.2. 27 Mean Speed(m/sec) 1 25 ‘1 0 0.71 0.69 o m m " 50 0.79 0.73 m E B 100 0.53 0.74 w m s g 200 0.76 0.74 Table 4.1: Correlation between # DUP-TSN and Delay Mean Speed(m/sec) 1 25 :3 0 0.53 0.57 0 1’3 50 0.71 0.66 w .E 9 100 0.58 0.65 w m 5%: 200 0.72 0.68 Table 4.2: Correlation between GAP-ACK and Delay From tables 4.1 and 4.2, it can be seen that delay has a strong correlation with GAP-ACK as well as DUP—TSN. The observed delay values seem to be more strongly correlated with DUP-TSN compared to GAP—ACK. The corresponding graphs for the above tables are given in appendix A. 4.2. Modeling the state of connection using SACK parameters The structure of SACK chunk has two parameters as discussed in section 4.1 (refer to figure 4.1). The GAP—ACK block 28 specifies the chunks in the stream that have not yet reached the destination. The study of this parameter over the period of the connection, gives a very good approximation of the variation in path condition. Another parameter that is included in the SACK chunk is the DUP— TSN. DUP—TSN is the number of duplicate chunks received due to retransmission. Type = 3 Chunk Flags Chunk Length Cumulative TSN Ack Advertised Receiver window Credit (a_rwnd) 7% of Gap ACk BlOCks E N Number of Duplicate TSN = X7 Gap Ack Block #1 startr rGap Ack Block #1 end Gap Ack Block #N start Gap Ack Block #N end Duplicate TSN l -. co ,-- L—fi Duplicate TSN X Figure 4.1: SACK Chunk We study the path condition by analyzing the variation in these parameters over a period of time. 29 15 Delay (in Seconds) 50 1 50 Time (In Seconds) 100 250 Figure 4.2a: Distribution of packets delay. AODV, Pause time-SOSec, Speed -1m/sec NNCOODJ-‘s 0010010 iijf' l l l i. l Delay (In Seconds) 6: a l § ,l l 150 100 Tlme (In Seconds) Figure 4.2b: Distribution of packets delay. AODV, Pause time=50sec, Figures 4.2a, Speed =25m/sec and 4.2b represent the distribution of packet delays for AODV with pause time equal to 50 seconds and two di f ferent mean speeds (lm/sec and 25m/sec). 30 It is evident from the figures that there is an increase in the number of delayed packets just after 54 seconds, as indicated on the x-axis. We averaged the delay in packet delivery by 0.5- second durations between 55 second and’60 second mark. The figures 4.3a and 4.3b represent the same. The average delay for 0.6 the the was this period is 0.9 seconds for mean speed lm/sec and seconds for mean speed 25m/sec. This variation can be result of nmltiple reasons. It could be that, most of packets never reached the destination, when mean speed 25m/sec. 1.4 1 1 2 . ._*.-__.__-... -_.._l.---..1..-.---_.-.-_-_-_._-.-__..----._- ----.-_--_-__.__. 0.8 — -. -0. . .9l. , . .-_-. 0.6 .. ____.--,,-_._.1--- 1.--.-1--h 1, , _, __-_. - 11-----. 1,“ -1. 0.4 Delay (in Seconds) 0.2 r W— W W W _-_--._, W-W WWW- —W Time (in Seconds) Figure 4.3a: AODV, averaged delay of packets. Speed 1m/sec, pause time 50 Sec. Secondly, the faster mobile nodes reached their destination soon. Once they reached the destination, they were 31 stationary for the next 50 seconds; hence they were able to receive more packets quicker compared to the other case. 09 l 0£~L W o -l §~Q7w~w~ 5%.- . o W WW c 06 W _ —.- ’ W. W .. § . ° 0,05~~— —- .-; — WWW—WW WWW o .— W E,Q4W WWWWW WW o ‘3 (12 +W-WW WWWWW WWW - W W~ W~- -W WW WWW W W» .WWWW—-WWWWWWWWWWW O r T r 54 55 56 57 58 59 60 Time (in Seconds) Figure 4.3b: .AODV, .Rveraged. Delay' of packets. Speed 25szec, pause time 50 Sec. Though we have depicted the graphs for pause time 50 seconds, we study the behavior for two pause times, namely, 50 and 100 seconds. With pause time 50 seconds, the nodes have just started moving when the time crossed 50 seconds and for pause time 100 seconds they are still stationary in our study interval. The mean speeds are lm/sec and 25 m/sec. Figure 4.4 represents a graph with a positive slope2 when the mean speed is 25m/sec. It indicates an increase in the number of GAP—ACK blocks. This implies that either the 2 Slope refers to the corresponding regression line. 32 packets are getting lost in the network or they are getting delayed in the network. Similarly, when the mean speed of the node is slow (i.e. lm.sec), the number of GAP-ACK blocks increases more rapidly. This is attributed to the fact that the nodes are still moving and have not reached the destination location yet, due to their slower speed. We get similar graphs with speeds lm/sec and 25 m/sec with pause time of 100 seconds (study interval is 55 seconds to 60 seconds). 8 7 -. — A g 6T- ~~wwww~w-Aww~wnwmw~m~c~‘—~« 3 5 + 5— ‘ - _-----o—-—»—-—o-»: ----—----——- --———----—« OPSO S1 {5 , IP100 31 < 4 +- ----——— a e—--~~0—t-r-l~—+—.c . ~ A APSO $25 3 3 ‘4 0! 19 - ~ - -‘ ‘ 2, we noticed that we were shifting too soon; this occurred very frequently. Setting the threshold value to 4 caused in the primary path to fail. Having decided that we need to shift to the backup path, there is another algorithm, which gives us the co—primary path (also called hot-standby path). This decision is taken based on the following parameters, the roundtrip time (RTT), and the last hop information. If it were a source routing protocol like DSR is being used, we can use a disjoint path as the backup path [8]. If it is Inn: a source routing protocol, we take into consideration the last hop node. Figure 4.7: Last hop node depiction: First we consider the RTT by selecting the path with the lowest roundtrip time and mark it ta. We also consider all 37 those paths, which have roundtrip time less than or equal to (l.l)*ta. Among these paths we select the path with the lowest roundtrip time and have a disjoint last hop node with the primary path. The last hop. node is node Q in figure 4.7, where node S is the sender and node R is the receiver. This is because, in a high percentage of times, it is the node movement of the receiver, which is responsible for the packets getting dropped. The paths in an association that share the last hop have some common intermediate nodes too. It is found that, most of the paths are not longer than 4—5 hops. Consequently, the consideration of the last hop information plays a crucial role in the selection of the co-primary path. Once the co—primary path is selected as the‘primary path, we start a timer called the path_shift timer. This timer expires in time l.l*RTT where RTT is the roundtrip time of the primary path. This setting of the initial value is strict in the sense that, it is set to a fixed value slightly above RTT. We require this because, if the path does not give us improvement with regards to the delay in packet delivery, then there is no use in changing the path. If we receive the acknowledgement before the expiration of the timer, we keep this co-primary path as the primary path, else we change back to the previous primary path. 38 Chapter 5: Results and Analysis The simulation setup is as described in chapter 3. We use n52 as the simulator. At the physical layer, we use a radio propagation (Two-ray Ground Reflection) model, with omni- directional antennas and a shared media interface. The IEEE 802.11 medium access protocol is used as the link layer protocol. The random waypoint model is used to generate the movement of the nodes. In our simulations, 50 mobile nodes move in a flat rectangular topology of size lSOOm x lSOOm, with each node having a transmission range of 250m. The bandwidth of each link was 2 Mbps and the total simulation time was 200 seconds. The number of connections was restricted to a maximum of 25 over the 200 seconds simulation period. This restriction is introduced to have at least some connections which were long enough to be affected by the network dynamics. Without such a restriction, we would have had a large number of small connections, which may not have given us the true performance picture. 39 7 - , _, _-_ __ ,_ _ m 6 ~ 77 7 # 77777‘ 7 7 7 v ‘ _ ‘6 2 5 A » e «I so eieee .D 0 P50 81 5 4 5 ”‘4’ ”I 5 ’ 3 “ _____ IP100 S1 of 3 7,1,, t a, . , , AP50 $25 3 :~. P100 $25 _ 2 She eoe» 3 a o * 1 ee e 0 o Y 1 54 55 56 57 58 59 60 61 Tlme (In Seconds) Figure 5.1: GAP-ACK distributions We counted the number of GAP—ACK blocks and the DUP—TSN in the SACK Chunk, which is as shown in figure 5.1. It can be observed that the number of GAP—ACK blocks does not increase as much when compared to the plain vanilla SCTP. This could imply that either the packets are delivered in sequence or there is loss of packets, hence, no DUP—TSN. This will be clear after the analysis of the average delay of packets and the goodput measurement. The distribution of DUP—TSN in the SACK chunks is denoted in figure 5.2. Here again in accordance with the results depicted in figure 5.1, we see that the DUP—TSNs in the SACK chunks is consistent and not increasing as in plain vanilla SCTP. 4O 9P5081 IP100 S1 AP50 S25 x P100 $25 # DUP TSN 54 55 56 57 58 59 60 61 Time (In Seconds) Figure 5.2: DUP-TSN distributions In plain vanilla SCTP, we were using a connection, which was getting congested as the lifetime of the association increased. At the same time, we had better connections within the association. These better connections could have given a better path, but we never explored for them till our primary path failed completely. Another reason for the improvement in the performance is the retransmission time out parameter. In the plain vanilla case, if the sender doesn't get the acknowledgement within the RTO, the chunk gets retransmitted and the RTO is increased. This in turn reduces the bandwidth utilization resulting in reduced goodput. 41 +SC‘I'P + TCP +A-SCTP Average Delay (In Seconds) O 50 100 200 Pause Tlme (In Seconds) Figure 5.3a: Average Delay AODV, Mean Speed lm/s ‘3 'D I g +sc1p‘ ;. +TCP 2 +A-SCTP 8 g 2 0 50 1 00 200 Pause Tlme (In Seconds) Figure 5.3b: Average Delay AODV, Mean Speed 25ml s 42 +SCTP +TCP + A-SCTP Average Delay (In Seconds) 0 50 1 00 200 Pause Tlme (In Seconds) Figure 5.3c: Average Delay DSDV, Mean Speed 1m/s ’3 'U C O 8 (D £05 7 7 ' W ' ' ' +5079 3 0.4 e —e e—e-eee »—-—» » -e~— +TCP 3 +A-SCTP 0.3 e , » e » a u __,_._——-a———e——es—————il $0.2» ee ~e L 2 0.1 e , e e »» » e e— < 0 Y 0 50 100 200 Pause TIme (in Seconds) Figure 5.3d: Average Delay DSDV, Mean Speed 25 m/s 43 From the figures 5.3(a, b, c, d), it is seen that we gain an advantage of 25% reduction in average delay in packet delivery. It is also observed that when the pause time is 200sec, i.e. when there is no mobility of nodes, we don't gain much advantage. This is because, in case of no mobility, there is not as much packet loss due to link deterioration (i.e. one of the intermediate nodes move out of the path). So our algorithm, which uses the transport layer‘ parameters like duplicate jpacket delivery' and the gaps. in jpacket delivery; is not very' efficient in such cases. So for a stationary wireless network, this solution may not fare as well as it does for MANET. The reduction in average delay results in the increase in bandwidth utilization. Increase in bandwidth utilization reflects in the increase in the goodput. On an average we get a 20% increase in the goodput. “ e"‘ The other two jparameters; namely, the percentage jpacket delivery ratio and routing overhead are not analyzed in this section for the following reasons. If we are providing a better and more stable path to the packet, the packet delivery ratio is bound to increase. This is also depicted from the goodput graphs in figure 5.4(a, b, c, d). 44 A 1400001 8 120000; 310000“ “ " ' ‘ ’ “j; +SCTP :43, 80000 '3 —'—«—*\«~\\ .. -_ ~13; —l—TCP :3. 60000 f +A-SCTP 20000 , 0 , 3 o 50 100 200 Pause Tlme (in Seconds) Figure 5.4a: Goodput AODV, Mean Speed 1m/s Goodput (bytes/sec) + SCTP —I— TCP + A-SCTP 50 1 00 200 Pause Tlme (in Seconds) Figure 5 . 4b : Goodput AODV, Mean Speed 25m/s 45 180000 160000 140000 120000 100000 80000 60000 40000 20000 0 -O- SCTP -I— TCP + A-SCTP Goodput (bytes/so) O 50 100 200 Pause Tlme (In Seconds) Figure 5.4c: Goodput DSDV, Mean Speed lm/s + SCTP + TCP +A-SCTP Goodput (bytes/sec) . - é 3 § § 1 2 3 4 Pause TIme (In Seconds) Figure 5.4d: Goodput DSDV, Mean Speed 25m/s The routing overhead is not analyzed for A—SCTP. This is because we do not introduce any extra overhead in routing. 46 We use the existing parameters at a node to gauge the condition of the network and take the necessary steps at the node. We are not introducing any new packet into the network to gather statistics and hence not increasing the routing overhead. The only overhead that we are introducing at the node is the additional number of CPU cycles for executing our algorithm. Our algorithm has a constant time complexity (i.e. O(constant k)). A study on sensor networks has revealed that transmitting one bit of information takes as much energy as 800 CPU cycles. Hence the overhead introduced by our algorithm is easily offset by the amount of energy saved by not requiring retransmission of a packet. 47 Chapter 6: Conclusion The goals of the thesis were to compare the performance of SCTP in MANET and identify the bottleneck parameters to be optimized to increase goodput. Using simulations we discovered that the average delay was high for SCTP compared to TCP. By reducing the average delay, the bandwidth utilization can be improved. It was seen that the SACK parameters (namely GAP-ACK and DUP—TSN) are strongly correlated to the delay in packet delivery. Consequently, we model the path condition using the SACK. parameters. Based on an adaptive algorithm, when the path condition was seen to deteriorate, we use the multi—homing feature of SCTP to switch to another available path. This way we do not wait for the link to deteriorate completely (break down) before we switch. This has resulted in the reduction of packet losses and the overall delay in the packet delivery. The consequence of this can be seen in increased bandwidth utilization, leading to increased goodput. Up to now, researchers have modeled the state of the network using the routing layer or the link layer parameters. We have been successful in modeling the path condition using the transport layer parameters and taking decisions at a 48 higher layer. Another prominent featwne is that we do not increase any routing overhead, which. most of the other approaches will require in order to gather information. In the future we wish to consider feedback from the link layer queues, this can be used to model the network. The queue length of the link layer can give a better estimate of the network conditions. Using this information the transport layer can decide to switch to a different path. One of the drawbacks of doing this is that it will lead to cross layer design and the dependence of the transport layer decisions on the link layer. There is not much performance gain when the nodes are stationary. In the future we would. want to model this algorithm to cater to networks, which are not affected by the network dynamics caused by node mobility. 49 APPENDICES 50 Appendix A Correlation DUP and Delay Correlation O 50 1 00 200 Pa use Tlme (Sec) Figure A1: Correlation between DUP-TSN and Delay Correlation GAP-ACK and Delay Correlation 0 50 100 200 Pause Tlme (Sec) Figure A2: Correlating between # GAP-ACK and Delay 51 Appendix B l A l l l +TCP +UDP Average Delay (In Seconds) 0 O O O O O O O O .L l I ) osnasaauabs 50 100 200 Pause Tlme (In Seconds) 0 Figure 31.1: Average Delay. AODV, Mean Speed = lm/s +SCTP +TCP + UDP Average Delay (In Seconds) 0 50 100 200 Pause Tlme (In Seconds) Figure 31.2: Average Delay. AODV, Mean Speed 25m/s 52 'oa'xlboio-t e——— --~— ‘—e-—- - ——--~e e—ee-e- — — e— —-—fi~—— _ _—e.._.*_.___'_._____._‘ + SCTP +TCP I + UDP 1 1 Average Delay (in Seconds) 0 O O O O O O O O 0'1 1 1 l 1 I l 1 I i L o'eiobob' 50 100 200 Pause TIme (In Seconds) 0 Figure 31.3: Average Delay. DSDV, Mean Speed 3 1m/s 0.8 13‘ n C o 8 a) g —e—SCTP go +TCP 2 + UDP 0 a E D > < 0 50 100 200 Pause TIme (In Seconds) Figure 81.4: Average Delay. DSDV, Mean Speed =- 25m/s 53 + SCTP +TCP + UDP % Data Packets Delivered 0 50 100 200 Pause Time (In Seconds) Figure 32.1: 95 Delivery. AODV, Mean Speed 8 1111/5 + SCTP +TCP + UDP % Dela Packets Dellvered 0 50 100 200 Pause Tlme (In Seconds) Figure 32.2: 96 Delivery. AODV, Mean Speed: 25m/s 54 é E 80 3 6° +SCTP 5 +TCP E 40 +UDP :2 0 50 100 200 Pause Tlme (In Seconds) Figure 32.3: 96 Delivery. DSDV, Mean Speed - lm/s 100 E 80 g 60 +SCTP g +TCP g 40 +UDP .5. O 20 ' a! 0 ‘7 ,_ 0 50 100 200 Pause Tlme (In Seconds) Figure 32.4: 96 Delivery. DSDV, Mean Speed - 25m/s 55 0.16 0.14 n 0.12 3 E °-‘ +SCTP g 0.08 +TCP § 006 +UDP 8 0.04 0.02 Pause 11me (In Seconds) Figure 33.1: Routing Overhead AODV, Mean Speed-lm/s '0 g —e-— SCTP g +TCP g + UDP 8 n: .0 .° .° 9 o .0 .° .° .0 o o _ .5 .5 .s .s O 0 50 100 200 Pause Time (In Seconds) Figure 33.2: Routing Overhead AODV, Mean Speed=25m/ s 56 0.14 0.12 E 0.1 E (103 +SCTP 5 +TCP E 0-06 +UDP ‘5 O I Pause Tlme (In Seconds) Figure 33.3: Routing Overhead DSDV, Mean Speedalms +SCTP +TCP -s— UDP Routlng Overhead 999909.09 08288;.5353 50 100 200 Pause Tlme (In Seconds) 0 Figure 33.4: Routing Overhead DSDV, Mean Speed-25m/s 57 140000 120000 - ~ ~] 6‘ o - 3 100000 J) 9 ~ —e—SCTP e \fi—--——-I +TCP a 60000 ""‘“ " ‘ -_ __ —‘__ _.._ " “—1 . UDP § ..... - - - - -..- - - G 20000 5 i A 0 T . 0 50 100 200 Pause TIme (In Seconds) Figure 34.1: Goodput AODV, Mean speed 1111/ sec § 75 g. +SCTP 5 —l— TCP a + UDP p o o 0 e3 1 0 50 100 200 Pause Tlme (In Seconds) Figure 34.2: Goodput AODV, Mean speed 25ml sec 58 160000 140000 120000 100000 Goodput (bytes/sec) 40000 20000 Pause Tlme (In Seconds) +scn> +TCP + UDP Figure 34.3: Goodput DSDV, Mean speed 1m/sec Goodput (bytes/sec) 2 3 Pause Tlme (In Seconds) +SCTP +TCP + UDP Figure 34.4: Goodput DSDV, Mean Speed 25m/sec 59 BIBLIOGRAPHY 6O [1] [2] [3] [4] [5] [6] [7] [8] [9] http://rtg.ietf.org/wg/manet/charter D. Johnson and D. Maltz. Dynamic Source Routing in Ad Hoc Wireless Networks. In T. Imielinsinki and H. Korth, Editors. Mobile Computing. Kluwer Academic Publishers, 1996. C. E. Perkins and P.Bhagwat. Highly Dynamic Destination Sequenced Distance-Vector Routing (DSDV) for Mobile Computers. In Proc. ACM SIGCOMM 94, London, pp. 234— 244, 1994 C. E. Perkins and E.M. Royer. Ad—hoc On—Demand Distance Vector Routing. In proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and A pplications, New Orleans, LA, February 1999, pp. 90- 100. Gavin Holland and Nitin Vaidya, Analysis of TCP performance over Mobile Ad-hoc Networks . In proceedings of ACM/IEEE MOBICOM '99, pp. 219-230, August 1999. Ashi sh Ahuja, Sulabh Agarwal , Jatinder P . Singh and Rajeev Shorey, Performance of TCP (over Different Routing Protocols in Mobile Ad-hoc Networks. In proceedings of IEEE Vehicular Technology Conference (VTC 2000), May 2000. Josh Broch, David A. Maltz, David B. Johnson, Yih—Chun Hu and Jorjeta Jetcheva. A Performance Comparison of Multi-Hop Wireless Ad-hoc Network Routing Protocols. In Proceedings of the 4th Annual ACM/IEEE International Conference (n1 Mobile Computing and Networking (MOBICOM’98), pp. 85—97. Antonios Argyriou and Vijay Madisetti. Performance Evaluation and Optimization of SCTP in Wireless Ad- Hoc Networks. In proceedings of the 28th Annual IEEE International Conference on Local Computer Networks (LCN ’03) User Datagram Protocol http://www.faqs.org/rfcs/rfc793.html 61 [10] [11] [12] [l3] [14] [15] [16] Transmission Control Protocol http://www.faqs.org/rfcs/rfc793.html R. Stewart et al. Stream Control Transmission Protocol http://www.faqs.org/rfcs/rfc2960.html The Network Simulator n32 http://www.isi.edu/nsnam/ns/ G. Ye, T. Saadawi, and. M. Lee, "Improving Stream Control. Transmission. Protocol Performancee over ‘Lossy Links", IEEE Journal on Selected Areas in Communications, Volume 22, Issue 4, pp. 727—736, May 2004. James Noonan, Andrew Kelly, Philip Perry, Sean Murphy, John Murphy, "Simulations Of Multimedia Traffic Over SCTP Modified For Delay-Centric Handover", In proceedings of World Wireless Congress '04. Shaliu,Shoubao Yang, Weifeng Sun, "Collaborative STCP: A Collaborative Approach to Improve the Performance of SCTP over Wired-cum—Wireless Networks" Perkins, Dmitri D. and Hughes, Herman D., "A Survey on Quality of Service Support in Wireless Ad Hoc Network", Journal of Wireless Communications and Mobile Computing (WCMC); Special Issue on Mobile Ad Hoc Networking, Trends and Applications, 2(5) (2002) pp. 503-513. 62 I“91(1);11;)ij)fl111111