Analysis of the Interaction between TCP Variants and Routing Protocols in MANETs

Analysis of the Interaction between TCP Variants and Routing Protocols inMANETs�

Dongkyun Kim, Hanseok Bae, Jeomki SongDepartment of Computer Engineering

Kyungpook National University, Daegu, [email protected], �bae, cloud21�@monet.knu.ac.kr

Juan-Carlos CanoDepartment of Computer Engineering

Polytechnic University of Valencia, [email protected]

Abstract

IETF MANET (Mobile Ad Hoc Network) working grouphas standardized AODV (Ad Hoc On-demand Distance Vec-tor) and OLSR (Optimized Link State Routing) as its reac-tive and proactive routing protocols, respectively. In addi-tion, from the transport layer’s perspective, TCP (Transmis-sion Control Protocol) is still needed for MANET since it iswidely used in the current Internet and suitable for smoothintegration with the fixed Internet. Particularly, TCP hasits variants, namely TCP-Reno and TCP-Vegas. However,there has been no research work on extensive performancecomparison of TCP-Reno and TCP-Vegas over AODV andOLSR. This paper is the first trial to perform the researchby using ns-2 simulator. Through the extensive simula-tions, we found that which to select among routing proto-cols is more important than which to select among TCPvariants, because the performance difference between TCP-Reno and TCP-Vegas over any selected routing protocol isnot so much outstanding.

1 Introduction

Recently, research interest in the MANET (Mobile AdHoc Networks) has increased because of the proliferationof small, inexpensive, portable and mobile personal com-puting devices. A MANET is viewed as a special networkwhere all nomadic nodes are able to communicate with each

�This work was supported by grant No. R05-2004-000-10307-0 fromKorea Science & Engineering Foundation. This work was also partiallysupported by the Ministerio de Educacion y Ciencia, Spain, under GrantTIN2004-03678-C02-01.

other through packet forwarding by the intermediate nodes.The IETF MANET working group [1] has standardizedOLSR (Optimized Link State Routing) [2] and AODV (AdHoc On-Demand Distance Vector) [4] as its proactive andreactive routing protocols, respectively. In proactive pro-tocols like OLSR and DSDV (Destination-Sequenced Dis-tance Vector) [5], all nodes should maintain their rout-ing tables for all possible destinations, without regard tothe actual desire for the route between source and destina-tion nodes. However, in reactive routing protocols such asAODV and DSR (Dynamic Source Routing) [3], only whena source node needs to send data packets to the destinationnode, it attempts to acquire the path in on-demand manner.Reactive approaches avoid the need of maintaining routingtables when there are no desires of routes between source-destination pairs.

In addition to the above-mentioned network layer pro-tocols, a transport layer protocol like TCP (TransmissionControl Protocol) is also needed to provide reliable end-to-end message transmission. TCP is still needed for MANETssince it is widely used in the current Internet and we wouldlike to achieve a smooth integration with the fixed Inter-net. In particular, TCP has its variants such as TCP-Renoand TCP-Vegas. In the fixed Internet, some research worksholds that TCP-Vegas is better than TCP-Reno. Researchinterest in finding more suitable TCP variant for MANEThas increased. However, most of research works evaluatedTCPs over one selected routing protocol, or evaluated therouting protocols with one chosen TCP. Recently, some re-search performed the comparison of TCPs over AODV andDSDV [13]. Although the authors selected DSDV as aproactive routing protocol, OLSR is getting more attentionbecause it has been standardized in IETF. However, to the

Proceedings of the 2005 International Conference on Parallel Processing Workshops (ICPPW’05)

1530-2016/05 $20.00 © 2005 IEEE

best of our knowledge, this paper is the first trial to exten-sively compare the two TCPs over AODV and OLSR. Al-though much research work performed some modificationsto the current TCP in order to improve the TCP performancefor MANET [6, 8, 9, 10], prior to such researches, we be-lieve that it is more important to know that which TCP vari-ant is suitable for which routing protocol.

The rest of this paper is organized as follows. Section2 describes the key operations of routing protocols (AODVand OLSR) and TCP variants (TCP-Reno and TCP-Vegas)compared in this paper. Section 3 presents the extensiveperformance comparison of TCP-Reno and TCP-Vegas overAODV and OLSR by using ns-2 network simulator. Section4 describes some trials to modify the existing TCPs in orderto improve TCP performance for MANET along with ourfuture work. Finally, some concluding remarks are given inSection 5.

2 Routing Protocols and TCPs compared

2.1 AODV (Ad hoc On-demand Distance Vector)

In AODV, a typical reactive routing protocol, when asource needs to send data packets to the destination, itinitiates a route discovery procedure by broadcasting anRREQ (Route REQuest) message in on-demand manner.The RREQ message contains Broadcast ID in order to avoidunnecessary retransmission of duplicate RREQ message.The Broadcast ID increases by 1 whenever a new RREQ isflooded in order to acquire a new path. Each node comparesthe Broadcast ID contained in a received RREQ messagewith the stored Broadcast ID contained in the RREQ mes-sage received before from the same source. If the BroadcastID is greater than the stored one, the RREQ message is re-broadcasted and the node from which it is broadcasted isrecorded into the routing table as the next node towards thesource. Otherwise, the RREQ message is silently discarded.During this flooding of the RREQ message, a destinationor an intermediate node which knows the path towards thedestination responds to the RREQ message by unicastingan RREP (Route REPly) message back to the source. Afteracquiring a route, the source starts sending the data packetand each intermediate node can forward the packet by look-ing up its routing entries. When a route breakage occursduring data transmission, the intermediate node which de-tected the route breakage executes a local discovery or sendsan RERR message towards the source. When receiving theRERR message, the source attempts to acquire a new routeby performing the aforementioned route discovery proce-dure.

2.2 OLSR (Optimized Link State Routing)

Most proactive routing protocols create routing infor-mation periodically through blind flooding technique. InOLSR, however, a node requires a subset of nodes , calledMPR (Multi-Point Relay) set, instead of all nodes withintwo-hop distance from itself to re-broadcast its TC (Topol-ogy Control) message in order to provide all nodes withintwo-hop distance with the message.

Multipoint Relays

A

B

C

D

E

F

G

H

I

Figure 1. An Example of the MPR set in OLSRprotocol.

For example, as shown in Figure 1, node A can create itsMPR set consisting of nodes C and E, whose rebroadcastingcan cover all nodes within two-hop distance from node A.

Every node in the network exchanges hello message withits neighboring nodes every hello intervals. The hello mes-sage also contains a list of nodes which are reachable withinone-hop distance from itself. Therefore, the MPR set canbe determined on the basis of the hello message. Using theMPR set, OLSR enables the network to reduce the trafficfor allowing each node to build its topology table createdwith link state information gathered from all nodes. In par-ticular, only the nodes which are selected as an MPR nodeof other nodes can construct their TC message. The TCmessage sent from a node also contains only the links withthe nodes which selected itself as their MPR node (calledMPR selector), instead of its all one-hop physical links. Inaddition, during the propagation of the TC message, onlythe MPR nodes participate in rebroadcasting the receivedTC message. Finally, with the topology table, each nodecan create its routing tables for all possible destinations. Aroute recovery relies on the propagation of a TC messagewith changed link state information.

2.3 TCP-Reno

TCP-Reno is the most widely used TCP variant withthree functions: Slow Start, Congestion Avoidance and FastRecovery. Slow Start is activated at the start of TCP con-nection or when a timeout event occurs. During Slow

Proceedings of the 2005 International Conference on Parallel Processing Workshops (ICPPW’05)

1530-2016/05 $20.00 © 2005 IEEE

Start phase, the congestion window size (called CWND)increases exponentially until a Slow Start threshold fromwhich CWND increases linearly. The period during whichCWND increases linearly is called Congestion Avoidancephase. In TCP-Reno, a lost packet is detected and retrans-mitted when triple duplicate ACKs are received (called FastRetransmit) or a timeout event occurs at the sender. For atimeout event, TCP considers a serious congestion and en-ters Slow Start phase. On the other hands, after Fast Re-trasmit, Fast Recovery phase to cancel the Slow Start phaseand increase its CWND linearly thereafter is executed.

2.4 TCP-Vegas

Unlike TCP-Reno which increases its CWND until apacket loss is detected, TCP-Vegas however utilizes thecongestion avoidance mechanism to avoid packet loss bydecreasing its CWND as soon as it detects an incipient con-gestion. In TCP-Vegas, CWND is determined by differencebetween expected throughput and actual throughput as fol-lows.

�������� � ������ ���������������

������ � ������ �����������������

���� � �������������������������

, where ������� is the minimum of all measured ��� s.TCP-Vegas defines two thresholds, namely � and �. If���� is � �, it considers the absence of congestion and in-creases its CWND by 1. If���� is� �, it expects an incip-ient congestion and decreases its CWND by 1. Otherwise, itkeeps the current CWND. For the purpose of retransmittinglost packets, TCP-Vegas maintains fine-grained RTO (Re-transmission Time-Out) value for each transmitted packet,which is used to determine the occurrence of a timeout eventwhen a duplicate ACK for a corresponding packet is re-ceived. If the timeout event occurs, the TCP sender thinksthat the packet is lost and retransmits it without waiting foradditional duplicate ACKs.

3 Performance Evaluation

We conducted performance evaluation by using ns-2simulator [16]. In this paper, ”Random waypoint” modelwas adopted to simulate nodes movement, where the mo-tion is characterized by two factors: the maximum speedand the pause time. Each node starts moving from its ini-tial position to a random target position selected inside thesimulation area. The node speed is uniformly distributedbetween 0 and the maximum speed. When a node reachesthe target position, it waits for the pause time, then selectsanother random target location and moves again. Therefore,

we simulated node mobility by varying the maximum speedand pause time.

For the simulations, 50 nodes were initially positioned atrandom location over 1000 m x 1000 m area. Each simula-tion is 500 seconds long. Also, every node has its limitedtransmission range of 250 meters. Additionally, 2 MbpsWireless LAN was used as lower protocol.

In particular, Hello INTERVAL of 2 seconds andTC INTERVAL of 5 seconds were used for Hello and TCintervals, respectively, which are OLSR-related parameters.

A TCP connection for a random pair of sender and re-ceiver was selected with the background traffic of five UDPconnections. We averaged 20 different mobility scenariosto obtain each result.

In addition, for the purpose of showing the sequencingof TCP segments and the progress of CWND change, thesimulation results using the maximum speed of 15 m/s areshown as examples.

First, we measured the throughput of TCP-Reno overAODV and OLSR according to node mobility. Irrespectiveof node mobility, TCP-Reno showed off better throughputover OLSR than AODV (see Figure 2).

A long latency of route discovery due to route breakagein AODV causes TCP sender to experience many timeoutevents before acquiring a new path and TCP sender there-fore reduces its CWND because it regards the situation ascongestion. However, OLSR forces a node with changedlink topology to promptly flood the change in order to al-low other nodes to update their topology tables. Therefore,every node using OLSR finds another next-hop node to-wards the destination quickly and then continues transmit-ting its TCP segments before a timeout event occurs. Un-like AODV, it results in avoiding unnecessary reduction ofCWND. Particularly, during recovery of a broken route, thetransmitted TCP segments are lost in the network. The longlatency taken to recover a route in AODV causes more TCPsegments to be lost than in OLSR.

In addition, OLSR obtains easily the shortest path be-tween source and destination because each node can viewthe network topology, while AODV cannot guarantee theusage of shortest path because an RREP corresponding tothe RREQ which has reached the receiver earliest is simplysent to the sender according to the broadcasting performedby each intermediate node at random time. The inabilityof using the shortest path indicates that the performanceof TCP throughput decreases as the hop distance betweensource and destination nodes increases, which also was re-ported in [14].

Figure 3 shows how each CWND changes and we ob-served that using OLSR reduces the dropping of CWNDsize.

Thus, the sequencing of TCP segments over OLSR pro-gresses faster than over AODV (see Figure 4). In the fig-

Proceedings of the 2005 International Conference on Parallel Processing Workshops (ICPPW’05)

1530-2016/05 $20.00 © 2005 IEEE

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

AODV_RenoOLSR_Reno

(a) pause time = 0

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

AODV_RenoOLSR_Reno

(b) pause time = 10

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

Mobility [m/s]

AODV_RenoOLSR_Reno

(c) pause time = 20

Figure 2. Performance Comparison of TCP-Reno over AODV and OLSR.

0

10

20

30

40

50

60

70

150 200 250 300 350

Win

dow

Siz

e

Time [Sec]

AODV_RenoOLSR_Reno

Figure 3. Window Size Progress of TCP-Renoover AODV and OLSR.

ure, the frequent occurrences of a long-term discontinuityof sequencing indicate that AODV experiences more time-out events.

We also measured the throughput of TCP-Vegas overAODV and OLSR. Due to the aforementioned characteris-tics of underlying routing protocols, TCP-Vegas over OLSRshows better performance than over AODV (see Figure 5).

As a result, we can see that OLSR is better than AODVwithout regard to TCP variants.

In addition, we traced the progress of sequencing of TCPsegments for AODV and OLSR. Obviously, we observedthat TCP-Vegas over OLSR produces more throughput thanover AODV (see Figure 6).

Next, we measured the throughput performance of TCP-Reno and TCP-Vegas over a selected routing protocol (seeFigure 7). When AODV is used as a reactive routing pro-tocol, we observed that TCP-Vegas shows better perfor-mance than TCP-Reno, which is the same result as shownin [13]. TCP-Reno aggressively increases its CWND, whilethe small size of sending window of TCP-Vegas (see Figure8) allows the occurrences of unnecessary route rediscovery

0

20000

40000

60000

80000

100000

120000

140000

160000

0 50 100 150 200 250 300 350 400 450 500

Seq

uenc

e N

umbe

rTime [Sec]

AODV_RenoOLSR_Reno

Figure 4. Sequence Trace of TCP-Reno overAODV and OLSR.

caused by ”hidden node problem” to be reduced [14]. Inother words, unnecessary increase of window size causesmuch contention on the shared channel. Thus, it is possi-ble that packet transmissions continue to be failed and thereaching of retry limit finally notifies the source of routefailure and requires it to obtain a new route. Therefore, it ismore important that the window size is maintained in an ap-propriate range as in TCP-Vegas. TCP-Vegas controls suchtraffic that unnecessary occurrences of route recovery canbe reduced.

As shown in Figure 9, although TCP-Reno increasedits sequencing of TCP segments faster in the early stage,much traffic injection caused many route recovery activi-ties, which resulted in performance degradation in the finalstage.

On the other hand, when OLSR is applied to the twoTCPs as a proactive routing protocol, TCP-Reno is bet-ter than TCP-Vegas (see Figure 10). Unlike window-basedTCP-Reno, the sending rate of a source using TCP-Vegasis determined according to the difference between expectedthroughput and actual throughput. As mentioned before,

Proceedings of the 2005 International Conference on Parallel Processing Workshops (ICPPW’05)

1530-2016/05 $20.00 © 2005 IEEE

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

AODV_VegasOLSR_Vegas

(a) pause time = 0

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

AODV_VegasOLSR_Vegas

(b) pause time = 10

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

AODV_VegasOLSR_Vegas

(c) pause time = 20

Figure 5. Performance Comparison of TCP-Vegas over AODV and OLSR.

40

80

120

160

200

240

280

320

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

AODV_RenoAODV_Vegas

(a) pause time = 0

40

80

120

160

200

240

280

320

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

AODV_RenoAODV_Vegas

(b) pause time = 10

40

80

120

160

200

240

280

320

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

AODV_RenoAODV_Vegas

(c) pause time = 20

Figure 7. Performance Comparison of TCP-Reno and TCP-Vegas over AODV.

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

0 50 100 150 200 250 300 350 400 450 500

Seq

uenc

e N

umbe

r

Time [Sec]

AODV_VegasOLSR_Vegas

Figure 6. Sequence Trace of TCP-Vegas overAODV and OLSR.

TCP-Vegas designates the minimum of measured RTTs asits base RTT and calculates its expected throughput basedon this base RTT. If TCP-Vegas begins using a new routedue to node mobility, its base RTT is not a new base RTT,but the base RTT over the old route, whose inaccuracy re-sults in performance degradation. Furthermore, AODV ad-

0

20

40

60

80

100

120

140

160

180

0 50 100 150 200 250 300 350 400 450 500

Win

dow

Siz

e

Time [Sec]

AODV_RenoAODV_Vegas

Figure 8. Window Size Progress of TCP-Renoand TCP-Vegas over AODV.

heres to the same route until the route is broken. In OLSR,however, a link change triggers nodes to update their rout-ing tables, which allows another route to be selected. Thefrequent change of route causes the inaccuracy of base RTTto be exaggerated.

As shown in Figure 11, TCP-Reno shows better progress

Proceedings of the 2005 International Conference on Parallel Processing Workshops (ICPPW’05)

1530-2016/05 $20.00 © 2005 IEEE

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

OLSR_RenoOLSR_Vegas

(a) pause time = 0

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

OLSR_RenoOLSR_Vegas

(b) pause time = 10

80

120

160

200

240

280

320

360

400

20 15 10 5

Thr

ough

put [

Kbp

s]

Mobility [m/s]

OLSR_RenoOLSR_Vegas

(c) pause time = 20

Figure 10. Performance Comparison of TCP-Reno and TCP-Vegas over OLSR.

0

10000

20000

30000

40000

50000

60000

0 50 100 150 200 250 300 350 400 450 500

Seq

uenc

e N

umbe

r

Time [Sec]

AODV_RenoAODV_Vegas

Figure 9. Sequence Trace of TCP-Reno andTCP-Vegas over AODV.

of TCP segments sequencing than TCP-Vegas due to theinaccuracy of base RTT.

4 Trials to modify the existing TCPs with ourFuture works

Many research works indicated that the existing TCPsare not able to distinguish between packet loss caused bynode mobility and that by congestion. Therefore, for thepurpose of improving TCP performance for MANETs, sev-eral approaches have been proposed.

In TCP-feedback [6], two special messages, RFN(Route Failure Notification) and RRN (Route Re-establishment Notification), are generated when routebreakage occurs and a new path is acquired, respectively.On receiving the RFN message, TCP sender freezes all itsvariables such as TCP-related timers and CWND (Conges-tion Window) size, and resumes the TCP process from thefrozen state after receiving the RRN message. In the ELFN-based approach [7], ELFN (Explicit Link Failure Notifica-tion) message like the RFN message can be used to inform

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

0 50 100 150 200 250 300 350 400 450 500

Seq

uenc

e N

umbe

rTime [Sec]

OLSR_RenoOLSR_Vegas

Figure 11. Sequence Trace of TCP-Reno andTCP-Vegas over OLSR.

the TCP sender of the route breakage. However, insteadof using RRN message as in TCP-Feedback, probe mes-sages are sent regularly toward the destination in order todetect the route restoration. Additionally, in TCP-BuS (TCPwith Buffering capability and Sequence Information) [8],the buffering mechanism at intermediate nodes helps to im-prove TCP performance, in addition to using explicit notifi-cation messages related to route breakage and restoration.

Unlike the approaches mentioned above, ATCP [9] im-plements an intermediate layer between network and trans-port layers rather than imposing changes to the standardTCP. ATCP relies on ECN (Explicit Congestion Notifica-tion) mechanism for congestion control and ICMP protocolfor detecting route failures. TCP-DOOR [10] utilizes onlyout-of-order packet information for detecting route failures.

In this paper, however, prior to such researches, wetried to know that which TCP variant is suitable for whichrouting protocol by extensive performance comparisons.As pointed out in the simulations, TCP-Vegas experiencesan inaccuracy problem of Base RTT due to frequent pathchange caused by node mobility, which results in perfor-

Proceedings of the 2005 International Conference on Parallel Processing Workshops (ICPPW’05)

1530-2016/05 $20.00 © 2005 IEEE

mance degradation. Therefore, some modification in orderto estimate an exact Base RTT over a new path is neededto improve TCP performance for MANET. On the otherhand, the aggressive window increasing attitude of TCP-Reno also invokes throughput decrease caused by ’hiddennode problem’. Although some research work [15] at-tempted to maintain the small size of TCP window, it did notreflect hop-distance between source and destination. There-fore, a dynamic determination of the window size accordingto the hop-distance between source and destination can im-prove the performance of TCP-Reno.

On the basis of the results observed in this paper andsome trials in the literature, we are planning to developan efficient technique to improve TCP performance overMANET, which is our interesting future work.

5 Conclusion

Recently, IETF MANET working group has standard-ized AODV and OLSR as its reactive and proactive routingprotocols, respectively. In addition, from the perspectiveof transport layer, we believe that TCP will be on top ofthe routing protocols for reliable data transmission. SinceTCP has its variants, namely TCP-Reno and TCP-Vegas,we performed the throughput comparison of TCP-Reno andTCP-Vegas over AODV and OLSR.

In summary, from the view of throughput, OLSR is thebest routing protocol irrespective of TCP variants. How-ever, TCP-Vegas performs better for AODV. On the otherhand, TCP-Reno is more suitable for OLSR. Through theextensive simulations, we found that which to select amongrouting protocols is more important than which to selectamong TCP variants, because the performance differencebetween TCP-Reno and TCP-Vegas over any selected rout-ing protocol is not so much outstanding.

On the basis of the results observed in this paper andsome trials in the literature, we can develop a technique toimprove TCP performance over MANET, which is our in-teresting future work.

References

[1] Internet Engineering Task Force,”Manet working group charter,”http://www.ietf.org/html.charters/manet-charter.html.

[2] T. Clausen, P. Jacquet, A. Laouiti, P. Minet, P. Muh-lethaler, A. Qayyum, and L. Viennot, ”Optimized LinkState Routing Protocol(OLSR)”, IETF RFC 3626.

[3] D. B. Johnson, D. A. Maltz, and Y. Hu, ”The Dy-namic Source Routing Protocol for Mobile Ad-hocNetworks (DSR)”, IETF Internet Draft, draft-ietf-manet-dsr-08.txt, February 2003.

[4] C. E. Perkins, E. M. Belding-Royer, and S. R. Das,”Ad-hoc On-Demand Distance Vector (AODV) Rout-ing”, IETF RFC 3561.

[5] C. E. Perkins and P. Bhagwat, ”Highly dy-namic Destination-Sequenced Distance-Vector rout-ing (DSDV) for Mobile Computers”, SIGCOMMSymposium on Communications Architectures andProtocols, Sept. 1994.

[6] K.Chandran, S. Raghunathan, S. Venkatesan, and R.Prakash, ”A Feedback Based Scheme For Improv-ing TCP Performance In Ad-Hoc Wireless Networks”,IEEE ICDCS 1998.

[7] G. Holland and N. H. Vaidya, ”Analysis of TCP Per-formance over Mobile Ad Hoc Networks. 5th AnnualInternational Conference on Mobile Computing andNetworking”, ACM Mobicom, August 1999.

[8] D. Kim, C.-K. Toh, and Y. Choi, ”TCP-BuS : Improv-ing TCP Performance in Wireless Ad Hoc Networks”,Journal of Communications and Networks, Vol. 3, No.2, 2001.

[9] J. Liu, S. Singh, ”ATCP: TCP for Mobile Ad Hoc Net-works”, IEEE Journal on selected areas in communi-cations, vol. 19, No. 7, July 2001.

[10] F. Wang and Y. Zhang, ”Improving TCP Performanceover Mobile Ad-Hoc Networks with Out-of- OrderDetection and Response”, ACM Mobihoc02, June2002.

[11] V.Jacobson, ”Congestion avoidance and control,”ACM SIGCOMM 88, Aug. 1988.

[12] L. Brakmo and L. Peterson, ”TCP Vegas: End to EndCongestion Avoidance on a Global Internet,” IEEEJournal on Selected Areas in Communications, vol.13, pp. 1465–1480, October 1995.

[13] S. Papanastasiou, M. Ould-Khaoua, ”Exploring theperformance of TCP Vegas in Mobile Ad hoc Net-works,” International Journal of Communication Sys-tems, pp. 163-177, Vol. 17, Issue 2, March 2004.

[14] Fu Z, Zerfos P, Luo H, Lu S, Zhang L and Gerla M,”The impact of multihop wireless channel on TCPthroughput and loss,” IEEE INFOCOM 2003.

[15] S. Xu ,T. Saadawi and M. Lee, ”Comparison of TCPReno and Vegas in wireless mobile ad hoc networks,”IEEE LCN 2000.

[16] K.Fall and K.Varadhan, ”ns notes and documents,”The VINT Project, UC Berkeley, LBL, USC/ISI.and Xerox PARC, February 2000, Available athttp://www.isi.edu/nsnam/ns/ns-documentation.html

Proceedings of the 2005 International Conference on Parallel Processing Workshops (ICPPW’05)

1530-2016/05 $20.00 © 2005 IEEE