CS5229 (2011/2012) NS2 Assignment

Due date: November 10, 2011

1. Introduction
The objective of this assignment is to give you hands-on experience in working with NS2 by running few
scenarios, changing some part of the existing modules and implementing new features for NS2. The
major focus of this assignment is on studying the performance of TCP by applying different active
queuing management mechanism (AQM). Although, both TCP and AQM have been implemented in
several different versions, you only need to concider Tahoe, Reno, NewReno and SACK [1] for TCP and
Droptail and RED [2] for AQM. You are adviced to stick with the requirement of this assignment and
deliver exactly what you are asked for.

2. Learning Objectives
The three major objectives of this assignment are:

 Learn how to use NS2 to simulate different network scenarios

o Study the performance of the four stated TCP protocols in presence of the two AQM
algorithms
 Learn how to change the existing NS2 modules
o Modify the existing RED module
 Learn how to implement and add your own protocols to NS2
o Add your own implemented AQM to NS2

3. Methodology
You will see one section for each aforementioned objective in this assignment. Please keep this format
for your report as well. You will be given some instructions on how to write and organize your report.

A. Simulating scenarios by NS2

a. Combining different TCP and AQM
You are going to simulate four network scenarios in this section. The topology that you need to apply is
given in fig.1. Use it for all four simulations. As it is shown, there are four flows among four source-
destination pairs, namely S1-D1, S2-D2, S3-D3 and S4-D4 flows. This scenario gives you the feeling of
point-to-point communication. Please find the network configuration parameters from table 1 for each
seperate scenario that you need to simulate. You are asked to include the following subsections in your
report using the results obtained from your simulations.
 1. For each scenario, plot the average throughput and average end-to-end delay of each flow when
the capacity of the bottleneck links (R1-R3 and R2- R3) decreases from 10Mbps to 1Mbps (in 10
steps, with the step size of 1Mbps).
2. Compare different flow curves for each figure.
3. Compare four delay figures and discuss your findings
4. Compare four throughput figures and discuss your findings
5. Change the AQM of R3 to RED, repeat the simulations and do step 1 to 4 for your new results. Is
there any difference between the two sets of figures? Why?

Figure 1: Poin to point topology

AQM Buf. Size Pkt. Duration

Scenario
R1 R2 R3 (packet) size (sec)
RED 1 2 3 4
DT (Minth=15,Maxth=45)
DT 100 1KB 50
TCP Tahoe Reno NewReno SACK
Table 1: Simulation configuration for Poin to point topology

b. Client-Server Scenario
In the second part of this section, you are going to experience another popular communication
paradigm which is the Client-Serevr model. Here, you need to creat more clients who are
communicating with a single destination. Again you need to repeat this simulation for all the four
network parameters given in table 2. Illustrate the simulation results as:

1. Plot both average queue size and instance queue size versus time for the bottleneck router in
each scenario. An example of the curve is illustrated in Fig. 3
2. Compare four figures

Figure 2: Client server topology

Number Buf. Size Pkt. Duration

AQM(R1) TCP Scenario
of flows (packet) size (sec)
1 2 3 4
50 RED Tahoe 100 1KB 50 Minth 15 20 25 30
Maxth 45 60 75 90
Table 2: Simulation configuration for client server topology
 Figure 3: Average/instance queue size vs time

B. Modify NS2 core

The aim of this section is to give you the chance to understand NS2 implemented modules and the skill
to modify them. Therefore, you are required to modify the already implemented RED module and
compare it with your own implementations. What you need to do is to apply the packet-marking
probability functions given in fig. 4 to the original RED module and run your simulation. The first version
of packet-marking probability function is a concave function instead of linear function for calculating pb.
The second and third versions have two different piece-wise linear functions. The forth version is a
convex function.

1. Implement four different versions and compare them to the regular RED
2. Which version is better than regular RED and which one is worse?
3. Is there any special situation that a version outperforms the regular RED?

You can use the file provided at /ns-2.34/queue/red.cc and /ns2.34/queue/red.h to begin your job.

Use regular RED in all scenarios. Neither use gentle RED (described here) nor adaptive RED (described
here).

Figure 4: Packet-marking probability

C. Add your own protocol to NS2

Now it is time to develop and add your own protocol into NS2. You should design a new AQM algorithm,
describe your idea in the report, implement it and then compare it with regular RED. Your AQM
algorithm controls the queue size in a way that queue size does not exceed the buffer size. If the queue
size exceeds the buffer size, it leads to lots of dropped packets and TCP global synchronization. In
addition, queue size should not stay zero otherwise it causes a huge degredation in throughput. Also
less queue size fluctuation is desirable because less fluctuation bounds the jitter. So far, many
researches have been conducted to improve the RED’s performance and we encourage you to use their
idea and cite the papers.

4. Notes
1. To do the assignment write scripts that parse the ns2 trace files. These scripts enable you to
calculate average throughput, loss rate, end-to-end latency and TCP congestion window for all
flows. You may use any scripting language such as awk, shell scripts, Tcl, Perl, Python etc. You
may use any tool you like to plot the figures such as gnuplot, Microsoft Excel, Matlab, xgraph
(included with ns-2) or any other tool.
2. You are required to repeat the simulation 10 times with different seeds, get the average and
then plot figures (only for throughput and end-to-end delay). Make this process automatic as
much as possible. For example we prefer a script that do the simulation, get the average and
show the requested figures.

5. Deliverables
 Write a report at most in 15 pages including everything such as figures. You are welcome to do
your own related investigations that give you more insight about the assignment and add them
to your report. However you should stick to the limit for your report. The report should be in the
ACM Large Format Single Column. You can find Microsoft Word format here and Latex format
here.
 Send a zip file including one readme file, your scripts and your impemented code. In the readme
file you will describe how I can use your script to get the same results that you plot in your
report. This section should works automatically as much as possible. The zip file should not
contain your figures. Instead, your scripts should generate them when I execute the scripts.

6. Submission guidline
The deadline for your assignment will be on November 10, 2011 in class. Deliver a hard copy of your
report at the class. Also you are supposed to email a soft copy of the report and the zip file (described
before) to [email protected] with “NS2 Assignment” title on November 10, 2011. There is penalty
for late submission. By one day delay you will lose 30% of the mark. By two days delay you will lose 50%
of the mark. We will not accept any submission after 12 of November 2011.

7. Assessment
Your assignment will be evaluated based on both your report and your code and scripts. The criteria for
evaluation are:

 Correctness of your implementation, simulations and results (45%)

 Your analysis of your findings (40%)
  Automation (15%)

8. Useful Links
 Installation
 Introduction to the Tcl command language
 Videos by Prof Ooi Wei Tsang
 Download and installation of NS2 (homepage)
 NS2 manual
 NS by Example
 Post processing NS2 result
 Configure NS2 in eclipse
 Binding variables

References
[1] K. Fall and S. Floyd. Simulation-based comparisons of Tahoe, Reno and SACK TCP. ACM SIGCOMM
Computer Communication Review, 26(3):5-21, 1996.

[2] S. Floyd and V. Jacobson. Random early detection gateways for congestion avoidance. IEEE/ACM Transactions
on Networking, 1(4):397-413, 1993.

[3] S. Ha and I. Rhee. CUBIC: A new TCP-friendly high-speed TCP variant. ACM SIGOPS Operating Systems
Review, pages 64-74, 2008.

[4] L. Xu and K. Harfoush. Binary increase congestion control (BIC) for fast long-distance networks. INFOCOM
2004. Twenty-third, 4(C):2514-2524,2004.

[5] C. Zhang, J. Yin, Z. Cai, and W. Chen. RRED: robust RED algorithm to counter low-rate denial-of-service
attacks. IEEE Communications Letters, 14(5):489-491, May 2010.