\section{Prototype and Evaluation}

Motivated by its lush support ecosystem, its frequent use as the controller platform of choice by \SDN application developers, and the fact that \floodlight project boasts the world's largest \SDN ecosystem~\cite{floodlight_greatestecosystem} we decided to modify the \floodlight controller platform to support \name.  We note that these changes are easily generalizable to other modular controllers such as NOX and OpenDayLight and Beacon. 
%
\evalsuperflous{
In addition, OSGI model adopted by both the OpenDaylight and Beacon controller platforms indeed provide us with half the mechanisms and the support system required to implement the AppVisor.  
%
We discuss our prototype in section~\ref{s:prototype}
%
}

Furthermore, to illustrate the overhead both in terms of performance and in terms of developer effort, we run a number of {\it unmodified} \floodlight 
applications on our re-architected controller.
%
\evalsuperflous{
We present initial results in section~\ref{s:results}.
}

\input{prototype}

\subsection{Evaluation}
\label{s:results}
We implemented and tested 3 unmodified \floodlight Applications; a simple MacTracker, a hub, and a switch.  Next, we examine the overheads placed by our technique.

\evalsuperflous{
First, we examine overheads in terms of controller server resources. In Figure~\ref{f:results} (a), we example the memory and process foot print of running each application with \Floodlight (FL) or our modified \floodlight (Safe-FL). We note that the number for the modified \floodlight are the memory and processor footprint of the JVM with \floodlight+\proxy and the JVM+\stub.  We find that, XXXXX.
}


We examine overheads in terms of delay placed on the control loop. To do this, we measure the time between receiving a network event and when an output is generated by the controller.  For the MacTracker, this is the time between \pktin events and print out statements.  For the other 2 applications, this is the time between \pktin events and \flowmod events.  In Figure~\ref{f:results} (b), we present the results for the most complicated application, the switch, however, these results generalize to the other applications.  We observe that \name introduces at most a 100 $\mu$ second latency.

Our results, show that highly availability is achievable with minimal costs. Given that involving the controller introduces at least a 10ms latency to packet processing, we argue that the additional 100$\mu$ second latency, or 1\% inflation in latency, is both acceptable and ultimately inconsequential.  We believe that these costs can be further reduced when our approach is streamlined into the controller's core design. 

\begin{figure}
	\begin{tabular}{cc}
	xx	& 
	xxx
		\\
		(a) & (b)
	\end{tabular}
	\caption{Comparison between a vanilla \floodlight instance and one modified to support \name.}
	\label{f:results}
\end{figure}
