\section{Introduction}
%SDN embodies a novel paradigm that is poised to revolutionize the networking industry, with research predicting a market size of \$3.5 billion~\cite{}. Despite its burgeoning ecosystem and proven benefits, many companies remain hesitant in adopting it. Two of the foremost issues that hamper to SDN adoptions are reliability and fault tolerance~\cite{}. These issues are only bound to become even more important as societies grows increasingly dependent  on cloud computing and online social networks.

Despite Software Defined Network's, SDN, proven benefits, many companies remain hesitant in adopting it. Two of the foremost issues that hamper to SDN adoptions are reliability and fault tolerance~\cite{}. \asim{I remember reading security is the biggest problem}. In a traditional SDN deployment, there are four main failure scenarios: controller server failures (hardware failures), controller crashes (bugs in the controller code), network device failure (switch, application server or link failure), and application crashes (bugs in the application code). While much work has gone into debugging the SDN ecosystem~\cite{sdnlayerdebugging:hotsdn13, ofpostcard:nsdi14, veriflow:hotsdn12, nice:nsdi12}, little work has gone into hardening SDN again these failures.

Most recent work focuses on overcoming hardware failures, namely controller server failures~\cite{onix:osdi10, b4:sigcomm13} and network device failures~\cite{shadowsdn:hotsdn13,fattire:hotsdn13}. Unfortunately, software failures remain un-addressed.  Furthermore, traditional operating system and application-server fault-tolerant techniques like reboot or replay~\cite{microreboot:osdi04,shadowdrivers:tcs06} can not simply be applied to the SDN control plane for three reasons.  

First, both the network and the applications both contain state, rebooting~\cite{microreboot:osdi04} the application will eliminate this state leading to inconsistency issues.  Second, unlike with in an OS, where-in a web-server can be rebooted without affecting other applications on the same OS, in an \SDN environment, the \SDN app is intermingled with the controller, so a reboot affects all other apps.  Third, replaying events~\cite{shadowdrivers:tcs06} to recover this state implicitly assumes that the bugs are non-deterministic and thus wouldn't be encountered during replay. However, we argue that given the event driven nature of \SDN applications, bugs will most likely be deterministic. In fact a brief survey of controller and application forums confirms this.
\asim{this is a very strong claim: all events, no threading. are you sure a single application does not have multiple threads in a controller library?}
% asim : shadowdrivers:tcs06 removed: I REMOVED THE SHADOW DRIVER REFERENCE, shadow drivers infact, do replay and driver code is also mashed with OS. you are better off sticking with applications in this section.


In this work, we focus on application crashes because the controller code represents a common layer that is highly re-used and thus has a lower probability of bug, whereas the application code is more likely to be provided by third party entities with limited testing.  A trend that is expected to become even more prevalent given the recent success of project \floodlight~\cite{floodlight_greatestecosystem} and the development OpenDayLight project~\cite{opendaylight}.   Furthermore, as stated earlier the lack of a clean separation between applications and controllers, introduces a fate-sharing relationship where-in an application crash induces a controller crash.  


The principle position of this paper is that availability is the upmost concern -- second only to perhaps security. To this end, we propose a re-architecture of the controller architecture that eliminates fate-sharing between applications through isolation and that relaxes the correctness of the polices implemented by an application with a {\it best-effort model}. We argue for a model where-in applications may not process all network events, 
to maintain controller availibility.

%We argue that strictly enforcing correctness requires that the application process all network event; however, if these events themselves trigger failures then the application is unable to satisfy both correctness and availability. In certain situations, we believe that the availability is a better choice than blindly enforcing correctness. \asim{there goes the determinism?}

The challenge lies in determining when to compromise correctness, how much to comprise, and how to ensure safety while compromising correctness. Where-in safely is defined as: at most one copy of a message is sent from the application to the network that the application is aware of all messages sent to the network. Thus during an application rollback, the network must also rollback. To overcome these challenges, we leverage properties of \SDN applications, namely that they are event driven.  This allows us to isolate and detect crash-triggering events and in turn determine when to compromise.  In addition given the nature of network events, we can allow the operator to choose between various levels of comprise. For example, if a link down event triggers an application crash. The operator can choose compromise 100\% by ignoring the event, or 0\% compromise by crashing the application, or something in between by transforming the port down event into a switch down event.  Finally, for safety, we implement a network roll-back mechanism which leverages the insight that most \SDN events are invertible. \asim{is this true for all events, then say all SDN events are invertible} For example, installing a rule is invertible by deleting the rule.

%
%Given the strong desire to maintain networks with five 9s of availability, we argue that such compromises are acceptable. 
%
%Furthermore, we show that given the appropriate architecture, application isolation and application fault tolerance complement each.

% Furthermore, a redesign of the controller architecture enables a large array of features currently absent.
%
%\name builds on \appvisor and aims to target both Bohrbugs bugs (deterministic) and Heisenbugs bugs (non-deterministic).
%
To this end, we propose \name a system that embodies the described principles.  \name provides isolation layer between applications and introduces a fault tolerance layer that detects crash triggering events and overcomes them through event transformations.  In \name applications run unmodified, thus shielding application programmers from having to understand the functionality and recovery techniques provided by \name.
%
\name provides a policy language for operators allowing them to specify the set of applications and network events whose accuracy and efficacy they are willing to compromise on.
%
This enables operators to trade-off between control plane available and correctness of network policy.
%
Thus allowing the network to persevere in the face of application crashes and provide slightly degraded functionality until a fix or patch can be deployed.
%
As a proof-of-concept, we re-architected the \floodlight controller to support \name. Using this prototype, we demonstrate that \name imposes minimal overheads and requires no application modifications.


\breadcrumbs{The rest of this paper is structured as follows: in section~\ref{}, XXX.}
\comments{
%{\it Migrating Applications Between Controllers:} Processor migration is a well understood technique in the O.S community. By treating individual controller apps as processes, we can leverage these migration techniques to move apps between distributed controllers. This would be particularly useful as a strategy to combat over utilized servers.

\begin{table}	
	\vspace{-0.05in}
	\begin{center}
\begin{tabular}{cc}
%$$\begin{figure}
		%\noindent \hrulefill 
		\epsfig{file=figs/FPGFlowChart.eps,height=2in} 
%\end{figure}

&

%\begin{figure}
		%\noindent \hrulefill 
		\epsfig{file=figs/ShadowApp.eps,height=2in} 
%\end{figure}
\end{tabular}
\vspace{-0.1in}
\caption{(a) Flow chart encoding fault tolerant module functionality. (b) \name Architecture}
	
\label{f:overload}
	\end{center}
\vspace{-0.35in}
\end{table}
}
