# Net4sat wiki

### Sidebar

dambox:user_manual

﻿

# User Manual

## Route traffic to DamBOX

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:

iptables -F

## Validation of the installation of DamBOX

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.

To ensure that your installation is correct, we RECOMMEND to reproduce the experiments that can be found in either the User Manual or in the OpenSAND Manual.

Note that there are limitations related to the machines that are exploited and the targeted throughput or patterns may not be achievable.

## Run DamBOX

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 [100000] and packets will be stored during 5*ds and released during ds.

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+\). The debug mode can be deactivated.

dambox --help

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.

## Validation

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.

### Impact on the goodput

For this test, DS is set to 13 ms and freq to 2 (the resulting timeline is [10]). 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.

### Impact on the delay and jitter

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.