Traffic engineering techniques used by the framework

In this section we first describe how a domain controller can identify flows that could benefit from a cut-through tunnel. Second, we describe what is the most appropriate way to setup a tunnel once a flow has been identified as candidate.

6.5.1 Deciding which flows to forward through a tunnel

The first step consists of analyzing traffic to identify flows that could benefit from a cut-through tunnel. The first technique detects elephant flows at the edge of the network. The second takes advantage of the GNRS capabilities and deduces the mobility of the destination device. The third uses the service type field in a MobilityFirst packet to allow the sender, or a previous controller, to indicate that a tunnel should be used.

6.5.1.1 Controller-initiated cut-through based on flow rate and duration

The first technique that we implement and evaluate is a reactive approach. The decision of whether to send a flow through a tunnel is taken by the domain controller based on the observed traffic. The goal is to detect large, long duration flows (also known as elephant flows) that can benefit from cutting through the MobilityFirst routing mechanisms. The motivation for this technique is that elephant flows are long enough to benefit from a cut-through tunnel even when a small overhead is incurred to create the cut-through. Also, elephant flows usually have a high data rate and reducing the overhead needed to forward data increases the throughput significantly. Mouse flows (short flows), on the other hand, do not necessarily benefit from this because the transmission of data could be finished by the time the bypass is created, or not long enough to actually benefit.

Previous studies have addressed elephant flow detection using packet sampling techniques [239, 240, 241]. Psounis et al. [241] propose SIFT, a detection algorithm based on biased sampling. The intuition behind the algorithm is to sample with

a low probability. Using this method, when a probability of p=0.01 is used, all

flows with more than 100 packets are detected and the probability of sampling a mouse flow is low. We implement the SIFT algorithm to detect elephant flows.

To detect large flows, traffic statistics must be observed. Although the OpenFlow protocol provides ways to query each switch for traffic statistics, this solution is too slow (data can only be obtained every five seconds). We use sFlow [211] to counter this problem and sample traffic every second. sFlow is a packet sampling tool used to monitor network usage. sFlow agents are deployed in network devices such as switches or routers and the information gathered is sent to a centralized collector. sFlow-RT is a monitoring framework that incorporates the sFlow analytic engine to provide real-time visibility in Software Defined Networking (SDN) [242]. A script running on the domain controller server obtains the metrics collected by sFlow-RT using the REST API. Using this data, the biased sampling technique proposed by the SIFT algorithm is used to detect large flows. When a flow has been labeled as elephant, the script uses the REST API of the Floodlight controller to find a route between the source and the destination and create a layer-2 circuit.

6.5.1.2 Controller-initiated cut-through based on mobility

The second technique is also reactive and leverages a specific feature of Mobility- First: the GNRS server. In MobilityFirst, every device connected to the network should register to the GNRS to notify the current attachment point. This notifica- tion is achieved through an update message that contains the GUID and the new set of NAs to which the device is attached. Therefore, the GNRS offers a unique

opportunity to track the mobility of all devices attached to a set of NAs.

To implement the controller-initiated cut-through based on mobility, we first expand the GNRS server so that it also keeps track of the number of updates issued by each device. With our implementation, when the GNRS receives a query for a given GUID, the response contains a timestamp of all update messages received by the GNRS for the given GUID.

Next, we leverage the SDN controller to dynamically process the timestamps and determine the degree of mobility of the destination device. To measure the degree of mobility, the controller takes into consideration the number of updates sent by the device in the last hour. If the device has remained attached to the same access point for more than an hour, it is considered static and the controller can initiate a cut-through tunnel for this flow. If the number of updates is larger than zero, then the node is considered mobile and a tunnel is not created for the flow.

6.5.1.3 Sender-initiated cut-through

The third technique is a proactive approach that can be used by the sender of data to ask for a cut-through tunnel to be used. Unlike the previous two, this approach is proactive because the sender device requests the network to use a cut-through tunnel. Thus, the controller does not react to traffic observations or GNRS responses but to a request introduced by the sender in the network packets.

This method makes use of the service type field of MobilityFirst packets. This field encodes the requested processing or delivery service(s). In MobilityFirst, it was designed to allow the user to request different delivery methods, such as unicast or multicast. By setting the service type to a specific value, a sender asks the network to forward all packets in that flow through a tunnel.

does not actually decide if a bypass should be used or not, it only creates it assuming that the sender knows why a bypass can be beneficial. Note that this is an advantage but also a risk. Certainly, this technique is the easiest to achieve by the controller (no traffic observation or timestamps parsing needed). On the other hand, the sender assumes all the responsibility of sending data through a bypass and this could be detrimental if the destination is highly mobile.

6.5.2 Deciding how to setup a tunnel

Once the controller has identified a flow that could benefit from a tunnel using the described techniques, the next step is to decide what is the best way to setup such tunnel. To do this, we use the insights learned in Section 6.3 that showed how the inter-domain latency plays a key role on the optimal creation of tunnels. Therefore, we incorporate into the framework the ability to create inter-domain tunnels only if the inter-controller latency is low, and to use intra-domain tunnels otherwise.

6.5.2.1 Combined technique

To consolidate the three techniques and the heuristic, we propose a method that combines them all. The main goal of this combined technique is to admit a flow into a tunnel when at least two of three ‘conditions’ exist: long flows, low mobility or user-requested tunnel. Each flow has candidate points to be accepted in a bypass tunnel. An elephant flow earns three points and a tunnel request from the user also earns three points. Finally, a static destination adds four candidate points to a flow. To ensure low mobility and another condition, this technique works by creating tunnels only to flows that have at least seven candidate points.

Another feature of the combined technique is that it allows to upgrade or downgrade flows as candidates for a tunnel. Suppose a flow has been sending

high traffic rates for a long time and the destination was static. Therefore, this flow had seven points and was part of a bypass. Later, if the destination stops being static or if the data rate is reduced, this flow can be downgraded and removed from the bypass. Similarly, it can be added again if the conditions change again.

Finally, the combined technique also considers the inter-controller latency to decide if a single end-to-end tunnel should be created, or if an intra-domain tunnel should be used instead.

Algorithms 4, 5 and 6 show how the combined traffic engineering technique operates. First, incoming flows are analyzed to identify the mobility degree and service type (Algorithm 4). Next, traffic is periodically sampled to identify elephant flows and update mobility degrees (Algorithm 5). Finally, Algorithm 6 is responsible for creating the tunnels or mapping flows to existing tunnels.

Data: new flow f

//New flow, check mobility and service type serviceType = getServiceType();

mobilityDegree = getMobilityDegree(); if serviceType = bypass then

f.candidate += 3; end

if mobility = low then f.candidate += 4; end

Algorithm 4:Combined technique applied to incoming flows.

6.6 Experimental evaluation

We first demonstrate that the framework is capable of detecting elephant flows and mobile destinations using the combined technique shown in Section 6.5. After that, we focus on demonstrating how inter-domain tunnels reduce the number of packets that must be handled by domain controllers. We also compare the number