The following is my simulation model,two simulation instance and my
analysis.
SIMULATION MODEL
By writing the Otcl script cifq.tcl,we define a very simple topology with
two nodes that are connected by a link. The following two lines define the
two nodes.
set n0 [$ns node]
set n1 [$ns node]
Then we connect the two nodes by using the following line:
$ns duplex-link $n0 $n1 1.5Mb 10ms CIFQ
This line tells the simulator object to connect the nodes n0 and n1 with a
duplex link with the bandwidth 1.5 Megabit, a delay of 10ms and a CIFQ
queue.
We regard n0 as a base station and it schedules three sessions. Each
session correspondents to a flow. The n1 is a destination node and it
receives packets that n0 sends. In our simulation, we only simulate the
down-link scheduler.
Then we set the parameter of the three flows, including weight, queue size
and error rate. We use the uniform distribution error model. The random
variable is uniform distributed from 0 to 1.
The next step is to create three agent objects that send data from node n0,
and another three agent objects that receive the data on node n1. Then we
attach three CBR traffic generators to the three UDP agents and define
packet size and interval. We identify the three flows as flow0, flow1 and
flow2.
The simulation starts at 0.0 second and finishes at 10.0 second. The flow0
starts at 0.0 second, the flow1 starts at 0.1 second and the flow2 starts
at 0.8 second.
The simulation model can be simply described as following
flow0------> cifq,1.5mb,10ms
flow1------> n0-------------------------->n1
flow2------>
After running the cifq.tcl script, we can get out.nam and out.tr files. Nam
is a Tcl/TK based animation tool for viewing network simulation traces and
real world packet traces. It supports topology layout, packet level
animation, and various data inspection tools. The trace file records each
individual packet as it arrives, departs, or is dropped at a link or queue.
SIMULATION INSTANCE
(a) instance 1
The tableI presents the parameters of each flow:
TableI parameters of each flow
Flow0 Flow1 Flow2
Weight 2 2 2
Packet size (bytes) 1000 1000 500
Packer interval (seconds) 0.008 0.008 00067
Max length of queue (bytes) 5000 5000 10000
Start time (second) 0.0 0.1 0.8
Finish time (second) 10 10 10
Error rate 0.0 0.4 0.2
We obtain the following results by analyzing the trace file:
TableII the results of instance1
Flow0 Flow1 Flow2
Enqued packets (packets) 1242 1228 1350
Sended packets (packets) 654 641 1150
Dropped packets (packets) 588 587 200
Received packets (packets) 653 640 1148
Average packet delay(second) 0.085 0.3008 0.2978
Packet-dropped rate 47.3% 47.8% 14.8%
Average throughput (Mbps) 0.5224 0.512 0.4592
From tableI, we can know that flow0 is error-free but flow1 and flow2 will
experience error. Flow1s error rate is 0.4 and flow2s error rate is
0.2. Except for error rate, the parameters of flow0 are the same as flow1
s. Flow2s interval and packet size are smaller than flow0 and flow2s.
From tableII, we can know that the average packet delay of flow0 is much
more shorter than the other twos, and the average throughput of each flow
is almost equal, because they are at the same weight. This results validate
the first properties of CIF that Delay bound and throughput for error-free
sessions are guaranteed, and are not affected by other sessions being in
error. The packet-dropped rate and average throughput of flow1 are almost
equal to flow0s. This result validate the second property of CIF that
During a large enough busy period, if a session becomes error-free, then,
as long as it has enough service demand, it should get back all the service
lost while it was in error, which is long term fairness for error
sessions.
It is worth noting that the packet-dropped rate of flow2 is much more
smaller than the other twos. It is because that the max queue length of
flow2 is lager than the other twos, while its packet size is smaller than
theirs. So we can conclude that for WF2Q+ , the packet-dropped rate is
relative to max queue length and packet size.
(b) instance 2
The tableIII presents the parameters of each flow:
TableIII parameters of each flow
Flow0 Flow1 Flow2
Weight 2 4 2
Packet size (bytes) 1000 1000 500
Packer interval (seconds) 0.008 0.008 00067
Max length of queue (bytes) 5000 5000 10000
Start time (second) 0.0 0.1 0.8
Finish time (second) 10 10 10
Error rate 0.0 0.4 0.2
We also obtain the following results by analyzing the trace file:
TableIV the results of instance2
Flow0 Flow1 Flow2
Enqued packets (packets) 1237 1231 1432
Sended packets (packets) 479 931 919
Dropped packets (packets) 758 300 513
Received packets (packets) 478 930 918
Average packet delay(second) 0.0981 0.0483 0.2042
Packet-dropped rate 61.3% 24.4% 35.8%
Average throughput (Mbps) 0.3824 0.744 0.3672
From tableIII, the difference of parameters between simulation instance2
and instance1 is only in that flow1s weight changes from 2 to 4. But From
the tableIV the results is quite different. For error-free session (flow0),
its delay bound and throughput are also guaranteed. From average
throughput, long term fairness for error session (flow1 and flow2) is
achieved, too.
There are two facts worth noting. The one fact is that the flow1s delay
is shortest among the three flows. Although flow1 experience error, its
weight is lager than the other twos. The other fact is that flow1s
packet-dropped rate is smallest among the three flows, and it is much
smaller than that in instance 1. We think it is also because the flow1 has
a larger weight. So we can conclude that for WF2Q+, weight is an important
parameter.
Zeng Kai