# Net4sat wiki

### Sidebar

openbach:exploitation:reference_scenarios:network:one_way_delay:index

## One way delay Metrology

### Context

To assess the delay in a deployed network, one may easily exploit the results given by the ICMP ping command.

However, this value may not reflect the real situation of the network of interest if the links from test host and to test host are unbalanced. To obtain this unbalanced delay assessment and better understanding of the tested network, one may use one-way delay tool which provides delay values on each link. The tools owping (composed of two jobs: owamp-client and owamp-server) and d-itg (composed of two jobs: d-itg_send and d-itg_recv) are provided by OpenBACH.

This reference scenario describes how to launch a simple one way delay scenario based on owamp and d-itg tools.

The synchronization of the agents is very important for the accuracy of the measurement. Please verify the synchronization of the agents before running this reference scenario.

## One way delay diagnostic including post processing

This scenario provides a one way delay diagnostic of a deployed network. It is assumed that the network is stable. The diagnostic allows to assess both directions of one way delay metric.

### Objective

The purpose of this scenario is to launch one way delay results obtained from owping (One-way Delay).

• owping measures the one-way delay (in ms) using OWAMP (One-way Active Measurement Protocol) detailed in D-ITG Manual. OWAMP requires a client/server architecture. A server daemon is installed on the test host and a TCP control connection is opened between the two client/server machines. Then, client launches owping command which sends test UDP packets. There are two jobs to correctly execute owping test: owamp-client and owamp-server. owamp-client returns two statistics: owd_sent (OWD from client to server) and owd_received (OWD from server to client). This tool has been implemented by perfSONAR.
• d-itg measures the one-way delay (in ms) using d-itg (Distributed Internet Traffic Generator) detailed in RFC 4656. d-itg requires a client/server architecture. A server is installed on the test host. Then, client sends test UDP packets. There are two jobs to correctly execute this test: d-itg_recv and d-itg_send. d-itg_send returns two statistics: owd_receiver (OWD from client to server) and owd_return (OWD from server to client). This tool has been implemented by Traffic.

Owamp-client is not a persistent job, it sends 100 test packets by default and after that the job instance stops. As it is shown in the following scenarios, owamp-server job must be launched before owamp-client with a guard period to let enough time to the server to be switched on. This guard time depends on the current delay of the network of interest. In this scenario example, the guard time has been set to 5s.

D-itg_send is not a persistent job, it sends 1 packets per second during 10 seconds, and after that the job instance stops. As it is shown in the following scenarios, d-itg_recv job must be launched before d-itg_send with a guard period to let enough time to the server to be switched on.

### Methodology

The scenario proposed herein will then:

• Launch subscenarios one_way_delay as subscenarios (owamp and d-itg jobs).
• Launch two postprocessing jobs to compare the time-series and the CDF of the one way delay measurements.

These scenarios have been written using the scenario builder.

### How to launch it

The scenario is available in network_one_way_delay . It uses helpers (see API scenario manual for more information on helpers), and subscenarios one_way_delay.

You must already have a project (i.e. “your_project”), two entities in the project (a server and a client), the owamp-client and d-itg_send jobs installed in the client and the owamp-server and d-itg_recv jobs installed in the server. You also need to install histogram and time-series jobs on the postprocess entity.

The executor script executor_network_one_way_delay will allow to launch it as follows.

python3 executor_network_one_way_delay.py your_project --client-entity your_client_entity --server-entity your_server_entity --server-ip your_server_ip --client-ip your_client_ip --post-processing-entity your_pp_entity run

Alternatively, it can create a JSON file that could be imported to the OpenBACH web interface:

python3 executor_network_one_way_delay.py your_project --client-entity your_client_entity --server-entity your_server_entity --server-ip your_server_ip --client-ip your_client_ip --post-processing-entity your_pp_entity build .

An example of the type of results that this scenarios is capable of plotting is shown below:

The plots can be downloaded from the OpenBACH web interface: go to the scenario instance, click on export CSV, check the histogram and time-series boxes and click on Download.