SB: Switch and Port Event Latency

Objective:

This series of tests are designed to characterize ONOS core's intrinsic response time in a single Openflow event. The events characterized are switch connection and port up/down. We expect single-node ONOS to have a fast event response time. As the cluster size grows, we expect the overhead of communicating the events throughout the cluster should add additional latency to the response time. We determine that a link event is not a good vehicle to run the latency test. This is because that latency will be largely dominated by the LLDP packet timing. The resulted latency will show no intrinsic behavior of ONOS core.

1. Single switch add latency

Method:

In order to have accurate accounts of event timing among all nodes of the cluster,  we first have to establish a synchronous clock using PTP protocol among the tester and ONOS nodes.

We use OVS switch(OF v 1.3) to emulate a switch first establish connection with ONOS. For more about the connection protocols, you may refer to the Openflow specification for the details. As the switch establishes the connection with ONOS, it triggers a set of OF message exchanges, and subsequently generate ONOS device event and graph event. Those events are also communicated throughout the cluster. 

In order to only characterize the ONOS core's intrinsic response time, we eliminate the external effect's such as tcp handshake time by starting a timer (t0) when tcp "SYN/ACK" is detected at the ONOS node with TSHARK. Subsequently, we obtain the latest event-type timestamps (t2_a and t2_c) from "topology-events-metrics", from all nodes of the cluster. The latest timestamps reported by all nodes of the cluster is used as the response time of ONOS as a system. The latency is calculated as the difference of these timestamps and t0. 

Results from multiple runs are used to collect statistical mean and deviation.

Diagram illustrating timing of a OVS switch add triggering a chain of ONOS events, eventually registering a Graph event in ONOS.

Procedure:

1. Start tshark tool (having the OF dissector plugin installed) on ONOS1 OF interface; tshark is configure to filter on TCP connection between the switch and ONOS1;
2. Assign a single (floating) ovs switch to ONOS and measure the latency of switch assignment based on various event update timestamps. This is achieved through the command 'ovs-vsctl set-controller <switch name> tcp:<ONOS ip>';
3. Give the system a sufficient wait time (usually in a few seconds), check on all ONOS nodes "topology-events-metrics" to collect the latest timestamp on Device and Graph Events;
4. Collate all timings to dissect various OF messages and latency to Devices and Graph events.

2. Port up / down discovery latency

Method:

Method used for this measurement is similar to switch event latency measurement. There are a number of differences in the method. Instead of switch connection event,we use a port up/down activity as the event. In this case, a two-switch/single-link topology is used - simply started with Mininet. Similarly, in order to characterize the intrinsic core capability and eliminate external effects, the starting timestamp of "t0" is when we TSHARK to detect Openflow message of port status after we trigger the event on the OVS switch.

Diagram illustrating timing of a chain of ONOS events when an OVS switch port is brought up or down.

Procedure:

1. Similar to switch up measurement,  port events are invoked by calling 'ifconfig <up / down>' on the corresponding interface to which the port of s1 is connected to s2;
2. from tshark capture of OF timing to collate the sequence of OF message exchange in relation with the Link and Graph events recorded on ONOS nodes.