User Tools

Site Tools


openbach:exploitation:reference_scenarios:network:delay:index

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
openbach:exploitation:reference_scenarios:network:delay:index [2019/04/25 15:39]
duboise ↷ Page moved from openbach:exploitation:scenarios:network:delay:index to openbach:exploitation:reference_scenarios:network:delay:index
openbach:exploitation:reference_scenarios:network:delay:index [2020/06/26 10:33]
kuhnn
Line 4: Line 4:
 To assess the delay in a deployed network, one may easily exploit the results given by the ICMP ping command. However, this measure may not reflect the actual delay that applications may face. To properly measure the delay in a given infrastructure,​ we recommend to compare the results of various delay measurements jobs. Depending on the targeted evaluation (application level, transport level, network level, etc.), one measure may be more relevant than one other. ​ To assess the delay in a deployed network, one may easily exploit the results given by the ICMP ping command. However, this measure may not reflect the actual delay that applications may face. To properly measure the delay in a given infrastructure,​ we recommend to compare the results of various delay measurements jobs. Depending on the targeted evaluation (application level, transport level, network level, etc.), one measure may be more relevant than one other. ​
  
-The most common way to assess delay in a deployed network remains to use round-trip time metric. Our choice is to use two tools one at ICMP level (fping) and one at UDP level (hping) to enforce the measurement. ​+The most common way to assess delay in a deployed network remains to use round-trip time metric. Our choice is to use two tools one at ICMP level (fping) and one at UDP level (d-itg) to enforce the measurement. ​
  
 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.  ​ 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 tool owping (composed of two jobs: owamp-client and owamp-server) is provided by OpenBACH in another ​scenario. ​+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 tool owping (composed of two jobs: owamp-client and owamp-server) is provided by OpenBACH in the [[openbach:​exploitation:​reference_scenarios:​network:​one_way_delay:​index|One Way Delay reference ​scenario]]
    
  
 ===== RTT Delay diagnostic including post processing ​ comparison scenario ===== ===== RTT Delay diagnostic including post processing ​ comparison scenario =====
-This scenario provides a delay diagnostic of a deployed network. It is assumed that the network is stable. The diagnostic allows to sequentially assess different delay metrics (RTT and one-way delay)+This scenario provides a delay diagnostic of a deployed network. It is assumed that the network is stable. The diagnostic allows to sequentially assess different delay metrics (RTT)
  
 ==== Objective ==== ==== Objective ====
-The purpose of this scenario is to compare delay results obtained from jobs: fping, hping (RTT) and owping (One-way Delay). +The purpose of this scenario is to compare delay results obtained from jobs: fping and d-itg (RTT). ​
  
   * ''​fping''​ measures the RTT delay (in ms) using the ICMP protocol (i.e. time since ICMP request sent until ICMP response received)   * ''​fping''​ measures the RTT delay (in ms) using the ICMP protocol (i.e. time since ICMP request sent until ICMP response received)
  
-  * ''​hping''​ measures the RTT delay (in ms) using the negotiation packets for opening a TCP connection (i.e. time since SYN sent until SYN-ACK received).+  * ''​d-itg''​ measures the RTT delay (in ms) using the an UDP connection (i.e. time since d-itg sender the packet ​until d-itg sender receive the same packet from d-itg receiver).
  
-  * ''​owping''​ measures the one-way delay (in ms) using OWAMP (One-way Active Measurement Protocol) detailed in [[https://​tools.ietf.org/​html/​rfc4656|RFC 4656]]. 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 [[https://​www.perfsonar.net/​|perfSONAR]]. +D-itg and fping (which are persistent jobs) are launched during the duration ​time (default 10)
- +
-Hping and fping (which are persistent jobs) are launched during ​60s. 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.+
  
 ==== Methodology ==== ==== Methodology ====
 Two approaches are used to analyse the delay: Two approaches are used to analyse the delay:
-  * The first one considers a parallel/​simultaneous launch of the three jobs.  +  * The default ​first one considers a sequential launch of the two jobs in order to avoid any overload caused by the injected test packets (active measurement methods). ​ 
-  * The second ​one considers a sequential launch of the three jobs in order to avoid any overload caused by the injected test packets (active measurement methods). ​+  * The second one considers a parallel/​simultaneous launch of the two jobs
  
 The scenario proposed herein will then: The scenario proposed herein will then:
-  * Launch subscenarios delay_simultaneous or delay_sequential as subscenarios (allowing to compare the RTT measurement of fping, ​hping and owamp jobs).+  * Launch subscenarios delay_simultaneous or delay_sequential as subscenarios (allowing to compare the RTT measurement of fping, ​d-itg).
   * Launch two postprocessing jobs to compare the time-series and the CDF of the delay measurements. ​   * Launch two postprocessing jobs to compare the time-series and the CDF of the delay measurements. ​
  
-These scenarios have been written using the [[openbach:​manuals:​2.x:​user_manual:advanced_user_api:​scenario_builder:​index|scenario builder]].+These scenarios have been written using the [[openbach:​manuals:​2.x:​developer_manual:openbach_api:​index|scenario builder]].
  
 ==== How to launch it  ==== ==== How to launch it  ====
  
-The scenario is available in [[https://​forge.net4sat.org/​openbach/​openbach-extra/​blob/​master/​apis/​scenario_builder/​scenarios/​network_delay.py | network_delay ]]. It uses helpers (see [[openbach:​manuals:​2.x:​user_manual:advanced_user_api:manual_scenario_api:​index ​| API scenario manual]] for more information on helpers), and subscenarios ''​delay_sequential''​ and ''​delay_simultaneous''​. ​+The scenario is available in [[https://​forge.net4sat.org/​openbach/​openbach-extra/​blob/​master/​apis/​scenario_builder/​scenarios/​network_delay.py | network_delay ]]. It uses helpers (see [[openbach:​manuals:​2.x:​developer_manual:scenario:old_manual| API scenario manual]] for more information on helpers), and subscenarios ''​delay_sequential''​ and ''​delay_simultaneous''​. ​
  
-You must already have a project (i.e. "​your_project"​),​ two entities in the project (a server and a client), the hping/fping/​owamp-client ​jobs installed in the client and the owamp-server ​job installed in the server. You also need to install histogram and time-series jobs on the "​your_entity"​.+You must already have a project (i.e. "​your_project"​),​ two entities in the project (a server and a client), the d-itg_send/fping jobs installed in the client and d-itg_recv ​job installed in the server. You also need to install histogram and time-series jobs on the "​your_entity"​.
  
-The reference scenario ​script [[https://​forge.net4sat.org/​openbach/​openbach-extra/​blob/​master/​reference_scenarios/generate_network_delay.py | generate_network_delay]] will allow to launch it as follows.+The executor ​script [[https://​forge.net4sat.org/​openbach/​openbach-extra/​blob/​master/​executors/​reference/executor_network_delay.py | executor_network_delay]] will allow to launch it as follows.
  
 <code shell> <code shell>
-python3 ​generate_network_delay.py -o -p your_project ​--client ​your_client_entity --server ​your_server_entity --ip_dst @IP --entity_pp your_entity run+python3 ​executor_network_delay.py -o PROJECT_NAME ​--clt your_client_entity --srv your_server_entity --clt_ip your_client_ip --srv_ip your_server_ip ​--entity_pp your_entity run
 </​code>​ </​code>​
  
-By default, it launches the scenario with the simultaneous ​methodology. If you want to launch the sequential ​one, you should add "- -sequential" to your arguments.+By default, it launches the scenario with the sequential ​methodology. If you want to launch the simultaneous ​one, you should add "--simultaneous" to your arguments. 
 + 
 +By default, it launches the scenario for a duration of 10 seconds. If you want to change the duration, you should add "​--duration duration_in_sec"​
  
 Alternatively,​ it can create a JSON file that could be imported to the OpenBACH web interface: Alternatively,​ it can create a JSON file that could be imported to the OpenBACH web interface:
  
 <code shell> <code shell>
-python3 ​generate_network_delay.py -o -p your_project ​--client ​your_client_entity --server ​your_server_entity --ip_dst @IP --entity_pp your_entity build .+python3 ​executor_network_delay.py -o PROJECT_NAME ​--clt your_client_entity --srv your_server_entity --clt_ip your_client_ip --srv_ip your_server_ip ​--entity_pp your_entity build .
 </​code>​ </​code>​
  
 An example of the type of results that this scenarios is capable of plotting is shown below: An example of the type of results that this scenarios is capable of plotting is shown below:
  
-{{ openbach:​exploitation:​scenarios:old:delay:time_series_rtt_owd_sent.png |}}+{{ :openbach:​exploitation:​reference_scenarios:network:delay:time_series_rtt_rtt_sender.png?​nolink ​|}}
  
-{{ openbach:​exploitation:​scenarios:old:delay:histogram_rtt_owd_sent.png |}}+{{ :openbach:​exploitation:​reference_scenarios:network:delay:histogram_rtt_rtt_sender.png?​nolink ​|}}
  
 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. 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.
openbach/exploitation/reference_scenarios/network/delay/index.txt · Last modified: 2020/10/22 09:58 by kuhnn