CHAPTER 6

SIMULATION RESULTS & ANALYSIS

This thesis will analyze and discuss the results of simulations. First the thesis analysis the
different TCP congestion control protocol i.e. TCP Reno, TCP Tahoe, TCP SACK and
TCP New RENO. The analysis is performed on the basis of congestion window
parameter. After this the results of all of these TCP congestion control protocols is
compared with Modified TCP congestion control protocol. Other than this thesis also
evaluate the performance of various queuing discipline algorithms to perform QoS in the
UMTS network. The results are collected in the form of graphs; every graph is presented
as time average. Different statistics are collected which are explain below.

6.1 SIMULATION RESULTS AND STATISTICS

6.1.1 TCP Congestion Control Protocols

This thesis uses both Global statistics and Object statistics to analyze the behaviors of
TCP congestion control protocols form the entire network. To view the results of all the
scenarios for performance evaluation DES is used. Finally run the simulation for ten
minutes i.e. 600 sec. and save all the graphs for analysis. All the graphs are very helpful
for performing the statistical analysis of TCP congestion control protocols and queuing
disciplines. Required graphs are saved as the jpeg image to perform the statistical
analysis. DES execution manager window for the simulation of TCP congestion control
protocol scenarios is shown in fig. 6.1
 SIMULATION RESULTS & ANALYSIS 149

Fig. 6.1(a) DES execution window for TCP Congestion control protocols

6.1.2 Queuing Disciplines

Fig. 6.1(b) DES execution window for all Queuing Disciplines

 SIMULATION RESULTS & ANALYSIS 150

6.2 ANALYZING SIMULATION FOR TCP FLAVORS & MODIFIED TCP Tahoe
PERFORMANCE

The scenarios used here are as described in earlier chapter. This thesis used four types of
TCP congestion control scenarios i.e. for TCP RENO, TCP Tahoe, TCP SACK and TCP
New Reno.
Simulation results are taken for all scenarios to check the performance of all above TCP
congestion control algorithms. Further the performance of modified TCP Tahoe
congestion control protocol is compare with all above TCP congestion control protocol.
Now this thesis discusses performance of all the four TCP congestion control protocol
with modified TCP Tahoe congestion control protocol for each parameter explicitly. For
all the protocols, the graphs shown are in time average form. The graph that shows delay
in seconds, the x-axis represents time in minutes and y in seconds. The graph that depicts
the throughput in bits/ sec, x-axis is stand for time in min and y axis shows data rate in
bits/sec.
Analyzing TCP Variants results by implementing the changes perform in TCP Tahoe.
Number of simulations was executed and results are taken, saved and comparison is
performed with other results. As shown in figures, modified TCP Tahoe presents a
minimum congestion window recovery time and a minimum FTP download response
time. The two statistics that is used to collect the results are:

1. GLOBAL STASTICS: These static is collected for FTP download response time.
Before modification FTP download response time for TCP New RENO is greater than
other variants.
2. OBJECT STATICS: Object statics is collected for various network objects i.e. for
FTP server and for various user equipments. For each node and user equipment TCP
congestion window is shown in results.
 SIMULATION RESULTS & ANALYSIS 151

 FTP Download Response Time

FTP download response time is the times taken to get a FTP file form server. FTP
download response time should be minimizing to get faster data.

Fig 6.2 FTP download response time for all TCP versions
Fig. 6.2 shows the FTP download response time for all TCP versions. FTP response time
is the time elapsed between sending a request packet and receiving the response packet.
 SIMULATION RESULTS & ANALYSIS 152

It is computed as the time taken by a client application to send a request to the server and
receives a response packet back. Each response packet that is sent from a server to FTP
application is contained in this statistic.

Fig. 6.3 FTP Download response time

Fig. 6.3 shows the FTP download response time for all TCP scenarios with modified TCP
Tahoe and it shows that modified TCP Tahoe performs better.
 SIMULATION RESULTS & ANALYSIS 153

Table 6.1 shows the comparative analysis of FTP Download Response Time for NEW
RENO, RENO, SACK, and Tahoe. Results shows in table 6.1 represents that FTP
download response time for SACK is less in compare to other TCP versions. This shows
that SACK takes minimum time to sent a request and download a FTP file in minimum
time duration.

Table 6.1 FTP Download Response Time for NEW RENO, RENO, SACK, Tahoe
Time (sec) New RENO RENO SACK Tahoe

530 425.8851 425.8851 412.945 425.8851

540 425.8851 425.8851 412.945 425.8851

550 434.4401 434.4401 412.945 434.4401

560 441.8117 441.8117 412.945 441.8117

570 446.2125 446.2125 412.945 446.2125

580 446.2125 446.2125 412.945 446.2125

590 446.2125 446.2125 412.945 446.2125

Table 6.2 FTP Download Response Time for Tahoe and Modified Tahoe
Time (Sec) Tahoe Modified Tahoe

530 425.8851 407.247

540 425.8851 407.247

550 434.4401 407.247

560 441.8117 407.247

570 446.2125 407.247

580 446.2125 407.247

590 446.2125 407.247

 SIMULATION RESULTS & ANALYSIS 154

Table 6.2 represents comparative analysis shown for Tahoe and modified Tahoe. Results
shows that, modified Tahoe performs better in comparison to old Tahoe and it is also
seems that it performs better than other TCP variants also.
 Congestion Window
Fig. 6.4 graph shows the results for TCP connection congestion window size. The graph
shows congestion window for all TCP variant and it shows that congestion window of
TCP New RENO is quite good and it performs better. Almost the performance of all TCP
versions is same.

Fig. 6.4 TCP Connection Congestion Window size

 SIMULATION RESULTS & ANALYSIS 155

Fig. 6.5 shows the TCP connection Congestion window size with modified TCP Tahoe.
Extensive simulations were run to get mean TCP throughput. The graph illustrates a
snapshot of the comparison of the TCP cwnd size for all TCP versions with modified
TCP Tahoe and results shows that modified TCP Tahoe perform better and the packet
drop rate of Tahoe is less.

Fig. 6.5 TCP Connection Congestion Window Size with Modified TCP Tahoe
 SIMULATION RESULTS & ANALYSIS 156

 Sent segment sequence number

Sent segment sequence number is sequence number of a sent segment for a single
connection. Fig. 6.6 shows the sent segment sequence number for both TCP Tahoe and
modified TCP Tahoe.

Fig. 6.6 Sent Segment Sequence Number with modified TCP Tahoe

Fig. 6.7 shows a comparison of the steady stat mean TCP cwnd size response of TCP
Tahoe with modified TCP Tahoe congestion control scheme with respect to packet drops
at various intervals. Results are taken at various packet drop rates. Packet drop rates
ranges from 5% to 20% which is very much equivalent with the steady state cwnd value.
 SIMULATION RESULTS & ANALYSIS 157

Fig. 6.7 TCP Congestion window size

Fig. 6.8 shows the TCP connection congestion window size at user equipment. The graph
shows TCP cwnd size responses of modified TCP Tahoe congestion control scheme with
respect to the standard TCP over UMTS network model for drop of the packets at various
intervals.
 SIMULATION RESULTS & ANALYSIS 158

Fig. 6.9 shows that Modified TCP Tahoe performs better at user equipments. It can be
examined that the modified TCP Tahoe congestion control scheme has rapidly recovered
from packets losses. The graph shows a comparison for the TCP cwnd size responses of
the modified TCP Tahoe congestion control scheme with the standard TCP congestion
control schemes in UMTS at different packet drops rate. It is observed that the proposed
scheme considerably raises the TCP cwnd size. Proposed scheme recover the majority of
the wireless packet losses and also minimize the number of spurious time outs by early
activating the improved wireless fast retransmit algorithms and disabled the fast recovery
algorithm.

Fig. 6.8 TCP connection congestion window at UE for all TCP flavors
 SIMULATION RESULTS & ANALYSIS 159

It can also observe that even with the proposed scheme, TCP timeouts happened at higher
packet drops rate. This can be recognized as the TCP Tahoe is not able to recover from
various packet losses within a window of data. It is also observed that if a packet is
dropped that is retransmitted and then this retransmitted packet can only be recovered by
the TCP timeout process.

Fig. 6.9 TCP connection congestion window at UE with modified TCP Tahoe
 SIMULATION RESULTS & ANALYSIS 160

 Throughput

Throughput is overall system output. Throughput stastics collected at RNC node to verify
the performance of UMTS network. Fig. 6.10 shows the throughput for TCP Tahoe and
modified TCP Tahoe. Results show that the throughput for modified TCP Tahoe is much
good rather than TCP Tahoe.

Fig. 6.10 Comparative analysis of Throughput for TCP Tahoe and Modified TCP Tahoe
 SIMULATION RESULTS & ANALYSIS 161

Comparative analysis is performing by table 6.3. Table shows the throughput of all TCP
versions. Throughput of RENO an d New RENO is almost same but throughput of Tahoe
is quite good.

Table 6.3 Throughput of New RENO, RENO, SACK, Tahoe with 10% packet drop
Time NEW RENO RENO SACK TAHOE

120 788.918 788.918 788.918 788.918

130 1519.333 1519.333 1467.939 1519.333

140 2397.69 2397.69 2090.141 2397.69

150 3193.947 3193.947 2563.526 3193.947

160 3863.111 3863.111 3261.136 3863.111

170 4501.302 4501.302 3855.442 4501.302

180 5004.132 5004.132 4342.505 5004.132

Table 6.4 shows the throughput of Tahoe and Modified Tahoe. Results show that
Modified Tahoe performs better and throughput of modified Tahoe is greater than Tahoe.

Table 6.4 Throughput of Tahoe and Modified Tahoe with 15% packet Drop
Time (Sec) Tahoe Modified Tahoe
110 72.59459 75.31532

120 246.6116 238.6777

130 516.8855 543.7557

140 861.844 918.5816

150 1167.152 1241.325

160 1410.683 1521.988

170 1650.058 1764.211

180 1847.072 1947.845

 SIMULATION RESULTS & ANALYSIS 162

6.3 ANALYZING SIMULATION FOR QUEUING DISCIPLINES

For analyzing queuing disciplines voice users are added to check the performance of on
UMTS network. Simulation results are analyze by a number of performance parameters
like jitter, MOS, Packet delay variation and Packet end to End Delay. By all these
performance metric results are checked for all queuing disciplines and for Non QoS
scenario also.
 Jitter
Jitter represents, if two successive packets depart from the source node with time stamps
t1 & t2 and are come back at the destination node at time t3 & t4, then jitter measured as
follows:
Jitter = (t4 - t3) - (t2 - t1)
Negative jitter shows that the time difference between the packets at the destination node
was less than that at the source node. Fig. 6.11 shows the jitter in all queuing disciplines
and Fig. 6.12 shows the comparative analysis of all queuing disciplines.

Fig. 6.11 (a) Jitter in PQ

 SIMULATION RESULTS & ANALYSIS 163

Fig. 6.11 (b) Jitter in FIFO

Fig. 6.11(c) Jitter in MWRR

 SIMULATION RESULTS & ANALYSIS 164

Fig. 6.11(d) Jitter in DWRR

Fig. 6.11(e) Jitter in WFQ

 SIMULATION RESULTS & ANALYSIS 165

Fig. 6.12 Comparative analysis of all Queuing Discipline for Jitter

 MOS

Fig. 6.13(a) MOS for FIFO

 SIMULATION RESULTS & ANALYSIS 166

Fig. 6.13(b) MOS for PQ

Fig. 6.13(c) MOS for DWRR

 SIMULATION RESULTS & ANALYSIS 167

Fig. 6.13(d) MOS for MWRR

Fig. 6.13 (e) MOS for WFQ

 SIMULATION RESULTS & ANALYSIS 168

Fig. 6.13 shows the results obtained of MOS for all queuing disciplines and it shows that
at the starting time the value of MOS is approx 2.8 but as the time expand the quality of
voice is degraded and comes to approx 2.2 which is same for all queuing disciplines. Fig.
6.14 shows the comparative analysis of MOS for all queuing disciplines. Graph shows
that the MOS for WFQ is not good and it comes to approx 1.9 which is not good for
quality of voice. Whether the MOS value of DWRR is approx 2.8 to 2.1 which shows a
good quality of voice.

Fig. 6.14 Comparative analysis of al Queuing Discipline for MOS

 SIMULATION RESULTS & ANALYSIS 169

 Packet End to end Delay

The total voice packet delay, called analog to analog or mouth to ear delay is equal to
network delay, encoding delay, decoding delay, compression delay and decompression
delay.
Network delay is the time at which the sender node gives the packet to RTP to the time
the receiver gets it from RTP. Encoding delay (on the sender node) is computed from the
encoder scheme. Decoding delay (on the receiver node) is assumed to be equal to the
encoding delay.
Compression and Decompression delays are calculated from the consequent attributes in
the voice application configuration. This statistic stores data from each node in the
network. Fig. 6.15 shows packet end to end delay for all queuing disciplines and Fig. 6.16
shows comparative analysis of packet end to end delay for all queuing discipline.

Fig. 6.15(a) Packet end to end delay in WFQ

 SIMULATION RESULTS & ANALYSIS 170

Fig. 6.15(b) Packet end to end delay in PQ

Fig. 6.15(c) Packet end to end delay in MWRR

 SIMULATION RESULTS & ANALYSIS 171

Fig. 6.15(d) Packet end to end delay in FIFO

Fig. 6.15(e) Packet end to end delay in DWRR

 SIMULATION RESULTS & ANALYSIS 172

Fig. 6.15 shows the packet end to end delay. The results shows that initially packet delay
variation is approximately same for all queuing disciplines but after 100 seconds
duration the packet end to end delay is changes for all queuing disciplines.

Fig. 6.16 Comparative analysis of all Queuing Discipline for packet end to end delay

Fig. 6.16 shows comparative analysis of packet end to end delay for all queuing
discipline and it explains that packet end to end delay is minimum for DWRR queuing,
whether it is maximum for WFQ.

 Packet Delay variation: Packet delay variation among end to end delays for voice
packets. End to end delay for a voice packet is computed from the time it is created to
the time it is received. Fig. 6.17 demonstrates the packet delay variation for all
queuing disciplines i.e. FIFO, WFQ, PQ, DWRR and MWRR.
 SIMULATION RESULTS & ANALYSIS 173

Fig. 6.17 (a) Packet Delay Variation for WFQ

Fig. 6.17 (b) Packet Delay Variation for PQ

 SIMULATION RESULTS & ANALYSIS 174

Fig. 6.17 (c) Packet Delay Variation for MWRR

Fig. 6.17 (d) Packet Delay Variation for FIFO

 SIMULATION RESULTS & ANALYSIS 175

Fig. 6.17 (e) Packet Delay Variation for DWRR

Fig. 6.17 shows the packet delay variation for all queuing disciplines. The results show
that DWRR shows less packet delay variation rather than other queuing disciplines.
Initially at the time of approx 100 seconds the packet delay variation of all queuing
disciplines are same but gradually it increases and finally after approx 150 seconds
gradually decreases.

Fig. 6.18 shows a comparative analysis of all queuing disciplines. The result shows that,
packet delay variation for DWRR is less in compare to other queuing disciplines. Packet
delay variation for MWRR and WFQ is quite same but WFQ shows more packet delay
variations.
 SIMULATION RESULTS & ANALYSIS 176

Fig. 6.18 Comparative analysis of all Queuing Discipline for Packet Delay Variation

Graph shows that DWRR shows less packet delay variation. While MWRR shows the
high packet delay variation.
 SIMULATION RESULTS & ANALYSIS 177

6.4 ANALYZING SIMULATION FOR QOS WITH NON QOS

 Jitter

Fig. 6.19 Comparative analysis of Jitter for QoS and Non QoS in UMTS

Fig. 6.19 shows the jitter in QoS and Non QoS scenario and it shows that while the QoS
is implemented in UMTS network the performance of UMTS network is better the non
QoS scenario. Performance of QoS implementation for jitter is quite good rather than
Non QoS.
 SIMULATION RESULTS & ANALYSIS 178

 Packet Delay Variation

Fig. 6.20 Comparative performance analysis of Packet Delay Variation for QoS and Non
QoS scenario

Fig. 6.20 shows the packet delay variation for QoS and non QoS scenario. A result shows
that the packet delay variation for non QoS is greater in comparison to QoS scenario
.
 Throughput
Total received throughput on the uplink, i.e. from UE to UTRAN in packets/second.
Throughput defined the performance of network.
 SIMULATION RESULTS & ANALYSIS 179

Fig. 6.21 Comparative performance analysis of Throughput for QoS and Non QoS
scenario

Fig. 6.21 shows the comparative performance analysis of throughput for QoS and Non
QoS scenario. The QoS shows the better result for throughput. Results show that when
QoS is implemented in UMTS network the performance of the UMTS network is
enhanced as shown in above figures.
So results shows that when modified TCP Tahoe and queuing disciplines (QoS)
implements on UMTS network the congestion in the network is minimize, packet drop
rate is reduced and throughput of UMTS network is increased. Above graphs shows the
results both for modified and unmodified versions.