\chapter{Conclusions}
In this work, we focus on the test of OpenFlow switch performance based on
the following categories:
control-plane-trigger-data-plane, data-plane-trigger-control-plane, and
OpenFlow data plane. We propose five test cases to evaluate six performance
metrics: action time, pipeline time, packet-in rate, packet-out rate,
pipeline gain, and timeout accuracy. These six items can be used to evaluate and reflect
the switch performance.

\subsection*{Larger idle timeout deviation for hardware switches}
In the results of timeout accuracy, the hardware switches have
around $\pm20\%$ deviation for idle timeout. This may cause the error for applications
based on the idle-timeout.

\subsection*{Better new flow handling capability for hardware switches}
In the testing results, the hardware switches are capable of generating Packet-in rate in the ranging from
3000 to 7000 Packet-in per second. This rate is approximately $20$ times higher than that of the software switches.

\subsection*{Well pipeline implementation for hardware switches}
%TODO: need to discuss
For the measurement of pipeline gain, The hardware switches reach $40-60\%$ pipeline gain
under handling the 1Gbps traffic. There has a large gap between hardware and software switches.
And the number of available tables have the large deviation. All the switch under test, these
switches only have around 60 usable tables, but these switches said they have 254 tables in the feature report.

\subsection*{Issues for switch implementation}
We observed issues and problems during the testing for the OpenFlow switched.
Firstly, the switches may not be well implemented on the
design of Apply-Action instructions. Secondly, the switches crashed with the high volume of burst
Packet-in traffic. Moreover, the timer
of idle-timeout is not reset properly when the flow entry matched.

\subsection*{Future work}
For our experiment, performance factor affected by the loading of the switched is excluded.
This may cause
some variance for our testing results presented. We plan to apply this factor and discuss some
advanced issues to our experiment in the near future.
Furthermore, the calculation of the queuing time will be integrated in the pipeline time.
In the measurement of pipeline time, we plan to use the finished time at the first table instead
of the sending time of the packet. Thus, the measurement of pipeline performance should be more accurate.
