Table Of Contents
Table Of Contents

Differentiated Services

Goals

Differentiated Services (DiffServ) was invented to provide a simple and scalable quality of service (QoS) mechanism for IP networks. Differentiated Services can, for example, be used to provide low latency for delay-sensitive network traffic such as voice while providing simple best-effort service to other services such as web traffic or file transfer.

This showcase presents an example network that employs DiffServ to provide preferential service to voice over other types of traffic.

INET version: 4.0

Source files location: inet/showcases/general/diffserv

About Differentiated Services

The INET User’s Guide, among many other resources, contains a good overview of Differentiated Services. If you are unfamiliar with the concept, we recommend that you read that first, because here we provide a brief summary only.

Differentiated Services classifies traffic entering a DiffServ domain into a limited number of forwarding classes, and encodes the forwarding class into the 6-bit DSCP field of the IP header. The DSCP field will then determine the treatment of packets (resource priority and drop priority) at intermediate nodes. In theory, a network could have up to 64 (i.e. 26) different traffic classes using different DSCPs. In practice, however, most networks use the following commonly defined per-hop behaviors:

  • Default PHB typically maps to best-effort traffic.
  • Expedited Forwarding (EF) PHB is dedicated to low-loss, low-latency traffic.
  • Assured Forwarding (AF) PHBs give assurance of delivery under prescribed conditions; there are four classes and three drop probabilities, yielding twelve separate DSCP encodings from AF11 through AF43.
  • Class Selector PHBs provide backward compatibility with the IP Precedence field.

As EF is often used for carrying VoIP traffic, we’ll also configure our example network to do that.

The model

The network

We will simulate one direction of a VoIP telephone call over the Internet while background traffic is present. Background traffic will be heavy enough to cause congestion in the first-hop router and impair voice quality at the receiver. Then we will use DiffServ to prioritize voice over background traffic to improve voice quality and reduce latency.

The following image shows the layout of the network:

../../../../_images/diffserv_network_layout.png

In our setup, voipPhone1 will transmit VoIP packets to voipPhone2. client will generate background traffic towards server. The internet node represents the Internet. We set the capacity of the link between router and internet deliberately low, to 128kbps, so we can more easily saturate it and demonstrate the effects of congestion on voice quality.

To make the example more realistic, voipPhone1 will transmit the actual contents of an audio file as VoIP traffic, and voipPhone2 will record the received audio into a WAV file. By playing back the WAV file produced by the simulation, we can directly assess voice quality.

The background traffic will be constant bit rate UDP traffic. Note that we use UDP instead of TCP, because congestion control algorithms present in TCP make it difficult to cause congestion with it.

Configuration and Behavior

The showcase contains three different configurations:

  • VoIP_WithoutQoS: The queue in the router’s PPP interface is overloaded and packets are dropped.
  • VoIP_WithPolicing: The VoIP traffic is classified as EF traffic and others as AF. AF traffic is rate limited using Token Bucket to 70% of the link’s capacity.
  • VoIP_WithPolicingAndQueuing: This is same as the previous configuration, except the router’s queue is configured so that EF packets are prioritized over other packets, so lower delays are expected.

The router’s PPP interface contains the key elements of Differentiated Services in this network: a queue (queue) and a traffic conditioner (egressTC). If both of them are used, the layout of the interface looks like the following:

../../../../_images/RouterPPP.png

In the VoIP_WithPolicing and VoIP_WithPolicingAndQueuing configurations, INET’s TrafficConditioner module is used in the router’s PPP interface in order to achieve the required policing.

../../../../_images/TrafficConditioner.png

In TrafficConditioner, the mfClassifier submodule is used for separating packets of different flows for marking with different DSCP values. It contains a list of filters that identifies the flow and determines their classes. Each filter can match the source and destination address, IP protocol number, source and destination ports, or ToS of the datagram. The first matching filter determines the index of the out gate. If no matching filter is found, then the packet will be sent through the defaultOut gate. The filters that are used in this showcase can be found in the filters.xml file:

<filters>
  <filter destAddress="voipPhone2" protocol="udp" destPort="1000" gate="0"/>
  <filter destAddress="server" protocol="udp" destPort="5001" gate="1"/>
  <filter destAddress="server" protocol="udp" destPort="5002" gate="2"/>
</filters>

For example, the VoIP packets, which can be recognized by their destination address voipPhone2 and UDP destination port 1000, are marked as EF traffic.

The DSCP field of the packets is then set by the modules named efMarker, af11Marker, af21Marker and beMarker. The differentiated handling of the marked packets is then achieved by metering the traffic with the token bucket based meters efMeter and defaultMeter, and dropping or reclassifying packets that do not conform to the traffic profile. In particular, excess AF traffic will be sent to the dropper module. Metering parameters are configured in the omnetpp.ini file:

[Config WithPolicing]
description = "Diffserv traffic conditioning is turned on in the ppp[0] interface of the router"
**.router.ppp[0].egressTC.typename = "TrafficConditioner"
**.efMeter.cir = "70%"
**.efMeter.cbs = 50KiB
**.defaultMeter.cir = "30%"
**.defaultMeter.cbs = 2KiB
**.defaultMeter.ebs = 4KiB

In the VoIP_WithPolicingAndQueuing configuration, a DiffservQueue module is used instead of DropTailQueue in the router’s PPP interface in order to achieve priority queuing.

../../../../_images/DiffServQueue.png

DiffservQueue, offered by INET, is an example queue that can be used in interfaces of Differentiated Services core and edge nodes to support AFxy and EF per-hop behaviors. The incoming packets are first classified by the classifier module according to their DSCP field previously set in the traffic conditioner. EF packets - these are the VoIP packets in this case - are stored in a dedicated queue, and served first when a packet is requested. Because they can preempt the other queues, the rate of the EF packets should be limited to a fraction of the bandwidth of the link. This is achieved by metering the EF traffic with a token bucket meter and dropping packets that do not conform to the traffic profile configured in the omnetpp.ini file:

[Config WithQueueing]
description = "A DiffservQueue is added to the ppp[0] interface of the router"
**.router.ppp[*].queue.typename = "DiffservQueue"
**.router.ppp[*].queue.efMeter.cir = "70%"
**.router.ppp[*].queue.efMeter.cbs = 5000B

We examine the results of the three different configurations listed above.

Results

Original Audio

As a reference, you can listen to the original audio file by clicking the play button below:

Without QoS

As expected, the quality of the received sound using the VoIP_WithoutQoS configuration is very low:

The jaggedness in the received audio is due to the fact that approximately half of the VoIP packets sent by voipPhone1 are dropped by DropTailQueue in the output interface of the router.

The delay of the VoIP packets also is very high, approximately 2.5 seconds, which is way too much compared to a real phone call. The following plot shows the delay of each VoIP packet:

../../../../_images/VoIP_WithoutQoS_delay.png

The dropouts you hear can also easily be observed if we zoom into the timeline of the received audio using Audacity:

../../../../_images/VoIP_WithoutQoS_audio.png

With Traffic Policing

In this configuration we use a traffic conditioner inside the router’s PPP interface. The following (edited) video, captured from the simulation, shows the classification and the differentiated handling of the packets in the traffic conditioner.

We can see that VoIP packets (VOICE, SILENCE) are classified as EF traffic, while the packets generated by client are classified as AF traffic. As a result, the data rate of the VoIP traffic increases and no VoIP packets are dropped.

The changes result in a better sound quality. Dropouts can now only be observed at the beginning of the recording:

The following plot shows the delay of the VoIP packets:

../../../../_images/VoIP_WithPolicing_delay.png

Although the delay of the packets is much less than it was with the previous configuration (0.3s instead of 2.5s), it is still very high for IP telephony.

The dropout problem that was present throughout the whole transmission using the first configuration is successfully eliminated, as we can see if we take a look at the audio track:

../../../../_images/VoIP_WithPolicing_audio.png

With Traffic Policing and Priority Queuing

With the VoIP_WithPolicingAndQueuing configuration, the router’s queue is configured to prioritize EF packets over other traffic. The following video shows how the different types of packets are handled:

Note that the priority module always prefers efQueue; it only takes packets from the other queues (via wrr) when efQueue is empty.

The fact that EF packets face shorter queues and have priority reduces their latency. Some delay still remains, of course, but the best audio quality could be reached with this configuration. The initial dropouts that were present in the previous configuration are almost inaudible now.

As seen from the next plot, the delay of voice packets has been reduced to about 0.11s:

../../../../_images/VoIP_WithPolicingAndQueueing_delay.png

Discussion

Use this page in the GitHub issue tracker for commenting on this showcase.