Who's first and who's last... -? Queueing in SDN

June 23, 2023

In the article There will be quality… – policing in the SDN, we took on the subject of ensuring the general idea of data transmission quality in SDNs. We discussed the notion of traffic policing, which means cutting the traffic to user-specified amounts. This article is a continuation of the aforementioned text and aims to familiarise the reader with another way of providing QoS, through traffic shaping.

The idea of traffic queuing

Traffic shaping is a self-explanatory notion. It’s main feature is the use of QoS mechanisms to transmit a specific portion of data as efficiently as possible, i.e. without any significant packet loss. In other words, traffic, instead of being clipped to a certain amount, may be stopped by the network device, and thus its characteristics may be smoothed out (see Figure 1.).

Shaping | EXATEL
Figure 1. The result of traffic modifications achieved by policing and shaping | source: cisco.com | source: cisco.com


When the network traffic’s density does not exceed the declared values, it is freely transmitted through the network. As it approaches the preset limits, it is held up. This specific hold up in network traffic is called buffering. It is a process of storing packets in a dedicated location of the device memory. The user can declare the size of such a buffer. If it is overloaded, subsequent packets are rejected (see Figure 2.).

Figure 2. Queuing - buffering of surplus packets

 Figure 2. Queuing - buffering of surplus packets

Buffering is also used in everyday video playing on online platforms such as YouTube.
A certain portion of network data is needed to play the video properly. If the data reaches the recipient, the video is played. If not, the data is collected in a buffer to then present the viewer with a full frame and, subsequently, a moving picture. In this case, buffering is used to collect data. In networks, it is used for queueing i.e. holding up the surplus traffic.


Network queuing

The simplest queuing in networks could consist of a single buffer. In fact, a single queue with set parameters allows to maintain traffic at a certain level, for example, 100 Mb/s. However, the real value of the packet queuing mechanism is revealed when scheduling, that is, during serialisation of packets using multiple queues.

In a network, we can distinguish different types of traffic and associated demands. These could be audio/video streams for real-time conversations, or ordinary data that needs to be transmitted end-to-end. Real-time traffic must be handled as quickly as possible, without delays or fluctuations in the arrival time of subsequent packets. The only requirement for data transmission is the certainty of reaching the recipient. So you can see that the two types of traffic have different priorities. If two such streams link up in the network, it’s a good idea to distinguish, mark and assign them to the appropriate queue, while the queue for real-time traffic should have a higher priority than the queue for regular data. Finally, the specified device mechanism should choose which packet to forward to the output of the network device: a packet from the queue with a higher priority or with a lower priority; if a higher priority is chosen, then how many packets of the higher queue should be fetched from the lower queue. This is a responsibility of the scheduler, which is an algorithm that ranks packets from individual queues. One of the more popular algorithms of this type is WFQ (Weighted Fair Queueing).

Traffic shaping is therefore a rather complex process, in which the following phases can be distinguished (see Figure 3.):

    • classification – traffic classification based on the MPLS_TC or VLAN_PCP packets arriving at the switch. These are 3-bit component fields of MPLS/VLAN headers, through which we can distinguish up to 8 classes of traffic.
    • queuing – on the switch, classified packets fall into queues intended for different types of traffic or with a different priority.
    • serialisation – the algorithm ranks packets and decides which packet from which queue to retrieve and forward to the output buffer.


Figure 3. Proces traffic shapingu
Figure 3. The traffic shaping process

Queuing in SDN

For network traffic to undergo traffic shaping, network devices must be properly configured. The advantage of SDN is the automation of the process. As the central unit, the SDN controller holds information about the entire network’s topology. Thanks to this, it is able to distinguish the operator’s network end ports (see Figure 4.) – so-called UNI ports ( User Network Interface), as well as the ports between successive devices in the operator’s network I-NNI ( Internal Network-to-Network Interface). What’s more, the controller has the ability to simultaneously configure all the network devices it notices on the network. It selects ports for configuration from among the given devices and takes action on them.

In the case of traffic shaping, it is necessary to identify INNI ports, install classifiers, queues on them and activate the relevant packet scheduling algorithm.

In the case of SDN based on the OpenFlow protocol and through using Open vSwitch network devices, the process can be implemented in the following steps:

          • configuration of queues on the switch
          • configuration of flows through a given switch.
Figure 4. Example of a network with labelled port types: UNI i INNI
 Figure 4. Example of a network with labelled port types: UNI i INNI


Queue installation

To install queues on a switch port, create a queue, add it to a QoS profile, and connect the profile with the relevant INNI port.

In the following example, two queues limiting traffic to 10Mbps and 50Mbps were created and then connected with the TE1 switch port (INNI port with a link to the next switch)


# ovs-vsctl create queue other-config:max-rate=10000000


# ovs-vsctl create queue other-config:max-rate=50000000


# ovs-vsctl create qos type=linux-htb


# ovs-vsctl set qos d56353d2-8b42-4074-a64f-2aeac0ff776e queues:1=c80b2a19-90e8-4eed-a1d4-5db061a6f864

# ovs-vsctl set qos d56353d2-8b42-4074-a64f-2aeac0ff776e queues:2=94965335-6dd5-4064-91f2-9b5c09f8e7ce

# ovs-vsctl set port TE1 qos=d56353d2-8b42-4074-a64f-2aeac0ff776e


The configuration results in a QoS profile with two queues (id 1 and 2). A Linux implementation of the Hierarchical Token Bucket (HTB) algorithm was used to shape the traffic.


# ovs-vsctl list qos

_uuid               : d56353d2-8b42-4074-a64f-2aeac0ff776e

external_ids        : {}

other_config        : {}

queues            : {1=c80b2a19-90e8-4eed-a1d4-5db061a6f864, 2=94965335-6dd5-4064-91f2-9b5c09f8e7ce}

type                : linux-htb


Flow installation

Once the queues are created, they must be configured to fetch specific packets. For this purpose, the OpenFlow protocol has defined flows, which are short portions of configuration composed of the match and action fields. The match field allows you to detect and classify packets with certain parameters, while the action field describes what action is to be taken for the packet.

For the following example, let’s assume that packets entering through TE2 port will be routed to queue id 1, while packets entering through TE3 port will be routed to queue id 2, and further to output port TE1.


# ovs-ofctl add-flow ETH1 in_port=2,actions=set_queue:1,output=1

# ovs-ofctl add-flow ETH1 in_port=3,actions=set_queue:2,output=1


As a result, OpenFlow rules will be added to the device’s flows, shaping traffic to queue-set levels depending on the input port on which the packet appears.

# ovs-ofctl dump-flows ETH1

cookie=0x0, duration=9.397s, table=0, n_packets=0, n_bytes=0, in_port=TE3 actions=set_queue:2,output:TE1

cookie=0x0, duration=9.397s, table=0, n_packets=0, n_bytes=0, in_port=TE3 actions=set_queue:2,output:TE1


QoS potential in SDN

The above part of the article concludes the topic of traffic policing and traffic shaping, by showing how significant and complex quality assurance techniques are for the network. The QoS mechanisms allow you to flexibly manipulate network traffic and differentiate its level and priority from other traffic sources. In the context of SDN, QoS provides an additional flexibility over traditional solutions. Combined with a programmable application layer that enables the implementation and deployment of multiple network functions, additional business functionality can be applied. For example, in conjunction with an open API, it is possible to dynamically manage QoS levels. The end user, for an additional charge, can independently decide the speed of the traffic. This approach to service and network traffic management reduces costs and opens up a new business model in which the network function is closer to the user than ever before.

Published by: Dominika Rybińska

Related articles