Image

OpenDaylight (ODL) Performance Report
OpenDaylight Base Edition - Hydrogen release benchmarked using Veryx PktBlaster SDN Controller

July 17, 2014

We conducted some performance tests in our lab for OpenDaylight Base Edition - Hydrogen release SDN controller, running on standard server platform, using Veryx PktBlaster SDN. The server platforms had dual Intel Xeon processors with 16GB of RAM.

The objective of this performance test is to assess the controller's Flow Setup rate (a.k.a. Throughput) and Flow Setup time (a.k.a. Latency) for constant and varying network loads. The test had been configured to use OpenFlow 1.3 version, and TCP connection setup.

The first test was conducted with a constant switch load of 128 switches. We observed that the controller's average Flow Setup rate was 3315 flows per second and the average time to setup a flow on a switch was 618 milliseconds. Please refer Reports 1 and 2 for more details.

The second test was conducted with 64 switches, and then stepped up to increase the number of switches in every iteration by 25%- essentially, ranging from 64 to 256 switches.

We observed that the controller's maximum Flow Setup rate was 10653 flows per second for a switch load of 64 switches and the minimum flow setup time was 401 milliseconds for switch load 128 switches. Please refer Reports 3 and 4 for more details.

We conclude that the OpenDaylight base edition hydrogen release gives lower flow setup rate and higher flow setup delay. While it may not be ideal for a network infrastructure which is highly dynamic, it provides a great starting point for those who wish to do a proof of concept (POC) before transitioning to SDN based network.

Veryx is working on measuring performance of other public domain SDN controllers (OpenFlow and non-OpenFlow) and will be publishing them in Veryx's blog periodically. Please stay tuned.

For reports of vendor specific controllers, contact Veryx

Disclaimer: This report has been focused on specific features and/or performance of the product(s) and was conducted under laboratory conditions. Since performance may vary in real-world conditions, users should conduct tests in their own environments to ensure the accuracy of the data contained herein. In no event shall Veryx Technologies be liable for any kind of direct, indirect, special, incidental or consequential damages which may result from the use of information contained in this document.

    User Comments

  • Others
    Thomas Edwards

    When you say "flow setup time", do you mean the time from the initiation of the OpenFlow rule install on the switch until the flow becomes actually usable? Most of the references I have seen for OpenFlow is 1ms to 10ms per rule (with a long tail). It would be great to know how much of this is a network communication and API time versus how much of this is a TCAM reorganization time.

  • Veryx
    Bhuvaneswaran Vengainathan

    Thanks Thomas for posting your query. The flow setup time mentioned in our post is the performance metric for the SDN controller. It is the time taken by the controller to process a flow request from the switch (i.e., Network communication time + Controller API time), expressed in milliseconds. The tool, Veryx PktBlaster SDN Controller used for the above testing uses the methodology defined in the IETF draft submitted by us.

    Please refer to the draft at http://tools.ietf.org/html/draft-bhuvan-bmwg-of-controller-benchmarking-00#section-6.1.2 for more details and let us know for more clarifications.

  • Others
    Marcos Salvador

    Our experience with controllers and switches tell us the bottleneck is typically in the OpenFlow (physical) switches rather than in the controller(s), but it is difficult to say if that is the case in this test since nothing is said about the switches (e.g., are they physical or virtual?).

  • Veryx
    Bhuvaneswaran Vengainathan

    You may be correct Marcos if we also look at the flow setup bottlenecks at the physical switch. As we are benchmarking the controller’s performance, we have simulated OpenFlow switches for these tests using our tool. The measurement point is between the exit of OpenFlow requests from the switch and entry of OpenFlow responses into the switch.