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