## 3 Problem Description: TFL as an Inconsistent Network Update Problem  
Despite the centralization of the logic control, SDN remains a distributed and an asynchronous system. Indeed, the data plane is managed by a logically-centralized controller that communicates with the data plane only by OpenFlow message passing via asynchronous communication channels. In the real world, during updates, applications running on the controller may compile several entries, requiring the controller to disseminate OpenFlow messages to install entries on switches. Therefore, the switches may deliver OpenFlow messages that are injected by the controller and in-fly packets, which interleave with update messages in any order, leading to inconsistent updates.  
Flow swaps: a motivating scenario. In order to analyze the TFL phenomenon in SDNs, we use a common and inevitable network update scenario known as flow swaps. Figure 2 illustrates an example of a basic flow swap scenario. In this scenario, the topology is composed of an OpenFlow controller and two switches. Initially, Switch 1 (\(S_{1}\)) contains an entry that forwards a specific packet flow \(f_{i}\) to Switch 2 (\(S_{2}\)) (see Figure 2a). Due to a network policy change, \(f_{i}\) should be forwarded from \(S_{2}\) to \(S_{1}\). To this end, the OpenFlow controller starts by instructing, based on two controller-to-switch OpenFlow messages of type _FlowMod_, (1) \(S_{1}\) to delete the entry directing \(f_{i}\) from \(S_{1}\) to \(S_{2}\) (see Figure 2b) and, then, (2) \(S_{2}\) to install a new entry to forward \(f_{i}\) from \(S_{2}\) to \(S_{1}\). While the controller sends Operation (1) before Operation (2), the second operation finishes before the first one. In this case, an in-fly packet flow \(f_{j}\) may interleave with the installation of the rule in \(S_{2}\), forwarding network traffic to \(S_{1}\), and then \(f_{j}\) enters into a TFL between \(S_{1}\) and \(S_{2}\).  
Based on the previous example, an SDN update may result in a broad combinatorial range space of messages and packets ordering, and thus, the controller may not assume anything about the data plane state. Therefore, the network wide-view from the controller may be temporarily or permanently inconsistent with the current data plane state. Intuitively, this affects the consistency of network updates. Indeed, three of eleven bugs reported in [10] were caused by inconsistent views from the controller. Alternatively, an OpenFlow controller can explicitly request acknowledgments by sending a barrier request message (_BarrierReq_) after sending a message, that is it sets a synchronization point between messages. An OpenFlow switch of a destination should then respond with a barrier response message (_BarrierRes_) once the message and all other messages received before the message have been processed [2]. However, in which case and time should the controller explicitly request to install a BarrierReqmessage? What about the overhead of messages in large-scale networks? On the other hand, such a solution forces the system to stop processing any new requests until all messages sent before the _BarrierReq_ message are completely processed. Indeed, this solution can harm performance by increasing the number of control messages, controllers, switch operations, and delays.  
Figure 2: Flow swap scenario: (**a**) initial forwarding policy; (**b**) after updating the initial forwarding policy.