ns3-dumbbell-sim/README.md

Simulation of a dumbbell topology using ns3 3.17

dependencies (on Debian based distros):

libns3-dev (= 3.17)

compilation:

make

example execution:

$ cat << END | ./dumbbell-sim > log
UR TCP 536 0.0 1250
UR TCP 536 250 500
LR UDP 1000 750 1000 0.9Mbps
END

The file log then contains traces with the first column being the timestamp, the second column being the ns3 context and the third column being the traced value of this context. The traced values are TCP congestion window size changes, received packets and queue drops.

The traffic description is done via standard input. Each line represents one flow and the dumbbell will be created such that it has as many clients on each side as there are flows. Each flow will originate from a unique node N on the left side of the dumbbell and reach node N on the right side of the dumbbell. This way, every node is involved in exactly one flow and the connection in the center of the dumbbell serves as the bottleneck.

So above example would create the following topology:

 L1                R1
   \              /
    \+--+    +--+/
L2---|LR|----|RR|---R2
    /+--+    +--|\
   /              \
 L3                R3

The flow given in the first line would originate from L1, go through the bottleneck link between the left and right router (LR and RR, respectively) and end at R1. The flow given in the second line would go from L2 to R2 and the last one from L3 to R3.

Flow description format

Each line represents one flow between two unique nodes of the dumbbell, flowing from left to right. Each line is split by their white spaces. The first element represents the type of flow. There are three flow types.

LR: this type stands for "limited rate" and allows to specify traffic which is limited by transmission rate. Start and stop times govern the duration of this traffic.

UR: this type stands for "unlimited rate" and allows to specify traffic which is sent as fast as possible. Only TCP traffic is allowed. Start and stop times govern the duration of this traffic.

LT: this type stands for "limited transfer" and allows to specify traffic which is sent as fast as possible. Only TCP traffic is allowed. The amount of data to transfer governs when this flow stops transmitting.

The second element in each line is the transport type an can be either "TCP" or "UDP". Observe the restrictions of transport type with respect to the flow type.

The third element is the package size to send. For TCP traffic this will also adapt the segment size of the underlying socket.

The fourth element is the start time of the flow given in seconds.

For LR and UR flow types, the fifth element is the stop time given in seconds. For the LT type, the fifth element is the maximum transfer size, given in bytes. For all types, the fifth element governs when the flow will stop.

The LR type takes a sixth element, specifying the desired transmission rate. This value is given with a unit like "Mbps".

Commandline Arguments

While flow descriptions are read from standard input, commandline arguments allow to setup properties of the dumbbell topology. By default, the error rate of the involved links is 0.0, which means no packet is dropped by the physical links. The default TCP congestion-avoidance algorithm is NewReno and other options are Tahoe, Reno, Westwood and WestwoodPlus. The default bandwith and latency of the bottleneck link is 1Mbps and 50ms, respectively. The default bandwidth and latency of the access links of the nodes to the routers is 10Mbps and 1ms, respectively.

When giving an error rate other than 0.0, a random element is introduced. It is possible to make this randomness deterministic by using the --run option which allows to make deterministic runs with the same outcome, given the same run number.

Depending on the flow definitions you might want to start the simulation early. This is possible with the --simstop argument.

You can enable pcap tracing of all links with the --tracing option.