{'fraction_non_alphanumeric': 0.02072114763279197, 'fraction_numerical': 0.005212596389953905, 'mean_word_length': 5.042165538781885, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Framework for Application-aware Networking by Delegating Traffic Management of SDNs

Presence of a logically centralized controller in software-defined networks enables smart and fine-grained management of network traffic. Generally, traffic management includes measurement, analysis and control of traffic in order to improve resource utilization. This is done by inspecting corresponding performance requirements using metrics such as packet delay, jitter, loss rate and bandwidth utilization from global network view. There has been many works regarding traffic management of software-defined networks and how it could help to efficiently allocate resources. However, the vast majority of these solutions are bounded to indirect information retrieved within the border of ingress and egress switches. This means that the three stage loop of measurement, analysis and control is performed on switches in between this border while the traffic flowing in network originates from applications on end hosts. In this work, we present a framework for incorporating network applications into the task of traffic management using the concept of software-defined networking. We demonstrate how this could help applications to receive desired level of quality of service by implementing a prototype of an API for flow bandwidth reservation using OpenFlow and OVSDB protocols.


I. INTRODUCTION
The term SDN was first introduced in an article which was describing the OpenFlow project at Stanford University [1]. OpenFlow stemmed from observing the fact that most new networking community ideas went untried and untested, so it was considered a means for researchers to let them test their experimental protocols in a production network [2]. It enabled programmability of network by setting rules in switches flow tables. Since then, the definition of SDN has expanded and OpenFlow is just one possible data plane or southbound API. Furthermore, SDN relies on control and data plane separation but does not reduce to just this, but in general, SDN is all about abstraction provided by forwarding devices with welldefined instruction sets, carefully designed network operating systems called controllers along with data and control plane separation by using appropriate southbound and northbound APIs [3].
The controller in software-defined networks maintains a global network view of traffic flows, link connectivity states, network resource allocation, etc. The control plane in these networks installs arbitrary forwarding and monitoring rules in TCAM entries of SDN switches to be matched on by data plane. This provides near-optimal, fine-grained decision making for traffic management tasks such as load balancing, fault tolerance, topology updates and traffic analysis compared to sub-optimal, coarse-grained decisions made in legacy networks.
Measuring and controlling QoS parameters like packet delay, jitter, loss rate and throughput is an inherent part of traffic management tasks and an important input to many decisions in computer networks. There has been several approaches towards maintaining these parameters in different types of networks. With more visibility into network resources, SDN introduced more efficient approaches [4]. However, these solutions are limited to knowledge of measurements performed on flow table entries within ingress and egress switches area. In other words, knowledge of controller about network traffic is confined to statistics of the rules it eventually had to install in order to forward the traffic towards destination while the traffic originates from end host applications.
In this paper, we argue that in some environments such as data centers, these network applications better know the nature and anticipated QoS of the traffic they are generating and thus might be able to help the controller to treat the traffic in a more efficient manner. When network application programmers are sending data in some parts of their code development process, they could ask the network controller through an API for special QoS treatment tailored to the nature of the data and the controller could investigate the possibility of providing the service and respond accordingly. By using this framework, some portions of traffic management are delegated to applications and the network becomes more applicationaware. This is not straightly possible in legacy networks due to distributed control. We will discuss that DiffServ [5] does not provide fine-grained guarantees some applications might expect. However, the logically centralized controller in software-defined networks enables more direct monitoring and control on network resources while being a designated authority who the applications could talk to through an API.
The remainder of this paper is organized as follows: Section II discusses related work on traffic management. Section III presents the suggested framework and Section IV continues by presenting a use case implementation for guaranteed minimum bandwidth. Section V evaluates the prototype and Section VI concludes the paper.

II. RELATED WORK
There are several research works in the field of quality of service maintenance and using application layer information both in legacy and software-defined networks. We tend to discuss more practical solutions here.
DiffServ [5] is a simple and scalable mechanism for classification and management of traffic to provide QoS in IP networks. This method can bring low-delay service for latencysensitive traffic while using best-effort delivery for web and file transfer purposes. This class-based, coarse-grained mechanism performs all traffic classification at DiffServ domains borders and conceals the complexity from network core and unlike IntServ [6] and RSVP [7], it does not require reservation and end-to-end signaling, but on the other hand, how each router deals with DSCP bits depends on its configuration and therefore it is hard to predict end-to-end behavior.
Hedera [8], is a dynamic and scalable solution for flow scheduling avoiding ECMP limitations. It has a global view of traffic demands and routing information. Hedera scheduler collects flow information from switches, computes collision free paths and instructs switches to conduct traffic along those paths in a control loop. This periodic polling of traffic information or packet sampling leads to high monitoring overheads which incurs significant switch resources consumption and long event detection times. Mahout [9] suggests to use an end host shim layer which marks the packets of elephant flows. The switches are configured to forward marked packets to the Mahout controller. This resolves switch monitoring overhead issue. MicroTE [10] notes that recent proposals for traffic engineering in ISPs operate at long time-scales and based on measurements [11], data center traffic is naturally bursty and unpredictable at such long time-scales but a significant amount of traffic is predictable at short time-scales. It assigns servers for aggregating traffic statistics and sending summarized traffic matrix to the network controller which takes appropriate routing decisions for both predictable and non-predictable traffic. Yet, using either shim layer or top-of-rack aggregator may not deliver fine-grained control to individual network applications.
In [12], a QoS controller is presented which can create network slices and provision them dynamically to satisfy performance requirements across applications it has assigned their traffic to those slices. Network administrators specify high level slice specifications and controller reserves network resources accordingly. Their main difference to our approach is that we delegate traffic management of our software-defined network to its applications and network administrators specify high level policies and limits for those authorized applications rather than slice specifications and we do this by developing a northbound API rather than extending southbound APIs such as OpenFlow since there is potentially more work to do in this part.
PANE [13] uses the concept of share tree to perform similar tasks, but the lack of resource monitoring for maintaining a network snapshot limits its applicability in environments where not interested users coexist. Authors in [14] focus

Network Snapshot
Policies:

Fig. 1. Framework overview
on SLA policy refinement applied to SDNs while this work focuses on delegating a part of policy enforcement process to applications.

III. PROPOSED FRAMEWORK
As mentioned, participating network applications in traffic management task of a software-defined network could better satisfy their service performance requirements. Here, we present the suggested framework which enables the controller to be aware of how the developer expected the network to behave with the traffic coming from the application.

A. Overview
Using this framework, network application developers use an API to connect to destination with a differentiated socket when they require special treatment from the network. When a function is called from this API, there will be a negotiation phase with the controller which is constantly updating a snapshot of network resources status. The controller would then accept, reject or revise the request and then implements the behavior as rules in case it conforms to policies provided by network administrator and required resources are available. Finally, in case of request acceptance, the controller reserves resources for that flow for some time and then the connection is made as usual. Otherwise it enforces a revision or rejects the request and the connection is made without any special treatment. Requests from applications are put in a queue and processed according to application priority or on a first-come, first-served basis in case of equal priorities. An overview of this framework with its abstract interactions is depicted in Fig. 1.
Four instances of API functions with their corresponding policies and network statistics data structures are shown in the Guarantees minimum bandwidth a flow receives. Lp is the set of links forming path p. C l and U l are capacity and utilization of link l respectively.
Enforces an upper bound for the drop rate a flow might suffer. Ip is the set of network interfaces along path p. D i is the drop rate of interface i.
Enforces an upper bound for the delay a flow might encounter. Delay(p) calculates average latency the flow packets encounter along path p.
Enforces traffic contract between tenants of flow source and destination. C l and U l are capacity and utilization of link l in path p respectively.
figure. Their common arguments are socketType, destIP and destPort. Their specific argument and policy check expression is indicated in Table I. Method simplePaths(G, source, dest) operates over graph G = (V, E) from a topology discovery module feeding network snapshot where V is the set of OpenFlow switches and E is the set of links interconnecting them and returns acyclic paths from source to destination. Note that these functions are only some samples of how QoS enforcement tasks could be plugged into this framework and the generality of framework allows for other forms of functions and parameters. We next describe how the controller becomes aware of application intents for traffic.

B. Application-Controller Interaction
When an application decides to send some traffic under special QoS requirements, it has to notify the controller about those requirements and also receive the response to know whether some special treatment is granted or not. Fig. 2 illustrates steps of this interaction. For this purpose, in API function calls, before a socket to the destination is created, there is a negotiation phase with the controller in which a request packet containing application and destination identifiers, socket type and intended QoS requirements in the body is prepared. Here is what happens next: • A TCP socket to the controller is created with packet DSCP bits set to 110110, a value not in commonly used values in [5] for consistency. We also pre-install a rule after discovery of each switch to match on these specific DSCP bits destined to the controller and forward those packets for further processing (step 1). • When the controller module responsible for this API receives this type of packet, it prepares a response according to what we described earlier, installs a rule in switches on path to the requesting application and forwards the response (step 2). • The requesting application finally acknowledges the response or revises the request based on specified limits announced by the controller and acknowledges revision request (step 3). • The controller installs necessary rules in switches along the path with feasible resources (step 4). • Based on rules set in step 2, the application-side API module which is waiting for resource allocation completion signal from the controller is notified about this (step 5). • Finally the application-side module creates its socket to the destination as before and main data flow starts by the application (step 6).

C. Monitoring Network Resources
Generally, there are two approaches to network monitoring and measurement. In active monitoring, some measurement traffic is injected into the network. For example a probe sent to the network will trigger a response and one could analyze the response to infer properties of the network. In passive monitoring, the traffic that naturally exists in the network is observed.
For OpenFlow networks [15], active monitoring translates to relying on OFPT_MULTIPART_REQUEST and OFPT_MULTIPART_REPLY messages exchanged between switches and the controller. While polling switches for statistics at arbitrarily high rates may provide accurate view of the network, this could incur significant overhead and impose scalability problems in large, heavily loaded networks. On the other hand, passive monitoring in OpenFlow networks means listening to asynchronous messages OFPT_PACKET_IN, OFPT_FLOW_REMOVED and OFPT_PORT_STATUS to infer some properties like link utilization and topology updates. Although passive method has less overhead, but it sacrifices accuracy and also not all QoS metrics can be inferred in this manner.
The monitoring methods plugged into this framework should provide a real-time, accurate snapshot of network so that the framework could properly decide how to respond to applications requests. We utilize adaptive, active statistics collection method similar to the algorithm in [16] which trades between accuracy and overhead and apply it to ports along simple network paths from source to destination. It adapts polling frequency to activity of the ports or amount of traffic that flows contribute to them and calculates link utilization for bandwidth guarantees and traffic shaping and also number of dropped packets and errors occurred. Regarding path delays, it is not feasible to apriori maintain all-pairs delays. This is because total delay is composed of several components such as processing, queueing and transmission delays which are added up together and cannot be independently captured and saved before a probe destined for that specific path is sent by OFPT_PACKET_OUT and OFPT_FLOW_MOD messages and also due to possible large number of simple paths between source and destination and limited size of flow tables, such a solution would not be practical. In this case we suggest to set the rules for navigating the probe towards the egress switch and send it upon the receipt of this kind of request.

IV. PROTOTYPE IMPLEMENTATION
We implemented bandwidth reservation and traffic shaping scenarios as instances of our proposed framework usage over Ryu which is a widely used component-based SDN controller [17]. Ryu is a modular controller. Each module registers itself to listen for specific events (i.e., messages from other modules) and upon receipt of events, puts them in a FIFO queue. It also has a thread for event processing which keeps dequeuing from this receive queue and calling appropriate event handler. We have a module that tracks topology changes based on LLDP packets plus a monitoring module that maintains links utilization and ports status. Another module processes application requests for validity based on network snapshot information and administration policies and evaluates whether the request complies with its criteria in Table I. For example, regarding minimum bandwidth reservation scenario it checks if the requested amount is less than the maximum bandwidth considered for that application and there is a path which can accommodate the flow. Finally a module implements the behavior in data plane.
We used OpenFlow version 1.3 [15] for communication between the control plane and Open vSwitch [18] data plane in Mininet [19] test and prototyping environment. Mininet uses lightweight virtualization meaning a host is a shell process moved into its own network namespace. Mininet hosts have their own virtual Ethernet interface(s) [20]. For generating test traffic we used iPerf [21] and for graph algorithms we used NetworkX package [22]. All scripts were written in Python.
To implement bandwidth reservation and traffic shaping scenarios we used OVSDB [23] management interface as a complementary protocol to OpenFlow for configuration of switches, ports, queues and attachment of QoS policies to queues. We chose hierarchical token bucket queuing discipline and set configurations in JSON format.

V. EVALUATION
We simultaneously evaluated the framework operation under the two implemented scenarios by requesting same upper and lower bandwidth limit through our API functions. A tree topology with 7 switches (s1-s7) and 8 hosts (h1-h8) was created with Mininet. All link capacities were set to 20Mbps. Two UDP flows f1 originating from h2, destined to h7 and f2 originating from h1, destined to h8 were created with iPerf. Flow f1 was configured as a link throttling flow while f2 was intended to receive 10Mbps bandwidth. Test environment is depicted in Fig. 3.
The bandwidth perceived by f2 was measured in two circumstances, with and without calling API functions, to study framework operation and API effectiveness. We configured iPerf to report the bandwidth for each flow in 0.5 second intervals for a 10 second time period. For evaluation purpose, upper and lower bounds bandwidth policies for the application generating f2 were set in compliance with its request. As shown in Fig. 4, the average f2 rate is 9.72Mbps with minimum variance when using our framework compared to the average of 5.2Mbps without using the framework. When the connection is made in traditional way, f1 overwhelms f2 by competing over shared links, but calling function reserveMinBW() before flow f2 starts, makes the controller set some queues along the path to the destination. For a graph G = (V, E), a simple path is found in O(V +E) using a modified DFS algorithm but since the number of simple paths might be as high as O(n!) for a complete graph of degree n, we exploit a deepening approach to check shorter paths first. Furthermore, a multi-commodity flow problem arises if requests are not handled readily. Assuming that link (u, v) has capacity c(u, v), there are k commodities K 1 , K 2 , ..., K k defined by K i = (s i , t i , d i ) where s i and t i are source and sick of commodity i and d i is the bandwidth demand. The flow of commodity i along link (u, v) is f i (u, v) and the problem is finding an assignment of flows which satisfies the following constraints: which is NP-Complete while we are facing a time-critical decision. We thus confine to a first-fit heuristic for flow placement. Table II indicates path computation time for flows generated in a k-ary fat-tree network topology introduced in [24]. In this topology which is an instance of Clos topology, there are k pods, each containing two layers of k/2 switches with k ports. So there are k 2 /2 edge switches that we consider triggering points of OFPT_PACKET_IN messages. There are (k/2) 2 paths between any two hosts on different pods and for evaluation we assume inter-pod traffic, therefore our firstfit heuristic finds paths for bandwidth reservation scenario in O(k 3 ). We simulate a performance test for the controller by sending a OFPT_PACKET_IN from a switch to the controller and waiting for a matching OFPT_FLOW_MOD and counting how many times this happens in a second. In each round, we perform this for each one of k 2 /2 edge switches. We do the test for 15 rounds and average over total number of responses received and path computation times. As evident in Table II, when the number of pods (same as the number of switch ports) increases, the number of switches increases even more and this leads to a larger graph to search and more path computation time. Meanwhile, since a greater portion of controller's time is dedicated to graph computations, each event handling would take more time and less new flows could be serviced in each time period. But even for a network with k = 40 which supports k 3 /4 = 16000 hosts, this time is less than 2 milliseconds. In order to get a better sense of the overhead our graph computations impose on the controller, we also compared the average number of new flows handled by the controller in two situations, when the controller is barely running a packet in handler to respond with a simple OFPT_FLOW_MOD with no hesitation and when an algorithm of O(k 3 ) is run by the handler before responding. Worst-case condition is assumed for API usage.
controller remains performant even in highest traffic demands. Note that we have considered the worst-case scenario for overhead analysis because the number of times a graph algorithm is required to run, depends on the number of accepted requests from applications and we know that normally, in a MapReduce [25] shuffle for example, there is a processing time between requests. So, not all packet in events require graph computations while this is the case with our performance tests. The same reasoning applies to graph search operation where many graph searches terminate sooner than we assumed. Anyway, as mentioned earlier, there is room for improvement of monitoring and controlling algorithms used in this framework when specific knowledge of traffic and communication patterns is present.

VI. CONCLUSION
This paper describes a framework for delegating traffic management tasks such as QoS enforcement to end-host applications in a software-defined environment. This is a move towards more practical application-aware networking enabled by centralized control in SDNs. With this framework, network administrators could specify policies for authorized applications and network application developers could use an API to inform the controller of their specific requirement for a flow. Several monitoring and control mechanisms can be incorporated into the framework. Evaluation of our implemented prototype for minimum bandwidth reservation and traffic shaping functions shows effective operation of this framework allowing integration of further traffic management tasks and network monitoring approaches.