CHAPTER 1 INTRODUCTION Nowadays wireless communication deployment is widely growth. From the beginning, wireless communication have developed good element in modern society. Staring from communication network in telegraph invention to telephone, followed by radio transmission and the exponential growth of radio transmission, the quality of the data transmission has been improved [7]. The communication has become cheaper and simple. The devices enable private, public communication and wireless networking. As to ensure the quality of the data transmission, an efficient protocol with is named as Transmission Control Protocol (TCP) is introduced. TCP is widely used in the transport layer in wired network. However in recent years,. TCP is implemented in wireless 1
95
Embed
performance evaluation of tcps in wireless network
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
CHAPTER 1
INTRODUCTION
Nowadays wireless communication deployment is widely growth. From the beginning,
wireless communication have developed good element in modern society. Staring from
communication network in telegraph invention to telephone, followed by radio
transmission and the exponential growth of radio transmission, the quality of the data
transmission has been improved [7]. The communication has become cheaper and
simple. The devices enable private, public communication and wireless networking.
As to ensure the quality of the data transmission, an efficient protocol with is
named as Transmission Control Protocol (TCP) is introduced. TCP is widely used in the
transport layer in wired network. However in recent years,. TCP is implemented in
wireless link because of the highly demands attention. This is because of the
importance of supporting application over wireless communication like laptops,PDAs,
and others.
1
TCP (Transmission Control Protocol) is a set of rules (protocol) used along with
the Internet Protocol (IP) to send data in the form of message units between computers
over the Internet. While IP takes care of handling the actual delivery of the data, TCP
takes care of keeping track of the individual units of data that a message is divided into
for efficient routing through the Internet. TCP is known as a connection-oriented
protocol, which means that a connection is established and maintained until such time as
the message or messages has been exchange. TCP is responsible for ensuring that a
message is divided into the packets. TCP manages and reassembles the packets back
into the complete message at the other end. TCP is usually used in wired network, but
nowaday TCP has been implemented in wireless network.
TCP is known of its reliability, congestion control, and connection management
and also flow control in their service, that are needed in wireless communicsation. Most
of the internet applications use TCP as its underlying transport layer protocol for
reliable data transfer. It is a very urgent need of a reliable data transfer protocol for
wireless network as wireless users growth is increasing tremendously [17].
1.1 Research Motivation
TCP is widely used in wired link. In recent years, wireless link also uses TCP for
supporting application over wireless. But TCP is inefficient in wireless network
because of longer delay and then causes packet losses. Packets may incur random loss
due to transient congestion caused by fluctuations in real-time traffic. Packet losses
over wireless links reduce TCP data transfer speed. Moreover, TCP with complete
design only focuses on the properties of wired network that is performing very poorly in
wireless networks. This is because wireless network has a very different characteristics
than wired which causes TCP is inefficient over the heterogeneous environment in both
Average Throughput[kbps] = 333.11 startTime=1.63stopTime=100.00
Average Delay is: 0.313364 Maximum Delay is: 0.470701
cause the bottleneck link becomes congested. Therefore, the segment is transmitted
over the base station to wireless node that is too slow and the delay also increases at that
time.
Figure 4.5: Simulation of TCP Tahoe for 100s
The simulation shows that slow-start mechanism opens up the transmission in a smooth
manner without too many retransmissions. After that, TCP congestion avoidance phase
takes over. The delay at this time is higher because there are many packets are sending
to the destination. This causes the route is congested and make the transmission slower
than before. Usually the slower route at router n2 from local area network ( LAN ) to
router n3 at T1 service that represents the wide area network (WAN)
53
Figure 4.6: Simulation of TCP Tahoe for 10s
For congestion avoidance, Tahoe uses ‘ Increase Multiplicative Decrease’. A packet
losses is taken as a sign of congestion and TCP saves half of the CWND as slow-start
threshold (ssthreshold). It then set CWND to 1 MSS and restart slow-start again until
ssthreshold value. Then the CWND will growths linearly until it encounters a packet
loss. Then it increase the CWND slowly as it approaches the bandwidth capacity.
54
Figure 4.7: Simulation of TCP Tahoe at time 90s-100s
In figure 4.7 above, we observe the delay is lower at time 95s than other period of time.
This is because in Tahoe, when encounter congestion TCP decrease the sending rate
and reduce congestion window to one. After that, TCP start retransmission over again.
In TCP Tahoe, the fast retransmit and fast recovery are not covered in the
implementation for congestion control algorithm.. But these mechanism is
implemented in TCP Reno. We discuss and analyze TCP Reno in the next section.
4.2.2 Analysis of TCP Reno in wireless communication
Figure 4.8 shows the simulation for TCP Reno for 100s. The TCP Reno and TCP
Tahoe have some equilibrium but there are some different on their mechanism
implementation. Refer to this graph below, we observe the congestion network better
as compared to TCP Tahoe.
Figure 4.8: Simulation of TCP Reno for 100s
55
From the figure 4.8, we observe that the delay at the starting point is also high because
‘signalling packet’ is sent by the host to the destination before it starts the transmission
to initiate TCP connection. Then TCP start to send data at 1.616274s. TCP Reno retains
the basic principle of Tahoe, just a slight modification over TCP Tahoe. We can see at
the beginning, the slow-start mechanism phase is starting until there is some dropping
point before it reaches congestion threshold. Then, slow-start restarts again. When the
congestion window is larger enough and reaches the congestion threshold, the slow-start
phase is over. After that, congestion avoidance mechanism continue to control the
transmission. In congestion avoidance phase, the congestion window is linearly growth.
TCP Reno implements the fast recovery mechanism in conjunction with the fast
retransmit. Fast retransmission and fast recovery algorithms [13,15,16] were developed
to recover packet losses quickly without RTTs. In fast retransmit, when there are
congestion network, it increases congestion window to 1 by reached 3 dupacks from the
receiver. The fast recovery algorithm in Reno [15, 16] replaces the slow-start with
congestion avoidance by reducing the congestion window to one half. Slow-start is
omitted if no timeout occurs, then CWND is immediately set to the threshold value.
After that, TCP increases the CWND by 1 MSS after every successful round of
transmissions. The effect of Reno TCP cuts the congestion window by half for each
recovered loss that causes maximum number of recoverable packet losses in a
congestion window without timeout is limited to one or two packets in most cases.
Under the most optimistic assumption that the algorithms always be triggered, no more
than six losses can be recovered with a maximum window size of 128 packets [15] .
56
Figure 4.9: Simulation of TCP Reno for 10s
Refer to figure 4.10, we observed at certain period of times, transmission of the
segments occur in order and sequentially. Hence, this decreases congestion network
until the end of simulation. After time 100s, the simulation end and the packet that are
still in the buffer is dropped.
57
Figure 4.10: Simulation of TCP Reno at time 90s-100s
4.2.4 Analysis of TCP Newreno in wireless communication
Figure 4.11: Simulation of TCP Newreno for 100s
58
Congestion network
Figure 4.11 above is a simulation experiment for TCP Newreno for 100s. The pattern of
simulation graph between Reno and Newreno are also have some equilibrium but
congested network in Newreno is worse than Reno at the beginning of the simulation
time. Before start a transmission between sender and receiver, TCP first sending
signalling packet to initiate connetion same like other TCPs. Same like Tahoe and Reno,
slow-start phase starts in the beginning of the transmission.TCP Newreno start send data
at time 1.637125s. Newreno is a slight modification over TCP Reno. The main
different among Reno and TCP Newreno is Newreno able to detect multiple packet
losses and more efficient than Reno per RTT. There are certain period of times network
are congested. When congestion occurred, Newreno solve the congestion same like
Reno for congestion avoidance. There are different implementation of Newreno in
fast recovery. mechanism. After entering the recovery phase, it will wait until all the
data which was outstanding is acknowledged, then will exit the phase. It will overcome
reducing the CWND multiple time.
Figure 4.12: Simulation of TCP Newreno for 10s
59
Figure 4.13: Simulation of TCP Newreno for at 90s-100s
After time 99.997s, the transmission is over and the packet that is sending after the
simulation time will be dropped. In the next section 4.2.5, we discussed simulation
experiment of TCP Sack.
4.2.5 Analysis of TCP Sack in wireless communication
Figure 4.14 shows the simulation result of TCP Sack for 100s. We have
considered the mobile node as a TCP receiver. The simulation shows that slow-start
mechanism opens up the transmission in a smooth manner without too many
retransmissions. From the figure, we see the various of delay patterns based on data
transmission. There are certain period network become congested. The most
congested period is among time 25s until to time 58s. The transmission of the segment
is too fast which cause the bottleneck link become congested. Therefore, the segment is
transmitted over the base station to wireless node that is too slow and the delay also
increases at that time.
60
Figure 4.14: Simulation of TCP Sack for 100s
From figure 4.14, we observe that delay at the starting point at time 0s is 1.60186s
because to initiate a TCP connection before start the transmission that we called three
handshake like other TCPs. When receiving ACK from the receiver, TCP nodes start
sending first segment to their destination respectively. At time 1.616274s, first segment
starts to transmit from node 0 to node 2. After n6 have received the segment, it sends
ACK to tell the sender that the first segment have been received at time 1.706477s.
Before time 2.01s, we see that the transient behavior in TCP is in the slow-start phase
and we see from the time 2.01s onwards, a steady-state cyclic regime of TCP is attained.
This is because TCP is in congestion avoidance and its window size is almost linearly
until congestion occurred. The congested network has occurred at time 23s until time
38s after that, the network congested again at time 40s until 58s. This is because of the
bottleneck link at n2 and n3. Node n2 and n3 are routers that link the sender to receiver
at different LANs. The bottleneck link has bandwidth capacity of 1.5Mb only. Both
wired node and wireless nodes sending data respectively at bandwidth capacity 100Mb,
these have caused the congestion network occurs at bottleneck link. Additionally, the
61
slow-start operation also have caused congested network. Every each segment that has
received to the receiver, the sender receives the ACK and transmits two segments then
have caused congestion network. An alternative to decrease the congested network
occur at the bottleneck link, we use RED (Random early detection) queue for the
bottleneck link. Operation of RED is preventing the router’s queue for becoming full
which can cause randomly dropping packets then network become congested. In RED
operation, it sends signals to the sender. This signal is to tell the sender to slow down
the transmission before the queue entirely full. After that, the transmission is slower
and this will decrease congestion network. At certain time, we could see the behavior of
the network is smooth. Hence, the congested network is also decreased than the certain
times before.
Figure 4.15: Simulation of TCP Sack for 10s
62
Figure 4.16: Simulation of TCP Sack at time 90s-100s
Starting from 61 onwards, the congested network decreases because of the
transmission of the segments are transmitted to their destination in order. Thus, the
order transmission makes the data not to be sent too fast. The network start congestion
again starting at time 90s. Then, congestion network decreases at time 96s onwards.
The traffic at bottleneck link also is in controlled. Maximum delay is 0.470701s and
average delay is 0.313364s. There are no drop segment occur until some segments drop
at the end time of simulation:100s
Slow-start mechanism is used at the beginning of the transmission, or after
repairing loss detected by retransmission timer [11]. For the operation of slow-start,
every each ACK received to the sender, the sender will send two more segments and
this will caused the cwnd increased exponentially. As each ACK arrives, two packets
are generated [14]. Each time the sender receives the ACK from the receiver, the sender
increases the CWND by 1 segment (1MSS). Therefore, after sending the first segment
before a time–out, the sender increases the CWND to two segments. Later if the two
63
segments is acknowledged, the CWND is increased to four segments and so on. The
CWND size grown exponentially during the slow-start phase because slow-start need to
fill the pipe as quickly as possible to utilize network resources maximally. But refer of
this graph, there is not exactly exponential growth because the receiver delay its ACK.
When the capacity of the network is reached, the bottleneck link will start discarding the
packets. This tells the CWND is too large. The slow-start will end when the CWND
exceeds a certain value specified as the congestion threshold. The slow-start algorithm
hands over the CWND control to the congestion avoidance algorithm based on Reno
implementation on congestion avoidance. After that, fast retransmit or fast recovery is
implemented if there are any packet losses in congestion avoidance phase. In the next
section 4.2.6 we analyse TCP Vegas performance in wireless communication.
4.2.6 Analysis of TCP Vegas in wireless communication
Figure 4.17 shows the simulation of TCP Vegas for 100s. The graph pattern of
TCP Vegas is different compared to other four TCPs we have discussed before. From
the figure, we observed the congestion network does not occur frequently, only at
certain periods when the data transmission occurs so fast over the bottleneck link. Thus,
the bottleneck link becomes congested.
At time 3.19483s, delay becomes higher again because of fast transmission of the
segments. When the trasnmission is fast, there are many segments are sent to the
receiver. Thus this cause congested network at the receiver, so the RTT of the segment
is longer than usual. We observe the average delay for Vegas simulation is 0.07151s
and the maximum delay is 0.11827s.
64
Figure 4.17: Simulation of TCP Vegas for 100s
From the figure 4.13, we observed delay at starting point is high because to
initiate TCP connection same with Sack and other TCPs we have discussed before.
After receiving ACK from the host, the transmission of first segment is started. Vegas is
a TCP implementation which is a modification of Reno. Slow-start mechanism that is
used in Vegas is modified of Reno. Same like Reno and Sack, Vegas implement slow-
start mechanism at the beginning of first segment transmission. But the implementation
of slow-start of Vegas is different than other TCPs. In slow-start phase of Vegas , it
increases exponentially only every other RTT, between that, it calculates the actual
sending throughput to the expected and the difference goes above a certain threshold it
exits slow-start and enter the congestion phase. Refer to the graph, we observe the
delay for the simulation of Vegas is lower than Sack and other TCPs. In Vegas, it
detects congestion before the packet losses occur. Thus cause delay is lower than other
TCPs because the rate of congested network is lower as compared to them. We observe
the delay of Vegas is balance starting from the begining to the end of simulation.
65
Figure 4.18: Simulation of TCP Vegas for 10s
Figure 4.19: Simulation of TCP Vegas for 90s
66
4.3 The difference of TCPs in wireless communication
Figure 4.20 above shows the comparative pattern of three TCP variants for simulation
experiment of 100s. From the figure we observed the pattern of the TCPs are different
among each other. The different patterns of the TCP variants above are caused by the
algorithm that is implemented on each of them. All of the TCP variants above do the
same mechanism for congestion control algorithm. But all the TCPs have their own
modification for the mechanisme we have discussed. As Vegas, it have modification of
slow-start mechanism congestion avoidance and also re-transmission mechanisme. In
Reno,it adds fast retranmsit conjunction with fast recovery. For Selective
Acknowledgement (SACK), IT added Sack option. Moreover, in Newreno, it have
modified the Reno to be more efficient in the event of multiple packet losses which is
able to detect multiple packet losses as compared to Reno. At the beginning of
simulation, we see all the TCP’s have higher delay because of initiate TCP connection.
After that, all the TCPs start the simulation with slow-start phase with different
modification.
67
Figure 4.20 : Combination graph of various TCP
68
Figure 4.21: Comparison of TCP variants
The main difference between the TCP Sack implementation and the TCP Reno
implementation is in the behavior when multiple packets are lost from one window of
data. With Sack, the sender is able to identify and retransmit multiple lost packets
within the same RTT if there are enough ACKs returning to the sender [15].
New retranmission mechanisme implement by Vegas is accurate than Reno[5].
Vegas does not need to wait for 3 dupacks for retransmission of packet losses. In
contrast, Reno still have to wait for 3 dupacks and when the coarse-grained timeout
occur for retransmission of packet losses. In Vegas, slow-start mechanisme is also
different than others. The exponential growth of Vegas increases only every other RTT.
In between, the CWND stays fixed so a valid comparison of the expected and actual
rates can be made. When the actual rate falls below the expected rate by a certain
amount. When the difference goes above the certain threshold , Vegas exits slow-start
phase and change to linear increase/decrease phase. But Vegas will implement coarse-
69
grained timeout like Reno if the mechanisme fail to recognize lost segment. In
Newreno, it take one RTT to detect each packet loss. When the ACK for the first
retransmitted segment is received, we only can deduce which other segment was lost. In
tahoe, in most of Tahoe implementation, it takes longer time because of the coarse grain
timeout. The table below show the advantages and disadvantages of TCP variants.
Table 4.1: The advantages and disadvantages of TCP variants
TCP ADVANTAGES DISADVANTAGES
Tahoe - Performance of Tahoe is better than Reno when mulitple packet are lost in 1 window of data
- slow start is not always efficient, especially if the error was random in nature.
- unable to fully utilize the available bandwidth of the radio channel during the phase of window re-expansion.
Reno Performs well over WLAN compared to TCP Tahoe when only a single packet is lost from one window of data
- Poor performance over WLAN compared to TCPTahoe when multiple packets are lost from one window of data
- Cannot distinguish between congestion loss and packet errors.
- Overreacts to packet errors.
Newreno - Performs better than TCP Reno over WLAN when multiple packets are lost from one window of data
- Modifications are only needed in the sender.
- Very popular protocol overall
Cannot distinguish between congestion loss and packet errors.
Sack The source has better information Requires modification to the
70
of the packets thathave been successfully delivered compared to other TCP versions. It can therefore avoid unnecessary delays and retransmissions.
acknowledgement procedures at both sender and receiver sides.
Vegas - Good performance over WLAN when using Snoop protocol
- Cannot distinguish between congestion loss and packet errors.
- Poor performance over WLAN when multiple error bursts (>4 losses) occur without using Snoop protocol.
- Asymmetric path.
- Algorithm is currently not embedded in most TCP implementations.
Based on the simulation experiment of all TCP variants we have proposed, the
perfomance evaluation of TCP Vegas is better than other TCPs we have analysed. But
all the TCPs we have discussed their own advantages and disadvantages respectively. In
section 4.4 we describe about the comparison of TCPs based on average of delay,
throughput and packset sent.
Table 4.1 shows the average delay Average, average throughput and maximum
delay, and packet sent of all TCPs we have discussed. From the table, we observed TCP
Sack has the highest average delay and average delay of Reno is higher than Vegas.
Average delay for Newreno is higher than Reno, Tahoe, and Vegas. Between all TCPs
we have analyzed, we have observed that TCP Vegas have the lowest average delay as
compared to other 4 TCPs. For the maximum delay, Newreno has the highest maximum
delay compared to other TCPs. For the average throughput, Vegas has the highest
average throughput as compared to others with 364.71Kbps. For packet sent, Tahoe
71
sent 3970 packet and TCP Sack sent 4010 packet. Then Reno sent 4163 packet. TCP
Vegas sent the highest packet 4379 as compared to other TCPs. Tahoe is the lowest TCP
of sent packet in simulation experiment. Thus, we conclude that Vegas performs better
than others in wireless communication. This is because Vegas has the lowest average
delay and sent more packet as compared to others.
Table 4.2: Average delay of TCP variants
TCP Average Delay(s)
Average Throughput(kb
ps)
Maximum Delay(s)
Packet
Sent(packet)
Tahoe 0.28806 329.78 0.4723 3970
Reno 0.27264 346.36 0.4710 4163
Newreno
0.3042 333.52 0.4745 4021
Sack 0.31336 333.11 0.4708 4010
Vegas 0.07151 364.71 0.11827 4379
72
4.5 Conclusion
Having the discussion of performance evaluation of TCP Tahoe, Reno, Newreno,Sack
and Vegas in this chapter, we have seen the comparative of TCPs by conducting
simulation experiment. From the discussion we have done, we observed that TCP
Vegas performs better in wireless communication. We also have investigated the
behavior of TCPs in wireless link. Moreover, we have seen the comparative pattern of
TCPs in graph and also the comparison of average and maximum delay among of them.
Among of five TCP we have evaluated, TCP Vegas has the highest average throughput.
73
CHAPTER 5
CONCLUSION
From this research, we observe the importance of Transmission Control Protocol (TCP)
in this modern society. Thus, the aim of this study is to evaluate the performance of TCP
variants in wireless communication via simulation experiment in ns-2.
In this thesis, we had presented our work about the performance evaluation of
TCP variants in wireless communication. We have investigated the performance
evaluation of the TCPs, we conduct the simulation experiment in ns-2 and we do some
comparative with the result that we have obtained. We present the results into graphs
and tables. The result of the simulation experiment using ns-2 shows that our proposed
network model performs well in wireless link. Between TCP variants we have compare
(on delay performance) each of the TCP variant that shows the various result. TCP
Vegas has the lowest delay in wireless link as compared to Tahoe, Newreno, Sack and
Reno. Vegas also have the best througput as compared to others. Moreover, based on
sending packet, Vegas also sent more packet than other TCPs. The effective congestion
74
control technique of Vegas makes it optimal in such a heterogeneous environment. The
lowest transmission delay causes the transmission of Vegas much better than Reno and
Sack. The service of wireless communication also performs better with implementation
of TCP algorithms. Thus the performance of the wireless communication is improved .
In chapter 2, we have discuss overview of our thesis. We also attach some
related works from previous researches. From the previous researches, we study about
the research that are related with our project.
In chapter 3, we presented the methodology used in our research. We had
discussed about the operating system that we used for our project and the simulation
tool ns-2 which we used for the simulation experiment. In the other hand ,we have
discussed the designed network topology which is written in the Tcl language in details.
In chapter 4, we evaluate the performance study of our proposed network
topology. We conduct some simulation experiment to our proposed topology, we do
some investigation to evaluate the performance of TCPs that we have proposed in
wireless communication. We also do the comparative of TCPs in graphs and tables.
Lastly in this chapter we conclude all the performance evaluation studies we
have done in all chapters before. After some evaluations and investigation, we
observed that TCP Vegas has better performance in wireless communication.
5.2 Future Work
As further improvement of this study, here are some points to be
considered:
75
(i) Investigate more TCP variants to tackle different problems
facing the behavior and performance of TCP in wireless
environments.
(ii) The network model can include more routers, base stations and
links to simulate other problems facing wired and wireless
scenarios such as, Out of Order Delivery, handoff latencies, the
effects of using different routing protocols, jitters, bandwidth
per station and packet processing time.
(iii) Other application that uses transportation protocols, such as
snoop, can be simulated. Thus, we could investigate the effects
and behavior of the different network topologies on such
protocols in wireless communication.
76
REFERENCE
[1] Kevin Fall and Sally Floyd “Simulation-based Comparisons of Tahoe, Reno, and SACK TCP” Lawrence Berkeley National Laboratory
[2] Jeonghoon Mo, Richard J. La Venkat Anantharam, and Jean Walrand “Analysis
and Comparison of TCP Reno and Vegas”, Department of Electrical Engineering and Computer Sciences University of California at Berkeley
[3] Upkar Varshney “ Selective Slow Start: A simple algorithm for improving TCP performance in wireless ATM network” Computer Information Sciences Washburn University of Topeka
[4] Christina Parsa and J.J. Garcia-Luna-Aceves“Improving TCP performance over wireless networks at the link layer”Computer Engineering Department, Baskin School of Engineering, University of California, Santa Cruz, CA 95064, USA
[5] Lawrence S . Brakmo, Sean W.O’ Malley and Larry L Peterson.“TCP Vegas: New Techniques for congestion detection and avoidance”
77
[6] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan and Randy H. Katz1 “A Comparison of Mechanisms for Improving TCP Performance over Wireless Links”
[7] Andrea Goldsmith“wireless communication”Cambridge University Press,2005
[8] Alberto Leon-Garcia and Indra widjaja “Communication networks fundamental concepts and key architectures” 2th edition 2009
[9] Transmission Control Protocol, RFC 793, Sep 1981.
[10] Cooperative Association for Internet Data Analysis (CAIDA), Traffic Workload Overview:http://www.caida.org/outreach/resources/learn/trafficworkload/tcpudp.xml
[11] Jinwen Zhu and Tianrui Bai “Performance of Tahoe, Reno, and SACK TCP at Different Scenarios”
[12] Padhye, J., S. Floyd, On Inferring TCP Behavior”, Computer Communications Review ACM-SIGCOMM, Vol. 31, August 2001. [13] Stevens, W.R., “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and
FastRecovery Algorithms”, RFC 2001, 1999
[14] V. Jacobson “Congestion Avoidance and Control” Proc Computer Communication Review, 18(4):314{ 29, August 1988.
[15] V. Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical report, April 1990.
[16] Wright, G., Stevens, W. R., TCP/IP ILLUSTRATED VOLUME 2, Addison-Wesley Publishing Co., New York, 1995
[17] Tsang-Ling Sheu and Lien-Wen Wu “An analytical model of fast retransmission and recovery in TCP-SACK” Department of Electrical Engineering, National Sun Yat-Sen University, Kaohsiung, Taiwan 26 April 2006
[18] Dong Lin and H.T. Kung “TCP Fast Recovery Strategies: Analysis and Improvements”
[19] Sharjeel Shahid “ Improving TCP Performance over Wireless Networks”
[20] Dah-Ming Chiu, Jain, R. “Analysis of the increase and decrease algorithms for congestion avoidance in computer network”. Computer Networks and ISDN Systems, 17(1), (1989), 1-14.
[21] Dongmin Kim, Beomjoon Kim, Jechan Han, and Jaiyong Lee “Enhancements to the Fast Recovery Algorithm of TCP NewReno”Department of Electrical & Electronic Engineering, Yonsei University Seoul, Korea
78
[22] Eitan Altman and Tania Jimenez “NS Simulatior for Beginner”, Lecture notes 2003-2004, University De Los Andes.December 4,2003
[23] Paul Meeneghan and Declan Delaney “An Introduction to NS, Nam and OTcl Scripting” NUIM-CS-TR-2004-05
[24] Kevin Fall and Kannan Varadhan The ns Manual (formerly ns Notes and Documentation)1 The VINT Project. UC Berkeley, LBL, USC/ISI, and Xerox PARC. January 6, 2009
[26] Sikdar, S. Kalyanaraman, and K. S. Vastola, “Analytic Models for the Latency and Steady-State Throughput of TCP Tahoe, Reno and
SACK”, Proceedings of IEEE GLOBECOM, San Antonio, TX, 2001.
[27] C. Barakat, E. Altman, and W. Dabbous, “On TCP Performance in a Heterogeneous Network: A Survey”, IEEE Communications
Magazine, Vol38, No 1, pp. 40-46, Jan. 2000.
[28] Thomas Williams & Colin Kelley Gnuplot “An Interactive Plotting Program” Copyright c 1986 - 1993, 1998, 2004 Thomas Williams, Colin Kelley
79
APPENDICES
80
New trace file descriptionEvent type
s send
r receivef Drop
forwardGeneral tag
-t time-t * (global setting)
Node property tags
-Ni node id-Nx node's x-coordinate-Ny node's y-coordinate-Nz node's z-coordinate-Ne node energy level -Nl trace level, such as AGT, RTR, MAC
-P arp Address Resolution Protocol. Details for ARP is given by the following tags
-Po ARP Request/Reply-Pm src mac address -Ps src address -Pa dst mac address -Pd dst address
-P dsr
-Pn how many nodes traversed -Pq routing request flag -Pi route request sequence number -Pp routing reply flag -Pl reply length-Pe src of srcrouting->dst of the source routing -Pw error report flag ?-Pm number of errors
82
-Pc report to whom-Pb link error from linka->linkb
-P cbr
-Pi sequence number-Pf how many times this pkt was forwarded -Po optimal number of forwards -P tcp Information about TCP flow is given by the following subtags: -Ps seq number -Pa ack number -Pf how many times this pkt was forwarded -Po optimal number of forwards
Available options for node configuration (see tcl/lib/ns-lib.tcl).
Option Available values Default
generaladdressType Flat, hierachical FlatMPLS ON, OFF OFF
Both satellite-and wireless orientedWiredRouting ON,OFF OFFIIType Ll,LL/Sat “”macType Mac/802_11,Mac/Csma/Ca, Mac/Sat,