Adaptive quality of service for packet loss reduction using OpenFlow meters

Introduction

Packet-switched networks first came into existence with the development of ARPANET to allow remote access to computers. The development of ARPANET commenced in the 1960s to meet the communication requirements without the need of telephone lines (Roberts, 1986). Since its development, the internet has been an elite amongst the military, universities, and the research community. By the 1990s, the internet began to percolate in the society as a luxurious item, following the continuous research and development from the research community (Naughton, 2016). Many internet-enabled technologies started emerging by the 2000s, such as Web 2.0, mobile connectivity, surveillance, and social media, to name a few. As more internet-enabled technologies came into existence, quality of service (QoS) played a vital role in everyday networks as the need for more bandwidth became a problem.

Quality of service was first defined in 1994 by the International Telecommunication Union (ITU) (International Telecommunication Union (ITU), 2008). It is a mechanism that can provide differential treatment to different flows based on their priority. In general, every traffic passing through the network device is treated on a best effort basis, i.e., all the traffic flows are treated equally and have an equal chance of being dropped should congestion occur at the forwarding device. However, some traffic, such as voice over IP (VoIP) and multiplayer online gaming, are sensitive to delay (Yildirim & Radcliffe, 2010) and require a fixed flow rate. Traditionally, QoS was implemented using two major approaches; integrated services (IntServ) (Braden, Shenkar & Clark, 1994) and differentiated services (DiffServ) (Nichols, Jacobson & Zhang, 1999). IntServ provides fine-grained flow-based control over the system and requires that every router in the path from source to destination implement IntServ. On the other hand, DiffServ is a coarse-grained class-based control system that works on classifying and marking packets to specific classes. Each router in the path is configured to mark and classify traffic to a class. The router can then treat each traffic class differently based on its priority.

With the advent of software defined networking (SDN) (Kreutz et al., 2015) and the OpenFlow (Open Networking Foundation, 2012) protocol, managing QoS became easier (Boucadair & Jacquenet, 2014) as it introduced new methods of configuring and managing QoS rules. SDN is an approach to network management and programmability via a central network controller (Malik et al., 2019). It separates the control and data plane of the forwarding devices and manages all the forwarding decisions centrally on the controller. The controller can query and update information on the devices and has a global view of the network. SDN introduced the concept of meters in OpenFlow 1.3 (Open Networking Foundation, 2012) that allows the controller to rate limit flows based on certain match fields and priority. A meter measures and controls the rate of traffic flowing through the device using a meter table. A meter table contains entries that dictate how the flows are matched to a meter on a per-flow basis. The meter table can be used to calculate the rate of flow using the counters in the meter table, and different actions can be applied to flows when the rate exceeds the set limit.

OpenFlow meter allows flexible bandwidth adjustment and can easily adapt to changing bandwidth requirements. One of the major problems addressed by this feature of OpenFlow meters is bandwidth allocation and distribution (Boley, Jung & Kettimuthu, 2017). Traditional methods of QoS configuration do not allow a flexible way of bandwidth allocation resulting in the link not being utilized to full capacity. It also does not allow other QoS flows to expand into the unused bandwidth of the other flows, causing packet losses for flows that need more bandwidth while the link can accommodate these extra requirements. Gateways and edge devices experience high traffic congestion due to traffic aggregation from the lower tier network devices. The devices can have multiple QoS classes configured, and each class could experience traffic at various rates. When a QoS class is using less than its configured bandwidth or needs more bandwidth, some bandwidth can be borrowed or leased out to another QoS class to ensure maximum link utiliation and throughput. Several works (Boley, Jung & Kettimuthu, 2017; Hong, Kandula & Mahajan, 2013; Jain, Kumar & Mandal, 2013) have attempted to address this issue using OpenFlow meters and hybrid approaches. Therefore, this article also attempts to approach the same problem. However, it looks at the traffic at a switch that experiences the highest congestion level and when it is bursty. It attempts to minimize the packet loss on a per-flow or a per-QoS class basis while also ensuring that high-priority requirements are satisfied by the unused bandwidth of other flows. The article presents an algorithm that implements these constraints and tests the algorithm with different flow rates per class to test the effectiveness of the algorithm.

The authors of this article propose, implement, and test the bandwidth allocation and redistribution algorithm for bursty flows at the highest congestion switch, such as the edge router. It takes advantage of the controller’s ability to query and monitor flow statistics. The algorithm calculates the excess bandwidth required by each QoS class and tries to find an empty QoS class that can satisfy the growing need. If multiple classes need more bandwidth, the algorithm carefully chooses the amount of bandwidth to allocate to each class while keeping a little margin for it grow to avoid packet losses. One of the issues with a resource shared network is fairness (Hwang & Chi, 2003). The algorithm employs a combination of max-min and weighted fairness mechanism to implement fairness in the proposed algorithm. The algorithm also ensures that the QoS class whose bandwidth had been previously borrowed are returned when the classes need more bandwidth, ensuring that the minimum guaranteed bandwidth is given to each QoS class.

The contributions in this article can be summarized as follows:

• Framework: The authors propose a framework that can easily integrate into Ryu controller as a controller application. The framework monitors the flows in real-time and strategically uses the statistics collected to allocate, distribute, and claim that bandwidth at the highest congestion switch. In literature, several works have attempted to make applications that focus on maximizing the overall throughput in different contexts. However, according to the authors' knowledge, no study has focused on maximizing the per-flow throughput while optimally adjusting the per-flow or per-class QoS in bursty network conditions.

• Design and implement three components: a traffic monitoring component, a rate approximation component, and a bandwidth allocation and distribution component. Other works (Boley, Jung & Kettimuthu, 2017) have proposed a similar component; however, this article focuses on optimizing the logic of the components to achieve the article’s objectives.

• Evaluation: The algorithm is evaluated through extensive and multiple simulations using virtual networks in Mininet. The analysis shows that the proposed algorithm achieves higher throughput and incurs less packet loss per-flow or per-QoS class.

The rest of the article is organized as follows: “Related Work” presents the related work on similar applications built using OpenFlow meters to configure and manage QoS or allocate bandwidth. “Problem Statement and Objectives” presents the problem statement as well the objectives. The bandwidth allocation algorithms overview, design, and implementation are discussed in “Bandwidth Allocation and Redistribution Methods”. “Testbed Setup” presents the testbed setup on which the entire experiment was setup. In “Methodology”, we discuss the methodology that was used to gather, analyze and test our algorithms. The algorithm is evaluated in “Results and Discussion”, showing the effectiveness of the algorithm, its loss per class and bandwidth distribution. Finally, the article concludes in “Conclusion”, discussing the contributions and recommendations for future work.

Related work

SDN has addressed many network programmability problems (Hu et al., 2013; Zhou, Zhu & Xiao, 2015; Long et al., 2013; Chou et al., 2014; Yang & Yeung, 2020; Ze & Yeung, 2017; Kaur, Kaur & Gupta, 2016; Kiadehi, Rahmani & Molahosseini, 2021) and has provided a flexible way of managing networks. Some of these include load balancing applications such as the work in Hwang & Chi (2003), which implements load balancing in wide-area OpenFlow networks, controller load balancing (Hu et al., 2013) to reduce overhead message exchange traffic, path switching to dynamically balance the traffic during data transmission in data centers (Zhou, Zhu & Xiao, 2015), distributing large dataset to clients using genetic algorithm (Long et al., 2013), and load balancers which converts the data plane into load balancers by employing certain strategies in the POX controller (Ze & Yeung, 2017). Flow monitoring was another component that reaped the benefits of SDN. The work in Yang & Yeung (2020) proposed a flow monitoring scheme that allows an SDN controller to periodically collect statistics of flows in the network. Another solution presented a method of minimizing network bandwidth (Chou et al., 2014) for flow monitoring by polling some statistics to prevent overwhelming the OpenFlow switches. SDN has not only leveraged the possibilities in organizational networks but also in IoT by providing fault tolerant solutions (Kiadehi, Rahmani & Molahosseini, 2021).

Along with the features provided by traditional networks, SDN provides a feature rich Controller-Data Plane Interface (C-DPI) that can tune the forwarding rules at a more granular level. QoS is one of the domains that have become feature rich with the introduction of SDN. QoS has benefited in the following areas: multimedia flows routing mechanisms, inter-domain routing mechanisms, resource reservation mechanisms, queue management and scheduling mechanisms, Quality of Experience (QoE)-aware mechanisms, network monitoring mechanisms, and other QoS-centric mechanisms such as virtualization-based QoS provisioning and QoS policy management (Karakus & Durresi, 2017). This section will first outline some of these works carried out in QoS domain using SDN, then look at some work related to this article and present a brief comparison with the proposed algorithm.

The work in Akella & Xiong (2014) proposes an approach to ensure end-to-end QoS guarantees to multiple users on the cloud platform. Cloud computing allows users to access and share remote files without owning physical devices. The work presents an expression that selects a path to carry the traffic from the cloud provider to the user. In Tomovic, Prasad & Radusinovic (2014), the authors present an SDN framework that programs the network devices to provide the relevant QoS requirements for multimedia applications. It provides bandwidth guarantees for priority flows and provides a mechanism to monitor the network state and resource levels. The authors in Amiri, Osman & Shirmohammadi (2018) propose a bandwidth allocation mechanism that intends to prioritize gaming flows with the data center to ensure that the delay sensitive game applications are not affected. It uses machine learning to classify different traffic to improve the QoS needs of the data center network. The work in Breiki, Zhou & Luo (2020) introduces a solution to enhance the QoS performance for streaming mission-critical video data in an OpenFlow network. The solution, called the Meter Band Rate Evaluator (MBE), uses a description language to optimize the QoS capabilities in the OpenFlow network. While these works provide insight into specific applications, some solutions look at the traffic as a whole for providing QoS solutions. Table 1 summarizes these work and compares their similarities and differences with the proposed approach.

These solutions provide great insight into the problems they solve. In contrast, this article looks at how the bandwidth can be allocated to each flow at a device and claimed back when the need for more bandwidth arises while also ensuring there’s least packet loss for each QoS class.

In summary, OpenFlow has been introduced to various applications including load balancers for networks as well as SDN controllers. Flow monitoring, bandwidth optimization, end-to-end QoS services, and network device programming to meet various QoS needs have been one of the major focus for OpenFlow. Consumer applications have also benefited from OpenFlow. This includes online gaming and multimedia streaming. While these have been some of the end products of OpenFlow, there have been a lot of research on the underlying complexity that powers the end applications. Various studies have explored the flow statistics to improve QoS with different objectives. The work most similar to this article is AQoS presented in Boley, Jung & Kettimuthu (2017). The authors of AQoS present an algorithm that allows other flows to expand and use the bandwidth that are not currently being used by other high-priority traffic while also ensuring that the initially assigned bandwidth is available for use when needed by those high-priority flows. If there are flows that are not using their allocated bandwidth, the remaining bandwidth is allocated to some other flow that can use it. The borrowed bandwidth is returned to the original flow if the need for more bandwidth arises. This article also allows flows to expand and use other flows’ bandwidth allocation; however, it differs in two ways: it does not fully exhaust the underperforming QoS flows and leaves some room for the borrowed flows to grow incase urgent need for more bandwidth arises. The work proposed in Boley, Jung & Kettimuthu (2017) aims to achieve a similar objective to this article and has proven to perform better than the existing QoS configuration methods (IntServ and DiffServ). Therefore, the proposed algorithms will be compared for performance and throughputs with AQoS.

Problem statement and objectives

The proposed algorithm can be applied to a single switch and an end-to-end path in a network from source to destination; however, it only targets the device with the highest traffic congestion, such as the edge router. The edge router in the network is loaded with the task to meet the service level agreement (SLA) requirements with the service provider and might need to drop packets, or rate limit should congestion occur at the egress port.

It is assumed that the switches are OpenFlow compatible and connected to an OpenFlow controller. Traffic flowing through the switch is first categorized into different classes of traffic based on their priority and QoS levels using the flow table level matching. To simulate the traffic at the switch, every flow entering the switch is categorized into N classes of traffic, with each class sharing a portion of the total egress link bandwidth. Each of the N classes gets $A_1,A_2,\dots A_{N}kbps$ of pre-assigned bandwidth, respectively.

The authors address the problem of bandwidth allocation, redistribution and sharing by allowing each QoS flow to expand into other flows when they are not in use while also incurring least packet loss. Other studies have done similar work; however, this article looks at the same problem when the traffic is bursty and minimises the packet loss. In this case, traffic rate approximation and allocation can become challenging.

The algorithm can be defined to best handle the distribution and reallocation of bandwidth if it meets the following conditions:

The allocated rate remains the same when the individual classes’ ingress rate is below the configured rate as well as the cumulative rate is less than the total allocated rates. This obeys and ensures that the min-max fairness is implemented. The algorithm ensures that the minimum set bandwidth is given to each flow as initially defined by the SLA. Mathematically,

(1) $R_{q_i}=A_{q_i}when{C}_{q_i}<A_{q_i}\wedge \sum _{q_i=1}^{q_N}{C}_{q_i}<\sum _{q_i=1}^{q_N}{A}_{q_i},\mathrm{\forall }{q}_i\in \left\{q_1,...,q_N\right\}$where; $R_{q_i}$ is the new rate of the i^th QoS, $A_{q_i}$ is the pre-configured rate of the i^th QoS, and $C_{q_i}$ is the current rate of the i^th QoS,

The allocation resets to the pre-configured rate when the individual classes ingress rate exceeds the configured rate as well as the cumulative rate is more than the total allocated rates. This again conforms to the min-max fairness policy. If all the flows are exceeding their set rates, and packet loss is inevitable due to the link being overutilized, the algorithm resets their rates to the initial SLA to guarantee that the minimum required bandwidth is given to each flow. Mathematically,

(2) $R_{q_i}=A_{q_i}when{C}_{q_i}>A_{q_i}\wedge \sum _{q_i=1}^{q_N}{C}_{q_i}>\sum _{q_i=1}^{q_N}{A}_{q_i},\mathrm{\forall }{q}_i\in \left\{q_1,...,q_N\right\}$where; $R_{q_i}$ is the new rate of the i^th QoS, $A_{q_i}$ is the pre-configured rate of the i^th QoS, and $C_{q_i}$ is the current rate of the i^th QoS,

If one or more classes ingress rate is exceeding the configured rate and other class is underperforming, the excess bandwidth requirement is satisfied by the underperforming classes. This employs the weighted fairness mechanism to allocate flows to those in need. The excess traffic is divided equally onto the free space or divided based on the priority of the classes. Mathematically,

(3) $\begin{array}{l}{R}_{q_i}=A_{q_i}+x.A_{q_j},i\ne j,x\in \left(0,1\right)when{C}_{q_i}>A_{q_i},\\ C_{q_j}<A_{q_j}{\exists }^{<q_N}{q}_i,\forall q_i,q_j\in \left\{q_1,\mathrm{...},q_N\right\}\end{array}$where; $R_{q_i}$ is the new rate of the i^th QoS, $A_{q_i}$ is the pre-configured rate of the i^th QoS, $C_{q_i}$ is the current rate of the i^th QoS, and x is the priority or chosen value of the fraction of other QoS’ bandwidth allocation.

The packet loss incurred by each classes’ meter has to be minimized.

(4) $loss=min\left(L_{q_i}\right),\mathrm{\forall }{q}_i\in \left\{q_1,...,q_N\right\}$where; $L_{q_i}$ is the packet loss incurred by the i^th QoS.

Therefore, the main objectives of the article are:

• Design and implement an algorithm that meets the above conditions to allocate, redistribute, and claim the bandwidth of different QoS classes when a class’s rate exceeds its configured rate and allows it to use other class’ free bandwidth.

• Design and implement an algorithm that incurs the least packet loss (maximum throughput) when allocating and redistributing bandwidth.

• Apply the algorithm on an OpenFlow network to determine its effectiveness.

Bandwidth allocation and redistribution methods

Testbed setup

The virtual network setup used in the experiment was hosted on a machine with the specifications listed in Table 3.

The virtualized SDN network in Fig. 1 was created in a standalone Mininet (2022) with the specifications listed in Table 4.

Ryu SDN controller was installed in Ubuntu and was connected to the Mininet as a remote controller.

The virtual network consisted of four PCs on each side of the OpenFlow switches. The PCs on switch 4 acted as servers and the PCs on switch 1 connected to the servers to query and generate flows. Each flow path consisted of a client and server PCs between which data was generated using iPerf (IPerf, 2023). All the flows generated between the client and server passed through switches 2 and 3. These switches acted as the congestion point in the network and the controller queried these switches for testing the proposed algorithms.

Methodology

We start the experiment with the objective of designing an algorithm for managing the bandwidth allocation between different QoS classes while ensuring the least packet loss per class. Thus, the experiment consisted of an OpenFlow network simulator, iPerf for generating data, a database to store the flow statistics, a Ryu controller, and OpenFlow switches with metering and flow stats capabilities.

A custom python script was written to create the topology in Fig. 1, and four flows with different rates were created between the source and destination devices. The flows were made bursty with additional logic implemented on top of the iPerf generator to simulate the bursty nature of the traffic. A meter is attached to each flow to classify them into different QoS classes and control each class’s rate.

Iperf was used to set up and generate traffic between each pair of source and destination hosts in Mininet. Four flows were set up and classified into four QoS classes, with one class for the best effort traffic. The flows were generated with different rates such that the link utilization ranges from underutilization to full utilization to overutilization. Five different traffic rates were configured for each class to test different traffic patterns.

The proposed algorithm was implemented as a controller application and run against different flows to test its effectiveness. The predictive method of rate approximation was used to approximate the flow rate of the flows for different values of capture duration. The flows were generated with different rates ranging from empty link to full saturation to exceeding capacity. For each of the rates, the experiment was run 30 times where each trial lasted for 300 s with 20 s pause for the controller to sense this pause and update the flow parameters.

For each trial of the experiment, the controller collected the flow statistics from both switch 1 and switch 2 and calculated the approximate flow rate per QoS class. The proposed algorithm then calculated the bandwidth to allocate to each QoS class and configured the switch with the new rate. The data collected from both switches were used to plot the losses for each QoS class and the overall packet loss.

Results and discussion

The same data that powered the proposed algorithm’s core logic was logged into the database for analysis. The proposed algorithm was tested against the Adaptive QoS (AQoS) algorithm in Boley, Jung & Kettimuthu (2017). Simulation results show that the proposed algorithm (AFQoS) yields a higher throughput with less packet loss per QoS class. The traffic rates for QoS 1, QoS 2, QoS 3, and QoS 4 were initialized to 8,000, 6,000, 4,000, and 2,000 kbps, respectively. The total capacity for the link was 20,000 kbps and QoS 4 was set as the best effort class.

Bandwidth allocation

The bar graphs in Figs. 2–9 show how the bandwidth allocation was done using both the AQoS and AFQoS. The allocation shows that the proposed algorithm allocates the bandwidth in an optimal way that not only incurs the least packet loss but also leaves some room for the flows to grow if there is a demand for more traffic for the current QoS class. The graphs show the instantaneous bandwidth allocation at a random time to show how the algorithm did the allocation in reaction to the current rate. With QoS in place, there could be different cases where different rate calculations may be applied. At any time during the flow session, an OpenFlow switch could either have few flows passing through, in which case, the link will be underutilized. The second case is when the link is operating at its peak capacity, in which case, the link is fully utilized. The last case is when different classes are competing for bandwidth and are incurring some packet losses. This is when the link is overutlized and there is contention for bandwidth. These three cases need different attention as to how allocations will be done.

Throughput/packet loss for AQoS and AFQoS

Figures 10–13 shows the throughput achieved by both algorithms for different allocation and traffic demands. The AFQoS algorithm always leaves some unused bandwidth for the current QoS class to grow into if there is a need for more bandwidth. The AQoS algorithm, however, caps the bandwidth to the class’s current rate if it has some bandwidth to lease out. These major differences in both algorithms cause a significant packet loss difference throughout the flow. The graphs show the throughput for four different traffic conditions. The total link capacity was 20,000 kbps.

Conclusion

This article proposed an algorithm for solving the bandwidth allocation problem using the flow statistics from the OpenFlow switches. The algorithm queries the switch at certain intervals to get the current flow details to calculate the proportion of bandwidth to allocate to each QoS class. In literature, various approaches have been proposed. However, this article focuses on a specific subset of a problem. The algorithm is used on specific switches that meet certain network conditions.

The proposed algorithm was compared with the AQoS algorithm for performance and efficiency. The algorithm was tested against different traffic scenarios, such as when the link is underutilized, at full capacity, and overutilized. It was noted that the proposed algorithm not only achieves a higher overall throughput but also causes the least packet loss per QoS class.

The algorithm was developed as a controller application and can easily be integrated into any OpenFlow network requiring QoS provisioning. Although the algorithm achieves a near maximum throughput for various traffic scenarios, it was noted that when the best effort class needs more bandwidth, the algorithm cannot optimally allocate the bandwidth despite the link not running at full capacity. Thus, in future work, the authors intend to rectify and improve the allocation efficiency of the algorithm. The research was conducted in Mininet simulation to mimic the real network behavior however, it has not been tested on a real network with SDN supported routers. In future work, the authors also intend to test the effectiveness of the algorithm on real devices.