ADVANCED NETWORKS ASSIGNMENT 1

Introduction:
Using Ns2, a network simulator, an investigation into the effect of QoS (Quality of Service) parameters
upon a network was carried out. From the results obtained via the Ns2 simulator such QoS parameters
like delay, jitter and packet loss were found. To further the investigation different network topologies
were used, along with different network queues and transmission rates to see the effect if any on the
chosen network topology.
Investigation:
While coding the network topologies within Ns2 it was decided that the topologies to cover would be
Ring, Star and Tree as these were felt to be the most suitable. The topologies were limited to just three
for a number of reasons least of all the amount of data which would need to be collated at the end of each
simulation, and secondly different queues and transmission rates were to be used thus increasing the data
to be collated.
Once the topologies were coded within Ns2 (code can be found within the reference section) they were
then simulated with the following queues, Droptail, FQ (Fair Queuing), RED (Random Early Detection)
and SFQ (Stochastic Fair Queuing) these queues were used as they were easily implemented within the
Ns2 code. The initial parameters used for the simulation were as follows:
Network link = 1Mb
Packet Size = 500Bytes
Packet Interval = 0.005sec
Transmission Protocol = UDP
The network link was chosen after some testing was carried out within the simulator, as it was initially
hoped to carry the simulation out using a network link of 100Mb however this proved to be too intensive
and time consuming for the machine carrying out the simulation. Throughout all of the simulations two
traffic flows are used for continuity. Traffic flow one will always begin transmitting first and will
transmit for three seconds, were as traffic flow two will begin transmitting one second after traffic flow
one and will also transmit for three seconds, thus giving an over lap of two seconds were both traffic
flows will be transmitting at the same time.
Timeline in Seconds
1

Traffic Flow 2 starts

Traffic Flow 1 starts

Traffic Flow 2 stops

Traffic Flow 1 stops

Traffic Flows 1 & 2 Transmitting at same time

The simulation of the Star topology consisted of five nodes, of which one of the nodes acted as a router,
node zero. Throughout the simulation of the star topology two traffic flows were used, traffic flow one
consisted of node one sending data to node four through node zero and traffic flow two has node two
sending data to node four through node zero.
BSc Communication Networks

-1-

To the left is a screen grab showing the Star topology simulated

with the Droptail queue in place. As can be seen from the screen
grab the queue is dropping packets, in all 253 packets were dropped
by this queue. This is to be expected as each traffic flow is sending
200pps (packets per second) and each packet is 500bytes in size.
With this packet size and transmission rate it results in a single
traffic flow needing 0.8Mbps bandwidth, this is fine for the 1Mb
link up until both traffic flows are transmitting at the same time.
When both traffic flows are transmitting at the same time this results
in an accumulative bandwidth need of 1.6Mbps which has surpassed
the 1Mb network link, hence packets are dropped. This will be the
same case for all of the network simulations which have been run
with these values; however it is believe that some of the queue types will result in less dropped packets.
The results from all of the Star topology simulations, using the above mentioned transmission rate, packet
size and queues types have been collected together and compared against each other to give some
indication of performance.
Comparison Of Queue Types Implemented With Star Network Topology

285
2119

SFQ

2404

290
2114

RED

2404

Packets Dropped
Packets Received
Packets Sent

232
2172

FQ

2404

252
DropTail

2152
2404

500

1000

1500

2000

2500

3000

Packets

As can be seen within the graph above, the queue with least dropped packets is that of the FQ queue.
This comes as no great revelation as an insight into the queues show that FQ gives equal processing time
to each traffic flow, thus each traffic flow will be given the same amount of processor time as the next
traffic flow at congested times. The next best alternative to FQ is that of the Droptail, however it is to be
noted that although this queue fairs well in comparison to RED and SFQ it does so at traffic flow twos
expense. As all of the packets dropped within the simulation using the Droptail queue, originated from
traffic flow two. This can be seen within the next graph that shows all of the packets dropped for each
queue with regards to which traffic flow the packets were dropped from.

BSc Communication Networks

-2-

Comparison Of Dropped Packets For Star Topology

Traffic Flow Two

144

Traffic Flow One

SFQ
141

110
RED
180

131
FQ
101

253
DropTail
0

50

100

150

200

250

300

Packets

The above graph further investigates the queues in terms of which traffic flows packets were dropped.
As already seen and mentioned above, Droptail is biased, within this case all of the packets dropped
belong to traffic flow two. SFQ favours well within the simulation as it is close to being the fairest
queue, this is to be expected as like the FQ queue, it provides each queue with an equal amount of
processing time, so the queue is not biased to any set traffic flow. However the SFQ queue has managed
to drop more packets than the FQ queue, which was not expected as both queues use processing time
sharing, this may be down to the accuracy of the fairness of the queuing methods or the default settings
which are initialised by Ns2. The case of RED shows that the bias went against traffic flow one as the
queue began to get congested, as 180 packets were dropped compared to that of 110 from traffic flow
two.
Following on with Star topology, average delay, jitter and throughput were measured for all of the queue
simulations, below is a graph showing the average delay in seconds for each traffic flow and their
respective queue type.
Average Delay

0.0280000000000000

Average Delay In
Sec

0.0279999999999999

0.0279999999999998

0.0279999999999997

0.0279999999999996

0.0279999999999995
DropTail Traffic Flow
One

DropTail Traffic Flow

Two

FQ - Traffic
Flow One

FQ - Traffic
Flow Two

RED - Traffic RED - Traffic SFQ - Traffic SFQ - Traffic

Flow One
Flow Two
Flow One
Flow Two

The data above shows that in the case of the Droptail queue, traffic flow two again suffers, this time in
terms of average delay. Although some of the delays are within 0.001 of a second it should be reminded
that networks are high speed devices that dont need to be held up by much to cause issues such low
performance when video streaming to name just one issue. The results within the graph are calculated for
the full journey from start node to finish node as it was felt this would be more beneficial than
representing each hop delay. The best performing queue in terms of average delay can be seen to be SFQ,
although both traffic flow one and two may not be the absolute lowest in terms of the other queues,
BSc Communication Networks

-3-

especially in the case of traffic flow two for the RED queue. It has to be reminded that the average delay
for the RED queue is only low as the queue dropped more packets from traffic flow two resulting in less
packets being transmitted, hence a shorter delay, this has only been taken into account due to the number
of packets which had been dropped.
Average jitter was measured for each of the queues within the Star network topology. However the
figures were so small, the majority of them sitting within the 10-18 range that is has been decided not to
represent the data within this report (results can be found within the calculation sheets, within the
reference section).
Packets Per Second, Per traffic Flow, Per Queue
250

Packets Per Second

200

150

100

50

0
Droptail Flow1

Droptail Flow2

FQ Flow1

FQ Flow2

RED Flow1

RED Flow2

SFQ Flow1

SFQ Flow2

Above is a graph showing the average throughput for each traffic flow within the Star network topology
simulation, for each queue type. The average throughput was gained by measuring the amount of packets
received at the end point from each traffic flow and then dividing the results by three to give the packets
per second received, as each traffic flow transmits for three seconds. Each traffic flow is using an interval
of 0.005 seconds and as such this means that a throughput of 200pps should be seen, however this will of
course vary depending on the amount of packets dropped by the queues. For instance traffic flow one
within the Droptail simulation is achieving its full throughput of 200pps, whereas traffic flow two which
suffered dropped packets has only achieved 116pps. Again it can be seen that SFQ has a level
throughput, but it can also be seen that the queue achieving more throughput in terms of both traffic flows
is that of the FQ queue. As traffic flow one achieved 166pps and traffic flow two achieved 156pps giving
a larger overall throughput than the rest of the queues.
To continue this investigation the transmission speed of each traffic flow was changed in terms of packets
per second. As the transmission speed of 200pps has already been used and shown to cause queues
within the simulation it has been decided to change the transmission speed to that of half the total
bandwidth of the network link. This will result in a transmission rate of 125 packets per second, and has
been done to see if queues are still present even though in theory the bandwidth of the link should not be
exceeded, but utilised to its fullest. The transmission rate for 125 packets per second will equate to a
transmission interval of 0.008sec. With the said changes in the place the simulations were re-simulated.
The results obtained were to be expected with regards to link usage, as there were no dropped packets
reported by either of the queue types for the Star topology. Again the average delay, jitter and throughput
were calculated, below is a graph showing the average delay.

BSc Communication Networks

-4-

Average Delay
0.0280000000000000

0.0280000000000000

Average Delay in
in sec

0.0279999999999999

0.0279999999999999

0.0279999999999998

0.0279999999999998

0.0279999999999997
DropTail Traffic Flow
One

DropTail Traffic Flow

Two

FQ - Traffic
Flow One

FQ - Traffic
Flow Two

RED - Traffic
Flow One

RED - Traffic
Flow Two

SFQ - Traffic
Flow One

SFQ - Traffic
Flow Two

As the graph shows, the average delay is levelled out due to a lower transmission rate. As there are fewer
packets being transmitted it results in less queues, which in turn result in a regular average delay. The
throughput in terms of each traffic flow is shown in the graph below.
Packets Per Second, Per Traffic Flow, Per Queue
140

120

Packets Per Second

100

80

60

40

20

0
Droptail Flow1

Droptail Flow2

FQ Flow1

FQ Flow2

RED Flow1

RED Flow2

SFQ Flow1

SFQ Flow2

A maximum packet rate had been calculated as 125pps for each traffic flow, it can be seen from the graph
above that this is being achieved by all of the traffic flows as the link is being used to its optimum. This
was to be expected as even when both traffic flows are transmitting the resulting bandwidth need is only
250pps, which works out to be 1Mbps, which is the link size.
So far interval rates have been used that show the link at full use with no queues (interval 0.008=125pps)
and full use with queues and dropped packets (interval 0.005=200pps). However an interval rate which
represented heavy use was used to see the effects on both, the queues and the topologies, the interval rate
decided upon was that of 0.001 seconds. This interval rate would result in 1000pps being transmitted
from each traffic flow and would in theory need a bandwidth of 4Mb per traffic flow, which is well over
the 1Mb link provided within the simulation.
The Star topology simulation was re-simulated again this time using the interval
of 0.001 seconds.
When the simulation was run it was found that the packet rate was so high that
the transmitting nodes themselves began to drop packets as can be seen within
the screen grab to the left.
BSc Communication Networks

-5-

The average packet delay for each of the queues within the Star topology simulation can be seen within
the graph below.
Average Delay
0.3000000000000000

0.2500000000000000

seconds

0.2000000000000000

0.1500000000000000

0.1000000000000000

0.0500000000000000

0.0000000000000000
DropTail Traffic Flow
One

DropTail Traffic Flow

Two

FQ - Traffic
Flow One

FQ - Traffic RED - Traffic RED - Traffic SFQ - Traffic SFQ - Traffic

Flow Two
Flow One
Flow Two
Flow One
Flow Two

This graph is a starker contrast than the others before it. However this is to be expected as far more data
is trying to be transmitted over the link. As the graph shows both Droptail and FQ seem to have the
lowest average delay as both are below 0.05 seconds for each traffic flow, while RED and SFQ are above
0.25 seconds for each traffic flow. However it has not been seen how many packets each queue has
dropped to achieve this average delay.
Comparison of Dropped Packets For Star Topology With Interval of 0.001

4975
SFQ

2552
7527

4969
RED

2592
7561
packets dropped
packets received
packets sent
4901

FQ

2700
7601

4903
DropTail

2696
7599

1000

2000

3000

4000

5000

6000

7000

8000

The data above clearly shows that both Droptail and FQ drop fewer packets than RED and SFQ.
Furthermore the FQ and Droptail queues have more packets sent and received than the RED and SFQ
queues, showing that when dealing with heavy load networks with no weighted queues, FQ and Droptail
queues would be far more beneficial. This is somewhat reinforced by the average throughput shown
within the next graph.

BSc Communication Networks

-6-

Packets Per Second, Per Traffic Flow, Per Queue

300

250

Packets Per Second

200

150

100

50

0
Droptail Flow1

Droptail Flow2

FQ Flow1

FQ Flow2

RED Flow1

RED Flow2

SFQ Flow1

SFQ Flow2

Although Droptail and FQ allow the most packets through, compared to the other queues it can be seen
that Droptail still show affects on one traffic flow more harshly than the other. This is shown as traffic
flow one has an average throughput of 100pps, whereas traffic flow two has an average throughput of
over 250pps. Within this simulation the fairest queue is shown to be the FQ queue as both traffic flows
are within 16 packets of each other, which again is a stark contrast as SFQ queue was expected to be the
fairest.
The interval will not be altered on any of the other topologies, due to the amount of time it has taken to
correlate the data from the above changes within the Star topology simulations.
To the left is a screen grab of the Ring topology simulation, within this
simulation a Droptail queue was used, again the standard packet size of
500bytes at an interval of 0.005 seconds was used. The link is still 1Mb to
keep consistency throughout the simulations.

Comparison Of Queue Types Implemented With Ring Network Topology

287
SFQ

2431
2718

292
RED

2421
2713

Packets Dropped
Packets Received
Packets Sent

234
FQ

2537
2771

255
DropTail

2495
2750

500

1000

1500

2000

2500

3000

Packets

Within the graph above is a comparison of dropped packets from all the queues within the Ring topology
simulation, the queue with the least amount of dropped packets is the FQ queue at 234. It does have to be
noted though that the hops between the nodes have changed for each of the traffic flows as they are not
BSc Communication Networks

-7-

the same, as in previous cases. For instance within the Ring simulations traffic flow one consisted of
node one transmitting to node four through node two and node three, where as traffic flow two consisted
of node two transmitting to node four through node three. With this factor taken in to consideration the
FQ queue still out performs the other queues as not only does it have the least dropped packets, but it also
sends the most packets, with the Droptail queue coming in second. A closer look at which dropped
packets make up which traffic flows can be seen below.
Comparison Of Dropped Packets For Ring Topology

165
SFQ
122
Traffic Flow Two
Traffic Flow One

182
RED
110

139
FQ
95

224
DropTail
31

50

100

150

200

250

Packets

Within the Ring topology simulations it has been seen that although the traffic rate is the same in terms of
interval etc. the way the queues are affected by the topology are different. For instance the Droptail
queue when used within the Star topology with an interval of 0.005 seconds resulted in all of traffic flow
twos packets being dropped and none being dropped from traffic flow one, however within the
simulation of the Ring Topology it can be seen that traffic flow one incurs dropped packets. Again the
FQ fairs well within this simulation for dropped packets as overall it drops the least.
Average Delay
0.0450000000000000

0.0400000000000000

0.0350000000000000

0.0300000000000000

sec

0.0250000000000000

0.0200000000000000

0.0150000000000000

0.0100000000000000

0.0050000000000000

0.0000000000000000
DropTail Traffic Flow
One

DropTail Traffic Flow

Two

FQ - Traffic
Flow One

FQ - Traffic
Flow Two

RED - Traffic
Flow One

RED - Traffic
Flow Two

SFQ - Traffic
Flow One

SFQ - Traffic
Flow Two

The average delay for all of the simulations, were uniform in terms of traffic flow, for example traffic
flow one from both the Droptail simulation and the SFQ simulation are the same. This is believed to be
happening due to the fact that the maximum delay in terms of queue delay has been obtained. If this is
the case it may be reflected within the throughput graph on the next page.

BSc Communication Networks

-8-

Packets Per Second, Per Traffic Flow, Per Queue

350

300

Packets Per Second

250

200

150

100

50

0
Droptail Flow1

Droptail Flow2

FQ Flow1

FQ Flow2

RED Flow1

RED Flow2

SFQ Flow1

SFQ Flow2

As suspected the data above has resulted in a noticeable similarity between the queues. Since there is a
similarity between the traffic flows, it is believed that the maximum queue delay has been found for the
setting used.
The Tree topology was the largest topology used within the simulations, this
topology used sixteen nodes, but not all of them were used for
communicating. Traffic flow one consisted of node one transmitting to node
fourteen through nodes zero, five and eleven. Where as Traffic flow two
consisted of node six transmitting to node fourteen through nodes five and
eleven. A 1Mb network link is still used along with the same packet sizes
and a transmit interval of 0.005 seconds.

Comparison Of Queue Types Implemented With Tree Network

287
SFQ

2431
2718

292
RED

2421
2713
Packets Dropped
Packets Received
234

Packets Sent

FQ

2537
2771

255
Droptail

2495
2750

500

1000

1500

2000

2500

3000

As with the other simulations the data was compared against the other queues within the topology, as can
be seen above, the FQ queue again outperforms the other queues in terms of packets received and packets
dropped. A closer inspection will reveal if like the other simulations there are trends or not.

BSc Communication Networks

-9-

Comparison Of Dropped Packets For Tree Topology

Traffic Flow Two

165

Traffic Flow One

SFQ
122

182
RED
110

139
FQ
95

224
DropTail
31

50

100

150

200

250

Packets

The comparison of the dropped packets from the Tree simulation show that once again Droptail is biased
to traffic flow two in that the majority of the packets within that simulation were from traffic flow two. It
also appears that the SFQ queue seems to not be as fair as in previous simulations, this may be down to
the fact that traffic flow two had less hops than that of traffic flow one, and as such would have arrived
twice as fast, which would also match the case of the Ring network where traffic flow one went through
more hops than one.
Leading on to the average delay, a graph consisting of all the average delays within the Tree network
topology simulation can be found below.
Average Delay
0.0450000000000000

0.0400000000000000

0.0350000000000000

0.0300000000000000

secs

0.0250000000000000

0.0200000000000000

0.0150000000000000

0.0100000000000000

0.0050000000000000

0.0000000000000000
DropTail Traffic Flow
One

DropTail Traffic Flow

Two

FQ - Traffic
Flow One

FQ - Traffic
Flow Two

RED - Traffic
Flow One

RED - Traffic
Flow Two

SFQ - Traffic
Flow One

SFQ - Traffic
Flow Two

The graph of results looks to be exactly the same as the delay graph from the Ring topology simulation,
as all results are of the same order and size. Again it is believed that this is the case due to the maximum
queue delay time being obtained, using the default queue settings.
A graph showing the average throughputs of all the queues within the Tree simulation can be found on
the next page.

BSc Communication Networks

- 10 -

Packets Per Second, Per Traffic Flow, Per Queue

350

300

Packets Per Second

250

200

150

100

50

0
Droptail Flow1

Droptail Flow2

FQ Flow1

FQ Flow2

RED Flow1

RED Flow2

SFQ Flow1

SFQ Flow2

As was seen within the Ring topology simulation, the data is more uniform than in previous simulations,
which is to be expected if the deduction of the maximum queue delay has been reached. This will be
further analysis and discussed within the conclusion.
Conclusion:
With all of the data simulated now collated and shown within this report a conclusion can be made.
Below is a graph showing a comparison of all the topologies used with an interval of 0.005 seconds.
From this graph it can be shown that that Tree and Ring topology had the largest average throughput in
terms of packets per second compared to that of the Star topology.
Comparison Of Topology @ Interval of 0.005
600

500

Packets Per Second

400

Star
Ring
Tree

300

200

100

0
Droptail

FQ

RED

SFQ

Furthermore it can also be shown that both the Tree and Ring topology are identical at an interval of
0.005 seconds in terms of average throughput as both overlay each other within the graph. It is believed
that if the Star network had more interim nodes between the sending and receiving node it too would have
a larger throughput similar to that of the Tree and Ring topology. This is said as it is believed that a
longer communications link will be able to carry more information than that of a short link. Possibly an
expansion to this investigation would be to investigate if this theory is true.
A comparison of interval rates can be made from the graph on the next page.

BSc Communication Networks

- 11 -

Comparison Of Intervals
400

350

Packets Per Second

300

250
PPS @ Int 0.008
PPS @ Int 0.005

200

PPS @ Int 0.001

150

100

50

0
Droptail

FQ

RED

SFQ

The graph above shows all of the interval rates used within the Star topology simulation. As shown
within the data above, an interval of 0.001 seconds resulted in a higher throughput in terms of packets per
second. It can also be seen that the interval of 0.008 resulted in a level output due to the link being used
to within its bandwidth. A further comparison of the intervals within the Star topology simulations is
made within the graph below.
Comparison of Interval for Star Topology
0.6000000000000000

0.5000000000000000

Seconds

0.4000000000000000

Delay @ Int 0.008

Delay @ Int 0.005

0.3000000000000000

Delay @ Int 0.001

0.2000000000000000

0.1000000000000000

0.0000000000000000
Droptail

FQ

RED

SFQ

The data above show the average packet delay for the given interval and queue. As the data above shows
both the average delay for an interval of 0.005 and 0.008 seconds are the same across the queue types,
with the only change coming from an interval of 0.001 seconds, which results in an extra 0.5 seconds of
delay when queues RED and SFQ are used.
On the next page a comparison of all of the network topologies using an interval of 0.005 seconds is made
with reference to the amount of packets they drop.

BSc Communication Networks

- 12 -

Comparison Of Dropped Packets For All Topologies Using Interval Of 0.005

350

300

Packets Per Second

250

200
Star
Ring
Tree
150

100

50

0
DropTail

FQ

RED

SFQ

The data above shows that on the larger scale of things, with an interval of 0.005 seconds there is little
difference between the simulations in terms of dropped packets other than that of the queue used. With
this in mind a comparison between the intervals for the Star topology was made and can be seen below.
Comparison Of Dropped Packets For Range Of Interval Times
6000

5000

Packets

4000

PPS @ Interval 0.008

PPS @ Interval 0.005

3000

PPS @ Interval 0.001

2000

1000

0
Droptail

FQ

RED

SFQ

As previously shown there were no dropped packets for the 0.001 second interval, however there were
dropped packets for the other two intervals used. An increase in the amount of dropped packets can be
seen when the interval is changed from 0.005 seconds to 0.001 seconds, as roughly another 4700pps are
dropped as soon as the interval is increased to 0.001 seconds. Although the interval rate of 0.001 seconds
transfers more packets per second through the link than the other intervals, having just under 5000pps
dropped is not desirable.
Given the data shown it can be concluded that a Ring or Tree topology is of greater use than that of a Star
topology, as a larger throughput can be achieved with either the Ring or the Tree Topology. For
reliability and fault tolerance a Tree topology would be the ideal topology, as the Ring topology gives
little fault tolerance. It is also considered that the FQ queue would be the most beneficial queue to use if
low packet loss is wanted, as overall it loses fewer packets than the other queues and is a fairer alternative
to that of Droptail queue. Given that if the FQ queue was to be used there would be no penalty in the
form of added delay incurred if an interval of 0.001 seconds were to be used over that of a 0.005 second
interval. However at the rate at which packets would be dropped it would be advisable to use an interval
of 0.005 seconds if not lower, as the losses are relatively low. It should also be noted that the simulation
only use a UDP link and as such dropped packets are not re-transmitted, if this was to be changed to a
TCP link then the situation would become far more hectic as the dropped packets would be re-sent adding
BSc Communication Networks

- 13 -

to the network traffic and load, thus causing more packets further down the line to be dropped like a
domino effect.
Further advancement:
Possible further advancements that could have been made given more time would have been to change
the links within the simulations to that of a TCP link, so to observe how the change in the link would
affect the overall results. The possibility of changing the queue size would have also been advantageous,
along with weighting one of the queues with the aim of observing how it affected the overall outcome.

BSc Communication Networks

- 14 -

References Section

TCL SCRIPT WRITTEN FOR THIS ASSIGNMENT AND USED WITHIN

THE SIMULATIONS.

CD CONTAINING ALL OF THE EXCEL SHEETS WHICH CORRELATE

THE DATA

BSc Communication Networks

- 15 -