Hindawi Publishing CorporationEURASIP Journal on Wireless Communications and NetworkingVolume 2006, Article ID 95149, Pages 1–16DOI 10.1155/WCN/2006/95149

TCP-M: Multiflow Transmission Control Protocolfor Ad Hoc Networks

Nagaraja Thanthry, Anand Kalamkar, and Ravi Pendse

Department of Electrical and Computer Engineering, Wichita State University, 1845 N Fairmount, Wichita, KS 67260, USA

Received 2 August 2005; Revised 18 February 2006; Accepted 13 March 2006

Recent research has indicated that transmission control protocol (TCP) in its base form does not perform well in an ad hocenvironment. The main reason identified for this behavior involves the ad hoc network dynamics. By nature, an ad hoc networkdoes not support any form of quality of service. The reduction in congestion window size during packet drops, a property ofthe TCP used to ensure guaranteed delivery, further deteriorates the overall performance. While other researchers have proposedmodifying congestion window properties to improve TCP performance in an ad hoc environment, the authors of this paperpropose using multiple TCP flows per connection. The proposed protocol reduces the influence of packet drops that occurred inany single path on the overall system performance. The analysis carried out by the authors indicates a significant improvement inoverall performance.

Copyright © 2006 Nagaraja Thanthry et al. This is an open access article distributed under the Creative Commons AttributionLicense, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properlycited.

1. INTRODUCTION

The transmission control protocol (TCP) is the most widelyused transport layer protocol in the networking world. Manyof the features supported by the TCP were developed basedon a wired network environment, although now they are alsobeing used in wireless networks. It has been observed that theTCP does not perform well in a wireless network environ-ment due to such issues as link failures, collision, interfer-ence, and fading. Link failures are considered one of the ma-jor causes of performance degradation. The TCP works onthe principle of guaranteed delivery. When a sender does notreceive an acknowledgment for a packet being transmitted,the TCP assumes that the packet is dropped due to conges-tion and therefore attempts to retransmit it. In a wired net-work environment, packet drops generally result from net-work congestion, but in a wireless network, packet dropscould also result from link failures. However, the TCP, by de-sign, attributes packet drops to network congestion and at-tempts to avoid this by reducing the transmission rate. Thisfurther degrades network performance in a wireless networkenvironment. Apart from the reduction in transmission rate,TCP behavior also results in an increase in the retransmissiontimeout period (RTO), which further delays packet delivery.

This situation further deteriorates when the TCP is usedin its base form in an ad hoc network environment. An ad

hoc network is formed on the fly and can be characterizedby the absence of a centralized authority, random networktopology, high mobility, and a high degree of link failures.This absence of a centralized authority makes it difficult todeploy any form of quality of service improvement tech-niques in the ad hoc network environment. With mobilityin place, nodes often need to rediscover the path to a desti-nation. During the route discovery process, the path to thedestination will be unavailable, thereby resulting in packetdrops.

Many researchers have considered the issue of improv-ing TCP performance in the wireless network environment,and some of them have suggested using a feedback mech-anism. TCP implementations like TCP-ELFN [1] and TCP-F [2] make use of an immediate neighbor to provide no-tification of path failure. The authors of [3] suggested us-ing a constant RTO instead of exponential back-off in or-der to improve TCP performance. This scheme attemptedto distinguish between route failures and network conges-tion by keeping track of number of timeouts. If an acknowl-edgment times out second time, it is attributed to the routefailure and the packet is retransmitted without changing theRTO value. The analysis carried out in [3] also showed a sig-nificant improvement in TCP performance. The authors of[3] observed that the protocol is only applicable for a wire-less network MANET environment due to the fact that the

2 EURASIP Journal on Wireless Communications and Networking

concept of route failures can be applied only in the case ofMANET. In a wired network scenario, the packet losses arecaused mainly due to network congestion. Another majorfactor that needs additional research in the case of the pro-posal presented in [3] is the claim that the successive packetdrops are due to route failure. In a dense network scenario,with multiple nodes attempting to transmit at the same time,it is quite possible that the acknowledgment timed out due tonetwork congestion itself.

One way to improve performance in ad hoc networks isto deploy multipath routing. In a sufficiently large network, asource node can route packets to the destination using mul-tiple paths, which could be established using intermediatenodes. Most of the routing protocols used in ad hoc networksmaintain a single path for every destination. Therefore, forevery path failure, the routing protocol wastes a significantamount of time in rediscovering the path. In addition, otherpaths that might be available between the source and the des-tination are underutilized, thus wasting network resources.In ad hoc networks, paths are short-lived due to node mo-bility. Hence, maintaining only a single path for any desti-nation may result in frequent route discoveries. Maintainingmultiple paths between the source and the destination willensure the availability of at least one path during link fail-ure. Recently, many routing protocols have been developedto support multipath routing. While some of these protocolsare based on a link-disjoint model, others work on the basisof a node-disjoint model.

Multipath routing improves the probability of path avail-ability between the source and the destination. However, itdoes result in variable round-trip time (RTT), which doesnot work well with TCP flows. Packets flowing through thepaths with a higher RTT tend to time out, forcing the senderto retransmit the packets. In addition, multipath routingcauses out-of-order delivery of packets, which results in du-plicate acknowledgments and additional delay at the receiv-ing end (due to packet realignment). Recent research effortson the performance evaluation of the TCP over a multipathenvironment have revealed that TCP performance actuallydegrades in a multipath environment [4]. In this paper, theauthors propose extensions to the existing TCP to supporta multipath ad hoc network environment. These extensionsare based on the principle of multiple connections betweenthe source and destination at the transport layer, similar tothe idea proposed in [5]. Since each connection takes a dis-tinct route to reach a destination, single-link failure will notaffect the performance of the network to a large extent. Anal-ysis carried out by the authors indicates that the proposedextensions improve TCP performance to a large extent, com-pared to the normal TCP.

The remainder of this paper is organized as follows. InSection 2, the authors review the related research work in-volving the TCP and ad hoc networks. Section 3 discussesthe performance of the TCP in multipath ad hoc networks.Section 4 presents the proposed protocol, that is, TCP-M.Section 5 shows an analysis of the proposed protocol andcompares it to the existing TCP. Conclusions are presentedin Section 6.

2. RELATEDWORK

While the TCP is the most widely used transport layer proto-col, it has been proven that it does not perform well in an adhoc network environment. Link unavailability (mainly dueto mobility) is considered to be one of the main reasons forthis performance degradation. However, the TCP assumesthat performance degradation is due to congestion and re-sorts to congestion-avoidance techniques. Many researchershave suggested different methods to address the performanceissue associated with the TCP and ad hoc networks. The au-thors of [1] proposed feedback-based extensions to the TCPand termed the new protocol TCP-ELFN. In their protocol,the sender probes the network to check the path status. In theTCP-ELFN protocol, neighbors take an active part and sendnotifications of link failure whenever a path becomes inac-tive. At this instance, the sender freezes its congestion win-dow, therebyminimizing the effect of packet drops on overallthroughput.

TCP-F is another similar proposal employing a feedbackmechanism. Here, the intermediate nodes notify the senderabout the link failure after which the sender freezes the con-gestion window. The difference between the two is that in-stead of the sender probing for network status, the interme-diate nodes or neighbors intimate the sender whenever a linkbecomes active. One of the major issues in this protocol is thereliability of the feedback mechanism. It does not specify anymeasures to deal with lost feedback messages.

Another approach is to fix the RTO timer value. Thefixed RTO scheme was primarily proposed to overcome theproblem of a long restart latency caused by the exponentialback-off algorithms during link failures. Normally the RTOis doubled for every retransmission timeout, and this contin-ues until it reaches 64 times the original timeout value. Afterthis, the timeout value remains constant until any one of thepacket is acknowledged. According to the fixed RTO scheme,the RTO is frozen until the path becomes active again.

Sundaresan et al. suggested using the ad hoc transportProtocol (ATP) for mobile ad hoc networks [6]. After study-ing issues with the TCP in ad hoc networks, the authorshave taken a new approach using ATP to improve the per-formance of the transport layer protocol in ad hoc networkswith the introduction of a rate-based transmission schemerather than window-based transmission. The authors alsohave introduced other techniques such as quick start, sepa-rating the congestion control mechanism from the reliability,a composite parameter that considers the effect of transmis-sion, and a queuing delay of the followed path.

Sundaresan et al. revealed that, even though the slow-start mechanism used in the TCP may be effective in wirednetworks, it has several drawbacks in an ad hoc network en-vironment. Although the slow-start mechanism uses an ex-ponential increase in the congestion window, this method isnot aggressive enough, especially because of the short-livednature of links in ad hoc networks, where the packet dropis due to link failure. Also, when the link becomes activeagain, the slow-start mechanism wastes a significant amountof time to reach the normal transmission rate, whereby it can

Nagaraja Thanthry et al. 3

transmit at the capacity rate almost immediately after be-coming active. The authors who suggested ATP introduceda quick mechanism; whereby after a packet drop or at thetime of connection establishment, the sender sends a syn-chronization (SYN) packet to the receiver. The intermediatenodes update the values of the parameters Qt, queuing delay,and Tt , transmission delay, for the link. When the receiverreceives the SYN packet, it replies by an acknowledgment(ACK) packet with the values of Qt and Tt . After receivingthe ACK packet, the sender determines the bandwidth of thepath and begins transmitting at the same rate instead of ex-ponentially increasing the transmission rate.

Rather than using window-based transmission, the ATPuses a three-step rate-based data transmission. This schemeconsists of an increase phase, whereby the sender checks thefeedback rate from the receiver. If this rate is greater thanthe current rate, then the sender increases the transmissionrate. The threshold is kept as the current rate to allow flowswith lower rates to increase more aggressively than flows withhigher rates. If the feedback rate from the receiver is less thanthe current transmission rate, then the sender reduces thetransmission rate to the value in the feedback. If the feed-back rate is within a certain limit of the current rate, then theprotocol maintains the current transmission rate.

Thus, the ATP tries to solve issues that are the result ofthe slow-start mechanism response of the TCP to congestionand the window-based transmission scheme. However, theATP still fails to make optimal use of network resources sinceit does not have amechanism formultipath routing, and also,data transmissions are scheduled by the timer at the sender;thus requiring timer overheads at the sender.

Although all of these schemes try to improve the perfor-mance of the TCP, they use only a single path to transmit thedata from source to destination. Therefore, every time a pathfailure occurs, a considerable amount of time is wasted untila new path is reestablished. However, a number of other al-ternate paths that are not being usedmight be available in thenetwork. In the case of path failure, being able to use multi-ple paths can improve the performance of a TCP since it canuse an alternate path.

The routing protocol used at the network layer also playsan important role in ad hoc networks. A robust routing pro-tocol increases path availability. Recent proposals for routingprotocols maintain more than one path for the same destina-tion in the route cache so that when the primary path fails,the secondary or backup path can be used immediately. Inthe case of a path failure, this helps to eliminate additionaltime wasted in the route discovery. Some of the multipathrouting protocols are discussed below.

The multipath routing protocol called ad hoc on-de-mand multipath distance vector (AOMDV) [7] finds mul-tiple-disjoint loop-free paths during the route discovery. Thepaths can be node-disjoint or link-disjoint and are selectedon the basis of hop count. A node enters a path in the table,only if the new route has less hop count than the one alreadyin the table.

When the protocol is configured for using a node-disjointpath, those paths with no common intermediate node are

selected; whereas when the protocol is configured for usinga link-disjoint path, those paths with no common interme-diate link are selected. Using node-disjoint paths providesmore granularity in path selection and guarantees more reli-able paths. However, it also reduces the number of availablepaths, as compared to link-disjoint paths. The authors ob-served in their performance evaluation that, in most cases,the link-disjoint paths have satisfactory performance. TheAOMDV maintains different next hops for different paths.

Unlike in the single-path routing protocol called ad hocon-demand distance vector (AODV), in AOMDV the inter-mediate node does not simply drop the duplicate route re-quest (RREQ) packet but examines it to see if it gives a node-disjoint path to the destination. If so, then the node checksto see if the reverse path to the source is available. If this isalso true, then the path is added in the table. In the case ofa link-disjoint path, the node applies a slightly lenient policyand replies to a certain number of RREQs, which come fromdisjoint neighbors. The unique next hop guarantees the link-disjoint path. Although not a part of the basic implementa-tion, the AOMDV can use multiple paths simultaneously fordata transmission.

Split multipath routing (SMR) [8] is another multi-path protocol, which attempts to utilize the available net-work resources in an effective manner. SMR is also an on-demand routing protocol, which finds and uses multiple-disjoint paths. The SMR uses a per-packet allocation schemeto distribute data packets among different paths of the ac-tive session. This scheme helps in utilizing network resourcesand preventing congestion at a node under heavy-load con-ditions. The protocol operates as follows.

Being an on-demand routing protocol, the SMR sourcebroadcasts the RREQ packet only when the route to the des-tination node is not present in the route cache. The RREQpacket contains the source ID and sequence number thatuniquely identifies the source. When the intermediate nodereceives the packet, it records its node ID in the packet headerand further forwards that packet. The intermediate node for-wards any duplicate RREQ packets that come from differ-ent links and have a hop count less than the earlier-receivedRREQ packet. Also, the intermediate node does not send thesource route reply (RREP) packet, even if it knows the pathto the destination. This helps avoiding paths with commonlinks. Although more than two paths can be selected in theSMR implementation, the receiver selects two disjoint paths.Upon receiving the first RREQ packet, the destination repliesto the source by sending the RREP packet with the completepath in the packet. Then the destination node waits a certainamount of time and receives more RREQ packets. Then it se-lects the route that is maximally disjoint with the path alreadysent to the source. In the case of multiple-disjoint paths, thepath with the shortest hop count is used. In the case of a tie,the path received first is used. When an intermediate node isunable to forward the packet to the next hop, it assumes alink failure and sends the route error (RERR) packet in theupstream direction to the source. Upon receiving the RERRpacket, the source deletes every entry in the route table thatuses the broken link. After this, if the second path to the

4 EURASIP Journal on Wireless Communications and Networking

Source Intermediate network Destination

Transportlayer

Networklayer

Networklayer

Transportlayer

Transmitbuffer

Receive buffer

Figure 1: Packet forwarding in a multipath environment.

destination is available, the source uses the remaining routefor data transfer or it restarts the route discovery.

Thus, the SMR allows two routes to be used simultane-ously for data transmission and provides optimal use of net-work resources. Choosing the second route disjoint with thefirst one reduces the possibility of both routes failing at thesame time and hence giving greater path availability.

In the next section, the authors discuss the issues involvedin using the TCP in a multipath ad hoc network environ-ment.

3. TCP PERFORMANCE INMULTIPATH ADHOCNETWORKS

The TCP was originally designed for wired networks wherethe packet drop is generally assumed to be due to networkcongestion. Therefore, whenever there is a packet drop, theTCP goes into fast-retransmit mode and appropriately re-duces the congestion window. If the path is unavailable for anextended period of time and packets are still being dropped,the TCP enters the slow-start mode, and the window sizeis reduced to one. This can be justified in the case of wirednetworks where congestion is the primary reason behind apacket drop. However, when the TCP is used for mobile adhoc networks, its performance suffers. Here, the links areshort-lived and prone to errors, and generally the packetdrop is due to link failure. In this case, even after reducing thewindow size, if the packet sent is dropped, the TCP enters theslow-start mode and reduces the window size to one packet.As pointed out by the authors of [6], if the path is reestab-lished at this stage, the TCP takes a longer time to come outof slow-start and attain normal transmission capacity of thepath, thus wasting path capacity during this time.

With the traditional TCP implementation in place, evenusing multipath routing will not improve the situation. Asseen in Figure 1, in the traditional implementation, the TCPmaintains a single buffer and congestion window for ev-ery connection. When packets are routed through differentpaths, a packet drop in any one path (which is heavily con-gested) triggers a change in TCP behavior. This automati-cally pushes the TCP into the congestion-avoidance mode,thus reducing the rate of data transmission and the conges-tion window size. This diminishes the advantages of multi-path routing to a great extent.

Another important factor to be considered is the valueof retransmission timeout (RTO). When multiple paths withdifferent RTT values are present, it is better to maintain dif-ferent RTO values for each of these paths. This ensures aguaranteed delivery of the packets to their destination andalso reduces the number of duplicate acknowledgments. Al-though different RTT values result in an out-of-order deliv-ery of packets at the destination, this is better than losingpackets or increasing traffic due to duplicate acknowledg-ments.

Recently, the authors of [9] proposed transmission con-trol protocol-persistent packet reordering (TCP-PR) inwhich they suggested a mechanism to handle out-of-orderpacket delivery in MANETs. The TCP-PR does not rely onduplicate acknowledgments to detect packet loss in the net-work. Instead, it maintains a timer for each transmittedpacket. This timer is set when a packet is transmitted, andif the sender does not receive the acknowledgment before thetimer expires, the packet is assumed to be dropped. Hence,since this protocol does not reply on duplicate acknowledg-ment, reordering at the receiver does not degrade TCP-PRperformance.

The TCP-PR maintains two lists: a to-be-sent list, whichcontains all the packets that are waiting to be transmitted,and a to-be-ack list, which stores all the packets whose ac-knowledgments are pending. When an application has tosend a packet, it puts the packet in the to-be-sent list. Whenthe packet is transmitted, a time stamp is applied to thepacket, and it is removed from the to-be-sent list and storedin the to-be-ack list. The packet is removed from the to-be-ack list when it is acknowledged. If the acknowledgment forthe packet is not received before the time stamp expires, thepacket is assumed to be dropped and placed in the to-be-sentlist again for transmission.

Another transport layer protocol proposed for ad hocnetworks, multiflow real-time transport protocol (MRTP)[5], is primarily used for real-time data transmission. Thisprotocol uses multiple flows at the transport layer and mul-tiple paths at the network layer.

Figure 2 describes the operation of the MRTP scheme.Packets are split over different flows for the transmission.Each packet carries the timestamp and the sequence iden-tifier so it can be reassembled at the receiver. The receiveralso keeps track of the QoS parameters like the jitter, packet

Nagaraja Thanthry et al. 5

X[n]

Trafficpartitioning

X1[n]

X2[n]

Xk[n]

· · ·· · ·...

· · ·

Reassemblyprocess

X[n]

Communication network(e.g., an ad hoc network)

Figure 2: MRTP operation mechanism [5].

loss, and the highest packet sequence number received andsends this information to the sender in a receiver report (RR)packet, which can be sent through any flow. This helps thesender in maintaining the QoS parameters. The MRTP usesflow IDs for each flow, and either the sender or the receivercan delete a flow that is broken. The MRTP uses the underly-ing protocol multiflow real-time transport control protocol(MRTCP), which establishes multiple flows at the transportlayer.

The MRTP tries to use multiple paths in the network. Al-though the protocol uses the multiple paths wisely, it cannotbe used for non-real-time transmission, that is, for reliabledata transmission, since it does not have any mechanism forpacket retransmission and is mainly used for real-time datatransmission.

In this paper, the authors propose using multiple TCPflows per connection. Each of these TCP flows can be routedthrough different paths and reassembled at the destination.In the next section, the authors explain the protocol in detail.

4. TCPMULTIFLOW

Traditionally, when using the TCP in a multipath environ-ment, a single TCP connection is opened between two com-municating nodes. Datagrams are sent from the TCP layerto the network layer, where the routing protocol decidesthe scheduling of packets over different available paths. Aspointed out earlier, information about the number of pathsavailable from the source to the destination is hidden fromthe TCP layer. In the proposed scheme, the authors suggestproviding the information about the number of paths avail-able between the source and the destination to the trans-port layer (TCP layer in this case). This will enable the TCPlayer to decide upon the optimum number of connectionsrequired between the source and destination to transfer thegiven data. This scheme ensures optimum utilization of net-work resources and improves overall network performance.

4.1. Protocol description

Figure 2 represents a logical view of the traditional imple-mentation, and Figure 3 represents the logical view of theproposed protocol. In a traditional implementation, when an

application wants to communicate with a remote destinationnode, the transport layer establishes a single connection withthe destination and allocates one transmitter/receive bufferalong with a single congestion window. In a normal mul-tipath environment, only the network layer will know thenumber of available paths. When load balancing is enabled,the network layer intelligently (using some sort of schedul-ing algorithm) forwards the packets belonging to the sameconnection through multiple paths. This helps to reduce theload on the best path and improve the network utilization;however, a single packet drop in any one path will resultin the TCP going into the congestion-avoidance mode anddropping down the data transmission rate on all other sta-ble paths. Depending upon the number of packet drops, theTCP will take a long time to restabilize. This severely affectsthe throughput of the application.

In the proposed protocol, when an application runningon the source node requests the transport layer (in this case,TCP layer) to establish connection with a remote destination,the transport layer sends a message (similar to ioctl () func-tion with a request type of SIOCGRTCONF) to the networklayer (interlayer messaging) requesting the number of pathsto a particular destination. After receiving the request, thenetwork layer looks for available routes for the given destina-tion in the routing table. If it finds the routes in the routingtable, it sends the number of routes available to the trans-port (TCP) layer as a reply (similar to rtc returned in the caseof an ioctl () call). If there is no route in the routing tablecorresponding to the requested destination address, the net-work layer broadcasts a route request to the network (sameas a normal route request). Once routes to the destinationaddress are installed in the routing table, the network layerupdates the transport (TCP) layer with the requested infor-mation. This route request by the network layer does not in-troduce an extra overhead to the network because the routerequest is just preponed. At this point, the TCP can set upconnections according to the number of paths available (oneconnection per path). Data transfer between the source anddestination is then divided into the number of flows (one foreach connection), and one flow is assigned to each connec-tion.

4.2. TCP connection establishment

For the purpose of this protocol, the authors divide the TCPlayer into two parts (Figure 4). The first part, called the globalconnection manager (GCM), is responsible for communica-tion with the upper layers, establishing connection with theremote destination, packet reordering, and packet schedul-ing. The second part, called the data transmission manager,consists of multiple TCP processes, which are child processesof the GCM. The data transmission manager is similar to thenormal TCP layer and handles data delivery to the destina-tion. Except for packet reordering, it performs all functionsof a normal TCP layer.

When the TCP layer obtains the number or availableroutes to the destination, it initiates the three-way hand-shaking process by originating multiple SYN messages with

6 EURASIP Journal on Wireless Communications and Networking

Source Intermediate network Destination

Transportlayer

Networklayer

Networklayer

Transportlayer

Transmitbuffer

Global receivebuffer

Multiple network pathsIndividual flow receive buffers with

separate congestion window

Figure 3: Logical representation of TCP-M.

Application layer

Transport layer: globalconnection manager

Transport layer: datatransmission manager

Network layer

Physical layer

Figure 4: Logical partitioning of the TCP layer.

respect to the number of available paths. Each SYN messagecontains a different source port address but a single destina-tion port address. This is consistent with the case where asingle host opens multiple connections with the server. Thedestination node responds to the SYN messages like the nor-mal TCP does, and connections between the source and des-tination nodes will be established. Each of these connectionswill have different connection identifiers (typically the TCPuses the IP address and port address, both source and desti-nation, as the connection identifier). In addition to the nor-mal connection identifier, the proposed protocol uses an-other connection identifier, that is, global connection iden-tifier (4 bytes), which will be used by the destination nodefor reordering the packets.

4.3. Data transfer process

Once the connection is established between the source andthe destination, the GCM starts acting as a scheduler. Basedon feedback information (collected periodically from eachindividual connection), the GCM schedules the data ondifferent connections. While transferring data to the child

Source port Destination portSequence number

Acknowledgment number

HLEN Reserved Code bits Window

Checksum Urgent pointerGlobal connection identifierGlobal sequence number

Data

· · ·

SPLT URG ACK PSH RST SYN FIN

Figure 5: TCP header for the proposed protocol.

processes, the GCM also sends the original sequence num-ber (4 bytes) of the datagram and a connection identifier (4bytes) as arguments. These two pieces of information will beembedded in the options field of the TCP header and willhelp the receiver in reordering the packets.

When the child processes obtain the data, they form theTCP header similar to the normal TCP process. As men-tioned earlier, they embed the original sequence number andthe connection identifier information in the options field ofthe TCP header. In order to inform the destination nodethat the datagram is part of split connections, the proposedprotocol suggests borrowing a bit from the reserved bits inthe original TCP header. The borrowed bit will be called theSPLT bit. When the SPLT bit is set, it indicates to the receiverthat the packet is a part of split connections. Figure 5 showsthe TCP header information for the proposed protocol.

Each connection between the source and the destinationwill be associated with its own buffer space. This allows theTCP process to handle the flows independent of each otherduring congestion. If one path experiences congestion or fail-ure, traffic corresponding to that path could be forwardedusing other active paths without affecting other TCP flows.In addition, each of these flows maintains its own congestionwindow, independent of other flows.

When datagrams reach the network layer, based on thesource and destination port pair, the network layer forwards

Nagaraja Thanthry et al. 7

k − 1 k k + 1

Packets to be scheduled

Flow condition estimation

Scheduling decision process

Parameter update block

Scheduling decision

Flow measurement

Flows to be assigned

Figure 6: Block diagram of scheduling algorithm.

the packets through different paths. The authors assume thatthe network layer is enabled with load-balancing techniquesto use different paths for different connections between thesame source and destination pair. The discussion of imple-mentation of multipath routing with load balancing is be-yond the scope of this paper. While it is possible that twoflows could be assigned to the same path, they will be treatedas two different connections. On the other hand, two flowsassigned to the same path might lead to unfair sharing ofbandwidth, which also is beyond the scope of this paper. Theproposed scheme works better in the presence of multiplepaths between the source and the destination. The presenceof disjoint paths (either node-disjoint or path-disjoint) to thedestination is preferred in order to minimize the risk of per-formance degradation due to one link. In addition, this willalso help in avoiding overloading and unfair sharing of a linkor path.

While sending acknowledgments to packets, the receivertreats each split flow as a separate flow and sends acknowl-edgments accordingly. Acknowledgments are handled onlyby the data transmission layer, and the GCM will not haveany control over this process. As mentioned earlier, the GCMis also responsible for reordering datagrams and presentingdata to the higher layers. When the GCM obtains data fromthe child processes, it first checks for the SPLT flag. If theSPLT flag is set, it checks for the actual sequence number andthe global connection identifier in the options field of theTCP header. Based on these two pieces of information, theGCM reorders the datagrams from different child processesand presents the data to the higher layers. As the sender getsindividual acknowledgments for each split flow, it can keeptrack of the packet losses on the individual flows. If a packet isdropped, the sender can identify the flow in which the packethas been dropped and enter the congestion-avoidance modeonly for that flow. In the case of a path failure, the sendercan stop sending packets along that path and only use activepaths until the old path is reestablished.

4.4. Packet-scheduling algorithm

TCP-M uses a packet-scheduling algorithm for schedulingthe packets on different flows. The packet scheduler is a part

of the GCM. It schedules packets based on current informa-tion about queue size, delay, and available capacity for eachflow. The scheduler assumes that each flow is a single entity.In addition, it also assumes that information about a con-nection’s queue size, queuing delay, and available capacity ofeach flow is provided to the scheduler. The scheduler thenselects a flow in order to minimize the delay experienced bythe packet.

Figure 6 shows the block diagram for the packet sched-uler. In here, the flow measurement block keeps monitoringthe status of each TCP flow setup by the sender for transmit-ting data. At regular intervals, the flow measurement blockupdates the flow condition estimation block about the statusof different TCP connections. Typical update parameters in-clude RTT for each connection, number of packets handledby each connection in that time duration, number of retrans-missions during the time interval, and the current state ofthe TCP congestion window. The flow condition estimatorblock acquires these parameters and calculates packet sharefor each connection. It then updates the scheduling decisionprocess with the new traffic share information.

The scheduling decision process is responsible for for-warding the packet towards destination using a specific con-nection. It uses the traffic share information provided by theflow condition estimation block in deciding the connectionfor each packet. Once the decision is made, the schedulingdecision process marks the packets accordingly and sends itto the appropriate connection. In order to reduce the effect ofpacket reordering at the destination, the scheduler forwardsconsecutive packets through the same connection (as per thetraffic share calculated by the flow condition estimator). Theparameter update block updates the scheduling decision pro-cess block if the connection chosen at that instance runs outof buffer space. Scheduling decision process updates the flowcondition estimation block with the same information. Thishelps the scheduler to avoid packet drops at the source andalso helps the scheduler to reduce the overall delay.

4.5. Traffic share calculation

In the proposed scheduling algorithm, traffic share iscalculated based on three different parameters, that is,

8 EURASIP Journal on Wireless Communications and Networking

instantaneous RTT, instantaneous packet drop probability,and current status of TCP congestion window. While con-sidering the routing table metric for each path will also helpin deciding the best path, the authors assume that any changein the routing metric will also be reflected in the TCP param-eters like RTT and packet drop probability.

The flow condition estimation block obtains parameterslike instantaneous RTT, number of packets transmitted bya particular connection, and number of retransmissions inthe given time interval. Based on these parameters, the flowcondition estimator first calculates the packet drop probabil-ity:

Packet drop probability for path i(pi) = Total number of retransmissions during the time period for path i

Total number of packets transmitted through path i during the time period.

(1)

Once the packet drop probability is found for each path,the flow condition estimation block calculates the geometricdistribution of the ratio of packet drop probability of path iand minimum packet drop probability:

Packet Drop Ratio sum =i=n∑

i=1

pip min

, (2)

where p min = min(p1, p2, . . . , pn) is the minimum packetdrop probability among all the paths and n is the total num-ber of paths available between the source and destination.

Similar to packet drop probability, the flow condition es-timator also calculates the geometric distribution of the ratioof RTT of path i and minimum RTT among all the paths(RTT min):

RTT Ratio sum =i=n∑

i=1

RTTi

RTT min. (3)

Now the traffic share for path i for time instance t (TS(i, t))is calculated as

TS(i, t) =

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨

⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

α∗(

RTT RatioRTT Ratio sum

)+ (1− α)∗

(Packet Drop Ratio

Packet Drop Ratio sum

)if CW is stable or increasing,

min[(

α∗(

RTT RatioRTT Ratio sum

)

+(1− α)∗(

Packet Drop RatioPacket Drop Ratio sum

)), DataRatei

]if CW is decreasing due to congestion.

(4)

Here α represents the weight to be assigned for the RTTratio, RTT Ratio represents the ratio of RTT for path i andthe minimum RTT (RTT min), and Packet Drop Ratio rep-resents the ratio of packet drop probability for path i and theminimum packet drop probability p min.

Now the overall traffic share for any path i (Ni) is calcu-lated as

Ni =t=z∑

t=1TS(i, t)∗Nt, (5)

where z is the total number of time intervals and Nt is thetotal number of packets transmitted during the time intervalt.

In the following sections, the authors discuss and ana-lyze the performance of the proposed protocol and compareit with the TCP single-path and traditional multipath ap-proaches.

5. PROTOCOL ANALYSIS

In this section, the authors analyze the proposed protocolperformance with respect to delay and throughput. In addi-tion, they compare the proposed protocol performance withthat of the traditional single-path and multipath TCP.

Consider a sample network withm nodes in the networkarranged in a random fashion. Let n be the average num-ber of distinct paths between any two nodes. Let RTTi be theround-trip time of the ith path and Ts the time period withinwhich the TCP expects an ACK from the destination. Let pibe the loss probability of the ith path. As described in [10],the TCP connection setup time can be estimated using theloss probability and RTT of the path as

tSetup = RTT+2Ts

(1− p

1− 2p− 1), (6)

Nagaraja Thanthry et al. 9

where

RTT = min(RTT1, RTT2, RTT3, . . .RTTn

)(7)

is the minimum RTT among all the available paths, and p isthe loss probability of the path corresponding to the mini-mum RTT.

In an ideal situation, with no packet losses, the total timerequired to transferN packets from source to destination de-pends on the maximum congestion window size, time re-quired to reach the peak transmission rate, and number ofpackets itself. Equation (8) [10] represents the total time re-quired to transmit N packets from source to destination. Ascan be observed from this equation, when the total numberof packets to be transmitted is greater than the total num-ber of packets that could be transmitted until the congestionwindow (cwnd) reaches the maximum congestion windowsize (Wmax), the time required to transmit all the packets alsodepends upon the maximum congestion window size.

Tnl =

⎧⎪⎪⎪⎪⎪⎨

⎪⎪⎪⎪⎪⎩

[2 log2

(2N + 4 + 3

√2

2√2 + 3(2)5/8

)]RTT if N ≤ Nexp,

[nwmax +

[N −Nexp

Wmax

]]RTT otherwise,

(8)

where nwmax is the number of rounds required by the TCP

to reach congestion window of Wmax, and Nexp is the ex-pected number of packets transmitted until the TCP conges-tion window reaches the maximum congestion window sizeWmax,

nwmax =[

2 log2

(2Wmax

1 +√2

)]

,

Nexp =[2(nwmax+1)/2 + 3(2)(4nwmax−3)/8 − 2− 3

√2

2

]+Wmax.

(9)

Equation (10) represents the corresponding data trans-fer time when the TCP flow experiences a single packetloss. Here, tnl(i) represents the time required to transmitfirst y packets without any drops, tlin(a, b) represents thetime required to transmit a packets during the congestion-avoidance mode with a congestion window size of b, andE[TO] represents the timeout period experienced by the TCPflow. In the case of fast retransmit, TCP experiences timeoutfor congestion windows less than 4 [11]. TCP will recognizea packet drop only when it receives multiple duplicate ac-knowledgments (typically 3) [12]. When congestion windowis less than 4, there cannot be 3 duplicate acknowledgments.The only way to identify a packet drop is due to timeout ofan acknowledgment,

tsl =

⎧⎪⎪⎪⎨

⎪⎪⎪⎩

[tnl(y) + E[To] + tlin(N − k − 1, 2) + 1

]RTT if y ≤ 6,

[tnl(y) + 1 + tlin(N − k,n) + 1

]RTT if nmax(y)− y < 3

[tnl(y) + 1 + tlin(N − k,n)

]RTT otherwise

if y > 6,(10)

tlin(a, b) =

⎧⎪⎪⎪⎪⎨

⎪⎪⎪⎪⎩

[a− x(x + 1) + b(b− 1)

x + 1

]+ 2x − 2(b− 1) if a ≤Wmax

(Wmax + 1

)− b(b− 1),

[a−Wmax

(Wmax+1

)+ b(b− 1)

Wmax

]+ 2Wmax − 2(b − 1) otherwise,

E[TO] = TO2(1 + p + 2p2 + 4p3 + 8p4 + 16p5 + 32p6

)

1− p.

(11)

In the event of multiple packet losses, the total data trans-fer time also depends upon the time interval between packetdrops. Equation (12) [10] represents the delay involved intransmitting N datagrams across the network in the pres-ence of multiple packet losses. Here, tsl(y) represents thetime required to transmit the first y packets with a singleloss, and tfr(l) represents the time delay involved in transmit-ting remaining packets in the congestion-avoidance mode.The point to be noted here is the fact that once the TCPenters the congestion-avoidance mode, the congestion win-dow will be set to half of its previous value. Hence, the totaltime required will be much higher than the single packet loss

case:

tml(N) = E{tsl(m− 1)

}+ E{(M − 2)tto

(Dave

)}

+ E{(M − 2)tfr

(Dave

)},

(12)

tfr(l) =

⎧⎪⎪⎪⎪⎨

⎪⎪⎪⎪⎩

[2 + tlin

(Dave − k,

[h

2

])]RTT if h− j < 3,

[1 + tlin

(Dave − k,

[h

2

])]RTT otherwise,

tto(l) =[E[TO]− I( j > 1)− tlin

(Dave − h, 2

)]RTT .

(13)

10 EURASIP Journal on Wireless Communications and Networking

Here,M represents the number of loss occurrences whiletransmittingN packets andDave represents the average num-ber of packets transmitted between two successive losses. Us-ing (6), (8),(10), and (12), the total time required to transferN packets across the network can be estimated as

Ttransfer(N)

= tsetup + (1− p)Ntnl(N)

+ p(1− p)N−1E{tsl(N)

}+ tml(N) + tdack.

(14)

Equations (8), (10),(12), and (14) were developed by theauthors of [10] for analyzing TCP performance primarily ina single-path environment. However, this could be extendedto analyze TCP performance in a multipath environment.

5.1. TCP performance inmultipath environment

In a multipath environment, normal TCP implementationssuffer performance degradations due to the fact that fromthe TCPs perspective, it is still a single path, that is, multi-path routing is transparent to the TCP layer. Hence, a packetdrop in one path affects the overall performance of the entiresystem.

5.1.1. TCP connection setup time

The following equation:

tSetup = RTTi +2Ts

(1− pi1− 2pi

− 1)

(15)

represents the TCP connection setup time in the case of amultipath environment. As can be observed from this equa-tion, the TCP setup time depends upon the RTT and packetdrop probability of the path assigned by the network layer.This is similar to the normal single-path environment wherethe TCP connection is established using the best availablepath, that is, the path suggested by the network layer. Forpurposes of this analysis, the authors assume that the pathsuggested by the network layer has the lowest RTT. Then thetotal connection setup time is similar to the single-path rout-ing scenario. The connection setup time also depends uponthe packet drop probability pi of the path selected for theconnection setup process.

5.1.2. Data transmission delay

While the TCP setup time in the case of a multipath routingenvironment is similar to the single-path routing environ-ment, the data transfer delay varies significantly. Equation(16) represents the corresponding total data transfer time forN packets. In this case, pi represents the maximum packetdrop probability among all the paths that are used to trans-mit the data. As one of the paths being used becomes con-gested/unavailable, it adversely affects the performance ofthe entire TCP flow, irrespective of the performance demon-strated by other paths. In the case of ad hoc networks, pathunavailability leads to another route discovery process, which

further deteriorates ad hoc network performance:

Ttransfer(N) = tsetup +(1− pi

)Ntnl(N)

+ pi(1− pi

)N−1E{tsl(N)

}

+ tml(N) + tdack + trecorder,

(16)

pi = max(p1, p2, p3, . . . , pn

). (17)

Compared to the single-path data transfer, multipathdata transfer also induces additional delay in terms of packetreordering. In a multipath environment with load balancingcapabilities, it is highly likely that packets travel through var-ious paths to reach a destination. Depending on the amountof delay experienced by the path, the packets may reach thedestination out of order. One of the functionalities of theTCP layer is to check for packet sequence numbers and ar-range them in the proper order so that data can be presentedto higher layers. Packet reordering requires that datagramswait in the queue for some time before all the packets (of aparticular sequence) arrive at the destination. This delay isreferred to as packet reordering delay (treorder).

Another important aspect to note here is the fact that ina multipath environment, the RTT is calculated as the av-erage RTT of all available paths. This is because datagramsfrom source to destination could get routed through onepath while the acknowledgments could take a different path.Hence, the effective RTT is the average RTT of the forwardpath and the reverse path:

RTT =∑n

i=1 RTTi

n. (18)

5.2. TCP performance in proposed scheme

5.2.1. TCP connection setup time

In the case of the proposed scheme,multiple connections willbe set up between source and destination. The setup processwill be complete only after the connection using the slowestpath is complete. Hence, the total time involved in setting upthe connection can be expressed as

tsetup = max(RTTi +2Ts

(1− pi1− 2pi

− 1))

, (19)

where RTTi represents the round-trip time of the path cho-sen for ith connection, and pi represents the correspondingpacket drop probability. Compared to the normal multipathrouting scheme, the proposed scheme takes longer time insetting up TCP connections.

5.2.2. Data transmission delay

Data transmission delay is one of the major areas wherethe proposed scheme gains over the traditional multipathscheme. Contrary to the traditional multipath scheme, theproposed scheme establishes multiple connections at thetransport layer itself. This is done in cooperation with thenetwork layer, with the understanding that the networklayer forwards the packets belonging to different connections

Nagaraja Thanthry et al. 11

through different paths. The amount of traffic to be for-warded through an individual path is decided based on theRTT, packet drop statistics, and queue status correspondingto that path at that instance. Since the scheduler changes thetraffic share through individual paths adaptively, the effectof one path failure will be minimal on overall TCP perfor-mance. Equation (20) represents the expected time delay intransmitting N packets from source to destination:

Ttransfer(N) = tsetup + tdack + treorder

+n∑

i=1

((1− pi

)Ni tnl(Ni)

+ pi(1− pi

)Ni−1E{t(Ni)}

+ tml(Ni)).

(20)

Here, Ni represents the number of packets transmittedthrough path i, and pi represents the packet drop probabilityof that path. Since these connections are set up independentof each other, a packet drop in one path will not affect flowon the other. When a packet is dropped, the TCP enters thecongestion-avoidance mode only for that flow. This reducesthe overall data rate by a small fraction, as compared to tra-ditional multipath routing where a single packet drop resultsin a large data rate reduction (almost 50%). However, thepacket drop in one pathmay result inmore packets being for-warded through the other paths, resulting in higher resourceutilization in that path. However, the effect of such rerout-ing is minimal on overall TCP performance, as compared toTCP behavior in a traditional multipath environment. Whilethe proposed protocol requires the TCP to reorder the pack-ets (out-of-order delivery of packets is common in a multi-path environment), the authors argue that the delay associ-ated with packet reordering will have lesser impact on overallTCP performance, as compared to reduction of the conges-tion window. Also, the effect of out-of-order delivery in theproposed protocol is not similar to traditional TCP as theconnection is managed by individual flows where packets aredelivered in order. Reordering has to be done only when datahas to be delivered to the upper layers.

While the proposed scheme improves overall TCP per-formance, it is associated with certain overhead such as ad-ditional memory, reordering delay at the receiver, and flow-splitting delay at the transmitter. In order for the TCP to han-dle each of the flows separately, a larger buffer space is re-quired. Each flow must be associated with a separate bufferspace that is similar to the original TCP connection. Hence,in the proposed scheme, thememory requirement can be cal-culated as

Memory = n∗MTCP, (21)

where n is the number of connections established, andMTCP

is the memory required by the original TCP connection.With recent advances in the portable communication de-vices, the authors assume that allocation of additional mem-ory should not be a great concern. Also, based on availablesystem resources, it is possible to restrict the number of pathsto be used in the proposed protocol. Optimizing the buffersize would also improve the performance at a lower cost.

S

A

B

F

H

RC K

G L I

D E J

Figure 7: Sample ad hoc network with random topology.

While the protocol is associated with certain additionaldelays, it is assumed that these delays are very small and canbe ignored, considering the performance benefits providedby the proposed protocol. Also, these delays will be heavilydependent on implementation.

Example 1. Consider an ad hoc network with nodes placed ina random manner (Figure 7). Let S be the sender node hav-ing infinite number of packets to send, and R the receivernode. Assume that all nodes are using the 802.11b chan-nel access mechanism and can transmit data at the rate of11Mbps. From Figure 7, it can be seen that there are threedistinct paths (S-A-B-F-H-R), (S-C-K-G-L-I-R), and (S-D-E-J-R), with different costs between the source and destina-tion.

In the current scenario, assume that the optimal path(S-D-E-J-R) between S and R is over utilized and can offeronly 4Mbps of bandwidth for the TCP flow under test. If apacket size of 50 Kb is assumed, then the optimal path cancarry nearly 80 packets per second, which can be consideredas the maximum throughput attainable for the data transfer.However, if a packet loss occurs in the network, then the con-gestion window size is reduced to half. This, in turn, resultsin a reduction of the data transfer rate to half of its originalvalue, that is, 40 packets per second. Subsequent packet dropsfurther reduce the data rate. Hence, the average throughputachieved by the data transfer will be much less than the max-imum throughput, that is, 80 packets per second and can beapproximated to be around 40 packets per second.

An interesting point to note here is that even if multiplepaths are considered between the source and the destination,the performance may not improve. Since only a single flow isused, a packet drop in any path will trigger a reduction in thedata rate, thereby reducing throughput.

Now consider the proposed scheme. Assume the exis-tence of three distinct paths between S and R, which is afair probability in a large network. Let one of the paths bethe optimum path, as in the last case, with a capacity of 80packets per second, and let the other two have lower capac-ity, that is, 40 packets per second and 60 packets per sec-ond. The proposed protocol establishes three flows, each us-ing one of the three available paths. Therefore, the maximum

12 EURASIP Journal on Wireless Communications and Networking

throughput of the data transfer is the cumulative capacity ofall the paths, that is, 180 packets per second. This will be theupper limit for the throughput. Compared to the previouscase, the throughput is much higher. If congestion occurs inthe primary path, the data transfer rate in that path alone isreduced to half or even less. However, the overall through-put will still be more than 100 packets per second, which ishigher than the maximum throughput attainable in the pre-vious case. If all paths are considered to have congestion andtheir data rate is reduced to half, then the overall throughputof the proposed scheme is at 90 packets per second, whichis higher than the throughput of the original scheme. Theprobability of all paths failing at the same time is consideredto be less, especially if the paths are distinct. Therefore, if oneof the paths fails, then it will not influence the congestionwindow of other paths.

6. RESULTS ANDDISCUSSION

In this section, the authors compare the performance of theproposed protocol with that of normal single path and mul-tipath TCP. The simulations were run using MatLab 7.0. Fol-lowing values were considered for various parameters:

(i) RTT {40, 30, 20, 15, 45, 70};(ii) packet drop probability {0.05, 0.018, 0.023, 0.25,

0.097, 0.086};(iii) timeout value = 250ms;(iv) TS = 150ms;(v) H = 10, J = 4.

Figure 8 presents the total data transfer time for all threeapproaches under different load conditions. From the figure,it can be inferred that the proposed protocol outperformsboth single-path and multipath TCP in the case of higherpacket drop probability scenarios. However, at low packetdrop probability scenarios single-path approach works bet-ter. Figure 8(a) represents the total data delivery delay varia-tion with respect to different data size when all paths haveequal packet drop probability (0.05) and equal round-triptime (40ms). Figure 8(b) also represents the same results asFigure 8(a), but with emphasis on the performance variationof single-path and normal multipath environment. Fromthese two graphs, it is evident that when all paths have similarcharacteristics, TCP based on single path outperforms oth-ers. This is due to the fact that with single path, most of thepackets get delivered in order and packet realignment timeis very negligible. However, in the proposed scheme, delaydue to packet reordering and delay due to packet schedul-ing play an important role and hence affect the overall per-formance compared to single-path and traditional multipathapproaches.

Figures 8(c), 8(d), and 8(e) present the results corre-sponding to different packet drop probabilities. Figures 8(f),8(g), and 8(h) present the total packet transfer delay for apacket drop probability of 0.15, round-trip time of 40ms,and different window size. All the results presented confirmthe fact that when all paths have similar characteristics, TCPsingle-path approach provides the best results. At the same

time, it can also be observed from the results that as thepacket drop probability increases, the proposed approachstarts performing better compared to the traditional multi-path approach. This is because each packet drop (in any path)results the traditional multipath TCP to get into congestion-avoidance mode. On the other hand, in the case of proposedapproach, packet drop in one path affects only the perfor-mance of the TCP connection through that path. Also thescheduling algorithm will consider the affect of congestionwhile deciding the traffic share that needs to be sent via anypath thereby reducing the overall effect of packet drops.

Figure 9 presents the total data transfer time in a nor-mal situation (with different packet drop probabilities anddifferent round-trip times) under different load conditions.The results presented in Figure 9 confirm the previous trend,that is, under low packet drop probability, TCP single-pathapproach provide better results compared to other two ap-proaches. However, as the number of packets to be trans-ferred increases and packet drop probability of the best path(lowest RTT path) increases, the proposed approach outper-forms both TCP single-path and traditional multipath ap-proaches. This is due to the fact that, in the proposed ap-proach traffic is shared between all available paths based ontheir respective RTT (instantaneous), packet drop probabil-ity (instantaneous), and current status of the TCP connec-tion. This ensures that the effect of packet drop in one pathdoes not affect the overall data transfer process to a largerextent.

Figure 10 lists the proposed approach performanceagainst TCP single-path and traditional multipath approach-es under varying packet drop probability conditions. Totalnumber of packets to be transferred was kept constant at5000 packets and TCP window size was fixed at 16. The re-sults indicate that as the packet drop probability of the bestpath (lowest RTT) increases, the TCP single-path and tradi-tional multipath approaches suffer performance degradationto a larger extent compared to the proposed approach. Thisis because, as stated earlier, the scheduling algorithm in theproposed approach detects the congestion in one path anddirects traffic through other paths. Even compared to thetraditional multipath approach, TCP single path performsbetter due to the fact that after successive packet drops, theTCP enters congestion-avoidance mode quickly and entersthe slow start mode. However in the case of multipath, be-fore the TCP process realizes the packet drop, it would havealready transmitted several packets which results in retrans-mission. Figures 10(e) and 10(f) present the performance ofall the three approaches when the packet drop probability ofa secondary path is varied. Again, similar to previous results,at low packet drop probability, TCP single-path approachperforms better and as the packet drop probability increases,the proposed approach performs better than the other two.

While the above results indicate that the TCP single-pathapproach is better in the case of low packet drop conditions,it is not applicable in all situations. The above simulation re-sults do not consider the resource availability along the path.Also, in the case of ad hoc networks, a route failure in thebest path may result in high amount of delay for the data

Nagaraja Thanthry et al. 13

×10614

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP single path &TCP multipath

TCP-M

(a)

×106

1.083

1.082

1.081

1.08

1.079

1.078

1.077

1.076

1.075

619 620 621 622 623 624 625

TCP single path

TCP multipath

(b)

×1075

4.5

4

3.53

2.5

2

1.5

1

0.5

00 10 20 30 40 50 60 70 80 90 100

×102

TCP single path &TCP multipath

TCP-M

(c)

×10714

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP single path

TCP-M

(d)

×1083.5

3

2.5

2

1.5

1

0.5

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP-M

TCP single path

(e)

×10714

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP single path

TCP-M

(f)

×10714

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP single path

TCP-M

(g)

×10714

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP-M

TCP single path

(h)

Figure 8: Total data transmission delay with respect to different traffic loads with all paths having same characteristics. (a) & (b) Packet dropprobability = 0.05, TCP window = 16, RTT = 40ms. (c) Packet drop probability = 0.1, TCP window = 16, RTT = 40ms. (d) Packet dropprobability = 0.01, TCP window = 16, RTT = 40ms. (e) Packet drop probability = 0.3, TCP window = 16, RTT = 40ms. (f) Packet dropprobability = 0.15, TCP window = 16, RTT = 40ms. (g) Packet drop probability = 0.15, TCP window = 32, RTT = 40ms. (h) Packet dropprobability = 0.15, TCP window = 64, RTT = 40ms.

transmission as the source needs to discover the alternatepath and reestablish the connection. Also, this kind of ap-proach would result in underutilization of some links in thenetwork. Compared to that, the proposed approach providesa balanced performance under all conditions. Under low

packet drop scenarios, its performance is comparable to theTCP single-path approach and is better than the traditionalmultipath approach. Under highly unreliable network sce-nario, the proposed approach outperforms both TCP single-path and traditional multipath approaches.

14 EURASIP Journal on Wireless Communications and Networking

×10714

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP-M

TCP single path

(a)

×10714

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP-M

TCP single path

(b)

×10714

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP-M

TCP single path

(c)

×10714

12

10

8

6

4

2

00 10 20 30 40 50 60 70 80 90 100

×102

TCP multipath

TCP-M

TCP single path

(d)

Figure 9: Total data transmission delay with respect to different traffic loads under general conditions. (a) Packet drop probability = 0.05,TCP window = 16, RTT = 40ms. (b) Packet drop probability = 0.15, TCP window = 16, RTT = 40ms. (c) Packet drop probability = 0.20,TCP window = 16, RTT = 40ms. (d) Packet drop probability = 0.30, TCP window = 16, RTT = 40ms.

7. CONCLUSION

In this paper, the authors have analyzed various parametersthat affect the performance of TCP in an ad hoc network en-vironment. Congestion and path nonavailability are two ma-jor factors that affect TCP performance. It was also observedthat, in the presence of multiple paths, TCP performance de-grades when one of the paths used for forwarding data dropsa packet. In the current paper, the authors have proposed es-tablishing multiple connections for every data transfer be-tween the source and the destination. The proposed mech-anism would be transparent to the application and sessionlayers; however, it involves the transport layer in multipathrouting scheme.

The analysis carried out by the authors indicates a sig-nificant improvement in overall performance. While the per-formance of the proposed protocol is slightly inferior to thestandard TCP or TCP in the presence of multiple paths when

the network is stable, it proves beneficial in the presence ofnetwork congestion and packet losses. This analysis also in-dicates that a packet drop in one of the paths does not af-fect the overall performance of TCP flow in a larger scheme.Even though the protocol has some additional costs in termsof memory and delay, the authors argue that performancebenefits associated with the protocol overshadow costs. Theauthors also note that the protocol performs better in thepresence of multiple paths between the source and the des-tination, and that the paths are disjoint.

One of the disadvantages of the proposed protocol liesin its memory requirements, whereby each data transfer re-quires memory in multiples of the number of connectionsestablished. The authors assume that the memory allocationwill not cause any issue as, at system level, the proposed ap-proach is similar to having multiple simultaneous TCP ses-sions with the same destination. However, at the server end,this could cause performance issues if the TCP session lasts

Nagaraja Thanthry et al. 15

×1077

6

5

4

3

2

1

00 5 10 15 20 25 30 35 40 45 50

×10−2

TCP multipath

TCP single path

TCP-M

(a)

×10714

12

10

8

6

4

2

00 5 10 15 20 25 30 35 40 45 50

×10−2

TCP multipath

TCP single path

TCP-M

(b)

×1083.5

3

2.5

2

1.5

1

0.5

00 5 10 15 20 25 30 35 40 45 50

×10−2

TCP multipath

TCP single path

TCP-M

(c)

×1087

6

5

4

3

2

1

00 5 10 15 20 25 30 35 40 45 50

×10−2

TCP multipath

TCP single path

TCP-M

(d)

×1077

6

5

4

3

2

1

00 5 10 15 20 25 30 35 40 45 50

×10−2

TCP multipath

TCP single path

TCP-M

(e)

×1077

6

5

4

3

2

1

00 5 10 15 20 25 30 35 40 45 50

×10−2

TCP multipath

TCP single path

TCP-M

(f)

Figure 10: Total data transmission delay with respect to different packet drop probabilities under general conditions. (a) TCP window = 16,RTT (best path) = 40ms. (b) TCP window = 16, RTT (best path) = 40ms. (c) TCP window = 16, RTT (best path) = 40ms. (d) TCPwindow = 16, RTT (best path) = 40ms. (e) Packet drop probability (best path) = 0.15, TCP window = 16, RTT (best path) = 40ms. (f)Packet drop probability (best path) = 0.25, TCP window = 16, RTT (best path) = 40ms.

longer and the memory allocated for one session is not freedat due time. The fine tuning of the memory allocation policyis beyond the scope of this article. Another area where theproposed protocol introduces overhead compared to TCPsingle-path and traditional multipath approaches is controldata. Compared to TCP single path and traditional multi-path, the proposed approach will generate higher number ofconnection establishment/connection maintenance packets.But the number of packets generated during the data transferstill remains the same. As a matter of fact, the authors arguethat the additional control packets generated in the proposedapproach is negligible compared to the amount of retrans-missions saved by the proposed approach.

In the proposed scheme the authors assumed that the de-lays at the source and destination sides due to modificationswould be negligible, but it would be interesting to study theseeffects at the system level. Also, the proposed scheme requiresmodifications to the existing TCP implementation.

REFERENCES

[1] B. Atkin and K. P. Birman, “Evaluation of an adaptive trans-port protocol,” in Proceedings of 22nd Annual Joint Conference

of the IEEE Computer and Communications Societies (INFO-COM ’03), vol. 3, pp. 2323–2333, San Francisco, Calif, USA,March-April 2003.

[2] K. Chandran, S. Raghunathan, S. Venkatesan, and R. Prakash,“A feedback based scheme to improving TCP performance inad-hoc wireless networks,” in Proceedings of 18th InternationalConference on Distributed Computing Systems, pp. 472–479,Amsterdam, The Netherlands, May 1998.

[3] T. D. Dyer and R. V. Bopanna, “A comparison of TCP per-formance over three routing protocols for mobile ad hoc net-works,” in Proceedings of the 2nd International Symposium onMobile Ad Hoc Networking and Computing (MobiHoc ’01), pp.56–66, Long Beach, Calif, USA, October 2001.

[4] H. Lim, K. Xu, and M. Gerla, “TCP performance over mul-tipath routing in mobile ad hoc networks,” in Proceedings ofIEEE International Conference on Communications (ICC ’03),vol. 2, pp. 1064–1068, Anchorage, Alaska, USA, May 2003.

[5] S. Mao, D. Bushmitch, S. Narayanan, and S. S. Panwar,“MRTP: a multi-flow real-time transport protocol for ad hocnetworks,” in Proceedings of the IEEE Semiannual VehicularTechnology Conference (VTC ’03), Orlando, Fla, USA, October2003.

[6] K. Sundaresan, V. Anantharaman, H.-Y. Hsieh, and R. Sivaku-mar, “ATP: a reliable transport protocol for ad-hoc networks,”in Proceedings of ACM International Symposium on Mobile Ad

16 EURASIP Journal on Wireless Communications and Networking

Hoc Networking and Computing (MOBIHOC ’03), Annapolis,Md, USA, June 2003.

[7] M. K. Marina and S. R. Das, “On-demand multipath distancevector routing in ad hoc networks,” in Proceedings of the In-ternational Conference for Network Protocols (ICNP ’01), pp.14–23, Riverside, Calif, USA, November 2001.

[8] S.-J. Lee and M. Gerla, “SMR: split multipath routing withmaximally disjoint paths in ad hoc networks,” Tech. Rep.,Computer Science Department, University of California, LosAngeles, Calif, USA, August 2000.

[9] S. Bohacek, J. P. Hespanha, J. Lee, C Lim, and K. Obraczka,“TCP-PR: TCP for persistent packet reordering,” in Proceed-ings of 23rd International Conference on Distributed ComputingSystems, pp. 222–231, Providence, RI, USA, May 2003.

[10] B. Sikdar, S. Kalyanaraman, and K. S. Vastola, “Analytic mod-els and comparative study of the latency and steady-statethroughput of TCP Tahoe, Reno and SACK,” in Proceedingsof IEEE Global Telecommunications Conference (GLOBECOM’01), San Antonio, Tex, USA, November 2001.

[11] R. Morris, “Scalable TCP congestion control,” in Proceedingsof the 9th Annual Joint Conference of the IEEE Computer andCommunications Societies (INFOCOM ’00), vol. 3, pp. 1176–1183, Tel-Aviv, Israel, March 2000.

[12] W. R. Stevens, “TCP Slow Start, Congestion Avoidance, FastRetransmit, and Fast Recovery Algorithms,” RFC2001, IETF,1997, http://rfc.sunsite.dk/rfc/rfc2001.html.

Nagaraja Thanthry is a Ph.D. student inthe Department of Electrical and ComputerEngineering, Wichita State University. Hehas received his B.S. degree in electronicsand communication from Mysore Univer-sity, India, in 1997, and M.S. degree in elec-trical engineering from Wichita State Uni-versity, in 2002. He is a student member ofIEEE. His research interests include ad hocnetworks, multiservice over IP, aviation datanetworks, quality of service, and security.

Anand Kalamkar has completed his M.S.degree in electrical engineering at WichitaState University in 2004. He received his B.S.degree in electrical engineering from Nag-pur University, India, in 2001. He is cur-rently working with AT&T as a Data Sup-port Engineer. His research interests includead hoc networks and quality of service.

Ravi Pendse is an Associate Vice Presidentfor Academic Affairs and Research, CiscoFellow, and Director of Advanced Network-ing Research Center at Wichita State Uni-versity. He has received his B.S. degree inelectronics and communication engineer-ing from Osmania University, India, in1982, M.S. degree in electrical engineeringfrom Wichita State University, in 1985, andPh.D. degree in electrical engineering fromWichita State University, in 1994. He is a Senior Member of IEEE.His research interests include ad hoc networks, multiservice overIP, and aviation security.