\subsection{Fault Tolerance in \SDN Networks and Operating Systems}
{\bf \SDN Fault Tolerance:} Fault tolerance within the \SDN environment has been a subject of research for quite some time; however, research has focused on shielding application developers from writing application code that needs to reacts to switch failures~\cite{fattire:hotsdn13,shadowsdn:hotsdn13}, link failures, or application server failures~\cite{rulebricks:hotsdn13}.  Unfortunately, little has been done to shield the network and the controller from application failure. It is precisely this that \name focuses on.

Recent approaches~\cite{onix:osdi10,b4:sigcomm13} to tackle controller failure, focus on recovering from hardware failures: applying Paxos~\cite{pease-1980-paxos} to ensure robustness to controller server failures (hardware failures). Unfortunately, little has been done to detect or recover from software failures.  Most specifically failures induced by bugs within the controller platform or the controller applications.  In this paper, we argue these problems are equally as important as hardware failures (server failures) and provide a solution that tackles application failures. We leave controller platform failures for future work.

We note that high-level controllers restrict and control the application syntax thus potentially eliminating errors. However, current commercial deployments are dominated by modular or low-level controllers due to their low adoption barrier~\cite{floodlight_greatestecosystem}.

{\bf Bugs in \SDN Code:} Recent work~\cite{veriflow:hotsdn12, ofpostcard:nsdi14} to detect bugs in \SDN applications focus on detecting bugs that generate output that violates certain invariants; essentially focusing on bugs that impact the safety or correctness of the network.  Instead, we attack an orthogonal problem, that of detecting bugs that result in controller failures; essentially focusing on bugs that impact the availability of the controller. 


{\bf Operating System Fault Tolerance:} Our approach builds on several key operating system principles, namely; isolation~\cite{microreboot:osdi04}, failure oblivious computation~\cite{failureobliviouscomputing:osdi04}, and shadowing~\cite{fgft:asplos13,shadowdrivers:tcs06}. However, these approaches either assume that bugs are non-deterministic and thus can be fixed by a reboot~\cite{microreboot:osdi04,fgft:asplos13,shadowdrivers:tcs06} or that safety and completeness can be compromised in the face of availability~\cite{failureobliviouscomputing:osdi04}.  Similarly, we compromise completeness for availability but focus on ensuring safety in all situations and ensuring that network operators have control over the degree of completeness that can be compromised for availability. 
%More interesting, we aim to provide a solution that allows the operators to choose between different levels of compromise.

More concretely, we utilize \SDN's programmatic control to roll-back and undo the network events created by failure inducing input thus ensuring safety.  In addition, we provide operators with an interface for specifying the degrees of correctness they are willing to tolerate on a per-application basis. 