Filtering rules based on iptables are necessary to redirect incoming packets to DamBOX.
iptables –I FORWARD –j NFQUEUE
Other parameters may be relevant for the filtering rule :
-p: Filter only one type of protocols (e.g.: UDP)
-o: Filter only packets intended for an interface
-i: Filter only packets coming from an interface
-d: Filter only packets destined to an IP address
-s: Filter only packets sent by an IP address
To delete the filter rules, simply execute the following command:
Before any utilisation of the DamBOX, the user MUST test the limits related to the machines that are exploited, otherwise results will not be relevant.
Note that there are limitations related to the machines that are exploited and the targeted throughput or patterns may not be achievable.
Run DamBOX as follows:
dambox -ds $ds -f $freq (-d $duration --debug)
Two parameters are mandatory :
ds: duration in us (microsecond) of a timeslot. DS should not be below one millisecond.
freq: frequency at which packets are released. As one example, for freq=6, the timeline will be  and packets will be stored during
5*dsand released during
DamBOX can be parametrized to run during a finite time. To do so, the parameter
duration must be specified (in seconds). If
duration is not specified, the executable will run until the user stop the program manually (ctrl+c, ctrl+z, ctrl+\).
debug mode can be deactivated.
More information can be otain by running :
The program exploits the specified parameters to establish the timeline. Then all the incoming packets are stored on the FIFO. They are only retransmitted to the recipient when the beam is considered switched ON. Architecture of DamBOX provides more information about the parameters and the architecture of the program.
At the end of the execution, if the debug mode is activated, the program gives access to two output files:
profil_dam.txt: Evolution of the blocking/releasing over time
profil_fifo.txt: Evolution of the FIFO filling over time. The unit is the bytes.
This section aims to validate how DamBOX stores and releases packets as expected.
To validate the implementation of DamBOX, the following architecture is exploited. DamBOX is applied on Host 2 and on the interface towards Host 3.
For this test, DS is set to 13 ms and freq to 2 (the resulting timeline is ). Iperf3 transmit a UDP traffic at 22.5 Mbit/s.
The profile of the incoming and outgoing traffic of DamBOX is shown below:
The rate profile follows the timeline profile. Flow peaks are observed each time the packets are released at the interface goodput.
For further validate the implementation, this section assesses how DamBOX modifies the latency and jitter of a communication.
This test was performed without DamBOX, with DamBox and a timeline [1,1] and then with a timeline [1,0]. The DS used is set to 13 ms.
|Without DamBOX||With DamBOX (timeline) [1,1]||With DamBOX (timeline) [1,0]|
|Average jitter (ms)||0.0138||0.0121||0.232|
|Average latency (ms)||0.2895||0.3145||3.5655|
Using DamBOX without actually storing and releasing packets (e.g. with timeline [1,1]) does not have a considerable impact on the latency and jitter of the communication.
With the timeline [1, 0] and the DS=13ms, we see a latency increase of 3.251ms. With a timeline [1,0], half of the packets will be interrupted by the DamBOX. With a DS of 13ms, packets will wait on average 6.5 ms in the box. The theoretical value (6.5*50%=3.25) corresponds to the experimental value. There is also an increase in the average jitter with the introduction of the beam-hopping in the communication.