State of OpenFlow 2012 Testing Notes – Days 12-14 – IWNetworks SDN 8952S

More Information on Latency and Testing the IWNetworks SDN 8952S

We are happy to be able to announce the third vendor in our tests: IWNetworks.

The IWNetworks SDN 8952S OpenFlow capable 10/40GbE Switch

IWNetworks has provided Router Analysis with an SDN 8952S switch.  The SDN 8952S is a 48 port 10GE + 4 port 40GE line-rate capable switch with OpenFlow v1.0 support.  In our testing we were able to connect the switch to our RouteFlow setup and our Floodlight setup without any issues.  As this is not a speed test, we did not do any benchmarking of the IWNetworks SDN 8952S.  We are happy to have IWNetworks join in the State of OpenFlow 2012 Testing and Analysis.

Latency Measurements

As discussed in our last post, we have been working on better measurements regarding latency of the first (few) packets that are passed to the OpenFlow Controller and re-directed through the switch.  As we are attempting to make very precise measurements, we do not want to pre-post any data before we are able to reproduce it.  We are working with all three vendors to cross confirm all test results.  We are also working with Dr. Christian Esteve Rothenberg Ph.D from CqPD which developed and supports the RouteFlow Project an open source project to provide virtualized IP routing services over OpenFlow enabled hardware.

Initial measurements were done using ICMP, i.e. ping to determine how much time the initial packet took to get through the system.  Here are some of the “test” (I have to use the word loosely as using ping is a very generic way of testing things and reliant on too many moving parts, machine speed, link speed, etc).

root@rfvm1:~# ping 172.31.2.2

PING 172.31.2.2 (172.31.2.2): 48 data bytes
56 bytes from 172.31.2.2: icmp_seq=0 ttl=64 time=13.767 ms
56 bytes from 172.31.2.2: icmp_seq=1 ttl=64 time=1.997 ms
56 bytes from 172.31.2.2: icmp_seq=2 ttl=64 time=2.081 ms
56 bytes from 172.31.2.2: icmp_seq=3 ttl=64 time=1.971 ms
56 bytes from 172.31.2.2: icmp_seq=4 ttl=64 time=2.085 ms
— 172.31.2.2 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.971/4.380/13.767/4.694 ms
root@rfvm1:~# ping 172.31.3.2
PING 172.31.3.2 (172.31.3.2): 48 data bytes
56 bytes from 172.31.3.2: icmp_seq=0 ttl=64 time=13.503 ms
56 bytes from 172.31.3.2: icmp_seq=1 ttl=64 time=2.039 ms
56 bytes from 172.31.3.2: icmp_seq=2 ttl=64 time=1.926 ms
56 bytes from 172.31.3.2: icmp_seq=3 ttl=64 time=1.970 ms
56 bytes from 172.31.3.2: icmp_seq=4 ttl=64 time=1.937 ms
— 172.31.3.2 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.926/4.275/13.503/4.614 ms

Here we are pinging the test port of our machines from the RouteFlow Routing VM (rfvm1 = Quagga running in a LXC container).  The first packet takes ~13.5ms to return, the packets after that take ~2ms.

We at Router Analysis are currently working on more specific measurements down to the nano-second.

Summary

The inclusion of IWNetworks in our tests last week as “Vendor X” and the “unnamed vendor” supports our and many of our friends assertion that the Routing and Switching market will be disrupted by Network Programable switches.  We have worked with IWNetworks before and because of that relationship IWNetworks reached out to us about their new switch.  There are other vendors out there developing or possibly releasing switches that support OpenFlow that we as Router Analysis don’t know about.  If your company has an OpenFlow compatbile switch that we have not mentioned, please reach out and let us know.

As for Latency, the more we know, the better off we all are in the networking field.  Being able to define the latency of your design is important.  From what we have seen, you can add anywhere between 10-30 ms to your path.  This can be improved as we are using copper GE, VMs and other tools that add to the latency, it won’t be 0, but it will get closer.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.