QoS-aware Energy-Efficient Algorithms for Ethernet Link Aggregates in Software-Defined Networks

TL;DR

This paper presents energy-efficient algorithms for Ethernet link aggregation in SDN, balancing energy savings with real-time traffic requirements through innovative ONOS application solutions.

Contribution

It introduces novel algorithms and an ONOS application that optimize energy use in Ethernet link aggregates while ensuring quality of service for time-sensitive traffic.

Findings

Energy-efficient algorithms reduce overall power consumption.

The solutions maintain low latency for real-time traffic.

Energy savings are effective when real-time traffic share is moderate.

Abstract

In this paper we discuss the implementation of an ONOS application that leverages Energy-Efficient Ethernet links between a pair of switches and shares incoming traffic among the link in the way that minimizes overall energy usage. As the straightforward solution can result in excessive traffic delay, we provide two alternative solutions to meet the demands of real time traffic arriving to the link aggregate. Experimental results show that our final application can keep low energy usage while meeting the demands of time-sensitive traffic, as long as the latter does not represent an excessive share of traffic demand.

Full text

©2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. DOI: 10.23919/SOFTCOM.2018.8555789

I Introduction

Software-defined networks have opened the opportunity to devise innovative solutions for switching equipment without further assistance from hardware vendors. This opportunity has coincided with ever increasing environmental concerns that has naturally led to many green networking proposals.

A great deal of attention has been put in reducing the energy demands of wired infrastructure, and, in particular wired networks. The IEEE 802.3az [1] amendment, informally known as Energy Efficient Ethernet (EEE) [2], that defines a low power mode for idling interfaces is one of the first successes in reducing energy usage. However, many proposals [3, 4, 5], many related to forwarding behavior, have remained unimplemented due to lack of support from networking equipment.

We have shown in our previous work [6] that SDN, and ONOS [7] in particular, can be used to implement some of these proposals. In particular, we presented an ONOS application capable of minimizing the energy usage of an Ethernet aggregate made up of EEE links adapting the algorithm in [5]. However, [6] ignored the effects on traffic delay.

In this paper, we provide an updated proposal than can take into account the needs of traffic with time constraints. We provide two alternative methods to meet the QoS demands of traffic, depending on the characteristics of the underlying switching equipment. Finally, we present a practical evaluation of the effects on both energy usage, additional delay of the original proposal and of the new ones.

II Problem Statement

When traffic is transmitted in an Ethernet aggregate composed of EEE links, the actual share of traffic among the links has strong effects on the global energy usage. The optimal way to distribute the traffic was the focus of [5], where we presented a water-filling algorithm that minimizes energy usage. However, that algorithm operates at the packet level, and needs specific hardware support to be implemented. To overcome this problem, we have developed a flow level adaptation to be implemented in an SDN controller [6]. The application periodically queries the flow rules installed in the switches, determines which flows are assigned to a bundle, estimates the transmission rate that each flow will forward in the next interval based on the bytes it transmitted previously and reallocates the flows to the ports of the bundle so as to reduce energy consumption. We proposed three different allocation algorithms: greedy, bounded-greedy and conservative. All of them obtain substantial energy savings, close to the optimum, but only the conservative one achieves an acceptable packet loss rate. In a nutshell, the conservative algorithm calculates the minimum number of active links needed for the current traffic load to then assign flows to each link in a way that aims at equalizing the load among them. The rest of the links are kept idle. For specific details see [6]. However, this modus operandi ignores the latency requirements of the flows, with some preliminary results suggesting that latency can get too high.

In the next Section we explain the operation of the energy saving algorithms for EEE link aggregates in order to be able to handle traffic flows with QoS requirements of low latency, but also maintaining considerable energy savings.

III QoS-aware Energy-Efficient Algorithms

In this Section we will propose two modifications to the conservative algorithm for taking into account the needs of time sensitive traffic while keeping the energy consumption of the aggregate to a minimum. The specific mechanism used to identify low latency flows is out of scope for this work, as the method actually employed is irrelevant for the algorithm. In any case, we assume that these low latency flows are tagged with a well-known DSCP codepoint carried in the IP header.

III-A Spare Port Algorithm

The spare port algorithm leverages on the fact that, most of the time, the conservative algorithm leaves some ports completely unused. In particular, it trades a small energy usage in unused ports for premium service to low latency flows. The resulting algorithm is a two-step process.

In the first step, the unmodified conservative algorithm is employed, but taking into consideration only the flows without timing requirements. 2. 2.

In the second pass, the low latency flows are allocated to the emptiest port in the bundle, which will be ideally empty. For this to work, we assume that low latency traffic represents a small share of the total load. This algorithm relies on the idea that the basic goal of the proposed energy-efficient algorithms is to concentrate the traffic on as few ports as possible. This way, after the first stage of the algorithm, normal traffic will be concentrated on the first ports of the bundled, leaving the last ports unused, which can then be devoted to low-latency traffic.

It is important to bear in mind the limitations of this algorithm:

When there is a high traffic load in the bundle all ports of the aggregate are allocated in the first step, and so the low latency traffic will not find an unused port. As a result, low-latency traffic will have to compete with normal traffic in equal terms and the delay of the low-priority traffic will also depend on the normal traffic scheduled to that port.

Allocating low-latency flows to empty ports has an impact in the energy consumption. Since the energy profile of an EEE link is super linear, see Fig. 1, the energy savings can be greatly affected if the amount of delay sensitive traffic is significant.

A nice characteristic of this algorithm is that it does not penalize the delay suffered by normal traffic.

III-B Two Queues Algorithm

As we have pointed out, the previous solution can significantly increase the overall energy consumption. What is more, the energy-minimizing solution will not be able to meet the latency targets of high priority packets when traffic load is too high. Some SDN capable switches have the ability to attach multiple queues a physical port, and treat these queues with different priorities. This is, in fact, the natural way to guarantee QoS requirements in SDN devices conforming to the OpenFlow specification [9]. However, this capability is optional, even though support is not hard to come by, for instance, OpenvSwitch [10], probably the most widely used OpenFlow-enabled switch, supports this feature.

The Two Queues Algorithm performs the same flow allocations than the conservative one, but without taking into account the latency requirements of the flows. Then, for each port, traffic flows are further reassigned to the appropriate queue, i.e., low-latency flows are assigned to the high priority queue, whereas normal flows are associated with the low priority queue of each port. This algorithm should achieve the same energy consumption as the original algorithm, where no QoS special treatment was considered. Instead of increasing the energy consumption, this algorithm increases the average delay of the normal packets, as the fraction of low-latency traffic increases. Actually, the average delay of all the packets will be the same as when using the original energy-efficient algorithm. In fact, from the point of view of the packets transmitted by a port, the two-queues algorithm only performs a reordering of the packets transmitted by each port compared to the original one, so that priority packets are forwarded before normal packets in each port. Thereby, when a port finishes the transmission of a packet it will choose the next packet to be transmitted from the low-priority queue if and only if the high-priority queue is empty. As a result, a high-priority packet will only have to wait for the transmission of other high-priority packets that had arrived to the port before him and, at most, one normal packet (i.e., if a normal packet was already being transmitted by the time the high priority packet arrived at the port).

This algorithm solves the drawbacks caused by using the spare ports: On the one hand, the latency of the high-priority traffic is not sensitive to the variations in the load of the normal traffic, i.e., the high-priority traffic is still forwarded with low delay even when there is a high load of normal traffic. On the other hand, as explained before, this algorithm does not increase the energy consumption, since it maintains the maximum number of ports fully idle, exactly in the same way as the energy-efficient conservative algorithm described in [6].

Its main drawback is the possibility that a switch might not support defining multiple queues for each port. In addition, the increase in the delay of normal traffic would be more noticeable as the amount of low-latency traffic grows. Nevertheless, since the average delay of all the packets is unmodified, the maximum delay of the normal packets is bounded.

IV Experimental Results

We have designed and carried out a set of experiments to compare the performance of the two proposed algorithms. This comparison will be done by simulation and later validated with a special-purpose ONOS application. For completeness, we will first study the QoS performance of the three algorithms in [6] which serve as a baseline for our two new proposals.

The scenario that we set up for the simulations is made up of two SDN-enabled switches connected by a bundle of five 10 GBASE-T IEEE 802.3az interfaces. We have fed this bundle using anonymized real traffic traces retrieved from the publicly available CAIDA dataset [11]. The trace we are going to use throughout this paper has been captured on a $10\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ link and has an average rate about $3.25\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$. In order to obtain a set of traces with different rates to conduct our analysis, we have reduced the inter-arrival times by a constant factor creating traces with the following rates: $6.5\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$, $13\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$, $19.5\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$, $26\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ and $32.5\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$.

In order to compute the delay of the packets, we have extended the Java-based simulator used in [6] that is available for download at [12], performing the calculation of the average delay of the packets transmitted through the bundle. The calculation of the packet delay takes into account both the queue waiting time, the transmission time and the transitions times to enter ($\mathrm{T}_{\mathrm{S}}$) and exit ($\mathrm{T}_{\mathrm{W}}$) the low power mode (LPI) of the individual EEE ports. The times to enter LPI and wake up an interface are set to $2.28\text{\,}\mathrm{\SIUnitSymbolMicro s}\text{/}$ and $4.48\text{\,}\mathrm{\SIUnitSymbolMicro s}\text{/}$, respectively, as defined in the standard [1].

The simulator has been configured with the following parameters, which provide acceptable results in terms of energy consumption and packet losses, as shown in [6]: flow sampling period of $500\text{\,}\mathrm{ms}\text{/}$ and buffer size limited to $10\,000\text{\,}\mathrm{p}\mathrm{a}\mathrm{c}\mathrm{k}\mathrm{e}\mathrm{t}\mathrm{s}$.

IV-A Baseline Results

We will first simulate the execution of the three energy-efficient algorithms proposed in [6] and the non-energy-aware equitable algorithm, that simply spreads traffic evenly among the links of the aggregate, using as input the set of traces reported above. The results

are shown in Fig. 2. We observe that the delay attained by the greedy algorithm is the highest, followed by the bounded-greedy one. The conservative algorithm shows a lower delay, but it is high in comparison to the baseline equitable algorithm. However, even the delay achieved by the conservative algorithm could be unacceptable for critical applications, especially when the traffic load is high, reaching delays in the order of hundreds of microseconds.

Notice the particular case of the $6.5\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ trace, where the three energy-efficient algorithms behave identically, concentrating the traffic on just one port. Also, due to the operation of the conservative algorithm, the delay of the packets in the $26\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ trace is higher than in the $32.5\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ one. This is due to the fact that the algorithm is using, in average, three ports for the former and four ports for the latter. A trade-off between energy consumption and packet delay is clearly observed here, since using four ports in the $26\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ trace would reduce the delay but at the cost of increased energy consumption.

IV-B QoS-Aware Energy-Efficient Algorithms

The next experiment consist in conducting simulations to evaluate the QoS-aware energy-efficient algorithms that we have proposed in this paper, in terms of energy consumption, delay of the normal packets and delay of the high-priority packets. First, we extended the simulator with capabilities to support the differentiation of high-priority and normal traffic. Next, we modified the simulator to implement two queues in each port with different priorities, using the low-priority queue by default for the all the traffic. Finally, we implemented the proposed algorithms in our simulator, using only the low-priority queue for the spare-port algorithm and using the high-priority queue for high-priority traffic in the two-queues algorithm as explained above. Note that, although the QoS-aware modifications are compatible with any of the energy-efficient solutions presented in [6], we will only use the conservative algorithm, since we have shown that it outperforms the greedy ones in packet delay and losses while obtaining very similar energy consumption.

To simulate the low latency traffic, we have generated synthetic traces. These traces consist of packets of relatively small size (less than 200 bytes) with constant inter-arrival times, as a crude approximation to real-time multimedia traffic. To obtain different loads of real time traffic, the inter-arrival times of the different traces is altered. The actual traces fed to the simulator are the results of merging these synthetic low-latency traces with the aforementioned CAIDA traces. Obviously, prior to the final merge, the low latency traffic has been marked with a specific DSCP codepoint to be able to distinguish it. Using this joint traces, we will evaluate our QoS-aware energy-efficient algorithms, comparing their packet delays and energy consumption with the baseline conservative algorithm.

Figure 3 shows the average packet delay of the low-latency traffic using the QoS-aware algorithms along with the average delay of these packets using the conservative algorithm, for the $32.5\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ normal traffic trace, using low-latency traces with different rates.111The results for the other traces with different rates previously described show analogous results, and have omitted for the sake of brevity. The conservative algorithm presents clearly the worst results, yielding a delay of more than $100\text{\,}\mathrm{\SIUnitSymbolMicro s}\text{/}$, showing a strong dependence on the rest of the traffic, since these packets are treated as normal traffic by the conservative algorithm. The other QoS-aware algorithms attain a significant lower delay for the different low-latency traffic traces evaluated. The values obtained are two orders of magnitude lower than the baseline conservative algorithm, with the spare port algorithm getting around $5\text{\,}\mathrm{\SIUnitSymbolMicro s}\text{/}$ and the two-queues algorithm showing the best results, always below $2\text{\,}\mathrm{\SIUnitSymbolMicro s}\text{/}$. The main contribution to the delay of the spare-port algorithm is the time involved in waking up the interface, since the port used for low-latency traffic is most of the time inactive. On the other hand, the two-queues algorithm uses a port which is also being used for normal traffic and thus, the port will be active many times a low-latency packet arrives. As a result, it will only have to wait for the current normal packet transmission to end, which takes, in general, less time than waking up an idle interface ($1.2\text{\,}\mathrm{\SIUnitSymbolMicro s}\text{/}$ vs $4.48\text{\,}\mathrm{\SIUnitSymbolMicro s}\text{/}$ for a $1500\text{\,}\mathrm{b}\mathrm{y}\mathrm{t}\mathrm{e}\mathrm{s}$ long frame).

Figure 4 shows the average packet delay of the normal traffic using the QoS-aware algorithms along with the average delay of these packets using the conservative algorithm, for the $32.5\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ normal traffic trace, using low-latency traces with different rates. As we can see, for low rates of high-priority traffic, both algorithms obtain the same delay for the normal packets as the baseline, since the impact of the low-latency traffic is negligible in the total traffic. However, for low-latency rates higher than $100\text{\,}\mathrm{Mbit}\text{/}\mathrm{s}$ we appreciate an increase in the delay of baseline conservative algorithm, which is even higher for the two-queues algorithm. On the contrary, the spare-port algorithm maintains exactly the same value of delay for all the different rates. These results match with our previous expectations validating the hypothesis presented when describing the algorithms.

Figure 5 shows the average value of the normalized energy consumption using the QoS-aware algorithms and also the conservative algorithm, for the $32.5\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ normal traffic trace, using low-latency traces with different rates. As well as in the case of the delay of the normal packets, the energy consumption is the same for the three algorithms for low rates of low-latency traffic. For values higher than $10\text{\,}\mathrm{Mbit}\text{/}\mathrm{s}$ we observe how the energy consumption raises very quickly for the spare-port algorithm, being almost a $100\text{\,}\mathrm{\char 37\relax}\text{/}$ for rates from $100\text{\,}\mathrm{Mbit}\text{/}\mathrm{s}$. The two-queues algorithm achieves exactly the same consumption as the baseline conservative algorithm. Again, these results in terms of energy consumption validate our previous assumptions, confirming that the spare-port algorithm can lead to an increase in the energy consumption whereas the two-queues algorithm does not increase the consumption at all.

Overall, these results prove that our algorithms are capable of achieving a low delay for traffic with stringent QoS requirements without increasing the energy consumption achieved by our conservative algorithm.

IV-C ONOS Implementation

In order to further validate our algorithms, we have implemented these algorithms as a real ONOS application. The network has been emulated with Mininet [13] running in the same computer as an ONOS instance. Then, we tested the implementation validating the energy-efficient algorithms proposed in our previous work and also verifying that the QoS-aware energy-efficient solutions properly handle flows with low-latency QoS requirements.

We have set up a topology composed of three switches (numbered from 1 to 3) and eight hosts (numbered from 1 to 8). Hosts 1 to 4 are connected to switch 1 whereas hosts 5 to 8 are connected to switch 3. We will refer to these two switches as edge switches. On the other hand, switch 2, namely the inner switch, is connected to both edge switches, through 4-link bundles of $1\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ interfaces. This way, traffic generated from hosts 1 to 4 destined to hosts 5 to 8, have to go across the two bundles. Fig. 6 shows a snapshot of the ONOS web interface with this topology.

In this scenario, we first validate that the energy-efficient algorithms are capable of concentrating the traffic on few ports dynamically adapting the allocation according to the variations in the demand. We performed this experiment using traffic generated with iperf3 [14] and also a real trace of $3.25\text{\,}\mathrm{Gbit}\text{/}\mathrm{s}$ retrieved from the CAIDA dataset [11]. The empirical results verify the correct operation of our energy-efficient algorithms, validating the expected results of the simulations.

Then we implemented the two QoS-aware energy-efficient algorithms proposed in this paper. We evaluated the proper operation of both algorithms with a simple demonstration scenario: three big flows without special QoS requirements are generated from hosts 1 to 3, destined to hosts 5 to 7, respectively. These big flows have been generated with the iperf3 tool, creating iperf3 servers in the hosts of one side and clients iperf3 on the other side. Two of clients will be transmitting UDP traffic to the servers at rate of $700\text{\,}\mathrm{Mbit}\text{/}\mathrm{s}$ whereas the other one will be transmitting at $600\text{\,}\mathrm{Mbit}\text{/}\mathrm{s}$. This way, the basic behavior of our energy-efficient conservative algorithm will allocate these three flows in the first three ports of the two bundles that the packets have to traverse on their path from the client to the server. In addition, we added two lightweight flows, both transmitted from host 4 to host 8. These two flows will be generated executing a ping, using the DSCP field to identify one of these flows as having low latency QoS requirements and the other one as normal traffic. The usage of the ping tool allows us to easily measure the round-trip time (RTT) of the packets.

The results for the round trip time of the packets of these lightweight flows are shown in Fig. 7. The first we can see is that packets without QoS requirements experience a noticeable delay in this scenario. The reason is because this flow, whose rate is almost negligible, is allocated to the same port and same queue as the $600\text{\,}\mathrm{Mbit}\text{/}\mathrm{s}$ big flow. The main contribution to this round-trip time will be the waiting time in the queue of the port, which will be noticeable due to the big flow also assigned to it. At the same time, note how both QoS-aware algorithms are largely able to reduce the RTT of low-latency traffic, in this case, three orders of magnitude.

V Conclusions

In this work we have firstly analyzed the QoS characteristics of the algorithms presented in [6]. As expected, the delay added to the traffic in order to minimize energy usage in the aggregated Ethernet link can grow too high for applications with stringent latency requirements.

We have provided two alternative refinements that are able to offer expedited service to low latency traffic while keeping the energy usage at its lowest. One manages to obtain optimal energy savings results, albeit at the cost of a slight increase of delay for normal traffic. The other one, on the contrary, trades a slight increase of energy consumption for keeping unaffected the QoS of non real time traffic.

Acknowledgments

This work was supported by the “Ministerio de Economía, Industria y Competitividad” through the project TEC2017-85587-R of the “Programa Estatal de Investigación, Desarrollo e Innovación Orientada a los Retos de la Sociedad” (partly financed with FEDER funds).