103 lines
4 KiB
Markdown
103 lines
4 KiB
Markdown
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.
|