Comparison of Flow Forwarding Between Software-Defined and Legacy Networks Based on Fixed Routing and QoS Conditions

The chosen scenario is generally used to present routing protocols problems over traditional networks and to identify solutions defined through Traffic Engineering (TE) and Quality of Service (QoS). Those solutions will include routing protocols, QoS policies and load balancing mechanisms. The topology of the scenario is shown below in Figure 1.

The network traffic flows from VM1 and VM2 (Virtual Machine 1 and 2) to the through PE1 (Border Router) to enter to AREA 0 (shaded in yellow) according to the queuing system. A brief description of the types of routing queues and, particularly the one chosen for the development of this work, is detailed as follows.

11.png

Figure 1. Analysis scenario

2.1 Queue types

The queuing system will be defined with one or more flows that may or may not enter a congested network. Queuing mechanisms are determinant regarding the performance of data networks. The different existing queuing mechanisms will have different bandwidths, delays, jitters and packet losses depending on the network congestion. In case of QoS, the following methods are used:

FIFO Queuing (First In First Out) [7]: There are no priorities or classification of types of traffic. The first packet to enter this queuing system is the first to leave, as shown in Figure 2.

2.png

Source: Cisco Systems

Figure 2. FIFO Queuing

WFQ (Weighted Fair Queuing): This queuing method generates a different queue with its priority for each flow type. When a queue is empty of packets, the system continues with the next priority queue as shown in Figure 3.

3.png

Source: Cisco Systems

Figure 3. WFQ mechanism

CBWFQ (Class Based Weighted Fair Queuing): Because WFQ has scaling limitations when the traffic per link increases, CBWFQ incorporates the use of a weighted Round Robin algorithm where it establishes different attention times for each queue depending on the guaranteed bandwidth for each of them, as shown in Figure 4.

4.png

Source: Cisco Systems

Figure 4. CBWFQ mechanism

LLQ (Low Latency Queueing): It is an extension of the CBWFQ mechanism that adds an additional PQ queue with the highest priority over the others as shows in Figure 5. LLQ queuing (CBWFQ + PQ) is currently the most recommended method for VoIP, IP telephony and video conferencing.

5.png

Source: Cisco Systems

Figure 5. LLQ mechanism

This work uses the CBWFQ (Figure 4) and LLQ (Figure 5) queues. Our experiment will prioritize the UDP flow taking as a premise to obtain the minimum loss of packets. For this reason, the queue model considered was the one that allows assigning absolute priorities, the LLQ protocol.

Although UDP is used in applications that can be treated as Best Effort and as a transport for real-time applications, this work will not focus on these characteristics within the experimentation.

4.1 Traditional networks scenario

4.1.1 Test without QoS, with Iperf3 [8], single stream over GNS3 [9], OSPF protocol

A first TCP stream is sent over port 5201 from VM1 to VM3. With this configuration we obtain that the capacity of the system is approximately 17 Mbps at the moment of starting the packet loss. This result will set the bandwidth limit as a parameter in the subsequent performance tests of this scenario. The OSPF protocol chose the path PE1–P4–P5–PE2 within “Area 0” as shown in Figure 6.

6.png

Figure 6. Route chosen by the OSPF protocol

Figure 7 shows the sending of the TCP flow generated in Iperf from VM1 to VM3 through port 5201 in VM1.

7.png

Figure 7. Iperf3 outcome

Results: Figure 8 shows the TCP flows sent. We can appreciate the maximum capacity of the system (Bandwidth).

8.png

Own source

Figure 8. Bandwidth performance test

4.1.2 Test without QoS, with Iperf3, double streams over GNS3, OSPF protocol

Two flows were sent, one from VM1 to VM3 and one from VM2 to VM3. UDP streams were sent through port 5060 and TCP through port 5201 respectively. According to the OSPF protocol, the chosen route is the same as in the previous case, PE1–P4–P5–PE2.

Figure 9 shows the output generated by Iperf3 of the UDP flow sent from VM1 to VM3.

9.png

Figure 9. Iperf3 output for UDP flow

Figure 10 shows the output generated by Iperf3 of the TCP flow sent from VM2 to VM3.

10.png

Figure 10. Iperf3 output for TCP flow

Results: In Figure 11 we can see the difference in the bandwidth used by each of the flows. The UDP flow tries to gain the maximum bandwidth allowed by the system, but the TCP flow limits its maximum reach.

111.png

Own source

Figure 11. Bandwidth used by UDP and TCP flows

On the other hand, the percentage of packets lost for the UDP flow reaches peaks around 60% as shown in Figure 12.

12.png

Own source

Figure 12. Packet loss in UDP flows

4.1.3 Test with QoS, with Iperf3, double streams over GNS3, OSPF protocol

In the previous tests with UDP and TCP flows without QoS (experiment 4.1.1) considerable packet losses were observed, especially in the UDP flow. This configuration will try to correct these losses by applying QoS policies on the chosen queuing mechanism.

In this test, a preferential delivery service is configured for the applications that needed it, ensuring sufficient bandwidth, controlling latency and reducing data loss.

Two flows were sent, one from VM1 to VM3 and one from VM2 to VM3. UDP streams were sent through port 5060 and TCP through port 5201 respectively. According to the OSPF protocol. The chosen route is the same as in the previous case. Figure 13 shows the UDP flow from VM1 to VM3 generated under Iperf3.

13.png

Figure 13. Iperf3 output for UDP flow

Figure 14 shows the output generated by Iperf3 of the TCP flow sent from VM2 to VM3.

14.png

Figure 14. Iperf3 output for TCP flow

Results: Compared to the previous test, it can be seen how both flows are stabilized and how the packet loss of UDP flows is significantly reduced. It can also be seen how UDP flows take full advantage of the 7 Mbps, leaving the remaining 10 Mbps to TCP flows (Figure 15). In GNS3, the total 17 Mbps of bandwidth has been defined as a parameter.

15.png

Own source

Figure 15. Bandwidth used by UDP and TCP flows with QoS

Figure 16 shows the considerable decrease of 40% in the average packet loss, which results in a final value of 4%.

16.png

Own source

Figure 16. Packet loss in the flow under UDP protocol with QoS

Figure 17 shows the result of jitter (delay variation) for the UDP flow.

17.png

Own source

Figure 17. Jitter of the UDP flow with the application of differentiated services

4.2 SDN networks scenario

4.2.1 Tests with Iperf3, single flow over Mininet [10], rule of minimum number of skips

TCP streams are sent through port 5201 from h1 to h3 along the fixed path defined as s1–s2–s3–s4–s7. OSPF is not used. Figure 18 shows the scenario together with the limitation of interfaces.

18.png

Own source

Figure 18. SDN topology scenario for the TCP flow

To match the configuration of the tests developed in traditional networks, the maximum capacity of the system has been determined at 17 Mbps (Figure 19).

19.png

Figure 19. Limiting SDN Bandwidth on Mininet

As in the previous case, the bandwidth limit is decisive for the following performance tests. The following rules were established with priority 99:

•   Decrement of TTL

•   Modify ethernet address

•   Exit by interface

Figure 20 shows the configuration code for these rules in the Mininet simulator.

20.png

Figure 20. Mininet setup rules

Results: It is observed that the bandwidth remains within the limits established by the parameters specified in the rules (Figure 21).

21.png

Own source

Figure 21. Bandwidth of the TCP flow

4.2.2 Tests with Iperf3, double stream over Mininet, traffic sent by the longest route

Two flows were sent, one TCP from h1 to h3 through port 5201 and another UDP from h2 to h3 through port 5202. The same route is used as in the previous case (Figure 18) as shown in Figure 22.

22.png

Own source

Figure 22. SDN topology scenario for the TCP and UDP flows through the same route

In Figure 23, we observe the bandwidths occupied by each of the flows.

23.png

Own source

Figure 23. Bandwidth of TCP and UDP flows

Results: The number of packets lost in UDP flow is considerably lower for the same flow observed in Figure 16 despite the fact that, in this case, the two flows were sent by the longest route (Figure 24).

24.png

Own source

Figure 24. Number of packets lost from the UDP flow

4.2.3 Tests with Iperf3, double stream over Mininet, rules: minimum number of skips for UDP flow and TCP flow sent by the longest route

The flows were divided as follows: the TCP flow is sent through the route s1–s2–s3–s4–s7 through port 5202 and the UDP flow through the route s1–s5–s6–s7 through the port 5201 (Figure 25).

25.png

Own source

Figure 25. SDN topology scenario for the TCP and UDP flows through different routes

Set up of flows in Mininet (Figure 26):

•      Flows with priority 100 on s1 and s7 to correspond to TCP/UDP ports

•      TCP flow: 5202 port, s1–s2–s3–s4–s7 route

•      UDP flow: 5201 port, s1–s5–s6–s7 route

26.png

Own source

Figure 26. Mininet setup of UDP and TCP flows

Results: Figure 27 shows that the bandwidth is not affected in either of the two flows. Also, in Figure 28, we appreciate UDP packet loss is significantly reduced to 1%.

27.png

Own source

Figure 27. Bandwidth of both streams

28.png

Own source

Figure 28. Lost packets for the UDP flow

Figure 29 shows the result of the jitter (delay variation) for the UDP flow.

29.png

Own source

Figure 29. UDP flow jitter

4.3 Considerations for future experiments

In heterogeneous networks, both traditional and SDN, their developments have been much more complex. This brings many challenges to organize, manage and optimize network resources in a more effective way. One possible way to solve these problems is to incorporate more intelligence into networks as proposed by the Knowledge Plane approach (KP) [11] by applying Machine Learning (ML) [12] and cognitive techniques. However, the KP has not been prototyped or implemented at the time of writing this present work.

In traditional networks, each router or switch node can only see and act on a small portion of the network; If we need to control the entire network, it is very complex to learn from each node since they only have a small partial view of their environment. Future developments in SDN networks are expected to make it easier to learn the entire network as a whole [13].