Network Simulation

Due: December 6, 2014

This project involves using the ns-2 simulator on hopper.cs.luc.edu to explore the behavior of two TCP flows competing on the same bottleneck link when one of the flows starts later than the other. Information on ns-2 can be found in intronetworks.cs.luc.edu/current/html/ns2.html.

Here is some preliminary data when the second-flow delay is 2000 ms, the run-time is 15 sec, the bottleneck delay is 120 ms, the bottleneck bandwidth is 0.8 mbps (1 packet / 10 ms), and the "overhead" parameter (introducing randomization in packet send times) is set to 0, meaning no randomization is added. Packets are counted by counting the ACKs. The delayed connection is tcp1; the ACK number for tcp0 includes only ACKs since tcp1 started.

Note the rather remarkable change when the queue size is 17. What happens at queuesize = 17? A second question is why, as the queue size gets larger, the initial head-start becomes increasingly beneficial to the first flow. The goal of this assignment is to identify the reasons for this behavior, and to identify the other aspects of the simulation configuration that contribute.

The topology of the simulation is as follows:

# n0      
#   \     
#     \   
#      mid---dest
#     /
#   /
# n1

The first flow, tcp0, connects from n0 to dest; the second flow, tcp1, connects from n1 to dest. The simulation is in the file latestart.tcl, which accepts the following command-line parameters:

• start1, the delay in starting tcp1, in milliseconds
• queuesize, the size of the queue at node mid
• bottleneckDelay, the propagation delay in ms on the mid--dest link, normally 120 ms
• endtime, the time at which the simulation ends (eg 30 seconds)
• overhead, an attribute to introduce randomization to packet transmission times (default = 0 means disabled)
• bottleneckBW, the bandwidth of the mid--dest link, normally 0.8 mbps

The first three parameters seem to be the ones most influential on the results. Your first goal should probably be to vary these in controlled ways, to find out how they influence the queuesize=17 change above and the long-term tcp1 behavior.

Increasing endtime will, evenetually, bring tcp0 and tcp1 goodput to parity (though you might ask just how long this will take). You can try varying overhead according to the suggestion in intronetworks.cs.luc.edu/current/html/ns2.html#phase-effects-and-overhead, eg by setting it to 0.01 or 0.02 (seconds) because the bandwidth delay is 0.01 seconds, but this should be done after you have identified how the other variables affect the simulation. The bottleneckBW seems to have only a secondary effect here.

The table above was produced by setting start1=2000, etc, and varying queuesize. The shell-script used to do this, queuevary.sh, is

start1=2000
qsize=15
bottleneckDelay=120
endtime=15
overhead=0
bottleneckBW=0.8
for qsize in 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 28 30 32 34 40 45 50 60 70 80 90 100
do
   ns latestart.tcl $start1 $qsize $bottleneckDelay $endtime $overhead $bottleneckBW
done

The latestart.tcl script generates, for each run, four lines like

tcp0  acks since tcp1 started = 375
final tcp1 (late-start tcp) ack = 569
queue size was 10
2.000000 10 15 0.000000 0.800000 120.000000 375 569

My usual practice is to keep only the last line (eg with egrep -v 'tcp|queue'), and then to load these lines into a spreadsheet. Be sure you label the columns correctly. You can then add additional computed columns as desired.

Turn in a report describing your experiments and your results. If you changed latestart.tcl, or create a significant shell script to run your experiments, submit that too.

Where to run ns

Running ns directly under Windows is difficult (but not impossible; see the ns webpage; you will need cygwin). One option is to install ns on a virtual machine running Ubuntu. Another option is to log in to one of knuth.cs.luc.edu or shannon.cs.luc.edu and use ns there.

One way to connect using ssh is to go to https://ada.cs.luc.edu/shell using Chrome only, and use the username/password sent to you in an email. Then you should get a new screen that lets you log in directly. (Sometimes, however, this is down.) 

I have created a script ns that runs the ns program on knuth.cs.luc.edu; it's also in /home/users/cs/faculty/pld/bin/ns. Use this to run ns (perhaps by putting it in your own bin directory). The script takes care of all the library setup. I've also put this into my queuevary.sh shell script (found in my ns-examples directory); if you use the latter on your own installation you might have to comment some of this out.