NB: Intent Latency

Objective:

The purpose of this test is to characterize ONOS' intent installation, withdraw and re-routing latencies as the cluster size scale out from 1 to 3, 5, 7 nodes. In order to have a high performance distributed system, a single-node ONOS should have low latencies. As we scale the cluster out, we expect there are additional distributed system overheads for communicating with all other nodes; however, such overhead penalties should not be so high as to detriment performance significantly. 

We also want to characterize the performance with Intents as various of batch sizes, initially, 1, 10, 100,1000, 5000 intents in a batch. 

1) Batch intent install/withdraw latency

The main parameter to control how distributed the intents need to be is by the assignment of the switch masterships. We maintain a linear 7-switch topology as the base topology (an eighth switch is used for re-routing test). The switch mastership assignment will depend on the number of nodes in the cluster, for example, when testing a 1-node standalone ONOS, this ONOS is the master of all 7 switches; when testing a 7-node cluster, each ONOS node will be master of one switch, etc. 

We use a build-in ONOS application "push-test-intents" as a tool to push various sizes of intent batches (point-to-point intents) and obtain the returned response times of "install" and "withdraw". Only ONOS1 is used to push the intent into the cluster as we scale out. The point-to-point intents are between ports of the first and last switches of  the linear topology. Therefore we maintain a constant path for all intents as we scale out.

Timing synchronization among the nodes is kept by running ptpd on all nodes.

Test is iterated multiple times in order to obtain statistical results.

Procedure:

1. Configure Mininet , or Null Provider (device, link config files) to reflect topology required for the specific test;
2. Run "push-test-intents" with the end points and intent batch size to obtain response time;
3. Iterate through multiple times (excluding warm-up runs) to obtain statistical results.

2) Batch intent reroute latency

Method:

We use the same setup in the previous test. In order to stimulate re-routing of Intents, we cut the shortest path in the mininet topology (or activate the link-cut link description file, if using Null Provider)  and cause all previously installed flows to be re-routed to the newly calculated path. Given a sufficient wait time, we use the "intents-events-metrics" to record the latest to intent event as the completion of re-route. 

Procedure:

1. Reroute measurement begins by installing the same intents, without withdraw operation,  as in intent install latency test, by "push-test-intents -i";
2. Cut the shortest path, and record from ONOS log the timestamp when ONOS see topology change, as t0
3. Check ONOS "intents-events-metrics" for the latest intent Installed event timestamp, as t1. It may be necessary to give it some wait time (a few seconds) so that the intent events can complete and reflected in the metrics. 
4. The re-routing latency is calculated as t1 - t0.